Home > Blogs > Horizon Tech Blog


Using VMware Identity Manager to transform users between Active Directory domains..

I get a lot of questions about how to solve Single Sign-On (SSO) of users between two Active Directories without trust. Using the federation protocol SAML and VMware Identity Manager this is easy to achieve.

In my example we have two Domains, A and B. Users in Domain A wants to access resources in Domain B without being prompted for username or password.

Prerequisites

  • You need two VMware Identity Managers. One in each domain.
  • Federate the resource (a web server in my example) in Domain B to VMware Identity Manager in Domain B
  • A user object representing the user must exist in both Domains. One user attribute must be shared across the two domains. In my example I use the Email attribute. The attribute you choose must uniquely identify the user.

If your resource is a Windows application, VMware Horizon and the feature TrueSSO can be used to achieve SSO access for Domain A users into a Windows application running in Domain B.

Establish SAML based trust

First thing first, once the prerequisites are in place next step is to establish a trust between the two VMware Identity Managers. This trust is based on SAML and is much easier to establish than traditional Active Directory trust.

You establish trust by exchanging metadata.xml files between the two Identity Managers. In my example users from Domain A need to access resources in Domain B. So, VMware Identity Manager B must trust Identity Manager A as a third-party Identity Provider (idP).

On the VMware Identity Manager in Domain A navigate to Catalog – Settings – SAML Metadata. Right click on Identity Provider (idP) metadata and choose Copy link address.

Now navigate to the VMware Identity Manager in Domain B and add a third-party idP.

Give the new Identity Provider a name and paste the link to the idp.xml into the metadata field. Scroll down and click Save.

Once saved you’ll see all the settings being populated.

In my example, I’m relying on the Email attribute. Therefore, delete all the other Name ID Formats.

Next configure the user store where your users are in Domain B’s VMware Identity Manager and which network ranges this idP will serve.

You need to create an Authentication Method. I will use Password to login users in Domain A’s VMware Identity Manager. So I named the Authentication Method: domainA_PWD and password typically use SAML Context: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport. But obviously here your settings must match your implementation.

Scroll down..

Right click on the SAML Metadata, Service Provider (SP) metadata link and choose Save link as…

Now you have downloaded a file called sp.xml.

Click Save

Still on the VMware Identity Manager in Domain B you need to add the new Authentication Method in your access policy. In my example I simply add it as the last one. In my case I will only support idP initiated flow. If you are planning on supporting SP-init flow you must think about the order of authentication (authN) methods.

In above picture, you can see I added domainA_PWD as the third authN method. (This name was given the authentication method in previous step.)

With these steps, we have now established a SAML based trust. Domain B’s VMware Identity Manager trusts SAML assertions from Domain A’s Identity Manager.

Configure Users

Next step is to make sure you have user objects in both domains sharing the same attribute.

I’m using the Email attribute as the unique User Identifier.

Above is a screenshot of my test user synced into VMware Identity Manager in Domain B.

And below is the user object in my Domain A’s VMware Identity Manager.

As you can see in my example most attributes are the same. But the only important attribute is the Email one. That must be identical in both Domain A and B.

Run a test

Let’s now run a test to verify the SAML trust works from A to B.

We need to create an application in Domain A’s VMware Identity Manager that represents the Identity Manager in Domain B.

In Domain A create a new SAML 2.0 based Web Application.

Paste the content of the sp.xml file you saved previously into the Meta-data XML field and click on Save.

Modify the Configuration to use Email instead of Username:

Name ID Format: Email address

Name ID Value: ${user.email}

Click Save.

Entitle your test user to the newly created application.

Login to VMware Identity Manager in Domain A as your test user.

Click on the application icon representing the VMware Identity Manager in Domain B.

SAML Assertion is generated..

..if all is correctly configured you should now have been Single Sign-On into the VMware Identity Manager in Domain B. Now all resources entitled to the test user in Domain B are possible to consume.

Below is a picture showing what we have configured and tested so far.

While the test was successful. This method is not ideal from an end-user experience perspective. Users have to login to one portal and then get SSO:d into another portal. Next users must launch the application. We can solve this by adding resources from Domain B straight into the portal in Domain A.

Adding remote resources in VMware Identity Manager portal

VMware Identity Manager have one very nice feature and that is that each resource has its own unique launch URL. This can be used in many ways. Customers are placing links that launches applications on their intranet pages and such.. But in this case, we will use it to provide a greater user experience.

First, we need to identify the unique application ID used in the VMware Identity Manager in Domain B.

In above picture, you can easily find the UUID. This is the key to the unique launch URL. For Web Applications, you can also find the unique launch URL under Configuration tab.

But for Horizon resources it is different.. Here you will have to build your own launch URL using the UUID.

The launch URL format is: https://<hostname>/SAAS/API/1.0/GET/apps/launch/app/<resourceUUID>

So now when we know the unique launch URL let’s login to VMware Identity Manager in Domain A and manually create the representation of the resource.

Create a new SAML 2.0 SAML Web Application in Domain A’s VMware Identity Manager.

Configure the new Web Application:

  1. Copy the content of the sp.xml (same one as we used to create the icon for the full Domain B’s VMware Identity Manager) into the metadata field
  2. Name ID Format and Name ID Value should be Email (just the same as we did before)
  3. RelayState, enter the unique Launch URL of the application

Once saved, entitle the new application to your test user..

Now let’s test this new method..

Login to Domain A’s VMware Identity Manager as your test user.

Now launch the application pointing to the unique Launch URL. In my case Office 365 Portal.

SAML Assertion is generated..

..if the configuration is correct you should get straight into your federated application.

That concludes this blog post.. I hope you found it useful.