- Azure AD without on-prem Windows Active Directory? - Mon, Oct 25 2021
- An overview of Azure security - Mon, Mar 29 2021
- An introduction to Azure AD administrative units - Wed, Jan 6 2021
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 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!
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.
Want to write for 4sysops? We are looking for new authors.
In a non-AD environment, how would we support things like WPA Enterprise (802.1x authentication for wireless), and other technologies that would still be used on-prem?
Hey Kurt we have build 802.1X wifi authentication with that.