“Identity management (IdM) describes the management of individual identities, their authentication, authorization, and privileges/permissions within or across system and enterprise boundaries…” Source:Wikipedia
Identity Management in cloud-based deployments is still a work in progress for service providers and infrastructure software vendors. So far identity management and associated technologies such as Active Directory, Digital Identities, Security Tokens, Security Token Services, OpenID, OAuth amongst others have been successfully utilized for single instance authentication.
Organizations started to cross authentication boundaries using solutions that extend the local authentication domain allowing for a single authentication source to interact with multiple authentication providers. This is called identity federation. Some of the protocols in use are SAML 2.0 (Security Assertion Markup Language), WS-Federation and ADFS (Active Directory Federation Services).
A simple and common example of this cross-boundary authentication is the multiple online services that now accepted Facebook or Twitter logins as authentication token. 3rd Party enterprise-ready solutions are also available to federate internal enterprise identity management and external online services, such as Software-as-a-Service solutions like Salesforce.com and others. VMware Horizon Application Manager along with Horizon Connector allow organizations to federate Active Directory directory services.
Nowadays Microsoft Active Directory is the most common identity management solution for Windows desktops. Most Desktop-as-a-Service offerings available on the market today, with few exceptions, are offering Windows desktops.
Communication between Active Directory domains and entities occurs through trusts. Trusts are authentication pipelines that must be present in order for users in one domain to access resources or authenticate against another domain. There are multiple types of trusts, however the external, one-way, non-transitive trust is the most widely used in Desktop-as-a-Service deployments due to the security model implemented.
External – An external trust connects to other forests or non-AD domains.
One-Way – One domain allows access to users on another domain, but the other domain does not allow access to users on the first domain.
Non-Transitive – A non-transitive trust that does not extend beyond two domains.
Let’s take as example an Organization that utilizes cloud-based desktops (Desktop-as-a-Service) from a service provider. The Service provider commonly have a established Virtual Private Network with the tenant organization and also has an Active Directory trust relationship for authentication and resource access purposes.
Depending on the deployment model this VPN and Trust allow for either the Service Provider hosted desktops to access resources in the Organization datacenters, or the Organization’s IT administrator to manage Active Directory objects in the Service Provider tenant’s network and Active Directory services. In some deployments the Service Provider Active Directory is just a sub-domain or an extension of the organization’s corporate Active Directory.
The Desktop-as-a-Service model assumes that multiple users from multiple organizations use the same cloud-based desktop service and infrastructure without ever sharing data, authentication or credential information. The picture below illustrates this model in a rather simplistic and high-level architecture.
“A forest is a collection of trees that share a common global catalog, directory schema, logical structure, and directory configuration. The forest represents the security boundary within which users, computers, groups, and other objects are accessible.” Source: Wikipedia
I am starting to see Desktop-as-a-Service reference architectures surfacing from multiple vendors. However, I am yet to see an architecture that provides true secure multi-tenancy. Most of those reference architectures that I had the opportunity to see have an essential flaw that completely breaks the multi-tenancy concept – They share a single Active Directory Schema and Forest across all tenants. The reason being is that the desktop brokering solution does not work with multiple active directory forests simultaneously.
These reference architectures I mentioned implement multiple Organization Units (OUs) or child-domains as tenant boundaries. Each tenant will ever be as secure as Microsoft tell you so; and I am certain I don’t have to remind you about the number of patches MS release every month.
On another hand, imagine if Coca-Cola is able to breach into Pepsi domain, or Motorola is able to breach into Samsung Organization Unit. Well, you can get the picture here.
Surely, the risk acceptance depends on the level of separation you want to accomplish. Unfortunately restricting visibility of Active Directory objects within a domain/forest is rather difficult to accomplish.
A true multi-tenant secure solution should never utilize the same forest for multiple tenant organizations, therefore sharing parts of the schema and having serious implications around security.
As I mentioned above, another valid approach for multi-tenant authentication is the extension of the organization’s internal Active Directory into the service provider network, allowing virtual desktops to authenticate directly into the organization’s domain.
This approach allow organizations to maintain control over Active Directory user, computer and group policies objects without requirement to have trusts in place. However, this solution has its own security weaknesses as the organization is exposing the internal corporate Active Directory to a 3rd party provider.
To mitigate that some organizations create a dummy domain in the DMZ to serve virtual desktops provisioned by the service provider. The internal corporate Active Directory domain trusts this dummy domain.
As we can see there is no right or wrong approach, and each may be useful under a different context and use case. The most important is that the service provider brokering technology responsible for authenticating users be able to work with multiple Active Directory forests. Unfortunately most pre-packaged solutions on the market today work with multiple Active Directory domains, child-domains and external-domain, but not multiple Active Directory forests.
Other solutions, like spanning multiple independent AD forests with their own brokers is also available and I’ll discuss them in another article. Moving forward I will cover more aspects of Desktop-as-a-Service.
The 2nd and 3rd part of this article can be found at