vCloud Director and SSPI Authentication

vCloud Director 5.1 brings Single Sign On (SSO) functionality which simplifies the way users log in to the vCloud Director portal. There is some confusion with vCenter SSO so let me first state all the SSO options:

  • When vCloud Director is integrated with vSphere Lookup Service (System > Administration > System Settings > Federation menu) then vCloud Administrators can use vCenter SSO for authentication. The login screen is replaced with vSphere Client login screen.
  • The tenants can self configure SAML identity provider to enable SSO for their user access to the portal. This can be done by Organization Administrator in the Administration > Settings > Federation menu. Currently supported providers are OpenAM and Active Directory Federations Services (ADFS). This option is ideal for Public Clouds when there is no connectivity between vCloud Director cells and customers LDAP servers.
  • The vCloud Administrator can enable Microsoft proprietary Security Support Provider Interface (SSPI) to simplify authentication with Active Directory for the organization users.

The third option is not documented in any way so i decided to research it and write down how to get it working.

Following diagram shows the authentication process:


Although in the diagram vCloud Director (VCD) does not talk directly to Active Directory server it is still necessary there is direct connectivity between the cells and AD servers, because group membership information is retrieved from AD by the cells. The client must be logged into the domain and use browser that enables integrated authentication. The client also has to use the same DNS server as the active directory. This implies that the SSPI authentication is valid only for private cloud use case.

Here are the steps to get it working:

  1. For given organization enable custom LDAP with kerberos authentication. Here is a nice detailed article how to do it.
  2. In AD create a group for the users and import it to vCloud Director and assign a vCloud Director role.
  3. Again on the AD server in Active Directory Users and Computer create a computer account for vCloud Director. I created account VCLOUD under Computers.
  4. Map this account to the Security Principal Name (SPI) which has following form: HTTP/<vCloud FQDN>@AD REALM. This can be done with setspn command from the AD server:

    setspn -a HTTP/ VCLOUD$

    (note the $ character at the end of the Computer account)

  5. Now we need to export the encryption key used by the Kerberos token issuer to encrypt the token and upload it to vCloud Director. This can be done from command line (again on the AD server) with ktpass utility:

    ktpass -princ HTTP/<VCD FQDN>@AD REALM -pass * -mapuser <computer account>$@domain -out HTTP.keytab -ptype KRB_NT_PRINCIPAL /crypto RC4-HMAC-NT

    in my case I used:
    ktpass -princ HTTP/ -pass * -mapuser VCLOUD$@FOJTA.COM -out VCLOUD.HTTP.keytab -ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT

    type any password and confirm the reset.


  6. Now we need to take the created keytab file (VCLOUD.HTTP.keytab) and use it for the SSPI configuration. In the vCloud Director organization Custom LDAP configuration go to the SSPI section, enable it, enter the Service Principal Name from step #4 and upload the keytab file from step 5#.
  7. To get the single sign on experience some settings must be done in the client web browser:
    • Internet Explorer: go to Internet Options, Security, Local intranet, Sites and add vCloud Director FQDN to the zone trusted sites. Then edit the security level for this zone by clicking Custom Level button and at the bottom of the list in User Authentication Logon section enable Automatic logon only in Intranet zone.
    • Firefox: open about:config URL and search for network.negotiate and add vCloud Director FQDN to the network.negotiate-auth.trusted-uris.

7 thoughts on “vCloud Director and SSPI Authentication

  1. Tomas, in your examples it should be “KRB5_NT_PRINCIPAL” not “KRB_NT_PRINCIPAL”.
    The “5” is missing 😉

    ktpass -princ HTTP/@AD REALM -pass * -mapuser $@domain -out HTTP.keytab -ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT
    in my case I used:
    ktpass -princ HTTP/ -pass * -mapuser VCLOUD$@FOJTA.COM -out VCLOUD.HTTP.keytab -ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT

  2. Hi Tomas,

    I have set it up completely. I have couple of queries since this is new thing for me.

    1) Why did we create a computer account VCLOUD in step # 3

    2) What is the purpose of setspn -a HTTP/ VCLOUD$ in step # 4

    3) How do I login using SSPI authentication? In one of the blog I read that if I open the URL “”(VCD FQDN) , we should be automatically logged onto VCD.

    4) Do I need to have the physical computer by name “VCLOUD”? and typing the URL “” will logs me into VCD automatically?

    Please advice.

    I’m very much in need of this info, Your reply will be much appreciated..


    1. Re 1) We need to create the account in order to have a shared secret for the token exchange. The client asks the AD for authentication to the http service (step #3 in the chart).
      Re 2) Mapping of the account to http service.
      Re 3) Yes you should be logged in directly to the website without a need to type login credentials. The client (browser) needs to be in a domain, logged in into the domain and the browser needs to support automatic login (step #7).
      Re 4) No need for physical computer.

  3. Hi Tomas,

    great article, thanks.
    Can you confirm the authentication workflow and how and when the keytab file is used during the process?

    My understanding is the following:
    1- Client access VCD url
    2- VCD responds with a www authenticate
    3- Client requests a kerberos token to AD
    4- AD provides kerberos token to VCD
    5- Client provides token to VCD ???
    6- VCD authenticates the client???

    What am I missing? how and when is the key tab being used? How the mapping between the http service endpoint and the keytab file is validated?


  4. Hi Tom,

    I had a few more readings and this is my updated version:

    1- Client access VCD url
    2- VCD responds with “www authenticate request to: HTTP/”
    3- Client requests a kerberos token to AD to authenticate to
    4- AD lookup for an spn with that record and if found generates the auth token and encrypts it using the mapped AD account VCLOUD$
    4- AD provides kerberos token to Client
    5- Client provides token to VCD
    6- VCD uses keytab file to decrypt token and if succesfull authenticates the client

    Is this correct?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s