Get started with Azure AD Domain Services

Tutorials

/

Posted on

October 30, 2015

Azure custom domain, Azure DNS and Azure Active Directory Domain Services (Azure AD Domain Services).

Ok, this will be a blogpost on three services within Azure. They are all independent on each other, but my end goal here is to set up Azure Active Directory Domain Services (Azure AD Domain Services) so we can build and deploy IaaS Windows servers and have them joined to a Active Directory domain and use our Azure AD tenant (cloud only) users.

Background

A customer developing applications on the Microsoft plattform needed a way to quickly deploy and destroy Windows VMs and have a centralized directory for user access to the machines.

Problem

To able to have a centralised directory for users that works for Windows servers you need Active Directory. That means that you actually need at least one Windows server running the DC role. And that means using accounts within that AD. But they wanted to use accounts from their Azure AD tenant.

Solution

Using the newly announced PaaS service Azure AD Domain Services (still in preview and only enabled in the following locations) we can use users from the Azure AD tenant and have deployed servers joined to the PaaS service domain. This eliminate the need for having a traditional AD installed, and we can use users populated in the Azure AD tenant instead. Bazinga!

In short what we will do..

  • Configure Azure DNS for a new public domain
  • Configure a Custom Domain for the Azure AD directory (a domain better than somethingshitty.onmicrosoft.com)
  • Deploying new infrastructure and a Windows server to Azure with ARM
  • Creating and configuring Azure AD Domain Services
  • Creating a new user and have that user join a Windows VM to the new AD.

Let's create a custom domain.

Log in to old Azure portal and to Active Directory --> Your Directory --> Domains

azurecustomdomain

Hit Add, and enter your domain name.

specifyazurecustomdomain

Now we need to verify that we actually have control and own that domain.

verifyazurecustomdomain

We need to create a TXT record for our domain. But first we will move the domain to Azure DNS (don't do this if you already have DNS hosting provider and still want to use it).

We are going to have the domain reazure.se hosted at Azures anycast DNS servers. To do this we use PowerShell in ARM mode.

Go get a cup of coffee while the new NS settings for your domain are being replicated. Verify that the NS records and the TXT record for your domain is present.

Edit your domain at your registrar to point to your new NS records. Now verify the TXT record:

Now you can verify your custom domain.

azurecustomdomainverify

On to creating Azure AD Domain Services. Start with creating a Resource Group and a Vnet within one of this locations.

Log in to old Azure portal and to Active Directory --> Your Directory --> Groups. Create a new group called "AAD DC Administrators" (yes, exactly that name).

Jump to the Configure page on the directory and scroll down to domain services. Check the Yes box, and choose the domain and the vnet. Save.

azuredomainservices

Kick back and relax while your AD Domain Services is created (it can take a couple of minutes). When its done, go back and create a new user in the AAD DC Administrators group as a global admin with your new domain. (change the temporary password) at for example myapps

To be able to join a Windows VM to the Domain, the user needs to be present within that group.

Now we have a custom domain that is configured in the Azure directory, the DNS is hosted at Azure DNS and Azure AD Domain Services is enabled.

Let's try to join a Windows VM to the new PaaS domain service.

joinazuredomain
joinedazuredomain

No problem here. Just a quick look in what we can see in the domain

ADDS

Thats pretty much it. A nice PaaS solution where you don't need to set up a traditional Active Directory domain.

Pros

  • No need for virtual machines hosting your Active Directory
  • Use the same groups and users as in your Azure tenant for your virtual machines.
  • Passwords from your Azure tenant is replicated to your domain (SSO)
  • Good for automation and deployment of virtual machines in a dev/test environment without the hassle of authentication

Cons

  • Limited to one domain per Azure AD directory
  • Limited and tied to only one vnet in Azure
  • Only works in ASM (Azure Service Manager) and not ARM (Azure Resource Manager)
  • No way of having users from other Azure AD directories.

Written by

Jonas Erikson