VMware Identity Manager with Multiple AD Domains

I like a product name that ‘does what it says’ on the tin (or download…) – VMware Identity Manager is such a product, and then some.  VMware Identity Manager (vIDM) does just that – it manages the various facets of Identity.  Now let’s consider what we use Identity for?  Typically, it’s the following:

• For the purposes of authentication into a solution – who are you?
• For the entitlement to resources – what you can do, based on who you are?

VMware Identity Manager provides this layer, providing a central point to answer these key questions as a part of VMware Workspace ONE. In order to be able to answer the authentication ‘who are you?’ it typically leans on existing directory services (usually Active Directory) to generate its own synchronised directory listings and passes through requests for validation – i.e. a password or multi-factor token, to the appropriate solution. For the entitlement to resources, VMware Identity Manager can present a wide range of resources on its own.  These include Cloud services, complete with Single-Sign-On integration, as well as VMware Horizon (either Cloud or On-Premises).  Using the Directory above, we can use the user’s credentials as part of the ‘what can you do?’ along with other policy elements such as location (by IP address) and device type. Because VMware Identity Manager sits as a sort of gatehouse between the user and resources, it stands apart from a single environment.  This means that it’s entirely possible to integrate several disparate environments behind a single portal.  In this scenario, you might need to integrate several different directory services and authentication layers as well as grant entitlements to resources. This article takes a high-level look into how you’d go about this.

vIDM Connectors

VMware Identity Manager follows the concept of a Connector; providing a service for integration into an estate, usually for Directory services, but also for plugging into authentication mechanisms such as RADIUS and Kerberos as well as providing a hook into resources such as VMware Horizon. In order to add multiple directories, you’ll need to deploy multiple Connectors – at least one per domain (ideally a pair for resilience).  In an on-premises deployment, the vIDM appliance has a built-in Connector, though it’s probably wise to deploy separate, standalone Connectors.  These are available as either a Linux based appliance, or a Windows Server installable application (included as part of the VMware Workspace ONE Enterprise Systems Connector). In either case, within vIDM, you need to log into the Admin console and go through “Identity & Access Management”, select Setup and the “Add Connector” button to generate an activation code. Once you’ve done this, it’s a case of deploying the Connector, and logging onto its web interface (https://connectorFQDN:8443) and completing a wizard.  All you do here is drop in the Activation Code, the root certificate used for vIDM and set a local Admin password.  Simple! In vIDM, you’ll see your new Connector – note the installed version conforms to what you’ve deployed (here, a Windows connector). With this in place, we can set up a Directory synchronisation.

Creating a Directory

With the connectors in place, you add each directory.  You’ll notice below I’ve already added the first Domain, Galaxy.local.  Let’s add another. In the Add Directory wizard, it’s the same process as would be the case for adding the first – though using the new Connector.  Remember that you’ll also need to select attribute mappings and Organisational Units for Users and Groups.  Once you’re done, you’ll see multiple directories:

Authentication

When we add our directory, we should enable the Connector to provide authentication for this directory as well. With this done, we have quite a bit of latitude with respect to authentication.  With a Connector in place, we can integrate with domain specific multi-factor authentication (MFA) solutions, then tie it all together with the use of policies to select what conditions dictate which authentication mechanism to use – for example, a User in Group X on an iPhone on IP address Y must use Password and RADIUS.

Assigning Applications

So now we can use both directories for assigning users/groups to applications.  For cloud-based applications, it’s possible to grant access to users from any domain.  The limiting factor here is, if the application is leveraging SSO – it might not be able to support multiple domains.

Adding Horizon

When you integrate VMware Horizon into Identity Manager, it too leverages the Connector, so if you have separate Horizon instances in each Domain, you can set each of these up. It’s possible to configure the Client Access FQDN for each Horizon instance on each IP range, configured in vIDM, so you have further options.

Closing Thoughts…

So, what does this mean?  VMware Identity Manager, either as part of a VMware Horizon deployment, or broader ranging as part of a Workspace ONE delivery really can be the one ring to rule them all.  It can provide a single access point for all users in a business, regardless of whether they are separated into different business units with their own Active Directory, and still present their applications. A use case for this might be providing a single front end to unify resources following an acquisition – two separate environments fronted by a single interface as a starting point for a migration?  Maybe. Xtravirt have experience in deploying VMware Workspace ONE and Horizon across many different environments and bring a broad range of skills and experience to the table.  If you’re deploying such a solution, perhaps we can help. We have a long track record of successful workspace projects and can provide advisory, design and implementation services to create the right solution for your organisation. Contact us and we’ll be happy to assist you.