Monday 15 October 2012

Integrating vCloud Director with vCenter Single Sign-On (SSO)


vCloud Director (vCD) and vShield Manager are two components which don't connect to SSO automatically. After installation, you need to point them to SSO manually for authentication.

We are considering now vCD integration with SSO since this is more complicated than vShield integration. vShield integration is simple and start forward.

vCD can has two types of integration with SSO:

  • SSO integration for System Admin authentication (this type of integration supports all types of identity providers in SSO)
  • SSO integration for Client authentication (this type of integration supports ONLY OpenLDAP as identity provider. Therefore we won't be covering it here)

After installing vCD Cell you need to browse vCD portal and navigate to System > Administration > Federation.
From there you have two parameters to configure:

  1. Register vCD with SSO server (this will enable other components such as vCenter and vSphere Web client to discover vCD and manage it)
  1. Use vSphere Single Sign-On (this option will force vCD System Admins to authenticate using SSO and not vCD users).

That's it !! Now vCD is integrated with SSO for System Admin authentication. Test it …. Ops !!! Its not working.

There are many tweaks to  be done for vCD-SSO integration to work.
 
1.        You need to import SSO users in vCD as SAML users. Those users should be in UPN format even if they are part of default identity providers. Navigate to Administration > Users > Import.
Note: In vShield Manager, you need to import the users in UPN format similar to vCD case
 
2.        As we mentioned earlier, when the client tries to open vCD portal, the page will be redirected to vSphere Web Client to authenticate. Accordingly, vCenter will pass the token to vCD which is used to verify the user against SSO.

For the redirection to work properly, below is a list of prerequisites:

a. vSphere Web Client should be published to internet with CA-Signed SSL Certificate. In case the certificate isn't signed, the redirection will be terminated by the server with SSL Security Error.
b. vSphere Web Client should be installed with custom ports (80 & 443). The reason is that redirection from vCD to vSphere Web Client is happening on port 80 & 443 (https://<web-client-fqdn>/vsphere-client). The default installation for  Web Client is using ports 9090 & 9443. Another option is configure static PAT on your internet gateway to redirect from port 80 to 9090 and 443 to 9443.
c. When vSphere components are registering with SSO server, they will register using their FQDNs (this includes vCD, vShield, vCenter Server, vCenter Inventory Service, and vSphere Web Client). Now when the redirection takes place, the URL of web client will be using its fqdn (https://<web-client-fqdn>/vsphere-client). Therefore, the FQDN of web client server should be resolvable publically. But this has a challenge!!!

Usually, you will configure your web client server to be part of domain (e.g. ehdfcloud.int). In this case the FQDN of the web client server will be, for example, vmweb.ehdfcloud.int. This FQDN won't be resolvable from internet since its local one. So how to fix this ???

The proper way of doing it is to change the DNS suffix of web client server name only, while keeping it member of domain.
Important: After this change, you need to unregister/register vCD from SSO.

Here are two major benefits I noticed after integration between SSO and vCD.
 
1.        Correlation between vCD logs and vSphere Logs: With 5.1, you can see the logs/tasks occurred on vCD cell and the corresponding logs/tasks occurred on vSphere infrastructure using one console on vCD Portal.

On vCD Portal navigate to System > Logs > Tasks tab > Double-Click on Any Task. You will see two tabs:

a. Task Details: This represents the details occurred on vCD Cell
b. vSphere Tasks: This represents the corresponding details occurred on vSphere Infrastructure.
2.        Open in vSphere Web Client: Using this feature, you can open any vCD object using vSphere Web Client directly. This simplifies the manageability of vCD objects from vSphere Web Client. No more searching for vCD objects in vSphere Client/Web Client. Once the client selects "Open in vSphere Web Client", the browser will open a new window for vSphere Web Client listing the selected object. You won't login again to vSphere Web Client due to SSO.

vCD objects can be vCenter Server, Resource Pools, Hosts, Datastores, Switches, VMs, vApps, Networks, etc.
In case you upgraded from vCD 1.5 to vCD 5.1, you will find this feature disabled (greyed). To enable it navigate to System > Manage and Monitor > vSphere Resources > vCenters > Right-Click vCenter Server > Properties. You need to type vSphere Web Client URL manually or use vSphere Services to provide the URL.
Important TIP: Assume that SSO Server went down. In this case you won't be able to login to vCD since the authentication through SSO isn't working. Similarly, if you do misconfiguration while integrating SSO with vCD (such as enabling SSO authentication on vCD and logging out without importing users), in this case you won't be able to login to vCD. There are many other errors which can cause this failure.

So what is next??? Do you need to rebuild your vCD server?????

No, there are two workarounds which I found while searching on blogs:

  1. Browse vCD URL and add "/login.jsp" at the end of the URL. For example, https://vcd.testdomain.com/cloud/login.jsp. This will bypass SSO redirection to web client and the client will land directly on vCD login page. In this case, vCD local accounts can authenticate and browse. Then you can fix your problem by correcting vCD configuration.
  2. You can run the following SQL script against vCD DB which will disable SSO/vCD integration. In this case, clients can browse and login to vCD using vCD local accounts. For MSSQL DB, here is the script:

UPDATE [vcloud].[dbo].[identity_provider]
SET [is_enabled] = '0'
WHERE provider_type = 'SAML'
GO

9 comments:

  1. Great Post. FYI... I was getting the SAML error when trying to logon even though SSO worked to vCS. I added vCD admins via a group in SSO and was generating the error. Once I added the users individually it worked. Have you tested this yet?

    ReplyDelete
    Replies
    1. Also, do you know of any SAML documentation for vCenter SSO? I want to use it for our organizations as well if possible.

      Delete
    2. 1. To make it working using group, you need to import the group in vCD in the following format: DomainName\GroupName. It won't work if you import in UPN format (GroupName@DomainName). For example you need to import the group as System-Domain\TestGroup.

      2. Regarding Documents, I don't have something specific. Only VMware KBs and blogs. But try to see my blogs about vCenter SSO. I wrote quite good details which can clarify the basics.

      Delete
    3. Thanks for the update. I have the system organization working off of the group format now.

      I'm not sure how to create the SAML connection for all of our other organizations though. I tried copying the system one from the DB but it's not complete and gives me an error page on load. I found a URL on how to connect it to an OpenAM SSO system. I may try to get it setup so I can see the SAML XML format and go from there.

      Delete
  2. Clean and clear explanation of Integrating vCloud Director with vCenter Single Sign-On (SSO) .Liked your blog "Virtualization Technology"

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Hi there,

    You mentioned that the Redirect from the vCloud to Web Client requires a CA Signed Certificate. I have no experience with certs so I was wondering how can we get the vcloud director to work with self signed certificate. Currently I am getting the invalid certificate error.

    Appreciate your help.

    Mohit

    ReplyDelete
  5. Such a lovely blog and well crafted, short and crisp.I was really looking for some informative blog like this one for research purpose on single sign on solutions. Thanks for the shoot out.Keep blogging.

    ReplyDelete