First look: Microsoft Azure Active Directory Domain Services puts it all in the cloud

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_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence\PasswordSync\EnableWindowsLegacyCredentialsSync

• 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.

This story, "First look: Microsoft Azure Active Directory Domain Services puts it all in the cloud" was originally published by Computerworld.