Get ready because this is going to be a long an 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 were 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, note that I have selected the Enterprise SKU and forest type of resource because I want to take leverage of features such as creating forest trusts in the future. These kind of features are not available in the Standard SKU. Attach it to our virtual network and then select the subnet.

Dis regard the subnet in this image and use your own 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 each and every object change in our on-premises Active directory to Azure AD replicated. Then below take note of the settings that can not be changed after the creation of this instance and then click create.

This operation can take 45 minutes to an hour and sometimes can even take upto 2 hours max as per the Microsoft service creation time out window. Hahah, anyways sometimes these time out window errors happen when you deploy the service to a given region that it's not currently supported or even a supported region, Microsoft only knows why sometimes this fails so you'll have to contact support.

Part Two

In the next part we are going to 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.

This change can be confirmed by checking the DNS settings of the VNet which changed from Azure provided DNS to Custom.

Next part we are going to connect our Windows server 2016 VM to the same VNet that our Azure ADDS is and then we log into the VM so that we can 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 ("Alot 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.