How objects & credentials are synchronized in Azure Active Directory?
This tutorial will help to gain insights on How objects & credentials are synchronized in Azure Active Directory? Objects and credentials in an Azure Active Directory Domain Services (Azure AD DS) managed domain can either be created locally within the domain, or synchronized from an Azure Active Directory (Azure AD) tenant. Also, When you first deploy Azure AD DS, an automatic one-way synchronization is configured and started to replicate the objects from Azure AD. Furthermore, This one-way synchronization continues to run in the background to keep the Azure AD DS managed domain up-to-date with any changes from Azure AD. No synchronization occurs from Azure AD DS back to Azure AD.
The following diagram illustrates how synchronization works between Azure AD DS, Azure AD, and also an optional on-premises AD DS environment:
Synchronization from Azure AD to Azure AD DS
User accounts, group memberships, and credential hashes are synchronized one way from Azure AD to Azure AD DS. Also, This synchronization process is automatic. You don’t need to configure, monitor, or manage this synchronization process. Furthermore, The initial synchronization may take a few hours to a couple of days, depending on the number of objects in the Azure AD directory. After the initial synchronization is complete, changes that are made in Azure AD, such as password or attribute changes, are then automatically synchronized to Azure AD DS.
Attribute synchronization and mapping to Azure AD DS
The following table lists some common attributes and how they’re synchronized to Azure AD DS.
| Attribute in Azure AD DS | Source | Notes |
|---|---|---|
| UPN | User’s UPN attribute in Azure AD tenant | The UPN attribute from the Azure AD tenant is synchronized as-is to Azure AD DS. Also, The most reliable way to sign in to a managed domain is using the UPN. |
| SAMAccountName | User’s mailNickname attribute in Azure AD tenant or autogenerated | The SAMAccountName attribute is sourced from the mailNickname attribute in the Azure AD tenant. Furthermore, If multiple user accounts have the same mailNickname attribute, the SAMAccountName is autogenerated. If the user’s mailNickname or UPN prefix is longer than 20 characters, the SAMAccountName is autogenerated to meet the 20 character limit on SAMAccountName attributes. |
| Passwords | User’s password from the Azure AD tenant | Legacy password hashes required for NTLM or Kerberos authentication are synchronized from the Azure AD tenant. Subsequently, If the Azure AD tenant is configured for hybrid synchronization using Azure AD Connect, these password hashes are sourced from the on-premises AD DS environment. |
| Primary user/group SID | Autogenerated | The primary SID for user/group accounts is autogenerated in Azure AD DS. Also, This attribute doesn’t match the primary user/group SID of the object in an on-premises AD DS environment. Subsequently, This mismatch is because the managed domain has a different SID namespace than the on-premises AD DS domain. |
| SID history for users and groups | On-premises primary user and group SID | The SidHistory attribute for users and groups in Azure AD DS is set to match the corresponding primary user or group SID in an on-premises AD DS environment. Also, This feature helps make lift-and-shift of on-premises applications to Azure AD DS also easier as you don’t need to re-ACL resources. |
Synchronization from on-premises AD DS to Azure AD and Azure AD DS
Sbsequently, Azure AD Connect is used to synchronize user accounts, group memberships, and credential hashes from an on-premises AD DS environment to Azure AD. Attributes of user accounts such as the UPN and on-premises security identifier (SID) are synchronized. To sign in using Azure AD DS, legacy password hashes required for NTLM and Kerberos authentication are indeed synchronized to Azure AD.
Furthermore, also having knowledge about Synchronization from a multi-forest on-premises environment and What isn’t synchronized to Azure AD DS.
Password hash synchronization and security considerations
When you enable Azure AD DS, legacy password hashes for NTLM + Kerberos authentication are required. Also, Azure AD doesn’t store clear-text passwords, so these hashes can’t be automatically generated for existing user accounts. Subsequently, Once generated and stored, NTLM and Kerberos compatible password hashes are always stored in an encrypted manner in Azure AD.
Furthermore, The encryption keys are unique to each Azure AD tenant. Indeed, These hashes are encrypted such that only Azure AD DS has access to the decryption keys. Finally, No other service or component in Azure AD has access to the decryption keys.
Reference documentation – How objects and credentials are synchronized in an Azure Active Directory Domain Services managed domain