Windows domain in Azure

I wrote this article to better understand all the pieces called “AD” or “Active Directory” in Microsoft Azure fit together. The pieces are as follows:

  • Active Directory (AD): The is the classic on-premise Active Directory with LDAP, Kerberos, group policies and all that. Traditionally Windows machines in larger environments have been domain-joined to on-premise AD.

  • Active Directory Federation services (AD FS): adds support for modern web-SSO protocols (SAML, OAuth 2.0 and OIDC) to on-premise Active Directory.

  • Azure Active Directory (AAD): Azure SaaS software that is automatically enabled for every Azure tenant. the same software as on-premise Active Directory. Windows machines with recent enough operating system (Windows 10) support AAD authentication either as joined or registered device. As of late 2021 Microsoft also supports logging into Linux VMs using AAD credentials using ephemeral OpenSSH certificates. AAD does not directly support LDAP, Kerberos or other protocols considered legacy, but does support more modern web-based SAML, OAuth 2.0 and OIDC protocols. AAD seems to have better support for BYOD (“Bring Your Own Device”) environments than on-premise AD, as AAD was designed with that use-case in mind from the get-go.

  • Azure AD Connect: on-premise software used to synchronizing contents of on-premise Active Directory (AD) with Azure Active Directory (AAD).

  • Azure AD Domain Services: Azure SaaS service that provides services similar to on-premise Active Directory (AD) for Azure. Data such as users and groups are synchronizes from AAD to AAD DS, but not the other way around. AAD DS does not support all the features of on-premise AD and hence is not a full replacement for it. For good overview of the pros and cons compared to on-site AD look here.

Until quite recently it was not possible to join a Windows instance to Azure AD directly. That is, you needed one of the following:

  • Azure AD synchronized with Azure AD Connect to an on-premise Active Directory

  • Azure AD coupled with Azure AD Domain services

As of November 11, 2021 it became possible to directly register or join devices such as Windows VMs to Azure AD. Joining is limited to recent versions of Windows 10 and Windows Server 2019 or later. Registering a device to AAD is more suitable for personal (non-corporate) devices the user, typically an employee, manages himself/herself. Joining a device to AAD is mainly meant for corporate-owned devices in cases where an on-premise AD is not available (e.g. small branch office) or the vast majority of corporate services are Cloud-based and having an on-premise AD does not make much sense.

The easiest way to join a VM to Azure AD is to just enable Azure AD login when creating the VM. However, it is also possible to join existing VMs to Azure AD by provisioning a virtual machine extension (installable using the Azure Cloud shell) and by enabling system managed identity in the VMs identity settings. For debugging use dsregcmd.exe and check Azure AD’s Devices section to ensure that your device (VM) is there and shows as joined.

Things get a bit interesting when you use Azure AD with Azure AD Domain Services. Based on practical testing you can join some Windows devices directly to Azure AD and join some via Azure AD DS. The latter devices will not show up in the “Devices” section in Azure AD, which makes sense given that Azure AD DS syncs one-way from Azure AD. The domain join methods are also different: Azure AD DS supports the classic on-premise style domain join, whereas direct Azure AD domain join process is completely different. Trying to use classic domain join with Azure AD fails because Azure AD does not expose DNS SRV records that classic join depends on.

Note that by default you can RDP to Azure AD-joined devices (e.g Azure VMs) only from devices that are, at minimum, registered to Azure AD - look here for details. It is, however, possible work around this limitation by disabling the requirement for network level authentication in the Azure AD-joined Windows machine. This may be acceptable if you, say, only use RDP through a VPN. Instructions for doing this on Windows RDP clients are in here, and for Linux (Remmina) clients in here. In addition, you need to grant Virtual Machine User Login or Virtual Machine Administrator Login IAM roles to users who need to be able to RDP in to the VM.

Overall, it seems like Azure Active Directory is slowly replacing on-premise Active Directory and Active Directory Federation Services, and tools like Azure AD Domain Services and Azure AD Connect and are just tools aimed at helping the migration to Microsoft’s cloud-based SaaS offering.