DaaS Identity Management, Federation & Multi-Tenancy

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.

Screen Shot 2012-07-15 at 11.25.28 AM

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.

Screen Shot 2012-07-15 at 11.25.39 AM

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.

Screen Shot 2012-07-15 at 11.25.48 AM

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.

Screen Shot 2012-07-15 at 11.26.10 AM

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.

Screen Shot 2012-07-15 at 11.26.17 AM

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

DaaS Mobility and Portability and

DaaS Scalability and Elasticity.


This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net.


4 pings

Skip to comment form

  1. Great article Andre. My company haven’t gone down the VDI route so I’ve no exposure or understanding of the VDI specific AD requirements but I’m learning!

    I’ve been implementing ADFS recently (for a non virtualisation related project) and found it to be complicated yet extremely flexible and its applicability to cloud models is fascinating. You article implies that ADFS is a federation protocol but it’s simply Microsoft’s branding and actually uses either SAML2.0 or WS-Federation (depending on your deployment scenario) under the hood. It works differently to the usual AD trusts model allowing for more loosely coupled systems – I’m surprised to hear that VDI brokers still insist on fairly limited AD trusts. I’m still getting to grips with the big picture and where ADFS will fit into the cloud world – once I have it clear in my head I’ll post my thoughts on my blog.

    Does your book cover these aspects of VDI? It was already on my wishlist but might have to be bumped nearer the top!

  2. @Ed Grigson
    VDI brokers were created for enterprise use and at the time the DaaS concept didn’t exist or was at early stages. In addition, to that Windows OS require AD for Policy Management, otherwise other identity management solution could be used. The difficult part is to move to a true multi-tenant solution yet providing support for common AD trusts.

    No, the book only cover the VDI aspects in a enterprise deployment.

    Thanks for you comments,

    • Bill Adams on 08/20/2012 at 3:37 pm

    “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.”

    What is your experience using ADLDS as the bridge between the disparate AD environments? It would seem that using ADLDS as a (sort of) SSO solution maintains the true separation, while allowing different organizations to access a common platform.

    Interested to see your views… moving in this direction myself.


    Bill Adams

  3. @Bill Adams
    AD LDS used to be called Active Directory Application Mode (ADAM). It’s the same product and it allows you to create an independent AD for applications. Many applications that require replication uses ADAM, including VMWare View. However, ADLDS does not solve the federation piece between multiple forests or domains.

    Have a look at SAML 2.0 (Security Assertion Markup Language), WS-Federation and ADFS (Active Directory Federation Services) as possible solutions for resource authentications between environments.


  1. […] am building this discussion on top of my previous article DaaS Identity Management, Federation & Multi-Tenancy. Therefore, before moving forward I recommend reading the mentioned […]

  2. […] article is built on top of my previous DaaS articles: DaaS Identity Management, Federation & Multi-Tenancy DaaS Mobility and […]

  3. […] DaaS Identity Management, Federation & Multi-Tenancy […]

  4. […] DaaS Identity Management, Federation & Multi-Tenancy […]

Leave a Reply