Azure AD addresses identity management for cloud-based services. Many organizations have extended their on-premises identities to Azure AD for the best of both worlds: network and cloud identity management. Some organizations take their identity strategy further by removing their domain controllers and transitioning to cloud-only identity management, using Azure AD as the sole identity management solution. This article reviews considerations for moving to cloud-only identity management with Azure AD.
Latest posts by Travis Roberts (see all)

Windows AD vs. Azure AD ^

Before we move on to considerations of moving to an Azure AD-only identity provider, let's compare some of the main differences between Windows AD and Azure AD as they relate to user identities.

Windows AD is a network-based directory service. It processes network logins and access management using authentication protocols, such as LDAP, Kerberos, and NTLM. These are network-based protocols that cannot or should not be extended to the public cloud. In addition, Windows AD is implemented on-premises with virtual or physical servers. These servers require maintenance and updating to maintain reliable operations.

Azure AD and on prem Windows AD

Azure AD and on prem Windows AD

Azure AD is a cloud-based identity service that supports authentication protocols like SAML 2.0, OpenID Connect, and OAuth 2.0. One of the core principles of Azure AD is that the user is the security boundary, not the network. Azure AD is a Software as a Service (SaaS) application built on the Azure cloud with support for multiple public clouds. There is no on-premises infrastructure to support. Identities originate in Azure AD or are synchronized from an on-premises Windows AD for a hybrid identity option.

Azure AD only ^

Many organizations are considering or planning to move away from the traditional on-premises infrastructure to a cloud-only approach, replacing on-premises Windows AD with Azure AD. This is a logical progression as an increasing number of services move to the cloud. However, there is a twenty-year history with Windows AD, and many services and applications depend on the authentication and management services that Windows AD provides.

Some organizations may even establish the goal of removing Windows AD. This is often driven by the desire to stop managing on-premises infrastructure, such as domain controllers. However, the goal of removing on-premises domain controllers and no longer supporting Windows AD does not address the dependencies that rely on Windows AD.

The better approach to ending support for Windows AD is to remove or upgrade applications that require the protocols and services that Windows AD provides, such as LDAP, Kerberos, and NTLM. This includes upgrading or replacing these applications with applications that support modern authentication protocols, such as SAML, OpenID, or OAuth. Taking this approach addresses the applications and services dependent on Windows AD. Removing or upgrading them is a prerequisite for removing Windows AD.

The process of removing Windows AD starts by taking inventory of services that depend on it, not only what is currently in place but services that may be required in the future. Foundational infrastructure, such as Windows File Shares and Windows Server Certificate Authority, relies on Windows AD for authentication. There may also be other third-party applications that depend on Windows AD. These services must be identified and the dependency removed before an organization can remove Windows AD.

Organizations that start as cloud-only have the advantage of not having dependencies on Windows AD. As these organizations grow, it's important to stay committed to a cloud-only strategy. There is a long history of Windows AD in application development. Many third-party applications depend on Windows AD. Properly vetting applications and maintaining the Azure AD authentication support requirement will prevent application drift, which could force an organization into supporting Windows AD.

Azure AD DS does not replace Windows AD ^

Azure AD Domain Services (Azure AD DS) is a Windows AD-compatible SaaS offering hosted in Azure. Although compatible with Windows AD, there are limitations. There are no Administrator or Enterprise Admin accounts, limiting the applications that can be installed. The schema cannot be extended, and Azure AD DS-joined client computers cannot be hybrid Azure AD-joined.

Occasionally, an organization will try to use Azure AD as a replacement for traditional Windows AD. Inevitably, they run into issues due to the limitations of Azure AD DS. Azure AD DS is not intended to be a replacement for Windows AD. It is an option when moving legacy applications that depend on Windows AD to Azure without extending Windows AD to Azure, such as an IIS application that leverages Windows AD for authentication.

Moving from Windows AD to Azure AD DS may satisfy a requirement to end management of domain controllers while retaining a requirement for management of a Windows AD Domain. Moving to Azure AD DS does not address removing the dependency of applications that require legacy network authentication, such as Kerberos and NTLM.

Subscribe to 4sysops newsletter!

Conclusion ^

The goal of using Azure AD without Windows AD is achievable for many organizations. Moving to Azure AD and away from Windows AD requires evaluating services dependent on Windows AD and creating a strategy to upgrade or replace them with options that support Azure AD. Organizations that are currently cloud-only, using Azure AD without Windows AD, need to maintain this by setting specific requirements when making decisions on new software and services. Lastly, be sure to thoroughly evaluate Azure AD DS when considering it as a replacement for Windows AD. In most cases, the limitations of Azure AD DS will prevent the service from replacing Windows AD.