EMC Integration of PKI and Authentication Services for ... · EMC INTEGRATION OF PKI AND AUTHENTICATION SERVICES FOR ... 11 Proven Solutions Guide ... EMC Integration of PKI and Authentication

Proven Solutions Guide

EMC Solutions Group

Abstract

This Proven Solutions Guide provides procedures for integrating hardened components including VMware vSphere, vCloud Director, and EMC® VMAX® and VNX® storage on VCE™ Vblock™ Systems with a PKI X.509 certificate authority, and unifying the environment’s authentication mechanisms with a centralized directory. This guide details a secure multitenant Compute as a Service cloud solution.

July 2013

EMC INTEGRATION OF PKI AND AUTHENTICATION SERVICES FOR SECURING VMWARE VCLOUD SUITE 5.1 ENVIRONMENTS EMC VMAX, EMC VNX, VMware vSphere, VMware vCloud Director, VCE Vblock Systems

PKI X.509 certificate authority integration Centralized authentication Based on a hardened Compute as a Service cloud solution

EMC Integration of PKI and Authentication Services for Securing VMware vCloud Suite 5.1 Environments

EMC VMAX, EMC VNX, VMware vSphere, VMware vCloud Director, VCE Vblock Systems

2

Copyright © 2012-2013 EMC Corporation. All Rights Reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

All trademarks used herein are the property of their respective owners.

Part Number: H10985.1

Table of Contents

3 EMC Integration of PKI and Authentication Services for Securing VMware vCloud Suite 5.1 Environments


Table of Contents

1 Executive Summary ................................................................................................. 8

Business case ..................................................................................................................... 8

Solution overview ............................................................................................................... 9

Key results and recommendations ...................................................................................... 9

2 Introduction .......................................................................................................... 11

Document overview .......................................................................................................... 11

Proven Solutions Guide ............................................................................................................. 11

Purpose ..................................................................................................................................... 11

Scope ........................................................................................................................................ 11

Audience ................................................................................................................................... 12

Important considerations .......................................................................................................... 12

Verification versus validation .................................................................................................... 12

Terminology............................................................................................................................... 13

Technology overview ......................................................................................................... 15

Introduction to technology overview .......................................................................................... 15

Cisco Unified Computing System ............................................................................................... 15

Cisco UCS 6200 Series Fabric Interconnects ...................................................................................... 15

Cisco Nexus 5000 Series switches .................................................................................................... 15

Cisco MDS 9500 Series Multilayer Director ........................................................................................ 15

EMC Unified Infrastructure Manager/Provisioning ..................................................................... 16

EMC VMAX ................................................................................................................................. 16

EMC VNX ................................................................................................................................... 16

VCE Vblock Systems .................................................................................................................. 16

Vblock System 320 ........................................................................................................................... 16

Vblock System 720 ........................................................................................................................... 17

VMware vCloud Suite 5.1 ........................................................................................................... 17

VMware vCloud Director .................................................................................................................... 17

VMware vCloud Networking and Security ........................................................................................... 17

VMware vSphere ............................................................................................................................... 17

3 Solution Architecture ............................................................................................ 18

Six pillars of as-a-service solutions ................................................................................... 18

Introduction to six pillars ........................................................................................................... 18

Availability and protection ......................................................................................................... 19

Secure separation ..................................................................................................................... 19

Security and compliance ........................................................................................................... 19

Service assurance ..................................................................................................................... 19

Table of Contents



4

Tenant management and control ............................................................................................... 19

Service provider management and control ................................................................................. 19

Compute as a Service solution architecture ....................................................................... 20

Introduction to solution architecture ......................................................................................... 20

CaaS solution stack architecture ............................................................................................... 20

Physical architecture ................................................................................................................. 21

Logical architecture ................................................................................................................... 22

Resources ......................................................................................................................... 23

Hardware resources ................................................................................................................... 23

Software resources .................................................................................................................... 23

4 Solution Integration .............................................................................................. 25

Security recommendations and best practices .................................................................. 25

Solution and authentication integration ............................................................................ 25

PKI X.509 integration ................................................................................................................. 25

PKI hierarchy ............................................................................................................................. 26

Authentication integration ......................................................................................................... 28

Verification ................................................................................................................................ 29

5 PKI Integration ...................................................................................................... 31

Certificate authorities ....................................................................................................... 31

PKI integration ........................................................................................................................... 31

Installing and configuring Root CA ............................................................................................. 32

Installing and configuring Subordinate CA ................................................................................. 39

Installing Root and Subordinate CA certificates ................................................................. 51

Overview of Root and Subordinate CA certificates ...................................................................... 51

Installing Windows CA certificates ............................................................................................. 52

Installing Java CA certificates ..................................................................................................... 53

Subject Alternative Name attributes in certificates .................................................................... 54

End-entity certificates and certificate chain ............................................................................... 55

Submitting certificate requests ......................................................................................................... 55

Obtaining the certificate chain .......................................................................................................... 57

VMware vCloud Suite 5.1 certificates ................................................................................ 58

Overview of vCloud Suite ........................................................................................................... 58

vSphere 5.1 certificates ............................................................................................................. 58

vCenter Single Sign-On .............................................................................................................. 59

vSphere certificate template ...................................................................................................... 60

Requesting vSphere certificates ................................................................................................ 63

Installing ESXi host certificates .................................................................................................. 65

Installing vCenter certificates .................................................................................................... 67

Table of Contents



VMware vCloud Networking and Security .......................................................................... 70

Creating vShield Manager SSL certificates ................................................................................. 70

VMware vCloud Director SSL certificates ........................................................................... 72

Creating SSL certificates ............................................................................................................ 72

Location of certificates .............................................................................................................. 72

Verifying vCenter and vShield Manager certificates.................................................................... 77

Cisco UCS certificates ....................................................................................................... 79

Overview of UCS certificates ...................................................................................................... 79

Generating a new certificate request .......................................................................................... 80

Creating a trusted point ............................................................................................................. 82

Certificate chaining issue in UCS ....................................................................................................... 83

Installing the chain certificate ................................................................................................... 83

Installing the SSL certificate ...................................................................................................... 84

Applying the configuration changes ........................................................................................... 86

EMC UIM/P SSL certificate ................................................................................................. 88

Configuring UIM/P to use an SSL certificate ............................................................................... 88

EMC VMAX SSL certificates for Unisphere .......................................................................... 91

Unisphere for VMAX ................................................................................................................... 91

EMC VNX Unisphere SSL certificates .................................................................................. 95

Control station certificates ......................................................................................................... 95

Location of certificates and configuration files ................................................................................... 95

VNX storage processor certificates ............................................................................................ 97

6 Integration with Centralized Authentication ........................................................ 101

Microsoft Active Directory—LDAP over SSL ...................................................................... 101

Microsoft Active Directory SSL certificates for LDAPS ............................................................... 101

AD integrated Certificate Authorities ........................................................................................ 102

Active Directory Domain Services LDAPS certificate ................................................................. 110

Standalone or non-AD integrated Certificate Authorities .......................................................... 118

Integrated Windows authentication and service accounts ............................................... 120

Overview of Windows authentication and service accounts ..................................................... 120

Microsoft SQL Server Security .................................................................................................. 120

Integrated Windows Authentication ......................................................................................... 120

SQL Server service accounts .................................................................................................... 121

Configuring the vCenter Server database ................................................................................. 121

Service accounts for vCenter Server and Update Manager ....................................................... 130

VMware vCenter Single Sign-On: RBAC ............................................................................ 135

Overview of SSO RBAC ............................................................................................................. 135

VMware vCloud Director: LDAP and Kerberos ................................................................... 137

Table of Contents



6

Overview of vCloud Director authentication ............................................................................. 137

Configuring LDAP over SSL ....................................................................................................... 137

Configuring Kerberos ............................................................................................................... 141

Integration with vCenter SSO ................................................................................................... 144

Troubleshooting authentication problems ............................................................................... 144

Authentication integration with VMware vSphere ESXi host ............................................. 145

Overview of authentication integration with ESXi host ............................................................. 145

Adding the ESXi hosts to the Active Directory ........................................................................... 145

EMC Unisphere for VMAX authentication ......................................................................... 149

Unisphere for VMAX ................................................................................................................. 149

Authentication Prerequisites ........................................................................................................... 149

Solutions Enabler Prerequisites ...................................................................................................... 149

Configuring Unisphere for VMAX authentication .............................................................................. 150

EMC VNX LDAP authentication over SSL .......................................................................... 151

Overview ................................................................................................................................. 151

Prerequisites ........................................................................................................................... 151

VNX certificates for integration with Active Directory ................................................................ 151

Manage LDAP Domain certificates ........................................................................................... 152

Authentication integration with TACACS+ ........................................................................ 157

Overview of authentication integration with TACACS+ .............................................................. 157

TACACS+ installation notes ..................................................................................................... 157

TACDES ........................................................................................................................................... 158

TACTest ........................................................................................................................................... 158

TACVerify ........................................................................................................................................ 159

MDS TACACS+ integration ........................................................................................................ 159

Nexus TACACS+ integration ..................................................................................................... 159

Cisco UCS Manager and TACACS+ integration .......................................................................... 159

UCS Manager command line interface ..................................................................................... 160

UCS Manager GUI .................................................................................................................... 162

EMC UIM/P TACACS+ integration ............................................................................................. 165

Assigning user privileges ................................................................................................................ 168

UIM/P - Vblock System discovery over SSL .............................................................................. 170

Prerequisites .................................................................................................................................. 170

UCS cluster ..................................................................................................................................... 170

VNX storage processor .................................................................................................................... 173

SAN fabric ....................................................................................................................................... 173

Troubleshooting UCS discovery issues ............................................................................................ 173

7 Verification ......................................................................................................... 175

PKI certificate verification ................................................................................................ 175

Verification process for PKI certificates .................................................................................... 175

Table of Contents



Authentication verification .............................................................................................. 177

Verification process for authentication services ....................................................................... 177

Testing LDAPS connectivity ...................................................................................................... 178

8 Conclusion .......................................................................................................... 181

Summary ........................................................................................................................ 181

Findings .......................................................................................................................... 181

9 References .......................................................................................................... 183

White papers ........................................................................................................................... 183

Product documentation ........................................................................................................... 183

Vendor implementation guides................................................................................................ 183

Vendor hardening guides ........................................................................................................ 183

10 Appendix A .......................................................................................................... 185

Red Hat Enterprise Linux integration with Active Directory ............................................... 185

Windows Server 2008 R2 SP1 Component ............................................................................... 185

Red Hat Enterprise Linux 6.3 configuration .............................................................................. 189

RHEL preparation for integration with AD ......................................................................................... 189

Pivotal Greenplum Database and PostgreSQL integration with Active Directory ................ 192

Integration Overview ............................................................................................................... 192

Active Directory configuration .................................................................................................. 192

Pivotal Greenplum Database 4.2.x configuration ..................................................................... 192

PostgreSQL 9.x configuration .................................................................................................. 193

RecoverPoint 3.5 integration with Active Directory ........................................................... 194

Integration Overview ............................................................................................................... 194

Active Directory configuration .................................................................................................. 195

RecoverPoint PKI configuration ................................................................................................ 195

RecoverPoint LDAPS configuration ........................................................................................... 198

11 Appendix B .......................................................................................................... 202

Table of Procedures ........................................................................................................ 202

1 Executive Summary This chapter summarizes the proven solution described in this document and includes the following sections:

Business case

Solution overview

Key results and recommendations

Business case Today, service providers face several challenges in delivering services to their clients. In particular, they need to demonstrate that the security of their systems are aligned with their customers’ requirements and where appropriate, compliant with regulatory and industry standards. As workloads shift from physical data centers into virtual cloud-based environments, the associated security requirements and challenges also change from those that are simple to manage to those that are more complex to maintain. This is largely because of challenges associated with service provider-operated multitenant environments. Service providers can offer cloud computing services that incorporate this guide as a solution to these challenges, while integrating customer service catalogs into an easy-to-deploy platform.

A key requirement of many regulatory and industry standards is strong authentication. Securing the infrastructure by integrating with a public key infrastructure (PKI) to provide authenticity, non-repudiation, encryption and additionally converging the various authentication sources into a single directory enables the service provider to address this key requirement and simplify administration of the overall environment.

While this solution uses EMC® Compute as a Service (CaaS) architecture as its foundation, the solution also has direct application to other EMC “as-a-service” offerings such as Messaging and Collaboration as a Service (MCaaS) and Backup as a Service (BaaS). EMC has established a flexible and secure baseline to deliver these additional value-added services, to create new revenue streams, and to solve information security and compliance implications when moving workloads between clouds.

Customers list security of information and data as one of their top concerns in moving to cloud computing-based environments. Service providers need to demonstrate that they have followed sufficient due diligence in establishing robust infrastructures with process-based monitoring and reporting to recognized standards and certifications.

Chapter 1: Executive Summary



By demonstrating the strong authentication integration capabilities for a compute, network, and storage infrastructure EMC has provided an already-proven baseline configuration that:

Simplifies integration of the solution components with PKI and converged authentication services

Demonstrates the depth of integration possible

Greatly shortens the duration, and therefore the cost, in deploying such a solution

Therefore the effort and cost involved in creating and maintaining an environment that complies with industry and regulatory expectations around centralized authentication and certificate management is simplified.

Solution overview The as-a-service solution environment described in this Proven Solutions Guide (PSG) deals with the configuration of servers, storage, networking, and security hardware and software components, and provides a resource for you to achieve compliance.

This solution enables service providers to further enhance a hardened security baseline across hardware and software stacks. In addition, it describes the challenges of securing authentication to further harden the environment through:

Integration with a public key infrastructure (PKI) to enable stronger authentication and nonrepudiation.

Integration with a centralized authentication directory service to enable a centralized point of administration and policy enforcement.

For a broader description on the EMC CaaS architecture underpinning this solution, refer to the following white papers:

EMC Compute-as-a-Service: Design Principles and Considerations for Deployment—VCE Vblock Systems, VMware vCloud Director

EMC Security Design Principles for Multi-Tenant as-a-Service Environments

Design Principles and Considerations for Configuring VMware vShield in Service Provider Environments

If you do not have access to these documents, contact your EMC representative.

Key results and recommendations This solution helps to reduce the concerns around the complexities of the underlying infrastructure by demonstrating how an as-a-service solution stack can be tightly integrated with PKI and a common authentication directory to provide centralized administration and tighter control over security.

Chapter 1: Executive Summary



10

We1 verified the following during testing of the solution:

Integration with a PKI implementation that enabled encryption of management activities

Building and testing of a fully functional solution where all components use trusted certificates for authentication

Integration with a centralized point of authentication and authorization for common system components

1 In this PSG, "we" refers to the EMC Solutions engineering team that validated the solution.

2 Introduction This chapter introduces the solution and its components, and includes the following sections:

Document overview

Technology overview

Document overview

This PSG focuses on each of the specific elements required to implement the use of PKI X.509 certificates and subsequent steps to integrate centralized authentication in the various components of the solution stack.

By integrating PKI and authentication, the solution is able to offer a centralized approach for access, authorization, and accounting of the various components.

The hardware and software components on which this PSG are based have already been hardened by implementing the vendors’ security best practices. The PSG uses a solution environment based on the EMC CaaS solution architecture.

The purpose of this PSG is to provide a detailed approach to integrating a hardened as-a-service environment with PKI. In addition, the solution includes the key steps required to unify the authentication mechanisms of the hardware and software solution components with a centralized environment by using Terminal Access Controller Access-Control System Plus (TACACS+) and Microsoft Active Directory, and the required configuration changes.

It also identifies considerations relevant to service providers and their customers, and is a valuable resource to help you achieve compliance with industry or regulatory standards.

This PSG documents the results of integrating best practices for each vendor’s hardware and software components in the CaaS solution stack. This is applicable to any EMC as-a-service solution stack.

Hardening best practices have been followed in accordance with the vendors’ guidelines, where available. For more information, see Vendor hardening guides. Details of how to implement the vendors’ security best practices are not covered in the PSG.

Application of the hardening guidelines did not negatively affect our ability to manage or integrate a secure multitenant CaaS environment into a PKI or central authentication system.

Proven Solutions Guide

Purpose

Scope

Chapter 2: Introduction



12

Some general configuration and operational procedures and processes are outlined in this PSG. For detailed technical information relating to each product, refer to the appropriate documentation available from the vendors.

This PSG is intended for EMC employees, partners, and customers including IT planners, virtualization architects and administrators, and any others involved in evaluating, acquiring, managing, operating, configuring, securing, auditing or designing an as-a-service infrastructure environment using EMC technologies.

Throughout this PSG, we assume that you have some familiarity with the concepts and operations of virtualized cloud infrastructures and security frameworks, and how they are used to achieve a hardened security baseline.

This PSG documents Microsoft Active Directory Certificate Services as a PKI solution to integrate with the EMC solution stack, for the purposes of validation and demonstration. It does not specify or recommend any specific PKI architecture.

Similarly, in the context of centralized authentication, Microsoft Active Directory and TACACS+ provide a means of validation to demonstrate integration points in this PSG.

Establishing a public key infrastructure and directory services requires significant attention to requirements, design, planning, and implementation, all of which are beyond the scope of this PSG.

This PSG, in documenting integration points for PKI and authentication services, is intended as a resource to guide service providers preparing for industry and regulatory standards compliance, such as Payment Card Industry Data Security Standard (PCI DSS) 2.0. It is not a guide on achieving PCI DSS 2.0 compliance.

As a matter of good due diligence, the recommendations contained herein should be assessed according to the business needs, information security policies, and risk management methodologies of the organization planning an implementation.

The procedures for integrating the PKI X.509 certificates and centralized authentication have been verified as detailed in Verification.

Verification is the process of testing the system to determine that we built the system correctly. In contrast, validation answers the question of whether the correct system was built, and is typically determined by stakeholders. For the purposes of this PSG, we are simply verifying that the integration effort was completed correctly.

Audience

Important considerations

Verification versus validation




Table 1 provides important terms frequently used in this paper.

Table 1. Terminology

Term Definition

PKI Public Key Infrastructure, as a collection of tools and policies used in the creation, management, and distribution of X.509 digital certificates.

AIA The Authority Information Access extension, as defined in RFC-5280, is used by a CA to provide information about the issuer of a certificate.

CDP The CRL Distribution Point extension, as defined in RFC-5280, identifies how CRL information is obtained.

X.509 X.509 specifies a format for certificates and CRLs. Almost all certificates use the X.509 version 3 format, described in RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile".

CRL A Certificate Revocation List, as defined in RFC 5280, is a list of certificates that have been revoked and should not be trusted.

CA Certificate Authority, digitally signs certificates for end-entities or issues certificates for CAs that are subordinate to it.

Root CA The Root Certificate Authority is the trust anchor in the chain of trust or certification path of a PKI implementation. It can issue end-entity certificates but more commonly issues certificate-issuing certificates to intermediate CAs.

Intermediate CA An intermediate CA is a CA that has been issued with a certificate-issuing certificate by a Root or Intermediate CA. It may in turn issue a certificate-issuing certificate to another intermediate CA or issue certificates for end-entities (see Issuing CA).

Issuing CA An issuing CA digitally signs certificate requests for end-entities.

Subordinate CA This is a CA that is subordinate to the Root CA. It is a term that is often used interchangeably with Intermediate CA.

PEM Base64 encoded certificates

Privacy Enhanced Mail, or PEM, is a key format that stores data in a Base-64 encoded Distinguished Encoding Rules (DER) format. The PEM format is often used for representing a certificate, certificate request, or PKCS#7 object in ASCII by encoding it in base64 and putting the encoding between the typical PEM BEGIN and END delimiters.

Terminology

http://tools.ietf.org/html/rfc5280



http://www.ietf.org/rfc/rfc2459.txt

http://www.ietf.org/rfc/rfc5280.txt




14

Term Definition

DER format Distinguished Encoding Rules, or DER format is a subset of the Basic Encoding Rules or BER that always provides only one way to encode any data structure defined by ASN.1. This is used in applications in which unique encoding is needed, such as when a digital signature is computed.

PKCS#7 Used for certificate dissemination (for instance as a response to a PKCS#10 message)

Keystore A keystore contains keys or certificates. The most popular keystore file formats used by Java programs are JKS, JCEKS and PKCS#12

JKS Java KeyStore formatted using the SUN provider in the standard JDK.

JCEKS Java Cryptography Extension KeyStore formatted using the SunJCE provider in the Java Cryptography Extension (JCE). JCEKS has two major advantages over JKS:

Can store secret keys

Uses stronger 3DES (DES eDE) encryption for stored private keys

PKCS#12 PKCS#12 is typically used to store a private key with its corresponding X.509 certificate in a single file that can be encrypted and signed. It can be used to store all the certificates of a chain of trust (also called a certificate chain or certificate validation path). Java programs can read this keystore format but cannot write to it or modify its contents.

IWD Integrated Windows Authentication

LDAP Lightweight Directory Access Protocol, typically used in conjunction with a database (commonly called LDAP directory) for authentication or information storage.

LDAP Lightweight Directory Access Protocol transmission encrypted with SSL.

RBAC Role-based access control

SAN In the context of this PSG, means Subject Alternative Name, used in x.509 certificates to denote additional names or IP addresses.




Technology overview

This section provides a brief description of the major components of the validated solution environment. The components include:

Cisco Unified Computing System

EMC Unified Infrastructure Manager/Provisioning

EMC VMAX®

EMC VNX®

VCE™ Vblock™ Systems

VMware vCloud Director

VMware vShield

VMware vSphere

Cisco Unified Computing System (UCS) provides the computing platform purpose-built for virtualization, and delivers a cohesive system that unites computing, networking, and storage access. Cisco UCS integrates a low-latency, lossless 10 Gigabit Ethernet unified network fabric with enterprise-class, x86-architecture servers. This platform can be scaled to the demands of virtualized desktop workloads without sacrificing performance or application responsiveness. Cisco UCS Manager enables a stateless computing model that uses service profile templates to scale up large pools of fully provisioned computing resources from “bare metal”, within a fraction of the time required by traditional server solutions.

Cisco UCS 6200 Series Fabric Interconnects

Cisco UCS 6200 Series Fabric Interconnects are a core part of Cisco UCS and provide both network connectivity and management capabilities to all attached blades and chassis. The Cisco UCS 6200 Series offers line-rate, low-latency, lossless 10 Gigabit Ethernet and Fibre Channel over Ethernet (FCoE) functions. The interconnects provide the management and communication backbone for the Cisco UCS B-Series Blades and UCS 5100 Series Blade Server Chassis.

Cisco Nexus 5000 Series switches

The Cisco Nexus 5000 Series offers an end-to-end solution for aggregation, and end-of-row and top-of-rack server connectivity in a single platform. The switch series, using cut-through architecture, supports line-rate 10 Gigabit Ethernet on all ports while maintaining consistently low latency, irrespective of packet size and services enabled. The Cisco Nexus 5000 Series platform is run by Cisco NX-OS software. It was specifically designed for the most critical place in the network—the data center.

Cisco MDS 9500 Series Multilayer Director

The Cisco MDS 9500 Series Multilayer Director layers a broad set of intelligent features onto a high-performance, open-protocol switch fabric. By addressing the stringent requirements of large data center storage environments, Cisco MDS 9500

Introduction to technology overview

Cisco Unified Computing System




16

Series Multilayer Director provides high availability, security, scalability, ease of management, and transparent integration of new technologies.

EMC Unified Infrastructure Manager/Provisioning (UIM/P) provides a powerful and simplified solution to discover and configure VCE™ Vblock™ Systems. From this single tool, service providers can discover, configure, and provision their compute, network, and storage resources as a service offering.

The configuration and application of a service offering can be linked to resources configured at a later stage in vCloud Director, for example, tenant organizations, Organization vDCs and Provider vDCs. UIM/P integrates with vCenter, and provides the ability to provision high availability (HA) and DRS-enabled VMware vSphere ESX and VMware vSphere ESXi clusters, synchronize these clusters in vCenter, and provision the resources through to vCloud Director Provider vDCs.

The EMC Symmetrix® VMAX ®system features a revolutionary Virtual Matrix Architecture. This system architecture builds upon the rich heritage of the Symmetrix multicontroller platform and extends the value of the Direct Matrix Architecture® to deliver unprecedented performance, availability, and functionality at a reduced cost. The unique scale-out architecture of the Symmetrix VMAX system provides the foundation to scale to hundreds of petabytes of capacity. They are all flexibly deployed throughout the virtual environment and can be controlled through a single screen.

VMAX system architecture provides a Virtual Matrix that can scale beyond the confines of a single system footprint. The core element of the Virtual Matrix is the Symmetrix VMAX engine, which includes caches, front-end connectivity, and back-end connectivity.

The EMC VNX family delivers innovation and enterprise capabilities for file, block, and object storage in a scalable, easy-to-use solution. This next-generation storage platform combines powerful and flexible hardware with advanced efficiency, management, and protection software to meet the demanding needs of today’s enterprises.

The VNX series is designed to meet the high-performance, high-scalability requirements of midsize and large enterprises, delivering performance, efficiency, and simplicity for demanding virtual application environments.

VCE designs and delivers Vblock Systems, which seamlessly integrate leading compute, network, and storage technologies. Through intelligent discovery, awareness and automation, Vblock Systems provide the highest levels of virtualization and application performance. Vblock Systems are unique in their ability to be managed as a single entity with a common interface that provides customers’ end-to-end-visibility.

Vblock System 320

The Vblock System 320 is an agile and efficient data center class system, providing flexible and scalable performance. The Vblock System 320 features a high density,

EMC Unified Infrastructure Manager/Provisioning

EMC VMAX

EMC VNX

VCE Vblock Systems




compact fabric switch, tightly-integrated fabric-based blade servers, and unified storage.

Vblock System 720

The Vblock System 720 is an enterprise-class mission-critical system for demanding workloads and service levels. It includes a director-class fabric switch, an advanced fabric-based blade server, and a storage platform.

The VMware vCloud Suite is an integrated cloud solution that automates service provisioning in multitenant environments. It simplifies service provider and tenant operations and delivers the best SLAs for all applications. This integrated product offering includes all the elements needed to build a complete multitenant cloud solution using the following products. In this guide, we built our environment using a subset of the suite that includes the following products.


VMware vCloud Director is a cloud computing management platform for private and hybrid cloud-computing infrastructures. Using VMware vSphere, vCloud Director manages cloud infrastructure services by applying the principles of pooling, abstraction, and automation. It helps manage as-a-service offerings by monitoring and controlling cloud components such as security, virtual machine provisioning, and self-service portal access.

VMware vCloud Networking and Security

VMware vCloud Networking and Security (vCNS) provides common gateway and network services to deliver network communications and connectivity within the tenant’s virtual data center (vDC) networks, supplying security at the edge and between the tenant’s internal networks. In addition, VXLAN technology enables network abstraction and elasticity, scaling workloads across the data center without the need to reconfigure the physical network. The Edge virtual security gateway delivers integrated network and security services such as dynamic host configuration protocol (DHCP), VPN, web load balancing, network and port address translation (NAPT), and fully-fledged Layer 3/Layer 4 stateful firewall support. The App Firewall protects applications at the vNIC level applying security policies to protect workloads.

VMware vSphere

VMware vSphere is a virtualization suite of tools that provide compute, network, storage, security, availability, and automation resources. vSphere can transform or virtualize computer hardware including CPU, RAM, storage, and network, to create fully functional virtual machines that run their own operating systems and applications just like a physical computer.

VMware vCloud Suite 5.1

3 Solution Architecture This chapter introduces the solution and its components, and includes the following sections:

Six pillars of as-a-service solutions

Compute as a Service solution architecture

Resources

Six pillars of as-a-service solutions

EMC as-a-service solutions are built by using multiple technologies that include the compute, network, security, storage, and management resources of the compute environment. For successful cloud-service delivery, all as-a-service solutions, including Compute as a Service, must adhere to six key design principles, as shown in Figure 1.

Figure 1. Six pillars of as-a-service solutions

Service providers can use these pillars as the framework for any as-a-service solution to deliver IT services through the network to their customers. The platform enables service providers to build agile, secure, available, and interoperable solutions as the foundation for the services that they provide. By reducing administrative and operational expenses and efforts in such environments, service providers can improve their current and future IT investment decisions for the services they deliver.

Introduction to six pillars

Chapter 3: Solution Architecture



For end users, resources and data must be continuously available. The most secure environment is of no use if it is unavailable. Service providers can ensure availability through redundant systems, configurations, and architecture to minimize or eliminate points of failure that can adversely affect availability to end users.

Security is a primary adoption concern. Organizations need to ensure that their data is secure at all times—at rest, in motion, and in use. In a secure multitenant environment, end users need to operate in a dedicated environment in which it appears, from the tenant’s perspective, that all resources are dedicated to that tenant. In addition, the infrastructure must ensure that no tenant can influence the behavior of another tenant’s environment in any way.

It is vital to ensure the integrity of each tenant’s environment. Internal and external compliance requirements are continuously expanding. Organizations are concerned about the loss of transparency and insight in the management of the environment, and compliance with regulatory and industry standards.

The ability to deliver consistent, predictable service, across systems within a data center, and across geographically dispersed data centers, is fundamental to the service provider’s business.

In every cloud services model, service providers delegate some elements of control to the tenant. For some service providers, this is a matter of convenience; for others, it is a matter of security or compliance.

Providers of infrastructure services in a multitenant environment require comprehensive control and complete visibility of the shared infrastructure to provide the data protection, security, and service levels that their tenants expect. The ability to control, manage, and monitor resources at all levels of the infrastructure requires a dynamic, efficient, and flexible design. This enables service providers to access, provision, and then release compute resources from a shared pool quickly and easily, with minimal management effort.

Availability and protection

Secure separation

Security and compliance

Service assurance

Tenant management and control

Service provider management and control




20

Compute as a Service solution architecture

This section provides details on the architecture of this solution.

The architecture validated in this PSG is represented using a combination of logical and physical diagrams to describe the core technologies that make up an as-a-service solution stack and supporting infrastructure.

The integrated products focus specifically on an architecturally consistent Vblock Systems environment and cover hardware and software components from VMware, Cisco, and EMC.

Figure 2 shows an example of a CaaS solution stack.

Figure 2. A logical depiction of an EMC solution stack

Introduction to solution architecture

CaaS solution stack architecture




Figure 3 shows the physical interconnectivity (network and Fibre Channel fabric) between the Vblock Systems hardware components, including the VNX array, used in the CaaS solution stack that is the basis for this solution.

This configuration is applicable to all EMC virtualization solutions that employ the same key components.

Figure 3. Vblock Systems physical hardware components and their interconnectivity with VNX in an EMC CaaS solution stack

Physical architecture




22

Figure 4 shows a logical depiction of the software components of the CaaS stack provisioned on the Vblock System used in this solution.

Per VCE and VMware recommended best practices, the vCenter Servers for the MGMT and CaaS management pods (and supporting components, such as database servers and vShield Manager) are not provisioned on the ESXi cluster that they manage.

As shown in Figure 4, each cluster has zones, with each color representing a different network.

Figure 4. Logical view of EMC CaaS solution stack software components that are provisioned on Vblock Systems

Logical architecture




Resources

Table 2 lists the hardware resources used in this solution.

Table 2. Hardware resources

Hardware Quantity Configuration Notes

Cisco UCS B200 server blade

2 2 Intel Xeon 5500 series, 48 GB RAM

Hosts vCloud Director CaaS cluster VMware vSphere ESXi hosts

Cisco UCS B200 server blade

2 2 Intel Xeon 5500 series, 96 GB RAM

Hosts management cluster ESXi hosts

Cisco UCS C250 servers 2 2 Intel Xeon 5600 series, 48 GB RAM

AMP ESXi hosts

Cisco MDS 9506 2 6 slots, 2 Supervisor modules

Configured for dual FC fabric

Cisco Nexus 5548UP 1 C5548 Chassis Infrastructure Ethernet switch

Cisco UCS Chassis 2 UCS5108 Chassis Includes 2 x 6248UP fabric interconnects

EMC VMAX 10K 1 Enginuity 5876.85.95 Shared block storage array

EMC VNX5700 Unified 1 Unified Storage version: File 7.1.55-3/FLARE 5.32.000.5.509

Configured to only provide shared block storage

Table 3 lists the software resources used in this solution.

Table 3. Software resources

Software Version Notes

Cisco MDS NX-OS 5.2(6a) Software image version for Nexus 5010

Cisco Nexus NX-OS 5.2(1)N1(2a) Software image version for MDS 9506

Cisco UCS Manager 2.0(4a) Cisco UCS management software and firmware

EMC UIM/Provisioning 3.2 Provisions service offerings on Vblock Systems

EMC Unisphere® for VMAX 1.5.1.1 Manages EMC VMAX array

EMC Unisphere 1.2.26 Manages EMC VNX array

EMC VNX5700

VNX OE for block

5.32.000.5.509 Operating environment for EMC VNX block storage array

EMC VNX5700

VNX OE for file

7.1.55-3 Operating environment for EMC VNX file

Hardware resources

Software resources




24

Software Version Notes

VMware vSphere ESXi 5.10A build 838463 Hypervisor

VMware vCloud Director 5.1.2 build 1068441 Cloud resource management solution that leverages VMware vSphere resources

VMware vCenter Server 5.1.0B build 947673 vSphere management server

VMware vShield Manager 5.1.2 build 943471 Used to manage and deploy vShield Edge, in this environment, by VMware vCloud Director

OpenSSL 1.1 Used to create signing requests and convert certificates between formats

Microsoft SQL Server 2008 R2 SP1 DB management system that hosts the vCloud and vSphere databases

Microsoft Windows Server 2008 R2 x64 SP1 Used as standard image for all Windows-based guest OS

4 Solution Integration This chapter introduces hardening and integration and includes the following sections:

Security recommendations and best practices

Solution and authentication integration

Security recommendations and best practices This solution is based on an environment that implements security recommendations and best practices based on vendor guides on each of the components that form an as-a-service solution.

The security best practices we applied follow the security recommendations from each vendor.

In the absence of any specific vendor recommendations to remediate or mitigate risks, industry best practice guides and resources should also be considered from sources such as:

Center for Internet Security: Security Benchmarks

Department Information Systems Agency: Security Technical Implementation Guides (STIGs)

National Institute of Standards and Technology: Computer Security Resource Center – Special Publications

Note This is not intended as a complete list of security resources.

Solution and authentication integration

The goal of integrating a PKI infrastructure within the context of a multitenant as-a-Service environment is to ensure that all of the components that use or rely on X.509 certificates and technology are trusted. By default, most, if not all, components are installed with self-signed untrusted X.509 certificates.

This PSG provides a guide for integrating the as-a-service solution stack and supporting infrastructure into a single PKI hierarchy.

This solution demonstrates the use and integration of a simple internal public-key infrastructure. This PSG does not cover PKI policies, registration authorities (RAs), validation authorities (VAs), or other components typically used within the public-key infrastructure. Careful design considerations should be taken into account when implementing PKI with your organization, which is outside the scope of this PSG.

PKI X.509 integration

http://benchmarks.cisecurity.org/en-us/?route=downloads

http://iase.disa.mil/stigs/index.html

http://iase.disa.mil/stigs/index.html

http://csrc.nist.gov/publications/PubsSPs.html

http://csrc.nist.gov/publications/PubsSPs.html

Chapter 4: Solution Integration



26

Certain safeguards should be put in place to protect the private keys used by the CAs. By using network-based hardware security modules (HSM), a virtualized environment can use these devices to store the CAs’ private keys in a secure manner with tamper protection. HSMs can also provide offloading of certain cryptographic processing for symmetric or asymmetric needs where performance and speed is a requirement.

Figure 5 shows the hierarchal relationship of the PKI environment with the Root self-signed certificate, the issuing CA certificate, and the end-entity-issued certificates.

Figure 5 also shows the trust relationship between the end-entity certificates used in this solution and the end user.

Figure 5. PKI hierarchy for EMC CaaS solution stack

PKI hierarchy




All issuing CA and end-entity certificates have defined URLs for the Authority Information Access (AIA) where the Root and Subordinate CA certificates are located, and the location for the Certificate Revocation List Distribution Point (CDP) that contains a list of revoked certificate serial numbers. The following certificates were issued for this solution:

Root CA has a self-signed certificate and is stored in the certificate stores of each system that will access and validate end-entity certificates. Certificate and private key are created during role installation. This CA only issues certificates to Subordinate CAs.

Subordinate or issuing CA has a certificate signed by the Root CA and is stored on each system that will access and validate end-entity certificates. The private key and certificate request is generated during role installation. The issuing CA issues certificates to the end entities.

ESXi end-entity certificate is issued by Subordinate CA and requested with a Subject Alternative Name (SAN) that consists of fully qualified domain name (FQDN), hostname, and IP address. The private key and certificate request is generated using OpenSSL. The issued certificate thumbprint is registered with vCenter and used for secure communications.

vCenter Single Sign-On (SSO), Inventory Service, vCenter Server, vCenter Orchestrator, vSphere Web Client, Log browser, and vSphere Update Manager, all use unique private keys, full certificate chains, and end-entity certificates issued from the Subordinate CA. The certificate contains the standard SAN attributes, FQDN, hostname, and IP address. The private key and certificate request are generated using OpenSSL. These certificates are registered within vCenter and used for secure communications and to validate vCenter authenticity from the vSphere Client.

vShield Manager generates a certificate request to be submitted to the CA. The request is submitted with the appropriate SAN attributes to the Subordinate CA. Once the certificate is installed on the vShield Manager, this is used to register that service with vCenter and vCloud Director.

vCloud Director end-entity certificates issued by the Subordinate CA with the SAN attributes, FQDN, hostname, and IP address. Two certificates are requested and issued for each vCloud Director cell. These are used for registering the services and secure communications for web-client access.

UIM/P certificate is issued by Subordinate CA and requested with a SAN that consists of FQDN, hostname, and IP address. The private key and certificate request are generated using the UIM/P SSL utility script. The installed certificate is applied to the Apache, JBoss, and Tomcat management interfaces to secure administrator access.

VNX Control Station certificate is issued by Subordinate CA and requested with a SAN that consists of FQDN, hostname, and IP address. The private key and certificate request are generated using OpenSSL. The installed certificate is applied to the Unisphere management interface to secure administrator access.

VNX SP certificate is issued by Subordinate CA and requested with a SAN that consists of FQDN, hostname, and IP address. The certificate request is




28

generated and the issued certificate is installed through the storage processor setup web page. The installed certificate is applied to the storage processor management interface to secure administrator access.

Solutions Enabler certificate is issued by Subordinate CA and requested with a SAN that consists of FQDN, hostname, and IP address. The issued certificate is used to secure management communications between Unisphere for VMAX and Solutions Enabler.

Unisphere for VMAX certificate is issued by Subordinate CA and requested with a SAN that consists of FQDN, hostname, and IP address. The certificate request is generated and the issued is applied to the Unisphere for VMAX management interface to secure administrator access.

Active Directory LDAPS certificate is issued by the Subordinate CA and requested on each participating Domain Controller using the Certificates MMC. The certificate is installed in the Domain Controller certificate store and applied to the LDAP protocol to secure authentication and authorization communications.

A significant challenge in securing any environment is securing how credentials are used to access the solution’s resources. This is addressed in part by PKI integration by implementing trusted certificates that enable authenticity of the components that encrypt administrator access to the management interfaces.

Another challenge is the disparate authentication containers across hardware and software components with differing account and password policies. To address this challenge, this solution covers the integration of the authentication mechanisms found in VMware, EMC, and Cisco components, with Kerberos, LDAPS, and TACACS+ authentication services by using Microsoft Active Directory as a centralized directory.

Microsoft Active Directory provides a single point of control for account management and policy enforcement. In addition, it is used to provide Kerberos and LDAPS authentication, and authorization services. To address devices that do not integrate with Active Directory we used an implementation of TACACS+ from TACACS.net and configured it to use Active Directory to be the authentication source.

Authentication integration




Figure 6 shows the authentication hierarchy used in this solution.

Figure 6. Authentication relationships between the solution components, Kerberos, LDAPS, and TACACS+ authentication services, and Active Directory

This integration effort enables end-to-end encryption of authentication credentials and authorization communications over the virtual and physical networks.

Once the security hardening and integration activities were completed, two tenant environments were deployed in the CaaS solution and tested to ensure that tenant isolation was maintained within the secured CaaS infrastructure.

Verification




30

Documentation of the testing regimen used and detailed results is beyond the scope of this PSG.

While no negative impact on functionality or usability was observed following verification of both the vendors’ security best practices and PKI and LDAP authentication integration, EMC strongly recommends that an extensive testing regimen is developed that is appropriate for the target environment and consistent with information security policies.

5 PKI Integration This chapter introduces the PKI integration and includes the following sections:

Certificate authorities

Installing Root and Subordinate CA certificates

VMware vSphere certificates

VMware vShield Manager certificates

VMware vCloud Director certificates

Cisco UCS certificates

EMC UIM/P certificates

EMC VNX Unisphere SSL certificates

Certificate authorities

Part of hardening the infrastructure is to remove the X.509 self-signed certificates and replace them with valid signed certificates. Some organizations may choose to use an external entity for this.

In this solution, we configured an internal certificate authority (CA) using a hierarchical structure. This shows the CA architecture with the Root at the top level, which is either offline or air-gapped. Subordinate CAs are tiered in the Active Directory forest.

This PSG includes the procedures used in the deployment of the Microsoft Active Directory Certificate Services PKI infrastructure employed in this solution. You must follow best practices when designing your organization’s PKI infrastructure. You can take additional security measures to ensure protection of the private keys in use by the CAs.

Note Hardware Security Modules (HSM) can provide increased randomness and private key protection, but were not used in this solution.

PKI integration

Chapter 5: PKI Integration



32

This section describes the steps taken to deploy Microsoft Active Directory Certificate Services in the environment.

In this solution, we installed the Root CA (ESG Lab Root Certificate Authority) on a dedicated Microsoft Windows 2008 R2 standalone virtual machine.

Procedure: Deploy the Root CA To install the Root CA, follow these steps:

1. Connect to the desktop of the Microsoft Windows Server that will be used as the Root CA.

2. Click Start, select Administrative Tools, then select Server Manager.

3. Click Add Roles.

4. In the Select Server Roles window, select Active Directory Certificate Services, then click Next.

5. In the Role Services window, only select Certificate Authority, then click Next.

6. Because this is not part of a domain, in the Setup Type window, Enterprise must be grayed out. Standalone is selected by default. If not, select Standalone then click Next.

7. In the CA Type window, select Root CA, then click Next.

8. In the Private Key window, select Create a new private key, then click Next.

9. In the Cryptography window, select RSA#Microsoft Software Key Storage Provider for CSP, 2048 for Key Length, and SHA256 for HASH, then click Next.

10. In the CA Name window, enter the Common Name (CN) and Distinguished Name (DN) for the CA, then click Next.

For this example, we used the following information for the CN:

ESG Lab Root Certificate Authority

For the DN suffix, we used:

OU=EMC Solutions Group,O=EMC Corporation

The preview showed the complete DN as:

CN=ESG Lab Root Certificate Authority,OU=EMC Solutions

Group,O=EMC Corporation

11. In the Validity Period window, enter the validity period (we used 25 years), then click Next.

12. In the Certificate Database window, select the database and log locations (we kept the defaults), then click Next.

13. Verify the settings in the Confirmation window, then click Install.

14. Once the installation is complete, click Close.

Installing and configuring Root CA




In a production environment, these validity periods would likely be different based on your corporate certificate policies and the period of time which the offline Root CA’s CRLs can be made available on the network.

As part of this environment, the validity period for both the certificates and certificate revocation list (CRL) issued by the Root CA was set to five years, as shown below.

C:\>certutil -setreg ca/ValidityPeriodUnits 5

C:\>certutil -setreg ca/CRLPeriod Years

C:\>certutil -setreg ca/CRLPeriodUnits 5

Procedure: Configure Root CA AIA and CDP locations Once the periods were set, we configured the location of the authority information access (AIA) and CRL distribution points for the Root CA. Because the Root CA is typically offline, it is important that the AIAs and CRLs are available. In this example, these are published on the Subordinate CA that has a DNS CNAME alias of pki.lab.esg.local.

To apply these AIA and CRL locations to the Root CA Properties extensions, follow these steps:

1. Connect to the desktop of the Root CA server.

2. To open the Certification Authority MMC, click Start, select Administrative Tools, and then select Certification Authority. Once the Certification Authority MMC is displayed, right-click on the CA (RSG Lab Root Certificate Authority) and select Properties, as shown in Figure 7.

Figure 7. Root certificate authority properties

3. Verify that each of the default CRL distribution points (CDP) in the Root CA Properties extensions for CRL match that shown in Figure 8. This ensures that none of the default CDPs is listed in the certificates issued by this Root CA.




34

Figure 8. Root CA properties extensions for the default CDP locations

4. Add the URL for the CDP. In this example, we used: http://pki.lab.esg.local/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

5. Verify that both Include in CRLs and Include in the CDP extension of issued certificates are checked, as shown in Figure 9.




Figure 9. Root CA URL location for the CDP and URL location settings

6. For the AIA, verify that each of the default AIA locations in the Root CA Properties extensions match Figure 10. This ensures that none of the default AIAs are listed in the certificates issued by this CA.




36

Figure 10. Root CA Properties extensions for the default AIA locations

7. Add the URL for the AIA location. In this example, we used: http://pki.lab.esg.local/pki/<ServerDNSName>_<CaName><CertificateName>.crt

8. Select Include in the AIA extension of issued certificates, as shown in Figure 11.




Figure 11. Root CA URL location for the AIA and URL location settings

9. Click OK, then restart Certificate Services when prompted.

10. Now that the settings have been changed, publish the Root CA’s full CRL, as shown in Figure 12.




38

Figure 12. Publish the Root CA’s CRLs

11. Verify the validity period by viewing the attributes in the CRL properties, as shown in Figure 13.

Figure 13. Verify the CRL validity period is five years (effective date and next update)




12. After publishing the CRLs, go to c:\Windows\system32\CertSrv\CertEnroll and copy the certificate and CRL to a place you can access from the Subordinate CA. You need these for AIA and CRL validation.

When you have configured the Root CA, back it up using the certificate services CA backup utility. This enables you to create a backup of the Root CA’s private key, CA certificate, certificate database, and certificate database log.

We used c:\PKI\CA Backup - 2012-09-20 as the folder location. Create the folder before backing up the CA as the CA cannot be created if the folder does not exist.

Also, it is important that you now install the Root CA certificate on the system-wide certificate stores on all systems within this environment. To see how this is done, refer to Installing Windows CA certificate and Installing Java CA certificates.

As a prerequisite to starting the Subordinate CA configuration, the Root CA certificate must be installed on the system-wide certificate store on the Microsoft Windows Server that will be used as the Subordinate CA. Once the Root CA certificate has been installed, and after joining the domain, the following steps outline the installation and configuration procedure for the Subordinate CA as an integrated component of Active Directory.

Procedure: Deploy the Subordinate CA 1. Connect to the desktop of the Microsoft Windows Server that will be used as

the Subordinate CA.

2. To open Server Manager, click Start, select Administrative Tools, and then select Server Manager.

3. Click Add Roles.

4. In the Select Server Roles window, select Active Directory Certificate Services, then click Next.

5. In the Role Services window, select both Certificate Authority and Certificate Authority Web Enrollment, then click Next.

6. After selecting Certificate Authority Web Enrollment, a dialog box prompts you to add required role services (IIS). Click Next to continue.

7. In the Setup Type window, select Enterprise, then click Next.

8. In the CA Type window, select Subordinate CA, then click Next.

9. In the Private Key window, select Create a new private key, then click Next.

10. In the Cryptography window, accept the default values, then click Next.

Note Default values are RSA#Microsoft Software Key Storage Provider for CSP, 2048 for Key Length, and SHA1 for HASH.

11. In the CA Name window, enter the Common Name (CN) and Distinguished Name (DN) information for the CA, then click Next.

For this example, we used the following information for the CN:

Cork ESG Lab Certificate Authority

Installing and configuring Subordinate CA




40

For the DN suffix, we used:

OU=EMC Solutions Group,O=EMC Corporation,L=Cork,C=IE

The preview showed the complete DN as:

CN=Cork ESG Lab Certificate Authority,OU=EMC Solutions

Group,O=EMC Corporation,L=Cork,C=IE

12. In the Certificate Request window, select Save a certificate and accept the default location of c:\<ServerDNSName>_<CaName>.req, then click Next.

13. In the Certificate Database window, select the database and log locations (we kept the defaults), then click Next.

14. In the Web Server (IIS) window, click Next.

15. In the IIS Role Services window, accept the defaults, then click Next.

16. Verify the settings in the Confirmation window and click Install.

17. Once the installation is complete, click Close.

18. After installation, copy the request file to a location that will be accessible to the Root CA server.

19. On the Root CA server, submit a new request, as shown in Figure 14.

Figure 14. Submit a new Subordinate CA certificate request to the Root CA

20. After selecting the certificate request from the Subordinate CA, click OK to continue.

After the certificate request has been received, it is listed under Pending Requests.




21. Right-click the Subordinate CA certificate to issue the certificate, then select All Tasks, then select Issue, as shown in Figure 15.

Figure 15. Certification Authority console showing steps to issue a pending request.

22. The certificate is now listed under Issued Certificates which you need to export, as shown in Figure 16.

Figure 16. Export Issued Subordinate Certificate as Binary Data to file




42

23. Save the binary data to a file and click OK. Save the certificate with a CRT extension to a location that will be accessible to the Subordinate CA.

24. Verify that each of the CDP and AIA locations defined in the Root CA Properties extensions are correct.

None of the default CDP and AIA locations should be present in the issued certificate. You should only see the custom URLs, as shown in Figure 17.

Figure 17. CDP and AIA locations in a Subordinate CA certificate




Procedure: Install CA certificate on Subordinate CA When the certificate is issued, install it on the Subordinate CA and start the Certificate Authority service, as shown in Figure 18.

Figure 18. Install Subordinate CA certificate and start Certificate Authority service

The AIA and CRL for the Root CA are published to a folder that is web accessible, where the fully qualified domain name (FQDN, also known as the DNS name) is a CNAME record that points to the DNS A record for corkca01.cork.lab.esg.local. In the next procedure, we describe how to configure the Subordinate CA locations for AIA and CRLs so they use the same location.

c:\Windows\System32\CertSrv\CertEnroll is the default location that Microsoft CA Services uses on the local system to store AIA and CRLs. In this example, we created a separate local folder in c:\inetpub\PKI to hold all AIA and CRLs for both the Root and the Subordinate CA.




44

Procedure: Create virtual directory for AIAs and CRLs AIAs and CRLs issued by the Root, and CRLs issued by the Subordinate CA, are stored at the same URL for web-based access using IIS.

1. Connect to the desktop of the Subordinate CA server.

2. Create a separate local folder in c:\inetpub\ called PKI.

3. Copy the Subordinate CA certificate from c:\Windows\System32\CertSrv\CertEnroll to c:\inetpub\PKI folder.

4. Copy CRL and certificate files from the Root CA to the Subordinate CA folder c:\inetpub\PKI, as shown in Figure 19.

Note Once configured in the next steps, these URLs will be hardcoded in all issued certificates.

Figure 19. Root and Subordinate CA files in the c:\inetpub\PKI folder

5. Open the Internet Information Services (IIS) Manager and add a virtual directory alias named pki for c:\inetpub\PKI, as shown in Figure 20, and click OK.




Figure 20. Internet Information Services (IIS) Manager and PKI virtual directory configuration

Procedure: Change default behavior of IIS for files with special characters Once the virtual directory has been created, change the default behavior in IIS to enable files with special characters to be downloaded. This is disabled by default as a security precaution. Delta CRLs, smaller CRLs that contain a list of revoked certificates since the last full CRL was published, contain a plus (+) sign in the file name, so enable an exception for the PKI folder only.

Without changing this setting, delta CRLs are not permitted to be downloaded and the system returns an error message of “The requested filtering module is configured to deny a request that contains a double escape sequence.”

To enable the exception, open an administrative command prompt on the Subordinate CA server and enter the following commands:

C:\Windows\system32>cd \Windows\System32\inetsrv

C:\Windows\System32\inetsrv>appcmd.exe set config "Default Web

Site/pki" -section:system.webServer/security/requestFiltering

-allowDoubleEscaping:true

Applied configuration changes to section

"system.webServer/security/requestFiltering" for

"MACHINE/WEBROOT/APPHOST/Default Web Site/pki" at configuration

commit path "MACHINE/WEBROOT/APPHOST/Default Web Site/pki"




46

If you cannot start the CA service when you install the certificate, as shown in Figure 21, it may be because the system cannot locate the Root CA revocation lists.

Figure 21. Error when starting Subordinate CA service

This may happen if, as in this example, http://pki.lab.esg.local/pki is not online or the Root CA CRL cannot be found at this URL. This can be temporarily resolved by running the following command:

C:\>certutil –setreg ca\CRLFlags CRLF_REVCHECK_IGNORE_OFFLINE

Once the Root CA CRL is available via the CDP in the Subordinate CA certificate, to remove this setting, run the following command:

C:\>certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

Procedure: Configure Subordinate CA AIA and CDP locations To configure the Subordinate CA locations, follow these steps:


2. To open the Certification Authority MMC, click Start, select Administrative Tools, and then select Certification Authority. When the Certification Authority MMC is displayed, right-click on the CA (Cork ESG Lab Certificate Authority) and select Properties.

3. Verify that each of the default CRL Distribution Points (CDP) in the Subordinate CA Properties extensions for CRL match Figure 22.

Because this server is online, you can keep most of the default settings.




Figure 22. Subordinate CA Properties extensions for the default CDP locations

4. Add the local URL for the CRL Distribution Point (CDP). In this example, we used c:\inetpub\PKI\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl , as shown in Figure 23.




48

Figure 23. Subordinate CA system location for the CDP and location settings

5. Add the URL for the CRL Distribution Point (CDP). In this example, we used http://pki.lab.esg.local/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl, as shown in Figure 24.




Figure 24. Subordinate CA URL location for the CDP and URL location settings

6. For the AIA, verify that each of the default AIA locations in the Subordinate CA Properties extensions matches those in Figure 25.

This ensures that none of the default AIAs are listed in the certificates issued by this CA.




50

Figure 25. Subordinate CA properties extensions for the default AIA locations

7. Add the URL for the AIA location. In this example, we used: http://pki.lab.esg.local/pki/<ServerDNSName>_<CaName><CertificateName>.crt




8. Select Include in the AIA extension of issued certificates, as shown in Figure 26, and click OK.

Figure 26. Subordinate CA URL location for the AIA and URL location settings

9. When prompted, restart the CA services.

Installing Root and Subordinate CA certificates

In addition to the creation of certificates, the Root CA and Subordinate CA public keys must be installed into the certificate stores on all operating systems, and applications that have independent certificate stores. This includes Microsoft Windows certificate stores, Java, and any third-party browsers, such as Firefox, that use their own certificate stores. In this guide we have exclusively used Microsoft Internet Explorer as a browser, because it uses the Windows certificate store. Discussion of other browsers is beyond the scope of this PSG.

The CA public key certificates are needed to validate that when an end-entity certificate is presented, each certificate listed in the end-entity certification path, or chain, matches the installed CA public key certificates. For example, the following chaining, Root CA Certificate to Subordinate CA Certificate to vCenter Certificate, would be validated against the certificates.

In addition, the AIA reference contained in the Subordinate CA certificate and that of the certificate issued by the Subordinate CA, can be used to validate the trust status of the certificates.

Overview of Root and Subordinate CA certificates




52

Note Throughout this guide, we use the terms subordinate CA, intermediate CA, and issuing CA interchangeably due to the simple architecture of our PKI implementation. In our environment, our Subordinate CA is also the intermediate CA, and issuing CA in that it signs X.509 certificates for end-entities. However, depending on the PKI architecture adopted in your environment, its role could be that of an intermediate CA but not an issuing CA, which maybe subordinate to it. While beyond the scope of this guide, it is important to understand the distinction between the CA roles.

Microsoft Windows uses a system wide certificate repository for all users and individual certificate repositories for each user. The vSphere client also uses the Windows certificate repository. If you use the Microsoft Management Console (MMC) as a privileged user, the Certificates Snap-in enables you to modify the Computer account (system wide) or the My user account (currently signed in user) certificate stores. The process is the same for both certificate stores.

Procedure: Install Root CA certificate in Windows certificate store To install the Root CA certificate, follow these steps:

1. Connect to the desktop of the Microsoft Windows system where the Root CA certificate will be installed.

2. To open the MMC, click Start, then click Run. Type “mmc.exe” and click OK.

3. Once Console1 has opened, click File, then choose Add/Remove Snap-in.

4. Select Certificates, then click Add.

5. In the Certificates Snap-in window, select either My user account or Computer account, then click Next.

6. Under Certificates, expand the Trusted Root Certificate Authorities and right-click Certificates, then choose All Tasks, and then choose Import.

7. In the Certificate Import Wizard window, click Next.

8. Enter the path to the Root CA certificate, for example, c:\TEMP\RootCA.crt, then click Next.

9. Accept the default Place all certificates in the following store, then click Next.

10. Click Finish.

Procedure: Install Subordinate CA certificate in Windows certificate store To install the Subordinate CA certificate, follow these steps:

1. Connect to the desktop of the Microsoft Windows system where the Subordinate CA certificate will be installed.



4. Select Certificates, then click Add.

5. In the Certificates Snap-in window, select either My user account or Computer account, then click Next.

Installing Windows CA certificates




6. Under Certificates, expand the Intermediate Certificate Authorities and right-click Certificates, then choose All Tasks, and then choose Import.

7. In the Certificate Import Wizard window, click Next.

8. Enter the path to the Subordinate CA certificate, for example, c:\TEMP\SubordinateCA.crt, then click Next.

9. Accept the default Place all certificates in the following store, then click Next.

10. Click Finish.

Notes

This example used a manual process to populate the certificate store; however, this can also be accomplished using Active Directory (AD) group policy.

Active Directory integrated Subordinate CA automatically adds this certificate to a domain user’s certificate store. EMC recommends that this is also added to the system-wide certificate store.

For any Java-based application, the Root and Subordinate CA certificates need to be placed in the system Java certificate key store. The format required for the certificate is Base64, PEM format.

The following procedures are provided as examples and therefore may need to be modified to accommodate different operating systems, applications, or Java implementations.

Procedure: Install Root CA certificate in Java certificate key store To install the Root CA certificate (RootCA.crt), run the following command:

C:\> "C:\Program Files\Java\jre6\bin\keytool.exe" -import -

trustcacerts -alias "ESG Lab Root Certificate Authority" -file

"C:\TEMP\RootCA.crt" -keystore "C:\Program

Files\Java\jre6\lib\security\cacerts" -storepass changeit -

noprompt

Procedure: Install Subordinate CA certificate in Java certificate key store To install the Subordinate CA certificate (SubordinateCA.crt), run the following command:

C:\> "C:\Program Files\Java\jre6\bin\keytool.exe" -import -

trustcacerts -alias "Cork ESG Lab Certificate Authority" -file

"C:\TEMP\SubordinateCA.crt" -keystore "C:\Program

Files\Java\jre6\lib\security\cacerts" -storepass changeit –

noprompt

Note Quotes are necessary regardless of the existence of spaces in the variable, such as “c:\TEMP\RootCA.crt”.

Procedure: Remove certificate from Java certificate key store To remove a certificate from the Java certificate key store, this is done by the alias used during installation, in this case "ESG Lab Root Certificate Authority" or “Cork ESG Lab Certificate Authority”. To remove the certificate run the following command:

Installing Java CA certificates




54

C:\>"C:\Program Files\Java\jre6\bin\keytool.exe" -delete -alias

"ESG Lab Root Certificate Authority" -keystore "C:\Program


noprompt

C:\>"C:\Program Files\Java\jre6\bin\keytool.exe" -delete -alias

"ESG Lab Root Certificate Authority" -keystore "C:\Program


noprompt

For the User Java certificate key store, you can use the Java control panel to import the Root and Subordinate CA certificates under the Security tab.

In production environments, it is common for systems to be managed and accessed using the system IP address, hostname or FQDN. However, when PKI is introduced, this behavior can result in certificate validation errors that can cause integration to fail.

It is possible to issue a certificate that contains one or more SAN attributes (subjectAltName) in addition to the Subject Name (also known as the Common Name). However, this is not enabled by default in Microsoft Active Directory Certificate Services. To enable SAN, run the following from the command prompt on the CA:

certutil –setreg policy\SubjectAltName enabled

certutil –setreg policy\SubjectAltName2 enabled

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

net stop certsvc

net start certsvc

The SAN attribute can be specified in the Additional Attributes window of the Certificate Web Services certificate request page when submitting a certificate request. Throughout this guide, when submitting each certificate request via the Certificate Web Services portal we have specified SAN attributes in the following format:

SAN:dns=hostname.domain.local&dns=hostname&dns=xxx.xxx.xxx.xxx

The SAN attribute can also be included while creating the certificate request using OpenSSL with a custom configuration file.

Note You must consider the security implications of enabling this extension. The security best practices for enabling SANs in certificates can be reviewed in the Microsoft Technet article How to Request a Certificate With a Custom Subject Alternative Name.

Subject Alternative Name attributes in certificates

http://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx

http://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx




Submitting certificate requests

Active Directory Certificate Services provides a web portal through which you can submit a certificate request to the issuing CA and retrieve the signed certificate.

Procedure: Submitting a certificate request via web portal Once the certificate request has been generated, you can submit it to the Active Directory Certificate Services web portal to be signed by the CA, and then download the issued certificate. To do so, follow these steps:

1. Open a browser and log in to the Microsoft Active Directory Certificate Services web portal as a user with administrative privileges.

2. In the Welcome window, click Request a certificate.

3. In the Request a Certificate window, click Advanced Certificate Request.

4. In the Advanced Certificate Request window, click either Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file or Submit a renewal request by using a base-64-encoded PKCS #7 file.

5. Using a text editor such as Windows Notepad, open the certificate request file, for example mycsr.csr, then select and copy all the content.

Note The content may appear to be on one or more lines, as shown in Figure 27.

Figure 27. Select and copy all the content of mycsr.csr

6. In the Submit a Certificate Request or Renewal Request window, paste the contents into the Base-64-encoded certificate request (CMC or PKCS #10 or PKCS #7) field,

7. Select vSphereSSL as the Certificate Template, as shown in Figure 28, enter the SAN attribute parameters if required, then click Submit.

End-entity certificates and certificate chain




56

Figure 28. vSphere platform SSL certificate request with SAN values

8. In the Certificate Issued window, select Base 64 encoded, then click Download certificate.

9. Save the certificate as rui.crt in the c:\TEMP\ folder, in the same location as rui.key.

Given the number of vSphere components involved in a production environment we can leverage OpenSSL and the Active Directory Certificate Services API to streamline the process. To do this, create a custom OpenSSL configuration file for each vSphere component. For vCenter 5.1 components, export your Root and Issuing CA certificates in Base 64 format.

Procedure: Submitting a certificate request using via CLI A more useful approach when creating many certificate requests is to use the Microsoft certificate request command line certreq.exe tool. This can be included in a script to automate mass generation or certificates for an environment. The certreq.exe tool uses the following syntax:

certreq.exe –config “MY_CA_NAME\MY_CA_LONG_NAME” -submit -attrib

"CertificateTemplate:MyTemplate" certrequest.csr signed_cert.crt

In this example, we submitted a previously prepared certificate request server1.csr to our issuing CA, CORKCA01, and used the Web Server certificate template to generate the signed certificate:

certreq.exe –config “CORKCA01\Cork ESG Lab CA” -submit -attrib

"CertificateTemplate:WebServer" server1.csr server1_signed.crt

Note The certificate template value must reference the Template name and not the Template display name attribute. In this example, the default Web Server




certificate template name is WebServer while its template display name is Web Server.

To specify a SAN attribute, append \nSAN:DNS=VALUE at the end of the certificate template value and before the closing quotation mark as follows:

certreq.exe –config “CORKCA01\Cork ESG Lab CA” -submit -attrib

"CertificateTemplate:WebServer\nSAN:DNS=server1.cork.lab.local&DNS=

server1&DNS=192.168.1.1" server1.csr server1_signed.crt

Obtaining the certificate chain

Throughout this guide the root and issuing CA certificates are required to validate the certification path, or certificate chain, of the end-entity certificates or to provide a full certificate chain when combined with an end-entity certificate.

Procedure: Export the certificate chain To export the certificate chain as individual certificates, follow these steps:

1. Open the Active Directory Certificate Web services URL in Internet Explorer.

2. Click on the padlock icon next to the URL and click View certificates, as shown in Figure 29.

Figure 29. How to view PKI certificate

3. Select the root CA, which in this example, shown in Figure 30, is ESG Lab Root CA and click View Certificate.

Figure 30. Certification Path tab of LDAPS certificate properties depicting Root CA, Issuing CA, and LDAPS certificate for corkdc01 Domain Controller.

4. A further certificate properties window will appear. Select the Details tab and click Copy to File.

5. The Certificate Export Wizard will start, click Next, and select Base-64 encoded X.509, and click Next.




58

6. Browse to a location and provide a filename to save the certificate, click Next, and Finish.

7. Click OK on the root CA certificate properties window to return to the certificate properties window.

8. This time select the issuing or intermediate CA certificate, shown as Cork ESG Lab CA in this example in Figure 30, click View Certificate and repeat steps 4 to 7. When completed click OK to close the certificate properties window.

You should now have two files which comprise of the Root CA certificate and the Issuing (intermediate) CA certificate. For the purposes of this guide we have named them Root_CA_64.cer and Issuing_CA_64.cer.

VMware vCloud Suite 5.1 certificates

VMware’s vCloud Suite integrates products from a number of disciplines such as management, extensibility, cloud infrastructure, virtualization, and physical infrastructure, as shown in Figure 31.

Figure 31. Depiction of VMware vCloud Suite products

In this guide, we configured vSphere, vCloud Director, and vCloud Networking and Security to use trusted certificates obtained through our PKI implementation.

To generate certificates for the vSphere platform (ESXi, vCenter Single Sign-On, vCenter Inventory Service, vCenter Server, vCenter Orchestrator, Web Client, Log Browser, and VMware vSphere Update Manager), install OpenSSL to generate private keys and certificate requests. A PEM formatted file containing the full certificate chain must also be created for each service.

In addition to the creation of certificates and chain files, the Root CA and Subordinate CA public keys must be installed into the certificate or key store on all systems. For example, Windows uses a system-wide certificate repository for all users and individual certificate repositories for each user. Using the Microsoft Management

Overview of vCloud Suite

vSphere 5.1 certificates




Console as a privileged user, you can add the Snap-in certificates for the system-wide Computer account or the currently signed in My user account.

A customized OpenSSL configuration file can be used for the creation of vSphere certificates. The delta of changes from the default OpenSSL client included in the Win64OpenSSL_Light-1_0_1c.exe software is listed Table 4. We installed OpenSSL on to a Windows 7 x64 platform in the c:\OpenSSL folder.

Table 4. Required OpenSSL.cfg file changes

Line number

Old value New value

42 dir = ./demoCA dir = .

55 private_key = $dir/private/cakey.pem

private_key = $dir/private/myroot.key

107 default_keyfile = privkey.pem default_keyfile = rui.key

129 countryName_default = AU countryName_default = US

134 stateOrProvinceName_default = Some-State

stateOrProvinceName_default = Massachusetts

140 0.organizationName_default = Internet Widgits Pty Ltd

organizationName_default = EMC Corporation

147 #organizationalUnitName_default = organizationalUnitName_default = ESG

331 dir = ./demoCA dir = .

For OpenSSL Light binaries:

OpenSSL Light can be installed on the vCenter host without additional libraries being installed, because the requisite libraries, 2008 C++, are already installed.

If you use the OpenSSL Light 64-bit installer, ensure that when prompted to copy the library files, these are put in the OpenSSL “.\bin” folder instead of the Windows System folder.

However, for the purposes of generating key material and creating PFX files, this process can be followed on any system on which the OpenSSL binaries are installed.

The certificate requirements of vSphere 5.1 differ significantly from vSphere 5.0 because of the introduction of vCenter SSO as a mandatory component to support vSphere and vCloud suite authentication and the security token exchange mechanism. vCenter SSO provides an authentication interface called Security Token Service (STS) that allows administrators or applications to authenticate with a defined security domain such as Active Directory or OpenLDAP. If successful, the credentials are exchanged for a token which is then used to interact with the various vSphere platform applications. During the interaction between components, the

vCenter Single Sign-On




60

client verifies the authenticity of the certificate presented during the SSL handshake phase, before encryption, which protects against “man-in-the-middle” attacks.

Each vSphere application that is installed registers with vCenter SSO using its SSL certificate and so requires a unique certificate for each vSphere application, as detailed in Table 5.

Table 5. List of certificates and key stores types required for vCloud Suite 5.1 deployment

Component Keystore Private key Full certificate chain

Single Sign-On N/A Y Y

Inventory Service N/A Y Y

vCenter Server N/A Y Y

vCenter Log Browser N/A Y Y

vCenter Orchestrator N/A Y Y

vSphere Web Client N/A Y Y

vSphere Update Manager N/A Y Y

vSphere ESXi N/A Y Y

vCloud Director JCEKS Y Y

vCloud Networking and Security N/A N/A Y

In this context, what distinguishes a vSphere component certificate as being unique is the Organization Unit (OU) value. This is important as vCenter SSO looks exclusively to this attribute to determine if the vSphere service is already registered or not. The OU value is stored in the SSO database as the primary key for each certificate, rather than the hash, thumbprint, or any other attribute. Even though you might generate a separate certificate for each vSphere component so that the thumbprints are unique, the installation will not succeed unless you meet the OU value condition.

To address some of these difficulties, VMware has released the vCenter Certificate Automation Tool 1.0. While it cannot generate certificate requests, or have them signed, or renewed by a trusted CA, it can update or replace existing certificates and establish trust between the vSphere components. It does not handle the replacement of ESXi certificates.

Some characteristics of the vSphere certificates differ slightly from the normal web-based SSL certificate provided by the Web Server certificate template. Create a new certificate template to satisfy VMware’s certificate requirements. The Data Encipherment key usage attribute must be included in the certificate template. In addition, the Client Authentication application policy must be included for use with ESXi 5.1 and for backward compatibility with vCenter versions 5.0 and earlier.

It is also possible for certificates to contain multiple SAN values, such as FQDN, hostname, and IP address. These additional attributes can be provided along with the

vSphere certificate template




certificate request when submitted through the Microsoft Active Directory Certificate Services web portal or included in the certificate request when the CLI is used.

Procedure: Create a certificate template for the vSphere platform To create a certificate for use with vSphere, first create a template that will be used by the certificate authority with the necessary certificate attributes.


2. Click Start, then choose Administrative Tools, then choose Certification Authority,

3. Expand the Subordinate CA (in this example, Cork ESG Lab Certificate Authority).

4. Right-click on Certificate Templates and choose Manage, as shown in Figure 32.

Figure 32. Open the Certificate Templates console from the CA console Snap-in

Note Do not close the Certification Authority. You will use this to publish the newly created vSphereSSL template to make it available from the web interface.

Once the Certificate Templates console is open, use the following steps to duplicate the Web Server template and customize this copy for use with vSphere certificate requests.

1. Right-click the Web Server template and select Duplicate Template.

2. Keep the default Windows Server 2003 for minimum supported CAs and click OK.

3. On the General tab, enter “vSphereSSL” in the Template display name and change the Validity period to “3 years”.

Note Do not click OK.




62

4. Select Request Handling, then select Allow private key to be exported.

5. As shown in Figure 33, select Extensions, select Application Policies, then click Edit.

a. In Edit Application Policies Extension, click Add.

b. In Add Application Policy, select Client Authentication, then click OK.

c. In the Edit Application Policies Extension window, click OK.

6. As shown in Figure 33, in Extensions, select Key Usage and click Edit.

Keep the defaults, select Signature is proof of origin (nonrepudiation) and Allow encryption of user data and click OK.

Figure 33. ESXi template key usage extensions

7. In Properties of New Template, click OK.

8. After the vSphereSSL template has been created, close the Certificate Templates window.

9. In the Certification Authority window, right-click Certificate Templates, then select New, then select Certificate Template to Issue, as shown in Figure 34.




Figure 34. Issue a certificate template in the Certification Authority MMC

10. Scroll down and select the newly created vSphereSSL template, then click OK. vSphereSSL is listed under Certificate Templates.

Now that the template is published, it is visible to Domain Administrators and Enterprise Administrators through the Microsoft Active Directory Certificate Services web portal when you submit certificate requests.

Use the following OpenSSL command to generate private keys (rui.key) and certificate requests (mycsr.csr).

C:\TEMP> C:\OpenSSL\bin\openssl.exe req -config

C:\OpenSSL\bin\openssl.cfg -newkey rsa:2048 -keyout

C:\TEMP\rui.key -nodes -out C:\TEMP\mycsr.csr

You are prompted to include certain values in the certificate request. The following text is an example of the information used for one of the ESXi hosts used in this solution.

Loading 'window' into random state - done

Generating a 2048 bit RSA private key

..............+++

......................+++

writing new private key to 'C:\TEMP\rui.key'

-----

You are about to be asked to enter information that will be

incorporated into your certificate request.

What you are about to enter is what is called a

Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

Requesting vSphere certificates




64

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [US]:IE

State or Province Name (full name) [Massachusetts]:Co. Cork

Locality Name (eg, city) [Hopkinton]:Cork

Organization Name (eg, company) [EMC Corporation]:

Organizational Unit Name (eg, section) [ESG]:

Common Name (e.g. server FQDN or YOUR name) []:lab-mgmt-

esx01.cork.lab.esg.local

Email Address []:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Procedure: Create CLI certificate request with embedded SAN attributes 1. Create the Base 64 formatted CA certificate chain by exporting the CA

certificates in Base 64 format, as detailed in Procedure: Export the certificate chain, and running the following command with the binary (/B) switch:

COPY /B C:\TEMP\Issuing_CA_64.cer+C:\TEMP\Root_CA_64.cer

C:\TEMP\CA_Chain_64.cer

The order of the concatenation is important as the vCenter Certificate Automation Tool requires the certificates to be in a particular order in the certificate chain file, starting with the end-entity certificate and finishing with the root CA certificate.

2. To do this, create an OpenSSL configuration file for each vSphere component containing the parameters in the following example:

[ req ]

default_bits = 2048

default_keyfile = rui.key

distinguished_name = req_distinguished_name

encrypt_key = no

prompt = no

string_mask = nombstr

req_extensions = v3_req

[ v3_req ]

basicConstraints = CA:FALSE

keyUsage = digitalSignature, keyEncipherment,

dataEncipherment

extendedKeyUsage = serverAuth,

subjectAltName = DNS:vCenterService1.cork.lab.esg.local,

DNS:vCenterService1, DNS:vCenterServiceIP

[ req_distinguished_name ]

countryName = IE

stateOrProvinceName = County Cork

localityName = Ovens

0.organizationName = EMC Corporation

organizationalUnitName = vCenterService1

commonName = vCenterService1.cork.lab.esg.local




Note For vCenter 5.1 components the organizationalUnitName value must be unique. When using the example provided the vCenterService1 and vCenterServiceIP parameters must be replaced by your production information for each service and configuration file created.

3. Generate a key:

C:\OpenSSL\bin\openssl.exe req -newkey rsa:2048 -keyout

C:\TEMP\vCenterService1\rui.key

4. Use the previously created OpenSSL configuration file and private key to generate the certificate request:

C:\OpenSSL\bin\openssl.exe req -out

C:\TEMP\vCenterService1\rui.csr -key

C:\TEMP\vCenterService1\rui.key -new -config

C:\TEMP\vCenterService1\vCenterService1.cfg

5. At this point, you have a certificate request. Submit it to the issuing CA using the vSphereSSL certificate template you created earlier:

certreq -submit -config “CORKCA01\Cork ESG Lab Certificate

Authority" -attrib "CertificateTemplate:vSphereSSL"

C:\TEMP\vCenterService1\rui.csr

C:\TEMP\vCenterService1\rui.crt

6. Concatenate the rui.crt and the CA chain certificates to produce a full chain containing all three:

COPY /B

C:\TEMP\vCenterService1\rui.crt+C:\TEMP\CA_Chain_64.cer

C:\TEMP\vCenterService1\Full_Chain.pem

Note This step is not required for ESXi host certificates.

The order of the concatenation is important as the vCenter Certificate Automation Tool requires the certificates to be in a particular order in the certificate chain file, starting with the end-entity certificate and finishing with the root CA certificate.

7. Repeat the procedure for each vSphere component, noting that step 6 is not required for ESXi certificates.

Before beginning a certificate installation, consider the following:

It is best to replace the certificates once ESXi is installed on the host; however, this is not mandatory. Doing so can eliminate unverified HASH errors when adding the host to vCenter.

If the ESXi host has been added to a vCenter Server and is in lockdown mode, you have to disable this setting. SSH must be enabled in order to copy the certificate and key to the host through Secure File Transfer Protocol (SFTP) or SCP (Secure Copy Protocol). You can do this through the vSphere Client or through the ESXi console.

Note You must disable SSH when it is no longer needed.

Installing ESXi host certificates




66

If the host has been added to vCenter:

Migrate all virtual machines and templates to another host in the cluster

Place the ESXi host in maintenance mode

Remove the ESXi host from vCenter

Note If you do not remove the host from vCenter when replacing the certificate, you may see errors. For example, if you attempt to open the console of a running virtual machine, you could receive the error “Unable to connect to the MKS”.

Procedure: Install certificate on ESXi host Once the host is in maintenance mode and SSH has been enabled, you replace the private key and certificate.

1. Open an SFTP or SCP capable client, such as FileZilla, and connect to the ESXi host.

2. Navigate to the /etc/vmware/ssl folder, as shown in Figure 35.

Figure 35. Upload an ESXi host private key and certificate

3. Make a backup of the existing private key and certificate that are located in folder /etc/vmware/ssl on the ESXi host to another location, for example, c:\TEMP\esxHost1\OLD.

4. Copy the previously created rui.key and rui.crt files from c:\TEMP\ esxHost1\ to /etc/vmware/ssl/.




5. Once these have been replaced, reboot the ESXi host.

Note In the lab, we found that it is more effective to reboot the ESXi host after replacing the keys rather than restarting the DCUI as outlined in the VMware documentation.

6. Once the ESXi host has been rebooted, add the ESXi host to your vCenter Cluster and exit maintenance mode.

This process can also be used if you want to rekey (change the private key) or renew the certificate.

To streamline the complicated installation process, VMware has released the vCenter Certificate Automation Tool. With it, you can take your previously created private keys and chains and replace the self-signed certificates for the following components:

vCenter SSO

Inventory Service

vCenter Server

vCenter Orchestrator

vSphere Web Client

Log browser

vSphere Update Manager (if installed)

For each service listed above the private key file must contain a single PEM (Base64) encoded RSA private key. The certificate chain files must contain a sequence of PEM (Base64) encoded X.509 certificates ordered from the entity certificate to the issuing CA certificate and, finally, the root CA certificates.

Procedure: Using the vCenter Certificate Automation Tool Once you have downloaded and extracted the vCenter Certificate Automation Tool on the vCenter system to be updated, perform the following steps:

1. Open the ssl-environmen.bat script in a text editor.

2. For each service, locate the relevant lines in the script and provide the path and filename for the private key and certificate chain files.

vCenter SSO:

rem # sso_cert_chain

set sso_cert_chain=C:\TEMP\SSO\Full_chain_SSO.pem

rem # sso_private_key

set sso_private_key=C:\TEMP\SSO\rui.key

Inventory Service:

rem # is_cert_chain

set is_cert_chain=C:\TEMP\Inventory\Full_chain_Inventory.pem

rem # is_private_key_new

set is_private_key_new=C:\TEMP\Inventory\rui.key

Installing vCenter certificates




68

vCenter Server:

rem # vc_cert_chain

set vc_cert_chain=C:\TEMP\vCenter\Full_chain_vCenter.pem

rem # vc_private_key

set vc_private_key=C:\TEMP\vCenter\rui.key

vSphere Web Client:

rem # ngc_cert_chain

set

ngc_cert_chain=C:\TEMP\WebClient\Full_chain_WebClient.pem

rem # ngc_private_key

set ngc_private_key=C:\TEMP\WebClient\rui.key

Log browser:

rem # logbrowser_cert_chain

set

logbrowser_cert_chain=C:\TEMP\LogBrowser\Full_chain_LogBrows

er.pem

rem # logbrowser_private_key

set logbrowser_private_key=C:\TEMP\LogBrowser\rui.key

vCenter Orchestrator:

rem # vco_cert_chain

set vco_cert_chain=C:\TEMP\vCO\Full_chain_Orchestrator.pem

rem # vco_private_key

set vco_private_key=C:\TEMP\vCO\rui.key

vSphere Update Manager:

rem # vum_cert_chain

set vum_cert_chain=C:\TEMP\VUM\Full_chain_VUM.pem

rem # vum_private_key

set vum_private_key=C:\TEMP\VUM\rui.key

3. You can also set both the SSO admin user and the vCenter username to be used:

rem Common parameters

set sso_admin_user=admin@System-Domain

set vc_username=administrator

4. Save the ssl-environment.bat script and run it from an elevated command prompt on the vCenter system to load the variables you have just defined.

5. Next, run the ssl-updater.bat script. This presents you with a menu of options to choose from.

Main menu

Enter the action you want to run

1. Plan your steps to update SSL certificates (Update

Steps Planner)

2. Update Single Sign-On

3. Update Inventory Service

4. Update vCenter Server

5. Update vCenter Orchestrator (vCO)




6. Update vSphere Web Client and Log Browser

7. Update vSphere Update Manager (VUM)

8. End the update process and exit

6. From the menu, select option 1 to create a step-by-step plan to install the certificates. This presents a further menu of options:

Choose the services you want to update:

1. Single Sign-On

2. Inventory Service

3. vCenter Server

4. vCenter Orchestrator

5. vSphere Web Client

6. Log Browser

7. vSphere Update Manager

8. All services(listed above)

9. Return to the main menu

Example:

To choose the certificate update of Inventory Service,

vCenter Server and vSphere Web Client you would enter: 2,3,5

7. Depending on your deployment architecture, select the services installed on the vCenter system that must be updated.

Note If the service was configured to use the vCenter Server hostname or FQDN during installation, this tool cannot be used to update the vSphere Update Manager SSL certificate. The IP address must be specified at the point of installation according to VMware’s installation recommendations.

8. The tool lists the steps that must be taken to satisfy your selection. Copy this list to record it and use it as a guide to complete the steps in the correct sequence. Enter 9 to return to the tool’s main menu and begin the certificate update process.

Note that logs are stored in the logs folder in the SSLAutomationTool1.0 directory and should be used to troubleshoot if necessary.

To complete the rollout of trusted SSL certificates, you must update the vCenter SSO STS service certificate chain. To replace this, use the following procedure.

Procedure: Installing vCenter Single Sign-On STS certificate 1. Open the vSphere Web Client by browsing to http://vcenter.fqdn/vsphere-

client.

2. Log on as an administrative SSO user such as admin@System-Domain.

3. Click Administration in the left-hand navigation pane.

4. Under Sign-On and Discovery, click Configuration and then select the STS Certificate tab.

5. Click Edit to browse to location of the SSO JKS keystore, normally stored in C:\Program Files\VMware\Infrastructure\SSOServer\security , and select the server-identity.jks keystore.

http://vcenter.fqdn/vsphere-client





70

6. Enter changeit when prompted for a password and select the displayed chain. Click OK and enter the password again.

7. Restart the following services:

vSphere Web Client

vCenter Server

Inventory Service

Log Browser

VMware vCloud Networking and Security

When deployed, vShield Manager is configured with a self-signed certificate. However, it is possible to replace the self-signed certificate with a signed certificate from a trusted CA.

Procedure: Create a certificate request in vShield Manager To create a certificate request in vShield Manager, follow these steps, as shown in the example in Figure 36:

1. Log into the vShield Manager web interface with administrative credentials.

2. Navigate to Settings & Reports, then select Configuration, then select SSL Certificate.

3. Expand Generate Certificate Signing Request, then populate the certificate request fields with the appropriate information.

4. Select RSA Key Algorithm.

5. Select 2048 from Key Size list box.

6. Click Generate.

Figure 36. Example certificate request configuration

Creating vShield Manager SSL certificates




7. To retrieve the certificate request, click Download generated certificate.

8. Submit the certificate request to the issuing CA.

Procedure: Import the CA-signed certificate in vShield Manager To import the CA-signed certificate, follow these steps:

1. Export the certificate chain (both root and issuing CA certificates) in Base64 format.

2. From the issuing CA, export the vShield Manager CA-signed certificate in Base64 format to a local folder, for example, c:\TEMP\.

3. In vShield Manager, expand Import Signed Certificate, as shown in Figure 37.

4. Browse to the location of the root CA certificate.

5. Select Root CA from the Certificate Type list box.

6. Click Apply.

Figure 37. Importing the Root CA certificate

7. Browse to the location of the issuing CA certificate, select Certificate Type: Intermediate CA, as shown in Figure 38, and click Apply.

Figure 38. Importing the intermediate (issuing) CA certificate

8. Browse to the location of the vShield Manager certificate, select Certificate Type: CA-signed X.509 Cert, as shown in Figure 39, and click Apply.

Figure 39. Importing the vShield Manager CA-signed SSL certificate




72

9. After all the certificates have been imported, under Apply Signed Certificate, click Apply Certificate to restart vShield Manager, as shown in Figure 40. This applies the new SSL certificate.

Figure 40. Applying the new SSL certificate

Note Every time you generate a new certificate request, you must import the root and intermediate certificates.

VMware vCloud Director SSL certificates

Each vCloud Director cell in the cluster requires two certificates to encrypt communications between the client and cells. These certificates, whether self-signed or signed by a trusted CA, are required prior to the installation of vCloud Director.

However, it is possible to replace self-signed certificates with trusted certificates after installation.

vCloud Director certificates are stored in the JCEKS formatted keystore file that is specified when you run the keytool utility or is saved to the working directory (in this example, located by default in /opt/vmware/vcloud-director/jre/bin).

The keystore file and its path must be readable by the vCloud user account or the configuration script will fail.

Procedure: Create certificate requests for vCloud Director To create the certificate requests, ensure you use the keytool utility located in /opt/vmware/vcloud-director/jre/bin. Failure to do so may result in another keytool on the system being used and producing errors.

1. To create a private key in the keystore for the HTTP service, run:

#cd /opt/vmware/vcloud-director/jre/bin

#keytool -genkey -keystore certificates.ks -storetype JCEKS

-storepass KS_PASSWORD -keyalg RSA -alias http

What is your first and last name?

[Unknown]: caas-vcd1.cork.lab.esg.local

What is the name of your organizational unit?

[Unknown]: EMC Solutions Group

What is the name of your organization?

[Unknown]: EMC Corporation

What is the name of your City or Locality?

[Unknown]: Ovens

What is the name of your State or Province?

[Unknown]: County Cork

What is the two-letter country code for this unit?

[Unknown]: IE

Is CN=caas-vcd1.cork.lab.esg.local, OU=EMC Solutions Group,

O=EMC Corporation, L=Ovens, ST=County Cork, C=IE correct?

Creating SSL certificates

Location of certificates




[no]: yes

Enter key password for <http>

(RETURN if same as keystore password):

2. To create a certificate request in the keystore for the HTTP service, run:

#keytool -keystore certificates.ks -storetype JCEKS -

storepass KS_PASSWORD -certreq -alias http -file caas-vcd1-

http.csr

3. To create a private key in the keystore for the consoleproxy service, run:

#keytool -genkey -keystore certificates.ks -storetype JCEKS

-storepass KS_PASSWORD -keyalg RSA -alias consoleproxy


[Unknown]: caas-vcd1p.cork.lab.esg.local


[Unknown]: EMC Solutions Group




[Unknown]: Ovens




[Unknown]: IE

Is CN=caas-vcd1p.cork.lab.esg.local, OU=EMC Solutions Group,

O=EMC Corporation, L=Ovens, ST=County Cork, C=IE correct?

[no]: yes

Enter key password for <consoleproxy>


4. To create a certificate request in the keystore for the HTTP service, run:

#keytool -keystore certificates.ks -storetype JCEKS -

storepass KS_PASSWORD -certreq -alias consoleproxy -file

caas-vcd1-consoleproxy.csr

5. Submit the certificate requests to your issuing CA and export the signed certificates in Base64 format.

Procedure: Install the certificate chain in the vCloud Director keystore Once you have obtained the signed certificates, you also need to import the certificate chain.

1. Import the root and issuing CA certificates by running the following command:

#keytool -storetype JCEKS -storepass KS_PASSWORD -keystore

certificates.ks -import -alias root -file Root_CA_64.cer

Owner: CN=ESG Lab Root Certificate Authority, OU=EMC

Solutions Group, O=EMC Corporation

Issuer: CN=ESG Lab Root Certificate Authority, OU=EMC


Serial number: bae669051522cb04160dcaa225cb969

Valid from: Mon Jul 23 16:02:28 IST 2012 until: Thu Jul 23

16:12:27 IST 2037




74

Certificate fingerprints:

MD5: 1A:F7:A8:17:90:70:23:E6:34:B2:C2:FE:36:B8:AC:13

SHA1:

83:0C:CE:A5:EB:17:81:44:BF:A6:74:EA:58:AA:ED:85:8C:6F:C6:A8

Signature algorithm name: SHA256withRSA

Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true

BasicConstraints:[

CA:true

PathLen:2147483647

]

#2: ObjectId: 2.5.29.15 Criticality=false

KeyUsage [

DigitalSignature

Key_CertSign

Crl_Sign

]


SubjectKeyIdentifier [

KeyIdentifier [

0000: 8E 2A 7E 03 AA BC 35 91 8B 9F 02 C7 8B 68 58 71

.*....5......hXq

0010: 91 44 90 70 .D.p

]

]

#4: ObjectId: 1.3.6.1.4.1.311.21.1 Criticality=false

Trust this certificate? [no]: yes

Certificate was added to keystore

2. To import the issuing CA certificate, run:


certificates.ks -import -alias intermediate -file

Issuing_CA_64.cer


3. To verify the import by listing the keystore contents and checking the resulting output, run:


certificates.ks –list

Keystore type: JCEKS

Keystore provider: SunJCE

Your keystore contains 4 entries

root, Aug 8, 2012, trustedCertEntry,

Certificate fingerprint (MD5):

1A:F7:A8:17:90:70:23:E6:34:B2:C2:FE:36:B8:AC:13

intermediate, Aug 8, 2012, trustedCertEntry,





4F:8E:47:53:5D:80:2D:15:E2:C1:BD:22:FC:FC:A7:E5

The root and intermediate certificates’ MD5 thumbprint are displayed in the keystore; an excerpt is shown in the example output above.

Procedure: Install SSL certificates in vCloud Director 1. To import the signed certificates, use the following commands:


certificates.ks -import -alias http -file caas-vcd1-

http.b64.cer


certificates.ks -import -alias consoleproxy -file caas-vcd1-

consoleproxy.b64.cer

2. To verify the import, run:


certificates.ks –list



Your keystore contains 4 entries:



1A:F7:A8:17:90:70:23:E6:34:B2:C2:FE:36:B8:AC:13



4F:8E:47:53:5D:80:2D:15:E2:C1:BD:22:FC:FC:A7:E5

http, Aug 8, 2012, PrivateKeyEntry,


01:35:8A:FD:17:92:5D:D7:A6:D3:14:91:6F:B7:D2:44

consoleproxy, Aug 8, 2012, PrivateKeyEntry,


8B:A3:6A:5A:1E:BD:0F:1C:9A:56:09:36:F3:28:4C:B5

Procedure: Run the vCloud Director initial configuration script Ensure that the user account under which the configuration script is run can read the keystore and its path:

1. To configure vCloud Director to use the signed certificates, run the vCloud Director configuration script.

# /opt/vmware/vcloud-director/bin/configure

You are prompted to enter a number of parameters that are necessary to configure and start the vCloud Director service.

Welcome to the vCloud Director configuration utility.

Please enter the path to the Java keystore containing your

SSL certificates and

private keys: /opt/keystore/vcd1_certs.ks

Please enter the password for the keystore:




76

Connecting to the database:

jdbc:jtds:sqlserver://172.30.206.18:1433/vcloud;socketTimeou

t=90;instance=

Database configuration complete.

vCloud Director configuration is now complete.

Once the vCloud Director server has been started you will be

able to access the first-time setup wizard at this URL:

https://caas-vcd1.cork.lab.esg.local

Would you like to start the vCloud Director service now? If

you choose not to start it now, you can manually start it at

any time using this command:

service vmware-vcd start

Start it now? [y/n] y

Starting vmware-vcd-watchdog: [ OK ]

Starting vmware-vcd-cell [ OK ]

The vCD service will be started automatically on boot. To

disable this, use the following command: chkconfig --del

vmware-vcd

2. Run the configuration script on each cell in the vCloud Director cluster using the cell-specific keystore in each case.

Procedure: Replacing vCloud Director SSL certificates post-installation Ensure that the user account under which the cell management tool is run can read the keystore and its path:

1. To configure vCloud Director to use the signed certificates, run the vCloud Director configuration script.

# /opt/vmware/vcloud-director/bin/configure

# ./cell-management-tool certificates –s

/opt/keystore/vcd1_certs.ks –w KS_PASSWORD

Certificate replaced by user specified keystore at

/opt/keystore/vcd1_certs.ks.

You will need to restart the cell for changes to take

effect.

2. Restart the cell to enable it to use the signed SSL certificates.

# ./cell-management-tool –u administrator –p ADMIN_PASS cell

--quiesce true

# ./cell-management-tool –u administrator –p ADMIN_PASS cell

--shutdown

# service vmware-vcd start

3. Repeat for each cell in the vCloud Director cluster using the cell-specific keystore in each case.




To configure VMware vCloud Director to verify vCenter SSO, vCenter Server, and vShield Manager certificates, create a Java keystore in JCEKS format that contains the following:

PEM-formatted trusted certificate of the issuing CA used to sign vCenter SSO

Root CA certificate that issued the subordinate (issuing) CA certificate

The SSL certificates for the individual servers are not in this store—only the root and issuing CA certificates that are used to sign them.

Procedure: Create a JCEKS keystore To create a JCEKS keystore, follow these steps:

1. On a system that has Java installed, to create a new JCEKS keystore in which to store the certificate chain of the vCenter servers and vShield Manager appliances, run the following command:

#keytool -genkey -keystore vcd_verify_keystore.ks -storetype

JCEKS -storepass KS_PASSWORD -keyalg RSA –alias tempkey

2. At each prompt, to accept the default Unknown, press Enter until the final confirmation prompt, then click Yes.

3. To remove the tempkey alias and leave the keystore empty, run the following command:

#keytool -keystore vcd_verify_keystore.ks -storetype JCEKS -

storepass KS_PASSWORD -keyalg RSA –delete –alias tempkey

4. To import the root CA certificate, run the following commands:


vcd_verify_keystore.ks -import -alias root -file

Root_CA_64.cer

Owner: CN=ESG Lab Root Certificate Authority, OU=EMC


Issuer: CN=ESG Lab Root Certificate Authority, OU=EMC


Serial number: bae669051522cb04160dcaa225cb969

Valid from: Mon Jul 23 16:02:28 IST 2012 until: Thu Jul 23

16:12:27 IST 2037

Certificate fingerprints:

MD5: 1A:F7:A8:17:90:70:23:E6:34:B2:C2:FE:36:B8:AC:13

SHA1:

83:0C:CE:A5:EB:17:81:44:BF:A6:74:EA:58:AA:ED:85:8C:6F:C6:A8

Signature algorithm name: SHA256withRSA

Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true

BasicConstraints:[

CA:true

PathLen:2147483647

]


KeyUsage [

DigitalSignature

Verifying vCenter and vShield Manager certificates




78

Key_CertSign

Crl_Sign

]


SubjectKeyIdentifier [

KeyIdentifier [

0000: 8E 2A 7E 03 AA BC 35 91 8B 9F 02 C7 8B 68 58 71

.*....5......hXq

0010: 91 44 90 70 .D.p

]

]

#4: ObjectId: 1.3.6.1.4.1.311.21.1 Criticality=false

Trust this certificate? [no]: yes


5. After the Root CA certificate has been added, to import the issuing CA certificate, run the following command:


vcd_verify_keystore.ks -import -alias intermediate -file

Issuing_CA_64.cer


Note In a production environment, multiple issuing CAs may exist. If so, each CA that has signed vCenter Server and vShield Manager certificates needs to be imported.

6. To verify the import by listing the keystore contents and checking the resulting output, run the following command:


vcd_verify_keystore.ks –list



Your keystore contains 2 entries



1A:F7:A8:17:90:70:23:E6:34:B2:C2:FE:36:B8:AC:13



4F:8E:47:53:5D:80:2D:15:E2:C1:BD:22:FC:FC:A7:E5

The root and intermediate certificates are displayed in the keystore.

Procedure: Import a JCEKS keystore Once you have created the keystore, log in to VMware vCloud Director as an Administrator. To import the keystore, follow these steps:

1. In the Administration window, under System Settings, under General settings, scroll down to the bottom, then select Verify vCenter and vSphere SSO certificates and Verify vShield Manager certificates, as shown in Figure 41.




Figure 41. VMware vCloud Director certificate verification

2. Click Browse to navigate to the JCEKS keystore that contains the certificate chain.

3. Provide the password for this file and click Apply.

The certificate chain is imported and stored in the vCloud Director database.

This configuration is global and applies to all vCenter servers and vShield Manager appliances. Each vCenter and vShield Manager must have a valid certificate chain and a certificate that matches its FQDN. If it does not, the connection to that system will fail.

If the issued certificates are replaced after adding vCenter servers or vShield Manager appliances to VMware vCloud Director, then force a reconnection to the servers by reconnecting each vCenter.

If vCenter servers or vShield Managers are added and have certificates issued by a CA other than those in the keystore, add the issuing CA certificate to the keystore and upload the keystore file again.

Cisco UCS certificates

By default, the HTTPS configuration in UCS Communication Services uses self-signed certificates to encrypt communications between two devices, such as UIM/P or an administrator’s browser and UCS Manager.

To provide stronger authentication for UCS Manager, you must install a trusted third-party certificate from a trusted source (known as “trusted point” in Cisco), that confirms the identity of the UCS system. The following sections detail the required procedures to enable management and communication over SSL.

Overview of UCS certificates




80

Procedure: Create a key ring through the UCS Manager CLI To create a new key ring, use SSH to log into the UCS cluster and execute the following commands:

1. Switch to the security context:

SP-UCS-01-A# scope security

2. Create a new key ring:

SP-UCS-01-A /security # create keyring <NAME_OF_KEYRING>

3. Configure the strength of the key (2048 bits):

SP-UCS-01-A /security/keyring* # set modulus mod2048

4. Create the certificate request with the cluster IP address and FQDN:

SP-UCS-01-A /security/keyring* # create certreq ip

172.30.208.66 subject-name sp-ucs-01.cork.lab.esg.local

5. Provide and confirm a password for the request:

Certificate request password:

Confirm certificate request password:

6. Save the configuration:

SP-UCS-01-A /security/keyring* # commit-buffer

7. Print the certificate request to the terminal window:

SP-UCS-01-A /security/keyring* # show certreq

-----BEGIN CERTIFICATE REQUEST-----

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

-----END CERTIFICATE REQUEST-----

8. Exit the scope:

SP-UCS-01-A /security/keyring* # exit

9. Submit the certificate request to the issuing CA, as detailed in the Submitting certificate requests section.

Procedure: Create a key ring through the UCS Manager GUI To create a new key ring, follow these steps:

1. Log into the UCS Manager web interface, select Admin and expand All to navigate to Key Management.

2. Right-click on Key Management and select Create Key Ring, as shown in Figure 42.

Generating a new certificate request




Figure 42. Navigation to Key Management.

3. Enter an appropriate Name and select Mod2048, as shown in Figure 43, to set the key to 2048-bit strength. Click OK.

Figure 43. Key ring creation dialog showing key bit strength options.

4. Select the newly created key ring, as shown in Figure 44, and select the Properties icon. Alternatively, right-click on the key ring and select Show Navigator.




82

Figure 44. List of key rings

5. Provide a password (optional), then enter the Subject (FQDN) and the IP address of the UCS cluster, as shown in Figure 45. Click OK.

After the certificate is created, a confirmation message appears.

Figure 45. UCS certificate request dialog box showing attribute options

6. Expand Request and copy the certificate request contents. Paste contents into a file to be used to submit the request.

7. Submit the certificate request to the issuing CA, as detailed in the Submitting certificate requests section.

The trusted point confirms the certification path of the SSL certificate. The SSL certificate is signed by the issuing trusted point, which according to Cisco “can be a Root CA or an Intermediate CA or trust anchor that is part of a trust chain that leads to a Root CA.”

Creating a trusted point




Certificate chaining issue in UCS

This is a critical part of the configuration, because it is possible to import the Root CA certificate as the trusted point. However, if you attempt to assign this trusted point to the key ring, you may receive the error message, as shown in Figure 46.

Figure 46. Certificate chain error dialog

If the error is shown, you must export or download the entire chain from your issuing CA via the Active Directory Certificate Services web portal and perform the following conversion exactly.

Procedure: Convert the chain to PKCS7S The exported certificate chain is in base64 p7b format; however, UCS Manager requires the chain certificate to be in PKCS7S format.

Convert the P7B certificate chain to PKCS7S by running the following command on a system with OpenSSL:

c:\> openssl pkcs7 -print_certs -in CACerts.p7b -out CACerts.crt

Procedure: Install the chain certificate through the UCS Manager CLI To install the chain certificate through the CLI, follow these steps:

1. To create the trusted point in which to store the chain certificate, type:

SP-UCS-01-A /security # create trustpoint

<NAME_OF_TRUSTPOINT>

2. To set the chain and paste the chain certificate file contents, type:

SP-UCS-01-A /security/trustpoint* # set certchain

Enter lines one at a time. Enter ENDOFBUF to finish. Press

^C to abort.

Trustpoint Certificate Chain:

subject=/C=IE/L=Cork/O=EMC Corporation/OU=EMC Solutions

Group/CN=Cork ESG Lab

Certificate Authority

issuer=/O=EMC Corporation/OU=EMC Solutions Group/CN=ESG

Lab Root Certificate Authority

-----BEGIN CERTIFICATE-----

XXXXXXXXXXXXXXXXXXXXXXXXXXX

-----END CERTIFICATE-----

subject=/O=EMC Corporation/OU=EMC Solutions Group/CN=ESG Lab

Root Certificate

Authority

issuer=/O=EMC Corporation/OU=EMC Solutions Group/CN=ESG Lab

Root

Certificate Authority

Installing the chain certificate




84




>ENDOFBUF

3. To save the configuration and exit, type:

SP-UCS-01-A /security/trustpoint* # commit-buffer

SP-UCS-01-A /security/trustpoint* # exit

Procedure: Install the chain certificate through the UCS Manager GUI To install the chain certificate through the UCS Manager interface, follow these steps:

1. To create a new trusted point, right-click on Key Management and select Create Trusted Point.

2. Provide a name for the trusted point (limited to 16 characters) and paste the previously converted PKCS7S certificate chain into Certificate Chain, as shown in Figure 47.

Figure 47. Creating the trust point and installing the certificate chain.

3. Click OK.

After the trusted point is created, a confirmation is displayed.

As a precursor to installing the SSL certificate, you must specify the trusted point that is to be used for the key ring. The trusted point validates the certification path of the SSL certificate.

Procedure: Install the SSL certificate through the UCS Manager CLI To import the SSL certificate, follow these steps:

1. To enter the key ring configuration context, type:

SP-UCS-01-A /security/keyring* # enter keyring

<NAME_OF_KEYRING>

Installing the SSL certificate




2. To configure the key ring to use the trust point created earlier, type:

SP-UCS-01-A /security/keyring* # set trustpoint

<NAME_OF_TRUSTPOINT>

3. To install the SSL certificate, paste the following text at the key ring certificate prompt:

SP-UCS-A /security/keyring # set cert

Enter lines one at a time. Enter ENDOFBUF to finish. Press

^C to abort.

Keyring certificate:




4. To save the configuration and exit, type:

SP-UCS-01-A /security/keyring* # commit-buffer

SP-UCS-01-A /security/keyring* # exit

Procedure: Install the SSL certificate through the UCS Manager GUI To install the SSL certificate through the UCS Manager interface, follow these steps:

1. Navigate to the new key ring and open its properties.

2. Select the trusted point associated with the SSL certificate from the Trusted Point list box.

3. Expand the Certificate section. Copy and paste the contents of the base64 SSL certificate file into Certificate, as shown in Figure 48, then click OK.




86

Figure 48. Setting the key ring trust point and installing the SSL certificate

If you receive a Verify Certificate error, ensure that you have exported the certificate chain and correctly followed the instructions in Creating a trusted point.

To apply the configuration changes, assign the new key ring to the HTTPS communications services and disable HTTP.

Note Any changes to the HTTP/HTTPS configuration will close all current HTTP/HTTPS sessions as soon as the changes are saved.

Procedure: Configure Communication Services through the UCS Manager CLI To change the configuration through CLI, follow these steps:

1. To switch to the services context, type the following commands:

SP-UCS-01-A /security/keyring # scope system

SP-UCS-A /system # scope services

2. To enable HTTPS, set the key ring to use and disable HTTP, by entering the following commands:

SP-UCS-01-A /system/services # enable https

SP-UCS-01-A /system/services # set https keyring <NAME>

SP-UCS-01-A /system/services # disable http

SP-UCS-01-A /system/services* # commit-buffer

3. Verify the change by browsing to https://f.q.d.n/ and viewing the certificate properties.

Applying the configuration changes




Procedure: Configure Communication Services through the UCS Manager GUI To change the configuration through the UCS Manager interface, follow these steps:

1. Expand Communication Management and select Communication Services. In the HTTPS panel, ensure that the Admin State is set to Enabled, and from the Key Ring list box, select the newly created key ring, as shown in Figure 49. Click Save Changes.

Figure 49. UCS Manager Communication Services configuration window

2. This causes UCS Manager to issue the warning, as shown in Figure 50. Select Yes to continue.

Figure 50. Warning dialog box displayed when saving HTTPS changes

3. The UCS Manager disconnects and prompts you to log in, as shown in Figure 51. Click Re-Login.

Figure 51. Prompt to re-login or exit UCS Manager




88

4. Navigate to Communication Services. In the HTTP panel, to restrict UCS Manager web access to exclusively use SSL, select Disabled.

EMC UIM/P SSL certificate

UIM/P can be configured to use an SSL certificate that has been signed by a trusted CA. A Perl script is used to generate a private key and certificate request. Once the CA has signed the SSL certificate, the same script is used to install the new certificate and private key into Apache, JBoss, and Tomcat configurations.

Procedure: Change the default SSL utility private key strength By default, the UIM/P private key is 1024 bits. To use 2048 bits or higher, follow these steps:

1. Using SSH, log onto the UIM/P appliance as a user with root privileges.

2. Use VI or a similar editor to edit the /opt/ionix-uim/tools/ssl/ssl-utility.pl file. Search for the following line:

open(PIPE,"| \"$OPENSSL\" req -newkey rsa:1024 -keyout

server.key -keyform PEM -out server.csr -outform PEM -

nodes") or die("ERROR: Failed to run openssl\n");

3. Replace rsa:1024 in the line with rsa:2048.

4. Save the file and exit the editor.

Procedure: Update the path to the Homebase configuration file For UIM 3.2, you also need to update the path to the Homebase server.xml file in the ssl-utility.pl script to reflect the correct path; otherwise, when a new SSL certificate is installed, Homebase will fail to start and you will not be able to provision operating systems using UIM/O. To update the path, follow these steps:


2. Use a VI or a similar editor to edit the /opt/ionix-uim/tools/ssl/ssl-utility.pl file. Search for the path at line 286 and 287:

$BMP_HOME/jboss/server/all/deploy/jboss-

web.deployer/server.xml

3. Use VI or a similar editor to edit the /opt/ionix-uim/tools/ssl/ssl-utility.pl file. Search for the path reference at line 286 and 287:

$BMP_HOME/jboss/server/standard/deploy/jboss-

web.sar/server.xml

4. Save the file and exit the editor.

Procedure: Create a certificate request To create the keypair and a certificate request, follow these steps:


2. Type the following command, and press Enter:

Configuring UIM/P to use an SSL certificate




sp-uimp-01:/opt/ionix-uim/tools/ssl # perl ssl-utility.pl -

keygen

3. Follow the prompts to supply general security information about the location of the appliance, such as country, state, locality, and organization name, and the hostname.

You can enter a period into a field to leave it blank, as shown in the following sample text:

============================================================

SSL Configuration Utility

------------------------------------------------------------

This utility will generate a private key and a Certificate

Signing Request (CSR). Note: Do not issue a private key

challenge password during the prompts to follow. The

password will be added during the install mode. Would you

like to continue? [y/n] y

Required certificate information:

Country Name (2 letter code): IE

State or Province Name (full name): County Cork

Locality Name (eg, city): Ovens

Organization Name (eg, company): EMC Corporation

Organizational Unit Name (eg, section): EMC Solutions Group

Server hostname: sp-uimp-01.cork.lab.esg.local

Generating Private Key and CSR...


........................................++

............................................................

............................................................

...........................................++

writing new private key to 'server.key'

-----

4. Enter DN information that will be incorporated into your certificate request. For some fields, there is a default value. You can enter a period into a field to leave it blank.

-----

Country Name (2 letter code) [AU]:State or Province Name

(full name) [Some-State]:Locality Name (eg, city)

[]:Organization Name (eg, company) [Internet Widgits Pty




90

Ltd]:Organizational Unit Name (eg, section) []:Common Name

(eg, YOUR name) []:Email Address []:



A challenge password []: An optional company name []:

Private Key created: /opt/ionix-uim/tools/ssl/server.key

Certificate Signing Request created: /opt/ionix-

uim/tools/ssl/server.csr

Please send the CSR to your preferred Certificate Authority

(CA). They will send you a certificate. Save this

certificate to this server, and then run this utility in the

"install" mode.

sp-uimp-01:/opt/ionix-uim/tools/ssl #

The ssl-utility.pl script generates the following files and stores them in the/opt/ionix-uim/tools/ssl directory:

server.key

server.csr

5. Submit the certificate request to the issuing CA, as detailed in the Submitting certificate requests section, and place the resulting certificate in the same directory as the ssl-utility.pl script.

Procedure: Install the CA issued UIM/P SSL certificate To install the new SSL certificate, follow these steps:


2. Run the following command and specify the newly created private key and CA-issued certificate:

sp-uimp-01:/opt/ionix-uim/tools/ssl # perl ssl-utility.pl -

install server.key sp-uimp-01.b64.cer

============================================================

SSL Configuration Utility

------------------------------------------------------------

This utility will install the private key and certificate

into httpd, Tomcat, and JBoss's configurations. The original

certificate, key, and keystore will be backed up into the

/opt/ionix-uim/backup directory. Would you like to

continue? [y/n] y

Stopping uim-service-wrapper service

Converting base64 encoded certificate to DER format...

Converting base64 encoded private key to DER format...




Injecting DER certificate and DER private key into the

keystore...

Using keystore-file : temp/voyence-ssl.keystore

One certificate, no chain.

Key and certificate stored.

Alias:voyence-server Password:

Applying a password to the keystore and private key...

Please create a password for the keystore:

YouWi11neverGu355!

Applying password to keystore...

Server fully qualified domain name: sp-uimp-

01.cork.lab.esg.local

Installing Apache certificate...

copying /opt/ionix-uim/conf/server.crt to /opt/ionix-

uim/backup/server.crt.2

Installing Apache private key...

copying /opt/ionix-uim/conf/server.key to /opt/ionix-

uim/backup/server.key.2

Installing JBoss keystore...

copying /opt/ionix-uim/jboss/server/vc-

server/deploy/1vc.sar/voyence-ssl.keystore to /opt/ionix-

uim/backup/voyence-ssl.keystore.2

Installing SLM Tomcat keystore...

copying /opt/ionix-uim/slm/conf/.keystore to /opt/ionix-

uim/backup/.keystore.2

Installing HomeBase keystore...

copying /opt/ionix-uim/bmp/keys/ssl.keystore to /opt/ionix-

uim/backup/ssl.keystore.3

Starting service uim-service-wrapper

SSL Configuration is complete.

EMC VMAX SSL certificates for Unisphere

EMC Solutions Enabler must be deployed in you environment in order to manage an EMC VMAX array. In addition, to encrypt the management traffic it is necessary to replace the default SSL certificate that is installed when Solutions Enabler is deployed.

Unisphere for VMAX




92

For the purposes of this PSG, we installed Unisphere for VMAX on the same system Solutions Enabler was installed on. This can be installed on a separate system and connect to the SYMAPI interface of Solutions Enabler over the network using SSL connections.

First we need to configure Solutions Enabler to use SSL and then configure Unisphere for VMAX to do likewise.

Procedure: Create a new Solutions Enabler keypair and certificate request 1. Generate the private key and certificate request using OpenSSL as shown

here:

C:\TEMP>c:\openssl\bin\openssl.exe req -config

C:\OpenSSL\bin\openssl.cfg -newkey rsa:2048 -keyout

C:\TEMP\symapi_x509.key -nodes -out C:\TEMP\symapi_x509.csr

WARNING: can't open config file: /usr/local/ssl/openssl.cnf

Loading 'screen' into random state - done


.............................................+++

............................................................

....................

..................+++

writing new private key to 'C:\TEMP\symapi_x509.key'

-----

You are about to be asked to enter information that will be

incorporated

into your certificate request.

What you are about to enter is what is called a

Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [IE]:

State or Province Name (full name) [County Cork]:

Locality Name (eg, city) [Ovens]:

Organization Name (eg, company) [EMC Corporation]:

Organizational Unit Name (eg, section) []:ESG

Common Name (e.g. server FQDN or YOUR name) []:storsrvd

corksmc01. cork.lab.esg.local

Email Address []:



A challenge password []:

An optional company name []:

Note As detailed in the Security Configuration Guide, the Common Name must contain “storsrvd” followed by a space and the FQDN. We have also supplemented this with SAN values for the FQDN, short name and the IP address, as in step 2 in this section.

2. Submit the request to the certificate authority with the appropriate Subject ALT names using the instructions in the Submitting certificate requests section of this guide.




Procedure: Install the Solutions Enabler SSL certificate 1. Convert the private key from X.509 to RSA format:

C:\OpenSSL\bin\openssl.exe rsa -in symapi_x509.key -out

symapi_key.pem

2. Copy the new key and certificate to the SYMAPI Cert folder

copy C:\TEMP\*.pem C:\Program Files\EMC\SYMAPI\config\cert

3. Copy the Root and Intermediate CA cert

copy root.crt C:\Program

Files\EMC\SYMAPI\config\cert\root.pem

copy intermediate.crt C:\Program

Files\EMC\SYMAPI\config\cert\root.pem

4. Run manage_server_cert.bat from the C:\Program Files\EMC\SYMAPI\config\cert folder with the update option. This will create the hashed DN links to the files new certificate files. You should see new hexadecimal file names with the “.0” extension. This is the MD5 hashed value of the Subject DN in the certificate.

C:\Program Files\EMC\SYMAPI\config\cert>"C:\Program

Files\EMC\SYMCLI\bin\manage_server_cert.bat" update

1 file(s) copied.

1 file(s) copied.

1 file(s) copied.

1 file(s) copied.

1 file(s) copied.

C:\Program Files\EMC\SYMAPI\config\cert>

5. Once run, edit the file C:\Program Files\EMC\SYMAPI\config\daemon_options and set, change or uncomment if necessary:

storsrvd:SECURITY_ALT_KEY_FILE = symapi_key.pem

storsrvd:SECURITY_ALT_CERT_FILE = symapi_crt.pem

6. Restart the EMC storsrvd and SMAS service by running these commands:

C:\TEMP>net stop storsrvd

The EMC storsrvd service is stopping..

The EMC storsrvd service was stopped successfully.

C:\TEMP>net start storsrvd

The EMC storsrvd service is starting.

The EMC storsrvd service was started successfully.

C:\TEMP>net stop EMCSMAS

The EMC Symmetrix Management Application Server service was

stopped successfully

.

C:\TEMP>net start EMCSMAS

The EMC Symmetrix Management Application Server service is

starting.




94


started successfully

.

Note Additional security features can be set based on your governing rules or regulations for security compliance. For more information, refer to the “Client/server security settings” section in the EMC Solutions Enabler V7.5 Installation Guide.

Procedure: Create a new Unisphere for VMAX keypair and certificate request 1. Stop the Unisphere for VMAX Tomcat service by running the following

command:

C:\>net stop EMCSMAS


stopped successfully

.

2. Change directories to the installation folder where the keystore file is located and generate a new certificate request.

D:\Program Files\EMC\SMAS\jboss\server\default-

em\conf>"D:\Program Files\EMC\SMAS\jre\bin\keytool.exe" –

genkey -keystore keystore –storepass “corksmc011@Keystore-2”

–keyalg RSA -keysize 2048 –alias tomcat


[Unknown]: CORKSMC01 corksmc01.cork.lab.esg.local


[Unknown]: ESG




[Unknown]: Cork




[Unknown]: IE

Is CN=corksmc01.cork.lab.esg.local, OU=ESG, O=EMC

Corporation, L=Cork,

ST=County Cork, C=IE correct?

[no]: yes

Enter key password for <tomcat>


Note As detailed in the Installation Guide, the keystore passwords are created at installation time and located in the file “<Install Directory>\jboss\server\default-em\deploy\ jbossweb.sar\server.xml”.

3. Generate the certificate request by running the following command:


em\conf>"D:\Program Files\EMC\SMAS\jre\bin\keytool.exe" -

certreq -alias tomcat -file tomcatcert.csr -keystore

keystore




4. Submit the certificate request to the certificate authority using the instructions in the Submitting certificate requests section.

Procedure: Install the Unisphere for VMAX SSL certificate Get the randomly generated password that was created during the Unisphere for VMAX installation. This can be found in the file <INSTALLDIRECTORY>\jboss\server\default-em\deploy\jbossweb.sar\server.xml. The password will be located on the line:

keystoreFile="${jboss.server.home.dir}/conf/keystore"

keystorePass=" corksmc01@Keystore-2".

1. Import the Root and Intermediate CA certificates into the Java Keystore file as detailed in the Installing Java CA certificates section of this guide.

2. Add the CA-signed certificate into the keystore


em\conf>"d:\Program Files\EMC\SMA

S\jre\bin\keytool.exe" -import -alias tomcat -file

tomcatcert.crt -keystore keys

tore -trustcacerts

Enter keystore password:

Certificate reply was installed in keystore

3. Start the Unisphere for VMAX Tomcat service

C:\>net start EMCSMAS

The EMC Symmetrix Management Application Server service is

starting.


started successfully

.

Note The Unisphere for VMAX tomcat service may take a few minutes to fully complete startup. You can check to see if the service startup is complete using “netstat –na | findstr 8443”

EMC VNX Unisphere SSL certificates

Location of certificates and configuration files

The OpenSSL configuration file used by the internal Control Station CA is located at: /nas/http/conf/celerrassl.cnf. To use this file as a template for the CA, we copied celerrassl.cnf to trustedca.cnf. This example uses the trustedca.cnf configuration template.

By default, the server key and certificate are stored in the ssl.key and ssl.crt directories in: /nas/http/conf.

Procedure: Generate a new key pair (OpenSSL) You can edit the trustedca.cnf template by using the values returned from issuing the following commands and replacing the variables in the trustedca.cnf configuration file with the preferred settings:

Control station certificates




96

IP_ADDR = <IP address of the Control Station>

HOSTNAME_LONG = <output of `hostname -f`>

HOSTNAME_SHORT= <output of `hostname -s`>

Procedure: Change the Control Station private key strength In versions prior to 7.1, the default private key strength is 1,024 bits; however, from version 7.1 on, the default key strength is 2,048 bits.

To use a non-default private key strength, use the following commands to create a new key pair:

1. Using SSH, log onto the VNX Control Station as a user with root privileges.

2. Generate a new private key with 2048-bit strength:

# openssl genrsa -out /nas/http/conf/ssl.key/server.key 2048

3. Lock down permissions on the key file:

# chmod go-rwx /nas/http/conf/ssl.key/server.key

4. Create a symbolic link to the newly created private key:

# ln -s /nas/http/conf/ssl.key/server.key

/nas/http/conf/current.key

Procedure: Create a certificate request To create a certificate request, follow these steps:

1. Using SSH, log onto the VNX Control Station as a user with root privileges.

2. Create the certificate request:

# /usr/bin/openssl req -key

/nas/http/conf/ssl.key/server.key -config

/nas/http/conf/trustedca.cnf -out

/nas/http/conf/cert_request

3. Display the newly created certificate request:

# cat /nas/http/conf/cert_request

4. Copy the certificate request from the terminal window and save to a text file.

5. Submit the certificate request to the issuing CA as detailed in the Submitting certificate requests section.

Procedure: Install the signed Control Station SSL certificate Once you obtain the base-64 format signed certificate, upload it to the Control Station into the following folder: /nas/http/conf/ssl.crt/.

1. Update the symbolic links to point to the new certificate:

# ln -s /nas/http/conf/ssl.crt/server.crt

/nas/http/conf/current.crt

2. Check that the certificate and key files mode bits are set to 0644 and 0600 respectively, if they are not then run one or both of the following commands:

# chmod 0600 /nas/http/conf/ssl.key/server.key




# chmod 0644 /nas/http/conf/ssl.crt/server.crt

3. To use the new certificate, restart Apache.

4. Repeat on the secondary Control Station, if deployed.

Procedure: Replace the VNX storage processor self-signed certificate To replace the VNX storage processor self-signed certificate with one signed by the trusted CA, follow these steps:

1. Browse to the VNX storage processor setup URL (http://IP.ADD.RE.SS/setup/)and log in using a Navisphere or LDAP account with Security Administrator privileges for VNX block.

2. At Certificate Management, as shown in Figure 52, select Manage SSL/TLS Certificate, then click Generate a Certificate Signing Request.

Figure 52. Certificate Management configuration

The configuration must meet a number of conditions for this process to work correctly:

Common Name (Domain Name) must be the SP hostname, not FQDN.

Common Name (Alias) must be blank.

Both Common Name (Domain Name) AND Common Name (IPv4) must be populated.

The pre-populated Organization Unit Name must be ou=CLARiiON.

Email Address must be blank.

If you do not adhere to these conditions, either a failure will occur during SSL certificate installation or you will encounter certificate errors.

VNX storage processor certificates




98

Figure 53 shows the certificate request configuration used for one of the VNX storage processor used in this solution.

Figure 53. Certificate request configuration

3. Click Generate a Certificate Signing Request and copy the PKCS#10 formatted certificate request content, as shown in Figure 54.

Figure 54. VNX storage processor certificate request export




4. Save the certificate request text in a file to submit to your issuing CA.

5. Submit the certificate request to the issuing CA as detailed in the Submitting certificate requests section.

Procedure: Import the new certificate To import the new certificate, follow these steps:

1. To import the signed certificate as PEM (base64) data, click Continue submit the signed certificate.

2. Return to the VNX SP Certificate Signing Request window and click Import Signed Certificate.

3. At Submit Certificate, as shown in Figure 55, paste the certificate contents into the text box, then click Submit the Certificate.

Figure 55. Import signed VNX SP certificate

Procedure: Import a new certificate through SecureCLI Alternatively, a certificate can be imported with the associated private RSA key through SecureCLI.

From a system with the naviseccli agent installed, run the naviseccli command using the following syntax to install the certificate:

naviseccli -User adminusr -password secretpass -Scope 0 -Address

172.30.208.127 security -pkcs12upload -file /path/to/pkcs12.cert




100

Notes

If you have entered a FQDN, an alias, or altered the pre-populated Organization Unit Name in the certificate request configuration window, you will receive the following error message: “Invalid common name. At least one of the certificate's common names must be set to the array's IP address.”

Entering an email address will not result in a certificate import failure; however, a certificate error will be displayed when the storage processor setup window is accessed.

If any of these errors occur, a new certificate request will need to be generated.

Repeat the procedures in VNX storage processor certificate for each storage processor.

Chapter 6: Integration with Centralized Authentication



6 Integration with Centralized Authentication This chapter introduces integration of authentication mechanisms with a centralized directory and includes the following sections:

Microsoft Active Directory—LDAP over SSL

Integrated Windows authentication and service accounts

VMware vCloud Director—LDAP and Kerberos

Authentication integration with VMware vSphere ESXi host

EMC VNX LDAP authentication over SSL

Authentication integration with TACACS+

Microsoft Active Directory—LDAP over SSL

It is an accepted security best practice to encrypt the authentication session, because account credentials are exposed in clear text when an application or system authenticates users using a simple BIND to the directory.

To enable LDAPS, an authentication certificate must be installed that meets the following requirements:

The LDAPS certificate is located in the local computer's personal certificate store (programmatically known as the computer's MY certificate store), or the Active Directory Domain Services (ADDS) personal certificate store.

A private key that matches the certificate is present in the local computer's store and is correctly associated with the certificate. The private key must not have strong private key protection enabled.

The enhanced key usage extension includes the server authentication (1.3.6.1.5.5.7.3.1) object identifier (OID).

The Active Directory fully qualified domain name of the domain controller must appear in one of the following places:

Common Name (CN) in the Subject field

DNS entry in the Subject Alternative Name extension

The certificate is issued by a CA that the domain controller and the LDAPS clients trust. Trust is established by configuring the clients and the server to trust the Root CA to which the issuing CA chains.

Microsoft Active Directory SSL certificates for LDAPS




102

You must use the Schannel cryptographic service provider (CSP) to generate the key.

Procedure: Create a LDAPS certificate template for AD CA A certificate template that supports server authentication needs to be created. To achieve this, follow these steps on the Certificate Authority that will issue the certificate:

1. Open the Certification Authority management console.

2. If done remotely, retarget the console to the issuing CA by right-clicking Certification Authority (Local) and selecting Retarget Certification Authority, as shown in Figure 56.

Figure 56. Retargeting the CA management console to issuing CA

3. Enter the server name in Another computer, as shown in Figure 57.

AD integrated Certificate Authorities




Figure 57. Specify server name of issuing CA

4. Right-click on the Certificate Templates folder and select Manage , as shown in Figure 58.

Figure 58. Managing certificate templates

5. Select a server authentication template, such as Kerberos or Web Server, right-click and then select Duplicate Template, as shown in Figure 59.




104

Figure 59. Duplicating an existing certificate template

6. Select Windows Server 2003 Enterprise as the minimum-supported CA, as shown in Figure 60, so that the new template will be available to administrators through the Microsoft Active Directory Certificate Services web portal, then click OK.

Figure 60. Choosing the minimum-supported CA

7. Give the copied template an appropriate name.




8. Right-click on the template, select Properties, then review the validity and renewal periods. If you want to publish the certificate in Active Directory, then this is also set here, as shown in Figure 61.

These options must conform to your organization’s security policy.

Figure 61. Certificate template properties

9. As shown in Figure 62, select Request Handling, then enter Minimum key size as at least 2,048 bits.




106

Figure 62. Request Handing configuration tab

10. If you intend to import the certificate to the Active Directory Domain Services certificate store, enable Allow private key to be exported, otherwise skip to the next step.

11. Select Subject Name, then:

a. Select Build from this Active Directory information, as shown in Figure 63, then select:

Common name from the Subject name format list box

DNS name

Service principal name (SPN)

b. Click OK.




Figure 63. Subject Name configuration

12. To enable the newly created certificate template, navigate to the Certificate Authority console. Right-click Certificate Templates, select New, then select Certificate Template to Issue, as shown in Figure 64.




108

Figure 64. Enabling a new certificate template

13. To enable the newly created certificate template, select it, as shown in Figure 65, then click OK.

Figure 65. Enable the new certificate template

The certificate template has been created, and certificates based on the LDAPoverSSL template can now be requested.




Procedure: Enroll domain controller LDAPS certificate Each domain controller must be configured with a certificate to encrypt LDAP connections. For each domain controller, complete the following steps:

1. To open the Certificates console, add the Certificates Snap-in (Computer account) to the Microsoft Management Console.

2. Expand the Certificates (Local Computer) folder and then expand the Personal folder. Right-click the Certificates folder, select All Tasks, and then select Request New Certificate, as shown in Figure 66.

Figure 66. Requesting a new certificate

If Request New Certificate is missing, then the Certificates Snap-in has been opened from a remote MMC. Open the MMC locally on the domain controller and add the Certificates Snap-in and click Next.

3. Select Active Directory Enrollment Policy and click Next.

4. At Request Certificates, select LDAPoverSSL, as shown in Figure 67, and click Enroll.




110

Figure 67. LDAP certificate enrollment

5. In the Certificate Enrollment dialog box, click Finish.

If the LDAPS-enabled domain controllers are configured with multiple server authentication certificates in the local computer certificate store, problems may arise with LDAPS authentication. This is because the Microsoft SSL provider (Schannel) selects the first valid certificate that it finds in the local computer store and that may not be the correct certificate.

To work around this issue, the LDAPS certificate can be placed in the Active Directory Domain Services (ADDS) personal certificate store in Windows Server 2008 R2.

Active Directory will exclusively use a certificate placed in the ADDS personal certificate store for LDAPS connections; however, there are important considerations to be made before you implement this. According to Microsoft:

Automatic certificate enrollment (auto-enrollment) cannot be utilized with certificates in the ADDS personal certificate store.

Current command line tools do not allow certificate management of the ADDS personal certificate store.

Certificates should be imported into the store and not moved through the certificates console.

Each LDAP server requires its own certificate in order to encrypt LDAP authentication sessions, but it is only necessary to use this option on a server that has multiple certificates for the purpose of server authentication in the local certificates store. The best solution is to have only one certificate in the computer's personal certificate store.

Active Directory Domain Services LDAPS certificate




Procedure: Export the LDAPS certificate for ADDS Follow these steps to export an LDAPS certificate from the local computer certificate store and import it to the ADDS personal certificate store.

1. Open the MMC and add the Certificates (Local Computer) Snap-in. Expand Certificates (Local Computer), select Personal, and then select Certificates.

2. To determine which of the list of certificates is the LDAPS certificate, view the Certificate Template column for LDAPoverSSL. Right-click this certificate, select All Tasks, and then select Export, as shown in Figure 68.

Figure 68. Exporting an LDAPS certificate

3. In the Certificate Export Wizard, click Next.

4. At Export Private Key, select Yes, export the private key, as shown in Figure 69, and then click Next.

Note If the option to export the private key is grayed out, either the option was not enabled in the template before the certificate was issued, or the Certificates Snap-in has been opened from a remote MMC. You must open the MMC locally on the domain controller and add the Certificates Snap-in.




112

Figure 69. Selecting the certificate format

5. At Export File Format, select Personal Information Exchange - PKCS #12 (.PFX) and Export all extended properties, as shown in Figure 70, and then click Next.

Figure 70. Selecting the certificate format parameters




6. Provide a password to protect the private key, then click Next.

7. Provide a file name and location in which to store the certificate, then click Next.

8. Review the settings and click Finish.

Procedure: Import the LDAPS certificate to ADDS To import the LDAPS certificate to the ADDS personal certificate store, follow these steps:

1. Connect to the desktop of the Domain Controller.



4. Add the certificates snap-in to the MMC, and, when prompted, select Service Account.

5. From the Service account list, select Active Directory Domain Services, as shown in Figure 71, then click Finish.

Figure 71. Selecting the service account

6. In the next window, click OK.

7. Expand the Certificates - Service store, expand NTDS/Personal, then right-click Certificates. Select All Tasks, then select Import, as shown in Figure 72.




114

Figure 72. Importing the LDAPS certificate

8. In the Certificate Import Wizard, click Next and browse to the LDAPS certificate that was exported, as shown in Figure 73. Select the certificate, then click Open.

Note Ensure that Personal Information Exchange or All Files is selected or else the file type or the LDAPS certificate will not be visible.

Figure 73. Choosing the LDAPS certificate from the file system

9. At File to Import, click Next, as shown in Figure 74.




Figure 74. Certificate format types and file import path

10. Enter the password you used to protect the certificate, as shown in Figure 75, then click Next.

Figure 75. Password for the LDAPS certificate to be imported




116

11. At Certificate store, select Place all certificates in the following store. Ensure Certificate store shows NTDS\Personal, as shown in Figure 76. Click Next.

Figure 76. Certificate store to import LDAPS certificate


13. Restart the ADDS service for the change to take effect.

The LDAPS certificate should now be visible in the console. The configuration can be validated by following Testing LDAPS connectivity.

Once you have confirmed that LDAPS is enabled and functioning correctly, you must export the LDAPS certificate to integrate components, such as Unisphere, vCloud Director, and vSphere, in the environment.

Procedure: Export the LDAPS certificate for installation on clients To export the LDAPS certificate, follow these steps:

1. Add the Certificates (Service account) Snap-in to the MMC on the domain controller, selecting Local computer and Active Directory Domain Services when prompted.

2. Expand the Certificates folder and expand the Personal folder. Right-click the LDAPS certificate and select All Tasks, then select Export, as shown in Figure 77.




Figure 77. Using the certificates management console to export the certificate

3. In the Certificate Export Wizard, click Next.

4. At Export Private Key, select No and click Next.

5. At Export File Format, select Base-64 encoded X.509 (.CER), as shown in Figure 78, and click Next.

Figure 78. Selecting the certificate format

6. Enter a file name and choose a location in which to store the certificate, as shown in Figure 79, and click Next.




118

Figure 79. Specify a location


The CA architecture implemented in our build integrates the Microsoft Certificate Service CAs with the Active Directory. There may be differences in how your CA is deployed in your production implementation, such as:

Standalone CA not integrated with Active Directory

CA Active Directory segregated from end-entity AD

Standalone or AD-integrated CA issuing certificates for non-AD LDAP directory

Procedure: Create LDAPS certificate template for non-AD integrated CA To configure the CA to issue LDAPS certificates for any of the above scenarios, refer to the Procedure: Configure the LDAPS certificate template with the following exceptions:

Do not publish in AD, as shown in Figure 80.

Specify that the Subject Name is supplied in the request, as shown in Figure 80.

Standalone or non-AD integrated Certificate Authorities




Figure 80. LDAPS certificate template properties showing required settings.

This enables AD LDAP certificates to be issued to standalone or external (non-Active Directory) systems. Non-Active Directory configurations are beyond the scope of this guide

Procedure: Generate an LDAPS certificate for non-AD CA 1. Create a ldaps_request.inf file containing the following:

[Version]

Signature="$Windows NT$"

[NewRequest]

Subject = "CN=corkdc01.cork.lab.esg.local"

KeySpec = 1

KeyLength = 2048

Exportable = TRUE

MachineKeySet = TRUE

SMIME = False

PrivateKeyArchive = FALSE

UserProtected = FALSE

UseExistingKeySet = FALSE

ProviderName = "Microsoft RSA SChannel Cryptographic

Provider"

ProviderType = 12

RequestType = PKCS10

KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; this is for Server

Authentication

2. Create a certificate request for the target domain controller by running the following command, replacing the values shown in bold with your domain controller and CA:




120

certreq -new –config “CORKCA01:Cork ESG Lab CA” -attrib

"SAN:[email protected]&dns=corkdc01.cork.lab.

esg.local&dns=cork.lab.esg.local&dns=CORK&dns=192.168.100.9"

ldaps_request.inf ldaps_cert_req.csr

3. Submit the certificate request, as detailed in Submitting certificate requests.

4. After the certificate is issued, export it by following the steps in the Procedure: Export the LDAPS certificate for ADDS.

5. Install it into the production domain controller’s Active Directory Domain Services personal certificate store by following the steps in the Procedure: Import the LDAPS certificate to ADDS.

6. Export the base 64 formatted LDAPS certificate by following the steps in the Procedure: Export the LDAPS certificate for installation on clients.

7. Repeat for each domain controller to be used as an LDAPS server.

Integrated Windows authentication and service accounts

In a production environment, it is an accepted security best practice to use service accounts to track and control applications, and to mitigate the impact of a potential systems compromise.

The integrated Windows authentication feature in Microsoft SQL Server provides better security than SQL Server authentication by taking advantage of Active Directory user security and account mechanisms.

In the following sections, we detail the steps required to improve security by using integrated Windows authentication for the vCenter Server SQL database, and service accounts for both vCenter Server and vSphere Update Manager.

While SQL Server Security is beyond the scope of this PSG, we make recommendations that refer to it in subsequent sections. Specifically, we discuss why integrated Windows authentication is preferred over SQL Server authentication. We also discuss why SQL Server’s services should be run under an account other than Local System.

When an application connects through an Active Directory user account, SQL Server validates the account name and password using the Active Directory principal token in the operating system. This means that Active Directory confirms the user identity.

SQL Server does not ask for the password and does not perform the identity validation.

Integrated Windows authentication uses the Kerberos security protocol, and provides a centralized mechanism for password policy enforcement with regard to complexity validation for strong passwords, support for account lockout, and password expiration. Integrated Windows authentication offers additional password policies that are not available for SQL Server logins.

Overview of Windows authentication and service accounts

Microsoft SQL Server Security

Integrated Windows Authentication




Microsoft recommends isolating the SQL Server services under separate, low-rights Active Directory or local user accounts for each SQL Server service to reduce the risk that one compromised service could be used to compromise other services. During the installation of Microsoft SQL Server, you have the option of specifying an alternate account for the SQL services to use.

Each service can be configured to use its own service account. SQL Server Configuration Manager utility should be used to manage or replace the accounts under which the services run.

The hierarchy of accounts (from least privileged to most privileged) that can be used is as follows:

1. Domain user (nonadministrative)

2. Local user (nonadministrative)

3. Network service account

4. Local System account

5. Local user (administrative)

6. Domain user (administrative)

Account Types 1 and 2 are preferred as they best encompass the principle of least privilege.

Local System is a very high-privileged built-in account. It has extensive privileges on the local system and acts as the computer on the network.

Account Types 5 and 6 are less secure, since they grant too many unneeded privileges.

We made the following assumptions:

This is either a fresh installation or a pre-existing installation that will change to use Windows authentication.

The vCenter Server database is already created on the Microsoft SQL Server.

The service accounts are already created in Active Directory.

Microsoft SQL Server 2008 R2 Native Client (for ODBC) is installed on the vCenter Server.

The easiest way to create a vCenter Server database on SQL Server is to modify the SQL script located in the vSphere installation package. You can browse to install_folder/vpx/dbschema/ and copy the SQL script (DB_and_schema_creation_scripts_MSSQL.txt) to another location, then customize the script according to your needs.

The vCenter Server service account must be granted access rights to the SQL Server and added to the vCenter Server database with the db_owner fixed database role. The set of database privileges needed for the vCenter installation and upgrade is different from the set of privileges needed for administration. Before installing or

SQL Server service accounts

Configuring the vCenter Server database




122

upgrading vCenter Server, you must grant adequate privileges to the database service account, which must also have the db_owner fixed database role or sysadmin server role (less desirable) on the msdb system database. The assigned role, whether db_owner or sysadmin, should be revoked once the installation or upgrade process is complete.

To install or upgrade Update Manager, you must grant a set of minimum privileges to the Update Manager database SQL login. The SQL login must have either the db_owner fixed database role or sysadmin server role (less desirable) on the Update Manager and msdb databases. This applies to both installation and normal operation of Update Manager.

Procedure: Grant service account rights To grant the service account rights to access the SQL Server and the relevant databases, follow these steps:

1. Open Microsoft SQL Management Studio and connect to the SQL Server database.

2. Navigate to Security then Logins. Right-click on the folder and select New Login, as shown in Figure 81.

Figure 81. Creating a new login in Microsoft SQL Server Management Studio

3. Enter a Login name. Select Windows authentication, as shown in Figure 82.




Figure 82. Specify the service account used by the login

4. Alternatively, search for the account by clicking Search and selecting Entire Directory in the Locations filter, as shown in Figure 83. Once the correct service account has been selected, click OK.

Figure 83. Locating the service account in Active Directory




124

5. Set Default database to the vCenter database, for example, MGMT-VC_DB, as shown in Figure 84, then click OK.

Figure 84. Specify the default database for the service account

6. In the Server Roles panel, under Server roles, select public, as shown in Figure 85, then click OK.




Figure 85. SQL Server roles to be assigned to service account

7. Select User Mapping. Under Users mapped to this login, select the maps that correspond to the vCenter and MSDB databases. Under Database role membership, select db_owner, as shown in Figure 86, then click OK.




126

Figure 86. SQL database role and user mapping for the service account

Procedure: Set up vCenter Server database ODBC DSN connections (64-bit) Configure a 64-bit ODBC data source number (DSN) to connect to the vCenter Server database.

1. Connect to the desktop of the vCenter Server.

2. Click Start. From Administrative Tools, select Data Sources (ODBC) and select System DSN, as shown in Figure 87.




Figure 87. ODBC configuration tool

3. Click Add and select the SQL Server Native Client 10.0 driver, as shown in Figure 88, then click Finish.

Figure 88. Choosing the Data Source driver

4. In the Create a New Data Source to SQL Server wizard, enter an appropriate name and description for the data source, enter the SQL Server to which you will connect, as shown in Figure 89, then click Next.




128

Figure 89. Providing the SQL server name

5. Select With Integrated Windows authentication, as shown in Figure 90, then click Next.

Figure 90. Choosing the authentication type

6. Select Change the default database to and select the correct Update Manager database from the list box, as shown in Figure 91, then click Next.




Figure 91. Select the database

7. In the final wizard window, click Finish.

8. The ODBC configuration review dialog box is displayed, as shown in Figure 92. To verify connectivity, click Test Data Source.

Figure 92. ODBC configuration review




130

9. When the test is completed, click OK.

By default, both vCenter Server and Update Manager services are installed to run under the Local System built-in server account. You do however, during the installation of vCenter Server, have the option to specify an alternate account for the services to use. This section addresses how to migrate to using domain user accounts in scenarios where vCenter Server or vSphere Update Manager have already been deployed and configured to use either the default Local System account or the local user accounts.

VMware recommends that you run vCenter Server and Update Manager using a user account rather than the default Local System built-in account, which has greater privileges than those required to run these services. The Local System built-in account is also more powerful than a normal member of the Administrators group, which can contribute to security problems, discussion of which is beyond the scope of this PSG.

In the lab environment, we have three layers of vSphere resources:

Advanced Management Pod of the Vblock System (AMP)

MGMT (used to manage the service provider resources)

CaaS (used to manage the vCloud resources)

In an ideal world, a unique service account is used for each vCenter service in each management layer, but this adds a large administrative overhead and level of complexity to the environment. For our purposes, we used one service account each for vCenter Server and Update Manager per management layer, as shown in Figure 93.

Figure 93. vCenter and Update Manager service accounts

In addition to providing better security and ease of management, when you use a domain-level service account, it enables integrated Windows authentication to access the vCenter and Update Manager databases.

Note The vCenter SQL Server database must be configured to enable the vCenter domain account access to SQL Server and specific privileges on the database.

Even if you do not plan to use Microsoft Active Directory authentication for SQL Server, VMware recommends that you install vCenter Server using a special-purpose user account on the Windows host with only a local Administrator role.

VMware stipulates the following conditions to correctly use a domain user service account for vCenter Server:

The user account must have administrative privileges on the local machine.

The user account must have the Log on as a service privilege (granted during installation).

Service accounts for vCenter Server and Update Manager




Note Update Manager does not require local Administrator’s group membership.

In the vSphere 5.0 installation wizard, you can specify the account name as DomainName\Username, for example, CORK\svc_vc_mgmt1.

When you configure vCenter and Update Manager in this way, it also enables service account management to be centralized in Active Directory. Ideally, these service accounts can be placed in a separate organizational unit (OU) with a customized group policy object (GPO) applied to enforce security and limit use of the accounts.

Procedure: Configure vCenter Server and Update Manager services You must stop the following services:

Update Manager service

VMware VirtualCenter Web service (Tomcat)

VMware VirtualCenter Server

1. On the vCenter Server, open Server Manager, then, under Local Users and Groups, navigate to the local Administrators group.

2. Add the domain service account for vCenter Server to the Administrators group.

Note vSphere Update Manager does not require administrator privileges to run and, therefore, is omitted from this step.

3. Open the Local Security Policy MMC and expand Local Policies, then select User Rights Assignment. In the Policy panel, open the Log on as service policy settings, as shown in Figure 94.

Figure 94. Configuring user rights assignment for service accounts

4. Add the domain service account, as shown in Figure 95, then click OK.




132

Figure 95. Assigning additional privileges to service accounts

5. Return to the Server Manager management console, expand Configuration, then select Services. Under Services, select the stopped service in the list, as shown in Figure 96.

Figure 96. Locating VMware services in the Server Manager console

6. To open the properties, right-click the selected service, then select Log On, as shown in Figure 97. Replace the credentials with the appropriate service




account per the vCenter Server and Update Manager service accounts, then click OK.

Figure 97. Log On tab of service properties dialog box

7. Run the Update Manager utility located in:

c:\Program Files (x86)\VMware\Infrastructure\Update

Manager\VMwareUpdateManagerUtility.exe

8. Enter the Update Manager service account credentials, as shown in Figure 98, and click Login.

Figure 98. vSphere Update Manager authentication




134

9. Click Database Settings. Enter the new service account credentials, as shown in Figure 99, then click Apply.

Figure 99. Setting the new vSphere Update Manager service account

10. Restart these services in the following order:

a. VirtualCenter Server

b. VirtualCenter Management Web service (Tomcat)

c. Update Manager service

11. Repeat for each vCenter Server and Update Manager system.




VMware vCenter Single Sign-On: RBAC

You can assign vCenter Single Sign-On administrator privileges to users or groups who are permitted to manage the SSO server. This also allows you to specify different groups to manage different aspects of the vSphere platform according to job function and encompasses the principle of separation of duties.

We also detail the steps required to configure SSO to use AD as a default domain to permit administrators and users to logon without having to specify their domain name.

Procedure: Configuring vCenter Single Sign-On administrative groups 1. Open the vSphere Web Client by browsing to http://vcenter.fqdn/vsphere-

client.

2. Logon as an administrative SSO user such as admin@System-Domain.

3. Click on Administration in the left hand navigation pane.

4. Under Access in the left hand navigation pane, click SSO Users and Groups and then select the Groups tab in the main body.

5. High-light the __Administrators__ principal name and click the Add Principals button, as shown in Figure 100.

Figure 100. SSO configuration pane showing SSO Administrators and Add Principals button highlighted

6. Select your AD domain from the Identity Source drop-down list, optionally you may enter a search term to narrow the directory results. Click Search, as shown in Figure 101.

Overview of SSO RBAC






136

Figure 101. Add Principals configuration pane showing the AD group configured as SSO administrators

7. Select the AD group to which you wish to grant SSO administrator privileges and click Add. Repeat this step if you have additional groups to be added and click OK when finished.

Procedure: Configuring vCenter Single Sign-On default domains 1. Open the vSphere Web Client by browsing to http://vcenter.fqdn/vsphere-

client.

2. Logon as an administrative SSO user such as admin@System-Domain.

3. Click on Administration in the left hand navigation pane.

4. Under Sign-On and Discovery in the left hand navigation pane, click Configuration and then select the Identity Sources tab in the main body.

5. Select the Active Directory identity source and click the Add to Default Domains button, as shown in Figure 102.

Figure 102. SSO configuration pane showing identity sources with Add to Default Domains button highlighted






6. Click OK to acknowledge the warning.

7. In the bottom pane, use the arrows to alter the order of domains and when satisfied click the Save button, as highlighted in Figure 103.

Figure 103. SSO configuration pane showing order of domains with Save button highlighted

VMware vCloud Director: LDAP and Kerberos

vCloud Director features the ability to integrate with a centralized authentication source such as vCenter SSO, LDAP directory, or Microsoft Active Directory as used in this solution. This integration provides Cloud Service Providers with the ability to implement role-based access control (RBAC) across the environment, with a central point of administration that enables account management to be centralized, in a manner consistent with their information security policies.

While accounts can be both authenticated and authorized using LDAP, Kerberos adds a stronger layer of security as it does not require transmission of passwords over the network. With Kerberos, authentication is achieved using Kerberos tickets.

When implemented together, Kerberos for authentication and LDAP for authorization, an even stronger solution for secure authentication and authorization is enabled. In this section, we show you how to configure both LDAP and Kerberos to integrate vCloud Director with Active Directory.

Note To use Kerberos, you must first configure LDAP.

Procedure: Configure LDAP over SSL (Microsoft Active Directory) To configure the LDAP over SSL, follow these steps:

1. Browse to the vCloud Director Administration web portal (https://IP.ADD.RE.SS/cloud/), select Administration, expand System Settings, then select LDAP, as shown in Figure 104.

Overview of vCloud Director authentication

Configuring LDAP over SSL




138

Figure 104. vCloud Director LDAP authentication configuration

2. In the LDAP panel, enter details for Server and Port.

Port = 636 for LDAPS, otherwise, Port = 389.

These are the default ports for LDAP and LDAPS. If the Active Directory domain controller is configured differently, then adjust the LDAP configuration accordingly.

3. Enter details for Base distinguished name.

In this example, the default users container (CN=Users, DC=cork, DC=lab, DC=esg, DC=local) has been used, but you can specify any container that contains all the users and groups that need to be synchronized and authenticated.

If the LDAPS certificate has not been exported from the Active Directory domain controller, do this before proceeding.

4. Select Use SSL and upload the LDAPS certificate, as shown in Figure 105.

Alternatively, a JCEKS key store can be created and uploaded.

Figure 105. Configuring SSL parameters for LDAP

5. Create a service account in Active Directory that vCloud Director will use to bind and query LDAP, if not already created.

6. In User name, enter the account that will be used to bind to Active Directory, in the format [email protected], for example, [email protected], as shown in Figure 106.




Figure 106. Setting the LDAP account to bind to Active Directory

You do not need to change the user and group attributes unless an LDAP authentication server other than Microsoft Active Directory is employed in the environment.

7. Click Apply. To validate your configuration, click Test LDAP Settings.

If configured correctly, a results window similar to that shown in Figure 107 appears. To close the window, click OK.

Figure 107. Validating LDAP connectivity

8. Click Synchronize LDAP. Under System Administrator & Roles, select Groups, then click Import from LDAP.

9. In the Import Groups dialog box, click Search Groups to display a list of Active Directory groups. Select vCloud Administrators and click Add.

The group you selected appears in Selected, as shown in Figure 108, and is assigned the System Administrator role. Click OK.




140

Figure 108. Importing LDAP groups from Active Directory

10. In the LDAP window, click Test LDAP Settings.

11. Enter a valid user account that is a member of the vCloud Director System Administrators’ group in Active Directory, and click Test, as shown in Figure 109. To close the window, click OK.




Figure 109. Validating Active Directory LDAP lookups

Procedure: Configure Kerberos To configure Kerberos, follow these steps:

1. Browse to the vCloud Director Administration web portal (https://FQDN/cloud/), select Administration, expand System Settings, then select LDAP.

2. At LDAP, under System Settings, select Administration.

3. Select Kerberos in the Authentication list box, as shown in Figure 110.

Do not select Use external Kerberos.

Figure 110. Kerberos authentication settings

Configuring Kerberos




142

4. To see a list of realms, click Edit All Realms, as shown in Figure 111.

Figure 111. List of realms and KDCs

5. To configure Realm (in the format DOMAIN.TLD) and KDC (in the format server.domain.tld), click Add.

6. At Add Realm, edit Realm and KDC, as shown in Figure 112, then click OK.

Figure 112. Configuring a Kerberos realm and KDC

7. At Edit Realms, select DNS, as shown in Figure 113.




Figure 113. List of realms and DNSs

8. To configure DNS for the realm, click Add.

9. At Add Domain, as shown in Figure 114, you can use .domain.tld as a wildcard for DNS. Click OK.

Figure 114. Configuring a Kerberos realm and DNS

10. Click Close then click Apply.

11. To validate your settings, click Test LDAP Settings.

12. Provide a valid User Name in the format of a User Principal Name (UPN), for example, [email protected], as shown in Figure 115, then click Test. Click OK.




144

Figure 115. Validating Active Directory LDAP lookups with Kerberos

vCenter Single Sign-On provides a new means by which service provider administrators can be authenticated in vCloud Director. VMware’s vCloud Director Administrator's Guide provides instructions on how to register vCloud Director with the vSphere Lookup Service and import vCenter SSO groups.

In our tests, when we enabled Allow lower-case realms in Edit Realms, it caused a connection failure when Test LDAP Settings was executed. Authentication also failed.

LDAP groups or users must be imported before LDAP administrators can log on to vCloud Director.

If authentication modes are switched (Simple to Kerberos, or vice versa), then LDAP user authentication fails until vCloud Director synchronizes with Active Directory (or LDAP server). This can be manually executed in the LDAP window by clicking Synchronize LDAP.

If Kerberos authentication mode is selected, LDAP users must log in using their UPN, for example, [email protected]. If Kerberos mode is not selected, then LDAP users must log in using the sAMAccountName attribute of their user name, for example, vcspadmin1.

Integration with vCenter SSO

Troubleshooting authentication problems

http://pubs.vmware.com/vcd-51/topic/com.vmware.ICbase/PDF/vcd_51_admin_guide.pdf

http://pubs.vmware.com/vcd-51/topic/com.vmware.ICbase/PDF/vcd_51_admin_guide.pdf




Authentication integration with VMware vSphere ESXi host

To integrate the ESXi host with Active Directory, after adding the ESXi host to the vCenter inventory, consider the following:

You must create and manage an ESX Administrators group named "ESX Admins" that restricts who can log into the ESXi hosts using Active Directory credentials.

If applicable, you need an OU where the ESXi hosts will reside in Active Directory. In this solution, we used an OU named “ESX Hosts”.

Procedure: Add the ESXi hosts to the Active Directory To add the ESXi hosts to the Active Directory, follow these steps:

1. Open the Domain Controller or system used for managing Active Directory, launch the Active Directory Users and Computers MMC Snap-in.

2. Select and expand the domain, select New, select Organizational Unit, then type ESX Hosts in Name, as shown in Figure 116, then click OK.

Figure 116. Adding ESX Hosts OU to the domain

3. Under the domain, select Users, select New, and select Group. Type ESX Admins in Group Name, as shown in Figure 117. Click OK.

Overview of authentication integration with ESXi host

Adding the ESXi hosts to the Active Directory




146

Figure 117. Adding ESX Admins users group to the domain

4. Open the vSphere client and connect to vCenter.

5. Select Home, then select Inventory, then select Hosts and Clusters.

6. Expand the left panel until you see the host that will be added to Active Directory. Select the host.

7. In the right panel, select Configuration, then select Software, then select Authentication Services. Click Properties, as shown in Figure 118.




Figure 118. ESX Host Authentication Services configuration window

8. In the Directory Services Configuration window, as shown in Figure 119:

a. Select Active Directory from the Select Directory Service Type list box.

b. Enter the Domain and optionally an OU (the default is the system’s container) where the ESX Host will be located in the form domain.local/OU.

c. Click Join Domain. Enter an Active Directory user name and password that have Create Computer Objects rights on the OU.

Alternatively, use an Active Directory administrative account.

Note Once joined to the domain, the Directory Service Configuration window will be grayed out with the exception of Leave Domain.




148

Figure 119. Directory Services Configuration window

Once the ESX Host is joined to the domain, you will see the host in the ESX Hosts OU in Active Directory, as shown in Figure 120.

Figure 120. ESX Host listed in Active Directory




EMC Unisphere for VMAX authentication

EMC Solutions Enabler must be deployed in you environment in order to manage an EMC VMAX array. Authentication for Unisphere for VMAX is configured through the Web application via the CLI tools installed with Solutions Enabler. Unisphere for VMAX, when implemented in combination with Solutions Enabler deployed on a Windows Server member of an Active Directory Domain, will by default be able to use Local Windows and/or Active Directory Domain-based authentication.

For the purposes of this PSG, we installed Unisphere for VMAX on the same system Solutions Enabler was installed on. This can be installed on a separate system and connect to the SYMAPI interface of Solutions Enabler over the network using SSL connections.

The following assumptions and prerequisites are made:

Authentication Prerequisites

Active Directory Authentication requirements for VMAX include:

Solutions Enabler v7.5.10.0 (se7510-WINDOWS-x64.exe)

To integrate Unisphere for VMAX with active directory, the Solutions Enabler must be deployed on a Windows Server that is a member of an Active Directory Domain. This eliminates the need for LDAP integration and uses the underlying Windows Server Kerberos authentication mechanism with Active Directory.

Windows Active Directory

Create a “VMAX_Admins” group

Add the “VMAX_Admins” group to the local administrators group on the Windows Server

Note If the “VMAX_Admins” group is not a member of the local administrators group, some tasks will not be available. An error message stating “Access denied - you are not an authorized base daemon user” is displayed. Conversely, if you are not a member of the “VMAX_Admins” group and are a member of the local administrators group, an error “The caller is not authorized to perform the requested operation” may be shown for some tasks.

Solutions Enabler Prerequisites

Ensure the Solutions Enabler version is compatible with the Enginuity Microcode of the VMAX you are managing.

Ensure the Gatekeeper LUNS are Zoned to all the ESXi hosts within the Cluster running this VM or Physical Server.

If a virtual machine, map the LUNS directly to the VM using RDM in physical compatibility mode.

Note After the LUNS have been presented to the Solutions Enabler target system, it is not necessary to format or mount these volumes once

Unisphere for VMAX




150

they have been presented to the host as these are used for sending array control messages via the SAN to the VMAX array.

SYMAUTH can restrict access by User/Group. More information can be obtained from the EMC Solutions Enabler Symmetrix Management CLI.

SYMACL can restrict access by machine. More information can be obtained from the EMC Solutions Enabler Symmetrix Management CLI.

Elevated Administration is required for some commands. This requires the logged-in user to right click on the Command Prompt start menu option and select “Run as Administrator” to open an elevated command prompt window.

Note When you run some commands on the Windows system, they must be run with Elevated Administrator rights, such as “symcfg discover”, which will populate the local database with the VMAX system that this system is connected to. An error message stating “Read or Read/Write permission/access not present” may be displayed if run from a user privileged command prompt.

Configuring Unisphere for VMAX authentication

Authentication configuration for Unisphere for VMAX can be accomplished through the SYMAUTH command line utility or through the Unisphere for VMAX interface.

Note When specifying users and groups, use of the fully qualified domain name is necessary. For example, if the domain is CORK, the fully qualified domain name is CORK.LAB.ESG.LOCAL. This is required for proper authentication for Unisphere for VMAX authentication. Users will also need to use this as the logon credential. For example:

C:\Program Files\EMC\SYMCLI\bin>symauth list -users

S Y M M E T R I X A U T H O R I Z A T I O N U S E R S

Symmetrix ID: 000194901323

Flags

Role User/Group name Component E

--------------- ----------------------------- -----------------

-------- -----

Admin User D:cork.lab.esg.local\ad* N/A .

Admin User H:CORKSMC01\localadmin N/A .

Admin Group D:cork.lab.esg.local\VM* N/A .

Legend for Flags:

(E) : N = Rule has no effect since a different rule grants greater

rights.

: . = Rule is active.

Note The default user created during the Unisphere for VMAX installation is not listed above. This user is for doing initial authentication configuration for




Unisphere for VMAX. After authentication configuration is complete, remove the default user account.

EMC VNX LDAP authentication over SSL

As part of the integration process, a centralized LDAP authentication system has been used and integrated with Unisphere to enable secure management of VNX storage.

EMC recommends that when you use LDAP for Unisphere on production environments, you implement trusted certificates and SSL security as part of the LDAP configuration.

Since unified VNX array OE releases 5.32 (block) and 7.1 (file), LDAP domains for both block and file share a common LDAP Domain configuration to authenticate administrators logging in with LDAP credentials. In addition, certificate validation is enabled by default and cannot be disabled. This section discusses how you configure the LDAP Domain to integrate with Active Directory.

The following prerequisite steps must be completed before you can configure the domain:

Determine the Active Directory domain name.

Create the Active Directory that will be mapped to VNX roles and add the users to the appropriate group. Each group must contain user accounts, not nested groups.

Provide a non-administrative Active Directory user account and password for binding the LDAP service in Unisphere.

Determine the DN for the users and groups search path that will be used for LDAP authentication to the VNX system through Unisphere, and the user account used to bind to the LDAP directory.

VNX OE versions 5.32 for block and 7.1 for unified arrays require LDAPS certificates that include the certificate chain in order to function correctly. This differs from previous VNX OE for block and OE for unified versions that required the LDAPS certificate and chain to be imported separately.

Procedure: Combine the LDAPS and chain certificates into a single file To combine the LDAPS certificate and chain, follow these steps:

1. Export the LDAPS certificate as instructed in this Procedure: Export the LDAPS certificate for installation on clients.

2. Export the CA chain certificates as instructed in this Procedure: Export the certificate chain.

3. After you have all three base64 certificates, open a command prompt and concatenate them, as shown in this example:

C:\>COPY /B

corkdc01_ldaps_b64.cer+Issuing_CA_64.cer+Root_CA_64.cer

corkdc01_ldaps_full_chain.cer

Overview

Prerequisites

VNX certificates for integration with Active Directory




152

Note The certificates can also be concatenated using a Linux shell or a text editor. Remember to repeat this procedure with the other domain controller’s LDAPS certificate to configure the secondary LDAP server. Also, the order in which the files are concatenated is important. The certificates should be in a particular order in the certificate chain file, starting with the end-entity certificate and finishing with the root CA certificate.

Procedure: Configure the LDAP Domain on a VNX array To configure the LDAP domain, follow these steps:

1. Open the Unisphere interface and ensure you authenticate as a global user with administrative privileges.

2. Click Domains (if you do not see Domains, click Home), as shown in Figure 121, then click Manage LDAP Domain.

Figure 121. Unisphere interface showing Domains window

3. To create a new LDAP service connection, click on Add.

4. In the Modify LDAP Connection Settings dialog box, enter the LDAP server’s FQDN, server type, port number, and protocol, as shown in Figure 122. An IP address or hostname will not work.

If Active Directory is used, as in this example, you must change the server type from the default LDAP Directory to Active Directory. Not doing so results in authentication failures because the directory attributes used to perform the lookup will be incorrect.

In addition, you must specify the AD Domain Name to be used.

Figure 122. Modify LDAP Connection Settings dialog box

Manage LDAP Domain certificates




5. Enter the credentials of the Active Directory bind account to be used, as shown in Figure 123, using the Distinguished Name of the account.

Figure 123. Base DN of account used to bind domain to Active Directory

6. Enter the user and group search paths.

While Figure 124 shows the default container, it may differ according to customer requirements.

Figure 124. Active Directory user and group search paths.

7. Because you want to encrypt the LDAP connections, you need to upload the LDAP server’s full certificate chain you created in Procedure: Combine the LDAPS and chain into a single file. Click Add Certificate. Click Yes to continue.

8. Select Add Certificate from File, as shown in Figure 125, browse to the location of the chained LDAPS certificate and select the certificate, click Open, then click OK.




154

Figure 125. Importing certificate from file

9. After the certificate is imported, click OK.

10. In Add LDAP Connection Settings, select Role Mapping, as shown in Figure 126. Under Manage Role Mappings:

a. Add the LDAP groups or users and assign appropriate Unisphere roles. Provide the Active Directory LDAP name of a group and the corresponding role it requires.

b. Click Add.

c. Repeat for any other LDAP groups or user accounts you want to map.




Figure 126. LDAP for block user and group mapping

11. Select Advanced and confirm that the directory attributes are correct, as shown in Figure 127.

This is more relevant for a non-Active Directory LDAP server but it is a good practice to review these settings.

If you are using Active Directory and you do not see sAMAccountName for User ID Attribute, then you have not set Active Directory as the server type on the Server tab.




156

Figure 127. LDAP Active Directory attributes configuration

12. Click OK. A dialog box appears with a review of the configuration and prompts you to continue, as shown in Figure 128. Click Yes.

Figure 128. LDAP connection settings configuration review

13. In the Confirmation dialog box, click OK.

14. In the Configure LDAP for Block Storage Systems window, to validate the configuration, click Synchronize. Unisphere synchronizes with the LDAP server. To confirm, click Yes, as shown in Figure 129.




Figure 129. LDAP for block synchronization

15. If the configuration is correct and Unisphere has successfully connected and authenticated using the bind credentials, a successful confirmation appears. Click OK twice to return to the main Unisphere window.

16. Log out of Unisphere and login using LDAP credentials to verify that the configuration is correct and the AD group role mappings are appropriately set.

Repeat the procedure if you want to configure an alternate LDAP server.

Authentication integration with TACACS+

TACACS+ provides an increased level of security through authentication, authorization, and accounting services, and is a publicly documented protocol over TCP/IP. EMC chose to use a TACACS+ implementation from TACACS.net due to its easy configuration and ability to integrate with Active Directory.

For this solution, TACACS+ is configured simply as an authentication source with no authorization restrictions. Configuring authorization for separation of duties, such as auditor, security administrator, and network administrator with the TACACS.net software is outside the scope of this PSG.

Implementation of TACACS+ involves a complete install of the software on the domain controllers, as recommended by TACACS.net. The complete install includes both services and utilities included to aid in configuring the TACACS+ server.

Documenting TACACS+ installation is outside the scope of this PSG, but we have included notes on the TACACS.net tools and their role in configuring the TACACS+ software.

During the installation, no password was entered for the shared secret; however, this can be changed or added in the TACACS+ configuration files.

During installation, you may encounter an error, as shown in Figure 130, when writing to the clients.xml file (even an empty password).

Overview of authentication integration with TACACS+

TACACS+ installation notes




158

Figure 130. TACACS.net installation error message

1. To fix this error, leave the Error dialog box open.

2. Navigate to c:\ProgramData\TACACS.net\config\clients.xml, right-click clients.xml, then select Properties.

3. To allow the installer to continue, select General, then deselect Read-only.

4. Return to the error dialog box and click Retry to complete the installation.

TACDES

TACDES is specifically for use in TACACS.net software. TACDES is used for creating hashes of a string to encrypt or disguise a password contained in the configuration files, as shown in this example:

Example

c:\Program Files (x86)\TACACS.net>tacdes "EMC Corporation"

Encrypted EMC Corporation is XtPsYbdfJnFZJ9UVGdikhw==

c:\Program Files (x86)\TACACS.net>

When you use TACDES, for example, in the clients.xml configuration file, the syntax is as follows:

Example using a plain text secret

<ClientGroup Name="DEFAULT">

<Secret ClearText="EMC Corporation" DES=""></Secret>

<Clients>

<Client>.*</Client>

</Clients>

</ClientGroup>

Example using a DES-encrypted secret

<ClientGroup Name="DEFAULT">

<Secret ClearText="" DES="XtPsYbdfJnFZJ9UVGdikhw=="></Secret>

<Clients>

<Client>.*</Client>

</Clients>

</ClientGroup>

TACTest

TACTest is used to test the TACACS+ user login and verify the configuration settings.




TACVerify

TACVerify is used to validate the syntax of several configuration files.

Once TACACS+ has been configured on the Active Directory Domain Controllers, to enable the use of TACACS+ for authentication, authorization, and accounting, we used the following configuration settings on the storage area network switches:

feature tacacs+

tacacs-server host 172.30.208.220 key 7 "HIG Uomugukyykr"


aaa group server tacacs+ AAA-Servers

server 172.30.208.220

server 172.30.208.240

aaa authentication login default group AAA-Servers

aaa authentication login console local

aaa authorization config-commands default group AAA-Servers local

aaa authorization commands default group AAA-Servers local

aaa accounting default group AAA-Servers

Procedure: Configure TACACS+ To configure TACACS+ on the Nexus 5000, to enable the use of TACACS+ for authentication, authorization, and accounting, we used the following configuration settings:

feature tacacs+



aaa group server tacacs+ AAA-Servers

server 172.30.208.220

server 172.30.208.240

use-vrf management

aaa authentication login default group AAA-Servers

aaa authentication login console local

aaa authorization config-commands default group AAA-Servers local

aaa authorization commands default group AAA-Servers local

aaa accounting default group AAA-Servers

Procedure: Integrate UCS Manager GUI and CLI with TACACS+ To integrate Cisco UCS Manager GUI and CLI with TACACS+, the authorization.xml file on the TACACS+ servers must be configured to set the user’s role to Administrator at login. To do this, we created a new authorization section with specific ClientGroup “UCS” and AutoExec parameters for UCS Manager as follows:

<Authorization>

<UserGroups>

<UserGroup>Cork_UCS_Admins</UserGroup>

<UserGroup>Network Engineering</UserGroup>

</UserGroups>

<ClientGroups>

<ClientGroup>UCS</ClientGroup>

</ClientGroups>

<AutoExec>

<Set>shell:roles="admin"</Set>

MDS TACACS+ integration

Nexus TACACS+ integration

Cisco UCS Manager and TACACS+ integration




160

</AutoExec>

<Shell>

<Permit>.*</Permit>

<Deny>.*</Deny>

</Shell>

<Services>

<Set>protocol=ip </Set> -->

</Services>

</Authorization>

Procedure: Add a new key ring To create a new key ring, log into the UCS cluster using SSH and execute the following commands:



2. Enter security TACACS+ mode:

SP-UCS-01-A# scope tacacs

3. Create a TACACS+ provider (authentication server):

SP-UCS-01-A /security/tacacs # create server

<NAME_OF_TACACS_SERVER>

4. Provide the TACACS+ server key:

SP-UCS-01-A /security/tacacs/server* # set key

5. Set the order preference for this TACACS+ server:

SP-UCS-01-A /security/tacacs/server* # set order

<ORDER_OF_AUTH_SERVER>

6. Set the port number this TACACS+ server uses, if it differs from the default (49):

SP-UCS-01-A /security/tacacs/server* # set port

<PORT_OF_AUTH_SERVER>


SP-UCS-01-A /security/tacacs/server* # commit-buffer

Procedure: Add secondary or subsequent TACACS+ servers To add secondary or subsequent TACACS+ servers to a TACACS+ provider group, follow these steps:



2. Enter security TACACS+ mode:

SP-UCS-01-A# scope tacacs

3. Create a TACACS+ provider (authentication server):

UCS Manager command line interface




SP-UCS-01-A /security/tacacs # create auth-server-group

<NAME_OF_SERVER_GROUP>

4. Add the previously created TACACS+ providers:

SP-UCS-01-A /security/tacacs/auth-server-group* # create

server-ref <NAME_OF_SERVER1>

5. Back up and add the second and subsequent TACACS+ providers:

SP-UCS-01-A /security/tacacs/auth-server-group/server-ref* #

up

SP-UCS-01-A /security/tacacs/auth-server-group* # create

server-ref <NAME_OF_SERVER2>


SP-UCS-01-A /security/tacacs/auth-server-group/server-ref *

# commit-buffer

Procedure: Make TACACS+ the primary authentication source UCS Manager uses the Authentication Domain default of Local. To change and use TACACS+ as the primary authentication source, follow these steps:



2. Enter default authorization mode:

SP-UCS-01-A# scope default-auth

3. Set the authentication source type:

SP-UCS-01-A /security/default-auth # set realm <TYPE> e.g.

tacacs

4. Add the previously created TACACS+ provider group:

SP-UCS-01-A /security/default-auth # set auth-server-group



SP-UCS-01-A /security/default-auth * # commit-buffer

Procedure: Change the role policy for remote user While not absolutely necessary, it is good security practice to change the role policy for remote user from its default Read-only to “No Login”. This restricts management of roles and authorization to the TACACS+ servers. To implement this control, follow these steps:



2. Set the default role for remote users:

SP-UCS-01-A /security # set remote-user default-role <ROLE>

e.g. no-login




162


SP-UCS-01-A /security # commit-buffer

Procedure: Change the authentication source type The authentication source type option requires careful consideration as failure of multiple defined TACACS+ servers, or the authentication backend for TACACS+ (for example, Active Directory or LDAP) could result in Administrators being unable to log in to the console. To change from the default Local to TACACS+, follow these steps:



2. Enter console authorization mode:

SP-UCS-01-A# scope console-auth

3. Set the authentication source type:

SP-UCS-01-A /security/console-auth # set realm <TYPE> e.g.

tacacs

4. Add the previously created TACACS+ provider group:

SP-UCS-01-A /security/console-auth # set auth-server-group



SP-UCS-01-A /security/console-auth * # commit-buffer

Procedure: Create a TACACS+ provider group To create a TACACS+ provider group, follow these steps:

1. Log into the UCS Manager web interface, select Admin, and expand All. Select and expand User Management, then select TACACS+, as shown in Figure 131.

Figure 131. UCS Manager showing navigation to TACACS+ configuration

UCS Manager GUI




2. Click Create TACACS+ Provider and enter the TACACS+ server IP address and key, as shown in Figure 132. The order, port, and timeout values can be customized, if required. Click OK.

Figure 132. Creating TACACS+ Provider configuration

3. Add a second or subsequent TACACS+ server. Once all the TACACS+ servers have been created, click Create TACACS+ Provider Group.

4. Provide a descriptive name for the group and select the TACACS+ servers on the left and add them to Included Providers, as shown in Figure 133. Click OK.

Figure 133. Create TACACS+ Provider Group configuration




164

5. Under User Management, select Authentication, as shown in Figure 134.

Figure 134. UCS Manager showing navigation to Authentication configuration

6. Click Create a Domain, then do the following, as shown in Figure 135:

a. Provide a descriptive name.

b. Under Realm, select TACACS.

c. Select the Provider Group created earlier for the list box.

d. Click OK.

Figure 135. Create an authentication domain

7. Under User Management, select Native Authentication, as shown in Figure 136.




Figure 136. Native Authentication configuration

8. Under Default Authentication, select Tacacs from the Realm list box. Select the provider group created in a previous step from the Provider Group list box.

9. Select the same options for Console Authentication.

Be aware that Administrators may not be able to log in through the console if TACACS+ or its back-end authentication source is offline.

10. By default, Assign Default Role, which is read-only, is selected for Role Policy for Remote Users. A better security practice would be to set it to No Login.

11. Click Save Changes.

UIM/P supports integration with a TACACS+ authentication source. While users and groups must be created locally on the UIM/P appliance, authentication is performed against TACACS+. By default, newly created users and groups have no privileges; therefore, after account creation, permissions must be assigned to grant access to UIM/P.

Procedure: Configure TACACS+ authentication servers To configure the TACACS+ authentication servers, follow these steps:

1. Log in to the UIM/P web interface and navigate to the Dashboard, as shown in Figure 137. To access the configuration center, click Switch center, and select Configuration Center.

EMC UIM/P TACACS+ integration




166

Figure 137. UIM/P Dashboard

2. From Tools, select System Administration, as shown in Figure 138.

Figure 138. UIM/P Configuration Center navigation to System Administration

3. Select and expand Global, then select and expand User Management. Select and expand Authentication Servers, then select TACACS+, as shown in Figure 139.




Figure 139. UIM/P TACACS+ Authentication Servers configuration

4. Configure the servers:

a. Enter the IP addresses of the primary TACACS+ and secondary TACACS+ servers.

b. Enter and confirm the key for each server.

c. Verify that the port is correct. If the default (49) is not used, enter the custom port here.

d. Click Apply.

Procedure: Create user accounts to enable external authentication Create a UIM user account for each network user that will be authenticated by the TACACS+ authentication servers by following these steps:

1. To create the users, select and expand Global, select and expand User Management, then select System Users.

2. Click Add and enter the user attributes, as shown in Figure 140.

The User ID must match the corresponding Active Directory account’s username.




168

Figure 140. Adding users

3. Select External TACACS+ from the Authentication list box, then click OK.

4. Click Apply and repeat for each system user.

5. When complete, click OK.

Assigning user privileges

You must assign the users with privileges by either:

Adding the users to the default UIM-ServiceAdmin or UIM-SystemAdmin groups

Creating additional groups corresponding to operational roles and assigning the appropriate permissions to these groups

Procedure: Assign user privileges To assign privileges, follow these steps:

1. Select and expand Global, then select and expand User Management, then select System Groups.

2. To create a new group click Add, then do the following, as shown in Figure 141.

a. Enter Group Name and Description.

b. Select users to be added to the group from Available Members.

c. Click Add, then click OK.




Figure 141. Creating groups for role-based access control

3. To assign privileges, in the System Groups window, select the group, then click Permissions.

This opens Access Control Administration, which provides granular permissions for access control, as shown in Figure 142.

Figure 142. Configuring group permissions for role-based access control

4. Edit permissions as required. To save your edits, click Apply.




170

Note While it is possible to assign permissions directly to user accounts, it is an industry-accepted best practice to employ role-based access control and use groups to manage roles.

The purpose of the procedures in this section is to employ SSL during the UIM/P - Vblock Systems discovery process in order to protect the credentials used. This improves security by centralizing authentication and enabling secured management traffic through encryption.

Prerequisites

The following prerequisite steps must be completed before you can initiate Vblock Systems discovery:

Create an account (for example, uimadmucs) in Active Directory for UIM/P to use to discover UCS.

Create a global administrator account (for example, uimadmvnx) in Unisphere for UIM/P to use to discover the storage processor.

Create an account (for example, uimadmucs) in Active Directory for UIM/P to use to discover the SAN Fabric.

UCS cluster

To enable discovery of Cisco UCS resources over SSL, use the following procedures:

Export the UCS Manager certificate

Install the certificate in UIM/P

Configure Vblock Systems discovery

Procedure: Export the UCS Manager certificate To export the UCS Manager certificate, follow these steps:

1. Start the Certification Authority on the issuing CA and navigate to Issued Certificates, as shown in Figure 143.

Figure 143. Certification Authority console showing SSL certificate issued to UCS Manager

UIM/P - Vblock System discovery over SSL




2. Verify that the Binary Certificate column is visible. If not, add it through View then select Add/Remove Columns.

3. Identify the UCS Manager certificate, double-click to open, then click Details, as shown in Figure 144.

Figure 144. Cisco UCS Manager SSL certificate properties.

4. To open the Certificate Export wizard, click Copy to File. Select DER encoded binary X.509 (.CER) format.

Alternatively, if you do not have access to the CA or issued certificate, you can export it through a browser. For information on exporting certificates, refer to the Certificates section in the EMC UIM/P Software Installation and Configuration Guide.

Because the certificates in this solution are issued by an internal CA, you also need to import the chain certificate in PEM format. You must ensure that the chain certificate file has a CRT extension.

Procedure: Install certificates in UIM/P To install certificate in UIM/P, follow these steps:

1. Ensure the certificate filename has a CRT extension, if not, rename it.




172

2. Copy the exported certificate to the following directory on the UIM/P appliance <UIMP_HOME>/conf/CA, where <UIMP_HOME> is the directory on which the UIM/P appliance is installed, usually /opt/ionix-uim/conf/CA.

3. Once both certificates are uploaded to the UIM/P appliance, issue the following command from the <UIMP_HOME>/conf/CA directory:

sp-uimp-01:/opt/ionix-uim/conf/CA # ./cert_HASH.pl

Installing:CORK_CERT_CHAIN.crt....

Installing:sp-ucs-01.cork.lab.esg.local.crt....

Installing:voyenceca.crt....

sp-uimp-01:/opt/ionix-uim/conf/CA #

Procedure: Configure discovery If you have configured Cisco UCS Manager as specified in Cisco UCS certificates, then the configuration is complete. To configure, discovery, follow these steps:

1. In the UIM/P Manager window, select Administration.

2. Click Vblocks and select the correct Vblock System (in this example, SPEng-Vblock, as shown in Figure 145), then click Edit.

Figure 145. UIM/P dashboard showing Vblock System configuration properties

3. Select Use SSL, enter the TACACS+ credentials (not the local UCS account), as shown in Figure 146, then click Modify.

Figure 146. Vblock System/UCS cluster settings

Note Do not run discover until the rest of the configuration is complete.




VNX storage processor

UIM/P uses a static NAVISECCLI command with a scope parameter value of 0 (Scope 0) to log into the VNX storage processor. This means that UIM/P can only log on to the VNX storage processor using a global account created through Unisphere. LDAP or TACACS+ are not yet an option, however, a global user account can be created specifically for UIM/P to use for VNX discovery.

You can modify the VNX storage processor discovery settings by entering the IP address of the VNX storage processor and the global Unisphere credentials you created previously and changing the details, as shown in Figure 147.

Figure 147. Vblock System/VNX storage processor settings

SAN fabric

You can change the fabric discovery settings by providing the IP addresses of both MDS fabric directors, entering the TACACS+ credentials created for UIM/P discovery, modifying the details, as shown in Figure 148.

Figure 148. Vblock System/MDS fabric settings

Note After importing any certificates, restart the UIM device service to perform a successful discover by running the following command from the UIM CLI:

sp-ucs-01:~ # service uim-device-services restart

Troubleshooting UCS discovery issues

When complete, the Details window in UIM/P should update to display Discovery Succeeded. If not, then the likely cause is misconfigured credentials. You must test the UIM/P credentials for each of the components.

If UCS cluster discovery fails with an HTTP/HTTPS-related error, it is likely due to an incomplete chain certificate installed in UCS Manager. Refer to Certificate chaining issue in UCS.

If VNX discovery fails, try to login using navseccli from the UIM CLI, using the following syntax:

sp-uimp-01:/opt/Navisphere/bin # ./naviseccli -User adminusr -

password secretpass -Scope 0 -Address 172.30.208.126

If you receive the following response, then there is a problem with the VNX certificate that was imported to UIM.

Error occurred while trying to connect: '172.30.208.127'.




174

Message : Invalid server certificate: certificate not trusted.

You should be able to observe a response like this:

Possible commands are:

migrate compression connection isns

Domain

Security spcollect arrayconfig EventMonitor

ntp

7 Verification This chapter summarizes our verification efforts to ensure the configuration resulted in the expected behavior, and includes the following sections:

PKI certificate verification

Authentication verification

PKI certificate verification

The verification process we used to ensure that the PKI x.509 certificates were properly issued and installed is described in this section at a high level.

The verification was demonstrated using a Web Browser for each of the following components:

HTTP Default SSL Port (443)


VMware vShield Manager

VMware vCenter Client

VNX Control Station

VNX Storage Processor A

VNX Storage Processor B

EMC UIM/P

Cisco UCS

For the following vCenter Server SSL ports, see VMware KB 2005105:

VMware vCenter Management Web services—port 8443

VMware vCenter Inventory Service—port 10443

For the following vCenter Server SSL ports, see VMware KB 1004543:

VMware vSphere Update Manager - 9087

To verify certificates, we used Microsoft Internet Explorer 9 (IE9) from a system that was used to manage the AMP, MGMT, and CaaS environments. IE9 was used to verify that the certificate chain was properly installed into the certificate store and that the end-entity certificate was valid.

When visiting one of the web-based applications, we browsed to that site and port using the FQDN name, Hostname (short-name), and IP address to verify that the certificate was created properly. For example, https://f.q.d.n:443/ is the FQDN name

Verification process for PKI certificates

https://f.q.d.n/

Chapter 7: Verification



176

and 443 is the port where the SSL-enabled service is located. This verified the SAN field and the DN. Figure 149 shows a passed verification, while Figure 150 shows a failed verification.

Figure 149. Correctly configured SSL service (verification passed)

Figure 150. Incorrectly configured SSL service (verification failed)

Procedure: Verify the certificate chain To verify the certificate chain:

1. Click the lock to view the certificate.

2. Once the certificate for the system is displayed, click Certificate Path.

3. Verify that the certificate status is okay, as shown in Figure 151, and click OK.

Figure 151. Certificate path and status




Authentication verification

The verification process we used to ensure that the authentication services were configured correctly is described in this section at a high level. The verification was demonstrated by logging in to each system’s management interface using Active Directory credentials.

We created two domain credentials for this purpose: an administrator account (CORK\admin) and a user account (CORK\user). The accounts had the Active Directory group memberships shown in Table 6.

Table 6. Active Directory group memberships

Account Groups Additional notes

CORK\admin Cork Network Admins Administrators of Nexus/MDS

ESX Admins

StorageAdmins Administrators of VNX block and file

VblockAdmins Administrators of UCS and UIM/P

vCloud Administrators

vSphereAdmins

CORK\user Domain Users Account with no administrative privileges

The solution stack used a number of authentication services—LDAPS, TACACS+ and Kerberos—which in turn used Microsoft Active Directory as the directory service underpinning authentication in the solution.

Table 7 provides a breakdown of the components and authentication services used.

Table 7. Components and authentication services

Solution components Authentication service Additional notes

MDS fabric switches TACACS+

Nexus TACACS+

UCS TACACS+

UIM/P TACACS+

VNX LDAPS Control stations and storage processors

vCloud Director Kerberos and LDAPS Kerberos for authentication

LDAP for authorization

vShield Manager LDAPS Indirectly, uses vCenter for authentication

ESXi LDAPS

vCenter LDAPS

Verification process for authentication services




178

Procedure: Test LDAPS connectivity To verify that LDAPS is enabled on the Active Directory domain controllers, and clients can successfully authenticate through an LDAP client, you can use LDP to do the following steps.

Note LDP is available if the Active Directory Domain Services role is installed on Windows Server 2008 and later. Otherwise, LDP can be installed with the Windows Server 2003 Support Tools from the product CD or downloaded from the Microsoft Download Center.

1. From Start or the command prompt, type ldp.exe and press Enter. From Connection, select Connect, as shown in Figure 152.

Figure 152. Configuration verification with LDP

2. Enter the domain controller server name, select SSL, change Port to 636, as shown in Figure 153, then click OK.

Figure 153. LDP connection parameters

3. Select Connection, then select Bind.

Testing LDAPS connectivity




4. Select Bind with credentials. Enter the credentials of the domain user account that was created to bind to Active Directory, as shown in Figure 154, then click OK.

Figure 154. LDP credentials to bind to Active Directory

5. Select View, then Tree. Enter the base DN (for example, DC=cork, DC=lab, DC=esg, DC=local), as shown in Figure 155, then click OK.

Figure 155. Base DN to query Active Directory

6. To see the directory, expand the tree and double-click the containers, as shown in Figure 156.




180

Figure 156. LDAPs to Active Directory

In order to ensure that the VNX and VMware components used LDAPS at all times, we created a simple Windows firewall on each domain controller to block access to LDAP (TCP port 389). This ensured that credentials could not be transmitted in unencrypted form over the network.

Note TACACS+ protocol encrypts both the user name and password so no credentials are exposed in clear text over the network. Similarly, Kerberos packages the user’s UPN and the user’s credentials in an encrypted ticket and encrypts all subsequent exchanges.

Once each component was configured to use an authentication service with a corresponding administrative group, we performed a verification test to validate the configuration. This involved logging into the component management interface (web UI, GUI, or SSH) using the CORK\admin credentials and, if successful, observing that the administrative level of access granted was as expected (full administrative access). In the case of vCloud Director, the user SPN, [email protected], was used because the SPN is required for Kerberos authentication.

All login attempts resulted in successful authentication with full administrative access, as expected.

Once the administrative test was successfully completed, which demonstrated that the configured authentication services function as expected, we performed the same verification with an Active Directory user account (CORK\user). This test account has no administrative privileges and is not a member of any groups other than Domain Users. In the case of vCloud Director, the user SPN, [email protected], was used because the SPN is required for Kerberos authentication.

All login attempts resulted in authentication failures, as expected.

8 Conclusion This section summarizes our test results and includes the following sections:

Summary

Findings

Summary The infrastructure solutions stack required to deliver Cloud Provider services must provide an easy means of centralized management, bringing together the software and hardware components that form the complete solution in such a way that they can be securely managed and enforced.

This solution shows that a hardened EMC “as-a-service” solution stack can be integrated with a public key infrastructure (PKI) in order to strengthen authentication and non-repudiation. In addition, this solution shows how integration with a common directory may be achieved to support LDAP, Kerberos, and TACACS+ authentication services, streamline administration and policy enforcement, and provide tighter control.

The procedures in this PSG enable Cloud Providers or Enterprise organizations to strengthen their security baseline and provide a solid foundation in preparation for achieving certification of industry and regulatory standards compliance.

Findings The solution performed as expected with improved trust established through the use of trusted X.509 certificates and centralized authentication and authorization services such as LDAP, Kerberos, and TACACS+ being provided by using Microsoft Active Directory as the underlying directory. We confirmed the following during testing of this solution:

It is both feasible and desirable to integrate PKI across the hardware and software infrastructures of an as-a-service solution stack.

LDAP, Kerberos, and TACACS+ authentication mechanisms can be implemented with Microsoft Active Directory to enable a centralized point of administration and policy enforcement for securing as-a-service solution stacks.

The combination of different vendors’ hardening procedures can be applied across the entire infrastructure solution stack without issue.

The baseline can be applied to numerous solutions and additional components added to the PKI infrastructure as required by using the combination of authorization services.

Chapter 8: Conclusion



182

The solution can be used in its entirety or on a per component basis as required.

By using industry standards and vendor best practices in delivering this solutions guide, Cloud Providers can be confident in the validation of each component and the future integration of technologies when using open standards in a tightly integrated security model.

9 References

Refer to the following white papers, available on the EMC online support website, for information about solutions similar to the one described in this paper:

EMC Compute-as-a Service: Design Principles and Consideration for Deployment

EMC Security Design Principles for Multi-Tenant as-a-Service Environments

EMC Design Principles and Considerations for Configuring VMware vShield in Service Provider Environments


Refer to the following product documents, available on the EMC online support website:

EMC UIM/P Software Installation and Configuration Guide


Refer to the following vendor implementation guides:

Windows Server Library: Active Directory Certificate Services

Windows Server Library: Configure Certificate Autoenrollment

VMware Knowledge Base: Installing vCenter Server 5.1 Best Practices

VMware Knowledge Base: vCenter Single Sign-On FAQ

VMware Knowledge Base: Implementing CA signed SSL certificates with vSphere 5.1

VMware Knowledge Base: Deploying and using the SSL Certificate Automation Tool

Refer to the following vendor hardening guides:

VMware vSphere 5.1 Hardening Guide

VMware vCloud Director Security Hardening Guide

Cisco Guide to Securing Cisco NX-OS Software Devices

Available from EMC

EMC VNX r31.5 Security Configuration Guide on VNX for Block

EMC Configuring and Using the Audit Tool

White papers

Product documentation

Vendor implementation guides

Vendor hardening guides

http://technet.microsoft.com/en-us/library/cc770357(v=ws.10).aspx

http://technet.microsoft.com/en-us/library/cc731522.aspx

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2021202



http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2034833

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2034833

http://kb.vmware.com/selfservice/documentLinkInt.do?micrositeID=&popup=true&languageId=&externalID=2041600

http://kb.vmware.com/selfservice/documentLinkInt.do?micrositeID=&popup=true&languageId=&externalID=2041600

http://communities.vmware.com/docs/DOC-22981

http://www.vmware.com/resources/techresources/10138

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/guide_c07-665160.html

Chapter 9: References



184

Available from VCE

VCE Vblock Systems Security Guide – Configuration

VCE Vblock Systems IOS-NX-OS Security Standards Baseline

VCE Vblock Systems UCS Security Baseline Standards

VCE Virtual Environment Security Standards Baseline

10 Appendix A

This appendix contains documentation that was created during the course of integrating the procedures in this guide with other solutions.

Red Hat Enterprise Linux integration with Active Directory

Procedure: Preparing AD for RHEL clients 1. Ensure that the role service Identity Management for UNIX is installed on each

domain controller that will authenticate Red Hat Enterprise Linux (RHEL) users and that the Password Synchronization option is not selected, as shown in Figure 157.

Figure 157. Identity Management for UNIX role in a domain controller’s Roles configuration page

2. Once installed and the system has rebooted, stop and disable the Server for NIS service, as shown in Figure 158.

Windows Server 2008 R2 SP1 Component

Chapter 10: Appendix A



186

Figure 158. Server for NIS Properties window

3. Open Windows Firewall Advanced Settings and disable the five inbound firewall ports created during the installation by right-clicking and selecting Disable for the two Portmap for UNIX, and three Server for NIS entries, as shown in Figure 159.

Figure 159. Inbound Rule view of Windows Firewall Advanced Settings showing the five rules that need to be disabled

4. In DNS, create a Reverse Zone file in the DNS for each IP Address space that this server will be resolving DNS records for, such as 192.168.10. or 172.16-31., as shown in Figure 160.




Figure 160. DNS Manager view showing reverse lookup zones

5. Ensure that the A records for domain controllers and RHEL systems have the PTR checkbox selected so that reverse DNS lookups can be performed successfully, as shown in Figure 161.

Figure 161. Showing the PTR update checkbox on a RHEL A record

6. Using the Active Directory User and Computers snap-in, create a new UNIX Users group, rhelusers and set the UNIX GID by going to the “UNIX Attributes” in the properties of this new group, and selecting the NIS Domain, as shown in Figure 162. Keep the default GID, and click OK.




188

Figure 162. View of UNIX Attributes tab in rhelusers group properties page

7. All users that log into RHEL systems need to have their UNIX attributes set in the active directory. To do this, go to the UNIX Attributes in the properties of each user and select the NIS Domain. This should be the same as your NetBIOS domain and keep the defaults for everything accept the group. If only one UNIX group was created in step 6, this defaults to that group; otherwise, if more than one group exists, you must manually select that group as it may not be selected for you by default. Also add those groups to the user’s Member Of tab, as shown in Figure 163.

Figure 163. UNIX Attributes view of a user account properties and group membership




Procedure: Integrating RHEL 1. Create a DNS record for the new RHEL system:

dnscmd /RecordAdd cork.lab.esg.local rhel-63 /CreatePTR A

192.168.100.10

2. Add the new RHEL system to Active Director:

dsadd computer "CN=rhel-

63,CN=Computers,DC=cork,DC=lab,DC=esg,DC=local"

3. Using the Active Directory User and Computers snap-in, set the NIS Domain (should be the same as the NetBIOS name, for example, short name) and IP Address of the system.

4. Configure the SPN (Service Principal Name) for new RHEL system:

setspn -A host/[email protected]

rhel-63

5. Execute the following command to configure the server principal name for the host or service in Active Directory Domain Services (AD DS) and generate a .keytab file that contains the shared secret key of the service:

ktpass /princ host/rhel-

[email protected] /out C:\rhel-

63.keytab /crypto all /ptype KRB5_NT_PRINCIPAL -desonly

/mapuser CORK\RHEL-63$ +rndPass

6. Copy the newly created Kerberos 5 keytab file to the new RHEL system.

RHEL preparation for integration with AD

Ensure that the following RPM modules are installed using the following command:

yum list installed | grep <name>

krb5-libs.x86_64

krb5-workstation.x86_64

pam_krb5.x86_64

oddjob-mkhomedir.x86_64

Procedure: Steps for integrating RHEL 1. Ensure that NTP file, /etc/ntp.conf, is configured to use the Active Directory

server as the time source as shown below (changing highlighted areas relevant to the domain being implemented):

# For more information about this file, see the man pages

# ntp.conf(5), ntp_acc(5), ntp_auth(5), ntp_clock(5),

ntp_misc(5), ntp_mon(5).

driftfile /var/lib/ntp/drift

# Permit time synchronization with our time source, but do

not

# permit the source to query or modify the service on this

system.

restrict default kod nomodify notrap nopeer noquery

restrict -6 default kod nomodify notrap nopeer noquery

Red Hat Enterprise Linux 6.3 configuration




190

# Permit all access over the loopback interface. This could

# be tightened as well, but to do so would affect some of

# the administrative functions.

restrict 127.0.0.1

restrict -6 ::1

# Use public servers from the pool.ntp.org project.

# Please consider joining the pool

(http://www.pool.ntp.org/join.html).

server corkdc01.cork.lab.esg.local

# Enable public key cryptography.

#crypto

includefile /etc/ntp/crypto/pw

# Key file containing the keys and key identifiers used when

operating

# with symmetric key cryptography.

keys /etc/ntp/keys

If you make changes to the NTP configuration ensure that you restart the ntpd daemon to have the changes take effect.

2. Edit the /etc/krb.conf file to point to the Active Directory domain controller as show below (changing highlighted areas relevant to the domain being implemented):

[logging]

default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

default_realm = CORK.LAB.ESG.LOCAL

dns_lookup_realm = false

dns_lookup_kdc = false

ticket_lifetime = 24h

renew_lifetime = 7d

forwardable = true

[realms]

CORK.LAB.ESG.LOCAL = {

kdc = CORKDC01.CORK.LAB.ESG.LOCAL

admin_server = CORKDC01.CORK.LAB.ESG.LOCAL

}

[domain_realm]

.cork = CORK.LAB.ESG.LOCAL

cork = CORK.LAB.ESG.LOCAL

3. Configure the RHEL system authentication component by running the system-config-authentication command, select LDAP as the User Account Database and on the Advanced Options tab, check the box Create home directories on the first login.




4. Edit the file /etc/sssd/sssd.conf to enable Kerberos5, GSSAPI encrypted queries to LDAP (Active Directory) as shown below (changing areas in bold relevant to the domain being implemented):

[domain/default]

ldap_id_use_start_tls = false

cache_credentials = true

krb5_realm = CORK.LAB.ESG.LOCAL

krb5_server = CORKDC01.CORK.LAB.ESG.LOCAL

id_provider = ldap

auth_provider = krb5

chpass_provider = krb5

krb5_kpasswd = CORKDC01.CORK.LAB.ESG.LOCAL

krb5_canonicalize = false

enumerate = false

access_provider = ldap

ldap_sasl_mech = GSSAPI

ldap_sasl_authid = host/rhel-

[email protected]

ldap_schema = rfc2307bis

ldap_user_object_class = user

ldap_user_home_directory = unixHomeDirectory

ldap_user_principal = userPrincipalName

ldap_user_name = sAMAccountName

ldap_group_object_class = group

ldap_access_order = expire

ldap_account_expire_policy = ad

ldap_force_upper_case_realm = true

ldap_disable_referrals = true

ldap_uri = ldap://corkdc01.cork.lab.esg.local/

ldap_search_base = DC=cork,DC=lab,DC=esg,DC=local

debug_level = 0

[sssd]

services = nss, pam

config_file_version = 2

domains = default

debug_level = 0

[nss]

[pam]

[sudo]

[autofs]

[ssh]

5. Copy the rhel-63.keytab file to /etc/krb5.keytab.

6. For the newly copied krb5.keytab file, set the set the ownership, mode bits and update SELinux:




192

chown root:root /etc/krb5.keytab

chmod 0600 /etc/krb5.keytab

restorecon /etc/krb5.keytab

7. SSSD needs to be restarted after clearing the logs and existing databases as follows:

service sssd stop

rm -f /var/lib/sss/db/*

rm –f /var/log/sssd/*.log

service sssd start

8. Test the system now by logging in a user that is a member of the rhelusers group.

Pivotal Greenplum Database and PostgreSQL integration with Active Directory

It is important to note that this procedure is to provide a centralized authentication point (single username/password). Specifically, accounts need to exist in both AD and PostgreSQL (including Pivotal™ Greenplum® Database) to use a single password maintained in AD.

To do this, create a role in PostgreSQL using the syntax, create role <username>… where the username is the same as the sAMAccountName AD account attribute.

1. Create a LDAP Bind service account if one does not already exist. (Verify the policy for the communal use of LDAP Bind accounts with your Information Security team, or if one account should be created per LDAP Bind instance—for example, one for EMC RecoverPoint®, another for Pivotal Greenplum Database, and so on.)

2. Ensure you follow the steps outlined in the Standalone or non-AD integrated Certificate Authorities and Procedure: Export the LDAPS certificate for installation on clients sections of this guide before proceeding.

Procedure: Integrating Pivotal Greenplum Database with Active Directory The following files should be present on the Pivotal Data Computing Appliance (DCA):

Root CA Certificate in Base64 PEM format

Subordinate CA Certificate(s) in Base64 PEM format

1. Put the PEM formatted certificate(s) in /etc/openldap/cacerts folder.

cp rootcacert.pem /etc/openldap/cacerts/

cp subcacert.pem /etc/openldap/cacerts/

2. Once the certs are located in /etc/openldap/cacerts/ folder, determine the subject hash value.

cd /etc/openldap/cacerts

openssl x509 -noout -subject_hash -in rootcacert.pem

Integration Overview

Active Directory configuration

Pivotal Greenplum Database 4.2.x configuration




7ea57313

openssl x509 -noout -subject_hash -in subcacert.pem

2ae79a78

3. Link the certificate to the hash value in the /etc/openldap/cacerts/ folder.

ln -s /etc/openldap/cacerts/rootcacert.pem

/etc/openldap/cacerts/7ea57313.0

ln -s /etc/openldap/cacerts/subcacert.pem

/etc/openldap/cacerts/2ae79a78.0

4. Log in as gpadmin and create the file .ldaprc in gpadmin’s home directory with the following content:

#

# LDAP Defaults

#

# See ldap.conf(5) for details

TLS_CACERTDIR /etc/openldap/cacerts

5. Edit the pg_hba.conf file to authenticate via LDAPS by entering the following at the end of the file:

host all all 0.0.0.0/0 ldap

ldapserver=corkdc01.cork.lab.esg.local

ldaptls=1

ldapbinddn=ldapbinduser

ldapbasedn="cn=Users,dc=cork,dc=lab,dc=esg,dc=local"

ldapbindpasswd="SomeComplexNon-memorablePassword"

ldapsearchattribute=sAMAccountName

Note Ensure that the pg_hba.conf file mode bits are set to 0600.

Procedure: Integrating PostgreSQL with Active Directory The following files should be present on the DCA:

Root CA Certificate in Base64 PEM format

Subordinate CA Certificate(s) in Base64 PEM format

1. Put the PEM formatted certificate(s) in /etc/openldap/cacerts folder.

cp rootcacert.pem /etc/openldap/cacerts/

cp subcacert.pem /etc/openldap/cacerts/

2. Once the certs are located in /etc/openldap/cacerts/ folder, determine the subject hash value.

cd /etc/openldap/cacerts

openssl x509 -noout -subject_hash -in rootcacert.pem

7ea57313

openssl x509 -noout -subject_hash -in subcacert.pem

2ae79a78

3. Link the certificate to the hash value in the /etc/openldap/cacerts/ folder.

PostgreSQL 9.x configuration




194

ln -s /etc/openldap/cacerts/rootcacert.pem

/etc/openldap/cacerts/7ea57313.0

ln -s /etc/openldap/cacerts/subcacert.pem

/etc/openldap/cacerts/2ae79a78.0

4. RHEL6 OpenLDAP’s TLS_CACERTDIR should default to /etc/openldap/cacerts; however, it is good practice to follow the same procedure as with the Pivotal Greenplum Database integration by logging in as the postgres user and create the file .ldaprc in the postgres account’s home directory with the following content:

#

# LDAP Defaults

#

# See ldap.conf(5) for details

TLS_CACERTDIR /etc/openldap/cacerts

5. Edit the /var/lib/pgsql/9.x/data/pg_hba.conf file to authenticate via LDAPS by entering the following at the end of the file:

host all all 0.0.0.0/0 ldap

ldapserver=corkdc01.cork.lab.esg.local

ldaptls=1

ldapbinddn=ldapbinduser

ldapbasedn="cn=Users,dc=cork,dc=lab,dc=esg,dc=local"

ldapbindpasswd="SomeComplexNon-memorablePassword"

ldapsearchattribute=sAMAccountName

Note Verify the 9.x in the path to the pg_hba.conf ensure that its mode bits are set to 0600.

RecoverPoint 3.5 integration with Active Directory

It is important to note that this procedure is to provide a centralized authentication point (single username/password). DNS entries are needed for all components that will be integrated into Active Directory.

This outline provides the steps necessary to integrate RecoverPoint into active directory. RecoverPoint Roles will need to be mapped to User Groups within Active Directory using the full (LDAP) Distinguished Name on the RecoverPoint Appliance.

Additionally, the RecoverPoint Appliance (RPA) also needs to have its self-signed certificate replaced with a certificate signed by a trusted certificate authority.

The RPA does not have a way to generate a private key and certificate request, so this will have to be done on another system using OpenSSL version 1.x.

Integration Overview




Procedure: Prepare Active Directory for RecoverPoint integration 1. Create a LDAP Bind service account if one does not already exist. (Verify the

policy for the communal use of LDAP Bind accounts with your Information Security team, or if one account should be created per LDAP Bind instance—for example, one for RecoverPoint, another for Pivotal Greenplum Database, and so on.)

2. Ensure you follow the steps outlined in the Standalone or non-AD integrated Certificate Authorities and Procedure: Export the LDAPS certificate for installation on clients sections of this guide before proceeding.

Procedure: PKI steps for integrating a RecoverPoint Cluster into Active Directory 1. Using OpenSSL, generate the private key and certificate signing request:

openssl.exe req -config openssl.cfg -newkey rsa:2048 -keyout

C:\TEMP\rpa.key -nodes -out C:\TEMP\rpa.csr

2. Convert the private key from X.509 format to RSA PEM format:

openssl.exe rsa -in rpa.key -out rpa.pem

3. Because the same private key and certificate will be used for the entire cluster, you must submit the certificate signing request with the Subject Alt Name attributes for all device DNS Names and IP Addresses:

DNS Name = FQDN of the Cluster Name

(Optional short names) DNS Name = Cluster Name

DNS Name = FQDN of RPA1

(Optional short names) DNS Name = RPA1

DNS Name = FQDN of RPA2

(Optional short names) DNS Name = RPA2

DNS Name = VIRTUAL IP

DNS Name = RPA1 IP Address

DNS Name = RPA2 IP Address

4. For Microsoft Certificate Services, the following command line will submit a certificate request to the Certificate Authority for the RPA’s certificate signing request:

certreq.exe -submit -attrib

"CertificateTemplate:RecoverPointAppliance\nSAN:DNS=rpaclcdp01.cor

k.lab.esg.local&DNS=rpaclcdp01&DNS=rpa05.cork.lab.esg.local&DNS=RP

A05&DNS=rpa06.cork.lab.esg.local&DNS=RPA06&DNS=10.110.75.240&DNS=1

0.110.75.241&DNS=10.110.75.242" rpa.csr rpa.crt

Note The certificate is in Base64 (PEM) format, so no further conversion using OpenSSL is necessary.

Active Directory configuration

RecoverPoint PKI configuration




196

Procedure: Installation of private key and certificate on RecoverPoint The following steps require the use of Installation Manager (boxmgmt) for the installation of the private key and certificate.

1. Using a SSH client such as PuTTY, login into the RPA Virtual address with the boxmgmt credentials, as shown in Figure 164.

Figure 164. Main menu presented upon login to RPA cluster as boxmgmt

2. Select Setup, then Advanced options, and then Security options.

3. Select Change web server certificate, as shown in Figure 165.

Figure 165. Showing security option Change web server certificate to be chosen

4. Enter Y to change the web server certificate, and then N to import by ftp.

5. Open the rpa.pem file in a text editor. Copy the contents and paste into the terminal window, as shown in Figure 166.




Figure 166. Depicting the contents of the rpa.pem file when entered in the terminal

6. Open the rpa.crt file in a text editor. Copy the contents and paste into the terminal window and enter # on a new line, as shown in Figure 167, and press return.

Figure 167. Depicting the contents of the rpa.crt file when entered in the terminal

7. Now we will disable the HTTP service to only allow HTTPS services by selecting Change web server mode, and entering Y to disable the HTTP server, as shown in Figure 168.




198

Figure 168. Showing menu selections to disable HTTP

Note It may take up to two minutes for the server to finish disabling HTTP services. During this process, the HTTPS server may also be unavailable.

8. The last step is to install the Root and any Intermediate Certificate authority certificates into the Client System Certificate store as well as the Java Application Certificate store.

9. If installing the Root and any Intermediate CA certificates into the System Java Keystore (JKS), the password to the keystore is changeit. Keytool is the method for adding these certificates.

To do this for the logged in user, use the Java Control Panel shortcut → Security → Certificates…. Then select the User tab and the Certificate type of Secure Site CA, then Import. You can use all types for the file type and select the Base64 formatted CA certificate.

The CLI examples for adding certificates to the User or System JKS system, found in the Installing Java CA certificates section of this guide, show how to do this system wide.

Procedure: Configure RPA cluster to use LDAP over SSL The following steps provide details on how to configure the RPA Cluster to use LDAPS authentication in Active Directory.

1. Log into the RPA cluster as the security-admin user with the default password security-admin.

2. Select System, then System Settings.

3. Select Users, and then select the LDAP Configuration tab.

a. Enter the following information, as shown in Figure 169:

i Select Enable Active Directory Support

ii Primary LDAP server, corkdc01.cork.lab.esg.local

iii Primary LDAP server port (636 for LDAPS), 636

iv Optionally, Secondary LDAP server

v Secondary LDAP server port (636 for LDAPS)

vi Fully Qualified Bind account Distinguished name

RecoverPoint LDAPS configuration




For example: CN=ldapbind,CN=Users,DC=cork,DC=lab,DC=esg,DC=local

vii Bind account password

b. Select LDAP over SSL for the Directory Access Protocol type and clear the Use certificate from file checkbox .

c. Leave the defaults for Advance Settings.

Figure 169. The RPA System Settings properties showing the configuration entered

d. Click Test configuration to verify the settings are correct.

e. Once confirming the settings are valid, click OK.

4. Next, select the Roles tab to assign the Active Directory group(s) to the various Roles within the RPA:

a. Select Add from the Roles tab

b. Select LDAP User/Group and check either User Name(s) or Group(s), then click From list, as shown in Figure 170 and Figure 171:




200

Figure 170. Add new user properties page

Figure 171. Showing groups that can be selected

c. After selecting the group from Active Directory, you should see the following in the Add New User dialog box, as shown in Figure 172:




Figure 172. Showing completed LDAP group role mapping

d. Click OK when finished adding the Active Directory User/Group.

5. You should now be able to log in with an Active Directory user account.

Chapter 11: Appendix B



202

11 Appendix B This appendix contains a list of the procedures contained in this PSG.

Table of Procedures

Certificate authorities ................................................................................................... 31

Procedure: Deploy the Root CA .......................................................................................... 32

Procedure: Configure Root CA AIA and CDP locations ......................................................... 33

Procedure: Deploy the Subordinate CA .............................................................................. 39

Procedure: Install CA certificate on Subordinate CA ........................................................... 43

Procedure: Create virtual directory for AIAs and CRLs ......................................................... 44

Procedure: Change default behavior of IIS for files with special characters ........................ 45

Procedure: Configure Subordinate CA AIA and CDP locations ............................................. 46

Installing Root and Subordinate CA certificates ............................................................ 51

Procedure: Install Root CA certificate in Windows certificate store ..................................... 52

Procedure: Install Subordinate CA certificate in Windows certificate store ......................... 52

Procedure: Install Root CA certificate in Java certificate key store ....................................... 53

Procedure: Install Subordinate CA certificate in Java certificate key store ........................... 53

Procedure: Remove certificate from Java certificate key store ............................................. 53

Procedure: Submitting a certificate request via web portal ................................................ 55

Procedure: Submitting a certificate request using via CLI ................................................... 56

Procedure: Export the certificate chain .............................................................................. 57

VMware vCloud Suite 5.1 certificates ............................................................................ 58

Procedure: Create a certificate template for the vSphere platform ..................................... 61

Procedure: Create CLI certificate request with embedded SAN attributes ........................... 64

Procedure: Install certificate on ESXi host ......................................................................... 66

Procedure: Using the vCenter Certificate Automation Tool ................................................. 67

Procedure: Installing vCenter Single Sign-On STS certificate .............................................. 69




VMware vCloud Networking and Security ...................................................................... 70

Procedure: Create a certificate request in vShield Manager ............................................... 70

Procedure: Import the CA-signed certificate in vShield Manager ........................................ 71

VMware vCloud Director SSL certificates ....................................................................... 72

Procedure: Create certificate requests for vCloud Director ................................................. 72

Procedure: Install the certificate chain in the vCloud Director keystore .............................. 73

Procedure: Install SSL certificates in vCloud Director ......................................................... 75

Procedure: Run the vCloud Director initial configuration script .......................................... 75

Procedure: Replacing vCloud Director SSL certificates post-installation ............................. 76

Procedure: Create a JCEKS keystore ................................................................................... 77

Procedure: Import a JCEKS keystore ................................................................................... 78

Cisco UCS certificates ................................................................................................... 79

Procedure: Create a key ring through the UCS Manager CLI ................................................ 80

Procedure: Create a key ring through the UCS Manager GUI ............................................... 80

Procedure: Convert the chain to PKCS7S ........................................................................... 83

Procedure: Install the chain certificate through the UCS Manager CLI ................................ 83

Procedure: Install the chain certificate through the UCS Manager GUI ................................ 84

Procedure: Install the SSL certificate through the UCS Manager CLI ................................... 84

Procedure: Install the SSL certificate through the UCS Manager GUI .................................. 85

Procedure: Configure Communication Services through the UCS Manager CLI .................... 86

Procedure: Configure Communication Services through the UCS Manager GUI ................... 87

EMC UIM/P SSL certificate ............................................................................................ 88

Procedure: Change the default SSL utility private key strength .......................................... 88

Procedure: Update the path to the Homebase configuration file ........................................ 88

Procedure: Create a certificate request .............................................................................. 88

Procedure: Install the CA issued UIM/P SSL certificate ...................................................... 90

EMC VMAX SSL certificates for Unisphere ..................................................................... 91

Procedure: Create a new Solutions Enabler keypair and certificate request ........................ 92

Procedure: Create a new Unisphere for VMAX keypair and certificate request .................... 94

Procedure: Install the Unisphere for VMAX SSL certificate ................................................. 95




204

EMC VNX Unisphere SSL certificates ............................................................................. 95

Procedure: Generate a new key pair (OpenSSL) ................................................................. 95

Procedure: Change the Control Station private key strength .............................................. 96

Procedure: Create a certificate request .............................................................................. 96

Procedure: Install the signed Control Station SSL certificate .............................................. 96

Procedure: Replace the VNX storage processor self-signed certificate ............................... 97

Procedure: Import the new certificate ................................................................................ 99

Procedure: Import a new certificate through SecureCLI ...................................................... 99

Microsoft Active Directory—LDAP over SSL .................................................................. 101

Procedure: Create a LDAPS certificate template for AD CA ................................................ 102

Procedure: Enroll domain controller LDAPS certificate ..................................................... 109

Procedure: Export the LDAPS certificate for ADDS ............................................................ 111

Procedure: Import the LDAPS certificate to ADDS ............................................................. 113

Procedure: Export the LDAPS certificate for installation on clients ................................... 116

Procedure: Create LDAPS certificate template for non-AD integrated CA ........................... 118

Procedure: Generate an LDAPS certificate for non-AD CA ................................................. 119

Integrated Windows authentication and service accounts ........................................... 120

Procedure: Grant service account rights .......................................................................... 122

Procedure: Set up vCenter Server database ODBC DSN connections (64-bit) ................... 126

Procedure: Configure vCenter Server and Update Manager services ................................. 131

VMware vCenter Single Sign-On: RBAC ....................................................................... 135

Procedure: Configuring vCenter Single Sign-On administrative groups ............................. 135

Procedure: Configuring vCenter Single Sign-On default domains ..................................... 136

VMware vCloud Director: LDAP and Kerberos .............................................................. 137

Procedure: Configure LDAP over SSL (Microsoft Active Directory) ..................................... 137

Procedure: Configure Kerberos ........................................................................................ 141

Authentication integration with VMware vSphere ESXi host ........................................ 145

Procedure: Add the ESXi hosts to the Active Directory...................................................... 145




EMC Unisphere for VMAX authentication ..................................................................... 149

EMC VNX LDAP authentication over SSL ...................................................................... 151

Procedure: Combine the LDAPS and chain certificates into a single file ........................... 151

Procedure: Configure the LDAP Domain on a VNX array .................................................... 152

Authentication integration with TACACS+ ................................................................... 157

Procedure: Configure TACACS+ ........................................................................................ 159

Procedure: Integrate UCS Manager GUI and CLI with TACACS+ ......................................... 159

Procedure: Add a new key ring ........................................................................................ 160

Procedure: Add secondary or subsequent TACACS+ servers ............................................ 160

Procedure: Make TACACS+ the primary authentication source ......................................... 161

Procedure: Change the role policy for remote user ........................................................... 161

Procedure: Change the authentication source type .......................................................... 162

Procedure: Create a TACACS+ provider group .................................................................. 162

Procedure: Configure TACACS+ authentication servers .................................................... 165

Procedure: Create user accounts to enable external authentication ................................. 167

Procedure: Assign user privileges ................................................................................... 168

Procedure: Export the UCS Manager certificate ................................................................ 170

Procedure: Install certificates in UIM/P ........................................................................... 171

Procedure: Configure discovery ....................................................................................... 172

PKI certificate verification ........................................................................................... 175

Procedure: Verify the certificate chain ............................................................................. 176

Authentication verification .......................................................................................... 177

Procedure: Test LDAPS connectivity ................................................................................ 178

Red Hat Enterprise Linux integration with Active Directory .......................................... 185

Procedure: Preparing AD for RHEL clients ........................................................................ 185

Procedure: Integrating RHEL ............................................................................................ 189

Procedure: Steps for integrating RHEL ............................................................................. 189

Pivotal Greenplum Database and PostgreSQL integration with Active Directory .......... 192

Procedure: Integrating Pivotal Greenplum Database with Active Directory ....................... 192




206

Procedure: Integrating PostgreSQL with Active Directory .................................................. 193

RecoverPoint 3.5 integration with Active Directory ...................................................... 194

Procedure: Prepare Active Directory for RecoverPoint integration ..................................... 195

Procedure: PKI steps for integrating a RecoverPoint Cluster into Active Directory ............. 195

Procedure: Installation of private key and certificate on RecoverPoint ............................. 196

Procedure: Configure RPA cluster to use LDAP over SSL ................................................... 198

Documents

EMC Integration of PKI and Authentication Services for ... · EMC INTEGRATION OF PKI AND AUTHENTICATION SERVICES FOR ... 11 Proven Solutions Guide ... EMC Integration of PKI and Authentication