Azure AD Domain Services is now in Public Preview – Use Azure AD as a cloud domain controller!

[Alex Simons (AZURE)]

First published on CloudBlogs on Oct, 14 2015
Howdy folks, It's been an exciting four weeks for us in the Identity Division with the launch of Azure AD B2B and B2C, the addition of Touch ID support to our Azure Authenticator app and the GA of Azure RBAC. But I'm happy to let you know that we're not even close to done! Today we've turned on a preview of a new Azure AD capability, Azure AD Domain Services Azure AD Domain Services is an entirely new concept. It's a cloud based service which gives you a fully Windows Server Active Directory compatible set of API's and protocols, delivered as a managed Azure service. This means as part of Azure AD you can now turn on support for all the critical directory capabilities your application and server VM's need, including Kerberos, NTLM, Group Policy and LDAP.

We've seen incredible customer demand for this capability. It gives you the ability to take any on-premises application that depends on Windows Server Active Directory and run it in Azure Infrastructure Services without having to worry about running, maintaining or patching Active Directory Domain Controller VMs. This is also a HUGE milestone for us as a team. After years of work, we've reached the point where Azure AD is now a super set of Windows Server AD. This means our customers have a ton of new options and flexibility as they plan and deploy their enterprise IT resources across on-premises and the cloud. And maybe most exciting, it gives cloud forward companies the opportunity to go "cloud only" while still getting all the benefits of Azure AD and Windows Server AD. To share all the details of this new set of capabilities, I've asked Mahesh Unnikrishnan, the PM who drives our Azure AD Domain Services to write up a blog post, which you'll find below. Hopefully you are as excited about this new set of capabilities as we are. So let us know what you think! And as always, we'd love to hear any suggestions or feedback you have. Best Regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity Division < Update: 10/15/2015 - Unfortunately we found a bug in the preview and have had to turn off the UX to fix it. Sorry about that! That's what happens in previews sometimes. The service should be available again for preview by EOD Friday PST > ------------------------------------ Hi there! I'm Mahesh Unnikrishnan, a Program Manager in the Identity division at Microsoft. Today, I'm thrilled to introduce the preview release of Azure Active Directory Domain Services. As many of you know, analyst's estimate that Windows Server Active Directory (AD) is deployed by over 90% enterprises in the world. It is the world's most widely used corporate directory and in the 15 years since AD was first introduced, many organizations have developed and deployed hundreds and thousands of applications that rely on LDAP and other AD APIs such as System.DirectoryServices . Additionally, Active Directory's Domain join and Group Policy capabilities are some of the most widely used enterprise technologies on the planet. For most organizations they are the standard for managing the access and configuration policies for Windows servers and Windows clients. So it's no surprise that now that these organizations are looking for ways to use the cloud to improve their economics and deliver new competitive advantage, they are looking for ways to virtualize these applications and servers and move them into IaaS cloud services like Azure. Unfortunately, these legacy applications, many of which were developed by employees and contractors who no longer work at the company, don't support modern authentication protocols like OAuth2.0 or SAML. So rewriting them to use modern authorization protocols is prohibitively expensive. To work around this challenge, customers generally take two approaches:

• Set up a VPN/Expressroute to support a direct connection between these apps and servers deployed in their IaaS cloud service provider of choice and the on-premises corporate AD.
• Run domain controller VMs in their IaaS cloud service and have those domain controllers synchronize to their on-premises Active Directory servers using a VPN/Expressroute connection.

The approaches present serious challenges in terms of reliability, ease of administration and cost. In the first approach, transient network glitches frequently impact application availability. In the second approach, the costs can be substantial. Administrators need to manage DCs running in VMs – including patching, monitoring, troubleshooting replication, performing backups, ensuring high-availability and SLAs etc. We built Azure AD Domain Services because we saw firsthand the struggles customers were having here and we were pretty sure we could provide a simple, reliable, cost effective solution.

Introducing Azure AD Domain Services

Azure AD Domain Services provides managed cloud based domain services such as domain join, group policy, LDAP & Kerberos/NTLM authentication in the Azure cloud that are fully compatible with Windows Server Active Directory. With these services, you get the full value of Windows Server AD in the cloud domain, without having to deploy, manage, monitor and patch domain controllers. And because Azure AD Domain Services is part of your existing Azure AD tenant, users login using the same corporate credentials they use for Azure AD, and you can use existing groups and user accounts to secure access to resources.

How does it work?

Azure AD Domain Services works seamlessly with your Application VM's running in Azure regardless of whether your Azure AD tenant is cloud-only or is syncing with your on-premises Active Directory. Let's see how – with an example of each. Contoso, a cloud-only organization Let's start with Contoso, in this example a cloud-only organization with no on-premises identity footprint. Contoso already has an existing Azure AD tenant, which they rely on for access to cloud-based SaaS applications such as Office 365, Salesforce etc. Now, Contoso is looking to make it easy for their admins to manage workloads deployed in Azure Infrastructure Services. Those admins need to be able to use their corporate credentials to connect remotely to VMs and they want to use domain join and Group Policy to set configuration policy for these VMs.

Azure AD Domain Services for cloud-only organizations.

Contoso's IT administrator can enable Azure AD Domain Services for their existing Azure AD tenant. Then with a few clicks, they can connect it to the Azure virtual networks in which their workloads (SQL server, Windows virtual machines etc.) are deployed. Azure AD Domain Services then takes care of the rest – a fully managed domain is provisioned for Contoso and made available on the selected virtual network in Azure. All user accounts, credentials and group memberships in Contoso's Azure AD tenant are automatically available in this managed domain. Once that completes, Virtual machines in this virtual network can be joined to the domain and users can login to these virtual machines using their corporate credentials. Applications and servers deployed on virtual machines connected to the virtual network can take advantage of the benefits of domain services like LDAP read & bind, NTLM, Kerberos, and Group Policy. Note: LDAP write will be enabled in an upcoming update to this preview Litware Corporation, a hybrid IT organization But what if your organization's IT infrastructure is hybrid – with a mix of on-premises and cloud resources, including an on-premises Windows Server Active Directory? Let's use Litware Corporation for this example. In the example, Litware is an organization with a hybrid IT infrastructure and they already have their on-premises user accounts, groups and credentials synchronizing with their Azure AD tenant. Litware has deployed Azure AD Connect to perform this synchronization. As illustrated in the diagram below, Litware has already deployed their applications and servers in a virtual network in Azure Infrastructure Services. Litware's IT administrator can now enable Azure AD Domain Services for their existing Azure AD tenant and choose to make a managed domain available in this virtual network.

Azure AD Domain Services for hybrid organizations.

Just like before, Azure AD Domain Services takes care of the rest – a fully managed domain is provisioned for Litware and made available on the selected virtual network in Azure. All user accounts, credentials and group memberships in Litware's Azure AD tenant (which are in sync with their on-premises directory) are automatically available in this managed domain. This ensures users can sign-in to the domain using their corporate credentials. Administrators can provision access to resources in the domain using existing group memberships. And just like Contoso's apps, Litware's apps can take advantage of the benefits of domain services like domain join, LDAP read & bind, NTLM, Kerberos, and Group Policy. (It is important to note that for security reasons, this managed domain is a standalone domain and is not an extension of Litware's on-premises domain/forest infrastructure. However, all user accounts, group memberships and credentials from the on-premises directory are available in this managed domain.) In both cases, IT administrators do not need to manage, patch, monitor or troubleshoot their identity infrastructure in Azure. They can rely on Azure AD to provide domain services required for legacy applications to be deployed in Azure, all without the hassle of running additional AD VM's.

Getting started

Getting started with Azure AD Domain Services is easy. You can enable Azure AD Domain Services for any existing Azure AD tenant – the same tenant you use with Office 365 or other SaaS applications. Azure AD Domain Services are available for all SKUs of Azure AD – i.e. Free, Basic and Premium. You can also sign up for a free Azure trial to test this. Please refer to our detailed Getting Started guide for instructions to set up Azure AD Domain Services. The following is an abbreviated version.

Step 1 – Create the 'AAD DC Administrators' group

Using the Azure management portal, create a group called 'AAD DC Administrators' and add all users who need to be administrators on the managed domain to it. These administrators will be able to join machines to the domain and to configure group policy for the domain.

Step 2 – Select (or create) the Azure virtual network in which to enable Azure AD Domain Services

When enabling Azure AD Domain Services, you will need to specify which Azure virtual network you'd like to make domain services available in. Ensure you pick a virtual network that satisfies the following criteria:

• The virtual network belongs to a region supported by Azure AD Domain Services. See the region page for details.
• Ensure the virtual network is a regional virtual network and doesn't use the legacy affinity groups mechanism.
• Ensure your workloads deployed in Azure Infrastructure services are connected to this virtual network.

Make a note of the virtual network's name for use later.

Step 3 – Enable Azure AD Domain Services for your Azure AD tenant

Enabling Azure AD Domain Services for your Azure AD tenant is a simple process. Navigate to the Azure AD tenant and click on the 'Configure' tab of your directory. You will notice a new section titled 'Domain Services'.

Flip the toggle titled 'Enable Domain Services for this directory' to 'Yes' to see other configuration options.

Specify a domain name for the domain you're creating using Azure AD Domain Services. You may choose to use the built-in domain name (*.onmicrosoft.com) or any of the domain names available in the domains tab of your directory. Optionally, you can also specify a custom domain name by typing it into the textbox. In the drop down, select the virtual network in which domain services should be made available. When you are done, hit 'Save' at the bottom of the page. At this point, Azure AD Domain Services will start to provision a domain for your tenant and the page should display a 'Pending…' state. Under the covers, domain services are being provisioned and connected to the virtual network you've selected.

You will notice the IP addresses of the Azure AD Domain Services start to appear on the page as these come online. Azure AD Domain Services provide high availability and you should expect to see two IP addresses when the services are fully provisioned for your domain. It can take 20-30 minutes for the first IP address to be displayed and another 20-30 minutes for the second IP to be available.

Step 4 – Update DNS settings for the Azure virtual network

At this point, you can set these IP addresses as the DNS servers for the virtual network in which you had enabled Azure AD Domain Services. This enables virtual machines within that virtual network to 'see' the domain and connect to it for domain join, LDAP, authentication etc.

Step 5 – Enable synchronization of legacy credential hashes to Azure AD Domain Services

This is an important step that you need to complete in order to use the domain you have just created. By default, Azure AD does not store the credential hashes required for NTLM/Kerberos authentication. You need to populate these credential hashes in Azure AD so users can use them to authenticate against the domain. The steps involved in populating these hashes Azure AD Domain Services are different for cloud-only and synced tenants. Cloud-only tenants If your organization is a cloud-only Azure AD tenant, users that need to use Azure AD Domain Services will need to change their passwords. This step causes the legacy credential hashes required by Azure AD Domain Services for Kerberos and NTLM authentication to be generated in Azure AD and populated into Azure AD Domain services. You can either expire passwords for all users in the tenant that need to use Azure AD Domain Services or instruct these end-users to change their passwords. Users can use Azure AD's self-service password change mechanism from the Azure AD Access Panel page in order to change their passwords.

After users change their password, the hashes will be populated into Azure AD Domain Services. After the population is complete, users can then login to the domain using their newly changed password. Note that this is a one-time process and subsequent password changes will work automatically with Azure AD Domain Services. Synced tenants If your Azure AD tenant is configured to synchronize with your on-premises directory, you will need to ensure that you have the latest release of Azure AD Connect . Once you have Azure AD Connect running, you need to force full password synchronization using Azure AD Connect. This ensures that all users' credential hashes required for Azure AD Domain Services are synchronized to Azure AD. In order to force full password synchronization and enable all on-premises users' passwords to sync to your Azure AD tenant, execute the following PowerShell script on each AD forest. Update the values in the script based on installation paths in your environment.

$adConnector = "<CASE SENSITIVE AD CONNECTOR NAME>"

$aadConnector = "<CASE SENSITIVE AAD 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 $aadConnector -Enable $false

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $true

NOTE: Depending on the size of your directory (number of users, groups etc.), synchronization of user accounts, group memberships and credentials to Azure AD and then to Azure AD Domain Services can take some time in this preview. We're working to speed this up for GA.

Scenarios

That's it! Azure AD Domain Services should be configured for your Azure AD tenant. Try out a couple of scenarios including joining virtual machines in the virtual network to the domain, deploying applications that rely on LDAP read/bind etc. A few scenarios and use-cases you can try out with Azure AD Domain Services are listed on our documentation page.

Pricing

Azure AD Domain Services are available for all SKUs of Azure AD – i.e. Free, Basic and Premium. Azure Active Directory Domain Services usage is charged per hour, based on the total number of objects in your Azure Active Directory tenant, including users, groups, and domain-joined computers. Each tier supports a certain average user workload, as shown in the following table. More details are available on the pricing page for Azure AD Domain Services .

During preview, only the highlighted (5,001–25,000 objects) tier is available and is billed at 50% of the general availability price.

Tier/Number of directory objects 1, 2	Approximate supported user workload	Preview price 2	General availability price 2
Less than 5,000	~1,250 users	Tier not available in preview	$0.05/hr (~$37.20/mo)
5,001 to 25,000	~6,250 users	$0.10/hr (~$74.40/mo)	$0.20/hr (~$148.80/mo)
25,001 to 100,000	~25,000 users	Tier not available in preview	$0.40/hr (~$297.60/mo)
Greater than 100,000	Contact us	Tier not available in preview	Contact us

¹ All objects in the Azure Active Directory tenant are counted, including users, groups, and domain-joined computers. ² Directory size and hours are calculated and emitted on a daily basis. Usage is prorated to the minute.

Feedback

We're thrilled to deliver the capabilities available in this preview release of Azure AD Domain Services. We'd love for you to try out the service and share your feedback with us. This helps us refine the service and focus on developing features useful to your deployment scenarios and the types of on-premises applications you want to move to Azure. If you have a feature suggestion, please post it in the Azure Active Directory User Voice site and put "AADDS:" in the title of your suggestion. Thanks, Mahesh Unnikrishnan Principal Program Manager Microsoft Identity Division