What is Azure Domain Services?

Azure Active Directory (AAD) is, as I’m sure you know, the identity services in Microsoft Azure. Unlike Windows Active Directory (WAD) which has been with us since Windows 2000, AAD doesn’t use Kerberos for authentication since Kerberos isn’t suited for internet traffic and slow/unreliable WAN connection. Obviously the major drawback is that AAD can’t communicate directly with most of our current applications and systems.

To combat this drawback, Microsoft has released Azure Domain Services (currently in preview) which is a feature that allows one AAD to communicate with Kerberos over one virtual network. This is NOT a full version of WAD, it is only AAD made Kerberos-enabled which gives you access to a some of the features from WAD, most of them are read-only however.

This is essentially “domain controller-as-a-service”, so there is no FSMO roles, AD sites, Global Catalog, schema extentions and such to configure or troubleshoot. After deployment you get 2 IP addresses to use as primary and secondary DNS server, which in turn lets you communicate with AAD using Kerberos. This includes joining the domain with you servers and clients. This feature is not to be confused with Windows 10 Azure device join which it something entirely different.

Also I want to remind you that this feature is in preview so things are likely to change from what you can read here.

Implementing Azure Domain Services

Implementing Azure Domain Services is very easy.

  1. Create a group named “AAD DC Administrators” and join the user accounts you want as your admin account to this group. The members won’t be Domain Admins as we are used to from WAD, but this is as close as you get.ads0b
  2. In the Azure portal, find you AAD and under configure you’ll find this setting to enable Azure Domain Servicesads01
  3. When enabled you have to select your domain DNS name and which virtual network this AAD will provide Kerberos over. If this network has a site 2 site VPN, your AAD will be available to resources on-premises.ads2
  4. Notice this message, which says you need password synchronization in order to log on AAD using Kerberos. This also means that Federation is not supported. The procedure is different for cloud accounts and on-prem accounts, but the link in the message describes very well what you need to do, so I’ll just link it here.ads3
  5. Now you have to wait..a lot. Enabling this takes a long time, about 20-30 minutes. Eventually you’ll get the 2 IP addresses you need to use to reach your domain. You should add both as DNS servers in your virtual network in Azure. It will take some time before the vm’s in Azure are updated so you can either refresh the IP’s or give the servers a reboot.ads5
  6. I have a cloud-only user to function as my admin account, so before I can join my servers to the AAD, I have to reset its password to generate the hash (step 4) so I do so at http://myapps.microsoft.com where you find the change password option. (“Endre passord”, sorry this screenshot is in norwegian)ads9
  7. And finally my server has the correct DNS servers and it can join AAD as if it was an ordinary WAD. ads6










Taking a closer look at an AAD-joined server

After my server joined my AAD and rebooted it’s available for my AzureAdmin account. So let’s take a closer look on how this works. Starting at the local administrator group on my member server where you see the group we added in step 1 thereby giving me access to the server.












So naturally I install the RSAT for AD and Group Policy and start to play around.

First of all having a look at FSMO roles:



AD sites and services won’t show anything but an error, so nothing to see there.

AD domain and trust just shows us the usual information with no ability to change anything at all.

AD users and computers on the other hand is a little more interesting. Here we see the AAD OU structure and we have our users and groups from the Azure portal in “AADDC Users” and our newly joined member server in “AADDC Computers”. This view seem to be completely read-only and nothing can be changed or edited. Note there is no “Domain Controller” container.ads_aduc1








Turns out I can create a new OU on the domain level and in here I can create new groups and users which I can edit. As of now this seem to have no function at all as I can’t authenticate with this new user account and it doesn’t show up in the Azure portal.


Group Policy is even more interesting.









There are 4 GPO’s present Default domain and domain controller policy, plus AADDC Computers and AADDS Users (both linked to the OU with the corresponding name).  Those last 2 GPO’s can be edited so you are able to deploy some GPO settings to your domain joined computers and users. You can also change GPO links, enforce, block inheritance and change GPO Staus (disable all users or/and computer settings) However you can’t do any of the following:

  • Create new GPO or delete existing ones
  • Change GPO security filtering
  • Create WMI filters
  • GPO links












DNS: Your account will not have any DNS server rights so trying to connect a DNS console againt the DC will only throw an access denied error.

Add domain controllers: No, you can’t promote an azure vm as an additional Domain Controller 😉


I think Azure Domain Services is a curious thing, while being far from a replacement for you WAD, it does provide the ability to join servers and clients to an AAD and communicate with each other using Kerberos. You can of course use it as if it was a normal WAD, but the management of both users and computer are very limited. Communication using Kerberos is the whole point of this feature and it should open up some new possibilities in both hybrid environments and perhaps also during migration from on-premises to cloud. Another possible application for this feature could be in combination with Azure Remote App.

Again this feature is in preview so I’m sure the re will be changes coming, probably based quite a bit on user feedback.

Enable immediate replication between AD sites

What is immediate replication?

Active Directory has 3 replication models:

  1. Within a site (Intrasite) the domain controllers use Change Notification to alert adjacent dc’s of changes made in AD. By default, after 15 seconds the first replication partner is notified and 3 more seconds to each subsequent replication partner.
  2. Between sites (Intersite) Change Notification is not used. Replication only happens on a schedule with every 15 minutes as the shortest configurable interval.
  3. Account lockout, changes to password policy, DC password changes and a few other situations trigger urgent replication which happens as quickly as the domain controllers are able and bypasses all other replication interval.

The intersite replication can however be configured to use Change Notification and this will bypass the replication schedule of the site link and replication will occur as if the domain controllers were in the same site. This does of course increase the traffic of you WAN link so make sure you have the bandwidth and latency to handle it.

How to enable immediate replication

The procedure is slightly different for automatically and manually changed sitelinks

For automatically created sitelinks:

  1. Open ADSIEDIT
  2. Connect to Configuration Naming Context
  3. Expand Sites –> Intersite Transport –> IP
  4. Right-click the relevant sitelink and select properties
  5. Change the value of “options” to 1


For manually created sitelinks:

  1. Open ADSIEDIT
  2. Connect to Configuration Naming Context
  3. Expand Sites –> (The site name) –> Servers –> (Servername) –> NTDS Settings
  4. Right-click the relevant sitelink and select properties
  5. Change the value of “options” to 8
  6. Repeat for every manually configured sitelink (if desired)


That’s all there is to it. Changes in AD will now flow as if the domain controllers are within the same site.