Jan 13, 2017

A common misconception I get quite often in classes is what exactly Azure Directory Services (Azure DS) is, and how it differs from Active Directory Directory Services (AD DS). Most often, people think Azure AD is just another copy of Active Directory in “the cloud” and I must admit that whilst they both have similar functionality, they also have quite different usage, capabilities, and features.

Active Directory was introduced as a hierarchical authentication and authorisation database system to replace the flat file Domain system in use on NT4 and previous servers. The NT4 domain model in 2000 was straining at the seams to keep up with evolving corporate structures, hampered by some quite severe limitations – maximum of 26,000 objects in a flat file “bucket”, only 5 kinds of fixed objects whose structure (properties etc.) could not be changed, maximum size of the database of 40Mb etc. NT4 Domains also primarily used NetBIOS (another flat file, Microsoft specific system) for its name resolution. For a lot of larger organisations this necessitated multiple domain databases with very limited and complicated interactions between those domains. Active Directory Directory Services (just called Active Directory in those days) was released with Windows Server 2000 and was based upon the X.500 hierarchical network standard that companies such as Novel’s NDS and Banyan Vines were using at the time. AD also used DNS as its name resolution system and the TCP/IP communication protocols in use on the internet. It brought in the idea of a directory system which contained a “schema” database (the set of “rules” that define the properties or attributes of objects created in the “domain” database) which could be added to or “extended” to create either entirely new objects or new properties of existing objects. Size limitations were also thrown out the window, with Microsoft creating directory systems in the billions of objects (given enough storage!) in their test labs.

And Active Directory – or AD DS as it is now known as – quickly became the defacto directory system still in use today in for most organisations. But times they are a-changing again. AD DS was, and still is great for managing the authentication and authorisation functions for the users, their workstations and servers etc. within an organisation, but its reliance upon member computers permanently joined to a domain, and protocols such as LDAP for directory querying, Kerberos for directory authentication and Server Message Block (SMB) for downloading Group Policy data, are not really suitable for the modern Internet-centric, BYOD, mobile style of work environment becoming more and more popular these days.

So enter Azure AD. Yes Azure AD is a version of directory services “in the cloud” – up on Azure to be precise! – but it does have quite different capabilities and features compared to AD DS. Its main function at the moment is to manage users and the myriad of devices (Windows, Apple and Linux PC’s, tablets and smartphones etc.) that users are employing in their work and social lives, particularly for “roaming” users and users on the internet. But it is also helping to blur the distinction between “in-house” and “remote” or “roaming” users. Obviously, it is the authentication and authorisation mechanism for not only Azure, Office 365 and InTune, but it is capable of tying in with so many other third party authentication or identity systems as well.

Some of the main differences therefore between AD DS and Azure AD are:

• Azure AD is primarily an identity solution, designed for Internet-based users and applications using HTTP and HTTPS communications.
• It has gone back to a flat file structure, ie no OU’s etc.
• It does not use Group Policy or Group Policy Objects (GPO’s).
• It cannot be queried with LDAP. Instead, it uses REST API’s over HTTP or HTTPS.
• It doesn’t use Kerberos for authentication. Instead, it can use various HTTP and HTTPS protocols such as Security Assertion Markup Language (SAML), WS-Federation and OpenID Connect for authentication (and OAuth for authorisation).
• It includes Federated Services, which allows it to federate (i.e. form a trust relationship) not only with on-premise AD DS, but also with other third party services (such as Facebook) for authentication purposes, giving users a single sign-on capability across multiple systems.

Furthermore, Azure AD supports 3 types of authentication:

• Cloud based – where the users are managed wholly from Azure AD, and their devices and applications can be managed via InTune or Office 365 etc.
• Directory Synchronisation – essentially a one-way synchronisation from the on-premise AD DS up to Azure AD, using tools such as AD Connect. Optional two-way synchronisation of a very limited number of Azure AD properties (primarily password sync) is possible and two way synchronisation of Exchange attributes is also possible in a Hybrid Exchange environment, however in both cases directory synchronisation and password sync are just keeping 2 sets of independent security credentials aligned.
• SSO with AD FS – Single Sign-On with AD Federated Services means the user is authenticating against AD FS instead of Azure AD. AD FS actually authenticates the user against your on-premise AD DS, but then uses a claims-based delegated token to provide access to resources governed by Azure AD without requiring a local account in Azure, and transparent to the user. Federated Services can also be extended to cover other third-party federation identity partners such as the previously mentioned Facebook, Google, Yahoo and of course Microsoft Live accounts, as well as the ability to add your own identity provider if necessary.

You can see that Azure AD can work closely with a number of identity providers as well as AD DS to greatly extend the management capabilities and functionality of your organisations directory services, so come along to one of the many Azure, SCCM/InTune and Office 365 courses run here at New Horizons, and find out what additional capabilities Azure AD can give you.