What is AAD?

Microsoft Azure Active Directory (AAD) underpins identity and authentication within the Azure suite of services. AAD is the cloud version of Windows Server Active Directory Domain Services (AD DS). It provides authentication and authorization (access control) to other resources. Office 365 for example, uses Azure Active Directory for authentication and authorization of client applications such as Outlook.

Although Azure Active Directory (AAD) and Windows Server Active Directory Domain Services (AD DS) serve the same purpose, there are differences in the protocols they use for external communication. AAD was specifically designed to support web-based services. The protocols available to us are SAML, Oauth 2.0, graph API. On the other hand, AD DS offers a different set of protocols – LDAP and Kerberos – which are typically used for legacy applications that haven’t caught up yet.

What’s the problem?

So, before AADDS, if you needed to install an application in Microsoft Azure cloud, and required LDAP function, you had two options. You could either install a new domain controller or reuse an existing domain controller.

Customers with existing domain controller(s) have no issues, as they may have already set up Azure AD Connect and other components. Exposing the LDAP requires only a few networking changes.

However, if you are a cloud only customer in Office 365, installation of a new domain controller is a laborious task. For example, you need to establish the necessary reverse “sync” attribute from Azure AD to the domain controller in Azure, combined with the installation of AAD Connect to sync your AD users back to Azure AD again.

A workaround: Azure Active Directory Domain Services

Given the complexity of this solution, Microsoft has introduced Azure Active Directory Domain Services (AADDS) to bridge the gap between a traditional hybrid environment and Office 365 only deployment.

What is Azure Active Directory Domain Services (AADDS)? Essentially it is ‘AD-as-a-service’. Enabling the service with a given subscription results in deployment of two domain controllers (with random names). You won’t have domain admins rights, but you will have domain join rights as well as LDAP, NTLM and Kerberos authentication rights.

The method described above is explained in greater detail in Azure Blogger.

Exposing services

However, AADDS only exposes LDAPS to internet-facing applications or clients. So for authentication purposes you can point your application directly to the LDAPS IP address provided and it will behave as a normal LDAPS server.

Regular LDAP (port 389) however is not supported. In order to expose LDAP to Internet, you’ll need to deploy a virtual appliance load balancer like free Virtual Netscaler. A regular Azure load balancer cannot be used in this case. It’s also important to note that access to your Public IP for LDAP can be protected through the use of Network Security Groups. This will ensure only authorised source IPs can utilise the service.

The above diagram illustrates using an application such as Meraki to access LDAP. Using a load balancer, you could apply NSG to protect which IP address will access the LDAP.

However, there are still fundamental differences between a real Active Directory and Azure Active Directory. For example, the LDAP functions in AADDS only support read, not write. A more detailed comparison between AD and AAD is available here.

Conclusion

Microsoft has extended its identity suite to offer us greater flexibility when tailoring a solution to our specific requirements. Now, environments without a traditional investment in Active Directory infrastructure can expose LDAPS. Microsoft has provided plenty of more use cases here. Your choice will ultimately be around the cost vs. benefit of each available option.

This is one step to closer to a cloud-only tenant. Sooner or later, you’ll be able to stop running your Domain Controller on-premises.

This article has helped immensely, although I’m still stuck as how to expose regular LDAP through port 389. Is it still the case that I would need to deploy a third party load balancer? I’m trying to control access to client-to-site VPN through a Meraki network switch using Azure MFA and AADDS.