Some time ago Microsoft unveiled its Azure Active Directory (AAD). During recent weeks, I have had several discussions about what AAD is. First of all: It is not just an on-premise AD ported to Azure and run as a Cloud service. Despite relying in its inner areas on proven AD technology, it differs greatly from on-premise AD. It is a new concept, going well beyond a classical directory service and integrating support for Identity Federation and Cloud Access/Authorization Management.
In fact you can use three flavors of AD today:
- The classical on-premise AD
- The on-premise AD running on Azure in virtual servers
- The AAD
However, the most interesting element in this family of ADs clearly is AAD. AAD is a new type of thing that is“more than a directory service”. It can integrate with existing AD infrastructures, best by using Identity Federation based on ADFS (Active Directory Federation Services) and SAML v2 as a protocol.
It then is a service that runs as a real Cloud service:
- Multi-tenant
- Elastic
When looking at existing AD infrastructures, there are some common challenges that AAD can address, aside from running as a Cloud service (there you also could use the on-premise AD running on Azure).
One of the common challenges for AD are schema changes. Schema changes are a nightmare for many administrators. They can’t be rolled back. And they might affect the AD performance. Thus, many administrators are extremely reluctant to make any schema changes. AAD solves this with its flexible, extensible data model. This data model has left the LDAP/X.500 history that still is visible in AD. Thus it comes to no surprise that the primary means of access to AAD is not via LDAP (which is not even supported out-of-the-box yet) but through the REST-based Graph API.
The second common challenge AD administrators are facing (amongst some others…) is the management of external users. Many organizations have implemented some approach to managing such externals, for instance in separate domains or at least subtrees. However, these approaches are not easy to define and implement from both a security and a scalability perspective. It might work rather well for some business partners and sub-contractors that need access for a longer period of time. However, onboarding thousands of employees of new business partners (for instance for sales to new target groups or in new regions) is something the on-premise AD is not ideally suited for.
AAD is built for that. It not only can scale flexibly – think about millions of customers instead of some thousand or tens of thousands employees or business partners – but it also supports federation by design. It can federate both inward and outward. In other words (and as mentioned above): It is not only a directory service but a federation platform.
And even more: It also is a tool that you can use to manage access to other Cloud Services. It can act as authorization services for these, when federating with them. Based on policies, access to such services can be managed and restricted.
So there is a lot more in AAD than in the on-premise AD. AAD is the logical extension of AD for the “Extended Enterprise” or “Connected Enterprise” – whichever term you chose. It allows managing external users far more simply while being massively scalable. It allows managing access to Cloud services. And it still behaves well in conjunction with existing on-premise AD environments.
There are alternatives to AAD in the market. However, AAD is one of the Identity Cloud services worth having a deeper look at. The most important thing you should do when looking at AAD is to accept and understand that this is far more than the on-premise AD ported to the Cloud.
I will cover some aspects of AAD and the surrounding (and growing) ecosystem in upcoming blog posts.