Objective 1.3: Enable SSO and Active Directory Integration
April 8, 2015
Under this objective we have the following topics to cover
- Configure / Manage Active Directory Authentication
- Configure / Manage Platform Services Controller (PSC)
- Configure / Manage VMware Certificate Authority (VMCA)
- Enable / Disable Single Sign-On (SSO)
- Identify available authentication methods with VMware vCenter
Just like before we will try to cover this in order.
Configure / Manage Active Directory Authentication
When you are logged into the ESXi host directly or are in the Web Client and go to the settings, you can set the host up to register in Active Directory, but this is not the same as being able to use AD as an authentication source in SSO. To set that up we will need to make sure we login as an administrator in the SSO domain. Then do the following:
- From the Home Screen, Click on Administration
- On the Navigator panel, click on Configuration under Single Sign On
- Then Click on Identity Sources in the center
- This will be what you see
- Fill out the appropriate source (AD or otherwise) and then click on Test Connection
- If successful, then go ahead and add it
- Once added, you can now choose the AD domain as a source for your users and groups
Configure / Manage Platform Services Controller (PSC)
Starting with vSphere 6, there has been a bit of a shakeup as to the services and how they can be deployed in vCenter. Before, the major services to contend with were SSO, Web Client, Inventory Service, and vCenter Server. Now though, there are two main types of groups of services are vCenter Server and Platform Services Controller. They are busted out like the following:
- Platform Services Controller = VMware Single Sign-On, VMware License Server, Lookup Service, Certificate Authority, Certificate Store
- vCenter Server = vCenter Server, Web Client, Inventory Service, Auto Deploy, Dump Collector, Syslog Server
You cannot break these services up into different servers now. When you install vCenter Server, you get all these features. You have the ability of an embedded installation, or a distributed vCenter Server System Configuration. With the embedded install, the Platform Services Controller and the vCenter Server are installed on a single machine. A single PSC is suitable for about 8 vCenter machines or services. When you go larger you will need to add additional servers. With a Distributed vCenter Server System Configuration, you will need to first deploy the PSC on a machine and then you can deploy your vCenter Server. Once you select one particular deployment method, it can’t be undone.
The first thing you will need to do when configuring a fresh install (and you have chosen just the Platform Services Controller option) is choose and create a SSO domain. If this is an additional PSC, then you would join a vCenter Single Sign-On domain. Then enter a password for the administrator, and a Site Name. The next screen will be to accept the default ports or chose new ones. Then go through the next screens of Destination Paths and then confirmation screen. The screens will be roughly the same for the appliance with a few added ones, such as choosing your datastore and network settings.
As far as managing the PSC, most has to do with your setup, and making sure that you setup the proper deployment method to begin with. After that, you can do things such as load balance and make your PSCs Highly available. The way you do this will depend a lot what kind of servers you deployed. Was it the appliance or the Windows machine. There are many different methods to do this, and you can even mix and match depending on customer requirements, especially since the new appliance is capable of Linked Mode in vSphere 6. Then of course you can configure the individual services making up the PSC.
Configure / Manage VMware Certificate Authority (VMCA)
Generally you won’t need to do any sort of certificate management in vSphere 6. The reasoning behind this is that the certificates that the VMCA issues are valid for 10 yrs. However, occasionally you might run into a situation where the user needs to either comply with some sort of HIPAA compliance or a user that got over zealous.
So we know that previous versions of VMware used self-signed certificates -this new version of vSphere now has a full on Certificate Authority. What does this mean? This means that we can now generate our own certificates or we can configure this as a subordinate certificate authority to use a third-party certificate such as GoDaddy or some other recognizable authority. When you do need to change certificates for some reason, you can do so using the certificate manager utility. On the Windows machine you just pull up an Admin CMD Prompt and type in certificate-manager. In order to make the VMCA a subordinate CA you will need to do the following steps.
Log into the PSC and using openssl, generate a certificate request.
openssl genrsa –out c:\certs\psc001.key 2048
openssl req –new –key c:\certs\psc001.key –out c:\certs\psc001.csr
- Submit the request to a CA. Use the Subordinate CA template for the request
- Download the cert in Base64 format; save it to c:\certs
- Wait at least 24 hrs (VMCA requires a cool off period J )
- Run certificate manager again from c:\program files\vmware\vCenter Server\bin for Windows and /usr/lib/vmware-vmca/bin/certificate-manager for the Appliance
- Choose option 2: Replace VMCA Root certificate with Custom Signing Certificate and replace all Certificates
- Answer all questions
- When asked to provide a valid customer certificate for root, enter the path for the cert you got earlier
- When asked for the customer key or root, provide the path to the .key file generated earlier
- Enter Y to replace the cert
- Add the cert to a Windows Group Policy as an intermediate CA
Enable / Disable Single Sign-On
This isn’t possible that I know of. I am reaching out for clarification on it, but at least in 5.5 VMware posted the following:
Can I disable SSO 5.5 in vCenter Server?
No, you cannot disable SSO 5.5 in vCenter Server 5.5. This is similar to vSphere 5.1.
Identify available Authentication methods Available with VMware vCenter
There are a number of authentication methods you can employ with vCenter. You can log in with SSO or with a local user for the vCenter. If you do log in as root with the appliance, you are no longer are not able to see any of your objects in the environment. The full listing of Identity sources available for use is as follows:
Active Directory versions 2003 and later. You can specify a single domain as an identity source. If you have child domains, they must be trusted
Active Directory over LDAP. This is included for backwards compatibility with the vCenter SSO service included with 5.1
OpenLDAP versions 2.4 and later
Local OS Users. These are the users local to whatever OS the vCenter Server is running on. This only exists in Basic SSO server deployments and not in multiple vCenter SSO instances. This is shown as “localos” in the web client
vCenter Single Sign-On system users. Exactly one system identity source named vsphere.local is created when you install vCenter. This is shown as vsphere.local in the web client (obviously) J
At any time only one default domain exists. If you do no belong to that one, you will need to add your domain to the username for it to work. And finally to add or configure identity sources you will need to be a SSO administrator. Here is a screenshot of where to find the identity sources for a refresher. And stay tuned for the next new set of objectives.