Since the evolution of Azure active directory, it has become a popular identity management solution on Azure but note, it is just an identity solution and does not provide all the features that Windows Active Directory offers; e.g., domain controller Services, certificate Services etc.
Typically, if your organization’s workstations, Servers and devices need to be joined to your domain, you will need to provision your On Premises domain controller and then each device will be joined to the domain but wait, before we move ahead with this, let’s dive deep into a few core concepts.
What is a domain?
Well, the existence of each thing has some definite meaning andthe same applies to the domain. Domain concept was introduced so that an individual user can be granted an access with the set of permissions to the multiple computer resources with the same credentials. In a nutshell, domain is a logical grouping of the computer resources, sharing central directory of the users. This directory is known as Active Directory.
What is a domain controller?
Domain controller is nothing but a Windows based computer containing a central directory of the users, best described as the centerpiece of the active directory. Since the domain controller is Windows based operating system machine, so all other computer resources in a domain also need to have a Windows based operating system.
What are domain services?
Now, as described above, the centerpiece of AD i.e. domain controller is responsible for providing the set of services to all the resources within a domain are called as domain Services. Now, these Services can be security policy enforcement, access control, user authentication etc.
Now, with these basics, let’s go ahead and see what Azure Active Directory Domain Services is.
The idea behind having the active directory domain services is as simple as having your domain controller in the Cloud and using its Services online. It means, when you create Azure active directory and provision users in it, all those users have their ‘*.onmicrosoft.com” domain, associated with them. Now, your computer resources like Servers and workstations can be brought into this *.onmicrosoft.com domain and let your Azure AD users sign in to these resources, using their Azure AD credentials.
Now, if you are not happy with this default *.onmicrosoft.com domain and already have your own custom domain, you can use your domain and bring your resources on your custom domain.
Let’s see, how we can leverage and configure ADDS.
Configuration of ADDS is usually 5 stepped process.
- Create Azure AD and configure administrative group.
- Create Azure VNET.
- Enable and configure ADDS.
- Configure DNS for VNET created in step 2.
- Validate Domain Services and Administer your on cloud DC.
Let’s see each step in detail.
First things first,
Azure ADDS service is currently in preview and requires that the virtual network should be in the same region where ADDS Services are available. Also, VNET has to be created in the classic mode, as currently, ADDS does not support ARM based VNETs.
For this article, we will be creating our AD and classic VNET in the Eastern US, where ADDS is available.
List of available azure services by region can be seen here - Services by region.
Create AD and configure administrative group.
Let’s start from scratch and crate a brand new Azure AD with the name ‘alphacorpinc’. Currently, Azure AD management operations are supported only through the classic Azure portal.
It opens up a modal dialogue, asking to enter the metadata for your new AD like the domain name. We will give the same domain name as AD name as ‘alphacorpinc’ and will not select the last checkbox for specifying B2C directory.
Click OK and it starts provisioning your new AD in Azure.
Now once the AD is created, we will need to create a group. Please note that this group creation is a mandate and the group only with the name “AAD DC Administrators” has to be created. Members of this group will be provided special rights and will be added to administrator group of the domain joined machines automatically.
We will create a user in Azure AD in a “User” role and will add the user in the group, mentioned above.
To create a user in AD, navigate to the Azure AD and click Users tab. Select Add from bottom action bar.
Next screen will give you an option to generate the temporary password. Copy the generated password and log in to Azure portal with the user credentials i.e. [email protected], where you will be asked to create new password for this user. Make a note of this new password, as we will be needing it in the next steps.
Now, let’s create a group, mentioned above, and add this newly-created user in the group.
To create a group in Azure AD, click Groups tab and select Add Group from the bottom action bar.
Click OK and add the user, which we just created in the group.
We are done with step 1. Let’s proceed to step 2.
Create Azure Virtual Network
As we need to create a network, while provisioning On Premises DC or DC on a VM, which acts as a logical boundary for the resources i.e. all the resources belonging to this network can be brought on to the domain and can establish communication to DC.
As mentioned above, this has to be a classic VNET, since ADDS currently only supports classic VNET and it has to be in the region, where ADDS Services are supported.
To create a new VNET in Azure, click new and select Virtual Network. We will name our VNET as ‘AlphaCorpVNet’.
Note, we selected DNS Server option as ‘None’ and we will be updating it later, once we enable ADDS in the next step.
Enable and configure ADDS in Azure AD
Let’s navigate back to the Azure AD created in step 1. Select Configure tab from the top on your AD home page.
Find the section Domain Services and select ‘Yes’ option for setting ‘ENABLE DOMAIN SERVICES FOR THIS DIRECTORY’.
Once you enable the ADDS option, you will be asked to choose the domain name and VNet. The domain name option lists all the registered i.e. the verified and unverified domain names of Azure AD.
Click save and it will enable ADDS for Azure AD.
Note that the DNS domain name of domain services dropdown contains the default AD domain, you can either keep it or change it to your desired domain name. If you have added your custom domains (verified and unverified both) in the AD then those will be shown in the dropdown too. You will not be able to change this once you click save and once domain services are enabled.
After a few minutes, you will be able to see the DNS Server addresses coming up on the same page of Azure AD i.e. configuration tab. The reason it takes a few minutes to show those IP addresses to you is because in the background, it provisions and configures the domain controller Server and once it is ready, it comes back with DNS address.
Take a note of these DNS Server addresses, which we will be using in ‘AlphaCorpVNet’.
Configuring VNET with ADDS DNS
Navigate to the AlphaCorpVNet and click configure tab.
Add both DNS entries obtained from Azure AD configuration page, as DNS Server for VNET. Save the VNET settings.
Validating and administrating ADDS
Once the entire set up is ready, now it is time to validate whether the ADDS setup is working or not. Best way to do this is by provisioning a domain joined virtual machine in Azure.
Let’s create a classic mode i.e. IaaS v1 virtual machine and we will try to bring it on the alphacorpinc domain. Note, we will need to create VM in same Vnet, where ADDS DNS is updated i.e. in AlphaCorpVnet.
Once the VM is created, login to it, using RDP, via local administrator account, specified during the VM creation.
In Server manager, select local Server node from left and click the workgroup name.
Select Domain and enter the domain name. You should be able to get the credential prompt, after clicking OK button, if VM is able to find DNS, if not, then as an alternative, you can set the preferred DNS address of the VM by modifying the network TCP IP properties and set ADDS DNS address, as preferred.
After clicking OK and closing, you will be disconnected from RDP session.
Restart the VM from Azure portal and log in to RDP session again.
Now, repeat the step, in order to join VM to the domain from workgroup by going to the Server manager. You will be asked for the credentials to join VM to the specified domain.
Specify the credentials of a user, which we created in step 1 and added to the group ‘AAD DC Administrators’.
After successful authentication, VM will be joined to the domain and the message, given below, can be seen.
(Please note, if you have recently updated the credentials of the authenticating user, it might take some time to reflect the updated password).
Restart the VM and now, you will be able to log on to the VM with your Azure AD user, which proves that ADDS setup has been correctly setup and is in place.
Administer ADDS
By now, some of you might be wondering that athough I have ADDS set up in place and machines are joined to the domain, but where can I configure the settings of my domain on the domain controller, which is running on the Cloud?
Well, you are right and that’s the valid question. There are two ways to do it.
Since we have just joined a VM to the Azure AD domain, let's see the details of the second approach.
Log in to the domain joined VM, using the credentials of a user added in ‘AAD DC Administrators’ group of Azure AD.
Open Server Manager and click Add roles and features. Navigate to the features selection dialogue and select the features, given below:
Click Next.
This basically enables the access to Active Directory Administration Tools.
Once the installation is complete, open up AD administration center.
It may look like:
Click the domain name, shown on the left and navigate to the AADDC Computers.
You will be able to overview and manage all the domain joined VMs from this console.
Like I mentioned before, ADDS currently supports only ASM based VNETs i.e. classic VNETs. Thus, only classic mode VMs can be joined to the domain but what is the workaround to join ARM based VMs to Azure AD Domain? We will be seeing it in the upcoming article by leveraging the peering concept of VNETs.