Azure Active Directory vs. Active Directory Domain Services

I’ll start by saying that today’s Identity technologies can be very confusing. There are many Services (in the cloud era everything is a service), protocols, solutions, SDKs, technologies and products aiming to solve the Identity problem.

I’ll start by comparing the basic two which might be the most confusing as they happen to share the same name: The good old Active Directory Domain Services (ADDS in short) and Windows Azure Active Directory (AAD in short).

ADDS is used for ages (well, 13 years in computers seem like ages) to provide authentication and authorization (AuthN and AuthZ) services within the enterprise Data Center (the on-premises environment). It’s pretty popular (87% of Fortune 1000 use it, based on Gartner) and it’s been pretty solid in providing all the required services. (Disclaimer: I used to support it working for MSFT, so I kind of like the product).

But in today’s changing landscape it’s not really enough anymore, and the reason is: Ze Cloud!

When we look at the local Data Center and the Cloud environment there are many differences in what protocols and solutions are being used due to several reason, but the 3 main ones are: Security, Privacy and Interoperability.

Looking at the protocols used within the local data center for authentication and authorization we can safely say that Kerberos is the most common protocol out there today, and looking at the data access used in Data Centers today to access the identity store, I would say LDAP is the most common protocol being supported by almost every directory vendor out there.

So this is exactly what ADDS does: Authenticates users and authorizes resource access by using Kerberos, and provides access to the data store by using the LDAP protocol.

But then came the cloud’ (And Facebook, which has a very tangible connection)

Looking at how AuthN and AuthZ is managed (or not managed) in the cloud it’s fairly understandable that Kerberos is not quite good enough.

The reason being is when using Kerberos you specify keys which are used to encrypt Kerberos tickets and are provided by a single authoritative source. That’s not possible in the cloud environment (What keys would you use if you want to authenticate a Facebook account to a Google service? There’s no central identity store, and there’s no central key provider!).

So then came SAML, OAuth, OpenID and several others to the rescue. All of which are technologies to enable federated logon. (Basically how can I single sign-on from Facebook to Google without having to enter my credentials twice). Each one have their own specification, but the main goal is to allow authentication across different services by different service/cloud vendors (have I mentioned Interoperability? ).

Looking at the data access layer, same thing applies. Although LDAP could work, there’s something that makes more sense when managing connection between people (whether they’re organizational users, or consumers with profile pictures and walls), which is the Graph!

Using Graph for data store (especially an identity store) makes perfect sense as it’s not hierarchical as LDAP, and can actually show ‘connections’ between the users and the resources in the organization, allowing you to actually manage an identity, rather than a whole hierarchy used in order to organize the identities in ‘Folders’ based on whatever the organization has decided makes sense to them.

This is where Azure Active Directory comes into play. AAD is a cloud based IDaaS (Identity as a Service) provided by Microsoft which uses open standards (SAML for example) in order to authenticate users and allow identity federation across cloud services, as well as the Graph data model in order to query and manage objects.

Here’s a short table comparison of the two:

In conclusion ADDS provides us the ability to logon to our corporate network, access the resources located in the corporate network and allows the services to query information about objects such as users, groups and resources.

AAD allows the ability to logon to our cloud services, access resources located in the cloud and allows cloud services to query information about objects.

Hope it made some sense in understanding the two.

In the next post I will try and cover how the two can be inter-connected for a ‘Hybrid’ Identity (one which allow to use the same account for both on premise resource as well as cloud services).