vRA – How to integrate ADFS SSO

Recently I needed to integrate a vRA environment with Active Directory Federated Services (ADFS) so the same Single Sign On experience could be delivered across various products for the customer. This required a good cooperation with the AD team in order to set it up correctly.

Below an overview how to get it working and the steps we went through 🙂

Resources

A good point to start are the VMware resources regarding the setup of Active Directory Federated Services with vRA:

Prerequisites

Next to knowing what needs to be done on the vRA side, you need to know how the ADFS side is set up.

  • In our case ADFS SSO was configured to use the e-mail address for authentication, hence we need to map the E-Mail address LDAP attribute to the outgoing claiming type used. Example:
    • LDAP: E-Mail address – Outgoing: E-Mail Address
    • In your specific use case / environment it might very well be that another LDAP attribute needs to be mapped to the ‘E-Mail address’ outgoing type (e.g. LDAP: SAM – Outgoing: E-Mail Address).
  • ADFS SSO Identity Provider Metadata XML
  • vRA SAML Metadata XML, these are always Tenant specific and of the following format:
    • E.g.: https://<YOUR-VRA-FQDN>/SAAS/t/<Tenant_Name>/API/1.0/GET/metadata/sp.xml
    • Can be found via: Log on to your vRA Tenant, go to ‘Administration‘ followed by ‘Directories Management‘ and you select ‘Identity Providers‘. Afterwards Click on ‘Add Identity Provider‘ and choose ‘Create Third Party IdP‘, scroll all the way to the bottom and you’ll see your vRA Tenant’s Metadata XML Link:
      Schermafbeelding 2019-06-17 om 12.23.48
  • Make sure to allow 443 communication between your vRA environment & ADFS in order to be able to add & resolve the MetaData XML URLs. Another option is to just copy-paste the content of the MetaData XML or save the file(s).
  • An Active Directory configured in vRA

ADFS Side Setup

Set up Relying Party Trust

First we need to setup a Relying Party Trust on the ADFS environment. To do this you can basically follow the procedure outlined by Microsoft for this and keep everything at default except modifying the ‘Data Source’ to your needs:

Below a short overview:

  1. Go to ‘Server Manager’ – ‘Tools‘ – ‘AD FS Management
  2. Under ‘Actions‘ select ‘Add Relying Party Trust’
  3. Follow the wizard, leave everything as default
  4. Under ‘Select Data Source‘ add your vRA Tenant’s MetaData XML URL or provide the file.
    This URL can be found in the ‘Prerequisites‘ section earlier in this blogpost.
  5. Complete the wizard

Set up Claim Rules

Next up is setting up the Claim Rules in order to issue a set of tokens. According to the Microsoft documentation, the Role of Claim Rules can be defined as follows:

The overall function of the Federation Service in Active Directory Federation Services (AD FS) is to issue a token that contains a set of claims. The decision regarding what claims AD FS accepts and then issues is governed by claim rules.

For vRA we will be setting up 2 Rules. Let’s start!

Rule 1:

  1. Click ‘Add Rule
  2. Choose the following template: ‘LDAP Attributes as Claims template
  3. Give the Claim Rule a name and set the Attribute Store to ‘Active Directory‘.
  4. Make sure to setup the correct mapping for your environment. In our use case the following was required: ‘LDAP Attribute – E-Mail-Addresses  | Outgoing Claim Type – E-Mail Address‘. An example can be found below
    Schermafbeelding 2019-06-15 om 20.17.02

Rule 2:

  1. Click ‘Add Rule
  2. Choose the following template: ‘Send Claims Using a Custom Rule
  3. Give the Claim Rule a name to your likings / standards and paste the following entry in the ‘Custom Rule‘ field*:
  4. c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] 
    => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "vmwareidentity.domain.com");
  5. Make sure to change the ‘vmwareidentity.domain.com‘ to the FQDN of your vRA environment. E.g.
    Schermafbeelding 2019-06-15 om 20.25.18
  6. Save your Claim Rule by clicking ‘Finish‘ and let’s configure vRA now! 🙂

*Note: The latest version of the Custom Rule entry can be found on the VMware KB pages provided in the ‘Resources’ section of this blog post.

The vRA Side Setup!

The all-in-one screenshot:
Schermafbeelding 2019-06-15 om 20.45.16

The written version:

  1. Logon to your vRA environment in a tenant of your choice
  2. Go to ‘Administration
  3. Select ‘Directories Management
  4. Select ‘Identity Providers
  5. Add an ‘Create Third Party IdP
  6. Give your Identity Provider a descriptive name. E.g.: ‘ADFS’
  7. Decide your SAML Request Binding. E.g.: ‘HTTP Redirect
  8. Enter your ADFS environment’s MetaData XML URL in the ‘Identity Provider Metadata URL or XML’ field. E.g.: https://<ADFS-SSO-FQDN.yourdomain.example>/FederationMetadata/2007-06/FederationMetadata.xml
  9. Click ‘Process IdP Metadata‘. This will automatically populate the Name ID Formatting From SAML Response fields below.
  10. Edit / Remove / Modify the fields so it looks like the all-in-one screenshot above.
    E.g.: ‘urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress’ mapped to ’emails’
  11. Set the Name ID Policy in SAML Request to ‘unspecified‘ as shown in the all-in-one screenshot above.
  12. Under ‘User’s select your vRA AD Directory to use this ADFS integration with
  13. Modify the Network Ranges to your likings
  14. And set the ‘Authentication Method‘ to: urn:oasis:name:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  15. Click ‘Save‘ & your good to go!

In order to test it, you need to modify your access policy in vRA to use this Identity Provider.

  1. Under the ‘Directories Management’ menu select ‘Policies
  2. Here you can add or modify your access policies
  3. !!! WARNING: Make sure that you can still access your vRA environment by your last known working Identity Provider in some way! For example only configure the ADFS Identity Provider for a specific network range or a specific application. In case something is wrong with your ADFS Identity Provider, you can still log on via your other Identity Provider(s). !!!
  4. Modify for example your default_access_policy and set the access from a specific network range or application type to use the ADFS Identity Provider.
    E.g.: Web browser, macOs, …. to use ADFS IdP and the others to use another IdP of which you are sure you can still access it.
  5. Click ‘OK
  6. And click ‘Save‘ to apply your changes!

Let’s test it out!

The Test!

  1. Browse to your Tenant vRA FQDN of which you’ve configured ADFS for and from a device which will be using the ADFS IdP as configured in your access_policy.
  2. If all goes well, you should land on your ADFS SSO sign in page
  3. Log in with credentials that have access to the vRA Tenant environment
  4. If all goes well you’ll be redirected back to vRA after login!
  5. Congratulations!

Troubleshooting

  1. A good start for troubleshooting issues with the setup is using a SAML plugin for your browser of choice in order to investigate the SAML Requests & Responses.
  2. Horizon.log file is a good place to investigate issues!
  3. E.g.: If you’ve mapped the wrong LDAP Attribute to the E-Mail Address on the ADFS Side within the Claim Rule we’ve setup, you might see what exactly ADFS is sending back to vRA. In combination with checking the ‘horizon.log’ file on your vRA environment, you might be able to see what exactly goes wrong (example: Invalid SAML response, cannot translate / decode response into format ’email address’).

Good luck! Hopefully it could be of any assistance 🙂

 

 

 

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close