The Evolution of Traditional Authentication

Early this month, Microsoft officially announced that they have released another preview feature for their Azure IaaS solution stack, Azure Active Directory Domain Services.  This is a clear evolution of the way traditional Microsoft AD administrators install/configure/manage legacy Active Directory.  Although there are currently some limitations that I’ll talk about later, this is an exciting step toward removing the need to maintain legacy configurations and more seamlessly integrate with cloud hosted services. So, let’s take a look at a very basic configuration.

Enabling Domain Services on Azure Active Directory

As it’s not the direct purpose of this blog post, I am not going to write a how-to for creating an Azure Active Directory instance, but rather I will refer you to a great blog post by a good friend, Keith Mayer, who has already detailed this process to perfection.  Go have a look here, it’s worth the time (you’ll get the added bonus of understanding enabling multifactor authentication too)! Once you have your Active Directory instance established, here are the steps to enable the new Domain Services.

Step 1:

To enable Domain Services for this directory you will need to, well, “enable Domain Services for this directory”.  First, browse to the configure tab under the selected directory:


Step 2:

Scroll down to the “Enable Domain Services for this directory” section and click “Yes”:


After some period of time, the domain will be created and ready to provision with the following information available via the Azure Management Portal:

  1. DNS domain name of Domain Services – This is the FQDN of the Domain we are configuring
  2. Connect Domain Services to this virtual network – You will have to either create a new virtual network or use a virtual network you already have in your environment.
  3. IP address – This is interesting: this is the address(s) for the new virtual machines/domain controllers that are created when this feature is enabled.

Step 3:

Because all services in an Active Directory environment are located via a series of DNS lookups, we need to configure our virtual network with the appropriate DNS settings.  Fortunately for us, this is incredibly simple.

3a. Browse to the previously selected virtual network, configure and scroll down to “DNS servers”:


3b. Create a new DNS entry using the IP address created in step 2.  These IP addresses are the DC/DNS server(s) that will be required to resolve the domain name from the machine(s) you will join to this domain later.

Step 4:

Next we need to create a group and user.  Until this happens, you will not be able to join machines to the domain or have any real access in the domain.

4a. Select the appropriately Active Directory instance and select users:


4b. Create a new ADS Administrator user. The user needs to be created with the exact spelling:


4c. Create a new AAD DC Administrators group and add the ADS Administrator user to that group. The group needs to be created with the exact spelling:


Step 5:

Create an Azure VM and join it to your newly created Domain with your newly created credentials.  Congratulations, you have enabled the next evolution of Active Directory!

Things to Keep in Mind:

Here are a few of the current limitations, from a Microsoft Support page:

  • Managed domains provided by Azure AD Domain Services support only a flat OU (Organizational Unit) structure. All domain-joined machines reside in a single flat OU and hierarchical OU structures are not supported.
  • Azure AD Domain Services supports simple Group Policy in the form of a built-in GPO each for the users and computers containers. You cannot target GP by OU/department, perform WMI filtering or create custom GPOs.
  • Azure AD Domain Services supports the base AD computer object schema. You cannot extend the computer object’s schema.

So, in its current form, is this preview a 100% replacement for a legacy deployment of Active Directory Domain Service? No, it’s not, but as a business professional who has their finger on the pulse on the identity management space, it sure might be the future of how we deploy core Microsoft identity, authentication, and access services.  Put a check for me in the box of “excited about the possibilities.”

Phone: 312-602-4000
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons