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.
Next up, you will need to either create a new virtual network or select an existing virtual network. This network has to be in the U.S. or Asia Azure regions. (These are the only geographic locales that the preview supports; of course, this feature will likely be available globally when the code comes out of the preview phase).
I’ll walk you through creating a new virtual network.
First, from the left side of the Azure management portal, choose Networks, enter a name, pick a region and then just accept the defaults.
Next up, we need to enable the domain services aspect of Azure Active Directory. From the left pane of the Azure management console, click on Active Directory again, select the directory you want (again, probably the Default Directory listing), and then click the Configure tab. Scroll down to the Domain Services section and under “Enable domain servicers for this directory,” click Yes.
Enter the DNS domain name you want to use — you can either use the one provided by Microsoft or type over that and enter your own — and then select the virtual network to use. Click the Save button.
It will take a little while as the service trundles behind the scenes. The domain is actually being created; when it’s ready, an IP address will pop up — it could take as long as 30 minutes — followed by another IP address up to another half hour later.
At that point, you need to go back to your virtual network page and pop those two IP addresses in as DNS servers for that network, just as you would configure your local clients to use your domain controllers as DNS servers.
You might be wondering exactly how this cloud AD instance is architected. Right now the service creates a flat, single organizational unit structure. Group Policy is layered on top by creating a single Group Policy Object (GPO) for the user container and another single GPO for the computer’s container.
You can edit the policy settings of each of these two GPOs, but you cannot create more, and you cannot target users or computers more finely via security trimming or Windows Management Instrumentation filtering. That’s the extent of the service for now, although it is fairly easy to envision how each of these subfeatures will be extended in future versions of Azure AD Domain Services.
Finally, you need to set up the actual credentials of users with the directory. Upon creation, the directory has no hashes (the protected credentials) for users, so those will need to be synced over to the directory. If you are an organization that only uses Azure in the cloud and you don’t have anything local to sync, then this is fairly simple: You just instruct the users to go to Azure AD at myapps.microsoft.com and change their existing Azure passwords. This will cause a hash to be generated (now that Domain Services is active on that particular directory), and Bob’s your uncle.
Most of us, though, have existing on-premises Active Directory deployments, so the setup is a little more involved. We will need to use Azure AD Connect, the third-generation sync and connection product that connects your data center with Azure’s services.
Azure AD Connect needs to be installed on your on-premises network on a domain-joined machine. Here is the basic procedure:
- Install Azure AD Connect.
- Create the following registry key and set its value to 1:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSOLCoExistencePasswordSyncEnableWindowsLegacyCredentialsSync
- Run the following PowerShell script provided by Microsoft (to be clear, I did not write this):
$adConnector = "CASE SENSITIVE AD CONNECTOR NAME"
$azureadConnector = "CASE SENSITIVE AZURE AD CONNECTOR NAME"
Import-Module adsync
$c = Get-ADSyncConnector -Name $adConnector
$p = New-Object
Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter
"Microsoft.Synchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null
$p.Value = 1
$c.GlobalParameters.Remove($p.Name)
$c.GlobalParameters.Add($p)
$c = Add-ADSyncConnector -Connector $c
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $azureadConnector -Enable $false
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $azureadConnector -Enable $true
Pricing
As with everything, there is a cost. Right now, Azure Active Directory Domain Services is a nickel per hour, or $438 a year for a directory that has 5,000 objects, 20 cents per hour or $1,752 a year for 5,001 to 25,000 objects, and $4.09 per hour or $3,504 a year for up to 100,000 objects in the directory.
Essentially, from a cash-flow perspective, the 100,000-object directory service is the cost of a couple of new servers per year, if not less, depending on your usage and directory object count. These objects are users, computers or groups within the directory — anything that is listed in the directory counts against this limit.
The last word
I personally think Azure AD Domain Services is a milestone for a number of reasons. Active Directory is available in the cloud as a managed service. The appeal of infrastructure as a service is greater, now that I can outsource the directory plumbing. And a future where I don’t have to deal with domain controllers is nearer and nearer. This is an interesting feature to watch, and it’s worth a look today if you are at all invested in Azure.
