On Oct. 14, Microsoft announced the preview release of Azure Active Directory Domain Services or, as I like to call it, a domain in a cloud.
What is really interesting about this preview is that Microsoft has managed to create a superset of its on-premises product. Azure Active Directory Domain Services has every feature that the venerable on-premises Active Directory (AD) has -- and then some.
There is complete feature parity to ensure compatibility with existing applications that you forklift up to the cloud, but there are also new Azure-specific features that extend AD functionality beyond what you get from Windows Server on local hardware. It's a very interesting milestone, and in this piece I'll take a close first look at what it is and what it offers.
What is it good for?
The first and primary use case for Azure Active Directory Domain Services is to move applications that depend on a full AD implementation into the cloud. Prior to this preview release, you could run SQL Server, Exchange or other directory-dependent applications in Azure, but you also had to have a full-fledged, infrastructure-as-a-service-style virtual machine (or two for best-practice reasons) equipped with Active Directory Domain Services to service the directory for your cloud.
Azure Active Directory was around, but it was mainly used for federation and cloud synchronization and did not fully support AD. If you did not want to deal with another cloud virtual machine just to run the plumbing, you could create a virtual private network (VPN) link between Azure and your on-premises data center so that you could use your existing AD deployment. But VPNs are their own worst enemy sometimes and it was yet another point of failure -- and yet another something to manage.
Azure Active Directory Domain Services basically takes AD and turns it into a "managed website" -- Microsoft handles the service, the patching, the updates, the underlying maintenance, the fault tolerance and whatnot. What you get is truly a managed Active Directory instance, with feature parity to the in-the-box version, without having to manage virtual machines on a full-time basis. In short, you pay Microsoft and it delivers a directory that you just use. You are not responsible for the plumbing underneath.
A secondary use case, mostly enabled by the fact that Azure Active Directory Domain Services is a superset of regular AD, is for disaster recovery and standby. Instead of having a backup data center and domain controllers spread around, you could more inexpensively have Azure Active Directory Domain Services act as your failover site and have the power and scale of Azure behind you in the event something happened to your on-premises AD deployment to make it unreachable.
This scenario is not fully fleshed out yet, mainly because the service is just in the preview phase, but technically there is little to prevent it -- and it may be less expensive than co-locating "backup" domain controllers around the globe or, for smaller shops, incurring the cost of a second Windows Server license to get that second domain controller running per best practice.
A third use case is probably the full Lightweight Directory Access Protocol (LDAP) support that Azure Active Directory Domain Services comes replete with. Many cloud applications do not necessarily need Active Directory per se, but they do need a central directory to perform identity lookups via the industry-standard LDAP. Azure can now offer this service via Domain Services, especially useful for Linux and Unix applications or for federating identity scenarios across multiple applications and providers.
Finally, a fourth use case might cause some tremors of fear in the hearts of Windows administrators: Small shops eschewing on-premises domain controllers entirely and using Azure Active Directory Domain Services as their sole directory. Given that in Windows 10 you can already join a machine to Azure Active Directory (not Domain Services yet, mind you, but still Azure AD) to take advantage of machine management and enrollment features, this day is not far off.
When you couple that with the fact that Microsoft has done a great job of killing off its Small Business Server product, crippling the Essentials SKUs they have offered for this market and pushing those customers to Office 365, it is not terribly difficult to see a future where 10-user, 15-user, even 25-user shops will operate just with a bunch of Windows machines joined to cloud Active Directory without Windows Server in the closet.
Since Azure Active Directory Domain Services has full support for Kerberos, NTLM and Group Policy, it is pretty much a stand-in replacement for a domain controller. Assuming you have decent uplink to the Internet without too much latency, a domain controller in your closet might not even be needed anymore. That fact might not mean that we are entering a "post-Active Directory" era but it sure signals a post-"local domain" era.
Getting set up
Let's get our feet wet and step in.
Contrary to what you might expect, Azure Active Directory Domain Services domains are separate domains from their on-premises counterparts. You can sync them up so that the same set of credentials works in both on-premises AD deployment and within the managed Azure service, but by default the domains are distinct. The machines in the cloud join directly to this cloud domain; the cloud domain is not a replica per se of the on-premises directory but more of a resource that can look like it.
Azure Active Directory Domain Services is joined at the hip with Azure Virtual networks. When you first log into the management portal to set up the service, you have to pick the virtual network the domain lives on. Once the wizard is complete, you get two IP addresses that correspond to the managed domain controllers that come with the service. You then use these two IP addresses as the primary and secondary DNS servers within domain members in the cloud so that lookups and control functionality route through the cloud domain controllers.
When you set up Domain Services you have to specify the virtual network to which it applies. These cloud domain controllers are also used as the main DNS servers for that virtual network.
First, open up the Azure Management Portal. On the left side, choose Active Directory, and then select the directory (it is probably called Default Directory for you unless you have created multiple directories) and then click the Groups tab. Click to add a new group, and call it AAD DC Administrators. Yes, it has to be that name.
Once the group is created, add all of the users of the directory who should be administrators. These folks will have rights to join computers to the domain and also to administer the cloud Group Policy implementation.
