Get ready because this is going to be a long and interactive article.
Azure AD Domain Services is a PaaS offering in Azure that can either extend your on-premises Active Directory infrastructure or creating an entirely new Active directory domain services environment to manage user and device identities.
Azure AD Domain services can work hand in hand with Azure AD to extend management capabilities in Azure. It can also be in standalone mode; however, most enterprises would prefer to sync with Azure AD since they might be in a situation where they're migrating their existing on-premises environment or need to take advantage of Azure AD features such as App registrations, MFA e.t.c and hence have to use tools such as Azure AD connect.
Below is a diagram of how the architecture could be laid out.
To get started with Azure AD DS, you need to set up an Azure virtual network and a subnet within that virtual network.
Next, we start creating a new Azure AD Domain Services instance. I have selected the Enterprise SKU and forest type of resource because I want to take advantage of features such as creating forest trusts in the future. These kinds of features are not available in the Standard SKU. Please attach it to our virtual network and then select the subnet.
On the next page, we select the group membership and add our existent Global administrator to act as the Active Directory Domain services administrator.
On the next step, we scope out all incase we want every object change in our on-premises Active Directory to Azure AD replicated. Then, take note of the settings that can't change after creating this instance and then click create.
This operation can take 45 minutes to an hour and sometimes can even take up to 2 hours max as per the Microsoft service creation time out the window.
In the next part, we will join a new Windows server VM to our new Active directory domain services server. To accomplish this, we shall configure the following settings.
Browse to our service and configure the DNS settings such that the DNS Servers of our VNet on which the domain service is, are configured with the private IP Addresses of our domain service.
You can confirm the change by checking the DNS settings of the VNet, which changed from Azure-provided DNS to Custom.
Next part, we will connect our Windows server 2016 VM to the same VNet that our Azure ADDS is and then log into the VM to add it to the domain.
Now this will fail because of the reason that Azure ADDS doesn't support the legacy password hashes that are supported on On-Premises Active directory environment and Azure AD using Azure AD Connect ("A lot of AD buzzwords, huh!")
And you can see an error thrown as above. The way around this is by regenerating a user password in Azure AD such that it's supported by our new Instance of Azure ADDS.
After changing the password in Azure AD, you can see that we can successfully join the computer to the domain, and that means we can always log into that machine using the Azure AD credentials.