Management concepts for user accounts, passwords, and administration in Microsoft Entra Domain Services
When you create and run a Microsoft Entra Domain Services managed domain, there are some differences in behavior compared to a traditional on-premises AD DS environment. You use the same administrative tools in Domain Services as a self-managed domain, but you can't directly access the domain controllers (DC). There's also some differences in behavior for password policies and password hashes depending on the source of the user account creation.
This conceptual article details how to administer a managed domain and the different behavior of user accounts depending on the way they're created.
Domain management
A managed domain is a DNS namespace and matching directory. In a managed domain, the domain controllers (DCs) that contain all the resources like users and groups, credentials, and policies are part of the managed service. For redundancy, two DCs are created as part of a managed domain. You can't sign in to these DCs to perform management tasks. Instead, you create a management VM that's joined to the managed domain, then install your regular AD DS management tools. You can use the Active Directory Administrative Center or Microsoft Management Console (MMC) snap-ins like DNS or Group Policy objects, for example.
User account creation
User accounts can be created in a managed domain in multiple ways. Most user accounts are synchronized in from Microsoft Entra ID, which can also include user account synchronized from an on-premises AD DS environment. You can also manually create accounts directly in the managed domain. Some features, like initial password synchronization or password policy, behave differently depending on how and where user accounts are created.
- The user account can be synchronized in from Microsoft Entra ID. This includes cloud-only user accounts created directly in Microsoft Entra ID, and hybrid user accounts synchronized from an on-premises AD DS environment using Microsoft Entra Connect.
- The majority of user accounts in a managed domain are created through the synchronization process from Microsoft Entra ID.
- The user account can be manually created in a managed domain, and doesn't exist in Microsoft Entra ID.
- If you need to create service accounts for applications that only run in the managed domain, you can manually create them in the managed domain. As synchronization is one way from Microsoft Entra ID, user accounts created in the managed domain aren't synchronized back to Microsoft Entra ID.
Password policy
Domain Services includes a default password policy that defines settings for things like account lockout, maximum password age, and password complexity. Settings like account lockout policy apply to all users in a managed domain, regardless of how the user was created as outlined in the previous section. A few settings, like minimum password length and password complexity, only apply to users created directly in a managed domain.
You can create your own custom password policies to override the default policy in a managed domain. These custom policies can then be applied to specific groups of users as needed.
For more information on the differences in how password policies are applied depending on the source of user creation, see Password and account lockout policies on managed domains.
Password hashes
To authenticate users on the managed domain, Domain Services needs password hashes in a format that's suitable for NT LAN Manager (NTLM) and Kerberos authentication. Microsoft Entra ID doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Domain Services for your tenant. For security reasons, Microsoft Entra ID also doesn't store any password credentials in clear-text form. Therefore, Microsoft Entra ID can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials.
For cloud-only user accounts, users must change their passwords before they can use the managed domain. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Microsoft Entra ID. The account isn't synchronized from Microsoft Entra ID to Domain Services until the password is changed.
For users synchronized from an on-premises AD DS environment using Microsoft Entra Connect, enable synchronization of password hashes.
Important
Microsoft Entra Connect only synchronizes legacy password hashes when you enable Domain Services for your Microsoft Entra tenant. Legacy password hashes aren't used if you only use Microsoft Entra Connect to synchronize an on-premises AD DS environment with Microsoft Entra ID.
If your legacy applications don't use NTLM authentication or LDAP simple binds, we recommend that you disable NTLM password hash synchronization for Domain Services. For more information, see Disable weak cipher suites and NTLM credential hash synchronization.
Once appropriately configured, the usable password hashes are stored in the managed domain. If you delete the managed domain, any password hashes stored at that point are also deleted. Synchronized credential information in Microsoft Entra ID can't be reused if you later create another managed domain - you must reconfigure the password hash synchronization to store the password hashes again. Previously domain-joined VMs or users won't be able to immediately authenticate - Microsoft Entra ID needs to generate and store the password hashes in the new managed domain. For more information, see Password hash sync process for Domain Services and Microsoft Entra Connect.
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.
Forests and trusts
A forest is a logical construct used by Active Directory Domain Services (AD DS) to group one or more domains. The domains then store objects for user or groups, and provide authentication services.
In Domain Services, the forest only contains one domain. On-premises AD DS forests often contain many domains. In large organizations, especially after mergers and acquisitions, you may end up with multiple on-premises forests that each then contain multiple domains.
By default, a managed domain synchronizes all objects from Microsoft Entra ID, including any user accounts created in an on-premises AD DS environment. User accounts can directly authenticate against the managed domain, such as to sign in to a domain-joined VM. This approach works when the password hashes can be synchronized and users aren't using exclusive sign-in methods like smart card authentication.
In Domain Services, you can also create a forest trust with another domain to allow users to access resources. Depending on your access requirements, you can create the forest trust in different directions.
| Trust direction | User access |
|---|---|
| Two-way | Allows users in both the managed domain and the on-premises domain to access resources in either domain. |
| One-way outgoing | Allows users in the on-premises domain to access resources in the managed domain, but not vice versa. |
| One-way incoming | Allows users in the managed domain to access resources in the on-premises domain. |
Domain Services SKUs
In Domain Services, the available performance and features are based on the SKU. You select a SKU when you create the managed domain, and you can switch SKUs as your business requirements change after the managed domain has been deployed. The following table outlines the available SKUs and the differences between them:
| SKU name | Maximum object count | Backup frequency |
|---|---|---|
| Standard | Unlimited | Every 5 days |
| Enterprise | Unlimited | Every 3 days |
| Premium | Unlimited | Daily |
Before these Domain Services SKUs, a billing model based on the number of objects (user and computer accounts) in the managed domain was used. There is no longer variable pricing based on the number of objects in the managed domain.
For more information, see the Domain Services pricing page.
Managed domain performance
Domain performance varies based on how authentication is implemented for an application. Additional compute resources may help improve query response time and reduce time spent in sync operations. As the SKU level increases, the compute resources available to the managed domain is increased. Monitor the performance of your applications and plan for the required resources.
If your business or application demands change and you need additional compute power for your managed domain, you can switch to a different SKU.
Backup frequency
The backup frequency determines how often a snapshot of the managed domain is taken. Backups are an automated process managed by the Azure platform. In the event of an issue with your managed domain, Azure support can assist you in restoring from backup. As synchronization only occurs one way from Microsoft Entra ID, any issues in a managed domain won't impact Microsoft Entra ID or on-premises AD DS environments and functionality.
As the SKU level increases, the frequency of those backup snapshots increases. Review your business requirements and recovery point objective (RPO) to determine the required backup frequency for your managed domain. If your business or application requirements change and you need more frequent backups, you can switch to a different SKU.
Domain Services provides the following guidance for recovery timespans for different types of issues:
- Recovery point objective (RPO) is the maximum timespan in which there is a potential data or transaction loss from an incident.
- Recovery time object (RTO) is the targeted timespan that occurs before service levels return to operational after an incident.
| Issues | RPO | RTO |
|---|---|---|
| Issues caused by data loss or corruption to Domain Services domain controllers, dependent services, an exploit that compromised the domain, or other incident that requires restoring a domain controller. | Five days before the occurrence of the event | Two hours to four days, depending on tenant size |
| Issues identified by our domain diagnostics. | Zero (0 minutes) | Two hours to four days, depending on tenant size |
Next steps
To get started, create a Domain Services managed domain.