Small- and mid-sized enterprises (SMEs) have some of the same IT needs as larger enterprises. Unlike large companies, however, SMEs usually do not have a separate department to look after internal IT. This work is either outsourced to external service providers or an employee performs the task on the side.

To deal with various compliance issues and to simplify the management of user access and devices, central directory services such as the Lightweight Directory Access Protocol (LDAP) or Active Directory have become increasingly widespread. Although a full-blown Active Directory was once considered a tool needed only by huge company infrastructures, small Active Directory setups can now also be found in companies with around 10 or more employees. The problem is that an Active Directory setup is hardly less complex today than it was a few years ago; if anything, it has become even more difficult.

As a central directory service, Active Directory also has a central relevance. If all user logins rely on Active Directory, they will not work if it is not available. Therefore, administrators see themselves confronted with the issue of needing high availability, even though it is often impossible to achieve on site because typically no data center infrastructure is available and the server with Active Directory might be hidden away in a broom closet.

Microsoft's focus on the cloud in the form of Azure could provide a solution. Lo and behold, if you scroll through the product portfolio, you will find Azure Active Directory (Azure AD) [1]. However, because of how it is structured, Azure AD is not the classic directory service that you know from your local Active Directory, even if the name suggests a relationship with its namesake from the on-premises world. The difference between the two is easy to see because Microsoft exclusively offers Azure AD as a managed service (i.e., as a Platform-as-a-Service (PaaS) or Software-as-a-Service offering (SaaS)). The user does not even find out where the service is running or what the underlying system looks like.

The primary task of Azure AD is to store combinations of user names and passwords and make them available to other services and applications over defined standard interfaces (e.g., in the context of OAuth). Indeed, the functional scope of Azure AD is more similar to the idea of a central vault for user data with a cloud connection than to that of a central directory service.

The good news is that Microsoft now also offers a "real" Active Directory in its cloud – Azure Active Directory Domain Services (Azure AD DS, sometimes called AAD DS) [2] – although it is far less in the spotlight than Azure AD. In this article I look at how admins in smaller companies can benefit from Microsoft's directory services in the cloud, how Azure AD and Azure AD DS differ, whether Server Message Block (SMB) IT managers can get rid of the annoying issue of Active Directory operations by migrating the service to the cloud, and which service is the best fit for various use cases.

Away with Old Habits

The Azure AD design is not a coincidence or the result of incompetence by those responsible for it at Microsoft. Azure AD was designed from the start to be exactly the service it is today. And Microsoft took the opportunity to drop off some of the legacy ballast that Active Directory is still dragging along with it today, as a look at the protocols used quickly shows. Although Active Directory still uses some of the same protocols it did several decades ago, Azure AD is primarily accessed through API interfaces according to the REST standard.

On the one hand, this design makes it far easier for Microsoft to connect Azure AD to other cloud services and applications. The company makes it abundantly clear how this works with its own cloud applications: Microsoft 365 (formerly Office 365), for example, can be operated fully with users from Azure AD. On the other hand, this design also means that Azure AD is unsuitable as a replacement for the local Active Directory because it lacks a great deal of functionality (Figure 1). Computers cannot be integrated into a domain in Azure AD, not least because Azure AD does not implement the domain concept. If you want to assign rights by group policies, you are out of luck because they do not exist in Azure AD – nor do LDAP, NT LAN Manager (NTLM), or Kerberos. Moreover, the hierarchy provided in Active Directory, which enables organizational units (OUs), is also completely missing in Azure AD.

Figure 1: Azure AD is a kind of password vault for the cloud with connectivity to many other services, but it is not a full-fledged replacement for Active Directory.

What does work with Azure AD, however, is the single-source-of-truth principle when it comes to user access, because Azure AD provides a way to synchronize users and passwords from existing Active Directory setups. When companies use software that can attach to Azure AD as an authentication and authorization service, synchronizing the on-premises Active Directory with Azure AD allows the same user base to be used everywhere. Microsoft even offers a way out for applications that cannot talk to Azure AD directly: The Azure Application Proxy can be deployed upstream of conventional web applications but communicate with Azure AD in the background. If the user name and password match, the application proxy forwards the client to a secure website (e.g., by HTTP authentication) and receives the correct combination of user name and password from the application proxy.

Almost Like a Local AD

A quick look at the Azure AD DS feature list gives Microsoft administrators that cozy feeling of being at home far more than is the case with Azure AD. In practical terms, Azure AD DS is a domain controller redundantly operated by Microsoft in the Azure cloud; it handles most of the familiar functionality of local setups in the usual way. Joining your notebooks and servers to the remote Active Directory domain is no problem. Azure AD DS also can be used to give the applications in your IT environment their user data over LDAP, either by public IP address over the Internet or a virtual private network (VPN) to the Azure cloud, which Microsoft also offers. Azure AD DS supports Kerberos authentication and the NTLM protocol, as well as nested OUs and group policies. Azure AD DS is therefore far closer to a conventional, on-premises Active Directory than Azure AD.

Even better news, from the administrator's point of view, is that Microsoft operates Azure AD DS instances completely without user intervention as PaaS. Therefore, you do not have to worry about redundancy or about patching the underlying operating system or Active Directory itself.

However, there is a catch: The typical permissions for domain administrators are implemented in Azure AD DS, but the service does not forward them to the user. Domain configuration details are therefore only possible with the GUIs provided by Azure for this purpose, not – as expected by well-versed Active Directory admins – by direct access to Active Directory as a domain administrator, although this situation is unlikely to worry most administrators of Active Directory instances in SMEs (Figure 2). In many places, Active Directory is used as a central directory service for managing users and resources, and Azure AD DS, hosted by Microsoft in its own cloud, is more than up to this task.

Figure 2: Azure Active Directory Domain Services is an almost complete replacement for an on-premises Active Directory in the cloud. The few missing features are unlikely to be relevant for SMEs.

The Right Migration Path

Once a company has decided to migrate Active Directory to the cloud, the question of "how" is often on the agenda. SMEs do not need to worry – even less so if Active Directory, as is almost always the case in such setups, has been used as the central logon and authorization service. The user access data can be migrated very easily, removing the need for comprehensive migration planning.

Azure AD, an old acquaintance, accompanies the migration. In the first step, you create a client in Azure AD, which can be interconnected and synchronized with an on-premises Active Directory. Then, in Azure AD DS, you configure the new domain that replaces the previous on-premises Active Directory domain. Finally, you just set up the synchronization between Azure AD and Azure AD DS. Once this is complete, the user data from what are three directories at this point is identical, and the on-premises Active Directory can be retired. It's a bit more complex if machines also need to be migrated to the cloud with their Active Directory connections. If you are not dealing with hundreds of end devices, the approach of individually unregistering the devices from the old domain and registering them with the new domain is probably your best bet.