Active Directory is dead: long live Active Directory. While Microsoft's Windows Server Active Directory (WSAD) is unable to meet the needs of today, its younger sibling Azure Active Directory (AAD) looks set to take the world by storm.
I have given it the once over and am impressed with the technology – but also ambivalent about its implications.
I am known for being sceptical of the public cloud, but we are long past the point where a competitive business can do all its IT in house. The reality today is that there is as much IT beyond the corporate firewall as behind it.
The on-premises-only authentication mechanism that has done us well for the past 15 years no longer fits the bill.
The old ways
With enough willpower and political capital in your organisation a charismatic CIO could impose VPNs, endpoint management and other legacy tools of the trade onto smartphones, tablets and even home PCs for teleworking staff members.
Corporate notebooks could be locked down and everything could be tied back to the existing WSAD infrastructure.
Most companies still run this way. From experience, however, it is all a right pain in the proverbial. Users who have got used to signing into virtually any website using their Facebook or Google credentials end up frustrated at negotiating a daily obstacle course of hooking up various widgetry to the corporate network.
The traditional approach is also lacking when it comes to integration with software as a service (SaaS) applications. If you wanted to create a single sign-on for your corporate Dropbox accounts as well as your on-premises WSAD accounts, you would have to rely on third-party software such as that provided by Centrify.
In one sense, AAD is very similar to products such as Centrify, which allows you to connect SaaS applications to your WSAD install, as does AAD. A gander at the Dropbox Tutorial will show those similarities.
Of course, AAD has going for it what Microsoft products always have going for them: deep integration into all things Microsoft. AAD support is to be built into Windows 10. It is certainly baked into Azure and Office 365.
It will be as much a part of every next-generation Microsoft product as WSAD was part of the last. AAD will have more third-party applications supporting it. It will be more deeply integrated into every aspect of Microsoft and will be the de facto identity service of the next 15 years.
So, what is it?
Ties that bind
The world of Microsoft identity potentially has a lot of moving pieces. On premises we have WSAD. Those conversant with Microsoft technologies may also have heard of Forefront Identity Manager (FIM).
You can think of FIM as Active Directory on steroids: its job is to connect WSAD to on-premises the way that AAD connects to SaaS applications.
If Active Directory is the foundation of modern identity management, FIM and AAD can be thought of as middleware glue that interconnects applications, each of which stores different chunks of information about users, all under different names.
One application might call a field "position" while another calls it "job title", but they need to be mapped to the same field across all applications if people are to stay sane trying to keep records straight.
FIM requires some help in connecting to the world of whacky as-a-service cloudy fun
FIM's current version – 2010 R2 – is not innately cloud aware. Like WSAD, it requires some help in connecting to the new world of whacky as-a-service cloudy fun. To make this all happen we rely on a tool called Dirsync (soon to be replaced by AAD Sync).
If you have FIM set up you will want to use AAD Premium, and you will have to set up Dirsync/AAD Sync manually. This is not the prettiest of processes, but it is a lot easier than, say, setting up System Center.
If you don't have FIM and are only using WSAD, then you are in luck. Microsoft Connect makes connecting WSAD to AAD a "next, next, next, finish" kind of affair.
Simply find an x64 server that is Server 2008 R2 or newer and is not a domain controller (sorry SBS users). Run Microsoft Connect. It will check for prerequisites like .NET, the AAD PowerShell Module and Microsoft Online Services Sign-In Assistant. It will download, install and configure Dirsync/AAD Sync and enable it in your Azure tenant.
Microsoft Connect will set up either password sync or AD FS; if you don't know what AD FS is, choose the password sync option. Microsoft Connect will then run various checks to make sure everything is good to go.
There is one caveat. If you want users to be able to sign in using the using the on-premises User Principal Name (UPN) then your UPN attribute needs to use a publicly routable domain. In other words, if your local domain is something like "vulturenorth.local" or "vulturenorth.intranet" you will run into a few problems.
There is a quick fix. Go here and scroll down until you find the section labelled "add alternative UPN suffix to Active Directory". Just follow the fairly simple steps outlined there and all your problems with connecting your local WSAD setup to AAD using Microsoft Connect should go away.
Of course, pushing the buttons to make A talk to B is only one part of this process. Another goal is to enable computers out on the wild woolly internets to authenticate with your local WSAD install.
Also, Microsoft's wider focus is to enable tomorrow's developers to tie their applications to AAD, preferably after developing their applications for Azure.
To ensure that these new applications can take full advantage of all that AAD has to offer, AAD naturally has a full REST API. The goal is to ensure that developers don't waste time building their own identity management for each application. No need to create and track users or worry about password hashes and so forth.
From a purely pragmatic standpoint, Microsoft is likely to do a better job of handling users and user security than if each developer tried to reinvent this particular wheel for every application.
Microsoft is already leveraging AAD's single-sign-on capabilities to unite Office 365, Dynamics CRM, Windows Intune and other Microsoft cloud products.
Microsoft is not building a complete walled garden here. Third-party identity networks such as Facebook and Google – and their constellation of attached applications and services – can be integrated. This is where things get a little complicated.
The various companies seeking to rule us through our logons are still arguing about which identity standards to support. This means that while these services can play together to a greater or lesser extent, there are some things we cannot have.
Where everyone plays nice, creating a user in the AAD interface will create that user in all connected applications and identity services. Where there is a butting of heads over standards, expect to have to create the user both in AAD and in a third-party application or identity service. After that you get to manually map the users one to the other.
Until the standards wars for hybrid federated identity management come to an end, expect this to be the new normal.
There is a huge amount of marketing bumf available for AAD: what it is good for, why we should care and so forth. Cutting to the chase, you need to understand how Microsoft envisions that we will use AAD if you want to see if it is a good fit for your organisation.
Naturally, Microsoft envisions that we will all synchronise our WSAD to AAD. This is nice for single sign-on, but strictly speaking, it is not required.
If your staff are capable of understanding that they have two separate logins – one for things behind the corporate firewall and one for cloud services – then you can keep the two separate and create a security model that is different from the one Microsoft proposes. The choice is yours.
AAD at the centre
Microsoft also sees everyone using its AAD management tools to manage users. It is theoretically possible to use your local tools to make changes to WSAD and have those pushed up to the cloud, or to manage everything through a third-party application and have it push changes to the rest of your identity network via the APIs – but this is not Microsoft's vision of the future.
Microsoft positions Azure at the centre of your digital life, filling the role that Windows Server held during the previous 15 years. Thus it wants Azure interfaces – including AAD – to be the new normal, and the means by which we interact with our entire identity network.
Everything is centred on creating a harmonised user experience, provided you start and end in Azure.
Along with this is the ability to inspect user login patterns to see if anything is amiss. Is someone trying to log in from multiple unknown sources? From a different part of the world than normal? Are they using a commercial VPN service? Not signing in during their normal time of day?
They can be banned, forced to punch in a security code and have an email sent to the administrator informing of them of this "suspicious activity".
Beware the users
Microsoft also proposes to "empower" end users. As a cynical sysadmin, I don't want my users empowered. Empowered users leads to early onset sysadmin madness.
The first bit of user empowerment gives users the right to change their own passwords. There is also an "access panel" that serves as a launcher for SaaS applications that user has access to. I see no issues here.
But AAD empowerment also gives end-users the right to create and manage groups. It is one thing for users to be able to shove their contacts in Outlook into groups, but I get twitchy when we start talking about users being able to do anything beyond changing their password.
Along the same lines, I have concerns about the level of access that all the bits of federated cloudy identity may or may not have with one another.
My nightmare scenario is someone who is not me being able to create a user in AAD with administrative privileges (or assign administrative privileges to an existing user) and have those changes replicate back to my on-premises WSAD infrastructure.
The culprit could be a miscreant who has cracked my Azure global administrator password, or a badly coded third-party application issuing commands through the API.
In this respect, AAD Sync is a huge advance on Dirsync. It offers much finer control over what can and can't sync, and provides some hope that forethought and planning can keep those nightmare scenarios at bay.
Despite my concerns, it is hard to argue with AAD’s utility. It provides needed functionality for today's joined-up world, and does it simply and robustly. The early versions had many teething problems but most of those have been worked out.
AAD is a fully modern federated identity service ready to handle the applications of yesterday, today and tomorrow. ®