Beginning with the Windows 2000 Server release, Active Directory Domain Services (AD DS) functioned as an identity management solution for enterprise resources. After creating an AD DS domain controller from a Windows server, administrators create a hierarchy of forests and domains and populate them with logical objects representing users, computers, applications, and other resources. With those objects, AD DS functions as an intermediary between users and network resources, providing authentication and authorization services when users attempt to access them. Azure Active Directory (Azure AD or AAD) is an Identity as a Service (IDaaS) mechanism that performs the same basic authentication and authorization functions for the Microsoft 365 cloud services, but it does so in a different way. More information is here
There are no forests or domains in Azure AD. After an organization subscribes to Microsoft 365 (or any of the individual Microsoft cloud services), an administrator creates a tenant using the Create A Tenant page, as shown in Figure 2-12. In Azure AD, a tenant is a logical construct representing an entire organization. Administrators of the tenant can then use the Azure portal to create user accounts and manage their properties, such as permissions and passwords. The accounts provide users with single-sign-on capability for all Microsoft services.
FIGURE 2-12 The Create A Tenant page in the Azure Active Directory portal
AD DS uses protocols such as Kerberos and NT LAN Manager (NTLM) for communication between domain controllers and the other computers involved in authentication or authorization. This is appropriate for its functions because AD DS functions only within the organization’s premises; it is not designed to work with users outside of the enterprise or manage cloud-based services like those in Microsoft 365.
Obviously, Azure AD is designed to manage cloud services and can work with users located anywhere, employing different security protocols, such as Security Assertion Markup Language (SAML) and Open Authorization (OAuth). Because they are so different, Azure AD and AD DS are not functionally interchangeable, as are the cloud-based and on-premises versions of services such as Exchange and SharePoint.
Thus, for any organization with an existing on-premises AD DS deployment and considering implementing Microsoft 365, the administrators will have to work with both AD DS and Azure AD. Fortunately, this does not mean that it will be necessary to create duplicate user accounts in each of the directory services. Azure AD Connect links the two and provides each user with a hybrid identity that spans both on-premises and cloud-based services. This provides the user with single sign-on capability for all applications and services.
Top comments (0)