So thinking about moving from on-premises Active Directory and moving towards using Azure Active Directory Domain Services in Azure? For those that aren’t aware Azure AD Domain Services is a PaaS service that Microsoft delivers in Microsoft Azure which is essentially Managed Active Directory. Now in most scenarioes, Active Directory is the authoritative source for identity and then we have Azure AD Connect which syncs out users to Azure AD, therefore all changes needs to be done in Active Directory.
Now with Azure AD Domain Services, Azure AD is now the main identity source. You make users in Azure AD and then the user is synced into Azure AD DS. Azure AD DS is intended as a simpler way to manage AD instead dealing with setting up an Active. Azure AD DS is integrated into a virtual network, so that you can connect other IaaS servers to a regular AD domain. You can see all the features that are provided here –> https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-features
Note: That when deploying Azure AD Domain services it should be placed within a seperate Subnet and when you associate an NSG with a subnet in which Azure AD Domain Services is enabled, you may disrupt Microsoft’s ability to service and manage the domain. Additionally, synchronization between your Azure AD tenant and your managed domain can be disrupted. The SLA does not apply to deployments where an NSG has been applied that blocks Azure AD Domain Services from updating and managing your domain.
Some issues that you need to be aware of:
We have encountered some issues that I want to highlight which you should consider before doing a “move” to Azure AD DS compared to setting up Active Directory as regular virtual machines. Now most of the limitations are listed here –> https://docs.microsoft.com/en-us/azure/active-directory-domain-services/comparison however there are few which I want to highlight.
- Does not support Hybrid scearioes or multiple regions
This is of course something that you need to be aware of is that Azure AD DS does not support a hybrid scenario where you might have some on-prem active directory domain controllers or multiple azure regions where you have other domain controllers. Because of the limitations of AD DS you cannot add more sites or add more domain controllers to the setup.
- Password time set to default 90 days
By default the password policy is set to 90 days in Azure AD DS regardless of the password policy in Azure AD. This means that users can get stuck with two passwords, one for Azure DS and one for Azure AD. You cannot change the default settings directly so you need to define fine grained password policies to ensure that users don’t need to change passwords every 90 days https://docs.microsoft.com/nb-no/azure/active-directory-domain-services/password-policy
- No support for NPS Server Roles
This is something that we can across when trying to setup with Azure MFA with NPS Extensions, since this requires an NPS Server to get authorized in Active Directory which is also not something that is supported with Azure AD Domain Services since you do not have Enterprise Admin rights. So therefore you cannot setup NPS Server and integrate it into Active Directory.
- No support for AD PKI
This is also another scenario that is not support with Azure AD Domain Services if you require AD integrated AD CS, which might be the case if you require for instance Direct Access and auto enrollment or Citrix FAS which also requires and AD integrated PKI, which is not supported.
- No support for setting SPN and Kerberos Delegation
On an Azure AD Domain Services managed domain, you do not have domain administrator privileges. Therefore, traditional account-based KCD cannot be configured on a managed domain and you would need to use resource-based KCD. In order to use KCD on a managed domain you would need to move the affected objects either users or machines to a custom OU.
- Create a custom OU. You can delegate permissions to manage this custom OU to users within the managed domain.
- Join both virtual machines (the one running the web app and the one running the web API) to the managed domain. Create these computer accounts within the custom OU
- Now, configure resource-based KCD using the following PowerShell command:
- $ImpersonatingAccount = Get-ADComputer -Identity contoso100-webapp.contoso100.com Set-ADComputer contoso100-api.contoso100.com -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount
- You need to configure DNS Forwarder
When setting up the default managed domain, the managed domain controllers will not have a DNS forwarder configured. This is not a limitation, but something you need to be aware of since you need to add a DNS forwarder –> https://docs.microsoft.com/en-us/azure/active-directory-domain-services/manage-dns and just add The Azure DNS IP address is 168.63.129.16 for instance.
- Be careful which domain you use
One thing you need to be aware of is when you create a Active directory domain you need to specify a managed domain name. If you just use the default managed domain which might be companyname.com which can create routing issues for the internal virtual machines if the internal DNS AD controllers have that specific zone name resolution. Here are some guidelines for which type of FQDN you should choose.
- Built-in domain name: By default, the wizard specifies the default/built-in domain name of the directory (with a .onmicrosoft.com suffix) for you. If you choose to enable secure LDAP access to the managed domain over the internet, expect issues creating a public DNS record or obtaining a secure LDAP certificate from a public CA for this domain name. Microsoft owns the .onmicrosoft.com domain and CAs will not issue certificates vouching for this domain.
- Custom domain names: You can also type in a custom domain name. In this example, the custom domain name is contoso100.com.
- Non-routable domain suffixes: We generally recommend avoiding a non-routable domain name suffix. For instance, it is better to avoid creating a domain with the DNS domain name ‘contoso.local’. The ‘.local’ DNS suffix is not routable and can cause issues with DNS resolution.
- Domain prefix restrictions: The prefix of your specified domain name (for example, contoso100 in the contoso100.com domain name) must contain 15 or fewer characters. You cannot create a managed domain with a prefix longer than 15 characters.
- Network name conflicts: Ensure that the DNS domain name you have chosen for the managed domain does not already exist in the virtual network. Specifically, check whether:
- You already have an Active Directory domain with the same DNS domain name on the virtual network.
- The virtual network where you plan to enable the managed domain has a VPN connection with your on-premises network. In this scenario, ensure you don’t have a domain with the same DNS domain name on your on-premises network.
- Configuring SSO within the managed domain
Now with most setup’s these days you have Azure AD connect configured with either Active Directory Federation Services or configured with Azure AD Passtrough authentication. It should also be noted that this is not supported for domain services either –> https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta-current-limitations so if you want to have SSO within the managed domain, Azure AD Domain Servics is a bad fit and will cause you some issues. For instance if you are providing a virtual desktop within a Azure AD DS enviroment with Office 365 using Shared Computer Support, it will not work because you will not have a way to provide SSO to Azure AD.
- What about redundancy?
It is important to remember that Azure AD Domain Services is bound to a single region, and therefore is not geo-redudant.
Monitoring Azure AD DS
When it comes to monitoring Azure AD DS there is limited capabilities. You can configure email notifications –> https://docs.microsoft.com/en-us/azure/active-directory-domain-services/notifications or you can see the health from the service portal –> https://docs.microsoft.com/en-us/azure/active-directory-domain-services/check-health but you cannot have any monitoring agents installed on the domain controllers so what you can do is have an internal agent probe installed on another vm to probe the domain controllers on the different ports such as
- SMB over IP (Microsoft-DS): port 445 TCP, UDP.
- Kerberos: port 88 TCP, UDP.
- LDAP: port 389 UDP.
- DNS: port 53 TCP, UDP.
So what’s new?
Well not much has happened on this service since last year https://azure.microsoft.com/en-us/updates/?product=active-directory-ds only some preview features for integrating this service with Azure Files, which shows that Microsoft is not investing much into this service, they want to move more services into native Azure AD and move away from the legacy AD architecture.
Should we use it?
I would only recommend using Azure AD Domain Services if
- You have some services that require LDAP/AD Integration
- You need to have some virtual machines that require AD integration.
I do not recommend using Azure AD Domain Services if you are building a fully IaaS Windows based enviroment in Azure, since you can potentially encounter one of more of the limitations above which will affect what kind of services you can implement.