How objects and credentials are synchronized in a Microsoft Entra Domain Services managed domain
Objects and credentials in a Microsoft Entra Domain Services managed domain can either be created locally within the domain, or synchronized from a Microsoft Entra tenant. When you first deploy Domain Services, an automatic one-way synchronization is configured and started to replicate the objects from Microsoft Entra ID. This one-way synchronization continues to run in the background to keep the Domain Services managed domain up-to-date with any changes from Microsoft Entra ID. No synchronization occurs from Domain Services back to Microsoft Entra ID.
In a hybrid environment, objects and credentials from an on-premises AD DS domain can be synchronized to Microsoft Entra ID using Microsoft Entra Connect. Once those objects are successfully synchronized to Microsoft Entra ID, the automatic background sync then makes those objects and credentials available to applications using the managed domain.
The following diagram illustrates how synchronization works between Domain Services, Microsoft Entra ID, and an optional on-premises AD DS environment:
Synchronization from Microsoft Entra ID to Domain Services
User accounts, group memberships, and credential hashes are synchronized one way from Microsoft Entra ID to Domain Services. This synchronization process is automatic. You don't need to configure, monitor, or manage this synchronization process. The initial synchronization may take a few hours to a couple of days, depending on the number of objects in the Microsoft Entra directory. After the initial synchronization is complete, changes that are made in Microsoft Entra ID, such as password or attribute changes, are then automatically synchronized to Domain Services.
When a user is created in Microsoft Entra ID, they're not synchronized to Domain Services until they change their password in Microsoft Entra ID. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Microsoft Entra ID. The password hashes are needed to successfully authenticate a user in Domain Services.
The synchronization process is one-way by design. There's no reverse synchronization of changes from Domain Services back to Microsoft Entra ID. A managed domain is largely read-only except for custom OUs that you can create. You can't make changes to user attributes, user passwords, or group memberships within a managed domain.
Scoped synchronization and group filter
You can scope synchronization to only user accounts that originated in the cloud. Within that synchronization scope, you can filter for specific groups or users. You can choose between cloud only groups, on-premises groups, or both. For more information about how to configure scoped synchronization, see Configure scoped synchronization.
Attribute synchronization and mapping to Domain Services
The following table lists some common attributes and how they're synchronized to Domain Services.
| Attribute in Domain Services | Source | Notes |
|---|---|---|
| UPN | User's UPN attribute in Microsoft Entra tenant | The UPN attribute from the Microsoft Entra tenant is synchronized as-is to Domain Services. The most reliable way to sign in to a managed domain is using the UPN. |
| SAMAccountName | User's mailNickname attribute in Microsoft Entra tenant or autogenerated | The SAMAccountName attribute is sourced from the mailNickname attribute in the Microsoft Entra tenant. 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 Microsoft Entra tenant | Legacy password hashes required for NTLM or Kerberos authentication are synchronized from the Microsoft Entra tenant. If the Microsoft Entra tenant is configured for hybrid synchronization using Microsoft Entra 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 Domain Services. This attribute doesn't match the primary user/group SID of the object in an on-premises AD DS environment. 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 Domain Services is set to match the corresponding primary user or group SID in an on-premises AD DS environment. This feature helps make lift-and-shift of on-premises applications to Domain Services easier as you don't need to re-ACL resources. |
Tip
Sign in to the managed domain using the UPN format The SAMAccountName attribute, such as AADDSCONTOSO\driley, may be auto-generated for some user accounts in a managed domain. Users' auto-generated SAMAccountName may differ from their UPN prefix, so isn't always a reliable way to sign in.
For example, if multiple users have the same mailNickname attribute or users have overly long UPN prefixes, the SAMAccountName for these users may be auto-generated. Use the UPN format, such as driley@aaddscontoso.com, to reliably sign in to a managed domain.
Attribute mapping for user accounts
The following table illustrates how specific attributes for user objects in Microsoft Entra ID are synchronized to corresponding attributes in Domain Services.
| User attribute in Microsoft Entra ID | User attribute in Domain Services |
|---|---|
| accountEnabled | userAccountControl (sets or clears the ACCOUNT_DISABLED bit) |
| city | l |
| companyName | companyName |
| country | co |
| department | department |
| displayName | displayName |
| employeeId | employeeId |
| facsimileTelephoneNumber | facsimileTelephoneNumber |
| givenName | givenName |
| jobTitle | title |
| mailNickname | msDS-AzureADMailNickname |
| mailNickname | SAMAccountName (may sometimes be autogenerated) |
| manager | manager |
| mobile | mobile |
| objectid | msDS-aadObjectId |
| onPremiseSecurityIdentifier | sidHistory |
| passwordPolicies | userAccountControl (sets or clears the DONT_EXPIRE_PASSWORD bit) |
| physicalDeliveryOfficeName | physicalDeliveryOfficeName |
| postalCode | postalCode |
| preferredLanguage | preferredLanguage |
| proxyAddresses | proxyAddresses |
| state | st |
| streetAddress | streetAddress |
| surname | sn |
| telephoneNumber | telephoneNumber |
| userPrincipalName | userPrincipalName |
Attribute mapping for groups
The following table illustrates how specific attributes for group objects in Microsoft Entra ID are synchronized to corresponding attributes in Domain Services.
| Group attribute in Microsoft Entra ID | Group attribute in Domain Services |
|---|---|
| displayName | displayName |
| displayName | SAMAccountName (may sometimes be autogenerated) |
| mailNickname | msDS-AzureADMailNickname |
| objectid | msDS-AzureADObjectId |
| onPremiseSecurityIdentifier | sidHistory |
| proxyAddresses | proxyAddresses |
| securityEnabled | groupType |
Synchronization from on-premises AD DS to Microsoft Entra ID and Domain Services
Microsoft Entra Connect is used to synchronize user accounts, group memberships, and credential hashes from an on-premises AD DS environment to Microsoft Entra ID. Attributes of user accounts such as the UPN and on-premises security identifier (SID) are synchronized. To sign in using Domain Services, legacy password hashes required for NTLM and Kerberos authentication are also synchronized to Microsoft Entra ID.
Important
Microsoft Entra Connect should only be installed and configured for synchronization with on-premises AD DS environments. It's not supported to install Microsoft Entra Connect in a managed domain to synchronize objects back to Microsoft Entra ID.
If you configure writeback, changes from Microsoft Entra ID are synchronized back to the on-premises AD DS environment. For example, if a user changes their password using Microsoft Entra self-service password management, the password is updated back in the on-premises AD DS environment.
Note
Always use the latest version of Microsoft Entra Connect to ensure you have fixes for all known bugs.
Synchronization from a multi-forest on-premises environment
Many organizations have a fairly complex on-premises AD DS environment that includes multiple forests. Microsoft Entra Connect supports synchronizing users, groups, and credential hashes from multi-forest environments to Microsoft Entra ID.
Microsoft Entra ID has a much simpler and flat namespace. To enable users to reliably access applications secured by Microsoft Entra ID, resolve UPN conflicts across user accounts in different forests. Managed domains use a flat OU structure, similar to Microsoft Entra ID. All user accounts and groups are stored in the AADDC Users container, despite being synchronized from different on-premises domains or forests, even if you've configured a hierarchical OU structure on-premises. The managed domain flattens any hierarchical OU structures.
As previously detailed, there's no synchronization from Domain Services back to Microsoft Entra ID. You can create a custom Organizational Unit (OU) in Domain Services and then users, groups, or service accounts within those custom OUs. None of the objects created in custom OUs are synchronized back to Microsoft Entra ID. These objects are available only within the managed domain, and aren't visible using Microsoft Graph PowerShell cmdlets, Microsoft Graph API, or using the Microsoft Entra admin center.
What isn't synchronized to Domain Services
The following objects or attributes aren't synchronized from an on-premises AD DS environment to Microsoft Entra ID or Domain Services:
- Excluded attributes: You can choose to exclude certain attributes from synchronizing to Microsoft Entra ID from an on-premises AD DS environment using Microsoft Entra Connect. These excluded attributes aren't then available in Domain Services.
- Group Policies: Group Policies configured in an on-premises AD DS environment aren't synchronized to Domain Services.
- Sysvol folder: The contents of the Sysvol folder in an on-premises AD DS environment aren't synchronized to Domain Services.
- Computer objects: Computer objects for computers joined to an on-premises AD DS environment aren't synchronized to Domain Services. These computers don't have a trust relationship with the managed domain and only belong to the on-premises AD DS environment. In Domain Services, only computer objects for computers that have explicitly domain-joined to the managed domain are shown.
- SidHistory attributes for users and groups: The primary user and primary group SIDs from an on-premises AD DS environment are synchronized to Domain Services. However, existing SidHistory attributes for users and groups aren't synchronized from the on-premises AD DS environment to Domain Services.
- Organization Units (OU) structures: Organizational Units defined in an on-premises AD DS environment don't synchronize to Domain Services. There are two built-in OUs in Domain Services - one for users, and one for computers. The managed domain has a flat OU structure. You can choose to create a custom OU in your managed domain.
Password hash synchronization and security considerations
When you enable Domain Services, legacy password hashes for NTLM and Kerberos authentication are required. Microsoft Entra ID doesn't store clear-text passwords, so these hashes can't be automatically generated for existing user accounts. NTLM and Kerberos compatible password hashes are always stored in an encrypted manner in Microsoft Entra ID.
The encryption keys are unique to each Microsoft Entra tenant. These hashes are encrypted such that only Domain Services has access to the decryption keys. No other service or component in Microsoft Entra ID has access to the decryption keys.
Legacy password hashes are then synchronized from Microsoft Entra ID into the domain controllers for a managed domain. The disks for these managed domain controllers in Domain Services are encrypted at rest. These password hashes are stored and secured on these domain controllers similar to how passwords are stored and secured in an on-premises AD DS environment.
For cloud-only Microsoft Entra environments, users must reset/change their password in order for the required password hashes to be generated and stored in Microsoft Entra ID. For any cloud user account created in Microsoft Entra ID after enabling Microsoft Entra Domain Services, the password hashes are generated and stored in the NTLM and Kerberos compatible formats. All cloud user accounts must change their password before they're synchronized to Domain Services.
For hybrid user accounts synced from on-premises AD DS environment using Microsoft Entra Connect, you must configure Microsoft Entra Connect to synchronize password hashes in the NTLM and Kerberos compatible formats.
Next steps
For more information on the specifics of password synchronization, see How password hash synchronization works with Microsoft Entra Connect.
To get started with Domain Services, create a managed domain.
Palaute
Tulossa pian: Vuoden 2024 aikana poistamme asteittain GitHub Issuesin käytöstä sisällön palautemekanismina ja korvaamme sen uudella palautejärjestelmällä. Lisätietoja on täällä: https://aka.ms/ContentUserFeedback.
Lähetä ja näytä palaute kohteelle