-description: Active Directory authentication non domain joined Linux Virtual Machines.

-# Active Directory authentication non domain joined Linux Virtual Machines

-Currently Linux distribution can work as member of Active Directory domains, which gives them access to the AD authentication system. To take advantage of AD authentication in some cases, we can avoid the AD join. To let users sign in on Azure Linux VM with Active Directory account you have different choices. One possibility is to Join in Active Directory the VM. Another possibility is to base the authentication flow through LDAP to your Active Directory without Join the VM on AD. This article shows you how to authenticate with AD credential on your Linux system (CentosOS) based on LDAP.

-## Prerequisites

-To complete the authentication flow we assume, you already have:

-* An Active Directory Domain Services already configured.

-* A Linux VM (**for the test we use CentosOS based machine**).

-* A network infrastructure that allows communication between Active Directory and the Linux VM.

-* A dedicated User Account for read AD objects.

-* The Linux VM need to have these packages installed:

- - sssd

- - sssd-tools

- - sssd-ldap

- - openldap-clients

-* An LDAPS Certificate correctly configured on the Linux VM.

-* A CA Certificate correctly imported into Certificate Store of the Linux VM (the path varies depending on the Linux distro).

-## Active Directory User Configuration

-To read Users in your Active Directory Domain Services create a ReadOnlyUser in AD. For create a new user follow the steps below:

-1. Connect to your *Domain Controller*.

-2. Click *Start*, point to *Administrative Tools*, and then click *Active Directory Users and Computers* to start the Active Directory Users and Computers console.

-3. Click the domain name that you created, and then expand the contents.

-4. Right-click Users, point to *New*, and then click *User*.

-5. Type the first name, last name, and user logon name of the new user, and then click Next. In lab environment we used a user called *ReadOnlyUser*.

-6. Type a *new password*, confirm the password, and then click to select one of the following check boxes if needed:

- - Users must change password at next logon (recommended for most user)

- - User cannot change password

- - Password never expires

- - Account is disabled (If you disable the account the authentication will fail)

-7. Click *Next*.

-Review the information that you provided, and if everything is correct, click Finish.

-> [!NOTE]

-> The lab environment is based on:

-> - Windows Server 2016 Domain and Forest Functional Level.

-> - Linux client Centos 8.5.

-## Linux Virtual Machines Configuration

-> [!NOTE]

-> You must run these command with sudo permission

-On your Linux VM, install the following packages: *sssd sssd-tools sssd-ldap openldap-client*:

-```bash

-sudo dnf install -y sssd sssd-tools sssd-ldap openldap-clients

-```

-After the installation check if LDAP search works. In order to check it try an LDAP search following the example below:

-```bash

-sudo ldapsearch -H ldaps://contoso.com -x \

- -D CN=ReadOnlyUser,CN=Users,DC=contoso,DC=com -w Read0nlyuserpassword \

- -b CN=Users,DC=contoso,DC=com

-```

-If the LDAP query works fine, you will obtain an output with some information like follow:

-```config

-extended LDIF

-LDAPv3

-base <CN=Users,DC=contoso,DC=com> with scope subtree

-filter: (objectclass=*)

-requesting: ALL

-Users, contoso.com

-dn: CN=Users,DC=contoso,DC=com

-objectClass: top

-objectClass: container

-cn: Users

-description: Default container for upgraded user accounts

-distinguishedName: CN=Users,DC=contoso,DC=com

-instanceType: 4

-whenCreated: 20220913115340.0Z

-whenChanged: 20220913115340.0Z

-uSNCreated: 5660

-uSNChanged: 5660

-showInAdvancedViewOnly: FALSE

-name: Users

-objectGUID:: i9MABLytKUurB2uTe/dOzg==

-systemFlags: -1946157056

-objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=contoso,DC=com

-isCriticalSystemObject: TRUE

-dSCorePropagationData: 20220930113600.0Z

-dSCorePropagationData: 20220930113600.0Z

-dSCorePropagationData: 20220930113600.0Z

-dSCorePropagationData: 20220930113600.0Z

-dSCorePropagationData: 16010101000000.0Z

-```

-> [!NOTE]

-> If your get and error run the following command:

->

-> sudo ldapsearch -H ldaps://contoso.com -x \

-> -D CN=ReadOnlyUser,CN=Users,DC=contoso,DC=com -w Read0nlyuserpassword \

-> -b CN=Users,DC=contoso,DC=com -d 3

->

-> Troubleshoot according to the output.

-## Create sssd.conf file

-Create */etc/sssd/sssd.conf* with a content like the following. Remember to update the *ldap_uri*, *ldap_search_base* and *ldap_default_bind_dn*.

-Command for file creation:

-```bash

-sudo vi /etc/sssd/sssd.conf

-```

-Example sssd.conf:

-```config

-[sssd]

-config_file_version = 2

-domains = default

-services = nss, pam

-full_name_format = %1$s

-[nss]

-[pam]

-[domain/default]

-id_provider = ldap

-cache_credentials = True

-ldap_uri = ldaps://contoso.com

-ldap_search_base = CN=Users,DC=contoso,DC=com

-ldap_schema = AD

-ldap_default_bind_dn = CN=ReadOnlyUser,CN=Users,DC=contoso,DC=com

-ldap_default_authtok_type = obfuscated_password

-ldap_default_authtok = generated_password

-# Obtain the CA root certificate for your LDAPS connection.

-ldap_tls_cacert = /etc/pki/tls/cacerts.pem

-# This setting disables cert verification.

-#ldap_tls_reqcert = allow

-# Only if the LDAP directory doesn't provide uidNumber and gidNumber attributes

-ldap_id_mapping = True

-# Consider setting enumerate=False for very large directories

-enumerate = True

-# Only needed if LDAP doesn't provide homeDirectory and loginShell attributes

-fallback_homedir = /home/%u

-default_shell = /bin/bash

-access_provider = permit

-sudo_provider = ldap

-auth_provider = ldap

-autofs_provider = ldap

-resolver_provider = ldap

-```

-Save the file with *ESC + wq!* command.

-> [!NOTE]

-> If you don't have a valid TLS certificate under */etc/pki/tls/* called *cacerts.pem* the bind doesn't work

-## Change permission for sssd.conf and create the obfuscated password

-Set the permission to sssd.conf to 600 with the following command:

-```bash

-sudo chmod 600 /etc/sssd/sssd.conf

-```

-After that create an obfuscated password for the Bind DN account. You must insert the Domain password for ReadOnlyUser:

-```bash

-sudo sss_obfuscate --domain default

-```

-The password will be placed automatically in the configuration file.

-## Configure the sssd service

-Start the sssd service:

-```bash

-sudo systemctl start sssd

-```

-Now configure the service with the *authconfig* tool:

-```bash

-sudo authconfig --enablesssd --enablesssdauth --enablemkhomedir --updateall

-```

-At this point restart the service:

-```bash

-sudo systemctl restart sssd

-```

-## Test the configuration

-The final step is to check that the flow works properly. To check this, try logging in with one of your AD users in Active Directory. We tried with a user called *ADUser*. If the configuration is correct, you will get the following result:

-```output

-[centosuser@centos8 ~]su - ADUser@contoso.com

-Last login: Wed Oct 12 15:13:39 UTC 2022 on pts/0

-[ADUser@Centos8 ~]$ exit

-```

-Now you are ready to use AD authentication on your Linux VM.

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization.md

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory.md

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-description: Learn about how to administer a Microsoft Entra Domain Services managed domain and the behavior of user accounts and passwords

-# 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-policy].

-## 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][hybrid-phs].

-> [!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][secure-domain].

-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][azure-ad-password-sync].

-> [!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 a Domain Services, you can also create a one-way forest *trust* to let users sign in from their on-premises AD DS. With this approach, the user objects and password hashes aren't synchronized to Domain Services. The user objects and credentials only exist in the on-premises AD DS. This approach lets enterprises host resources and application platforms in Azure that depend on classic authentication such LDAPS, Kerberos, or NTLM, but any authentication issues or concerns are removed.

-<a name='azure-ad-ds-skus'></a>

-## 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][pricing].

-### 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.

-## Next steps

-To get started, [create a Domain Services managed domain][create-instance].

-<!-- INTERNAL LINKS -->

-[password-policy]: password-policy.md

-[hybrid-phs]: tutorial-configure-password-hash-sync.md#enable-synchronization-of-password-hashes

-[secure-domain]: secure-your-domain.md

-[azure-ad-password-sync]: /azure/active-directory/hybrid/connect/how-to-connect-password-hash-synchronization#password-hash-sync-process-for-azure-ad-domain-services

-[create-instance]: tutorial-create-instance.md

-[tutorial-create-instance-advanced]: tutorial-create-instance-advanced.md

-[concepts-forest]: ./concepts-forest-trust.md

-[concepts-trust]: concepts-forest-trust.md

-<!-- EXTERNAL LINKS -->

-[pricing]: https://azure.microsoft.com/pricing/details/active-directory-ds/

-description: Learn how to troubleshoot and resolve common alerts with secure LDAP for Microsoft Entra Domain Services.

-# Known issues: Secure LDAP alerts in Microsoft Entra Domain Services

-Applications and services that use lightweight directory access protocol (LDAP) to communicate with Microsoft Entra Domain Services can be [configured to use secure LDAP](tutorial-configure-ldaps.md). An appropriate certificate and required network ports must be open for secure LDAP to work correctly.

-This article helps you understand and resolve common alerts with secure LDAP access in Domain Services.

-## AADDS101: Secure LDAP network configuration

-### Alert message

-*Secure LDAP over the internet is enabled for the managed domain. However, access to port 636 is not locked down using a network security group. This may expose user accounts on the managed domain to password brute-force attacks.*

-### Resolution

-When you enable secure LDAP, it's recommended to create extra rules that restrict inbound LDAPS access to specific IP addresses. These rules protect the managed domain from brute force attacks. To update the network security group to restrict TCP port 636 access for secure LDAP, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Network security groups**.

-1. Choose the network security group associated with your managed domain, such as *AADDS-contoso.com-NSG*, then select **Inbound security rules**

-1. Select **+ Add** to create a rule for TCP port 636. If needed, select **Advanced** in the window to create a rule.

-1. For the **Source**, choose *IP Addresses* from the drop-down menu. Enter the source IP addresses that you want to grant access for secure LDAP traffic.

-1. Choose *Any* as the **Destination**, then enter *636* for **Destination port ranges**.

-1. Set the **Protocol** as *TCP* and the **Action** to *Allow*.

-1. Specify the priority for the rule, then enter a name such as *RestrictLDAPS*.

-1. When ready, select **Add** to create the rule.

-The managed domain's health automatically updates itself within two hours and removes the alert.

-> [!TIP]

-> TCP port 636 isn't the only rule needed for Domain Services to run smoothly. To learn more, see the [Domain Services Network security groups and required ports](network-considerations.md#network-security-groups-and-required-ports).

-## AADDS502: Secure LDAP certificate expiring

-### Alert message

-*The secure LDAP certificate for the managed domain will expire on [date]].*

-### Resolution

-Create a replacement secure LDAP certificate by following the steps to [create a certificate for secure LDAP](tutorial-configure-ldaps.md#create-a-certificate-for-secure-ldap). Apply the replacement certificate to Domain Services, and distribute the certificate to any clients that connect using secure LDAP.

-## Next steps

-If you still have issues, [open an Azure support request][azure-support] for more troubleshooting help.

-<!-- INTERNAL LINKS -->

-[azure-support]: /azure/active-directory/fundamentals/how-to-get-support

-description: Learn how to troubleshoot and resolve network security group configuration alerts for Microsoft Entra Domain Services

-# Known issues: Network configuration alerts in Microsoft Entra Domain Services

-To let applications and services correctly communicate with a Microsoft Entra Domain Services managed domain, specific network ports must be open to allow traffic to flow. In Azure, you control the flow of traffic using network security groups. The health status of a Domain Services managed domain shows an alert if the required network security group rules aren't in place.

-This article helps you understand and resolve common alerts for network security group configuration issues.

-## Alert AADDS104: Network error

-### Alert message

-*Microsoft is unable to reach the domain controllers for this managed domain. This may happen if a network security group (NSG) configured on your virtual network blocks access to the managed domain. Another possible reason is if there is a user-defined route that blocks incoming traffic from the internet.*

-Invalid network security group rules are the most common cause of network errors for Domain Services. The network security group for the virtual network must allow access to specific ports and protocols. If these ports are blocked, the Azure platform can't monitor or update the managed domain. The synchronization between the Microsoft Entra directory and Domain Services is also impacted. Make sure you keep the default ports open to avoid interruption in service.

-## Default security rules

-The following default inbound and outbound security rules are applied to the network security group for a managed domain. These rules keep Domain Services secure and allow the Azure platform to monitor, manage, and update the managed domain.

-### Inbound security rules

-| Priority | Name | Port | Protocol | Source | Destination | Action |

-|-|||-|--|-|--|

-| 301 | AllowPSRemoting | 5986| TCP | AzureActiveDirectoryDomainServices | Any | Allow |

-| 201 | AllowRD | 3389 | TCP | CorpNetSaw | Any | Deny¹ |

-| 65000 | AllVnetInBound | Any | Any | VirtualNetwork | VirtualNetwork | Allow |

-| 65001 | AllowAzureLoadBalancerInBound | Any | Any | AzureLoadBalancer | Any | Allow |

-| 65500 | DenyAllInBound | Any | Any | Any | Any | Deny |

-¹Optional for debugging. Allow when required for advanced troubleshooting.

-> [!NOTE]

-> You may also have an additional rule that allows inbound traffic if you [configure secure LDAP][configure-ldaps]. This additional rule is required for the correct LDAPS communication.

-### Outbound security rules

-| Priority | Name | Port | Protocol | Source | Destination | Action |

-|-|||-|--|-|--|

-| 65000 | AllVnetOutBound | Any | Any | VirtualNetwork | VirtualNetwork | Allow |

-| 65001 | AllowAzureLoadBalancerOutBound | Any | Any | Any | Internet | Allow |

-| 65500 | DenyAllOutBound | Any | Any | Any | Any | Deny |

->[!NOTE]

-> Domain Services needs unrestricted outbound access from the virtual network. We don't recommend that you create any additional rules that restrict outbound access for the virtual network.

-## Verify and edit existing security rules

-To verify the existing security rules and make sure the default ports are open, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Network security groups**.

-1. Choose the network security group associated with your managed domain, such as *AADDS-contoso.com-NSG*.

-1. On the **Overview** page, the existing inbound and outbound security rules are shown.

- Review the inbound and outbound rules and compare to the list of required rules in the previous section. If needed, select and then delete any custom rules that block required traffic. If any of the required rules are missing, add a rule in the next section.

- After you add or delete rules to allow the required traffic, the managed domain's health automatically updates itself within two hours and removes the alert.

-### Add a security rule

-To add a missing security rule, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Network security groups**.

-1. Choose the network security group associated with your managed domain, such as *AADDS-contoso.com-NSG*.

-1. Under **Settings** in the left-hand panel, click *Inbound security rules* or *Outbound security rules* depending on which rule you need to add.

-1. Select **Add**, then create the required rule based on the port, protocol, direction, etc. When ready, select **OK**.

-It takes a few moments for the security rule to be added and show in the list.

-## Next steps

-If you still have issues, [open an Azure support request][azure-support] for additional troubleshooting assistance.

-<!-- INTERNAL LINKS -->

-[azure-support]: /azure/active-directory/fundamentals/how-to-get-support

-[configure-ldaps]: ./tutorial-configure-ldaps.md

-description: Learn how to troubleshoot service principal configuration alerts for Microsoft Entra Domain Services

-# Known issues: Service principal alerts in Microsoft Entra Domain Services

-[Service principals](/azure/active-directory/develop/app-objects-and-service-principals) are applications that the Azure platform uses to manage, update, and maintain a Microsoft Entra Domain Services managed domain. If a service principal is deleted, functionality in the managed domain is impacted.

-This article helps you troubleshoot and resolve service principal-related configuration alerts.

-## Alert AADDS102: Service principal not found

-### Alert message

-*A Service Principal required for Microsoft Entra Domain Services to function properly has been deleted from your Microsoft Entra directory. This configuration impacts Microsoft's ability to monitor, manage, patch, and synchronize your managed domain.*

-If a required service principal is deleted, the Azure platform can't perform automated management tasks. The managed domain may not correctly apply updates or take backups.

-### Check for missing service principals

-To check which service principal is missing and must be recreated, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Enterprise applications**. Choose *All applications* from the **Application Type** drop-down menu, then select **Apply**.

-1. Search for each of the following application IDs. For Azure Global, search for AppId value `2565bd9d-da50-47d4-8b85-4c97f669dc36`. For other Azure clouds, search for AppId value `6ba9a5d4-8456-4118-b521-9c5ca10cdf84`. If no existing application is found, follow the *Resolution* steps to create the service principal or re-register the namespace.

- | Application ID | Resolution |

- | : | : |

- | 2565bd9d-da50-47d4-8b85-4c97f669dc36 | [Recreate a missing service principal](#recreate-a-missing-service-principal) |

- | 443155a6-77f3-45e3-882b-22b3a8d431fb | [Re-register the `Microsoft.AAD` namespace](#re-register-the-microsoft-aad-namespace) |

- | abba844e-bc0e-44b0-947a-dc74e5d09022 | [Re-register the `Microsoft.AAD` namespace](#re-register-the-microsoft-aad-namespace) |

- | d87dcbc6-a371-462e-88e3-28ad15ec4e64 | [Re-register the `Microsoft.AAD` namespace](#re-register-the-microsoft-aad-namespace) |

-### Recreate a missing Service Principal

-If application ID *2565bd9d-da50-47d4-8b85-4c97f669dc36* is missing from your Microsoft Entra directory in Azure Global, use Azure AD PowerShell to complete the following steps. For other Azure clouds, use AppId value *6ba9a5d4-8456-4118-b521-9c5ca10cdf84*. For more information, see [Azure AD PowerShell](/powershell/azure/active-directory/install-adv2).

-1. If needed, install the Azure AD PowerShell module and import it as follows:

- ```powershell

- Install-Module AzureAD

- Import-Module AzureAD

- ```

-1. Now recreate the service principal using the [New-AzureAdServicePrincipal][New-AzureAdServicePrincipal] cmdlet:

- ```powershell

- New-AzureAdServicePrincipal -AppId "2565bd9d-da50-47d4-8b85-4c97f669dc36"

- ```

-The managed domain's health automatically updates itself within two hours and removes the alert.

-<a name='re-register-the-microsoft-aad-namespace'></a>

-### Re-register the Microsoft Entra namespace

-If application ID `443155a6-77f3-45e3-882b-22b3a8d431fb`, `abba844e-bc0e-44b0-947a-dc74e5d09022`, or `d87dcbc6-a371-462e-88e3-28ad15ec4e64` is missing from your Microsoft Entra directory, complete the following steps to re-register the `Microsoft.AAD` resource provider:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Subscriptions**.

-1. Choose the subscription associated with your managed domain.

-1. From the left-hand navigation, choose **Resource Providers**.

-1. Search for `Microsoft.AAD`, then select **Re-register**.

-The managed domain's health automatically updates itself within two hours and removes the alert.

-## Alert AADDS105: Password synchronization application is out of date

-### Alert message

-*The service principal with the application ID "d87dcbc6-a371-462e-88e3-28ad15ec4e64" was deleted and then recreated. The recreation leaves behind inconsistent permissions on Microsoft Entra Domain Services resources needed to service your managed domain. Synchronization of passwords on your managed domain could be affected.*

-Domain Services automatically synchronizes user accounts and credentials from Microsoft Entra ID. If there's a problem with the Microsoft Entra application used for this process, credential synchronization between Domain Services and Microsoft Entra ID fails.

-### Resolution

-To recreate the Microsoft Entra application used for credential synchronization, use Azure AD PowerShell to complete the following steps. For more information, see [install Azure AD PowerShell](/powershell/azure/active-directory/install-adv2).

-1. If needed, install the Azure AD PowerShell module and import it as follows:

- ```powershell

- Install-Module AzureAD

- Import-Module AzureAD

- ```

-2. Now delete the old application and object using the following PowerShell cmdlets:

- ```powershell

- $app = Get-AzureADApplication -Filter "IdentifierUris eq 'https://sync.aaddc.activedirectory.windowsazure.com'"

- Remove-AzureADApplication -ObjectId $app.ObjectId

- $spObject = Get-AzureADServicePrincipal -Filter "DisplayName eq 'Azure AD Domain Services Sync'"

- Remove-AzureADServicePrincipal -ObjectId $spObject

- ```

-After you delete both applications, the Azure platform automatically recreates them and tries to resume password synchronization. The managed domain's health automatically updates itself within two hours and removes the alert.

-## Next steps

-If you still have issues, [open an Azure support request][azure-support] for additional troubleshooting assistance.

-<!-- INTERNAL LINKS -->

-[azure-support]: /azure/active-directory/fundamentals/how-to-get-support

-<!-- EXTERNAL LINKS -->

-[New-AzureAdServicePrincipal]: /powershell/module/azuread/new-azureadserviceprincipal

-description: Learn how to the SKU tier for a Microsoft Entra Domain Services managed domain if your business requirements change

-#Customer intent: As an identity administrator, I want to change the SKU for my Microsoft Entra Domain Services managed domain to use different features as my business requirements change.

-# Change the SKU for an existing Microsoft Entra Domain Services managed domain

-In Microsoft Entra Domain Services, the available performance and features are based on the SKU type. These feature differences include the backup frequency or maximum number of one-way outbound forest trusts.

-You select a SKU when you create the managed domain, and you can switch SKUs up or down as your business needs change after the managed domain has been deployed. Changes in business requirements could include the need for more frequent backups or to create additional forest trusts. For more information on the limits and pricing of the different SKUs, see [Domain Services SKU concepts][concepts-sku] and [Domain Services pricing][pricing] pages.

-This article shows you how to change the SKU for an existing Domain Services managed domain using the [Microsoft Entra admin center](https://entra.microsoft.com).

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, complete the tutorial to [create and configure a managed domain][create-azure-ad-ds-instance].

-## SKU change limitations

-You can change SKUs up or down after the managed domain has been deployed. However, the *Premium* and *Enterprise* SKUs define a limit on the number of trusts you can create. You can't change to a SKU with a lower maximum limit than you currently have configured.

-For example, if you have created seven trusts on the *Premium* SKU, you can't change down to the *Enterprise* SKU. The *Enterprise* SKU supports a maximum of five trusts.

-For more information on these limits, see [Domain Services SKU features and limits][concepts-sku].

-## Select a new SKU

-To change the SKU for a managed domain using the [Microsoft Entra admin center](https://entra.microsoft.com), complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Microsoft Entra Domain Services**. Choose your managed domain from the list, such as *aaddscontoso.com*.

-1. In the menu on the left-hand side of the Domain Services page, select **Settings > SKU**.

- 

-1. From the drop-down menu, select the SKU you wish for your managed domain. If you have a resource forest, you can't select *Standard* SKU as forest trusts are only available on the *Enterprise* SKU or higher.

- Choose the SKU you want from the drop-down menu, then select **Save**.

- 

-It can take a minute or two to change the SKU type.

-## Next steps

-If you have a resource forest and want to create additional trusts after the SKU change, see [Create an outbound forest trust to an on-premises domain in Domain Services][create-trust].

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[concepts-sku]: administration-concepts.md#azure-ad-ds-skus

-[create-trust]: tutorial-create-forest-trust.md

-<!-- EXTERNAL LINKS -->

-[pricing]: https://azure.microsoft.com/pricing/details/active-directory-ds/

-description: Learn how to check the health of a Microsoft Entra Domain Services managed domain and understand status messages.

-# Check the health of a Microsoft Entra Domain Services managed domain

-Microsoft Entra Domain Services runs some background tasks to keep the managed domain healthy and up-to-date. These tasks include taking backups, applying security updates, and synchronizing data from Microsoft Entra ID. If there are issues with the Domain Services managed domain, these tasks may not successfully complete. To review and resolve any issues, you can check the health status of a managed domain using the Microsoft Entra admin center.

-This article shows you how to view the Domain Services health status and understand the information or alerts shown.

-## View the health status

-The health status for a managed domain is viewed using the Microsoft Entra admin center. Information on the last backup time and synchronization with Microsoft Entra ID can be seen, along with any alerts that indicate a problem with the managed domain's health. To view the health status for a managed domain, complete the following steps:

-1. Sign in to [Microsoft Entra admin center](https://entra.microsoft.com) as a [Global Administrator](/azure/active-directory/roles/permissions-reference#global-administrator).

-1. Search for and select **Microsoft Entra Domain Services**.

-1. Select your managed domain, such as *aaddscontoso.com*.

-1. On the left-hand side of the Domain Services resource window, select **Health**. The following example screenshot shows a healthy managed domain and the status of the last backup and Azure AD synchronization:

- 

-The *Last evaluated* timestamp of the health page shows when the managed domain was last checked. The health of a managed domain is evaluated every hour. If you make any changes to a managed domain, wait until the next evaluation cycle to view the updated health status.

-The status in the top right indicates the overall health of the managed domain. The status factors all of the existing alerts on your domain. The following table details the available status indicators:

-| Status | Icon | Explanation |

-| | :-: | |

-| Running | <img src= "./media/active-directory-domain-services-alerts/running-icon.png" width = "15" alt="Green check mark for running"> | The managed domain is running correctly and doesn't have any critical or warning alerts. The domain may have informational alerts. |

-| Needs attention (warning) | <img src= "./media/active-directory-domain-services-alerts/warning-icon.png" width = "15" alt="Yellow exclamation mark for warning"> | There are no critical alerts on the managed domain, but there are one or more warning alerts that should be addressed. |

-| Needs attention (critical) | <img src= "./media/active-directory-domain-services-alerts/critical-icon.png" width = "15" alt="Red exclamation mark for critical"> | There are one or more critical alerts on the managed domain that must be addressed. You may also have warning and / or informational alerts. |

-| Deploying | <img src= "./media/active-directory-domain-services-alerts/deploying-icon.png" width = "15" alt="Blue circular arrows for deploying"> | The managed domain is being deployed. |

-## Understand monitors and alerts

-The health status for a managed domain show two types of information - *monitors*, and *alerts*. Monitors show the time that core background tasks were completed. Alerts provide information or suggestions to improve the stability of the managed domain.

-### Monitors

-Monitors are areas of a managed domain that are checked on a regular basis. If there are any active alerts for the managed domain, it may cause one of the monitors to report an issue. Domain Services currently has monitors for the following areas:

-* Backup

-* Synchronization with Microsoft Entra ID

-#### Backup monitor

-The backup monitor checks that automated regular backups of the managed domain successfully run. The following table details the available backup monitor status:

-| Detail value | Explanation |

-| | |

-| Never backed up | This state is normal for new managed domains. The first backup should be created 24 hours after the managed domain is deployed. If this status persists, [open an Azure support request][azure-support]. |

-| Last backup was taken 1 to 14 days ago | This time range is the expected status for the backup monitor. Automated regular backups should occur in this period. |

-| Last backup was taken more than 14 days ago. | A timespan longer than two weeks indicates there's an issue with the automated regular backups. Active critical alerts may prevent the managed domain from being backed up. Resolve any active alerts for the managed domain. If the backup monitor doesn't then update the status to report a recent backup, [open an Azure support request][azure-support]. |

-<a name='synchronization-with-azure-ad-monitor'></a>

-#### Synchronization with Microsoft Entra ID monitor

-A managed domain regularly synchronizes with Microsoft Entra ID. The number of users and group objects, and the number of changes made in the Microsoft Entra directory since the last sync, affects how long it takes to synchronize. If the managed domain was last synchronized over three days ago, check for and resolve any active alerts. If the synchronization monitor doesn't update the status to show a recent sync after you address any active alerts, [open an Azure support request][azure-support].

-### Alerts

-Alerts are generated for issues in a managed domain that need to be addressed for the service to run correctly. Each alert explains the problem and gives a URL that outlines specific steps to resolve the issue. For more information on the possible alerts and their resolutions, see [Troubleshooting alerts](troubleshoot-alerts.md).

-Health status alerts are categorized into the following levels of severity:

- * **Critical alerts** are issues that severely impact the managed domain. These alerts should be addressed immediately. The Azure platform can't monitor, manage, patch, and synchronize the managed domain until the issues are resolved.

- * **Warning alerts** notify you of issues that may impact the managed domain operations if the problem persists. These alerts also offer recommendations to secure the managed domain.

- * **Informational alerts** are notifications that don't negatively impact the managed domain. Informational alerts provide some insight as to what's happening in the managed domain.

-## Next steps

-For more information on alerts that are shown in the health status page, see [Resolve alerts on your managed domain][troubleshoot-alerts]

-<!-- INTERNAL LINKS -->

-[azure-support]: /azure/active-directory/fundamentals/how-to-get-support

-[troubleshoot-alerts]: troubleshoot-alerts.md

-description: In this overview, you compare the different identity offerings for Active Directory Domain Services, Microsoft Entra ID, and Microsoft Entra Domain Services.

-#Customer intent: As an IT administrator or decision maker, I want to understand the differences between Active Directory Domain Services (AD DS), Microsoft Entra ID, and Domain Services so I can choose the most appropriate identity solution for my organization.

-# Compare self-managed Active Directory Domain Services, Microsoft Entra ID, and managed Microsoft Entra Domain Services

-To provide applications, services, or devices access to a central identity, there are three common ways to use Active Directory-based services in Azure. This choice in identity solutions gives you the flexibility to use the most appropriate directory for your organization's needs. For example, if you mostly manage cloud-only users that run mobile devices, it may not make sense to build and run your own Active Directory Domain Services (AD DS) identity solution. Instead, you could just use Microsoft Entra ID.

-Although the three Active Directory-based identity solutions share a common name and technology, they're designed to provide services that meet different customer demands. At high level, these identity solutions and feature sets are:

-* **Active Directory Domain Services (AD DS)** - Enterprise-ready lightweight directory access protocol (LDAP) server that provides key features such as identity and authentication, computer object management, group policy, and trusts.

- * AD DS is a central component in many organizations with an on-premises IT environment, and provides core user account authentication and computer management features.

- * For more information, see [Active Directory Domain Services overview in the Windows Server documentation][overview-adds].

-* **Microsoft Entra ID** - Cloud-based identity and mobile device management that provides user account and authentication services for resources such as Microsoft 365, the Microsoft Entra admin center, or SaaS applications.

- * Microsoft Entra ID can be synchronized with an on-premises AD DS environment to provide a single identity to users that works natively in the cloud.

- * For more information about Microsoft Entra ID, see [What is Microsoft Entra ID?][whatis-azuread]

-* **Microsoft Entra Domain Services** - Provides managed domain services with a subset of fully compatible traditional AD DS features such as domain join, group policy, LDAP, and Kerberos / NTLM authentication.

- * Domain Services integrates with Microsoft Entra ID, which itself can synchronize with an on-premises AD DS environment. This ability extends central identity use cases to traditional web applications that run in Azure as part of a lift-and-shift strategy.

- * To learn more about synchronization with Microsoft Entra ID and on-premises, see [How objects and credentials are synchronized in a managed domain][synchronization].

-This overview article compares and contrasts how these identity solutions can work together, or would be used independently, depending on the needs of your organization.

-> [!div class="nextstepaction"]

-> [To get started, create a Domain Services managed domain using the Microsoft Entra admin center][tutorial-create]

-<a name='azure-ad-ds-and-self-managed-ad-ds'></a>

-## Domain Services and self-managed AD DS

-If you have applications and services that need access to traditional authentication mechanisms such as Kerberos or NTLM, there are two ways to provide Active Directory Domain Services in the cloud:

-* A *managed domain* that you create using Microsoft Entra Domain Services. Microsoft creates and manages the required resources.

-* A *self-managed* domain that you create and configure using traditional resources such as virtual machines (VMs), Windows Server guest OS, and Active Directory Domain Services (AD DS). You then continue to administer these resources.

-With Domain Services, the core service components are deployed and maintained for you by Microsoft as a *managed* domain experience. You don't deploy, manage, patch, and secure the AD DS infrastructure for components like the VMs, Windows Server OS, or domain controllers (DCs).

-Domain Services provides a smaller subset of features to traditional self-managed AD DS environment, which reduces some of the design and management complexity. For example, there are no AD forests, domain, sites, and replication links to design and maintain. You can still [create forest trusts between Domain Services and on-premises environments][create-forest-trust].

-For applications and services that run in the cloud and need access to traditional authentication mechanisms such as Kerberos or NTLM, Domain Services provides a managed domain experience with the minimal amount of administrative overhead. For more information, see [Management concepts for user accounts, passwords, and administration in Domain Services][administration-concepts].

-When you deploy and run a self-managed AD DS environment, you have to maintain all of the associated infrastructure and directory components. There's additional maintenance overhead with a self-managed AD DS environment, but you're then able to do additional tasks such as extend the schema or create forest trusts.

-Common deployment models for a self-managed AD DS environment that provides identity to applications and services in the cloud include the following:

-* **Standalone cloud-only AD DS** - Azure VMs are configured as domain controllers and a separate, cloud-only AD DS environment is created. This AD DS environment doesn't integrate with an on-premises AD DS environment. A different set of credentials is used to sign in and administer VMs in the cloud.

-* **Extend on-premises domain to Azure** - An Azure virtual network connects to an on-premises network using a VPN / ExpressRoute connection. Azure VMs connect to this Azure virtual network, which lets them domain-join to the on-premises AD DS environment.

- * An alternative is to create Azure VMs and promote them as replica domain controllers from the on-premises AD DS domain. These domain controllers replicate over a VPN / ExpressRoute connection to the on-premises AD DS environment. The on-premises AD DS domain is effectively extended into Azure.

-The following table outlines some of the features you may need for your organization, and the differences between a managed domain or a self-managed AD DS domain:

-| **Feature** | **Managed domain** | **Self-managed AD DS** |

-| -- |::|:-:|

-| **Managed service** | **&#x2713;** | **&#x2715;** |

-| **Secure deployments** | **&#x2713;** | Administrator secures the deployment |

-| **DNS server** | **&#x2713;** (managed service) |**&#x2713;** |

-| **Domain or Enterprise administrator privileges** | **&#x2715;** | **&#x2713;** |

-| **Domain join** | **&#x2713;** | **&#x2713;** |

-| **Domain authentication using NTLM and Kerberos** | **&#x2713;** | **&#x2713;** |

-| **Kerberos constrained delegation** | Resource-based | Resource-based & account-based|

-| **Custom OU structure** | **&#x2713;** | **&#x2713;** |

-| **Group Policy** | **&#x2713;** | **&#x2713;** |

-| **Schema extensions** | **&#x2715;** | **&#x2713;** |

-| **AD domain / forest trusts** | **&#x2713;** (one-way outbound forest trusts only) | **&#x2713;** |

-| **Secure LDAP (LDAPS)** | **&#x2713;** | **&#x2713;** |

-| **LDAP read** | **&#x2713;** | **&#x2713;** |

-| **LDAP write** | **&#x2713;** (within the managed domain) | **&#x2713;** |

-| **Geo-distributed deployments** | **&#x2713;** | **&#x2713;** |

-<a name='azure-ad-ds-and-azure-ad'></a>

-## Domain Services and Microsoft Entra ID

-Microsoft Entra ID lets you manage the identity of devices used by the organization and control access to corporate resources from those devices. Users can also register their personal device (a bring-your-own (BYO) model) with Microsoft Entra ID, which provides the device with an identity. Microsoft Entra ID then authenticates the device when a user signs in to Microsoft Entra ID and uses the device to access secured resources. The device can be managed using Mobile Device Management (MDM) software like Microsoft Intune. This management ability lets you restrict access to sensitive resources to managed and policy-compliant devices.

-Traditional computers and laptops can also join to Microsoft Entra ID. This mechanism offers the same benefits of registering a personal device with Microsoft Entra ID, such as to allow users to sign in to the device using their corporate credentials.

-Microsoft Entra joined devices give you the following benefits:

-* Single-sign-on (SSO) to applications secured by Microsoft Entra ID.

-* Enterprise policy-compliant roaming of user settings across devices.

-* Access to the Windows Store for Business using corporate credentials.

-* Windows Hello for Business.

-* Restricted access to apps and resources from devices compliant with corporate policy.

-Devices can be joined to Microsoft Entra ID with or without a hybrid deployment that includes an on-premises AD DS environment. The following table outlines common device ownership models and how they would typically be joined to a domain:

-| **Type of device** | **Device platforms** | **Mechanism** |

-|:-| -- | - |

-| Personal devices | Windows 10, iOS, Android, macOS | Microsoft Entra registered |

-| Organization-owned device not joined to on-premises AD DS | Windows 10 | Microsoft Entra joined |

-| Organization-owned device joined to an on-premises AD DS | Windows 10 | Microsoft Entra hybrid joined |

-On a Microsoft Entra joined or registered device, user authentication happens using modern OAuth / OpenID Connect based protocols. These protocols are designed to work over the internet, so are great for mobile scenarios where users access corporate resources from anywhere.

-With Domain Services-joined devices, applications can use the Kerberos and NTLM protocols for authentication, so can support legacy applications migrated to run on Azure VMs as part of a lift-and-shift strategy. The following table outlines differences in how the devices are represented and can authenticate themselves against the directory:

-| **Aspect** | **Microsoft Entra joined** | **Domain Services-joined** |

-|:--| | - |

-| Device controlled by | Microsoft Entra ID | Domain Services managed domain |

-| Representation in the directory | Device objects in the Microsoft Entra directory | Computer objects in the Domain Services managed domain |

-| Authentication | OAuth / OpenID Connect based protocols | Kerberos and NTLM protocols |

-| Management | Mobile Device Management (MDM) software like Intune | Group Policy |

-| Networking | Works over the internet | Must be connected to, or peered with, the virtual network where the managed domain is deployed |

-| Great for... | End-user mobile or desktop devices | Server VMs deployed in Azure |

-If on-premises AD DS and Microsoft Entra ID are configured for federated authentication using AD FS, then there's no (current/valid) password hash available in Azure DS. Microsoft Entra user accounts created before fed auth was implemented might have an old password hash but this likely doesn't match a hash of their on-premises password. As a result, Domain Services won't be able to validate the users credentials

-## Next steps

-To get started with using Domain Services, [create a Domain Services managed domain using the Microsoft Entra admin center][tutorial-create].

-You can also learn more about

-[management concepts for user accounts, passwords, and administration in Domain Services][administration-concepts] and [how objects and credentials are synchronized in a managed domain][synchronization].

-<!-- INTERNAL LINKS -->

-[manage-dns]: manage-dns.md

-[deploy-kcd]: deploy-kcd.md

-[custom-ou]: create-ou.md

-[manage-gpos]: manage-group-policy.md

-[tutorial-ldaps]: tutorial-configure-ldaps.md

-[tutorial-create]: tutorial-create-instance.md

-[whatis-azuread]: /azure/active-directory/fundamentals/whatis

-[overview-adds]: /windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview

-[create-forest-trust]: tutorial-create-forest-trust.md

-[administration-concepts]: administration-concepts.md

-[synchronization]: synchronization.md

-description: Learn how to create and manage custom attributes in a Domain Services managed domain.

-# Custom attributes for Microsoft Entra Domain Services

-For various reasons, companies often canΓÇÖt modify code for legacy apps. For example, apps may use a custom attribute, such as a custom employee ID, and rely on that attribute for LDAP operations.

-Microsoft Entra ID supports adding custom data to resources using [extensions](/graph/extensibility-overview). Microsoft Entra Domain Services can synchronize the following types of extensions from Microsoft Entra ID, so you can also use apps that depend on custom attributes with Domain

-Both types of extensions can be configured by using Microsoft Entra Connect for users who are managed on-premises, or Microsoft Graph APIs for cloud-only users.

->[!Note]

->The following types of extensions aren't supported for synchronization:

->- Custom security attributes in Microsoft Entra ID (Preview)

->- Microsoft Graph schema extensions

->- Microsoft Graph open extensions

-## Requirements

-The minimum SKU supported for custom attributes is the Enterprise SKU. If you use Standard, you need to [upgrade](change-sku.md) the managed domain to Enterprise or Premium. For more information, see [Microsoft Entra Domain Pricing](https://azure.microsoft.com/pricing/details/active-directory-ds/).

-## How Custom Attributes work

-After you create a managed domain, click **Custom Attributes (Preview)** under **Settings** to enable attribute synchronization. Click **Save** to confirm the change.

-## Enable predefined attribute synchronization

-Click **OnPremisesExtensionAttributes** to synchronize the attributes extensionAttribute1-15, also known as [Exchange custom attributes](/graph/api/resources/onpremisesextensionattributes).

-<a name='synchronize-azure-ad-directory-extension-attributes-'></a>

-## Synchronize Microsoft Entra directory extension attributes

-These are the extended user or group attributes defined in your Microsoft Entra tenant.

-Select **+ Add** to choose which custom attributes to synchronize. The list shows the available extension properties in your tenant. You can filter the list by using the search bar.

-If you don't see the directory extension you are looking for, enter the extensionΓÇÖs associated application appId and click **Search** to load only that applicationΓÇÖs defined extension properties. This search helps when multiple applications define many extensions in your tenant.

->[!NOTE]

->If you would like to see directory extensions synchronized by Microsoft Entra Connect, click **Enterprise App** and look for the Application ID of the **Tenant Schema Extension App**. For more information, see [Microsoft Entra Connect Sync: Directory extensions](/azure/active-directory/hybrid/connect/how-to-connect-sync-feature-directory-extensions#configuration-changes-in-azure-ad-made-by-the-wizard).

-Click **Select**, and then **Save** to confirm the change.

-Domain Services back fills all synchronized users and groups with the onboarded custom attribute values. The custom attribute values gradually populate for objects that contain the directory extension in Microsoft Entra ID. During the backfill synchronization process, incremental changes in Microsoft Entra ID are paused, and the sync time depends on the size of the tenant.

-To check the backfilling status, click **Domain Services Health** and verify the **Synchronization with Microsoft Entra ID** monitor has an updated timestamp within an hour since onboarding. Once updated, the backfill is complete.

-## Next steps

-To configure onPremisesExtensionAttributes or directory extensions for cloud-only users in Microsoft Entra ID, see [Custom data options in Microsoft Graph](/graph/extensibility-overview?tabs=http#custom-data-options-in-microsoft-graph).

-To sync onPremisesExtensionAttributes or directory extensions from on-premises to Microsoft Entra ID, [configure Microsoft Entra Connect](/azure/active-directory/hybrid/connect/how-to-connect-sync-feature-directory-extensions).

-description: Learn more about how forest trust work with Microsoft Entra Domain Services

-# How trust relationships work for forests in Active Directory

-Active Directory Domain Services (AD DS) provides security across multiple domains or forests through domain and forest trust relationships. Before authentication can occur across trusts, Windows must first check if the domain being requested by a user, computer, or service has a trust relationship with the domain of the requesting account.

-To check for this trust relationship, the Windows security system computes a trust path between the domain controller (DC) for the server that receives the request and a DC in the domain of the requesting account.

-The access control mechanisms provided by AD DS and the Windows distributed security model provide an environment for the operation of domain and forest trusts. For these trusts to work properly, every resource or computer must have a direct trust path to a DC in the domain in which it is located.

-The trust path is implemented by the Net Logon service using an authenticated remote procedure call (RPC) connection to the trusted domain authority. A secured channel also extends to other AD DS domains through interdomain trust relationships. This secured channel is used to obtain and verify security information, including security identifiers (SIDs) for users and groups.

->[!NOTE]

->Domain Services only supports one-way transitive trusts where the managed domain will trust other domains, but no other directions or trust types are supported.

-For an overview of how trusts apply to Domain Services, see [Forest concepts and features][create-forest-trust].

-To get started using trusts in Domain Services, [create a managed domain that uses forest trusts][tutorial-create-advanced].

-## Trust relationship flows

-The flow of secured communications over trusts determines the elasticity of a trust. How you create or configure a trust determines how far the communication extends within or across forests.

-The flow of communication over trusts is determined by the direction of the trust. Trusts can be one-way or two-way, and can be transitive or non-transitive.

-The following diagram shows that all domains in *Tree 1* and *Tree 2* have transitive trust relationships by default. As a result, users in *Tree 1* can access resources in domains in *Tree 2* and users in *Tree 2* can access resources in *Tree 1*, when the proper permissions are assigned at the resource.

-

-### One-way and two-way trusts

-Trust relationships enable access to resources can be either one-way or two-way.

-A one-way trust is a unidirectional authentication path created between two domains. In a one-way trust between *Domain A* and *Domain B*, users in *Domain A* can access resources in *Domain B*. However, users in *Domain B* can't access resources in *Domain A*.

-Some one-way trusts can be either non-transitive or transitive depending on the type of trust being created.

-In a two-way trust, *Domain A* trusts *Domain B* and *Domain B* trusts *Domain A*. This configuration means that authentication requests can be passed between the two domains in both directions. Some two-way relationships can be non-transitive or transitive depending on the type of trust being created.

-All domain trusts in an AD DS forest are two-way, transitive trusts. When a new child domain is created, a two-way, transitive trust is automatically created between the new child domain and the parent domain.

-### Transitive and non-transitive trusts

-Transitivity determines whether a trust can be extended outside of the two domains with which it was formed.

-* A transitive trust can be used to extend trust relationships with other domains.

-* A non-transitive trust can be used to deny trust relationships with other domains.

-Each time you create a new domain in a forest, a two-way, transitive trust relationship is automatically created between the new domain and its parent domain. If child domains are added to the new domain, the trust path flows upward through the domain hierarchy extending the initial trust path created between the new domain and its parent domain. Transitive trust relationships flow upward through a domain tree as it is formed, creating transitive trusts between all domains in the domain tree.

-Authentication requests follow these trust paths, so accounts from any domain in the forest can be authenticated by any other domain in the forest. With a single sign in process, accounts with the proper permissions can access resources in any domain in the forest.

-## Forest trusts

-Forest trusts help you to manage a segmented AD DS infrastructures and support access to resources and other objects across multiple forests. Forest trusts are useful for service providers, companies undergoing mergers or acquisitions, collaborative business extranets, and companies seeking a solution for administrative autonomy.

-Using forest trusts, you can link two different forests to form a one-way or two-way transitive trust relationship. A forest trust allows administrators to connect two AD DS forests with a single trust relationship to provide a seamless authentication and authorization experience across the forests.

-A forest trust can only be created between a forest root domain in one forest and a forest root domain in another forest. Forest trusts can only be created between two forests and can't be implicitly extended to a third forest. This behavior means that if a forest trust is created between *Forest 1* and *Forest 2*, and another forest trust is created between *Forest 2* and *Forest 3*, *Forest 1* doesn't have an implicit trust with *Forest 3*.

-The following diagram shows two separate forest trust relationships between three AD DS forests in a single organization.

-

-This example configuration provides the following access:

-* Users in *Forest 2* can access resources in any domain in either *Forest 1* or *Forest 3*

-* Users in *Forest 3* can access resources in any domain in *Forest 2*

-* Users in *Forest 1* can access resources in any domain in *Forest 2*

-This configuration doesn't allow users in *Forest 1* to access resources in *Forest 3* or vice versa. To allow users in both *Forest 1* and *Forest 3* to share resources, a two-way transitive trust must be created between the two forests.

-If a one-way forest trust is created between two forests, members of the trusted forest can utilize resources located in the trusting forest. However, the trust operates in only one direction.

-For example, when a one-way, forest trust is created between *Forest 1* (the trusted forest) and *Forest 2* (the trusting forest):

-* Members of *Forest 1* can access resources located in *Forest 2*.

-* Members of *Forest 2* can't access resources located in *Forest 1* using the same trust.

-> [!IMPORTANT]

-> Microsoft Entra Domain Services only supports a one-way forest trust to on-premises Active Directory.

-### Forest trust requirements

-Before you can create a forest trust, you need to verify you have the correct Domain Name System (DNS) infrastructure in place. Forest trusts can only be created when one of the following DNS configurations is available:

-* A single root DNS server is the root DNS server for both forest DNS namespaces - the root zone contains delegations for each of the DNS namespaces and the root hints of all DNS servers include the root DNS server.

-* When there is no shared root DNS server and the root DNS servers in each forest DNS namespace use DNS conditional forwarders for each DNS namespace to route queries for names in the other namespace.

- > [!IMPORTANT]

- > Any Microsoft Entra Domain Services forest with a trust must use this DNS configuration. Hosting a DNS namespace other than the forest DNS namespace is not a feature of Microsoft Entra Domain Services. Conditional forwarders is the proper configuration.

-* When there is no shared root DNS server and the root DNS servers in each forest DNS namespace are use DNS secondary zones are configured in each DNS namespace to route queries for names in the other namespace.

-To create a forest trust, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory. Each trust is assigned a password that the administrators in both forests must know. Members of Enterprise Admins in both forests can create the trusts in both forests at once and, in this scenario, a password that is cryptographically random is automatically generated and written for both forests.

-A managed domain forest supports up to five one-way outbound forest trusts to on-premises forests. The outbound forest trust for Microsoft Entra Domain Services is created in the Microsoft Entra admin center. You don't manually create the trust with the managed domain itself. The incoming forest trust must be configured by a user with the privileges previously noted in the on-premises Active Directory.

-## Trust processes and interactions

-Many inter-domain and inter-forest transactions depend on domain or forest trusts in order to complete various tasks. This section describes the processes and interactions that occur as resources are accessed across trusts and authentication referrals are evaluated.

-### Overview of authentication referral processing

-When a request for authentication is referred to a domain, the domain controller in that domain must determine whether a trust relationship exists with the domain from which the request comes. The direction of the trust and whether the trust is transitive or nontransitive must also be determined before it authenticates the user to access resources in the domain. The authentication process that occurs between trusted domains varies according to the authentication protocol in use. The Kerberos V5 and NTLM protocols process referrals for authentication to a domain differently

-### Kerberos V5 referral processing

-The Kerberos V5 authentication protocol is dependent on the Net Logon service on domain controllers for client authentication and authorization information. The Kerberos protocol connects to an online Key Distribution Center (KDC) and the Active Directory account store for session tickets.

-The Kerberos protocol also uses trusts for cross-realm ticket-granting services (TGS) and to validate Privilege Attribute Certificates (PACs) across a secured channel. The Kerberos protocol performs cross-realm authentication only with non-Windows-brand operating system Kerberos realms such as an MIT Kerberos realm and does not need to interact with the Net Logon service.

-If the client uses Kerberos V5 for authentication, it requests a ticket to the server in the target domain from a domain controller in its account domain. The Kerberos KDC acts as a trusted intermediary between the client and server and provides a session key that enables the two parties to authenticate each other. If the target domain is different from the current domain, the KDC follows a logical process to determine whether an authentication request can be referred:

-1. Is the current domain trusted directly by the domain of the server that is being requested?

- * If yes, send the client a referral to the requested domain.

- * If no, go to the next step.

-2. Does a transitive trust relationship exist between the current domain and the next domain on the trust path?

- * If yes, send the client a referral to the next domain on the trust path.

- * If no, send the client a sign-in denied message.

-### NTLM referral processing

-The NTLM authentication protocol is dependent on the Net Logon service on domain controllers for client authentication and authorization information. This protocol authenticates clients that do not use Kerberos authentication. NTLM uses trusts to pass authentication requests between domains.

-If the client uses NTLM for authentication, the initial request for authentication goes directly from the client to the resource server in the target domain. This server creates a challenge to which the client responds. The server then sends the user's response to a domain controller in its computer account domain. This domain controller checks the user account against its security accounts database.

-If the account does not exist in the database, the domain controller determines whether to perform pass-through authentication, forward the request, or deny the request by using the following logic:

-1. Does the current domain have a direct trust relationship with the user's domain?

- * If yes, the domain controller sends the credentials of the client to a domain controller in the user's domain for pass-through authentication.

- * If no, go to the next step.

-2. Does the current domain have a transitive trust relationship with the user's domain?

- * If yes, pass the authentication request on to the next domain in the trust path. This domain controller repeats the process by checking the user's credentials against its own security accounts database.

- * If no, send the client a logon-denied message.

-### Kerberos-based processing of authentication requests over forest trusts

-When two forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests.

-When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores the information in a [trusted domain object](#trusted-domain-object). Trusted namespaces include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO objects are replicated to the global catalog.

->[!NOTE]

->Alternate UPN suffixes on trusts are not supported. If an on-premises domain uses the same UPN suffix as Domain Services, sign in must use **sAMAccountName**.

-Before authentication protocols can follow the forest trust path, the service principal name (SPN) of the resource computer must be resolved to a location in the other forest. An SPN can be one of the following names:

-* The DNS name of a host.

-* The DNS name of a domain.

-* The distinguished name of a service connection point object.

-When a workstation in one forest attempts to access data on a resource computer in another forest, the Kerberos authentication process contacts the domain controller for a service ticket to the SPN of the resource computer. Once the domain controller queries the global catalog and determines that the SPN is not in the same forest as the domain controller, the domain controller sends a referral for its parent domain back to the workstation. At that point, the workstation queries the parent domain for the service ticket and continues to follow the referral chain until it reaches the domain where the resource is located.

-The following diagram and steps provide a detailed description of the Kerberos authentication process that's used when computers running Windows attempt to access resources from a computer located in another forest.

-

-1. *User1* signs in to *Workstation1* using credentials from the *europe.tailspintoys.com* domain. The user then attempts to access a shared resource on *FileServer1* located in the *usa.wingtiptoys.com* forest.

-2. *Workstation1* contacts the Kerberos KDC on a domain controller in its domain, *ChildDC1*, and requests a service ticket for the *FileServer1* SPN.

-3. *ChildDC1* does not find the SPN in its domain database and queries the global catalog to see if any domains in the *tailspintoys.com* forest contain this SPN. Because a global catalog is limited to its own forest, the SPN is not found.

- The global catalog then checks its database for information about any forest trusts that are established with its forest. If found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match. Once a match is found, the global catalog provides a routing hint back to *ChildDC1*.

- Routing hints help direct authentication requests toward the destination forest. Hints are only used when all traditional authentication channels, such as local domain controller and then global catalog, fail to locate an SPN.

-4. *ChildDC1* sends a referral for its parent domain back to *Workstation1*.

-5. *Workstation1* contacts a domain controller in *ForestRootDC1* (its parent domain) for a referral to a domain controller (*ForestRootDC2*) in the forest root domain of the *wingtiptoys.com* forest.

-6. *Workstation1* contacts *ForestRootDC2* in the *wingtiptoys.com* forest for a service ticket to the requested service.

-7. *ForestRootDC2* contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it back to *ForestRootDC2*.

-8. *ForestRootDC2* then sends the referral to *usa.wingtiptoys.com* back to *Workstation1*.

-9. *Workstation1* contacts the KDC on *ChildDC2* and negotiates the ticket for *User1* to gain access to *FileServer1*.

-10. Once *Workstation1* has a service ticket, it sends the service ticket to *FileServer1*, which reads *User1*'s security credentials and constructs an access token accordingly.

-## Trusted domain object

-Each domain or forest trust within an organization is represented by a Trusted Domain Object (TDO) stored in the *System* container within its domain.

-### TDO contents

-The information contained in a TDO varies depending on whether a TDO was created by a domain trust or by a forest trust.

-When a domain trust is created, attributes such as the DNS domain name, domain SID, trust type, trust transitivity, and the reciprocal domain name are represented in the TDO. Forest trust TDOs store additional attributes to identify all of the trusted namespaces from the partner forest. These attributes include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces.

-Because trusts are stored in Active Directory as TDOs, all domains in a forest have knowledge of the trust relationships that are in place throughout the forest. Similarly, when two or more forests are joined together through forest trusts, the forest root domains in each forest have knowledge of the trust relationships that are in place throughout all of the domains in trusted forests.

-### TDO password changes

-Both domains in a trust relationship share a password, which is stored in the TDO object in Active Directory. As part of the account maintenance process, every 30 days the trusting domain controller changes the password stored in the TDO. Because all two-way trusts are actually two one-way trusts going in opposite directions, the process occurs twice for two-way trusts.

-A trust has a trusting and a trusted side. On the trusted side, any writable domain controller can be used for the process. On the trusting side, the PDC emulator performs the password change.

-To change a password, the domain controllers complete the following process:

-1. The primary domain controller (PDC) emulator in the trusting domain creates a new password. A domain controller in the trusted domain never initiates the password change. It's always initiated by the trusting domain PDC emulator.

-2. The PDC emulator in the trusting domain sets the *OldPassword* field of the TDO object to the current *NewPassword* field.

-3. The PDC emulator in the trusting domain sets the *NewPassword* field of the TDO object to the new password. Keeping a copy of the previous password makes it possible to revert to the old password if the domain controller in the trusted domain fails to receive the change, or if the change is not replicated before a request is made that uses the new trust password.

-4. The PDC emulator in the trusting domain makes a remote call to a domain controller in the trusted domain asking it to set the password on the trust account to the new password.

-5. The domain controller in the trusted domain changes the trust password to the new password.

-6. On each side of the trust, the updates are replicated to the other domain controllers in the domain. In the trusting domain, the change triggers an urgent replication of the trusted domain object.

-The password is now changed on both domain controllers. Normal replication distributes the TDO objects to the other domain controllers in the domain. However, it's possible for the domain controller in the trusting domain to change the password without successfully updating a domain controller in the trusted domain. This scenario might occur because a secured channel, which is required to process the password change, couldn't be established. It's also possible that the domain controller in the trusted domain might be unavailable at some point during the process and might not receive the updated password.

-To deal with situations in which the password change isn't successfully communicated, the domain controller in the trusting domain never changes the new password unless it has successfully authenticated (set up a secured channel) using the new password. This behavior is why both the old and new passwords are kept in the TDO object of the trusting domain.

-A password change isn't finalized until authentication using the password succeeds. The old, stored password can be used over the secured channel until the domain controller in the trusted domain receives the new password, thus enabling uninterrupted service.

-If authentication using the new password fails because the password is invalid, the trusting domain controller tries to authenticate using the old password. If it authenticates successfully with the old password, it resumes the password change process within 15 minutes.

-Trust password updates need to replicate to the domain controllers of both sides of the trust within 30 days. If the trust password is changed after 30 days and a domain controller only has the N-2 password, it cannot use the trust from the trusting side and cannot create a secure channel on the trusted side.

-## Network ports used by trusts

-Because trusts must be deployed across various network boundaries, they might have to span one or more firewalls. When this is the case, you can either tunnel trust traffic across a firewall or open specific ports in the firewall to allow the traffic to pass through.

-> [!IMPORTANT]

-> Active Directory Domain Services does not support restricting Active Directory RPC traffic to specific ports.

-Read the **Windows Server 2008 and later versions** section of the Microsoft Support Article [How to configure a firewall for Active Directory domains and trusts](https://support.microsoft.com/help/179442/how-to-configure-a-firewall-for-domains-and-trusts) to learn about the ports needed for a forest trust.

-## Supporting services and tools

-To support trusts and authentication, some additional features and management tools are used.

-### Net Logon

-The Net Logon service maintains a secured channel from a Windows-based computer to a DC. It's also used in the following trust-related processes:

-* Trust setup and management - Net Logon helps maintain trust passwords, gathers trust information, and verifies trusts by interacting with the LSA process and the TDO.

- For Forest trusts, the trust information includes the Forest Trust Information (*FTInfo*) record, which includes the set of namespaces that a trusted forest claims to manage, annotated with a field that indicates whether each claim is trusted by the trusting forest.

-* Authentication ΓÇô Supplies user credentials over a secured channel to a domain controller and returns the domain SIDs and user rights for the user.

-* Domain controller location ΓÇô Helps with finding or locating domain controllers in a domain or across domains.

-* Pass-through validation ΓÇô Credentials of users in other domains are processed by Net Logon. When a trusting domain needs to verify the identity of a user, it passes the user's credentials through Net Logon to the trusted domain for verification.

-* Privilege Attribute Certificate (PAC) verification ΓÇô When a server using the Kerberos protocol for authentication needs to verify the PAC in a service ticket, it sends the PAC across the secure channel to its domain controller for verification.

-### Local Security Authority

-The Local Security Authority (LSA) is a protected subsystem that maintains information about all aspects of local security on a system. Collectively known as local security policy, the LSA provides various services for translation between names and identifiers.

-The LSA security subsystem provides services in both kernel mode and user mode for validating access to objects, checking user privileges, and generating audit messages. LSA is responsible for checking the validity of all session tickets presented by services in trusted or untrusted domains.

-### Management tools

-Administrators can use *Active Directory Domains and Trusts*, *Netdom* and *Nltest* to expose, create, remove, or modify trusts.

-* *Active Directory Domains and Trusts* is the Microsoft Management Console (MMC) that is used to administer domain trusts, domain and forest functional levels, and user principal name suffixes.

-* The *Netdom* and *Nltest* command-line tools can be used to find, display, create, and manage trusts. These tools communicate directly with the LSA authority on a domain controller.

-## Next steps

-To get started with creating a managed domain with a forest trust, see [Create and configure a Domain Services managed domain][tutorial-create-advanced]. You can then [Create an outbound forest trust to an on-premises domain][create-forest-trust].

-<!-- LINKS - INTERNAL -->

-[tutorial-create-advanced]: tutorial-create-instance-advanced.md

-[create-forest-trust]: tutorial-create-forest-trust.md

-description: Learn what replica sets are in Microsoft Entra Domain Services and how they provide redundancy to applications that require identity services.

-# Replica sets concepts and features for Microsoft Entra Domain Services

-When you create a Microsoft Entra Domain Services managed domain, you define a unique namespace. This namespace is the domain name, such as *aaddscontoso.com*, and two domain controllers (DCs) are then deployed into your selected Azure region. This deployment of DCs is known as a replica set.

-You can expand a managed domain to have more than one replica set per Microsoft Entra tenant. Replica sets can be added to any peered virtual network in any Azure region that supports Domain Services. Additional replica sets in different Azure regions provide geographical disaster recovery for legacy applications if an Azure region goes offline.

-> [!NOTE]

-> Replica sets don't let you deploy multiple unique managed domains in a single Azure tenant. Each replica set contains the same data.

-## How replica sets work

-When you create a managed domain, such as *aaddscontoso.com*, an initial replica set is created. Additional replica sets share the same namespace and configuration. Changes to Domain Services, including configuration, user identity and credentials, groups, group policy objects, computer objects, and other changes are applied to all replica sets in the managed domain using AD DS replication.

-You create each replica set in a virtual network. Each virtual network must be peered to every other virtual network that hosts a managed domain's replica set. This configuration creates a mesh network topology that supports directory replication. A virtual network can support multiple replica sets, provided that each replica set is in a different virtual subnet.

-All replica sets are placed in the same Active Directory site. As the result, all changes are propagated using intrasite replication for quick convergence.

-> [!NOTE]

-> It's not possible to define separate sites and define replication settings between replica sets.

-The following diagram shows a managed domain with two replica sets. The first replica set is created with the domain namespace. A second replica set is created after that:

-

-> [!NOTE]

-> Replica sets ensure availability of authentication services in regions where a replica set is configured. For an application to have geographical redundancy if there's a regional outage, the application platform that relies on the managed domain must also reside in the other region.

->

-> Resiliency of other services required for the application to function, such as Azure VMs or Azure App Services, isn't provided by replica sets. Availability design of other application components needs to consider resiliency features for services that make up the application.

-The following example shows a managed domain with three replica sets to further provide resiliency and ensure availability of authentication services. In both examples, application workloads exist in the same region as the managed domain replica set:

-

-## Deployment considerations

-The default SKU for a managed domain is the *Enterprise* SKU, which supports multiple replica sets. To create additional replica sets if you changed to the *Standard* SKU, [upgrade the managed domain](change-sku.md) to *Enterprise* or *Premium*.

-The supported maximum number of replica sets is five, including the first replica created when you created the managed domain.

-Billing for each replica set is based on the domain configuration SKU. For example, if you have a managed domain that uses the *Enterprise* SKU and you have three replica sets, your subscription is billed per hour for each of the three replica sets.

-## Frequently asked questions

-### Can I create a replica set in subscription different from my managed domain?

-No. Replica sets must be in the same subscription as the managed domain.

-### How many replica sets can I create?

-You can create a maximum of five replica setsΓÇöthe initial replica set for the managed domain, plus four additional replica sets.

-### How does user and group information get synchronized to my replica sets?

-All replica sets are connected to each other using a mesh virtual network peering. One replica set receives user and group updates from Microsoft Entra ID. Those changes are then replicated to the other replica sets using intrasite AD DS replication over the peered network.

-Just like with on-premises AD DS, an extended disconnected state can cause disruption in replication. As peered virtual networks aren't transitive, the design requirements for replica sets requires a fully meshed network topology.

-### How do I make changes in my managed domain after I have replica sets?

-Changes within the managed domain work just like they previously did. You [create and use a management VM with the RSAT tools that is joined to the managed domain](tutorial-create-management-vm.md). You can join as many management VMs to the managed domain as you wish.

-## Next steps

-To get started with replica sets, [create and configure a Domain Services managed domain][tutorial-create-advanced]. When deployed, [create and use additional replica sets][create-replica-set].

-<!-- LINKS - INTERNAL -->

-[tutorial-create-advanced]: tutorial-create-instance-advanced.md

-[create-replica-set]: tutorial-create-replica-set.md

-description: In this article, learn how to create and configure a Microsoft Entra Domain Services forest trust to an on-premises Active Directory Domain Services environment using Azure PowerShell.

-#Customer intent: As an identity administrator, I want to create a Microsoft Entra Domain Services forest and one-way outbound trust from a Microsoft Entra Domain Services forest to an on-premises Active Directory Domain Services forest using Azure PowerShell to provide authentication and resource access between forests.

-# Create a Microsoft Entra Domain Services forest trust to an on-premises domain using Azure PowerShell

-In environments where you can't synchronize password hashes, or you have users that exclusively sign in using smart cards so they don't know their password, you can create a one-way outbound trust from Microsoft Entra Domain Services to one or more on-premises AD DS environments. This trust relationship lets users, applications, and computers authenticate against an on-premises domain from the Domain Services managed domain. In this case, on-premises password hashes are never synchronized.

-

-In this article, you learn how to:

-> [!div class="checklist"]

-> * Create a Domain Services forest using Azure PowerShell

-> * Create a one-way outbound forest trust in the managed domain using Azure PowerShell

-> * Configure DNS in an on-premises AD DS environment to support managed domain connectivity

-> * Create a one-way inbound forest trust in an on-premises AD DS environment

-> * Test and validate the trust relationship for authentication and resource access

-If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-> [!IMPORTANT]

-> Managed domain forests don't currently support Azure HDInsight or Azure Files. The default managed domain forests do support both of these additional services.

-## Prerequisites

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* Install and configure Azure PowerShell.

- * If needed, follow the instructions to [install the Azure PowerShell module and connect to your Azure subscription](/powershell/azure/install-azure-powershell).

- * Make sure that you sign in to your Azure subscription using the [Connect-AzAccount][Connect-AzAccount] cmdlet.

-* Install and configure Azure AD PowerShell.

- * If needed, follow the instructions to [install the Azure AD PowerShell module and connect to Microsoft Entra ID](/powershell/azure/active-directory/install-adv2).

- * Make sure that you sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet.

-* You need [Application Administrator](/azure/active-directory/roles/permissions-reference#application-administrator) and [Groups Administrator](/azure/active-directory/roles/permissions-reference#groups-administrator) Microsoft Entra roles in your tenant to enable Domain Services.

-* You need [Domain Services Contributor](/azure/role-based-access-control/built-in-roles#contributor) Azure role to create the required Domain Services resources.

-## Sign in to the Microsoft Entra admin center

-In this article, you create and configure the outbound forest trust from a managed domain using the Microsoft Entra admin center. To get started, first sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).

-## Deployment process

-It's a multi-part process to create a managed domain forest and the trust relationship to an on-premises AD DS. The following high-level steps build your trusted, hybrid environment:

-1. Create a managed domain service principal.

-1. Create a managed domain forest.

-1. Create hybrid network connectivity using site-to-site VPN or Express Route.

-1. Create the managed domain side of the trust relationship.

-1. Create the on-premises AD DS side of the trust relationship.

-Before you start, make sure you understand the [network considerations, forest naming, and DNS requirements](tutorial-create-forest-trust.md#networking-considerations). You can't change the managed domain forest name once it's deployed.

-<a name='create-the-azure-ad-service-principal'></a>

-## Create the Microsoft Entra service principal

-Domain Services requires a service principal synchronize data from Microsoft Entra ID. This principal must be created in your Microsoft Entra tenant before you created the managed domain forest.

-Create a Microsoft Entra service principal for Domain Services to communicate and authenticate itself. A specific application ID is used named *Domain Controller Services* with an ID of *6ba9a5d4-8456-4118-b521-9c5ca10cdf84*. Don't change this application ID.

-Create a Microsoft Entra service principal using the [New-AzureADServicePrincipal][New-AzureADServicePrincipal] cmdlet:

-```powershell

-New-AzureADServicePrincipal -AppId "6ba9a5d4-8456-4118-b521-9c5ca10cdf84"

-```

-## Create a managed domain

-To create a managed domain, you use the `New-AzureAaddsForest` script. This script is part of a wider set of commands that support managed domains, including create the one-way bound forest in a following section. These scripts are available from the [PowerShell Gallery](https://www.powershellgallery.com/) and are digitally signed by the Microsoft Entra engineering team.

-1. First, create a resource group using the [New-AzResourceGroup][New-AzResourceGroup] cmdlet. In the following example, the resource group is named *myResourceGroup* and is created in the *westus* region. Use your own name and desired region:

- ```azurepowershell

- New-AzResourceGroup `

- -Name "myResourceGroup" `

- -Location "WestUS"

- ```

-1. Install the `New-AaddsResourceForestTrust` script from the [PowerShell Gallery][powershell-gallery] using the [Install-Script][Install-Script] cmdlet:

- ```powershell

- Install-Script -Name New-AaddsResourceForestTrust

- ```

-1. Review the following parameters needed for the `New-AzureAaddsForest` script. Make sure you also have the prerequisite **Azure PowerShell** and **Azure AD PowerShell** modules. Make sure you have planned the virtual network requirements to provide application and on-premises connectivity.

- | Name | Script parameter | Description |

- |:--||:|

- | Subscription | *-azureSubscriptionId* | Subscription ID used for Domain Services billing. You can get the list of subscriptions using the [Get-AzureRMSubscription][Get-AzureRMSubscription] cmdlet. |

- | Resource Group | *-aaddsResourceGroupName* | Name of the resource group for the managed domain and associated resources. |

- | Location | *-aaddsLocation* | The Azure region to host your managed domain. For available regions, see [supported regions for Domain Services.](https://azure.microsoft.com/global-infrastructure/services/?products=active-directory-ds&regions=all) |

- | Domain Services administrator | *-aaddsAdminUser* | The user principal name of the first managed domain administrator. This account must be an existing cloud user account in your Microsoft Entra ID. The user, and the user running the script, is added to the *AAD DC Administrators* group. |

- | Domain Services domain name | *-aaddsDomainName* | The FQDN of the managed domain, based on the previous guidance on how to choose a forest name. |

- The `New-AzureAaddsForest` script can create the Azure virtual network and Domain Services subnet if these resources don't already exist. The script can optionally create the workload subnets, when specified:

- | Name | Script parameter | Description |

- |:-|:-|:|

- | Virtual network name | *-aaddsVnetName* | Name of the virtual network for the managed domain.|

- | Address space | *-aaddsVnetCIDRAddressSpace* | Virtual network's address range in CIDR notation (if creating the virtual network).|

- | Domain Services subnet name | *-aaddsSubnetName* | Name of the subnet of the *aaddsVnetName* virtual network hosting the managed domain. Don't deploy your own VMs and workloads into this subnet. |

- | Domain Services address range | *-aaddsSubnetCIDRAddressRange* | Subnet address range in CIDR notation for the Domain Services instance, such as *192.168.1.0/24*. Address range must be contained by the address range of the virtual network, and different from other subnets. |

- | Workload subnet name (optional) | *-workloadSubnetName* | Optional name of a subnet in the *aaddsVnetName* virtual network to create for your own application workloads. VMs and applications and also be connected to a peered Azure virtual network instead. |

- | Workload address range (optional) | *-workloadSubnetCIDRAddressRange* | Optional subnet address range in CIDR notation for application workload, such as *192.168.2.0/24*. Address range must be contained by the address range of the virtual network, and different from other subnets.|

-1. Now create a managed domain forest using the `New-AzureAaaddsForest` script. The following example creates a forest named *addscontoso.com* and creates a workload subnet. Provide your own parameter names and IP address ranges or existing virtual networks.

- ```azurepowershell

- New-AzureAaddsForest `

- -azureSubscriptionId <subscriptionId> `

- -aaddsResourceGroupName "myResourceGroup" `

- -aaddsLocation "WestUS" `

- -aaddsAdminUser "contosoadmin@contoso.com" `

- -aaddsDomainName "aaddscontoso.com" `

- -aaddsVnetName "myVnet" `

- -aaddsVnetCIDRAddressSpace "192.168.0.0/16" `

- -aaddsSubnetName "AzureADDS" `

- -aaddsSubnetCIDRAddressRange "192.168.1.0/24" `

- -workloadSubnetName "myWorkloads" `

- -workloadSubnetCIDRAddressRange "192.168.2.0/24"

- ```

- It takes quite some time to create the managed domain forest and supporting resources. Allow the script to complete. Continue on to the next section to configure your on-premises network connectivity while the Microsoft Entra forest provisions in the background.

-## Configure and validate network settings

-As the managed domain continues to deploy, configure and validate the hybrid network connectivity to the on-premises datacenter. You also need a management VM to use with the managed domain for regular maintenance. Some of the hybrid connectivity may already exist in your environment, or you may need to work with others in your team to configure the connections.

-Before you start, make sure you understand the [network considerations and recommendations](tutorial-create-forest-trust.md#networking-considerations).

-1. Create the hybrid connectivity to your on-premises network to Azure using an Azure VPN or Azure ExpressRoute connection. The hybrid network configuration is beyond the scope of this documentation, and may already exist in your environment. For details on specific scenarios, see the following articles:

- * [Azure Site-to-Site VPN](/azure/vpn-gateway/vpn-gateway-about-vpngateways).

- * [Azure ExpressRoute Overview](/azure/expressroute/expressroute-introduction).

- > [!IMPORTANT]

- > If you create the connection directly to your managed domain's virtual network, use a separate gateway subnet. Don't create the gateway in the managed domain's subnet.

-1. To administer a managed domain, you create a management VM, join it to the managed domain, and install the required AD DS management tools.

- While the managed domain is being deployed, [create a Windows Server VM](./join-windows-vm.md) then [install the core AD DS management tools](./tutorial-create-management-vm.md) to install the needed management tools. Wait to join the management VM to the managed domain until one of the following steps after the domain is successfully deployed.

-1. Validate network connectivity between your on-premises network and the Azure virtual network.

- * Confirm that your on-premises domain controller can connect to the managed VM using `ping` or remote desktop, for example.

- * Verify that your management VM can connect to your on-premises domain controllers, again using a utility such as `ping`.

-1. In the Microsoft Entra admin center, search for and select **Microsoft Entra Domain Services**. Choose your managed domain, such as *aaddscontoso.com* and wait for the status to report as **Running**.

- When running, [update DNS settings for the Azure virtual network](tutorial-create-instance.md#update-dns-settings-for-the-azure-virtual-network) and then [enable user accounts for Domain Services](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) to finalize the configurations for your managed domain.

-1. Make a note of the DNS addresses shown on the overview page. You need these addresses when you configure the on-premises Active Directory side of the trust relationship in a following section.

-1. Restart the management VM for it to receive the new DNS settings, then [join the VM to the managed domain](join-windows-vm.md#join-the-vm-to-the-managed-domain).

-1. After the management VM is joined to the managed domain, connect again using remote desktop.

- From a command prompt, use `nslookup` and the managed domain name to validate name resolution for the forest.

- ```console

- nslookup aaddscontoso.com

- ```

- The command should return two IP addresses for the forest.

-## Create the forest trust

-The forest trust has two parts - the one-way outbound forest trust in the managed domain, and the one-way inbound forest trust in the on-premises AD DS forest. You manually create both sides of this trust relationship. When both sides are created, users and resources can successfully authenticate using the forest trust. A managed domain supports up to five one-way outbound forest trusts to on-premises forests.

-### Create the managed domain side of the trust relationship

-Use the `Add-AaddsResourceForestTrust` script to create the managed domain side of the trust relationship. First, install the `Add-AaddsResourceForestTrust` script from the [PowerShell Gallery][powershell-gallery] using the [Install-Script][Install-Script] cmdlet:

-```powershell

-Install-Script -Name Add-AaddsResourceForestTrust

-```

-Now provide the script the following information:

-| Name | Script parameter | Description |

-|:--|:|:|

-| Domain Services domain name | *-ManagedDomainFqdn* | FQDN of the managed domain, such as *aaddscontoso.com* |

-| On-premises AD DS domain name | *-TrustFqdn* | The FQDN of the trusted forest, such as *onprem.contoso.com* |

-| Trust friendly name | *-TrustFriendlyName* | Friendly name of the trust relationship. |

-| On-premises AD DS DNS IP addresses | *-TrustDnsIPs* | A comma-delimited list of DNS server IPv4 addresses for the trusted domain listed. |

-| Trust password | *-TrustPassword* | A complex password for the trust relationship. This password is also entered when creating the one-way inbound trust in the on-premises AD DS. |

-| Credentials | *-Credentials* | The credentials used to authenticate to Azure. The user must be in the *AAD DC Administrators group*. If not provided, the script prompts for authentication. |

-The following example creates a trust relationship named *myAzureADDSTrust* to *onprem.contoso.com*. Use your own parameter names and passwords:.

-```azurepowershell

-Add-AaddsResourceForestTrust `

- -ManagedDomainFqdn "aaddscontoso.com" `

- -TrustFqdn "onprem.contoso.com" `

- -TrustFriendlyName "myAzureADDSTrust" `

- -TrustDnsIPs "10.0.1.10,10.0.1.11" `

- -TrustPassword <complexPassword>

-```

-> [!IMPORTANT]

-> Remember your trust password. You must use the same password when your create the on-premises side of the trust.

-## Configure DNS in the on-premises domain

-To correctly resolve the managed domain from the on-premises environment, you may need to add forwarders to the existing DNS servers. If you haven't configure the on-premises environment to communicate with the managed domain, complete the following steps from a management workstation for the on-premises AD DS domain:

-1. Select **Start | Administrative Tools | DNS**

-1. Right-select DNS server, such as *myAD01*, select **Properties**

-1. Choose **Forwarders**, then **Edit** to add additional forwarders.

-1. Add the IP addresses of the managed domain, such as *10.0.1.4* and *10.0.1.5*.

-1. From a local command prompt, validate name resolution using **nslookup** of the managed domain name. For example, `Nslookup aaddscontoso.com` should return the two IP addresses for the managed domain.

-## Create inbound forest trust in the on-premises domain

-The on-premises AD DS domain needs an incoming forest trust for the managed domain. This trust must be manually created in the on-premises AD DS domain, it can't be created from the Microsoft Entra admin center.

-To configure inbound trust on the on-premises AD DS domain, complete the following steps from a management workstation for the on-premises AD DS domain:

-1. Select **Start | Administrative Tools | Active Directory Domains and Trusts**

-1. Right-select domain, such as *onprem.contoso.com*, select **Properties**

-1. Choose **Trusts** tab, then **New Trust**

-1. Enter the name of the managed domain, such as *aaddscontoso.com*, then select **Next**

-1. Select the option to create a **Forest trust**, then to create a **One way: incoming** trust.

-1. Choose to create the trust for **This domain only**. In the next step, you create the trust in the Microsoft Entra admin center for the managed domain.

-1. Choose to use **Forest-wide authentication**, then enter and confirm a trust password. This same password is also entered in the Microsoft Entra admin center in the next section.

-1. Step through the next few windows with default options, then choose the option for **No, do not confirm the outgoing trust**. You can't validate the trust relation because your delegated admin account to the managed domain doesn't have the required permissions. This behavior is by design.

-1. Select **Finish**

-## Validate resource authentication

-The following common scenarios let you validate that forest trust correctly authenticates users and access to resources:

-* [On-premises user authentication from the Domain Services forest](#on-premises-user-authentication-from-the-azure-ad-ds-forest)

-* [Access resources in the Domain Services forest as an on-premises user](#access-resources-in-azure-ad-ds-as-an-on-premises-user)

- * [Enable file and printer sharing](#enable-file-and-printer-sharing)

- * [Create a security group and add members](#create-a-security-group-and-add-members)

- * [Create a file share for cross-forest access](#create-a-file-share-for-cross-forest-access)

- * [Validate cross-forest authentication to a resource](#validate-cross-forest-authentication-to-a-resource)

-<a name='on-premises-user-authentication-from-the-azure-ad-ds-forest'></a>

-### On-premises user authentication from the Domain Services forest

-You should have Windows Server virtual machine joined to the managed domain resource domain. Use this virtual machine to test your on-premises user can authenticate on a virtual machine.

-1. Connect to the Windows Server VM joined to the managed domain using Remote Desktop and your managed domain administrator credentials. If you get a Network Level Authentication (NLA) error, check the user account you used is not a domain user account.

- > [!TIP]

- > To securely connect to your VMs joined to Microsoft Entra Domain Services, you can use the [Azure Bastion Host Service](/azure/bastion/bastion-overview) in supported Azure regions.

-1. Open a command prompt and use the `whoami` command to show the distinguished name of the currently authenticated user:

- ```console

- whoami /fqdn

- ```

-1. Use the `runas` command to authenticate as a user from the on-premises domain. In the following command, replace `userUpn@trusteddomain.com` with the UPN of a user from the trusted on-premises domain. The command prompts you for the user's password:

- ```console

- Runas /u:userUpn@trusteddomain.com cmd.exe

- ```

-1. If the authentication is a successful, a new command prompt opens. The title of the new command prompt includes `running as userUpn@trusteddomain.com`.

-1. Use `whoami /fqdn` in the new command prompt to view the distinguished name of the authenticated user from the on-premises Active Directory.

-<a name='access-resources-in-azure-ad-ds-as-an-on-premises-user'></a>

-### Access resources in Domain Services as an on-premises user

-Using the Windows Server VM joined to the managed domain, you can test the scenario where users can access resources hosted in the forest when they authenticate from computers in the on-premises domain with users from the on-premises domain. The following examples show you how to create and test various common scenarios.

-#### Enable file and printer sharing

-1. Connect to the Windows Server VM joined to the managed domain using Remote Desktop and your managed domain administrator credentials. If you get a Network Level Authentication (NLA) error, check the user account you used is not a domain user account.

- > [!TIP]

- > To securely connect to your VMs joined to Microsoft Entra Domain Services, you can use the [Azure Bastion Host Service](/azure/bastion/bastion-overview) in supported Azure regions.

-1. Open **Windows Settings**, then search for and select **Network and Sharing Center**.

-1. Choose the option for **Change advanced sharing** settings.

-1. Under the **Domain Profile**, select **Turn on file and printer sharing** and then **Save changes**.

-1. Close **Network and Sharing Center**.

-#### Create a security group and add members

-1. Open **Active Directory Users and Computers**.

-1. Right-select the domain name, choose **New**, and then select **Organizational Unit**.

-1. In the name box, type *LocalObjects*, then select **OK**.

-1. Select and right-click **LocalObjects** in the navigation pane. Select **New** and then **Group**.

-1. Type *FileServerAccess* in the **Group name** box. For the **Group Scope**, select **Domain local**, then choose **OK**.

-1. In the content pane, double-click **FileServerAccess**. Select **Members**, choose to **Add**, then select **Locations**.

-1. Select your on-premises Active Directory from the **Location** view, then choose **OK**.

-1. Type *Domain Users* in the **Enter the object names to select** box. Select **Check Names**, provide credentials for the on-premises Active Directory, then select **OK**.

- > [!NOTE]

- > You must provide credentials because the trust relationship is only one way. This means users from the managed domain can't access resources or search for users or groups in the trusted (on-premises) domain.

-1. The **Domain Users** group from your on-premises Active Directory should be a member of the **FileServerAccess** group. Select **OK** to save the group and close the window.

-#### Create a file share for cross-forest access

-1. On the Windows Server VM joined to the managed domain, create a folder and provide name such as *CrossForestShare*.

-1. Right-select the folder and choose **Properties**.

-1. Select the **Security** tab, then choose **Edit**.

-1. In the *Permissions for CrossForestShare* dialog box, select **Add**.

-1. Type *FileServerAccess* in **Enter the object names to select**, then select **OK**.

-1. Select *FileServerAccess* from the **Groups or user names** list. In the **Permissions for FileServerAccess** list, choose *Allow* for the **Modify** and **Write** permissions, then select **OK**.

-1. Select the **Sharing** tab, then choose **Advanced Sharing…**

-1. Choose **Share this folder**, then enter a memorable name for the file share in **Share name** such as *CrossForestShare*.

-1. Select **Permissions**. In the **Permissions for Everyone** list, choose **Allow** for the **Change** permission.

-1. Select **OK** two times and then **Close**.

-#### Validate cross-forest authentication to a resource

-1. Sign in a Windows computer joined to your on-premises Active Directory using a user account from your on-premises Active Directory.

-1. Using **Windows Explorer**, connect to the share you created using the fully qualified host name and the share such as `\\fs1.aaddscontoso.com\CrossforestShare`.

-1. To validate the write permission, right-select in the folder, choose **New**, then select **Text Document**. Use the default name **New Text Document**.

- If the write permissions are set correctly, a new text document is created. The following steps will then open, edit, and delete the file as appropriate.

-1. To validate the read permission, open **New Text Document**.

-1. To validate the modify permission, add text to the file and close **Notepad**. When prompted to save changes, choose **Save**.

-1. To validate the delete permission, right-select **New Text Document** and choose **Delete**. Choose **Yes** to confirm file deletion.

-## Update or remove outbound forest trust

-If you need to update an existing one-way outbound forest from the managed domain, you can use the `Get-AaddsResourceForestTrusts` and `Set-AaddsResourceForestTrust` scripts. These scripts help in scenarios where you want to update the forest trust friendly name or trust password. To remove a one-way outbound trust from the managed domain, you can use the `Remove-AaddsResourceForestTrust` script. You must manually remove the one-way inbound forest trust in the associated on-premises AD DS forest.

-### Update a forest trust

-In normal operation, the managed domain and on-premises forest negotiate a regular password update process between themselves. This is part of the normal AD DS trust relationship security process. You don't need to manually rotate the trust password unless the trust relationship has experienced an issue and you want to manually reset to a known password. For more information, see [trusted domain object password changes](concepts-forest-trust.md#tdo-password-changes).

-The following example steps show you how to update an existing trust relationship if you need to manually reset the outbound trust password:

-1. Install the `Get-AaddsResourceForestTrusts` and `Set-AaddsResourceForestTrust` scripts from the [PowerShell Gallery][powershell-gallery] using the [Install-Script][Install-Script] cmdlet:

- ```powershell

- Install-Script -Name Get-AaddsResourceForestTrusts,Set-AaddsResourceForestTrust

- ```

-1. Before you can update an existing trust, first get the trust resource using the `Get-AaddsResourceForestTrusts` script. In the following example, the existing trust is assigned to an object named *existingTrust*. Specify your own managed domain forest name and on-premises forest name to update:

- ```powershell

- $existingTrust = Get-AaddsResourceForestTrust `

- -ManagedDomainFqdn "aaddscontoso.com" `

- -TrustFqdn "onprem.contoso.com" `

- -TrustFriendlyName "myAzureADDSTrust"

- ```

-1. To update the existing trust password, use the `Set-AaddsResourceForestTrust` script. Specify the existing trust object from the previous step, then a new trust relationship password. No password complexity is enforced by PowerShell, so make sure you to generate and use a secure password for your environment.

- ```powershell

- Set-AaddsResourceForestTrust `

- -Trust $existingTrust `

- -TrustPassword <newComplexPassword>

- ```

-### Delete a forest trust

-If you no longer need the one-way outbound forest trust from the managed domain to an on-premises AD DS forest, you can remove it. Make sure that no applications or services need to authenticate against the on-premises AD DS forest before you remove the trust. You must manually remove the one-way inbound trust in the on-premises AD DS forest, too.

-1. Install the `Remove-AaddsResourceForestTrust` script from the [PowerShell Gallery][powershell-gallery] using the [Install-Script][Install-Script] cmdlet:

- ```powershell

- Install-Script -Name Remove-AaddsResourceForestTrust

- ```

-1. Now remove the forest trust using the `Remove-AaddsResourceForestTrust` script. In the following example, the trust named *myAzureADDSTrust* between the managed domain forest named *aaddscontoso.com* and on-premises forest *onprem.contoso.com* is removed. Specify your own managed domain forest name and on-premises forest name to remove:

- ```powershell

- Remove-AaddsResourceForestTrust `

- -ManagedDomainFqdn "aaddscontoso.com" `

- -TrustFqdn "onprem.contoso.com" `

- -TrustFriendlyName "myAzureADDSTrust"

- ```

-To remove the one-way inbound trust from the on-premises AD DS forest, connect to a management computer with access to the on-premises AD DS forest and complete the following steps:

-1. Select **Start | Administrative Tools | Active Directory Domains and Trusts**.

-1. Right-select domain, such as *onprem.contoso.com*, select **Properties**.

-1. Choose **Trusts** tab, then select the existing incoming trust from your managed domain forest.

-1. Select **Remove**, then confirm that you wish to remove the incoming trust.

-## Next steps

-In this article, you learned how to:

-> [!div class="checklist"]

-> * Create a managed domain using Azure PowerShell

-> * Create a one-way outbound forest trust in the managed domain using Azure PowerShell

-> * Configure DNS in an on-premises AD DS environment to support the managed domain connectivity

-> * Create a one-way inbound forest trust in an on-premises AD DS environment

-> * Test and validate the trust relationship for authentication and resource access

-For more conceptual information about forest types in Domain Services, see [How do forest trusts work in Domain Services?][concepts-trust]

-<!-- INTERNAL LINKS -->

-[concepts-trust]: concepts-forest-trust.md

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance-advanced]: tutorial-create-instance-advanced.md

-[Connect-AzAccount]: /powershell/module/az.accounts/connect-azaccount

-[Connect-AzureAD]: /powershell/module/azuread/connect-azuread

-[New-AzResourceGroup]: /powershell/module/az.resources/new-azresourcegroup

-[network-peering]: /azure/virtual-network/virtual-network-peering-overview

-[New-AzureADServicePrincipal]: /powershell/module/azuread/new-azureadserviceprincipal

-[Get-AzureRMSubscription]: /powershell/module/azurerm.profile/get-azurermsubscription

-[Install-Script]: /powershell/module/powershellget/install-script

-<!-- EXTERNAL LINKS -->

-[powershell-gallery]: https://www.powershellgallery.com/

-description: Learn how to create a group managed service account (gMSA) for use with Microsoft Entra Domain Services managed domains

-# Create a group managed service account (gMSA) in Microsoft Entra Domain Services

-Applications and services often need an identity to authenticate themselves with other resources. For example, a web service may need to authenticate with a database service. If an application or service has multiple instances, such as a web server farm, manually creating and configuring the identities for those resources gets time consuming.

-Instead, a group managed service account (gMSA) can be created in the Microsoft Entra Domain Services managed domain. The Windows OS automatically manages the credentials for a gMSA, which simplifies the management of large groups of resources.

-This article shows you how to create a gMSA in a managed domain using Azure PowerShell.

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server management VM that is joined to the Domain Services managed domain.

- * If needed, complete the tutorial to [create a management VM][tutorial-create-management-vm].

-## Managed service accounts overview

-A standalone managed service account (sMSA) is a domain account whose password is automatically managed. This approach simplifies service principal name (SPN) management, and enables delegated management to other administrators. You don't need to manually create and rotate credentials for the account.

-A group managed service account (gMSA) provides the same management simplification, but for multiple servers in the domain. A gMSA lets all instances of a service hosted on a server farm use the same service principal for mutual authentication protocols to work. When a gMSA is used as service principal, the Windows operating system again manages the account's password instead of relying on the administrator.

-For more information, see [group managed service accounts (gMSA) overview][gmsa-overview].

-<a name='using-service-accounts-in-azure-ad-ds'></a>

-## Using service accounts in Domain Services

-As managed domains are locked down and managed by Microsoft, there are some considerations when using service accounts:

-* Create service accounts in custom organizational units (OU) on the managed domain.

- * You can't create a service account in the built-in *AADDC Users* or *AADDC Computers* OUs.

- * Instead, [create a custom OU][create-custom-ou] in the managed domain and then create service accounts in that custom OU.

-* The Key Distribution Services (KDS) root key is pre-created.

- * The KDS root key is used to generate and retrieve passwords for gMSAs. In Domain Services, the KDS root is created for you.

- * You don't have privileges to create another, or view the default, KDS root key.

-## Create a gMSA

-First, create a custom OU using the [New-ADOrganizationalUnit][New-AdOrganizationalUnit] cmdlet. For more information on creating and managing custom OUs, see [Custom OUs in Domain Services][create-custom-ou].

-> [!TIP]

-> To complete these steps to create a gMSA, [use your management VM][tutorial-create-management-vm]. This management VM should already have the required AD PowerShell cmdlets and connection to the managed domain.

-The following example creates a custom OU named *myNewOU* in the managed domain named *aaddscontoso.com*. Use your own OU and managed domain name:

-```powershell

-New-ADOrganizationalUnit -Name "myNewOU" -Path "DC=aaddscontoso,DC=COM"

-```

-Now create a gMSA using the [New-ADServiceAccount][New-ADServiceAccount] cmdlet. The following example parameters are defined:

-* **-Name** is set to *WebFarmSvc*

-* **-Path** parameter specifies the custom OU for the gMSA created in the previous step.

-* DNS entries and service principal names are set for *WebFarmSvc.aaddscontoso.com*

-* Principals in *AADDSCONTOSO-SERVER$* are allowed to retrieve the password and use the identity.

-Specify your own names and domain names.

-```powershell

-New-ADServiceAccount -Name WebFarmSvc `

- -DNSHostName WebFarmSvc.aaddscontoso.com `

- -Path "OU=MYNEWOU,DC=aaddscontoso,DC=com" `

- -KerberosEncryptionType AES128, AES256 `

- -ManagedPasswordIntervalInDays 30 `

- -ServicePrincipalNames http/WebFarmSvc.aaddscontoso.com/aaddscontoso.com, `

- http/WebFarmSvc.aaddscontoso.com/aaddscontoso, `

- http/WebFarmSvc/aaddscontoso.com, `

- http/WebFarmSvc/aaddscontoso `

- -PrincipalsAllowedToRetrieveManagedPassword AADDSCONTOSO-SERVER$

-```

-Applications and services can now be configured to use the gMSA as needed.

-## Next steps

-For more information about gMSAs, see [Getting started with group managed service accounts][gmsa-start].

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[tutorial-create-management-vm]: tutorial-create-management-vm.md

-[create-custom-ou]: create-ou.md

-<!-- EXTERNAL LINKS -->

-[New-ADOrganizationalUnit]: /powershell/module/activedirectory/new-adorganizationalunit

-[New-ADServiceAccount]: /powershell/module/activedirectory/new-adserviceaccount

-[gmsa-overview]: /windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview

-[gmsa-start]: /windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts

-description: Learn how to create and manage a custom Organizational Unit (OU) in a Microsoft Entra Domain Services managed domain.

-# Create an Organizational Unit (OU) in a Microsoft Entra Domain Services managed domain

-Organizational units (OUs) in an Active Directory Domain Services (AD DS) managed domain let you logically group objects such as user accounts, service accounts, or computer accounts. You can then assign administrators to specific OUs, and apply group policy to enforce targeted configuration settings.

-Domain Services managed domains include the following two built-in OUs:

-* *AADDC Computers* - contains computer objects for all computers that are joined to the managed domain.

-* *AADDC Users* - includes users and groups synchronized in from the Microsoft Entra tenant.

-As you create and run workloads that use Domain Services, you may need to create service accounts for applications to authenticate themselves. To organize these service accounts, you often create a custom OU in the managed domain and then create service accounts within that OU.

-In a hybrid environment, OUs created in an on-premises AD DS environment aren't synchronized to the managed domain. Managed domains use a flat OU structure. 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 there.

-This article shows you how to create an OU in your managed domain.

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server management VM that is joined to the Domain Services managed domain.

- * If needed, complete the tutorial to [create a management VM][tutorial-create-management-vm].

-* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

-## Custom OU considerations and limitations

-When you create custom OUs in a managed domain, you gain additional management flexibility for user management and applying group policy. Compared to an on-premises AD DS environment, there are some limitations and considerations when creating and managing a custom OU structure in a managed domain:

-* To create custom OUs, users must be a member of the *AAD DC Administrators* group.

-* A user that creates a custom OU is granted administrative privileges (full control) over that OU and is the resource owner.

- * By default, the *AAD DC Administrators* group also has full control of the custom OU.

-* A default OU for *AADDC Users* is created that contains all the synchronized user accounts from your Microsoft Entra tenant.

- * You can't move users or groups from the *AADDC Users* OU to custom OUs that you create. Only user accounts or resources created in the managed domain can be moved into custom OUs.

-* User accounts, groups, service accounts, and computer objects that you create under custom OUs aren't available in your Microsoft Entra tenant.

- * These objects don't show up using the Microsoft Graph API or in the Microsoft Entra UI; they're only available in your managed domain.

-## Create a custom OU

-To create a custom OU, you use the Active Directory Administrative Tools from a domain-joined VM. The Active Directory Administrative Center lets you view, edit, and create resources in a managed domain, including OUs.

-> [!NOTE]

-> To create a custom OU in a managed domain, you must be signed in to a user account that's a member of the *AAD DC Administrators* group.

-1. Sign in to your management VM. For steps on how to connect using the Microsoft Entra admin center, see [Connect to a Windows Server VM][connect-windows-server-vm].

-1. From the Start screen, select **Administrative Tools**. A list of available management tools is shown that were installed in the tutorial to [create a management VM][tutorial-create-management-vm].

-1. To create and manage OUs, select **Active Directory Administrative Center** from the list of administrative tools.

-1. In the left pane, choose your managed domain, such as *aaddscontoso.com*. A list of existing OUs and resources is shown:

- 

-1. The **Tasks** pane is shown on the right side of the Active Directory Administrative Center. Under the domain, such as *aaddscontoso.com*, select **New > Organizational Unit**.

- 

-1. In the **Create Organizational Unit** dialog, specify a **Name** for the new OU, such as *MyCustomOu*. Provide a short description for the OU, such as *Custom OU for service accounts*. If desired, you can also set the **Managed By** field for the OU. To create the custom OU, select **OK**.

- 

-1. Back in the Active Directory Administrative Center, the custom OU is now listed and is available for use:

- 

-## Next steps

-For more information on using the administrative tools or creating and using service accounts, see the following articles:

-* [Active Directory Administrative Center: Getting Started](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd560651(v=ws.10))

-* [Service Accounts Step-by-Step Guide](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd548356(v=ws.10))

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[tutorial-create-management-vm]: tutorial-create-management-vm.md

-[connect-windows-server-vm]: join-windows-vm.md#connect-to-the-windows-server-vm

-description: Learn how to enable and manage Microsoft Entra Domain Services managed domains for Azure Cloud Solution Providers

-# Microsoft Entra Domain Services deployment and management for Azure Cloud Solution Providers

-Azure Cloud Solution Providers (CSP) is a program for Microsoft Partners and provides a license channel for various Microsoft cloud services. Azure CSP enables partners to manage sales, own the billing relationship, provide technical and billing support, and be the customer's single point of contact. In addition, Azure CSP provides a full set of tools, including a self-service portal and accompanying APIs. These tools enable CSP partners to easily provision and manage Azure resources, and provide billing for customers and their subscriptions.

-The [Partner Center portal](/partner-center/azure-plan-lp) is the entry point for all Azure CSP partners, and provides rich customer management capabilities, automated processing, and more. Azure CSP partners can use Partner Center capabilities by using a web-based UI or by using PowerShell and various API calls.

-The following diagram illustrates how the CSP model works at a high level. Here, Contoso has a Microsoft Entra tenant. They have a partnership with a CSP, who deploys and manages resources in their Azure CSP subscription. Contoso may also have regular (direct) Azure subscriptions, which are billed directly to Contoso.

-

-The CSP partner's tenant has three special agent groups - *Admin* agents, *Helpdesk* agents, and *Sales* agents.

-The *Admin* agents group is assigned to the tenant administrator role in Contoso's Microsoft Entra tenant. As a result, a user belonging to the CSP partner's admin agents group has tenant admin privileges in Contoso's Microsoft Entra tenant.

-When the CSP partner provisions an Azure CSP subscription for Contoso, their admin agents group is assigned to the owner role for that subscription. As a result, the CSP partner's admin agents have the required privileges to provision Azure resources such as virtual machines, virtual networks, and Microsoft Entra Domain Services on behalf of Contoso.

-For more information, see the [Azure CSP overview](/partner-center/azure-plan-lp)

-<a name='benefits-of-using-azure-ad-ds-in-an-azure-csp-subscription'></a>

-## Benefits of using Domain Services in an Azure CSP subscription

-Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory Domain Services. Over the decades, many applications have been built to work against AD using these capabilities. Many independent software vendors (ISVs) have built and deployed applications at their customers' premises. These applications are hard to support since you often require access to the different environments where the applications are deployed. With Azure CSP subscriptions, you have a simpler alternative with the scale and flexibility of Azure.

-Domain Services supports Azure CSP subscriptions. You can deploy your application in an Azure CSP subscription tied to your customer's Microsoft Entra tenant. As a result, your employees (support staff) can manage, administer, and service the VMs on which your application is deployed using your organization's corporate credentials.

-You can also deploy a Domain Services managed domain in your customer's Microsoft Entra tenant. Your application is then connected to your customer's managed domain. Capabilities within your application that rely on Kerberos / NTLM, LDAP, or the [System.DirectoryServices API](/dotnet/api/system.directoryservices) work seamlessly against your customer's domain. End customers benefit from consuming your application as a service, without needing to worry about maintaining the infrastructure the application is deployed on.

-All billing for Azure resources you consume in that subscription, including Domain Services, is charged back to you. You maintain full control over the relationship with the customer when it comes to sales, billing, technical support etc. With the flexibility of the Azure CSP platform, a small team of support agents can service many such customers who have instances of your application deployed.

-<a name='csp-deployment-models-for-azure-ad-ds'></a>

-## CSP deployment models for Domain Services

-There are two ways in which you can use Domain Services with an Azure CSP subscription. Pick the right one based on the security and simplicity considerations your customers have.

-### Direct deployment model

-In this deployment model, Domain Services is enabled within a virtual network that belongs to the Azure CSP subscription. The CSP partner's admin agents have the following privileges:

-* *Global administrator* privileges in the customer's Microsoft Entra tenant.

-* *Subscription owner* privileges on the Azure CSP subscription.

-

-In this deployment model, the CSP provider's admin agents can administer identities for the customer. These admin agents can perform tasks like provision new users or groups, or add applications within the customer's Microsoft Entra tenant.

-This deployment model may be suited for smaller organizations that don't have a dedicated identity administrator or prefer for the CSP partner to administer identities on their behalf.

-### Peered deployment model

-In this deployment model, Domain Services is enabled within a virtual network belonging to the customer - a direct Azure subscription paid for by the customer. The CSP partner can deploy applications within a virtual network belonging to the customer's CSP subscription. The virtual networks can then be connected using Azure virtual network peering.

-With this deployment, the workloads or applications deployed by the CSP partner in the Azure CSP subscription can connect to the customer's managed domain provisioned in the customer's direct Azure subscription.

-

-This deployment model provides a separation of privileges and enables the CSP partner's helpdesk agents to administer the Azure subscription and deploy and manage resources within it. However, the CSP partner's helpdesk agents don't need to have global administrator privileges on the customer's Microsoft Entra directory. The customer's identity administrators can continue to manage identities for their organization.

-This deployment model may be suited to scenarios where an ISV provides a hosted version of their on-premises application, which also needs to connect to the customer's Microsoft Entra ID.

-<a name='administer-azure-ad-ds-in-csp-subscriptions'></a>

-## Administer Domain Services in CSP subscriptions

-The following important considerations apply when administering a managed domain in an Azure CSP subscription:

-* **CSP admin agents can provision a managed domain using their credentials:** Domain Services supports Azure CSP subscriptions. Users belonging to a CSP partner's admin agents group can provision a new managed domain.

-* **CSPs can script creation of new managed domains for their customers using PowerShell:** See [how to enable Domain Services using PowerShell](powershell-create-instance.md) for details.

-* **CSP admin agents can't perform ongoing management tasks on the managed domain using their credentials:** CSP admin users can't perform routine management tasks within the managed domain using their credentials. These users are external to the customer's Microsoft Entra tenant and their credentials aren't available within the customer's Microsoft Entra tenant. Domain Services doesn't have access to the Kerberos and NTLM password hashes for these users, so users can't be authenticated on managed domains.

- > [!WARNING]

- > You must create a user account within the customer's directory to perform ongoing administration tasks on the managed domain.

- >

- > You can't sign in to the managed domain using a CSP admin user's credentials. Use the credentials of a user account belonging to the customer's Microsoft Entra tenant to do so. You need these credentials for tasks such as joining VMs to the managed domain, administering DNS, or administering Group Policy.

-* **The user account created for ongoing administration must be added to the *AAD DC Administrators* group:** The *AAD DC Administrators* group has privileges to perform certain delegated administration tasks on the managed domain. These tasks include configuring DNS, creating organizational units, and administering group policy.

-

- For a CSP partner to perform these tasks on a managed domain, a user account must be created within the customer's Microsoft Entra tenant. The credentials for this account must be shared with the CSP partner's admin agents. Also, this user account must be added to the *AAD DC Administrators* group to enable configuration tasks on the managed domain to be performed using this user account.

-## Next steps

-To get started, [enroll in the Azure CSP program](/partner-center/enrolling-in-the-csp-program). You can then enable Microsoft Entra Domain Services using the [Microsoft Entra admin center](tutorial-create-instance.md) or [Azure PowerShell](powershell-create-instance.md).

-description: Learn how to disable, or delete, a Microsoft Entra Domain Services managed domain

-# Delete a Microsoft Entra Domain Services managed domain

-If you no longer need a Microsoft Entra Domain Services managed domain, you can delete it. There's no way to turn off or temporarily disable a Domain Services managed domain. Deleting the managed domain doesn't delete or have any other impact on the Microsoft Entra tenant.

-This article shows you how to use the Microsoft Entra admin center to delete a managed domain.

-> [!WARNING]

-> **Deletion is permanent and can't be reversed.**

->

-> When you delete a managed domain, the following steps occur:

-> * Domain controllers for the managed domain are deprovisioned and removed from the virtual network.

-> * Data on the managed domain is deleted permanently. This data includes custom OUs, GPOs, custom DNS records, service principals, GMSAs, etc. that you created.

-> * Machines joined to the managed domain lose their trust relationship with the domain and need to be unjoined from the domain.

-> * You can't sign in to these machines using corporate AD credentials. Instead, you must use the local administrator credentials for the machine.

-## Delete the managed domain

-To delete a managed domain, complete the following steps:

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as a [Global Administrator](/azure/active-directory/roles/permissions-reference#global-administrator).

-1. Search for and select **Microsoft Entra Domain Services**.

-1. Select the name of your managed domain, such as *aaddscontoso.com*.

-1. On the **Overview** page, select **Delete**. To confirm the deletion, type the domain name of the managed domain again, then select **Delete**.

-It can take 15-20 minutes or more to delete the managed domain.

-## Next steps

-Consider [sharing feedback][feedback] for the features that you would like to see in Domain Services.

-If you want to get started with Domain Services again, see [Create and configure a Microsoft Entra Domain Services managed domain][create-instance].

-<!-- INTERNAL LINKS -->

-[feedback]: https://feedback.azure.com/d365community/forum/22920db1-ad25-ec11-b6e6-000d3a4f0789?c=5d63b5b7-ae25-ec11-b6e6-000d3a4f0789

-[create-instance]: tutorial-create-instance.md

-description: Learn how to provide secure access to internal applications for remote workers by deploying and configuring Microsoft Entra application proxy in a Microsoft Entra Domain Services managed domain

-# Deploy Microsoft Entra application proxy for secure access to internal applications in a Microsoft Entra Domain Services managed domain

-With Microsoft Entra Domain Services, you can lift-and-shift legacy applications running on-premises into Azure. Microsoft Entra application proxy then helps you support remote workers by securely publishing those internal applications part of a Domain Services managed domain so they can be accessed over the internet.

-If you're new to the Microsoft Entra application proxy and want to learn more, see [How to provide secure remote access to internal applications](/azure/active-directory/app-proxy/application-proxy).

-This article shows you how to create and configure a Microsoft Entra application proxy connector to provide secure access to applications in a managed domain.

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

- * An **Microsoft Entra ID P1 or P2 license** is required to use the Microsoft Entra application proxy.

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-## Create a domain-joined Windows VM

-To route traffic to applications running in your environment, you install the Microsoft Entra application proxy connector component. This Microsoft Entra application proxy connector must be installed on a Windows Server virtual machine (VM) that's joined to the managed domain. For some applications, you can deploy multiple servers that each have the connector installed. This deployment option gives you greater availability and helps handle heavier authentication loads.

-The VM that runs the Microsoft Entra application proxy connector must be on the same, or a peered, virtual network as your managed domain. The VMs that then host the applications you publish using the Application Proxy must also be deployed on the same Azure virtual network.

-To create a VM for the Microsoft Entra application proxy connector, complete the following steps:

-1. [Create a custom OU](create-ou.md). You can delegate permissions to manage this custom OU to users within the managed domain. The VMs for Microsoft Entra application proxy and that run your applications must be a part of the custom OU, not the default *Microsoft Entra DC Computers* OU.

-1. [Domain-join the virtual machines][create-join-windows-vm], both the one that runs the Microsoft Entra application proxy connector, and the ones that run your applications, to the managed domain. Create these computer accounts in the custom OU from the previous step.

-<a name='download-the-azure-ad-application-proxy-connector'></a>

-## Download the Microsoft Entra application proxy connector

-Perform the following steps to download the Microsoft Entra application proxy connector. The setup file you download is copied to your App Proxy VM in the next section.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as a [Global Administrator](/azure/active-directory/roles/permissions-reference#global-administrator).

-1. Search for and select **Enterprise applications**.

-1. Select **Application proxy** from the menu on the left-hand side. To create your first connector and enable App Proxy, select the link to **download a connector**.

-1. On the download page, accept the license terms and privacy agreement, then select **Accept terms & Download**.

- 

-<a name='install-and-register-the-azure-ad-application-proxy-connector'></a>

-## Install and register the Microsoft Entra application proxy connector

-With a VM ready to be used as the Microsoft Entra application proxy connector, now copy and run the setup file downloaded from the Microsoft Entra admin center.

-1. Copy the Microsoft Entra application proxy connector setup file to your VM.

-1. Run the setup file, such as *AADApplicationProxyConnectorInstaller.exe*. Accept the software license terms.

-1. During the install, you're prompted to register the connector with the Application Proxy in your Microsoft Entra directory.

- * Provide the credentials for a global administrator in your Microsoft Entra directory. The Microsoft Entra Global Administrator credentials may be different from your Azure credentials in the portal

- > [!NOTE]

- > The global administrator account used to register the connector must belong to the same directory where you enable the Application Proxy service.

- >

- > For example, if the Microsoft Entra domain is *contoso.com*, the global administrator should be `admin@contoso.com` or another valid alias on that domain.

- * If Internet Explorer Enhanced Security Configuration is turned on for the VM where you install the connector, the registration screen might be blocked. To allow access, follow the instructions in the error message, or turn off Internet Explorer Enhanced Security during the install process.

- * If connector registration fails, see [Troubleshoot Application Proxy](/azure/active-directory/app-proxy/application-proxy-troubleshoot).

-1. At the end of the setup, a note is shown for environments with an outbound proxy. To configure the Microsoft Entra application proxy connector to work through the outbound proxy, run the provided script, such as `C:\Program Files\Microsoft AAD App Proxy connector\ConfigureOutBoundProxy.ps1`.

-1. On the Application proxy page in the Microsoft Entra admin center, the new connector is listed with a status of *Active*, as shown in the following example:

- 

-> [!NOTE]

-> To provide high availability for applications authenticating through the Microsoft Entra application proxy, you can install connectors on multiple VMs. Repeat the same steps listed in the previous section to install the connector on other servers joined to the managed domain.

-## Enable resource-based Kerberos constrained delegation

-If you want to use single sign-on to your applications using integrated Windows authentication (IWA), grant the Microsoft Entra application proxy connectors permission to impersonate users and send and receive tokens on their behalf. To grant these permissions, you configure Kerberos constrained delegation (KCD) for the connector to access resources on the managed domain. As you don't have domain administrator privileges in a managed domain, traditional account-level KCD cannot be configured on a managed domain. Instead, use resource-based KCD.

-For more information, see [Configure Kerberos constrained delegation (KCD) in Microsoft Entra Domain Services](deploy-kcd.md).

-> [!NOTE]

-> You must be signed in to a user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant to run the following PowerShell cmdlets.

->

-> The computer accounts for your App Proxy connector VM and application VMs must be in a custom OU where you have permissions to configure resource-based KCD. You can't configure resource-based KCD for a computer account in the built-in *Microsoft Entra DC Computers* container.

-Use the [Get-ADComputer][Get-ADComputer] to retrieve the settings for the computer on which the Microsoft Entra application proxy connector is installed. From your domain-joined management VM and logged in as user account that's a member of the *Microsoft Entra DC administrators* group, run the following cmdlets.

-The following example gets information about the computer account named *appproxy.aaddscontoso.com*. Provide your own computer name for the Microsoft Entra application proxy VM configured in the previous steps.

-```powershell

-$ImpersonatingAccount = Get-ADComputer -Identity appproxy.aaddscontoso.com

-```

-For each application server that runs the apps behind Microsoft Entra application proxy use the [Set-ADComputer][Set-ADComputer] PowerShell cmdlet to configure resource-based KCD. In the following example, the Microsoft Entra application proxy connector is granted permissions to use the *appserver.aaddscontoso.com* computer:

-```powershell

-Set-ADComputer appserver.aaddscontoso.com -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

-```

-If you deploy multiple Microsoft Entra application proxy connectors, you must configure resource-based KCD for each connector instance.

-## Next steps

-With the Microsoft Entra application proxy integrated with Domain Services, publish applications for users to access. For more information, see [publish applications using Microsoft Entra application proxy](/azure/active-directory/app-proxy/application-proxy-add-on-premises-application).

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[create-join-windows-vm]: join-windows-vm.md

-[azure-bastion]: /azure/bastion/tutorial-create-host-portal

-[Get-ADComputer]: /powershell/module/activedirectory/get-adcomputer

-[Set-ADComputer]: /powershell/module/activedirectory/set-adcomputer

-description: Learn how to enable resource-based Kerberos constrained delegation (KCD) in a Microsoft Entra Domain Services managed domain.

-# Configure Kerberos constrained delegation (KCD) in Microsoft Entra Domain Services

-As you run applications, there may be a need for those applications to access resources in the context of a different user. Active Directory Domain Services (AD DS) supports a mechanism called *Kerberos delegation* that enables this use-case. Kerberos *constrained* delegation (KCD) then builds on this mechanism to define specific resources that can be accessed in the context of the user.

-Microsoft Entra Domain Services managed domains are more securely locked down than traditional on-premises AD DS environments, so use a more secure *resource-based* KCD.

-This article shows you how to configure resource-based Kerberos constrained delegation in a Domain Services managed domain.

-## Prerequisites

-To complete this article, you need the following resources:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server management VM that is joined to the Domain Services managed domain.

- * If needed, complete the tutorial to [create a Windows Server VM and join it to a managed domain][create-join-windows-vm] then [install the AD DS management tools][tutorial-create-management-vm].

-* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

-## Kerberos constrained delegation overview

-Kerberos delegation lets one account impersonate another account to access resources. For example, a web application that accesses a back-end web component can impersonate itself as a different user account when it makes the back-end connection. Kerberos delegation is insecure as it doesn't limit what resources the impersonating account can access.

-Kerberos *constrained* delegation (KCD) restricts the services or resources that a specified server or application can connect when impersonating another identity. Traditional KCD requires domain administrator privileges to configure a domain account for a service, and it restricts the account to run on a single domain.

-Traditional KCD also has a few issues. For example, in earlier operating systems, the service administrator had no useful way to know which front-end services delegated to the resource services they owned. Any front-end service that could delegate to a resource service was a potential attack point. If a server that hosted a front-end service configured to delegate to resource services was compromised, the resource services could also be compromised.

-In a managed domain, you don't have domain administrator privileges. As a result, traditional account-based KCD can't be configured in a managed domain. Resource-based KCD can instead be used, which is also more secure.

-### Resource-based KCD

-Windows Server 2012 and later gives service administrators the ability to configure constrained delegation for their service. This model is known as resource-based KCD. With this approach, the back-end service administrator can allow or deny specific front-end services from using KCD.

-Resource-based KCD is configured using PowerShell. You use the [Set-ADComputer][Set-ADComputer] or [Set-ADUser][Set-ADUser] cmdlets, depending on whether the impersonating account is a computer account or a user account / service account.

-## Configure resource-based KCD for a computer account

-In this scenario, let's assume you have a web app that runs on the computer named *contoso-webapp.aaddscontoso.com*.

-The web app needs to access a web API that runs on the computer named *contoso-api.aaddscontoso.com* in the context of domain users.

-Complete the following steps to configure this scenario:

-1. [Create a custom OU](create-ou.md). You can delegate permissions to manage this custom OU to users within the managed domain.

-1. [Domain-join the virtual machines][create-join-windows-vm], both the one that runs the web app, and the one that runs the web API, to the managed domain. Create these computer accounts in the custom OU from the previous step.

- > [!NOTE]

- > The computer accounts for the web app and the web API must be in a custom OU where you have permissions to configure resource-based KCD. You can't configure resource-based KCD for a computer account in the built-in *Microsoft Entra DC Computers* container.

-1. Finally, configure resource-based KCD using the [Set-ADComputer][Set-ADComputer] PowerShell cmdlet.

- From your domain-joined management VM and logged in as user account that's a member of the *Microsoft Entra DC administrators* group, run the following cmdlets. Provide your own computer names as needed:

-

- ```powershell

- $ImpersonatingAccount = Get-ADComputer -Identity contoso-webapp.aaddscontoso.com

- Set-ADComputer contoso-api.aaddscontoso.com -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

- ```

-## Configure resource-based KCD for a user account

-In this scenario, let's assume you have a web app that runs as a service account named *appsvc*. The web app needs to access a web API that runs as a service account named *backendsvc* in the context of domain users. Complete the following steps to configure this scenario:

-1. [Create a custom OU](create-ou.md). You can delegate permissions to manage this custom OU to users within the managed domain.

-1. [Domain-join the virtual machines][create-join-windows-vm] that run the backend web API/resource to the managed domain. Create its computer account within the custom OU.

-1. Create the service account (for example, *appsvc*) used to run the web app within the custom OU.

- > [!NOTE]

- > Again, the computer account for the web API VM, and the service account for the web app, must be in a custom OU where you have permissions to configure resource-based KCD. You can't configure resource-based KCD for accounts in the built-in *Microsoft Entra DC Computers* or *Microsoft Entra DC Users* containers. This also means that you can't use user accounts synchronized from Microsoft Entra ID to set up resource-based KCD. You must create and use service accounts specifically created in Domain Services.

-1. Finally, configure resource-based KCD using the [Set-ADUser][Set-ADUser] PowerShell cmdlet.

- From your domain-joined management VM and logged in as user account that's a member of the *Microsoft Entra DC administrators* group, run the following cmdlets. Provide your own service names as needed:

- ```powershell

- $ImpersonatingAccount = Get-ADUser -Identity appsvc

- Set-ADUser backendsvc -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

- ```

-## Next steps

-To learn more about how delegation works in Active Directory Domain Services, see [Kerberos Constrained Delegation Overview][kcd-technet].

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[create-join-windows-vm]: join-windows-vm.md

-[tutorial-create-management-vm]: tutorial-create-management-vm.md

-[Set-ADComputer]: /powershell/module/activedirectory/set-adcomputer

-[Set-ADUser]: /powershell/module/activedirectory/set-aduser

-<!-- EXTERNAL LINKS -->

-[kcd-technet]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj553400(v=ws.11)

-description: Learn how to configure a Microsoft Entra Domain Services managed domain to support profile synchronization for SharePoint Server

-# Configure Microsoft Entra Domain Services to support user profile synchronization for SharePoint Server

-SharePoint Server includes a service to synchronize user profiles. This feature allows user profiles to be stored in a central location and accessible across multiple SharePoint sites and farms. To configure the SharePoint Server user profile service, the appropriate permissions must be granted in a Microsoft Entra Domain Services managed domain. For more information, see [user profile synchronization in SharePoint Server](/SharePoint/administration/user-profile-service-administration).

-This article shows you how to configure Domain Services to allow the SharePoint Server user profile sync service.

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server management VM that is joined to the Domain Services managed domain.

- * If needed, complete the tutorial to [create a management VM][tutorial-create-management-vm].

-* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

-* The SharePoint service account name for the user profile synchronization service. For more information about the *Profile Synchronization account*, see [Plan for administrative and service accounts in SharePoint Server][sharepoint-service-account]. To get the *Profile Synchronization account* name from the SharePoint Central Administration website, click **Application Management** > **Manage service applications** > **User Profile service application**. For more information, see [Configure profile synchronization by using SharePoint Active Directory Import in SharePoint Server](/SharePoint/administration/configure-profile-synchronization-by-using-sharepoint-active-directory-import).

-## Service accounts overview

-In a managed domain, a security group named *Microsoft Entra DC Service Accounts* exists as part of the *Users* organizational unit (OU). Members of this security group are delegated the following privileges:

-The *Microsoft Entra DC Service Accounts* security group is also a member of the built-in group *Pre-Windows 2000 Compatible Access*.

-When added to this security group, the service account for SharePoint Server user profile synchronization service is granted the required privileges to work correctly.

-## Enable support for SharePoint Server user profile sync

-The service account for SharePoint Server needs adequate privileges to replicate changes to the directory and let SharePoint Server user profile sync work correctly. To provide these privileges, add the service account used for SharePoint user profile synchronization to the *Microsoft Entra DC Service Accounts* group.

-From your Domain Services management VM, complete the following steps:

-> [!NOTE]

-> To edit group membership in a managed domain, you must be signed in to a user account that's a member of the *AAD DC Administrators* group.

-1. From the Start screen, select **Administrative Tools**. A list of available management tools is shown that were installed in the tutorial to [create a management VM][tutorial-create-management-vm].

-1. To manage group membership, select **Active Directory Administrative Center** from the list of administrative tools.

-1. In the left pane, choose your managed domain, such as *aaddscontoso.com*. A list of existing OUs and resources is shown.

-1. Select the **Users** OU, then choose the *Microsoft Entra DC Service Accounts* security group.

-1. Select **Members**, then choose **Add...**.

-1. Enter the name of the SharePoint service account, then select **OK**. In the following example, the SharePoint service account is named *spadmin*:

- 

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[tutorial-create-management-vm]: tutorial-create-management-vm.md

-<!-- EXTERNAL LINKS -->

-[sharepoint-service-account]: /sharepoint/security-for-sharepoint-server/plan-for-administrative-and-service-accounts

-description: Learn which Domain Services features are available in Azure Government.

-# Microsoft Entra Domain Services feature availability

-<!Jeremy said there are additional features that don't fit nicely in this list that we need to add later>

-This following table lists Microsoft Entra Domain Services feature availability in Azure Government.

-| Feature | Availability |

-||::|

-| Configure LDAPS | &#x2705; |

-| Create trusts | &#x2705; |

-| Create replica sets | &#x2705; |

-| Configure and scope user and group sync | &#x2705; |

-| Configure password hash sync | &#x2705; |

-| Configure password and account lockout policies | &#x2705; |

-| Manage Group Policy | &#x2705; |

-| Manage DNS | &#x2705; |

-| Email notifications | &#x2705; |

-| Configure Kerberos constrained delegation | &#x2705; |

-| Auditing and Azure Monitor Workbooks templates | &#x2705; |

-| Domain join Windows VMs | &#x2705; |

-| Domain join Linux VMs | &#x2705; |

-| Deploy Microsoft Entra application proxy | &#x2705; |

-| Enable profile sync for SharePoint | &#x2705; |

-## Next steps

-description: Learn how to check fleet metrics of a Microsoft Entra Domain Services managed domain.

-# Check fleet metrics of Microsoft Entra Domain Services

-Administrators can use Azure Monitor Metrics to configure a scope for Microsoft Entra Domain Services and gain insights into how the service is performing.

-You can access Domain Services metrics from two places:

- :::image type="content" border="true" source="media/fleet-metrics/select.png" alt-text="Screenshot of how to select Domain Services for fleet metrics.":::

- :::image type="content" border="true" source="media/fleet-metrics/metrics-scope.png" alt-text="Screenshot of how to select Domain Services as scope in Azure Monitor Metrics.":::

- The following screenshot shows how to select combined metrics for Total Processor Time and LDAP searches:

- :::image type="content" border="true" source="media/fleet-metrics/combined-metrics.png" alt-text="Screenshot of combined metrics in Azure Monitor Metrics.":::

- You can also view metrics for a fleet of Domain Services instances:

- :::image type="content" border="true" source="media/fleet-metrics/metrics-instance.png" alt-text="Screenshot of how to select a Domain Services instance as the scope for fleet metrics.":::

- The following screenshot shows combined metrics for Total Processor Time, DNS Queries, and LDAP searches by role instance:

- :::image type="content" border="true" source="media/fleet-metrics/combined-metrics-instance.png" alt-text="Screenshot of combined metrics for a Domain Services instance.":::

-## Metrics definitions and descriptions

-You can select a metric for more details about the data collection.

-The following table describes the metrics that are available for Domain Services.

-| Metric | Description |

-|--|-|

-|DNS - Total Query Received/sec |The average number of queries received by DNS server in each second. It's backed by performance counter data from the domain controller, and can be filtered or split by role instance.|

-|Total Response Sent/sec |The average number of responses sent by DNS server in each second. It's backed by performance counter data from the domain controller, and can be filtered or split by role instance.|

-|NTDS - LDAP Successful Binds/sec|The number of LDAP successful binds per second for the NTDS object. It's backed by performance counter data from the domain controller, and can be filtered or split by role instance.|

-|% Committed Bytes In Use |The ratio of Memory\\\Committed Bytes to the Memory\\\Commit Limit. Committed memory is the physical memory in use for which space has been reserved in the paging file should it need to be written to disk. The commit limit is determined by the size of the paging file. If the paging file is enlarged, the commit limit increases, and the ratio is reduced. This counter displays the current percentage value only; it isn't an average. It's backed by performance counter data from the domain controller, and can be filtered or split by role instance.|

-|Total Processor Time |The percentage of elapsed time that the processor spends to execute a non-Idle thread. It's calculated by measuring the percentage of time that the processor spends executing the idle thread and then subtracting that value from 100%. (Each processor has an idle thread that consumes cycles when no other threads are ready to run). This counter is the primary indicator of processor activity, and displays the average percentage of busy time observed during the sample interval. It should be noted that the accounting calculation of whether the processor is idle is performed at an internal sampling interval of the system clock (10ms). On today's fast processors, % Processor Time can therefore underestimate the processor utilization as the processor may be spending much time servicing threads between the system clock sampling interval. Workload-based timer applications are one type application that is more likely to be measured inaccurately because timers are signaled just after the sample is taken. It's backed by performance counter data from the domain controller, and can be filtered or split by role instance.|

-|Kerberos Authentications |The number of times that clients use a ticket to authenticate to this computer per second. It's backed by performance counter data from the domain controller, and can be filtered or split by role instance.|

-|NTLM Authentications|The number of NTLM authentications processed per second for the Active Directory on this domain controller or for local accounts on this member server. It's backed by performance counter data from the domain controller, and can be filtered or split by role instance.|

-|% Processor Time (dns)|The percentage of elapsed time that all of dns process threads used the processor to execute instructions. An instruction is the basic unit of execution in a computer, a thread is the object that executes instructions, and a process is the object created when a program is run. Code executed to handle some hardware interrupts and trap conditions are included in this count. It's backed by performance counter data from the domain controller, and can be filtered or split by role instance.|

-|% Processor Time (lsass)|The percentage of elapsed time that all of lsass process threads used the processor to execute instructions. An instruction is the basic unit of execution in a computer, a thread is the object that executes instructions, and a process is the object created when a program is run. Code executed to handle some hardware interrupts and trap conditions are included in this count. It's backed by performance counter data from the domain controller, and can be filtered or split by role instance.|

-|NTDS - LDAP Searches/sec |The average number of searches per second for the NTDS object. It's backed by performance counter data from the domain controller, and can be filtered or split by role instance.|

-## Azure Monitor alert

-You can configure metric alerts for Domain Services to be notified of possible problems. Metric alerts are one type of alert for Azure Monitor. For more information about other types of alerts, see [What are Azure Monitor Alerts?](/azure/azure-monitor/alerts/alerts-overview).

-To view and manage Azure Monitor alert, a user needs to be assigned [Azure Monitor roles](/azure/azure-monitor/roles-permissions-security).

-

-In Azure Monitor or Domain Services Metrics, click **New alert** and configure a Domain Services instance as the scope. Then choose the metrics you want to measure from the list of available signals:

- :::image type="content" border="true" source="media/fleet-metrics/available-alerts.png" alt-text="Screenshot of available alerts.":::

-The following screenshot shows how to define a metric alert with a threshold for **Total Processor Time**:

-You can also configure an alert notification, which can be email, SMS, or voice call:

-The following screenshot shows a metrics alert triggered for **Total Processor Time**:

-In this case, an email notification is sent after an alert activation:

-Another email notification is sent after deactivation of the alert:

-## Select multiple resources

-You can upvote to enable multiple resource selection to correlate data between resource types.

-## Next steps

-description: Learn how to retrieve data from Microsoft Entra Domain Services.

-# Microsoft Entra Domain Services instructions for data retrieval

-This document describes how to retrieve data from Microsoft Entra Domain Services.

-<a name='use-azure-active-directory-to-create-read-update-and-delete-user-objects'></a>

-## Use Microsoft Entra ID to create, read, update, and delete user objects

-You can create a user in the Microsoft Entra admin center or by using Graph PowerShell or Graph API. You can also read, update, and delete users. The next sections show how to do these operations in the Microsoft Entra admin center.

-### Create, read, or update a user

-You can create a new user using the Microsoft Entra admin center.

-To add a new user, follow these steps:

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [User Administrator](/azure/active-directory/roles/permissions-reference#user-administrator).

-1. Browse to **Identity** > **Users**, and then select **New user**.

- 

-1. On the **User** page, enter information for this user:

- - **Name**. Required. The first and last name of the new user. For example, *Mary Parker*.

- - **User name**. Required. The user name of the new user. For example, `mary@contoso.com`.

- - **Groups**. Optionally, you can add the user to one or more existing groups.

- - **Directory role**: If you require Microsoft Entra administrative permissions for the user, you can add them to a Microsoft Entra role.

- - **Job info**: You can add more information about the user here.

-1. Copy the autogenerated password provided in the **Password** box. You'll need to give this password to the user to sign in for the first time.

-1. Select **Create**.

-The user is created and added to your Microsoft Entra organization.

-To read or update a user, search for and select the user such as, _Mary Parker_. Change any property and click **Save**.

-### Delete a user

-To delete a user, follow these steps:

-1. Search for and select the user you want to delete from your Microsoft Entra tenant. For example, _Mary Parker_.

-1. Select **Delete user**.

- 

-The user is deleted and no longer appears on the **Users - All users** page. The user can be seen on the **Deleted users** page for the next 30 days and can be restored during that time.

-When a user is deleted, any licenses consumed by the user are made available for other users.

-<a name='use-rsat-tools-to-connect-to-an-azure-ad-ds-managed-domain-and-view-users'></a>

-## Use RSAT tools to connect to a Microsoft Entra Domain Services managed domain and view users

-Sign in to an administrative workstation with a user account that's a member of the *AAD DC Administrators* group. The following steps require installation of [Remote Server Administration Tools (RSAT)](tutorial-create-management-vm.md#install-active-directory-administrative-tools).

-1. From the **Start** menu, select **Windows Administrative Tools**. The Active Directory Administration Tools are listed.

- 

-1. Select **Active Directory Administrative Center**.

-1. To explore the managed domain, choose the domain name in the left pane, such as *aaddscontoso*. Two containers named *AADDC Computers* and *AADDC Users* are at the top of the list.

- 

-1. To see the users and groups that belong to the managed domain, select the **AADDC Users** container. The user accounts and groups from your Microsoft Entra tenant are listed in this container.

- In the following example output, a user account named *Contoso Admin* and a group for *AAD DC Administrators* are shown in this container.

- 

-1. To see the computers that are joined to the managed domain, select the **AADDC Computers** container. An entry for the current virtual machine, such as *myVM*, is listed. Computer accounts for all devices that are joined to the managed domain are stored in this *AADDC Computers* container.

-You can also use the *Active Directory Module for Windows PowerShell*, installed as part of the administrative tools, to manage common actions in your managed domain.

-## Next steps

-* [Microsoft Entra Domain Services Overview](overview.md)

-description: Learn how to configure and join a CentOS Linux virtual machine to a Microsoft Entra Domain Services managed domain.

-# Join a CentOS Linux virtual machine to a Microsoft Entra Domain Services managed domain

-To let users sign in to virtual machines (VMs) in Azure using a single set of credentials, you can join VMs to a Microsoft Entra Domain Services managed domain. When you join a VM to a Domain Services managed domain, user accounts and credentials from the domain can be used to sign in and manage servers. Group memberships from the managed domain are also applied to let you control access to files or services on the VM.

-This article shows you how to join a CentOS Linux VM to a managed domain.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A user account that's part of the managed domain.

-* Unique Linux VM names that are a maximum of 15 characters to avoid truncated names that might cause conflicts in Active Directory.

-## Create and connect to a CentOS Linux VM

-If you have an existing CentOS Linux VM in Azure, connect to it using SSH, then continue on to the next step to [start configuring the VM](#configure-the-hosts-file).

-If you need to create a CentOS Linux VM, or want to create a test VM for use with this article, you can use one of the following methods:

-* [Microsoft Entra admin center](/azure/virtual-machines/linux/quick-create-portal)

-* [Azure CLI](/azure/virtual-machines/linux/quick-create-cli)

-* [Azure PowerShell](/azure/virtual-machines/linux/quick-create-powershell)

-When you create the VM, pay attention to the virtual network settings to make sure that the VM can communicate with the managed domain:

-* Deploy the VM into the same, or a peered, virtual network in which you have enabled Microsoft Entra Domain Services.

-* Deploy the VM into a different subnet than your managed domain.

-Once the VM is deployed, follow the steps to connect to the VM using SSH.

-## Configure the hosts file

-To make sure that the VM host name is correctly configured for the managed domain, edit the */etc/hosts* file and set the hostname:

-```bash

-sudo vi /etc/hosts

-```

-In the *hosts* file, update the *localhost* address. In the following example:

-* *aaddscontoso.com* is the DNS domain name of your managed domain.

-* *centos* is the hostname of your CentOS VM that you're joining to the managed domain.

-Update these names with your own values:

-```config

-127.0.0.1 centos.aaddscontoso.com centos

-```

-When done, save and exit the *hosts* file using the `:wq` command of the editor.

-## Install required packages

-The VM needs some additional packages to join the VM to the managed domain. To install and configure these packages, update and install the domain-join tools using `yum`:

-```bash

-sudo yum install adcli realmd sssd krb5-workstation krb5-libs oddjob oddjob-mkhomedir samba-common-tools

-```

-## Join VM to the managed domain

-Now that the required packages are installed on the VM, join the VM to the managed domain.

-1. Use the `realm discover` command to discover the managed domain. The following example discovers the realm *AADDSCONTOSO.COM*. Specify your own managed domain name in ALL UPPERCASE:

- ```bash

- sudo realm discover AADDSCONTOSO.COM

- ```

- If the `realm discover` command can't find your managed domain, review the following troubleshooting steps:

- * Make sure that the domain is reachable from the VM. Try `ping aaddscontoso.com` to see if a positive reply is returned.

- * Check that the VM is deployed to the same, or a peered, virtual network in which the managed domain is available.

- * Confirm that the DNS server settings for the virtual network have been updated to point to the domain controllers of the managed domain.

-1. Now initialize Kerberos using the `kinit` command. Specify a user that's a part of the managed domain. If needed, [add a user account to a group in Microsoft Entra ID](/azure/active-directory/fundamentals/how-to-manage-groups).

- Again, the managed domain name must be entered in ALL UPPERCASE. In the following example, the account named `contosoadmin@aaddscontoso.com` is used to initialize Kerberos. Enter your own user account that's a part of the managed domain:

- ```bash

- sudo kinit contosoadmin@AADDSCONTOSO.COM

- ```

-1. Finally, join the VM to the managed domain using the `realm join` command. Use the same user account that's a part of the managed domain that you specified in the previous `kinit` command, such as `contosoadmin@AADDSCONTOSO.COM`:

- ```bash

- sudo realm join --verbose AADDSCONTOSO.COM -U 'contosoadmin@AADDSCONTOSO.COM' --membership-software=adcli

- ```

-It takes a few moments to join the VM to the managed domain. The following example output shows the VM has successfully joined to the managed domain:

-```output

-Successfully enrolled machine in realm

-```

-If your VM can't successfully complete the domain-join process, make sure that the VM's network security group allows outbound Kerberos traffic on TCP + UDP port 464 to the virtual network subnet for your managed domain.

-## Allow password authentication for SSH

-By default, users can only sign in to a VM using SSH public key-based authentication. Password-based authentication fails. When you join the VM to a managed domain, those domain accounts need to use password-based authentication. Update the SSH configuration to allow password-based authentication as follows.

-1. Open the *sshd_conf* file with an editor:

- ```bash

- sudo vi /etc/ssh/sshd_config

- ```

-1. Update the line for *PasswordAuthentication* to *yes*:

- ```bash

- PasswordAuthentication yes

- ```

- When done, save and exit the *sshd_conf* file using the `:wq` command of the editor.

-1. To apply the changes and let users sign in using a password, restart the SSH service:

- ```bash

- sudo systemctl restart sshd

- ```

-## Grant the 'AAD DC Administrators' group sudo privileges

-To grant members of the *AAD DC Administrators* group administrative privileges on the CentOS VM, you add an entry to the */etc/sudoers*. Once added, members of the *AAD DC Administrators* group can use the `sudo` command on the CentOS VM.

-1. Open the *sudoers* file for editing:

- ```bash

- sudo visudo

- ```

-1. Add the following entry to the end of */etc/sudoers* file. The *AAD DC Administrators* group contains whitespace in the name, so include the backslash escape character in the group name. Add your own domain name, such as *aaddscontoso.com*:

- ```config

- # Add 'AAD DC Administrators' group members as admins.

- %AAD\ DC\ Administrators@aaddscontoso.com ALL=(ALL) NOPASSWD:ALL

- ```

- When done, save and exit the editor using the `:wq` command of the editor.

-## Sign in to the VM using a domain account

-To verify that the VM has been successfully joined to the managed domain, start a new SSH connection using a domain user account. Confirm that a home directory has been created, and that group membership from the domain is applied.

-1. Create a new SSH connection from your console. Use a domain account that belongs to the managed domain using the `ssh -l` command, such as `contosoadmin@aaddscontoso.com` and then enter the address of your VM, such as *centos.aaddscontoso.com*. If you use the Azure Cloud Shell, use the public IP address of the VM rather than the internal DNS name.

- ```bash

- sudo ssh -l contosoadmin@AADDSCONTOSO.com centos.aaddscontoso.com

- ```

-1. When you've successfully connected to the VM, verify that the home directory was initialized correctly:

- ```bash

- sudo pwd

- ```

- You should be in the */home* directory with your own directory that matches the user account.

-1. Now check that the group memberships are being resolved correctly:

- ```bash

- sudo id

- ```

- You should see your group memberships from the managed domain.

-1. If you signed in to the VM as a member of the *AAD DC Administrators* group, check that you can correctly use the `sudo` command:

- ```bash

- sudo yum update

- ```

-## Next steps

-If you have problems connecting the VM to the managed domain or signing in with a domain account, see [Troubleshooting domain join issues](join-windows-vm.md#troubleshoot-domain-join-issues).

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-description: Learn how to configure and join a CoreOS virtual machine to a Microsoft Entra Domain Services managed domain.

-# Join a CoreOS virtual machine to a Microsoft Entra Domain Services managed domain

-To let users sign in to virtual machines (VMs) in Azure using a single set of credentials, you can join VMs to a Microsoft Entra Domain Services managed domain. When you join a VM to a Domain Services managed domain, user accounts and credentials from the domain can be used to sign in and manage servers. Group memberships from the managed domain are also applied to let you control access to files or services on the VM.

-This article shows you how to join a CoreOS VM to a managed domain.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A user account that's a part of the managed domain.

-* Unique Linux VM names that are a maximum of 15 characters to avoid truncated names that might cause conflicts in Active Directory.

-## Create and connect to a CoreOS Linux VM

-If you have an existing CoreOS Linux VM in Azure, connect to it using SSH, then continue on to the next step to [start configuring the VM](#configure-the-hosts-file).

-If you need to create a CoreOS Linux VM, or want to create a test VM for use with this article, you can use one of the following methods:

-* [Microsoft Entra admin center](/azure/virtual-machines/linux/quick-create-portal)

-* [Azure CLI](/azure/virtual-machines/linux/quick-create-cli)

-* [Azure PowerShell](/azure/virtual-machines/linux/quick-create-powershell)

-When you create the VM, pay attention to the virtual network settings to make sure that the VM can communicate with the managed domain:

-* Deploy the VM into the same, or a peered, virtual network in which you have enabled Microsoft Entra Domain Services.

-* Deploy the VM into a different subnet than your Microsoft Entra Domain Services managed domain.

-Once the VM is deployed, follow the steps to connect to the VM using SSH.

-## Configure the hosts file

-To make sure that the VM host name is correctly configured for the managed domain, edit the */etc/hosts* file and set the hostname:

-```console

-sudo vi /etc/hosts

-```

-In the *hosts* file, update the *localhost* address. In the following example:

-* *aaddscontoso.com* is the DNS domain name of your managed domain.

-* *coreos* is the hostname of your CoreOS VM that you're joining to the managed domain.

-Update these names with your own values:

-```console

-127.0.0.1 coreos coreos.aaddscontoso.com

-```

-When done, save and exit the *hosts* file using the `:wq` command of the editor.

-## Configure the SSSD service

-Update the */etc/sssd/sssd.conf* SSSD configuration.

-```console

-sudo vi /etc/sssd/sssd.conf

-```

-Specify your own managed domain name for the following parameters:

-* *domains* in ALL UPPER CASE

-* *[domain/AADDSCONTOSO]* where AADDSCONTOSO is in ALL UPPER CASE

-* *ldap_uri*

-* *ldap_search_base*

-* *krb5_server*

-* *krb5_realm* in ALL UPPER CASE

-```console

-[sssd]

-config_file_version = 2

-services = nss, pam

-domains = AADDSCONTOSO.COM

-[domain/AADDSCONTOSO]

-id_provider = ad

-auth_provider = ad

-chpass_provider = ad

-ldap_uri = ldap://aaddscontoso.com

-ldap_search_base = dc=aaddscontoso,dc=com

-ldap_schema = rfc2307bis

-ldap_sasl_mech = GSSAPI

-ldap_user_object_class = user

-ldap_group_object_class = group

-ldap_user_home_directory = unixHomeDirectory

-ldap_user_principal = userPrincipalName

-ldap_account_expire_policy = ad

-ldap_force_upper_case_realm = true

-fallback_homedir = /home/%d/%u

-krb5_server = aaddscontoso.com

-krb5_realm = AADDSCONTOSO.COM

-```

-## Join the VM to the managed domain

-With the SSSD configuration file updated, now join the virtual machine to the managed domain.

-1. First, use the `adcli info` command to verify you can see information about the managed domain. The following example gets information for the domain *AADDSCONTOSO.COM*. Specify your own managed domain name in ALL UPPERCASE:

- ```console

- sudo adcli info AADDSCONTOSO.COM

- ```

- If the `adcli info` command can't find your managed domain, review the following troubleshooting steps:

- * Make sure that the domain is reachable from the VM. Try `ping aaddscontoso.com` to see if a positive reply is returned.

- * Check that the VM is deployed to the same, or a peered, virtual network in which the managed domain is available.

- * Confirm that the DNS server settings for the virtual network have been updated to point to the domain controllers of the managed domain.

-1. Now join the VM to the managed domain using the `adcli join` command. Specify a user that's a part of the managed domain. If needed, [add a user account to a group in Microsoft Entra ID](/azure/active-directory/fundamentals/how-to-manage-groups).

- Again, the managed domain name must be entered in ALL UPPERCASE. In the following example, the account named `contosoadmin@aaddscontoso.com` is used to initialize Kerberos. Enter your own user account that's a part of the managed domain.

- ```console

- sudo adcli join -D AADDSCONTOSO.COM -U contosoadmin@AADDSCONTOSO.COM -K /etc/krb5.keytab -H coreos.aaddscontoso.com -N coreos

- ```

- The `adcli join` command doesn't return any information when the VM has successfully joined to the managed domain.

-1. To apply the domain-join configuration, start the SSSD service:

-

- ```console

- sudo systemctl start sssd.service

- ```

-## Sign in to the VM using a domain account

-To verify that the VM has been successfully joined to the managed domain, start a new SSH connection using a domain user account. Confirm that a home directory has been created, and that group membership from the domain is applied.

-1. Create a new SSH connection from your console. Use a domain account that belongs to the managed domain using the `ssh -l` command, such as `contosoadmin@aaddscontoso.com` and then enter the address of your VM, such as *coreos.aaddscontoso.com*. If you use the Azure Cloud Shell, use the public IP address of the VM rather than the internal DNS name.

- ```console

- ssh -l contosoadmin@AADDSCONTOSO.com coreos.aaddscontoso.com

- ```

-1. Now check that the group memberships are being resolved correctly:

- ```console

- id

- ```

- You should see your group memberships from the managed domain.

-## Next steps

-If you have problems connecting the VM to the managed domain or signing in with a domain account, see [Troubleshooting domain join issues](join-windows-vm.md#troubleshoot-domain-join-issues).

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-description: Learn how to configure and join a Red Hat Enterprise Linux virtual machine to a Microsoft Entra Domain Services managed domain.

-# Join a Red Hat Enterprise Linux virtual machine to a Microsoft Entra Domain Services managed domain

-To let users sign in to virtual machines (VMs) in Azure using a single set of credentials, you can join VMs to a Microsoft Entra Domain Services managed domain. When you join a VM to a Domain Services managed domain, user accounts and credentials from the domain can be used to sign in and manage servers. Group memberships from the managed domain are also applied to let you control access to files or services on the VM.

-This article shows you how to join a Red Hat Enterprise Linux (RHEL) VM to a managed domain.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A user account that's a part of the managed domain.

-* Unique Linux VM names that are a maximum of 15 characters to avoid truncated names that might cause conflicts in Active Directory.

-## Create and connect to a RHEL Linux VM

-If you have an existing RHEL Linux VM in Azure, connect to it using SSH, then continue on to the next step to [start configuring the VM](#configure-the-hosts-file).

-If you need to create a RHEL Linux VM, or want to create a test VM for use with this article, you can use one of the following methods:

-* [Microsoft Entra admin center](/azure/virtual-machines/linux/quick-create-portal)

-* [Azure CLI](/azure/virtual-machines/linux/quick-create-cli)

-* [Azure PowerShell](/azure/virtual-machines/linux/quick-create-powershell)

-When you create the VM, pay attention to the virtual network settings to make sure that the VM can communicate with the managed domain:

-* Deploy the VM into the same, or a peered, virtual network in which you have enabled Microsoft Entra Domain Services.

-* Deploy the VM into a different subnet than your Microsoft Entra Domain Services managed domain.

-Once the VM is deployed, follow the steps to connect to the VM using SSH.

-## Configure the hosts file

-To make sure that the VM host name is correctly configured for the managed domain, edit the */etc/hosts* file and set the hostname:

-```bash

-sudo vi /etc/hosts

-```

-In the *hosts* file, update the *localhost* address. In the following example:

-* *aaddscontoso.com* is the DNS domain name of your managed domain.

-* *rhel* is the hostname of your RHEL VM that you're joining to the managed domain.

-Update these names with your own values:

-```config

-127.0.0.1 rhel rhel.aaddscontoso.com

-```

-When done, save and exit the *hosts* file using the `:wq` command of the editor.

-# [RHEL 6](#tab/rhel)

-> [!IMPORTANT]

-> Keep in consideration Red Hat Enterprise Linux 6.X and Oracle Linux 6.x is already EOL.

-> RHEL 6.10 has available [ELS support](https://www.redhat.com/en/resources/els-datasheet), which [will end on 06/2024]( https://access.redhat.com/product-life-cycles/?product=Red%20Hat%20Enterprise%20Linux,OpenShift%20Container%20Platform%204).

-## Install required packages

-The VM needs some additional packages to join the VM to the managed domain. To install and configure these packages, update and install the domain-join tools using `yum`.

-```bash

-sudo yum install adcli sssd authconfig krb5-workstation

-```

-## Join VM to the managed domain

-Now that the required packages are installed on the VM, join the VM to the managed domain.

-1. Use the `adcli info` command to discover the managed domain. The following example discovers the realm *ADDDSCONTOSO.COM*. Specify your own managed domain name in ALL UPPERCASE:

- ```bash

- sudo adcli info aaddscontoso.com

- ```

- If the `adcli info` command can't find your managed domain, review the following troubleshooting steps:

- * Make sure that the domain is reachable from the VM. Try `ping aaddscontoso.com` to see if a positive reply is returned.

- * Check that the VM is deployed to the same, or a peered, virtual network in which the managed domain is available.

- * Confirm that the DNS server settings for the virtual network have been updated to point to the domain controllers of the managed domain.

-1. First, join the domain using the `adcli join` command, this command also creates the keytab to authenticate the machine. Use a user account that's a part of the managed domain.

- ```bash

- sudo adcli join aaddscontoso.com -U contosoadmin

- ```

-1. Now configure the `/ect/krb5.conf` and create the `/etc/sssd/sssd.conf` files to use the `aaddscontoso.com` Active Directory domain.

- Make sure that `AADDSCONTOSO.COM` is replaced by your own domain name:

- Open the `/etc/krb5.conf` file with an editor:

- ```bash

- sudo vi /etc/krb5.conf

- ```

- Update the `krb5.conf` file to match the following sample:

- ```config

- [logging]

- default = FILE:/var/log/krb5libs.log

- kdc = FILE:/var/log/krb5kdc.log

- admin_server = FILE:/var/log/kadmind.log

-

- [libdefaults]

- default_realm = AADDSCONTOSO.COM

- dns_lookup_realm = true

- dns_lookup_kdc = true

- ticket_lifetime = 24h

- renew_lifetime = 7d

- forwardable = true

-

- [realms]

- AADDSCONTOSO.COM = {

- kdc = AADDSCONTOSO.COM

- admin_server = AADDSCONTOSO.COM

- }

-

- [domain_realm]

- .AADDSCONTOSO.COM = AADDSCONTOSO.COM

- AADDSCONTOSO.COM = AADDSCONTOSO.COM

- ```

-

- Create the `/etc/sssd/sssd.conf` file:

-

- ```bash

- sudo vi /etc/sssd/sssd.conf

- ```

- Update the `sssd.conf` file to match the following sample:

- ```config

- [sssd]

- services = nss, pam, ssh, autofs

- config_file_version = 2

- domains = AADDSCONTOSO.COM

-

- [domain/AADDSCONTOSO.COM]

-

- id_provider = ad

- ```

-1. Make sure `/etc/sssd/sssd.conf` permissions are 600 and is owned by root user:

- ```bash

- sudo chmod 600 /etc/sssd/sssd.conf

- sudo chown root:root /etc/sssd/sssd.conf

- ```

-1. Use `authconfig` to instruct the VM about the AD Linux integration:

- ```bash

- sudo authconfig --enablesssd --enablesssd auth --update

- ```

-1. Start and enable the sssd service:

- ```bash

- sudo service sssd start

- sudo chkconfig sssd on

- ```

-If your VM can't successfully complete the domain-join process, make sure that the VM's network security group allows outbound Kerberos traffic on TCP + UDP port 464 to the virtual network subnet for your managed domain.

-Now check if you can query user AD information using `getent`

-```bash

-sudo getent passwd contosoadmin

-```

-## Allow password authentication for SSH

-By default, users can only sign in to a VM using SSH public key-based authentication. Password-based authentication fails. When you join the VM to a managed domain, those domain accounts need to use password-based authentication. Update the SSH configuration to allow password-based authentication as follows.

-1. Open the *sshd_conf* file with an editor:

- ```bash

- sudo vi /etc/ssh/sshd_config

- ```

-1. Update the line for *PasswordAuthentication* to *yes*:

- ```config

- PasswordAuthentication yes

- ```

- When done, save and exit the *sshd_conf* file using the `:wq` command of the editor.

-1. To apply the changes and let users sign in using a password, restart the SSH service for your RHEL distro version:

- ```bash

- sudo service sshd restart

- ```

-# [RHEL 7](#tab/rhel7)

-## Install required packages

-The VM needs some additional packages to join the VM to the managed domain. To install and configure these packages, update and install the domain-join tools using `yum`.

-```bash

-sudo yum install realmd sssd krb5-workstation krb5-libs oddjob oddjob-mkhomedir samba-common-tools

-```

-## Join VM to the managed domain

-Now that the required packages are installed on the VM, join the VM to the managed domain. Again, use the appropriate steps for your RHEL distro version.

-1. Use the `realm discover` command to discover the managed domain. The following example discovers the realm *AADDSCONTOSO.COM*. Specify your own managed domain name in ALL UPPERCASE:

- ```bash

- sudo realm discover AADDSCONTOSO.COM

- ```

- If the `realm discover` command can't find your managed domain, review the following troubleshooting steps:

- * Make sure that the domain is reachable from the VM. Try `ping aaddscontoso.com` to see if a positive reply is returned.

- * Check that the VM is deployed to the same, or a peered, virtual network in which the managed domain is available.

- * Confirm that the DNS server settings for the virtual network have been updated to point to the domain controllers of the managed domain.

-1. Now initialize Kerberos using the `kinit` command. Specify a user that's a part of the managed domain. If needed, [add a user account to a group in Microsoft Entra ID](/azure/active-directory/fundamentals/how-to-manage-groups).

- Again, the managed domain name must be entered in ALL UPPERCASE. In the following example, the account named `contosoadmin@aaddscontoso.com` is used to initialize Kerberos. Enter your own user account that's a part of the managed domain:

- ```bash

- sudo kinit contosoadmin@AADDSCONTOSO.COM

- ```

-1. Finally, join the VM to the managed domain using the `realm join` command. Use the same user account that's a part of the managed domain that you specified in the previous `kinit` command, such as `contosoadmin@AADDSCONTOSO.COM`:

- ```bash

- sudo realm join --verbose AADDSCONTOSO.COM -U 'contosoadmin@AADDSCONTOSO.COM'

- ```

-It takes a few moments to join the VM to the managed domain. The following example output shows the VM has successfully joined to the managed domain:

-```output

-Successfully enrolled machine in realm

-```

-## Allow password authentication for SSH

-By default, users can only sign in to a VM using SSH public key-based authentication. Password-based authentication fails. When you join the VM to a managed domain, those domain accounts need to use password-based authentication. Update the SSH configuration to allow password-based authentication as follows.

-1. Open the *sshd_conf* file with an editor:

- ```bash

- sudo vi /etc/ssh/sshd_config

- ```

-1. Update the line for *PasswordAuthentication* to *yes*:

- ```bash

- PasswordAuthentication yes

- ```

- When done, save and exit the *sshd_conf* file using the `:wq` command of the editor.

-1. To apply the changes and let users sign in using a password, restart the SSH service.

- ```bash

- sudo systemctl restart sshd

- ```

-## Grant the 'AAD DC Administrators' group sudo privileges

-To grant members of the *AAD DC Administrators* group administrative privileges on the RHEL VM, you add an entry to the */etc/sudoers*. Once added, members of the *AAD DC Administrators* group can use the `sudo` command on the RHEL VM.

-1. Open the *sudoers* file for editing:

- ```bash

- sudo visudo

- ```

-1. Add the following entry to the end of */etc/sudoers* file. The *AAD DC Administrators* group contains whitespace in the name, so include the backslash escape character in the group name. Add your own domain name, such as *aaddscontoso.com*:

- ```config

- # Add 'AAD DC Administrators' group members as admins.

- %AAD\ DC\ Administrators@aaddscontoso.com ALL=(ALL) NOPASSWD:ALL

- ```

- When done, save and exit the editor using the `:wq` command of the editor.

-## Sign in to the VM using a domain account

-To verify that the VM has been successfully joined to the managed domain, start a new SSH connection using a domain user account. Confirm that a home directory has been created, and that group membership from the domain is applied.

-1. Create a new SSH connection from your console. Use a domain account that belongs to the managed domain using the `ssh -l` command, such as `contosoadmin@aaddscontoso.com` and then enter the address of your VM, such as *rhel.aaddscontoso.com*. If you use the Azure Cloud Shell, use the public IP address of the VM rather than the internal DNS name.

- ```bash

- ssh -l contosoadmin@AADDSCONTOSO.com rhel.aaddscontoso.com

- ```

-1. When you've successfully connected to the VM, verify that the home directory was initialized correctly:

- ```bash

- pwd

- ```

- You should be in the */home* directory with your own directory that matches the user account.

-1. Now check that the group memberships are being resolved correctly:

- ```bash

- id

- ```

- You should see your group memberships from the managed domain.

-1. If you signed in to the VM as a member of the *AAD DC Administrators* group, check that you can correctly use the `sudo` command:

- ```bash

- sudo yum update

- ```

-## Next steps

-If you have problems connecting the VM to the managed domain or signing in with a domain account, see [Troubleshooting domain join issues](join-windows-vm.md#troubleshoot-domain-join-issues).

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-description: Learn how to configure and join a SUSE Linux Enterprise virtual machine to a Microsoft Entra Domain Services managed domain.

-# Join a SUSE Linux Enterprise virtual machine to a Microsoft Entra Domain Services managed domain

-To let users sign in to virtual machines (VMs) in Azure using a single set of credentials, you can join VMs to a Microsoft Entra Domain Services managed domain. When you join a VM to a Domain Services managed domain, user accounts and credentials from the domain can be used to sign in and manage servers. Group memberships from the managed domain are also applied to let you control access to files or services on the VM.

-This article shows you how to join a SUSE Linux Enterprise (SLE) VM to a managed domain.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A user account that's a part of the managed domain.

-* Unique Linux VM names that are a maximum of 15 characters to avoid truncated names that might cause conflicts in Active Directory.

-## Create and connect to a SLE Linux VM

-If you have an existing SLE Linux VM in Azure, connect to it using SSH, then continue on to the next step to [start configuring the VM](#configure-the-hosts-file).

-If you need to create a SLE Linux VM, or want to create a test VM for use with this article, you can use one of the following methods:

-* [Microsoft Entra admin center](/azure/virtual-machines/linux/quick-create-portal)

-* [Azure CLI](/azure/virtual-machines/linux/quick-create-cli)

-* [Azure PowerShell](/azure/virtual-machines/linux/quick-create-powershell)

-When you create the VM, pay attention to the virtual network settings to make sure that the VM can communicate with the managed domain:

-* Deploy the VM into the same, or a peered, virtual network in which you have enabled Microsoft Entra Domain Services.

-* Deploy the VM into a different subnet than your Microsoft Entra Domain Services managed domain.

-Once the VM is deployed, follow the steps to connect to the VM using SSH.

-## Configure the hosts file

-To make sure that the VM host name is correctly configured for the managed domain, edit the */etc/hosts* file and set the hostname:

-```bash

-sudo vi /etc/hosts

-```

-In the *hosts* file, update the *localhost* address. In the following example:

-* *aaddscontoso.com* is the DNS domain name of your managed domain.

-* *linux-q2gr* is the hostname of your SLE VM that you're joining to the managed domain.

-Update these names with your own values:

-```config

-127.0.0.1 linux-q2gr linux-q2gr.aaddscontoso.com

-```

-When done, save and exit the *hosts* file using the `:wq` command of the editor.

-## Join VM to the managed domain using SSSD

-To join the managed domain using **SSSD** and the *User Logon Management* module of YaST, complete the following steps:

-1. Install the *User Logon Management* YaST module:

- ```bash

- sudo zypper install yast2-auth-client

- ```

-1. Open YaST.

-1. To successfully use DNS autodiscovery later, configure the managed domain IP addresses (the *Active Directory server*) as the name server for your client.

- In YaST, select **System > Network Settings**.

-1. Select the *Hostname/DNS* tab, then enter the IP address(es) of the managed domain into the text box *Name Server 1*. These IP addresses are shown on the *Properties* window in the Microsoft Entra admin center for your managed domain, such as *10.0.2.4* and *10.0.2.5*.

- Add your own managed domain IP addresses, then select **OK**.

-1. From the YaST main window, choose *Network Services* > *User Logon Management*.

- The module opens with an overview showing different network properties of your computer and the authentication method currently in use, as shown in the following example screenshot:

- 

- To start editing, select **Change Settings**.

-To join the VM to the managed domain, complete the following steps:

-1. In the dialog box, select **Add Domain**.

-1. Specify the correct *Domain name*, such as *aaddscontoso.com*, then specify the services to use for identity data and authentication. Select *Microsoft Active Directory* for both.

- Make sure the option for *Enable the domain* is selected.

-1. When ready, select **OK**.

-1. Accept the default settings in the following dialog, then select **OK**.

-1. The VM installs additional software as needed, then checks to see if the managed domain is available.

- If everything is correct, the following example dialog is shown to indicate the VM has discovered the managed domain but that you're *Not yet enrolled*.

- 

-1. In the dialog, specify the *Username* and *Password* of a user that's a part of the managed domain. If needed, [add a user account to a group in Microsoft Entra ID](/azure/active-directory/fundamentals/how-to-manage-groups).

- To make sure that the current domain is enabled for Samba, activate *Overwrite Samba configuration to work with this AD*.

-1. To enroll, select **OK**.

-1. A message is shown to confirm that you are successfully enrolled. To finish, select **OK**.

-After the VM is enrolled in the managed domain, configure the client using *Manage Domain User Logon*, as shown in the following example screenshot:

-

-1. To allow sign-ins using data provided by the managed domain, check the box for *Allow Domain User Logon*.

-1. Optionally, under *Enable domain data source*, check additional data sources as needed for your environment. These options include which users are allowed to use **sudo** or which network drives are available.

-1. To allow users in the managed domain to have home directories on the VM, check the box for *Create Home Directories*.

-1. From the side bar, select **Service Options › Name switch**, then *Extended Options*. From that window, select either *fallback_homedir* or *override_homedir*, then select **Add**.

-1. Specify a value for the home directory location. To have home directories follow the format of */home/USER_NAME*, use */home/%u*. For more information about possible variables, see the sssd.conf man page (`man 5 sssd.conf`), section *override_homedir*.

-1. Select **OK**.

-1. To save the changes, select **OK**. Then make sure that the values displayed now are correct. To leave the dialog, select **Cancel**.

-1. If you intend to run SSSD and Winbind simultaneously (such as when joining via SSSD, but then running a Samba file server), the Samba option *kerberos method* should be set to *secrets and keytab* in smb.conf. The SSSD option *ad_update_samba_machine_account_password* should also be set to *true* in sssd.conf. These options prevent the system keytab from going out of sync.

-## Join VM to the managed domain using Winbind

-To join the managed domain using **winbind** and the *Windows Domain Membership* module of YaST, complete the following steps:

-1. In YaST, select **Network Services > Windows Domain Membership**.

-1. Enter the domain to join at *Domain or Workgroup* in the *Windows Domain Membership* screen. Enter the managed domain name, such as *aaddscontoso.com*.

- 

-1. To use the SMB source for Linux authentication, check the option for *Use SMB Information for Linux Authentication*.

-1. To automatically create a local home directory for managed domain users on the VM, check the option for *Create Home Directory on Login*.

-1. Check the option for *Offline Authentication* to allow your domain users to sign in even if the managed domain is temporarily unavailable.

-1. If you want to change the UID and GID ranges for the Samba users and groups, select *Expert Settings*.

-1. Configure Network Time Protocol (NTP) time synchronization for your managed domain by selecting *NTP Configuration*. Enter the IP addresses of the managed domain. These IP addresses are shown on the *Properties* window in the Microsoft Entra admin center for your managed domain, such as *10.0.2.4* and *10.0.2.5*.

-1. Select **OK** and confirm the domain join when prompted for it.

-1. Provide the password for an administrator in the managed domain and select **OK**.

- 

-After you have joined the managed domain, you can sign in to it from your workstation using the display manager of your desktop or the console.

-## Join VM to the managed domain using Winbind from the YaST command line interface

-To join the managed domain using **winbind** and the *YaST command line interface*:

-* Join the domain:

- ```bash

- sudo yast samba-client joindomain domain=aaddscontoso.com user=<admin> password=<admin password> machine=<(optional) machine account>

- ```

-## Join VM to the managed domain using Winbind from the terminal

-To join the managed domain using **winbind** and the *`samba net` command*:

-1. Install kerberos client and samba-winbind:

- ```bash

- sudo zypper in krb5-client samba-winbind

- ```

-2. Edit the configuration files:

- * /etc/samba/smb.conf

-

- ```config

- [global]

- workgroup = AADDSCONTOSO

- usershare allow guests = NO #disallow guests from sharing

- idmap config * : backend = tdb

- idmap config * : range = 1000000-1999999

- idmap config AADDSCONTOSO : backend = rid

- idmap config AADDSCONTOSO : range = 5000000-5999999

- kerberos method = secrets and keytab

- realm = AADDSCONTOSO.COM

- security = ADS

- template homedir = /home/%D/%U

- template shell = /bin/bash

- winbind offline logon = yes

- winbind refresh tickets = yes

- ```

- * /etc/krb5.conf

-

- ```config

- [libdefaults]

- default_realm = AADDSCONTOSO.COM

- clockskew = 300

- [realms]

- AADDSCONTOSO.COM = {

- kdc = PDC.AADDSCONTOSO.COM

- default_domain = AADDSCONTOSO.COM

- admin_server = PDC.AADDSCONTOSO.COM

- }

- [domain_realm]

- .aaddscontoso.com = AADDSCONTOSO.COM

- [appdefaults]

- pam = {

- ticket_lifetime = 1d

- renew_lifetime = 1d

- forwardable = true

- proxiable = false

- minimum_uid = 1

- }

- ```

- * /etc/security/pam_winbind.conf

-

- ```config

- [global]

- cached_login = yes

- krb5_auth = yes

- krb5_ccache_type = FILE

- warn_pwd_expire = 14

- ```

- * /etc/nsswitch.conf

-

- ```config

- passwd: compat winbind

- group: compat winbind

- ```

-3. Check that the date and time in Microsoft Entra ID and Linux are in sync. You can do this by adding the Microsoft Entra server to the NTP service:

-

- 1. Add the following line to `/etc/ntp.conf`:

-

- ```config

- server aaddscontoso.com

- ```

- 1. Restart the NTP service:

-

- ```bash

- sudo systemctl restart ntpd

- ```

-4. Join the domain:

- ```bash

- sudo net ads join -U Administrator%Mypassword

- ```

-5. Enable winbind as a login source in the Linux Pluggable Authentication Modules (PAM):

- ```bash

- config pam-config --add --winbind

- ```

-6. Enable automatic creation of home directories so that users can log in:

- ```bash

- sudo pam-config -a --mkhomedir

- ```

-7. Start and enable the winbind service:

- ```bash

- sudo systemctl enable winbind

- sudo systemctl start winbind

- ```

-## Allow password authentication for SSH

-By default, users can only sign in to a VM using SSH public key-based authentication. Password-based authentication fails. When you join the VM to a managed domain, those domain accounts need to use password-based authentication. Update the SSH configuration to allow password-based authentication as follows.

-1. Open the *sshd_conf* file with an editor:

- ```bash

- sudo vi /etc/ssh/sshd_config

- ```

-1. Update the line for *PasswordAuthentication* to *yes*:

- ```config

- PasswordAuthentication yes

- ```

- When done, save and exit the *sshd_conf* file using the `:wq` command of the editor.

-1. To apply the changes and let users sign in using a password, restart the SSH service:

- ```bash

- sudo systemctl restart sshd

- ```

-## Grant the 'AAD DC Administrators' group sudo privileges

-To grant members of the *AAD DC Administrators* group administrative privileges on the SLE VM, add an entry to the */etc/sudoers*. Once added, members of the *AAD DC Administrators* group can use the `sudo` command on the SLE VM.

-1. Open the *sudoers* file for editing:

- ```bash

- sudo visudo

- ```

-1. Add the following entry to the end of */etc/sudoers* file. The *AAD DC Administrators* group contains whitespace in the name, so include the backslash escape character in the group name. Add your own domain name, such as *aaddscontoso.com*:

- ```config

- # Add 'AAD DC Administrators' group members as admins.

- %AAD\ DC\ Administrators@aaddscontoso.com ALL=(ALL) NOPASSWD:ALL

- ```

- When done, save and exit the editor using the `:wq` command of the editor.

-## Sign in to the VM using a domain account

-To verify that the VM has been successfully joined to the managed domain, start a new SSH connection using a domain user account. Confirm that a home directory has been created, and that group membership from the domain is applied.

-1. Create a new SSH connection from your console. Use a domain account that belongs to the managed domain using the `ssh -l` command, such as `contosoadmin@aaddscontoso.com` and then enter the address of your VM, such as *linux-q2gr.aaddscontoso.com*. If you use the Azure Cloud Shell, use the public IP address of the VM rather than the internal DNS name.

- ```bash

- sudo ssh -l contosoadmin@AADDSCONTOSO.com linux-q2gr.aaddscontoso.com

- ```

-2. When you've successfully connected to the VM, verify that the home directory was initialized correctly:

- ```bash

- sudo pwd

- ```

- You should be in the */home* directory with your own directory that matches the user account.

-3. Now check that the group memberships are being resolved correctly:

- ```bash

- sudo id

- ```

- You should see your group memberships from the managed domain.

-4. If you signed in to the VM as a member of the *AAD DC Administrators* group, check that you can correctly use the `sudo` command:

- ```bash

- sudo zypper update

- ```

-## Next steps

-If you have problems connecting the VM to the managed domain or signing in with a domain account, see [Troubleshooting domain join issues](join-windows-vm.md#troubleshoot-domain-join-issues).

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-description: Learn how to configure and join an Ubuntu Linux virtual machine to a Microsoft Entra Domain Services managed domain.

-# Join an Ubuntu Linux virtual machine to a Microsoft Entra Domain Services managed domain

-To let users sign in to virtual machines (VMs) in Azure using a single set of credentials, you can join VMs to a Microsoft Entra Domain Services managed domain. When you join a VM to a Domain Services managed domain, user accounts and credentials from the domain can be used to sign in and manage servers. Group memberships from the managed domain are also applied to let you control access to files or services on the VM.

-This article shows you how to join an Ubuntu Linux VM to a managed domain.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A user account that's a part of the managed domain. Make sure the SAMAccountName attribute for the user is not autogenerated. If multiple user accounts in the Microsoft Entra tenant have the same mailNickname attribute, the SAMAccountName attribute for each user is autogenerated. For more information, see [How objects and credentials are synchronized in a Microsoft Entra Domain Services managed domain](synchronization.md).

-* Unique Linux VM names that are a maximum of 15 characters to avoid truncated names that might cause conflicts in Active Directory.

-## Create and connect to an Ubuntu Linux VM

-If you have an existing Ubuntu Linux VM in Azure, connect to it using SSH, then continue on to the next step to [start configuring the VM](#configure-the-hosts-file).

-If you need to create an Ubuntu Linux VM, or want to create a test VM for use with this article, you can use one of the following methods:

-* [Microsoft Entra admin center](/azure/virtual-machines/linux/quick-create-portal)

-* [Azure CLI](/azure/virtual-machines/linux/quick-create-cli)

-* [Azure PowerShell](/azure/virtual-machines/linux/quick-create-powershell)

-When you create the VM, pay attention to the virtual network settings to make sure that the VM can communicate with the managed domain:

-* Deploy the VM into the same, or a peered, virtual network in which you have enabled Microsoft Entra Domain Services.

-* Deploy the VM into a different subnet than your Microsoft Entra Domain Services managed domain.

-Once the VM is deployed, follow the steps to connect to the VM using SSH.

-## Configure the hosts file

-To make sure that the VM host name is correctly configured for the managed domain, edit the */etc/hosts* file and set the hostname:

-```bash

-sudo vi /etc/hosts

-```

-In the *hosts* file, update the *localhost* address. In the following example:

-* *aaddscontoso.com* is the DNS domain name of your managed domain.

-* *ubuntu* is the hostname of your Ubuntu VM that you're joining to the managed domain.

-Update these names with your own values:

-```config

-127.0.0.1 ubuntu.aaddscontoso.com ubuntu

-```

-When done, save and exit the *hosts* file using the `:wq` command of the editor.

-## Install required packages

-The VM needs some additional packages to join the VM to the managed domain. To install and configure these packages, update and install the domain-join tools using `apt-get`

-During the Kerberos installation, the *krb5-user* package prompts for the realm name in ALL UPPERCASE. For example, if the name of your managed domain is *aaddscontoso.com*, enter *AADDSCONTOSO.COM* as the realm. The installation writes the `[realm]` and `[domain_realm]` sections in */etc/krb5.conf* configuration file. Make sure that you specify the realm an ALL UPPERCASE:

-```bash

-sudo apt-get update

-sudo apt-get install krb5-user samba sssd sssd-tools libnss-sss libpam-sss ntp ntpdate realmd adcli

-```

-## Configure Network Time Protocol (NTP)

-For domain communication to work correctly, the date and time of your Ubuntu VM must synchronize with the managed domain. Add your managed domain's NTP hostname to the */etc/ntp.conf* file.

-1. Open the *ntp.conf* file with an editor:

- ```bash

- sudo vi /etc/ntp.conf

- ```

-1. In the *ntp.conf* file, create a line to add your managed domain's DNS name. In the following example, an entry for *aaddscontoso.com* is added. Use your own DNS name:

- ```config

- server aaddscontoso.com

- ```

- When done, save and exit the *ntp.conf* file using the `:wq` command of the editor.

-1. To make sure that the VM is synchronized with the managed domain, the following steps are needed:

- * Stop the NTP server

- * Update the date and time from the managed domain

- * Start the NTP service

- Run the following commands to complete these steps. Use your own DNS name with the `ntpdate` command:

- ```bash

- sudo systemctl stop ntp

- sudo ntpdate aaddscontoso.com

- sudo systemctl start ntp

- ```

-## Join VM to the managed domain

-Now that the required packages are installed on the VM and NTP is configured, join the VM to the managed domain.

-1. Use the `realm discover` command to discover the managed domain. The following example discovers the realm *AADDSCONTOSO.COM*. Specify your own managed domain name in ALL UPPERCASE:

- ```bash

- sudo realm discover AADDSCONTOSO.COM

- ```

- If the `realm discover` command can't find your managed domain, review the following troubleshooting steps:

- * Make sure that the domain is reachable from the VM. Try `ping aaddscontoso.com` to see if a positive reply is returned.

- * Check that the VM is deployed to the same, or a peered, virtual network in which the managed domain is available.

- * Confirm that the DNS server settings for the virtual network have been updated to point to the domain controllers of the managed domain.

-1. Now initialize Kerberos using the `kinit` command. Specify a user that's a part of the managed domain. If needed, [add a user account to a group in Microsoft Entra ID](/azure/active-directory/fundamentals/how-to-manage-groups).

- Again, the managed domain name must be entered in ALL UPPERCASE. In the following example, the account named `contosoadmin@aaddscontoso.com` is used to initialize Kerberos. Enter your own user account that's a part of the managed domain:

- ```bash

- sudo kinit -V contosoadmin@AADDSCONTOSO.COM

- ```

-1. Finally, join the VM to the managed domain using the `realm join` command. Use the same user account that's a part of the managed domain that you specified in the previous `kinit` command, such as `contosoadmin@AADDSCONTOSO.COM`:

- ```bash

- sudo realm join --verbose AADDSCONTOSO.COM -U 'contosoadmin@AADDSCONTOSO.COM' --install=/

- ```

-It takes a few moments to join the VM to the managed domain. The following example output shows the VM has successfully joined to the managed domain:

-```output

-Successfully enrolled machine in realm

-```

-If your VM can't successfully complete the domain-join process, make sure that the VM's network security group allows outbound Kerberos traffic on TCP + UDP port 464 to the virtual network subnet for your managed domain.

-If you received the error *Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)*, open the file */etc/krb5.conf* and add the following code in `[libdefaults]` section and try again:

-```config

-rdns=false

-```

-## Update the SSSD configuration

-One of the packages installed in a previous step was for System Security Services Daemon (SSSD). When a user tries to sign in to a VM using domain credentials, SSSD relays the request to an authentication provider. In this scenario, SSSD uses Domain Services to authenticate the request.

-1. Open the *sssd.conf* file with an editor:

- ```bash

- sudo vi /etc/sssd/sssd.conf

- ```

-1. Comment out the line for *use_fully_qualified_names* as follows:

- ```config

- # use_fully_qualified_names = True

- ```

- When done, save and exit the *sssd.conf* file using the `:wq` command of the editor.

-1. To apply the change, restart the SSSD service:

- ```bash

- sudo systemctl restart sssd

- ```

-## Configure user account and group settings

-With the VM joined to the managed domain and configured for authentication, there are a few user configuration options to complete. These configuration changes include allowing password-based authentication, and automatically creating home directories on the local VM when domain users first sign in.

-### Allow password authentication for SSH

-By default, users can only sign in to a VM using SSH public key-based authentication. Password-based authentication fails. When you join the VM to a managed domain, those domain accounts need to use password-based authentication. Update the SSH configuration to allow password-based authentication as follows.

-1. Open the *sshd_conf* file with an editor:

- ```bash

- sudo vi /etc/ssh/sshd_config

- ```

-1. Update the line for *PasswordAuthentication* to *yes*:

- ```config

- PasswordAuthentication yes

- ```

- When done, save and exit the *sshd_conf* file using the `:wq` command of the editor.

-1. To apply the changes and let users sign in using a password, restart the SSH service:

- ```bash

- sudo systemctl restart ssh

- ```

-### Configure automatic home directory creation

-To enable automatic creation of the home directory when a user first signs in, complete the following steps:

-1. Open the `/etc/pam.d/common-session` file in an editor:

- ```bash

- sudo vi /etc/pam.d/common-session

- ```

-1. Add the following line in this file below the line `session optional pam_sss.so`:

- ```config

- session required pam_mkhomedir.so skel=/etc/skel/ umask=0077

- ```

- When done, save and exit the *common-session* file using the `:wq` command of the editor.

-### Grant the 'AAD DC Administrators' group sudo privileges

-To grant members of the *AAD DC Administrators* group administrative privileges on the Ubuntu VM, you add an entry to the */etc/sudoers*. Once added, members of the *AAD DC Administrators* group can use the `sudo` command on the Ubuntu VM.

-1. Open the *sudoers* file for editing:

- ```bash

- sudo visudo

- ```

-1. Add the following entry to the end of */etc/sudoers* file:

- ```config

- # Add 'AAD DC Administrators' group members as admins.

- %AAD\ DC\ Administrators ALL=(ALL) NOPASSWD:ALL

- ```

- When done, save and exit the editor using the `Ctrl-X` command.

-## Sign in to the VM using a domain account

-To verify that the VM has been successfully joined to the managed domain, start a new SSH connection using a domain user account. Confirm that a home directory has been created, and that group membership from the domain is applied.

-1. Create a new SSH connection from your console. Use a domain account that belongs to the managed domain using the `ssh -l` command, such as `contosoadmin@aaddscontoso.com` and then enter the address of your VM, such as *ubuntu.aaddscontoso.com*. If you use the Azure Cloud Shell, use the public IP address of the VM rather than the internal DNS name.

- ```bash

- sudo ssh -l contosoadmin@AADDSCONTOSO.com ubuntu.aaddscontoso.com

- ```

-1. When you've successfully connected to the VM, verify that the home directory was initialized correctly:

- ```bash

- sudo pwd

- ```

- You should be in the */home* directory with your own directory that matches the user account.

-1. Now check that the group memberships are being resolved correctly:

- ```bash

- sudo id

- ```

- You should see your group memberships from the managed domain.

-1. If you signed in to the VM as a member of the *AAD DC Administrators* group, check that you can correctly use the `sudo` command:

- ```bash

- sudo apt-get update

- ```

-## Next steps

-If you have problems connecting the VM to the managed domain or signing in with a domain account, see [Troubleshooting domain join issues](join-windows-vm.md#troubleshoot-domain-join-issues).

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-description: Learn how to use Azure Resource Manager templates to join a new or existing Windows Server VM to a Microsoft Entra Domain Services managed domain.

-# Join a Windows Server virtual machine to a Microsoft Entra Domain Services managed domain using a Resource Manager template

-To automate the deployment and configuration of Azure virtual machines (VMs), you can use a Resource Manager template. These templates let you create consistent deployments each time. Extensions can also be included in templates to automatically configure a VM as part of the deployment. One useful extension joins VMs to a domain, which can be used with Microsoft Entra Domain Services managed domains.

-This article shows you how to create and join a Windows Server VM to a Domain Services managed domain using Resource Manager templates. You also learn how to join an existing Windows Server VM to a Domain Services domain.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A user account that's a part of the *AAD DC Administrators* group.

-## Azure Resource Manager template overview

-Resource Manager templates let you define Azure infrastructure in code. The required resources, network connections, or configuration of VMs can all be defined in a template. These templates create consistent, reproducible deployments each time, and can be versioned as you make changes. For more information, see [Azure Resource Manager templates overview][template-overview].

-Each resource is defined in a template using JavaScript Object Notation (JSON). The following JSON example uses the *Microsoft.Compute/virtualMachines/extensions* resource type to install the Active Directory domain join extension. Parameters are used that you specify at deployment time. When the extension is deployed, the VM is joined to the specified managed domain.

-```json

- {

- "apiVersion": "2015-06-15",

- "type": "Microsoft.Compute/virtualMachines/extensions",

- "name": "[concat(parameters('dnsLabelPrefix'),'/joindomain')]",

- "location": "[parameters('location')]",

- "dependsOn": [

- "[concat('Microsoft.Compute/virtualMachines/', parameters('dnsLabelPrefix'))]"

- ],

- "properties": {

- "publisher": "Microsoft.Compute",

- "type": "JsonADDomainExtension",

- "typeHandlerVersion": "1.3",

- "autoUpgradeMinorVersion": true,

- "settings": {

- "Name": "[parameters('domainToJoin')]",

- "OUPath": "[parameters('ouPath')]",

- "User": "[concat(parameters('domainToJoin'), '\\', parameters('domainUsername'))]",

- "Restart": "true",

- "Options": "[parameters('domainJoinOptions')]"

- },

- "protectedSettings": {

- "Password": "[parameters('domainPassword')]"

- }

- }

- }

-```

-This VM extension can be deployed even if you don't create a VM in the same template. The examples in this article show both of the following approaches:

-* [Create a Windows Server VM and join to a managed domain](#create-a-windows-server-vm-and-join-to-a-managed-domain)

-* [Join an existing Windows Server VM to a managed domain](#join-an-existing-windows-server-vm-to-a-managed-domain)

-## Create a Windows Server VM and join to a managed domain

-If you need a Windows Server VM, you can create and configure one using a Resource Manager template. When the VM is deployed, an extension is then installed to join the VM to a managed domain. If you already have a VM you wish to join to a managed domain, skip to [Join an existing Windows Server VM to a managed domain](#join-an-existing-windows-server-vm-to-a-managed-domain).

-To create a Windows Server VM then join it to a managed domain, complete the following steps:

-1. Browse to the [quickstart template](https://azure.microsoft.com/resources/templates/vm-domain-join/). Select the option to **Deploy to Azure**.

-1. On the **Custom deployment** page, enter the following information to create and join a Windows Server VM to the managed domain:

- | Setting | Value |

- ||-|

- | Subscription | Pick the same Azure subscription in which you have enabled Microsoft Entra Domain Services. |

- | Resource group | Choose the resource group for your VM. |

- | Location | Select the location of for your VM. |

- | Existing VNET Name | The name of the existing virtual network to connect the VM to, such as *myVnet*. |

- | Existing Subnet Name | The name of the existing virtual network subnet, such as *Workloads*. |

- | DNS Label Prefix | Enter a DNS name to use for the VM, such as *myvm*. |

- | VM size | Specify a VM size, such as *Standard_DS2_v2*. |

- | Domain To Join | The managed domain DNS name, such as *aaddscontoso.com*. |

- | Domain Username | The user account in the managed domain that should be used to join the VM to the managed domain, such as `contosoadmin@aaddscontoso.com`. This account must be a part of the managed domain. |

- | Domain Password | The password for the user account specified in the previous setting. |

- | Optional OU Path | The custom OU in which to add the VM. If you don't specify a value for this parameter, the VM is added to the default *Microsoft Entra DC Computers* OU. |

- | VM Admin Username | Specify a local administrator account to create on the VM. |

- | VM Admin Password | Specify a local administrator password for the VM. Create a strong local administrator password to protect against password brute-force attacks. |

-1. Review the terms and conditions, then check the box for **I agree to the terms and conditions stated above**. When ready, select **Purchase** to create and join the VM to the managed domain.

-> [!WARNING]

-> **Handle passwords with caution.**

-> The template parameter file requests the password for a user account that's a part of the managed domain. Don't manually enter values into this file and leave it accessible on file shares or other shared locations.

-It takes a few minutes for the deployment to complete successfully. When finished, the Windows VM is created and joined to the managed domain. The VM can be managed or signed into using domain accounts.

-## Join an existing Windows Server VM to a managed domain

-If you have an existing VM, or group of VMs, that you wish to join to a managed domain, you can use a Resource Manager template to just deploy the VM extension.

-To join an existing Windows Server VM to a managed domain, complete the following steps:

-1. Browse to the [quickstart template](https://azure.microsoft.com/resources/templates/vm-domain-join-existing/). Select the option to **Deploy to Azure**.

-1. On the **Custom deployment** page, enter the following information to join the VM to the managed domain:

- | Setting | Value |

- ||-|

- | Subscription | Pick the same Azure subscription in which you have enabled Microsoft Entra Domain Services. |

- | Resource group | Choose the resource group with your existing VM. |

- | Location | Select the location of your existing VM. |

- | VM list | Enter the comma-separated list of the existing VM(s) to join to the managed domain, such as *myVM1,myVM2*. |

- | Domain Join User Name | The user account in the managed domain that should be used to join the VM to the managed domain, such as `contosoadmin@aaddscontoso.com`. This account must be a part of the managed domain. |

- | Domain Join User Password | The password for the user account specified in the previous setting. |

- | Optional OU Path | The custom OU in which to add the VM. If you don't specify a value for this parameter, the VM is added to the default *Microsoft Entra DC Computers* OU. |

-1. Review the terms and conditions, then check the box for **I agree to the terms and conditions stated above**. When ready, select **Purchase** to join the VM to the managed domain.

-> [!WARNING]

-> **Handle passwords with caution.**

-> The template parameter file requests the password for a user account that's a part of the managed domain. Don't manually enter values into this file and leave it accessible on file shares or other shared locations.

-It takes a few moments for the deployment to complete successfully. When finished, the specified Windows VMs are joined to the managed domain and can be managed or signed into using domain accounts.

-## Next steps

-In this article, you used the Azure portal to configure and deploy resources using templates. You can also deploy resources with Resource Manager templates using [Azure PowerShell][deploy-powershell] or the [Azure CLI][deploy-cli].

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[template-overview]: /azure/azure-resource-manager/templates/overview

-[deploy-powershell]: /azure/azure-resource-manager/templates/deploy-powershell

-[deploy-cli]: /azure/azure-resource-manager/templates/deploy-cli

-description: In this tutorial, learn how to join a Windows Server virtual machine to a Microsoft Entra Domain Services managed domain.

-#Customer intent: As an server administrator, I want to learn how to join a Windows Server VM to a Microsoft Entra Domain Services managed domain to provide centralized identity and policy.

-# Tutorial: Join a Windows Server virtual machine to a Microsoft Entra Domain Services managed domain

-Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory. With a Domain Services managed domain, you can provide domain join features and management to virtual machines (VMs) in Azure. This tutorial shows you how to create a Windows Server VM then join it to a managed domain.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Create a Windows Server VM

-> * Connect the Windows Server VM to an Azure virtual network

-> * Join the VM to the managed domain

-If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-## Prerequisites

-To complete this tutorial, you need the following resources:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A user account that's a part of the managed domain.

- * Make sure that Microsoft Entra Connect password hash synchronization or self-service password reset has been performed so the account is able to sign in to managed domain.

-* An Azure Bastion host deployed in your Domain Services virtual network.

- * If needed, [create an Azure Bastion host][azure-bastion].

-If you already have a VM that you want to domain-join, skip to the section to [join the VM to the managed domain](#join-the-vm-to-the-managed-domain).

-## Sign in to the Microsoft Entra admin center

-In this tutorial, you create a Windows Server VM to join to your managed domain using the Microsoft Entra admin center. To get started, first sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).

-## Create a Windows Server virtual machine

-To see how to join a computer to a managed domain, let's create a Windows Server VM. This VM is connected to an Azure virtual network that provides connectivity to the managed domain. The process to join a managed domain is the same as joining a regular on-premises Active Directory Domain Services domain.

-If you already have a VM that you want to domain-join, skip to the section to [join the VM to the managed domain](#join-the-vm-to-the-managed-domain).

-1. From the Microsoft Entra admin center menu or from the **Home** page, select **Create a resource**.

-1. From **Get started**, choose **Windows Server 2016 Datacenter**.

- 

-1. In the **Basics** window, configure the core settings for the virtual machine. Leave the defaults for *Availability options*, *Image*, and *Size*.

- | Parameter | Suggested value |

- |-|-|

- | Resource group | Select or create a resource group, such as *myResourceGroup* |

- | Virtual machine name | Enter a name for the VM, such as *myVM* |

- | Region | Choose the region to create your VM in, such as *East US* |

- | Username | Enter a username for the local administrator account to create on the VM, such as *azureuser* |

- | Password | Enter, and then confirm, a secure password for the local administrator to create on the VM. Don't specify a domain user account's credentials. [Windows LAPS](/windows-server/identity/laps/laps-overview) isn't supported. |

-1. By default, VMs created in Azure are accessible from the Internet using RDP. When RDP is enabled, automated sign-in attacks are likely to occur, which may disable accounts with common names such as *admin* or *administrator* due to multiple failed successive sign-in attempts.

- RDP should only be enabled when required, and limited to a set of authorized IP ranges. This configuration helps improve the security of the VM and reduces the area for potential attack. Or, create and use an Azure Bastion host that allows access only through the Microsoft Entra admin center over TLS. In the next step of this tutorial, you use an Azure Bastion host to securely connect to the VM.

- Under **Public inbound ports**, select *None*.

-1. When done, select **Next: Disks**.

-1. From the drop-down menu for **OS disk type**, choose *Standard SSD*, then select **Next: Networking**.

-1. Your VM must connect to an Azure virtual network subnet that can communicate with the subnet your managed domain is deployed into. We recommend that a managed domain is deployed into its own dedicated subnet. Don't deploy your VM in the same subnet as your managed domain.

- There are two main ways to deploy your VM and connect to an appropriate virtual network subnet:

-

- * Create a, or select an existing, subnet in the same the virtual network as your managed domain is deployed.

- * Select a subnet in an Azure virtual network that is connected to it using [Azure virtual network peering][vnet-peering].

-

- If you select a virtual network subnet that isn't connected to the subnet for your managed domain, you can't join the VM to the managed domain. For this tutorial, let's create a new subnet in the Azure virtual network.

- In the **Networking** pane, select the virtual network in which your managed domain is deployed, such as *aaads-vnet*

-1. In this example, the existing *aaads-subnet* is shown that the managed domain is connected to. Don't connect your VM to this subnet. To create a subnet for the VM, select **Manage subnet configuration**.

- 

-1. In the left-hand menu of the virtual network window, select **Address space**. The virtual network is created with a single address space of *10.0.2.0/24*, which is used by the default subnet. Other subnets, such as for *workloads* or Azure Bastion may also already exist.

- Add an additional IP address range to the virtual network. The size of this address range and the actual IP address range to use depends on other network resources already deployed. The IP address range shouldn't overlap with any existing address ranges in your Azure or on-premises environment. Make sure that you size the IP address range large enough for the number of VMs you expect to deploy into the subnet.

- In the following example, an additional IP address range of *10.0.5.0/24* is added. When ready, select **Save**.

- 

-1. Next, in the left-hand menu of the virtual network window, select **Subnets**, then choose **+ Subnet** to add a subnet.

-1. Select **+ Subnet**, then enter a name for the subnet, such as *management*. Provide an **Address range (CIDR block)**, such as *10.0.5.0/24*. Make sure that this IP address range doesn't overlap with any other existing Azure or on-premises address ranges. Leave the other options as their default values, then select **OK**.

- 

-1. It takes a few seconds to create the subnet. Once it's created, select the *X* to close the subnet window.

-1. Back in the **Networking** pane to create a VM, choose the subnet you created from the drop-down menu, such as *management*. Again, make sure you choose the correct subnet and don't deploy your VM in the same subnet as your managed domain.

-1. For **Public IP**, select *None* from the drop-down menu. As you use Azure Bastion in this tutorial to connect to the management, you don't need a public IP address assigned to the VM.

-1. Leave the other options as their default values, then select **Management**.

-1. Set **Boot diagnostics** to *Off*. Leave the other options as their default values, then select **Review + create**.

-1. Review the VM settings, then select **Create**.

-It takes a few minutes to create the VM. The Microsoft Entra admin center shows the status of the deployment. Once the VM is ready, select **Go to resource**.

-

-## Connect to the Windows Server VM

-To securely connect to your VMs, use an Azure Bastion host. With Azure Bastion, a managed host is deployed into your virtual network and provides web-based RDP or SSH connections to VMs. No public IP addresses are required for the VMs, and you don't need to open network security group rules for external remote traffic. You connect to VMs using the Microsoft Entra admin center from your web browser. If needed, [create an Azure Bastion host][azure-bastion].

-To use a Bastion host to connect to your VM, complete the following steps:

-1. In the **Overview** pane for your VM, select **Connect**, then **Bastion**.

- 

-1. Enter the credentials for your VM that you specified in the previous section, then select **Connect**.

- 

-If needed, allow your web browser to open pop-ups for the Bastion connection to be displayed. It takes a few seconds to make the connection to your VM.

-## Join the VM to the managed domain

-With the VM created and a web-based RDP connection established using Azure Bastion, now let's join the Windows Server virtual machine to the managed domain. This process is the same as a computer connecting to a regular on-premises Active Directory Domain Services domain.

-1. If **Server Manager** doesn't open by default when you sign in to the VM, select the **Start** menu, then choose **Server Manager**.

-1. In the left pane of the **Server Manager** window, select **Local Server**. Under **Properties** on the right pane, choose **Workgroup**.

- 

-1. In the **System Properties** window, select **Change** to join the managed domain.

- 

-1. In the **Domain** box, specify the name of your managed domain, such as *aaddscontoso.com*, then select **OK**.

- 

-1. Enter domain credentials to join the domain. Provide credentials for a user that's a part of the managed domain. The account must be part of the managed domain or Microsoft Entra tenant - accounts from external directories associated with your Microsoft Entra tenant can't correctly authenticate during the domain-join process.

- Account credentials can be specified in one of the following ways:

- * **UPN format** (recommended) - Enter the user principal name (UPN) suffix for the user account, as configured in Microsoft Entra ID. For example, the UPN suffix of the user *contosoadmin* would be `contosoadmin@aaddscontoso.onmicrosoft.com`. There are a couple of common use-cases where the UPN format can be used reliably to sign in to the domain rather than the *SAMAccountName* format:

- * If a user's UPN prefix is long, such as *deehasareallylongname*, the *SAMAccountName* may be autogenerated.

- * If multiple users have the same UPN prefix in your Microsoft Entra tenant, such as *dee*, their *SAMAccountName* format might be autogenerated.

- * **SAMAccountName format** - Enter the account name in the *SAMAccountName* format. For example, the *SAMAccountName* of user *contosoadmin* would be `AADDSCONTOSO\contosoadmin`.

-1. It takes a few seconds to join to the managed domain. When complete, the following message welcomes you to the domain:

- 

- Select **OK** to continue.

-1. To complete the process to join to the managed domain, restart the VM.

-> [!TIP]

-> You can domain-join a VM using PowerShell with the [Add-Computer][add-computer] cmdlet. The following example joins the *AADDSCONTOSO* domain and then restarts the VM. When prompted, enter the credentials for a user that's a part of the managed domain:

->

-> `Add-Computer -DomainName AADDSCONTOSO -Restart`

->

-> To domain-join a VM without connecting to it and manually configuring the connection, you can use the [Set-AzVmAdDomainExtension][set-azvmaddomainextension] Azure PowerShell cmdlet.

-Once the Windows Server VM has restarted, any policies applied in the managed domain are pushed to the VM. You can also now sign in to the Windows Server VM using appropriate domain credentials.

-## Clean up resources

-In the next tutorial, you use this Windows Server VM to install the management tools that let you administer the managed domain. If you don't want to continue in this tutorial series, review the following clean up steps to [delete the VM](#delete-the-vm). Otherwise, [continue to the next tutorial](#next-steps).

-### Unjoin the VM from the managed domain

-To remove the VM from the managed domain, follow through the steps again to [join the VM to a domain](#join-the-vm-to-the-managed-domain). Instead of joining the managed domain, choose to join a workgroup, such as the default *WORKGROUP*. After the VM has rebooted, the computer object is removed from the managed domain.

-If you [delete the VM](#delete-the-vm) without unjoining from the domain, an orphaned computer object is left in Domain Services.

-### Delete the VM

-If you're not going use this Windows Server VM, delete the VM using the following steps:

-1. From the left-hand menu, select **Resource groups**

-1. Choose your resource group, such as *myResourceGroup*.

-1. Choose your VM, such as *myVM*, then select **Delete**. Select **Yes** to confirm the resource deletion. It takes a few minutes to delete the VM.

-1. When the VM is deleted, select the OS disk, network interface card, and any other resources with the *myVM-* prefix and delete them.

-## Troubleshoot domain-join issues

-The Windows Server VM should successfully join to the managed domain, the same way as a regular on-premises computer would join an Active Directory Domain Services domain. If the Windows Server VM can't join the managed domain, that indicates there's a connectivity or credentials-related issue. Review the following troubleshooting sections to successfully join the managed domain.

-### Connectivity issues

-If you don't receive a prompt that asks for credentials to join the domain, there's a connectivity problem. The VM can't reach the managed domain on the virtual network.

-After trying each of these troubleshooting steps, try to join the Windows Server VM to the managed domain again.

-* Verify the VM is connected to the same virtual network that Domain Services is enabled in, or has a peered network connection.

-* Try to ping the DNS domain name of the managed domain, such as `ping aaddscontoso.com`.

- * If the ping request fails, try to ping the IP addresses for the managed domain, such as `ping 10.0.0.4`. The IP address for your environment is displayed on the *Properties* page when you select the managed domain from your list of Azure resources.

- * If you can ping the IP address but not the domain, DNS may be incorrectly configured. Confirm that the IP addresses of the managed domain are configured as DNS servers for the virtual network.

-* Try to flush the DNS resolver cache on the virtual machine using the `ipconfig /flushdns` command.

-### Credentials-related issues

-If you receive a prompt that asks for credentials to join the domain, but then an error after you enter those credentials, the VM is able to connect to the managed domain. The credentials you provided don't then let the VM join the managed domain.

-After trying each of these troubleshooting steps, try to join the Windows Server VM to the managed domain again.

-* Make sure that the user account you specify belongs to the managed domain.

-* Confirm that the account is part of the managed domain or Microsoft Entra tenant. Accounts from external directories associated with your Microsoft Entra tenant can't correctly authenticate during the domain-join process.

-* Try using the UPN format to specify credentials, such as `contosoadmin@aaddscontoso.onmicrosoft.com`. If there are many users with the same UPN prefix in your tenant or if your UPN prefix is overly long, the *SAMAccountName* for your account may be autogenerated. In these cases, the *SAMAccountName* format for your account may be different from what you expect or use in your on-premises domain.

-* Check that you have [enabled password synchronization][password-sync] to your managed domain. Without this configuration step, the required password hashes won't be present in the managed domain to correctly authenticate your sign-in attempt.

-* Wait for password synchronization to be completed. When a user account's password is changed, an automatic background synchronization from Microsoft Entra ID updates the password in Domain Services. It takes some time for the password to be available for domain-join use.

-## Next steps

-In this tutorial, you learned how to:

-> [!div class="checklist"]

-> * Create a Windows Server VM

-> * Connect to the Windows Server VM to an Azure virtual network

-> * Join the VM to the managed domain

-To administer your managed domain, configure a management VM using the Active Directory Administrative Center (ADAC).

-> [!div class="nextstepaction"]

-> [Install administration tools on a management VM](tutorial-create-management-vm.md)

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[vnet-peering]: /azure/virtual-network/virtual-network-peering-overview

-[password-sync]: ./tutorial-create-instance.md

-[add-computer]: /powershell/module/microsoft.powershell.management/add-computer

-[azure-bastion]: /azure/bastion/tutorial-create-host-portal

-[set-azvmaddomainextension]: /powershell/module/az.compute/set-azvmaddomainextension

-description: Learn how to install the DNS Server Tools to manage DNS and create conditional forwarders for a Microsoft Entra Domain Services managed domain.

-# Administer DNS and create conditional forwarders in a Microsoft Entra Domain Services managed domain

-Microsoft Entra Domain Services includes a Domain Name System (DNS) server that provides name resolution for the managed domain. This DNS server includes built-in DNS records and updates for the key components that allow the service to run.

-As you run your own applications and services, you may need to create DNS records for machines that aren't joined to the domain, configure virtual IP addresses for load balancers, or set up external DNS forwarders. Users who belong to the *AAD DC Administrators* group are granted DNS administration privileges on the Domain Services managed domain and can create and edit custom DNS records.

-In a hybrid environment, DNS zones and records configured in other DNS namespaces, such as an on-premises AD DS environment, aren't synchronized to the managed domain. To resolve named resources in other DNS namespaces, create and use conditional forwarders that point to existing DNS servers in your environment.

-This article shows you how to install the DNS Server tools then use the DNS console to manage records and create conditional forwarders in Domain Services.

->[!NOTE]

->Creating or changing root hints or server-level DNS forwarders is not supported and will cause issues for the Domain Services managed domain.

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* Connectivity from your Domain Services virtual network to where your other DNS namespaces are hosted.

- * This connectivity can be provided with an [Azure ExpressRoute][expressroute] or [Azure VPN Gateway][vpn-gateway] connection.

-* A Windows Server management VM that is joined to the managed domain.

- * If needed, complete the tutorial to [create a Windows Server VM and join it to a managed domain][create-join-windows-vm].

-* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

-## Install DNS Server tools

-To create and modify DNS records in a managed domain, you need to install the DNS Server tools. These tools can be installed as a feature in Windows Server. For more information on how to install the administrative tools on a Windows client, see install [Remote Server Administration Tools (RSAT)][install-rsat].

-1. Sign in to your management VM. For steps on how to connect using the Microsoft Entra admin center, see [Connect to a Windows Server VM][connect-windows-server-vm].

-1. If **Server Manager** doesn't open by default when you sign in to the VM, select the **Start** menu, then choose **Server Manager**.

-1. In the *Dashboard* pane of the **Server Manager** window, select **Add Roles and Features**.

-1. On the **Before You Begin** page of the *Add Roles and Features Wizard*, select **Next**.

-1. For the *Installation Type*, leave the **Role-based or feature-based installation** option checked and select **Next**.

-1. On the **Server Selection** page, choose the current VM from the server pool, such as *myvm.aaddscontoso.com*, then select **Next**.

-1. On the **Server Roles** page, click **Next**.

-1. On the **Features** page, expand the **Remote Server Administration Tools** node, then expand the **Role Administration Tools** node. Select **DNS Server Tools** feature from the list of role administration tools.

- 

-1. On the **Confirmation** page, select **Install**. It may take a minute or two to install the DNS Server Tools.

-1. When feature installation is complete, select **Close** to exit the **Add Roles and Features** wizard.

-## Open the DNS management console to administer DNS

-With the DNS Server tools installed, you can administer DNS records on the managed domain.

-> [!NOTE]

-> To administer DNS in a managed domain, you must be signed in to a user account that's a member of the *AAD DC Administrators* group.

-1. From the Start screen, select **Administrative Tools**. A list of available management tools is shown, including **DNS** installed in the previous section. Select **DNS** to launch the DNS Management console.

-1. In the **Connect to DNS Server** dialog, select **The following computer**, then enter the DNS domain name of the managed domain, such as *aaddscontoso.com*:

- 

-1. The DNS Console connects to the specified managed domain. Expand the **Forward Lookup Zones** or **Reverse Lookup Zones** to create your required DNS entries or edit existing records as needed.

- 

-> [!WARNING]

-> When you manage records using the DNS Server tools, make sure that you don't delete or modify the built-in DNS records that are used by Domain Services. Built-in DNS records include domain DNS records, name server records, and other records used for DC location. If you modify these records, domain services are disrupted on the virtual network.

-## Create conditional forwarders

-A Domain Services DNS zone should only contain the zone and records for the managed domain itself. Don't create additional zones in the managed domain to resolve named resources in other DNS namespaces. Instead, use conditional forwarders in the managed domain to tell the DNS server where to go in order to resolve addresses for those resources.

-A conditional forwarder is a configuration option in a DNS server that lets you define a DNS domain, such as *contoso.com*, to forward queries to. Instead of the local DNS server trying to resolve queries for records in that domain, DNS queries are forwarded to the configured DNS for that domain. This configuration makes sure that the correct DNS records are returned, as you don't create a local a DNS zone with duplicate records in the managed domain to reflect those resources.

-To create a conditional forwarder in your managed domain, complete the following steps:

-1. Select your DNS zone, such as *aaddscontoso.com*.

-1. Select **Conditional Forwarders**, then right-select and choose **New Conditional Forwarder...**

-1. Enter your other **DNS Domain**, such as *contoso.com*, then enter the IP addresses of the DNS servers for that namespace, as shown in the following example:

- 

-1. Check the box for **Store this conditional forwarder in Active Directory, and replicate it as follows**, then select the option for *All DNS servers in this domain*, as shown in the following example:

- 

- > [!IMPORTANT]

- > If the conditional forwarder is stored in the *forest* instead of the *domain*, the conditional forwarder fails.

-1. To create the conditional forwarder, select **OK**.

-Name resolution of the resources in other namespaces from VMs connected to the managed domain should now resolve correctly. Queries for the DNS domain configured in the conditional forwarder are passed to the relevant DNS servers.

-## Next steps

-For more information about managing DNS, see the [DNS tools article on Technet](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753579(v=ws.11)).

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[expressroute]: /azure/expressroute/expressroute-introduction

-[vpn-gateway]: /azure/vpn-gateway/vpn-gateway-about-vpngateways

-[create-join-windows-vm]: join-windows-vm.md

-[tutorial-create-management-vm]: tutorial-create-management-vm.md

-[connect-windows-server-vm]: join-windows-vm.md#connect-to-the-windows-server-vm

-<!-- EXTERNAL LINKS -->

-[install-rsat]: /windows-server/remote/remote-server-administration-tools#BKMK_Thresh

-description: Learn how to edit the built-in group policy objects (GPOs) and create your own custom policies in a Microsoft Entra Domain Services managed domain.

-# Administer Group Policy in a Microsoft Entra Domain Services managed domain

-Settings for user and computer objects in Microsoft Entra Domain Services are often managed using Group Policy Objects (GPOs). Domain Services includes built-in GPOs for the *AADDC Users* and *AADDC Computers* containers. You can customize these built-in GPOs to configure Group Policy as needed for your environment. Members of the *Microsoft Entra DC administrators* group have Group Policy administration privileges in the Domain Services domain, and can also create custom GPOs and organizational units (OUs). For more information on what Group Policy is and how it works, see [Group Policy overview][group-policy-overview].

-In a hybrid environment, group policies configured in an on-premises AD DS environment aren't synchronized to Domain Services. To define configuration settings for users or computers in Domain Services, edit one of the default GPOs or create a custom GPO.

-This article shows you how to install the Group Policy Management tools, then edit the built-in GPOs and create custom GPOs.

-If you are interested in server management strategy, including machines in Azure and

-[hybrid connected](/azure/azure-arc/servers/overview),

-consider reading about the

-[guest configuration](/azure/governance/machine-configuration/overview)

-feature of

-[Azure Policy](/azure/governance/policy/overview).

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server management VM that is joined to the Domain Services managed domain.

- * If needed, complete the tutorial to [create a Windows Server VM and join it to a managed domain][create-join-windows-vm].

-* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

-> [!NOTE]

-> You can use Group Policy Administrative Templates by copying the new templates to the management workstation. Copy the *.admx* files into `%SYSTEMROOT%\PolicyDefinitions` and copy the locale-specific *.adml* files to `%SYSTEMROOT%\PolicyDefinitions\[Language-CountryRegion]`, where `Language-CountryRegion` matches the language and region of the *.adml* files.

->

-> For example, copy the English, United States version of the *.adml* files into the `\en-us` folder.

-## Install Group Policy Management tools

-To create and configure Group Policy Object (GPOs), you need to install the Group Policy Management tools. These tools can be installed as a feature in Windows Server. For more information on how to install the administrative tools on a Windows client, see install [Remote Server Administration Tools (RSAT)][install-rsat].

-1. Sign in to your management VM. For steps on how to connect using the Microsoft Entra admin center, see [Connect to a Windows Server VM][connect-windows-server-vm].

-1. **Server Manager** should open by default when you sign in to the VM. If not, on the **Start** menu, select **Server Manager**.

-1. In the *Dashboard* pane of the **Server Manager** window, select **Add Roles and Features**.

-1. On the **Before You Begin** page of the *Add Roles and Features Wizard*, select **Next**.

-1. For the *Installation Type*, leave the **Role-based or feature-based installation** option checked and select **Next**.

-1. On the **Server Selection** page, choose the current VM from the server pool, such as *myvm.aaddscontoso.com*, then select **Next**.

-1. On the **Server Roles** page, click **Next**.

-1. On the **Features** page, select the **Group Policy Management** feature.

- 

-1. On the **Confirmation** page, select **Install**. It may take a minute or two to install the Group Policy Management tools.

-1. When feature installation is complete, select **Close** to exit the **Add Roles and Features** wizard.

-## Open the Group Policy Management Console and edit an object

-Default group policy objects (GPOs) exist for users and computers in a managed domain. With the Group Policy Management feature installed from the previous section, let's view and edit an existing GPO. In the next section, you create a custom GPO.

-> [!NOTE]

-> To administer group policy in a managed domain, you must be signed in to a user account that's a member of the *AAD DC Administrators* group.

-1. From the Start screen, select **Administrative Tools**. A list of available management tools is shown, including **Group Policy Management** installed in the previous section.

-1. To open the Group Policy Management Console (GPMC), choose **Group Policy Management**.

- 

-There are two built-in Group Policy Objects (GPOs) in a managed domain - one for the *AADDC Computers* container, and one for the *AADDC Users* container. You can customize these GPOs to configure group policy as needed within your managed domain.

-1. In the **Group Policy Management** console, expand the **Forest: aaddscontoso.com** node. Next, expand the **Domains** nodes.

- Two built-in containers exist for *AADDC Computers* and *AADDC Users*. Each of these containers has a default GPO applied to them.

- 

-1. These built-in GPOs can be customized to configure specific group policies on your managed domain. Right-select one of the GPOs, such as *AADDC Computers GPO*, then choose **Edit...**.

- 

-1. The Group Policy Management Editor tool opens to let you customize the GPO, such as *Account Policies*:

- 

- When done, choose **File > Save** to save the policy. Computers refresh Group Policy by default every 90 minutes and apply the changes you made.

-## Create a custom Group Policy Object

-To group similar policy settings, you often create additional GPOs instead of applying all of the required settings in the single, default GPO. With Domain Services, you can create or import your own custom group policy objects and link them to a custom OU. If you need to first create a custom OU, see [create a custom OU in a managed domain](create-ou.md).

-1. In the **Group Policy Management** console, select your custom organizational unit (OU), such as *MyCustomOU*. Right-select the OU and choose **Create a GPO in this domain, and Link it here...**:

- 

-1. Specify a name for the new GPO, such as *My custom GPO*, then select **OK**. You can optionally base this custom GPO on an existing GPO and set of policy options.

- 

-1. The custom GPO is created and linked to your custom OU. To now configure the policy settings, right-select the custom GPO and choose **Edit...**:

- 

-1. The **Group Policy Management Editor** opens to let you customize the GPO:

- 

- When done, choose **File > Save** to save the policy. Computers refresh Group Policy by default every 90 minutes and apply the changes you made.

-## Next steps

-For more information on the available Group Policy settings that you can configure using the Group Policy Management Console, see [Work with Group Policy preference items][group-policy-console].

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[create-join-windows-vm]: join-windows-vm.md

-[tutorial-create-management-vm]: tutorial-create-management-vm.md

-[connect-windows-server-vm]: join-windows-vm.md#connect-to-the-windows-server-vm

-<!-- EXTERNAL LINKS -->

-[group-policy-overview]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831791(v=ws.11)

-[install-rsat]: /windows-server/remote/remote-server-administration-tools#BKMK_Thresh

-[group-policy-console]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn789194(v=ws.11)

-description: Learn what a mismatched directory error means and how to resolve it in Microsoft Entra Domain Services

-# Resolve mismatched directory errors for existing Microsoft Entra Domain Services managed domains

-If a Microsoft Entra Domain Services managed domain shows a mismatched tenant error, you can't administer the managed domain until resolved. This error occurs if the underlying Azure virtual network is moved to a different Microsoft Entra directory.

-This article explains why the error occurs and how to resolve it.

-## What causes this error?

-A mismatched directory error happens when a Domain Services managed domain and virtual network belong to two different Microsoft Entra tenants. For example, you may have a managed domain called *aaddscontoso.com* that runs in Contoso's Microsoft Entra tenant. However, the Azure virtual network for managed domain is part of the Fabrikam Microsoft Entra tenant.

-Azure role-based access control (Azure RBAC) is used to limit access to resources. When you enable Domain Services in a Microsoft Entra tenant, credential hashes are synchronized to the managed domain. This operation requires you to be a tenant admin for the Microsoft Entra directory, and access to the credentials must be controlled.

-To deploy resources to an Azure virtual network and control traffic, you must have administrative privileges on the virtual network in which you deploy the managed domain.

-For Azure RBAC to work consistently and secure access to all the resources Domain Services uses, the managed domain and the virtual network must belong to the same Microsoft Entra tenant.

-The following rules apply for deployments:

-### Valid configuration

-In the following example deployment scenario, the Contoso managed domain is enabled in the Contoso Microsoft Entra tenant. The managed domain is deployed in a virtual network that belongs to an Azure subscription owned by the Contoso Microsoft Entra tenant.

-Both the managed domain and the virtual network belong to the same Microsoft Entra tenant. This example configuration is valid and fully supported.

-

-### Mismatched tenant configuration

-In this example deployment scenario, the Contoso managed domain is enabled in the Contoso Microsoft Entra tenant. However, the managed domain is deployed in a virtual network that belongs to an Azure subscription owned by the Fabrikam Microsoft Entra tenant.

-The managed domain and the virtual network belong to two different Microsoft Entra tenants. This example configuration is a mismatched tenant and isn't supported. The virtual network must be moved to the same Microsoft Entra tenant as the managed domain.

-

-## Resolve mismatched tenant error

-The following two options resolve the mismatched directory error:

-* First, [delete the managed domain](delete-aadds.md) from your existing Microsoft Entra directory. Then, [create a replacement managed domain](tutorial-create-instance.md) in the same Microsoft Entra directory as the virtual network you wish to use. When ready, join all machines previously joined to the deleted domain to the recreated managed domain.

-* [Move the Azure subscription](/azure/cost-management-billing/manage/billing-subscription-transfer) containing the virtual network to the same Microsoft Entra directory as the managed domain.

-## Next steps

-For more information on troubleshooting issues with Domain Services, see the [troubleshooting guide](troubleshoot.md).

-description: Learn about some of the virtual network design considerations and resources used for connectivity when you run Microsoft Entra Domain Services.

-# Virtual network design considerations and configuration options for Microsoft Entra Domain Services

-Microsoft Entra Domain Services provides authentication and management services to other applications and workloads. Network connectivity is a key component. Without correctly configured virtual network resources, applications and workloads can't communicate with and use the features provided by Domain Services. Plan your virtual network requirements to make sure that Domain Services can serve your applications and workloads as needed.

-This article outlines design considerations and requirements for an Azure virtual network to support Domain Services.

-## Azure virtual network design

-To provide network connectivity and allow applications and services to authenticate against a Domain Services managed domain, you use an Azure virtual network and subnet. Ideally, the managed domain should be deployed into its own virtual network.

-You can include a separate application subnet in the same virtual network to host your management VM or light application workloads. A separate virtual network for larger or complex application workloads, peered to the Domain Services virtual network, is usually the most appropriate design.

-Other designs choices are valid, provided you meet the requirements outlined in the following sections for the virtual network and subnet.

-As you design the virtual network for Domain Services, the following considerations apply:

-* Domain Services must be deployed into the same Azure region as your virtual network.

- * At this time, you can only deploy one managed domain per Microsoft Entra tenant. The managed domain is deployed to single region. Make sure that you create or select a virtual network in a [region that supports Domain Services](https://azure.microsoft.com/global-infrastructure/services/?products=active-directory-ds&regions=all).

-* Consider the proximity of other Azure regions and the virtual networks that host your application workloads.

- * To minimize latency, keep your core applications close to, or in the same region as, the virtual network subnet for your managed domain. You can use virtual network peering or virtual private network (VPN) connections between Azure virtual networks. These connection options are discussed in a following section.

-* The virtual network can't rely on DNS services other than those services provided by the managed domain.

- * Domain Services provides its own DNS service. The virtual network must be configured to use these DNS service addresses. Name resolution for additional namespaces can be accomplished using conditional forwarders.

- * You can't use custom DNS server settings to direct queries from other DNS servers, including on VMs. Resources in the virtual network must use the DNS service provided by the managed domain.

-> [!IMPORTANT]

-> You can't move Domain Services to a different virtual network after you've enabled the service.

-A managed domain connects to a subnet in an Azure virtual network. Design this subnet for Domain Services with the following considerations:

-* A managed domain must be deployed in its own subnet. Using an existing subnet, gateway subnet, or remote gateways settings in the virtual network peering is unsupported.

-* A network security group is created during the deployment of a managed domain. This network security group contains the required rules for correct service communication.

- * Don't create or use an existing network security group with your own custom rules.

-* A managed domain requires 3-5 IP addresses. Make sure that your subnet IP address range can provide this number of addresses.

- * Restricting the available IP addresses can prevent the managed domain from maintaining two domain controllers.

- >[!NOTE]

- >You shouldn't use public IP addresses for virtual networks and their subnets due to the following issues:

- >

- >- **Scarcity of the IP address**: IPv4 public IP addresses are limited, and their demand often exceeds the available supply. Also, there are potentially overlapping IPs with public endpoints.

- >- **Security risks**: Using public IPs for virtual networks exposes your devices directly to the internet, increasing the risk of unauthorized access and potential attacks. Without proper security measures, your devices may become vulnerable to various threats.

- >

- >- **Complexity**: Managing a virtual network with public IPs can be more complex than using private IPs, as it requires dealing with external IP ranges and ensuring proper network segmentation and security.

- >

- >It is strongly recommended to use private IP addresses. If you use a public IP, ensure you are the owner/dedicated user of the chosen IPs in the public range you chose.

-The following example diagram outlines a valid design where the managed domain has its own subnet, there's a gateway subnet for external connectivity, and application workloads are in a connected subnet within the virtual network:

-

-<a name='connections-to-the-azure-ad-ds-virtual-network'></a>

-## Connections to the Domain Services virtual network

-As noted in the previous section, you can only create a managed domain in a single virtual network in Azure, and only one managed domain can be created per Microsoft Entra tenant. Based on this architecture, you may need to connect one or more virtual networks that host your application workloads to your managed domain's virtual network.

-You can connect application workloads hosted in other Azure virtual networks using one of the following methods:

-* Virtual network peering

-* Virtual private networking (VPN)

-### Virtual network peering

-Virtual network peering is a mechanism that connects two virtual networks in the same region through the Azure backbone network. Global virtual network peering can connect virtual network across Azure regions. Once peered, the two virtual networks let resources, such as VMs, communicate with each other directly using private IP addresses. Using virtual network peering lets you deploy a managed domain with your application workloads deployed in other virtual networks.

-

-For more information, see [Azure virtual network peering overview](/azure/virtual-network/virtual-network-peering-overview).

-### Virtual Private Networking (VPN)

-You can connect a virtual network to another virtual network (VNet-to-VNet) in the same way that you can configure a virtual network to an on-premises site location. Both connections use a VPN gateway to create a secure tunnel using IPsec/IKE. This connection model lets you deploy the managed domain into an Azure virtual network and then connect on-premises locations or other clouds.

-

-For more information on using virtual private networking, read [Configure a VNet-to-VNet VPN gateway connection by using the Microsoft Entra admin center](/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal).

-## Name resolution when connecting virtual networks

-Virtual networks connected to the managed domain's virtual network typically have their own DNS settings. When you connect virtual networks, it doesn't automatically configure name resolution for the connecting virtual network to resolve services provided by the managed domain. Name resolution on the connecting virtual networks must be configured to enable application workloads to locate the managed domain.

-You can enable name resolution using conditional DNS forwarders on the DNS server supporting the connecting virtual networks, or by using the same DNS IP addresses from the managed domain's virtual network.

-<a name='network-resources-used-by-azure-ad-ds'></a>

-## Network resources used by Domain Services

-A managed domain creates some networking resources during deployment. These resources are needed for successful operation and management of the managed domain, and shouldn't be manually configured.

-Don't lock the networking resources used by Domain Services. If networking resources get locked, they can't be deleted. When domain controllers need to be rebuilt in that case, new networking resources with different IP addresses need to be created.

-| Azure resource | Description |

-|:-|:|

-| Network interface card | Domain Services hosts the managed domain on two domain controllers (DCs) that run on Windows Server as Azure VMs. Each VM has a virtual network interface that connects to your virtual network subnet. |

-| Dynamic standard public IP address | Domain Services communicates with the synchronization and management service using a Standard SKU public IP address. For more information about public IP addresses, see [IP address types and allocation methods in Azure](/azure/virtual-network/ip-services/public-ip-addresses). |

-| Azure standard load balancer | Domain Services uses a Standard SKU load balancer for network address translation (NAT) and load balancing (when used with secure LDAP). For more information about Azure load balancers, see [What is Azure Load Balancer?](/azure/load-balancer/load-balancer-overview) |

-| Network address translation (NAT) rules | Domain Services creates and uses two Inbound NAT rules on the load balancer for secure PowerShell remoting. If a Standard SKU load balancer is used, it will have an Outbound NAT Rule too. For the Basic SKU load balancer, no Outbound NAT rule is required. |

-| Load balancer rules | When a managed domain is configured for secure LDAP on TCP port 636, three rules are created and used on a load balancer to distribute the traffic. |

-> [!WARNING]

-> Don't delete or modify any of the network resource created by Domain Services, such as manually configuring the load balancer or rules. If you delete or modify any of the network resources, a Domain Services service outage may occur.

-## Network security groups and required ports

-A [network security group (NSG)](/azure/virtual-network/network-security-groups-overview) contains a list of rules that allow or deny network traffic in an Azure virtual network. When you deploy a managed domain, a network security group is created with a set of rules that let the service provide authentication and management functions. This default network security group is associated with the virtual network subnet your managed domain is deployed into.

-The following sections cover network security groups and Inbound and Outbound port requirements.

-### Inbound connectivity

-The following network security group Inbound rules are required for the managed domain to provide authentication and management services. Don't edit or delete these network security group rules for the virtual network subnet for your managed domain.

-| Source | Source service tag | Source port ranges | Destination | Service | Destination port ranges | Protocol | Action | Required | Purpose |

-|:--:|:-:|::|:-:|:-:|:--:|:--:|::|:--:|:--|

-| Service tag | AzureActiveDirectoryDomainServices | * | Any | WinRM | 5986 | TCP | Allow | Yes | Management of your domain. |

-| Service tag | CorpNetSaw | * | Any | RDP | 3389 | TCP | Allow | Optional | Debugging for support |

-Note that the **CorpNetSaw** service tag isn't available by using the Microsoft Entra admin center, and the network security group rule for **CorpNetSaw** has to be added by using [PowerShell](powershell-create-instance.md#create-a-network-security-group).

-Domain Services also relies on the Default Security rules AllowVnetInBound and AllowAzureLoadBalancerInBound.

-The AllowVnetInBound rule allows all traffic within the VNet which allows the DCs to properly communicate and replicate as well as allow domain join and other domain services to domain members. For more information about required ports for Windows, see [Service overview and network port requirements for Windows](/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements).

-The AllowAzureLoadBalancerInBound rule is also required so that the service can properly communicate over the loadbalancer to manage the DCs. This network security group secures Domain Services and is required for the managed domain to work correctly. Don't delete this network security group. The load balancer won't work correctly without it.

-If needed, you can [create the required network security group and rules using Azure PowerShell](powershell-create-instance.md#create-a-network-security-group).

-> [!WARNING]

-> When you associate a misconfigured network security group or a user defined route table with the subnet in which the managed domain is deployed, you may disrupt Microsoft's ability to service and manage the domain. Synchronization between your Microsoft Entra tenant and your managed domain is also disrupted. Follow all listed requirements to avoid an unsupported configuration that could break sync, patching, or management.

->

-> If you use secure LDAP, you can add the required TCP port 636 rule to allow external traffic if needed. Adding this rule doesn't place your network security group rules in an unsupported state. For more information, see [Lock down secure LDAP access over the internet](tutorial-configure-ldaps.md#lock-down-secure-ldap-access-over-the-internet)

->

-> The Azure SLA doesn't apply to deployments that are blocked from updates or management by an improperly configured network security group or user defined route table. A broken network configuration can also prevent security patches from being applied.

-### Outbound connectivity

-For Outbound connectivity, you can either keep **AllowVnetOutbound** and **AllowInternetOutBound** or restrict Outbound traffic by using ServiceTags listed in the following table. The ServiceTag for AzureUpdateDelivery must be added via [PowerShell](powershell-create-instance.md). Make sure no other NSG with higher priority denies the Outbound connectivity. If Outbound connectivity is denied, replication won't work between replica sets.

-| Outbound port number | Protocol | Source | Destination | Action | Required | Purpose |

-|:--:|:--:|::|:-:|::|:--:|:-:|

-| 443 | TCP | Any | AzureActiveDirectoryDomainServices| Allow | Yes | Communication with the Microsoft Entra Domain Services management service. |

-| 443 | TCP | Any | AzureMonitor | Allow | Yes | Monitoring of the virtual machines. |

-| 443 | TCP | Any | Storage | Allow | Yes | Communication with Azure Storage. |

-| 443 | TCP | Any | Microsoft Entra ID | Allow | Yes | Communication with Microsoft Entra ID. |

-| 443 | TCP | Any | AzureUpdateDelivery | Allow | Yes | Communication with Windows Update. |

-| 80 | TCP | Any | AzureFrontDoor.FirstParty | Allow | Yes | Download of patches from Windows Update. |

-| 443 | TCP | Any | GuestAndHybridManagement | Allow | Yes | Automated management of security patches. |

-### Port 5986 - management using PowerShell remoting

-* Used to perform management tasks using PowerShell remoting in your managed domain.

-* Without access to this port, your managed domain can't be updated, configured, backed-up, or monitored.

-* You can restrict inbound access to this port to the *AzureActiveDirectoryDomainServices* service tag.

-### Port 3389 - management using remote desktop

-* Used for remote desktop connections to domain controllers in your managed domain.

-* The default network security group rule uses the *CorpNetSaw* service tag to further restrict traffic.

- * This service tag permits only secure access workstations on the Microsoft corporate network to use remote desktop to the managed domain.

- * Access is only allowed with business justification, such as for management or troubleshooting scenarios.

-* This rule can be set to *Deny*, and only set to *Allow* when required. Most management and monitoring tasks are performed using PowerShell remoting. RDP is only used in the rare event that Microsoft needs to connect remotely to your managed domain for advanced troubleshooting.

-You can't manually select the *CorpNetSaw* service tag from the portal if you try to edit this network security group rule. You must use Azure PowerShell or the Azure CLI to manually configure a rule that uses the *CorpNetSaw* service tag.

-For example, you can use the following script to create a rule allowing RDP:

-```powershell

-Get-AzNetworkSecurityGroup -Name "nsg-name" -ResourceGroupName "resource-group-name" | Add-AzNetworkSecurityRuleConfig -Name "new-rule-name" -Access "Allow" -Protocol "TCP" -Direction "Inbound" -Priority "priority-number" -SourceAddressPrefix "CorpNetSaw" -SourcePortRange "*" -DestinationPortRange "3389" -DestinationAddressPrefix "*" | Set-AzNetworkSecurityGroup

-```

-## User-defined routes

-User-defined routes aren't created by default, and aren't needed for Domain Services to work correctly. If you're required to use route tables, avoid making any changes to the *0.0.0.0* route. Changes to this route disrupt Domain Services and puts the managed domain in an unsupported state.

-You must also route inbound traffic from the IP addresses included in the respective Azure service tags to the managed domain's subnet. For more information on service tags and their associated IP address from, see [Azure IP Ranges and Service Tags - Public Cloud](https://www.microsoft.com/en-us/download/details.aspx?id=56519).

-> [!CAUTION]

-> These Azure datacenter IP ranges can change without notice. Ensure you have processes to validate you have the latest IP addresses.

-## Next steps

-For more information about some of the network resources and connection options used by Domain Services, see the following articles:

-* [Azure virtual network peering](/azure/virtual-network/virtual-network-peering-overview)

-* [Azure VPN gateways](/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings)

-* [Azure network security groups](/azure/virtual-network/network-security-groups-overview)

-description: Learn how to configure email notifications to alert you about issues in a Microsoft Entra Domain Services managed domain

-# Configure email notifications for issues in Microsoft Entra Domain Services

-The health of a Microsoft Entra Domain Services managed domain is monitored by the Azure platform. The health status page in the Microsoft Entra admin center shows any alerts for the managed domain. To make sure issues are responded to in a timely manner, email notifications can be configured to report on health alerts as soon as they're detected in the Domain Services managed domain.

-This article shows you how to configure email notification recipients for a managed domain.

-## Email notification overview

-To alert you of issues with a managed domain, you can configure email notifications. These email notifications specify the managed domain that the alert is present on, give the time of detection, and a link to the health page in the Microsoft Entra admin center. You can then follow the provided troubleshooting advice to resolve the issues.

-The following example email notification indicates a critical warning or alert was generated on the managed domain:

-

-> [!WARNING]

-> Always make sure that the email comes from a verified Microsoft sender before you click the links in the message. The email notifications always come from the `azure-noreply@microsoft.com` address.

-### Why would I receive email notifications?

-Domain Services sends email notifications for important updates about the managed domain. These notifications are only for urgent issues that impact the service and should be addressed immediately. Each email notification is triggered by an alert on the managed domain. The alerts also appear in the Microsoft Entra admin center and can be viewed on the [Domain Services health page][check-health].

-Domain Services doesn't send emails for advertisement, updates, or sales purposes.

-### When do I receive email notifications?

-A notification is sent immediately when a [new alert][troubleshoot-alerts] is found on a managed domain. If the alert isn't resolved, another email notification is sent as a reminder every four days.

-### Who should receive the email notifications?

-The list of email recipients for Domain Services should be composed of people who are able to administer and make changes to the managed domain. This email list should be thought of as your "first responders" to any alerts and issues.

-You can add up to five more recipients for email notifications. If you want more than five recipients for email notifications, create a distribution list and add that to the notification list instead.

-You can also choose to have all *Global Administrators* of the Microsoft Entra directory and every member of the *AAD DC Administrators* group receive email notifications. Domain Services only sends notification to up to 100 email addresses, including the list of global administrators and AAD DC Administrators.

-## Configure email notifications

-To review the existing email notification recipients, or add recipients, complete the following steps:

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as a [Global Administrator](/azure/active-directory/roles/permissions-reference#authentication-policy-administrator).

-1. Search for and select **Microsoft Entra Domain Services**.

-1. Select your managed domain, such as *aaddscontoso.com*.

-1. On the left-hand side of the Domain Services resource window, select **Notification settings**. The existing recipients for email notifications are shown.

-1. To add an email recipient, enter the email address in the additional recipients table.

-1. When done, select **Save** on the top-hand navigation.

-> [!WARNING]

-> When you change the notification settings, the notification settings for the entire managed domain are updated, not just yourself.

-## Frequently asked questions

-### I received an email notification for an alert but when I logged on to the Microsoft Entra admin center there was no alert. What happened?

-If an alert is resolved, the alert is cleared from the Microsoft Entra admin center. The most likely reason is that someone else who receives email notifications resolved the alert on the managed domain, or it was automatically resolved by Azure platform.

-### Why can I not edit the notification settings?

-If you're unable to access the notification settings page in the Microsoft Entra admin center, you don't have the permissions to edit the managed domain. Contact a global administrator to either get permissions to edit Domain Services resource or be removed from the recipient list.

-### I don't seem to be receiving email notifications even though I provided my email address. Why?

-Check your spam or junk folder in your email for the notification and make sure to allow the sender of `azure-noreply@microsoft.com`.

-## Next steps

-For more information on troubleshooting some of the issues that may be reported, see [Resolve alerts on a managed domain][troubleshoot-alerts].

-<!-- INTERNAL LINKS -->

-[check-health]: check-health.md

-[troubleshoot-alerts]: troubleshoot-alerts.md

-description: In this overview, learn what Microsoft Entra Domain Services provides and how to use it in your organization to provide identity services to applications and services in the cloud.

-#Customer intent: As an IT administrator or decision maker, I want to understand what Domain Services is and how it can benefit my organization.

-# What is Microsoft Entra Domain Services?

-Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos/NTLM authentication. You use these domain services without the need to deploy, manage, and patch domain controllers (DCs) in the cloud.

-A Domain Services managed domain lets you run legacy applications in the cloud that can't use modern authentication methods, or where you don't want directory lookups to always go back to an on-premises AD DS environment. You can lift and shift those legacy applications from your on-premises environment into a managed domain, without needing to manage the AD DS environment in the cloud.

-Domain Services integrates with your existing Microsoft Entra tenant. This integration lets users sign in to services and applications connected to the managed domain using their existing credentials. You can also use existing groups and user accounts to secure access to resources. These features provide a smoother lift-and-shift of on-premises resources to Azure.

-> [!div class="nextstepaction"]

-> [To get started, create a Domain Services managed domain using the Microsoft Entra admin center][tutorial-create]

-Take a look at our short video to learn more about Domain Services.

-> [!VIDEO https://www.microsoft.com/en-us/videoplayer/embed/RE4LblD]

-<a name='how-does-azure-ad-ds-work'></a>

-## How does Domain Services work?

-When you create a Domain Services managed domain, you define a unique namespace. This namespace is the domain name, such as *aaddscontoso.com*. Two Windows Server domain controllers (DCs) are then deployed into your selected Azure region. This deployment of DCs is known as a replica set.

-You don't need to manage, configure, or update these DCs. The Azure platform handles the DCs as part of the managed domain, including backups and encryption at rest using Azure Disk Encryption.

-A managed domain is configured to perform a one-way synchronization from Microsoft Entra ID to provide access to a central set of users, groups, and credentials. You can create resources directly in the managed domain, but they aren't synchronized back to Microsoft Entra ID. Applications, services, and VMs in Azure that connect to the managed domain can then use common AD DS features such as domain join, group policy, LDAP, and Kerberos/NTLM authentication.

-In a hybrid environment with an on-premises AD DS environment, [Microsoft Entra Connect][azure-ad-connect] synchronizes identity information with Microsoft Entra ID, which is then synchronized to the managed domain.

-

-Domain Services replicates identity information from Microsoft Entra ID, so it works with Microsoft Entra tenants that are cloud-only, or synchronized with an on-premises AD DS environment. The same set of Domain Services features exists for both environments.

-* If you have an existing on-premises AD DS environment, you can synchronize user account information to provide a consistent identity for users. To learn more, see [How objects and credentials are synchronized in a managed domain][synchronization].

-* For cloud-only environments, you don't need a traditional on-premises AD DS environment to use the centralized identity services of Domain Services.

-You can expand a managed domain to have more than one replica set per Microsoft Entra tenant. Replica sets can be added to any peered virtual network in any Azure region that supports Domain Services. By adding replica sets in different Azure regions, you can provide geographical disaster recovery for legacy applications if an Azure region goes offline. For more information, see [Replica sets concepts and features for managed domains][concepts-replica-sets].

-Take a look at this video about how Domain Services integrates with your applications and workloads to provide identity services in the cloud:

-<br />

->[!VIDEO https://www.youtube.com/embed/T1Nd9APNceQ]

-To see Domain Services deployment scenarios in action, you can explore the following examples:

-* [Domain Services for hybrid organizations](scenarios.md#azure-ad-ds-for-hybrid-organizations)

-* [Domain Services for cloud-only organizations](scenarios.md#azure-ad-ds-for-cloud-only-organizations)

-<a name='azure-ad-ds-features-and-benefits'></a>

-## Domain Services features and benefits

-To provide identity services to applications and VMs in the cloud, Domain Services is fully compatible with a traditional AD DS environment for operations such as domain-join, secure LDAP (LDAPS), Group Policy, DNS management, and LDAP bind and read support. LDAP write support is available for objects created in the managed domain, but not resources synchronized from Microsoft Entra ID.

-To learn more about your identity options, [compare Domain Services with Microsoft Entra ID, AD DS on Azure VMs, and AD DS on-premises][compare].

-The following features of Domain Services simplify deployment and management operations:

-* **Simplified deployment experience:** Domain Services is enabled for your Microsoft Entra tenant using a single wizard in the Microsoft Entra admin center.

-* **Integrated with Microsoft Entra ID:** User accounts, group memberships, and credentials are automatically available from your Microsoft Entra tenant. New users, groups, or changes to attributes from your Microsoft Entra tenant or your on-premises AD DS environment are automatically synchronized to Domain Services.

- * Accounts in external directories linked to your Microsoft Entra ID aren't available in Domain Services. Credentials aren't available for those external directories, so can't be synchronized into a managed domain.

-* **Use your corporate credentials/passwords:** Passwords for users in Domain Services are the same as in your Microsoft Entra tenant. Users can use their corporate credentials to domain-join machines, sign in interactively or over remote desktop, and authenticate against the managed domain.

-* **NTLM and Kerberos authentication:** With support for NTLM and Kerberos authentication, you can deploy applications that rely on Windows-integrated authentication.

-* **High availability:** Domain Services includes multiple domain controllers, which provide high availability for your managed domain. This high availability guarantees service uptime and resilience to failures.

- * In regions that support [Azure Availability Zones][availability-zones], these domain controllers are also distributed across zones for additional resiliency.

- * [Replica sets][concepts-replica-sets] can also be used to provide geographical disaster recovery for legacy applications if an Azure region goes offline.

-Some key aspects of a managed domain include the following:

-* The managed domain is a stand-alone domain. It isn't an extension of an on-premises domain.

- * If needed, you can create one-way outbound forest trusts from Domain Services to an on-premises AD DS environment. For more information, see [Forest concepts and features for Domain Services][forest-trusts].

-* Your IT team doesn't need to manage, patch, or monitor domain controllers for this managed domain.

-For hybrid environments that run AD DS on-premises, you don't need to manage AD replication to the managed domain. User accounts, group memberships, and credentials from your on-premises directory are synchronized to Microsoft Entra ID via [Microsoft Entra Connect][azure-ad-connect]. These user accounts, group memberships, and credentials are automatically available within the managed domain.

-## Next steps

-To learn more about Domain Services compares with other identity solutions and how synchronization works, see the following articles:

-* [Compare Domain Services with Microsoft Entra ID, Active Directory Domain Services on Azure VMs, and Active Directory Domain Services on-premises][compare]

-* [Learn how Microsoft Entra Domain Services synchronizes with your Microsoft Entra directory][synchronization]

-* To learn how to administrator a managed domain, see [management concepts for user accounts, passwords, and administration in Domain Services][administration-concepts].

-To get started, [create a managed domain using the Microsoft Entra admin center][tutorial-create].

-<!-- INTERNAL LINKS -->

-[compare]: compare-identity-solutions.md

-[synchronization]: synchronization.md

-[tutorial-create]: tutorial-create-instance.md

-[azure-ad-connect]: /azure/active-directory/hybrid/connect/whatis-azure-ad-connect

-[password-hash-sync]: /azure/active-directory/hybrid/connect/how-to-connect-password-hash-synchronization

-[availability-zones]: /azure/reliability/availability-zones-overview

-[forest-trusts]: ./concepts-forest-trust.md

-[administration-concepts]: administration-concepts.md

-[synchronization]: synchronization.md

-[concepts-replica-sets]: concepts-replica-sets.md

-description: Learn how and why to use fine-grained password policies to secure and control account passwords in a Domain Services managed domain.

-# Password and account lockout policies on Microsoft Entra Domain Services managed domains

-To manage user security in Microsoft Entra Domain Services, you can define fine-grained password policies that control account lockout settings or minimum password length and complexity. A default fine grained password policy is created and applied to all users in a Domain Services managed domain. To provide granular control and meet specific business or compliance needs, additional policies can be created and applied to specific users or groups.

-This article shows you how to create and configure a fine-grained password policy in Domain Services using the Active Directory Administrative Center.

-> [!NOTE]

-> Password policies are only available for managed domains created using the Resource Manager deployment model.

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

- * The managed domain must have been created using the Resource Manager deployment model.

-* A Windows Server management VM that is joined to the managed domain.

- * If needed, complete the tutorial to [create a management VM][tutorial-create-management-vm].

-* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

-## Default password policy settings

-Fine-grained password policies (FGPPs) let you apply specific restrictions for password and account lockout policies to different users in a domain. For example, to secure privileged accounts you can apply stricter account lockout settings than regular non-privileged accounts. You can create multiple FGPPs within a managed domain and specify the order of priority to apply them to users.

-For more information about password policies and using the Active Directory Administration Center, see the following articles:

-* [Learn about fine-grained password policies](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770394(v=ws.10))

-* [Configure fine-grained password policies using AD Administration Center](/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements--level-100-#fine_grained_pswd_policy_mgmt)

-Policies are distributed through group association in a managed domain, and any changes you make are applied at the next user sign-in. Changing the policy doesn't unlock a user account that's already locked out.

-Password policies behave a little differently depending on how the user account they're applied to was created. There are two ways a user account can be created in Domain

-* The user account can be synchronized in from Microsoft Entra ID. This includes cloud-only user accounts created directly in Azure, and hybrid user accounts synchronized from an on-premises AD DS environment using Microsoft Entra Connect.

- * The majority of user accounts in Domain Services 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.

-All users, regardless of how they're created, have the following account lockout policies applied by the default password policy in Domain

-* **Account lockout duration:** 30

-* **Number of failed logon attempts allowed:** 5

-* **Reset failed logon attempts count after:** 2 minutes

-* **Maximum password age (lifetime):** 90 days

-With these default settings, user accounts are locked out for 30 minutes if five invalid passwords are used within 2 minutes. Accounts are automatically unlocked after 30 minutes.

-Account lockouts only occur within the managed domain. User accounts are only locked out in Domain Services, and only due to failed sign-in attempts against the managed domain. User accounts that were synchronized in from Microsoft Entra ID or on-premises aren't locked out in their source directories, only in Domain Services.

-If you have a Microsoft Entra password policy that specifies a maximum password age greater than 90 days, that password age is applied to the default policy in Domain Services. You can configure a custom password policy to define a different maximum password age in Domain Services. Take care if you have a shorter maximum password age configured in a Domain Services password policy than in Microsoft Entra ID or an on-premises AD DS environment. In that scenario, a user's password may expire in Domain Services before they're prompted to change in Microsoft Entra ID or an on-premises AD DS environment.

-For user accounts created manually in a managed domain, the following additional password settings are also applied from the default policy. These settings don't apply to user accounts synchronized in from Microsoft Entra ID, as a user can't update their password directly in Domain Services.

-* **Minimum password length (characters):** 7

-* **Passwords must meet complexity requirements**

-You can't modify the account lockout or password settings in the default password policy. Instead, members of the *AAD DC Administrators* group can create custom password policies and configure it to override (take precedence over) the default built-in policy, as shown in the next section.

-## Create a custom password policy

-As you build and run applications in Azure, you may want to configure a custom password policy. For example, you could create a policy to set different account lockout policy settings.

-Custom password policies are applied to groups in a managed domain. This configuration effectively overrides the default policy.

-To create a custom password policy, you use the Active Directory Administrative Tools from a domain-joined VM. The Active Directory Administrative Center lets you view, edit, and create resources in a managed domain, including OUs.

-> [!NOTE]

-> To create a custom password policy in a managed domain, you must be signed in to a user account that's a member of the *AAD DC Administrators* group.

-1. From the Start screen, select **Administrative Tools**. A list of available management tools is shown that were installed in the tutorial to [create a management VM][tutorial-create-management-vm].

-1. To create and manage OUs, select **Active Directory Administrative Center** from the list of administrative tools.

-1. In the left pane, choose your managed domain, such as *aaddscontoso.com*.

-1. Open the **System** container, then the **Password Settings Container**.

- A built-in password policy for the managed domain is shown. You can't modify this built-in policy. Instead, create a custom password policy to override the default policy.

- 

-1. In the **Tasks** panel on the right, select **New > Password Settings**.

-1. In the **Create Password Settings** dialog, enter a name for the policy, such as *MyCustomFGPP*.

-1. When multiple password policies exist, the policy with the highest precedence, or priority, is applied to a user. The lower the number, the higher the priority. The default password policy has a priority of *200*.

- Set the precedence for your custom password policy to override the default, such as *1*.

-1. Edit other password policy settings as desired. Account lockout settings apply to all users, but only take effect within the managed domain and not in Microsoft Entra itself.

- 

-1. Uncheck **Protect from accidental deletion**. If this option is selected, you can't save the FGPP.

-1. In the **Directly Applies To** section, select the **Add** button. In the **Select Users or Groups** dialog, select the **Locations** button.

- 

-1. In the **Locations** dialog, expand the domain name, such as *aaddscontoso.com*, then select an OU, such as **AADDC Users**. If you have a custom OU that contains a group of users you wish to apply, select that OU.

- 

-1. Type the name of the user or group you wish to apply the policy to. Select **Check Names** to validate the account.

- 

-1. Click **OK** to save your custom password policy.

-## Next steps

-For more information about password policies and using the Active Directory Administration Center, see the following articles:

-* [Learn about fine-grained password policies](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770394(v=ws.10))

-* [Configure fine-grained password policies using AD Administration Center](/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements--level-100-#fine_grained_pswd_policy_mgmt)

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[tutorial-create-management-vm]: tutorial-create-management-vm.md

-description: Lists Azure Policy built-in policy definitions for Microsoft Entra Domain Services. These built-in policy definitions provide common approaches to managing your Azure resources.

-# Azure Policy built-in definitions for Microsoft Entra Domain Services

-This page is an index of [Azure Policy](../governance/policy/overview.md) built-in policy

-definitions for Microsoft Entra Domain Services. For additional Azure Policy built-ins for

-other services, see

-[Azure Policy built-in definitions](../governance/policy/samples/built-in-policies.md).

-The name of each built-in policy definition links to the policy definition in the Microsoft Entra admin center. Use

-the link in the **Version** column to view the source on the

-[Azure Policy GitHub repo](https://github.com/Azure/azure-policy).

-<a name='azure-active-directory-domain-services'></a>

-## Microsoft Entra Domain Services

-## Next steps

-description: Learn how to configure and enable Microsoft Entra Domain Services using Azure AD PowerShell and Azure PowerShell.

-# Enable Microsoft Entra Domain Services using PowerShell

-Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory. You consume these domain services without deploying, managing, and patching domain controllers yourself. Domain Services integrates with your existing Microsoft Entra tenant. This integration lets users sign in using their corporate credentials, and you can use existing groups and user accounts to secure access to resources.

-This article shows you how to enable Domain Services using PowerShell.

-## Prerequisites

-To complete this article, you need the following resources:

-* Install and configure Azure PowerShell.

- * If needed, follow the instructions to [install the Azure PowerShell module and connect to your Azure subscription](/powershell/azure/install-azure-powershell).

- * Make sure that you sign in to your Azure subscription using the [Connect-AzAccount][Connect-AzAccount] cmdlet.

-* Install and configure Azure AD PowerShell.

- * If needed, follow the instructions to [install the Azure AD PowerShell module and connect to Microsoft Entra ID](/powershell/azure/active-directory/install-adv2).

- * Make sure that you sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet.

-* You need *global administrator* privileges in your Microsoft Entra tenant to enable Domain Services.

-* You need *Contributor* privileges in your Azure subscription to create the required Domain Services resources.

- > [!IMPORTANT]

- > While the **Az.ADDomainServices** PowerShell module is in preview, you must install it separately

- > using the `Install-Module` cmdlet.

- ```azurepowershell-interactive

- Install-Module -Name Az.ADDomainServices

- ```

-<a name='create-required-azure-ad-resources'></a>

-## Create required Microsoft Entra resources

-Domain Services requires a service principal to authenticate and communicate and a Microsoft Entra group to define which users have administrative permissions in the managed domain.

-First, create a Microsoft Entra service principal by using a specific application ID named *Domain Controller Services*. The ID value is *2565bd9d-da50-47d4-8b85-4c97f669dc36* for global Azure and *6ba9a5d4-8456-4118-b521-9c5ca10cdf84* for other Azure clouds. Don't change this application ID.

-Create a Microsoft Entra service principal using the [New-AzureADServicePrincipal][New-AzureADServicePrincipal] cmdlet:

-```powershell

-New-AzureADServicePrincipal -AppId "2565bd9d-da50-47d4-8b85-4c97f669dc36"

-```

-Now create a Microsoft Entra group named *AAD DC Administrators*. Users added to this group are then granted permissions to perform administration tasks on the managed domain.

-First, get the *AAD DC Administrators* group object ID using the [Get-AzureADGroup][Get-AzureADGroup] cmdlet. If the group doesn't exist, create it with the *AAD DC Administrators* group using the [New-AzureADGroup][New-AzureADGroup] cmdlet:

-```powershell

-# First, retrieve the object ID of the 'AAD DC Administrators' group.

-$GroupObjectId = Get-AzureADGroup `

- -Filter "DisplayName eq 'AAD DC Administrators'" | `

- Select-Object ObjectId

-# If the group doesn't exist, create it

-if (!$GroupObjectId) {

- $GroupObjectId = New-AzureADGroup -DisplayName "AAD DC Administrators" `

- -Description "Delegated group to administer Azure AD Domain Services" `

- -SecurityEnabled $true `

- -MailEnabled $false `

- -MailNickName "AADDCAdministrators"

- }

-else {

- Write-Output "Admin group already exists."

-}

-```

-With the *AAD DC Administrators* group created, get the desired user's object ID using the [Get-AzureADUser][Get-AzureADUser] cmdlet, then add the user to the group using the [Add-AzureADGroupMember][Add-AzureADGroupMember] cmdlet.

-In the following example, the user object ID for the account with a UPN of `admin@contoso.onmicrosoft.com`. Replace this user account with the UPN of the user you wish to add to the *AAD DC Administrators* group:

-```powershell

-# Retrieve the object ID of the user you'd like to add to the group.

-$UserObjectId = Get-AzureADUser `

- -Filter "UserPrincipalName eq 'admin@contoso.onmicrosoft.com'" | `

- Select-Object ObjectId

-# Add the user to the 'AAD DC Administrators' group.

-Add-AzureADGroupMember -ObjectId $GroupObjectId.ObjectId -RefObjectId $UserObjectId.ObjectId

-```

-## Create network resources

-First, register the Microsoft Entra Domain Services resource provider using the [Register-AzResourceProvider][Register-AzResourceProvider] cmdlet:

-```azurepowershell-interactive

-Register-AzResourceProvider -ProviderNamespace Microsoft.AAD

-```

-Next, create a resource group using the [New-AzResourceGroup][New-AzResourceGroup] cmdlet. In the following example, the resource group is named *myResourceGroup* and is created in the *westus* region. Use your own name and desired region:

-```azurepowershell-interactive

-$ResourceGroupName = "myResourceGroup"

-$AzureLocation = "westus"

-# Create the resource group.

-New-AzResourceGroup `

- -Name $ResourceGroupName `

- -Location $AzureLocation

-```

-Create the virtual network and subnets for Microsoft Entra Domain Services. Two subnets are created - one for *DomainServices*, and one for *Workloads*. Domain Services is deployed into the dedicated *DomainServices* subnet. Don't deploy other applications or workloads into this subnet. Use the separate *Workloads* or other subnets for the rest of your VMs.

-Create the subnets using the [New-AzVirtualNetworkSubnetConfig][New-AzVirtualNetworkSubnetConfig] cmdlet, then create the virtual network using the [New-AzVirtualNetwork][New-AzVirtualNetwork] cmdlet.

-```azurepowershell-interactive

-$VnetName = "myVnet"

-# Create the dedicated subnet for Azure AD Domain Services.

-$SubnetName = "DomainServices"

-$AaddsSubnet = New-AzVirtualNetworkSubnetConfig `

- -Name $SubnetName `

- -AddressPrefix 10.0.0.0/24

-# Create an additional subnet for your own VM workloads

-$WorkloadSubnet = New-AzVirtualNetworkSubnetConfig `

- -Name Workloads `

- -AddressPrefix 10.0.1.0/24

-# Create the virtual network in which you will enable Azure AD Domain Services.

-$Vnet= New-AzVirtualNetwork `

- -ResourceGroupName $ResourceGroupName `

- -Location westus `

- -Name $VnetName `

- -AddressPrefix 10.0.0.0/16 `

- -Subnet $AaddsSubnet,$WorkloadSubnet

-```

-### Create a network security group

-Domain Services needs a network security group to secure the ports needed for the managed domain and block all other incoming traffic. A [network security group (NSG)][nsg-overview] contains a list of rules that allow or deny network traffic to traffic in an Azure virtual network. In Domain Services, the network security group acts as an extra layer of protection to lock down access to the managed domain. To view the ports required, see [Network security groups and required ports][network-ports].

-The following PowerShell cmdlets use [New-AzNetworkSecurityRuleConfig][New-AzNetworkSecurityRuleConfig] to create the rules, then [New-AzNetworkSecurityGroup][New-AzNetworkSecurityGroup] to create the network security group. The network security group and rules are then associated with the virtual network subnet using the [Set-AzVirtualNetworkSubnetConfig][Set-AzVirtualNetworkSubnetConfig] cmdlet.

-```azurepowershell-interactive

-$NSGName = "aaddsNSG"

-# Create a rule to allow inbound TCP port 3389 traffic from Microsoft secure access workstations for troubleshooting

-$nsg201 = New-AzNetworkSecurityRuleConfig -Name AllowRD `

- -Access Allow `

- -Protocol Tcp `

- -Direction Inbound `

- -Priority 201 `

- -SourceAddressPrefix CorpNetSaw `

- -SourcePortRange * `

- -DestinationAddressPrefix * `

- -DestinationPortRange 3389

-# Create a rule to allow TCP port 5986 traffic for PowerShell remote management

-$nsg301 = New-AzNetworkSecurityRuleConfig -Name AllowPSRemoting `

- -Access Allow `

- -Protocol Tcp `

- -Direction Inbound `

- -Priority 301 `

- -SourceAddressPrefix AzureActiveDirectoryDomainServices `

- -SourcePortRange * `

- -DestinationAddressPrefix * `

- -DestinationPortRange 5986

-# Create the network security group and rules

-$nsg = New-AzNetworkSecurityGroup -Name $NSGName `

- -ResourceGroupName $ResourceGroupName `

- -Location $AzureLocation `

- -SecurityRules $nsg201,$nsg301

-# Get the existing virtual network resource objects and information

-$vnet = Get-AzVirtualNetwork -Name $VnetName -ResourceGroupName $ResourceGroupName

-$subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name $SubnetName

-$addressPrefix = $subnet.AddressPrefix

-# Associate the network security group with the virtual network subnet

-Set-AzVirtualNetworkSubnetConfig -Name $SubnetName `

- -VirtualNetwork $vnet `

- -AddressPrefix $addressPrefix `

- -NetworkSecurityGroup $nsg

-$vnet | Set-AzVirtualNetwork

-```

-## Create a managed domain

-Now let's create a managed domain. Set your Azure subscription ID, and then provide a name for the managed domain, such as *aaddscontoso.com*. You can get your subscription ID using the [Get-AzSubscription][Get-AzSubscription] cmdlet.

-If you choose a region that supports Availability Zones, the Domain Services resources are distributed across zones for redundancy.

-Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there's a minimum of three separate zones in all enabled regions.

-There's nothing for you to configure for Domain Services to be distributed across zones. The Azure platform automatically handles the zone distribution of resources. For more information and to see region availability, see [What are Availability Zones in Azure?][availability-zones].

-```azurepowershell-interactive

-$AzureSubscriptionId = "YOUR_AZURE_SUBSCRIPTION_ID"

-$ManagedDomainName = "aaddscontoso.com"

-# Enable Azure AD Domain Services for the directory.

-$replicaSetParams = @{

- Location = $AzureLocation

- SubnetId = "/subscriptions/$AzureSubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.Network/virtualNetworks/$VnetName/subnets/DomainServices"

-}

-$replicaSet = New-AzADDomainServiceReplicaSetObject @replicaSetParams

-$domainServiceParams = @{

- Name = $ManagedDomainName

- ResourceGroupName = $ResourceGroupName

- DomainName = $ManagedDomainName

- ReplicaSet = $replicaSet

-}

-New-AzADDomainService @domainServiceParams

-```

-It takes a few minutes to create the resource and return control to the PowerShell prompt. The managed domain continues to be provisioned in the background, and can take up to an hour to complete the deployment. In the Microsoft Entra admin center, the **Overview** page for your managed domain shows the current status throughout this deployment stage.

-When the Microsoft Entra admin center shows that the managed domain has finished provisioning, the following tasks need to be completed:

-* Update DNS settings for the virtual network so virtual machines can find the managed domain for domain join or authentication.

- * To configure DNS, select your managed domain in the portal. On the **Overview** window, you are prompted to automatically configure these DNS settings.

-* [Enable password synchronization to Domain Services](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) so end users can sign in to the managed domain using their corporate credentials.

-## Complete PowerShell script

-The following complete PowerShell script combines all of the tasks shown in this article. Copy the script and save it to a file with a `.ps1` extension. For Azure Global, use AppId value *2565bd9d-da50-47d4-8b85-4c97f669dc36*. For other Azure clouds, use AppId value *6ba9a5d4-8456-4118-b521-9c5ca10cdf84*. Run the script in a local PowerShell console or the [Azure Cloud Shell][cloud-shell].

-> [!NOTE]

-> To enable Domain Services, you must be a global administrator for the Microsoft Entra tenant. You also need at least *Contributor* privileges in the Azure subscription.

-```azurepowershell-interactive

-# Change the following values to match your deployment.

-$AaddsAdminUserUpn = "admin@contoso.onmicrosoft.com"

-$ResourceGroupName = "myResourceGroup"

-$VnetName = "myVnet"

-$AzureLocation = "westus"

-$AzureSubscriptionId = "YOUR_AZURE_SUBSCRIPTION_ID"

-$ManagedDomainName = "aaddscontoso.com"

-# Connect to your Azure AD directory.

-Connect-AzureAD

-# Login to your Azure subscription.

-Connect-AzAccount

-# Create the service principal for Azure AD Domain Services.

-New-AzureADServicePrincipal -AppId "2565bd9d-da50-47d4-8b85-4c97f669dc36"

-# First, retrieve the object ID of the 'AAD DC Administrators' group.

-$GroupObjectId = Get-AzureADGroup `

- -Filter "DisplayName eq 'AAD DC Administrators'" | `

- Select-Object ObjectId

-# Create the delegated administration group for Azure AD Domain Services if it doesn't already exist.

-if (!$GroupObjectId) {

- $GroupObjectId = New-AzureADGroup -DisplayName "AAD DC Administrators" `

- -Description "Delegated group to administer Azure AD Domain Services" `

- -SecurityEnabled $true `

- -MailEnabled $false `

- -MailNickName "AADDCAdministrators"

- }

-else {

- Write-Output "Admin group already exists."

-}

-# Now, retrieve the object ID of the user you'd like to add to the group.

-$UserObjectId = Get-AzureADUser `

- -Filter "UserPrincipalName eq '$AaddsAdminUserUpn'" | `

- Select-Object ObjectId

-# Add the user to the 'AAD DC Administrators' group.

-Add-AzureADGroupMember -ObjectId $GroupObjectId.ObjectId -RefObjectId $UserObjectId.ObjectId

-# Register the resource provider for Azure AD Domain Services with Resource Manager.

-Register-AzResourceProvider -ProviderNamespace Microsoft.AAD

-# Create the resource group.

-New-AzResourceGroup `

- -Name $ResourceGroupName `

- -Location $AzureLocation

-# Create the dedicated subnet for AAD Domain Services.

-$SubnetName = "DomainServices"

-$AaddsSubnet = New-AzVirtualNetworkSubnetConfig `

- -Name DomainServices `

- -AddressPrefix 10.0.0.0/24

-$WorkloadSubnet = New-AzVirtualNetworkSubnetConfig `

- -Name Workloads `

- -AddressPrefix 10.0.1.0/24

-# Create the virtual network in which you will enable Azure AD Domain Services.

-$Vnet=New-AzVirtualNetwork `

- -ResourceGroupName $ResourceGroupName `

- -Location $AzureLocation `

- -Name $VnetName `

- -AddressPrefix 10.0.0.0/16 `

- -Subnet $AaddsSubnet,$WorkloadSubnet

-$NSGName = "aaddsNSG"

-# Create a rule to allow inbound TCP port 3389 traffic from Microsoft secure access workstations for troubleshooting

-$nsg201 = New-AzNetworkSecurityRuleConfig -Name AllowRD `

- -Access Allow `

- -Protocol Tcp `

- -Direction Inbound `

- -Priority 201 `

- -SourceAddressPrefix CorpNetSaw `

- -SourcePortRange * `

- -DestinationAddressPrefix * `

- -DestinationPortRange 3389

-# Create a rule to allow TCP port 5986 traffic for PowerShell remote management

-$nsg301 = New-AzNetworkSecurityRuleConfig -Name AllowPSRemoting `

- -Access Allow `

- -Protocol Tcp `

- -Direction Inbound `

- -Priority 301 `

- -SourceAddressPrefix AzureActiveDirectoryDomainServices `

- -SourcePortRange * `

- -DestinationAddressPrefix * `

- -DestinationPortRange 5986

-# Create the network security group and rules

-$nsg = New-AzNetworkSecurityGroup -Name $NSGName `

- -ResourceGroupName $ResourceGroupName `

- -Location $AzureLocation `

- -SecurityRules $nsg201,$nsg301

-# Get the existing virtual network resource objects and information

-$vnet = Get-AzVirtualNetwork -Name $VnetName -ResourceGroupName $ResourceGroupName

-$subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name $SubnetName

-$addressPrefix = $subnet.AddressPrefix

-# Associate the network security group with the virtual network subnet

-Set-AzVirtualNetworkSubnetConfig -Name $SubnetName `

- -VirtualNetwork $vnet `

- -AddressPrefix $addressPrefix `

- -NetworkSecurityGroup $nsg

-$vnet | Set-AzVirtualNetwork

-# Enable Azure AD Domain Services for the directory.

-$replicaSetParams = @{

- Location = $AzureLocation

- SubnetId = "/subscriptions/$AzureSubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.Network/virtualNetworks/$VnetName/subnets/DomainServices"

-}

-$replicaSet = New-AzADDomainServiceReplicaSet @replicaSetParams

-$domainServiceParams = @{

- Name = $ManagedDomainName

- ResourceGroupName = $ResourceGroupName

- DomainName = $ManagedDomainName

- ReplicaSet = $replicaSet

-}

-New-AzADDomainService @domainServiceParams

-```

-It takes a few minutes to create the resource and return control to the PowerShell prompt. The managed domain continues to be provisioned in the background, and can take up to an hour to complete the deployment. In the Microsoft Entra admin center, the **Overview** page for your managed domain shows the current status throughout this deployment stage.

-When the Microsoft Entra admin center shows that the managed domain has finished provisioning, the following tasks need to be completed:

-* Update DNS settings for the virtual network so virtual machines can find the managed domain for domain join or authentication.

- * To configure DNS, select your managed domain in the portal. On the **Overview** window, you are prompted to automatically configure these DNS settings.

-* [Enable password synchronization to Domain Services](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) so end users can sign in to the managed domain using their corporate credentials.

-## Next steps

-To see the managed domain in action, you can [domain-join a Windows VM][windows-join], [configure secure LDAP][tutorial-ldaps], and [configure password hash sync][tutorial-phs].

-<!-- INTERNAL LINKS -->

-[windows-join]: join-windows-vm.md

-[tutorial-ldaps]: tutorial-configure-ldaps.md

-[tutorial-phs]: tutorial-configure-password-hash-sync.md

-[nsg-overview]: /azure/virtual-network/network-security-groups-overview

-[network-ports]: network-considerations.md#network-security-groups-and-required-ports

-<!-- EXTERNAL LINKS -->

-[Connect-AzAccount]: /powershell/module/az.accounts/connect-azaccount

-[Connect-AzureAD]: /powershell/module/azuread/connect-azuread

-[New-AzureADServicePrincipal]: /powershell/module/AzureAD/New-AzureADServicePrincipal

-[New-AzureADGroup]: /powershell/module/azuread/new-azureadgroup

-[Add-AzureADGroupMember]: /powershell/module/azuread/add-azureadgroupmember

-[Get-AzureADGroup]: /powershell/module/azuread/get-azureadgroup

-[Get-AzureADUser]: /powershell/module/azuread/get-azureaduser

-[Register-AzResourceProvider]: /powershell/module/az.resources/register-azresourceprovider

-[New-AzResourceGroup]: /powershell/module/az.resources/new-azresourcegroup

-[New-AzVirtualNetworkSubnetConfig]: /powershell/module/az.network/new-azvirtualnetworksubnetconfig

-[New-AzVirtualNetwork]: /powershell/module/az.network/new-azvirtualnetwork

-[Get-AzSubscription]: /powershell/module/az.accounts/get-azsubscription

-[cloud-shell]: /azure/active-directory/develop/configure-app-multi-instancing

-[availability-zones]: /azure/reliability/availability-zones-overview

-[New-AzNetworkSecurityRuleConfig]: /powershell/module/az.network/new-aznetworksecurityruleconfig

-[New-AzNetworkSecurityGroup]: /powershell/module/az.network/new-aznetworksecuritygroup

-[Set-AzVirtualNetworkSubnetConfig]: /powershell/module/az.network/set-azvirtualnetworksubnetconfig

-description: Learn how to use Azure AD PowerShell to configure scoped synchronization from Microsoft Entra ID to a Microsoft Entra Domain Services managed domain

-# Configure scoped synchronization from Microsoft Entra ID to Microsoft Entra Domain Services using Azure AD PowerShell

-To provide authentication services, Microsoft Entra Domain Services synchronizes users and groups from Microsoft Entra ID. In a hybrid environment, users and groups from an on-premises Active Directory Domain Services (AD DS) environment can be first synchronized to Microsoft Entra ID using Microsoft Entra Connect, and then synchronized to Domain Services.

-By default, all users and groups from a Microsoft Entra directory are synchronized to a Domain Services managed domain. If you have specific needs, you can instead choose to synchronize only a defined set of users.

-This article shows you how to create a managed domain that uses scoped synchronization and then change or disable the set of scoped users using Azure AD PowerShell. You can also [complete these steps using the Microsoft Entra admin center][scoped-sync].

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][tutorial-create-instance].

-* You need [Application Administrator](/azure/active-directory/roles/permissions-reference#application-administrator) and [Groups Administrator](/azure/active-directory/roles/permissions-reference#groups-administrator) Microsoft Entra roles in your tenant to change the Domain Services synchronization scope.

-## Scoped synchronization overview

-By default, all users and groups from a Microsoft Entra directory are synchronized to a managed domain. If only a few users need to access the managed domain, you can synchronize only those user accounts. This scoped synchronization is group-based. When you configure group-based scoped synchronization, only the user accounts that belong to the groups you specify are synchronized to the managed domain. Nested groups aren't synchronized, only the specific groups you select.

-You can change the synchronization scope before or after you create the managed domain. The scope of synchronization is defined by a service principal with the application identifier 2565bd9d-da50-47d4-8b85-4c97f669dc36. To prevent scope loss, don't delete or change the service principal. If it is accidentally deleted, the synchronization scope can't be recovered.

-Keep in mind the following caveats if you change the synchronization scope:

-To learn more about the synchronization process, see [Understand synchronization in Microsoft Entra Domain Services][concepts-sync].

-## PowerShell script for scoped synchronization

-To configure scoped synchronization using PowerShell, first save the following script to a file named `Select-GroupsToSync.ps1`.

-This script configures Domain Services to synchronize selected groups from Microsoft Entra ID. All user accounts that are part of the specified groups are synchronized to the managed domain.

-This script is used in the additional steps in this article.

-```powershell

-param (

- [Parameter(Position = 0)]

- [String[]]$groupsToAdd

-)

-Connect-AzureAD

-$sp = Get-AzureADServicePrincipal -Filter "AppId eq '2565bd9d-da50-47d4-8b85-4c97f669dc36'"

-$role = $sp.AppRoles | where-object -FilterScript {$_.DisplayName -eq "User"}

-Write-Output "`n****************************************************************************"

-Write-Output "Total group-assignments need to be added: $($groupsToAdd.Count)"

-$newGroupIds = New-Object 'System.Collections.Generic.HashSet[string]'

-foreach ($groupName in $groupsToAdd)

-{

- try

- {

- $group = Get-AzureADGroup -Filter "DisplayName eq '$groupName'"

- $newGroupIds.Add($group.ObjectId)

- Write-Output "Group-Name: $groupName, Id: $($group.ObjectId)"

- }

- catch

- {

- Write-Error "Failed to find group: $groupName. Exception: $($_.Exception)."

- }

-}

-Write-Output "****************************************************************************`n"

-Write-Output "`n****************************************************************************"

-$currentAssignments = Get-AzureADServiceAppRoleAssignment -ObjectId $sp.ObjectId -All $true

-Write-Output "Total current group-assignments: $($currentAssignments.Count), SP-ObjectId: $($sp.ObjectId)"

-$currAssignedObjectIds = New-Object 'System.Collections.Generic.HashSet[string]'

-foreach ($assignment in $currentAssignments)

-{

- Write-Output "Assignment-ObjectId: $($assignment.PrincipalId)"

- if ($newGroupIds.Contains($assignment.PrincipalId) -eq $false)

- {

- Write-Output "This assignment is not needed anymore. Removing it! Assignment-ObjectId: $($assignment.PrincipalId)"

- Remove-AzureADServiceAppRoleAssignment -ObjectId $sp.ObjectId -AppRoleAssignmentId $assignment.ObjectId

- }

- else

- {

- $currAssignedObjectIds.Add($assignment.PrincipalId)

- }

-}

-Write-Output "****************************************************************************`n"

-Write-Output "`n****************************************************************************"

-foreach ($id in $newGroupIds)

-{

- try

- {

- if ($currAssignedObjectIds.Contains($id) -eq $false)

- {

- Write-Output "Adding new group-assignment. Role-Id: $($role.Id), Group-Object-Id: $id, ResourceId: $($sp.ObjectId)"

- New-AzureADGroupAppRoleAssignment -Id $role.Id -ObjectId $id -PrincipalId $id -ResourceId $sp.ObjectId

- }

- else

- {

- Write-Output "Group-ObjectId: $id is already assigned."

- }

- }

- catch

- {

- Write-Error "Exception occurred assigning Object-ID: $id. Exception: $($_.Exception)."

- }

-}

-Write-Output "****************************************************************************`n"

-```

-## Enable scoped synchronization

-To enable group-based scoped synchronization for a managed domain, complete the following steps:

-1. First set *"filteredSync" = "Enabled"* on the Domain Services resource, then update the managed domain.

- When prompted, specify the credentials for a *global admin* to sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

- ```powershell

- # Connect to your Azure AD tenant

- Connect-AzureAD

- # Retrieve the Azure AD DS resource.

- $DomainServicesResource = Get-AzResource -ResourceType "Microsoft.AAD/DomainServices"

- # Enable group-based scoped synchronization.

- $enableScopedSync = @{"filteredSync" = "Enabled"}

- # Update the Azure AD DS resource

- Set-AzResource -Id $DomainServicesResource.ResourceId -Properties $enableScopedSync

- ```

-1. Now specify the list of groups whose users should be synchronized to the managed domain.

- Run the `Select-GroupsToSync.ps1` script and specify the list of groups to sync. In the following example, the groups to synchronize are *GroupName1* and *GroupName2*.

- > [!WARNING]

- > You must include the *AAD DC Administrators* group in the list of groups for scoped synchronization. If you don't include this group, the managed domain is unusable.

- ```powershell

- .\Select-GroupsToSync.ps1 -groupsToAdd @("AAD DC Administrators", "GroupName1", "GroupName2")

- ```

-Changing the scope of synchronization causes the managed domain to resynchronize all data. Objects that are no longer required in the managed domain are deleted, and resynchronization may take a long time to complete.

-## Modify scoped synchronization

-To modify the list of groups whose users should be synchronized to the managed domain, run `Select-GroupsToSync.ps1` script and specify the new list of groups to sync.

-In the following example, the groups to synchronize no longer includes *GroupName2*, and now includes *GroupName3*.

-> [!WARNING]

-> You must include the *AAD DC Administrators* group in the list of groups for scoped synchronization. If you don't include this group, the managed domain is unusable.

-When prompted, specify the credentials for a *global admin* to sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

-```powershell

-.\Select-GroupsToSync.ps1 -groupsToAdd @("AAD DC Administrators", "GroupName1", "GroupName3")

-```

-Changing the scope of synchronization causes the managed domain to resynchronize all data. Objects that are no longer required in the managed domain are deleted, and resynchronization may take a long time to complete.

-## Disable scoped synchronization

-To disable group-based scoped synchronization for a managed domain, set *"filteredSync" = "Disabled"* on the Domain Services resource, then update the managed domain. When complete, all users and groups are set to synchronize from Microsoft Entra ID.

-When prompted, specify the credentials for a *global admin* to sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

-```powershell

-# Connect to your Azure AD tenant

-Connect-AzureAD

-# Retrieve the Azure AD DS resource.

-$DomainServicesResource = Get-AzResource -ResourceType "Microsoft.AAD/DomainServices"

-# Disable group-based scoped synchronization.

-$disableScopedSync = @{"filteredSync" = "Disabled"}

-# Update the Azure AD DS resource

-Set-AzResource -Id $DomainServicesResource.ResourceId -Properties $disableScopedSync

-```

-Changing the scope of synchronization causes the managed domain to resynchronize all data. Objects that are no longer required in the managed domain are deleted, and resynchronization may take a long time to complete.

-## Next steps

-To learn more about the synchronization process, see [Understand synchronization in Microsoft Entra Domain Services](synchronization.md).

-<!-- INTERNAL LINKS -->

-[scoped-sync]: scoped-synchronization.md

-[concepts-sync]: synchronization.md

-[tutorial-create-instance]: tutorial-create-instance.md

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-<!-- EXTERNAL LINKS -->

-[Connect-AzureAD]: /powershell/module/azuread/connect-azuread

-description: Learn about some of the common scenarios and use-cases for Microsoft Entra Domain Services to provide value and meet business needs.

-# Common use-cases and scenarios for Microsoft Entra Domain Services

-Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos / NTLM authentication. Microsoft Entra Domain Services integrates with your existing Microsoft Entra tenant, which makes it possible for users to sign in using their existing credentials. You use these domain services without the need to deploy, manage, and patch domain controllers in the cloud, which provides a smoother lift-and-shift of on-premises resources to Azure.

-This article outlines some common business scenarios where Microsoft Entra Domain Services provides value and meets those needs.

-## Common ways to provide identity solutions in the cloud

-When you migrate existing workloads to the cloud, directory-aware applications may use LDAP for read or write access to an on-premises AD DS directory. Applications that run on Windows Server are typically deployed on domain-joined virtual machines (VMs) so they can be managed securely using Group Policy. To authenticate end users, the applications may also rely on Windows-integrated authentication, such as Kerberos or NTLM authentication.

-IT administrators often use one of the following solutions to provide an identity service to applications that run in Azure:

-* Configure a site-to-site VPN connection between workloads that run in Azure and an on-premises AD DS environment.

- * The on-premises domain controllers then provide authentication via the VPN connection.

-* Create replica domain controllers using Azure virtual machines (VMs) to extend the AD DS domain / forest from on-premises.

- * The domain controllers that run on Azure VMs provide authentication, and replicate directory information between the on-premises AD DS environment.

-* Deploy a standalone AD DS environment in Azure using domain controllers that run on Azure VMs.

- * The domain controllers that run on Azure VMs provide authentication, but there's no directory information replicated from an on-premises AD DS environment.

-With these approaches, VPN connections to the on-premises directory make applications vulnerable to transient network glitches or outages. If you deploy domain controllers using VMs in Azure, the IT team must manage the VMs, then secure, patch, monitor, backup, and troubleshoot them.

-Microsoft Entra Domain Services offers alternatives to the need to create VPN connections back to an on-premises AD DS environment or run and manage VMs in Azure to provide identity services. As a managed service, Microsoft Entra Domain Services reduces the complexity to create an integrated identity solution for both hybrid and cloud-only environments.

-> [!div class="nextstepaction"]

-> [Compare Microsoft Entra Domain Services with Microsoft Entra ID and self-managed AD DS on Azure VMs or on-premises][compare]

-<a name='azure-ad-ds-for-hybrid-organizations'></a>

-<a name='microsoft-entra-ds-for-hybrid-organizations'></a>

-## Microsoft Entra Domain Services for hybrid organizations

-Many organizations run a hybrid infrastructure that includes both cloud and on-premises application workloads. Legacy applications migrated to Azure as part of a lift and shift strategy may use traditional LDAP connections to provide identity information. To support this hybrid infrastructure, identity information from an on-premises AD DS environment can be synchronized to a Microsoft Entra tenant. Microsoft Entra Domain Services then provides these legacy applications in Azure with an identity source, without the need to configure and manage application connectivity back to on-premises directory services.

-Let's look at an example for Litware Corporation, a hybrid organization that runs both on-premises and Azure resources:

-

-* Applications and server workloads that require domain services are deployed in a virtual network in Azure.

- * This may include legacy applications migrated to Azure as part of a lift and shift strategy.

-* To synchronize identity information from their on-premises directory to their Microsoft Entra tenant, Litware Corporation deploys [Microsoft Entra Connect][azure-ad-connect].

- * Identity information that is synchronized includes user accounts and group memberships.

-* Litware's IT team enables Microsoft Entra Domain Services for their Microsoft Entra tenant in this, or a peered, virtual network.

-* Applications and VMs deployed in the Azure virtual network can then use Microsoft Entra Domain Services features like domain join, LDAP read, LDAP bind, NTLM and Kerberos authentication, and Group Policy.

-> [!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.

-<a name='azure-ad-ds-for-cloud-only-organizations'></a>

-<a name='microsoft-entra-ds-for-cloud-only-organizations'></a>

-## Microsoft Entra Domain Services for cloud-only organizations

-A cloud-only Microsoft Entra tenant doesn't have an on-premises identity source. User accounts and group memberships, for example, are created and managed directly in Microsoft Entra ID.

-Now let's look at an example for Contoso, a cloud-only organization that uses Microsoft Entra ID for identity. All user identities, their credentials, and group memberships are created and managed in Microsoft Entra ID. There is no additional configuration of Microsoft Entra Connect to synchronize any identity information from an on-premises directory.

-

-* Applications and server workloads that require domain services are deployed in a virtual network in Azure.

-* Contoso's IT team enables Microsoft Entra Domain Services for their Microsoft Entra tenant in this, or a peered, virtual network.

-* Applications and VMs deployed in the Azure virtual network can then use Microsoft Entra Domain Services features like domain join, LDAP read, LDAP bind, NTLM and Kerberos authentication, and Group Policy.

-## Secure administration of Azure virtual machines

-To let you use a single set of AD credentials, Azure virtual machines (VMs) can be joined to a Microsoft Entra Domain Services managed domain. This approach reduces credential management issues such as maintaining local administrator accounts on each VM or separate accounts and passwords between environments.

-VMs that are joined to a managed domain can also be administered and secured using group policy. Required security baselines can be applied to VMs to lock them down in accordance with corporate security guidelines. For example, you can use group policy management capabilities to restrict the types of applications that can be launched on the VM.

-

-Let's look at a common example scenario. As servers and other infrastructure reaches end-of-life, Contoso wants to move applications currently hosted on premises to the cloud. Their current IT standard mandates that servers hosting corporate applications must be domain-joined and managed using group policy.

-Contoso's IT administrator would prefer to domain join VMs deployed in Azure to make administration easier as users can then sign in using their corporate credentials. When domain-joined, VMs can also be configured to comply with required security baselines using group policy objects (GPOs). Contoso would prefer not to deploy, monitor, and manage their own domain controllers in Azure.

-Microsoft Entra Domain Services is a great fit for this use-case. A managed domain lets you domain-join VMs, use a single set of credentials, and apply group policy. And because it's a managed domain, you don't have to configure and maintain the domain controllers yourself.

-### Deployment notes

-The following deployment considerations apply to this example use case:

-* Managed domains use a single, flat Organizational Unit (OU) structure by default. All domain-joined VMs are in a single OU. If desired, you can create [custom OUs][custom-ou].

-* Microsoft Entra Domain Services uses a built-in GPO each for the users and computers containers. For additional control, you can [create custom GPOs][create-gpo] and target them to custom OUs.

-* Microsoft Entra Domain Services supports the base AD computer object schema. You can't extend the computer object's schema.

-## Lift-and-shift on-premises applications that use LDAP bind authentication

-As a sample scenario, Contoso has an on-premises application that was purchased from an ISV many years ago. The application is currently in maintenance mode by the ISV and requesting changes to the application is prohibitively expensive. This application has a web-based frontend that collects user credentials using a web form and then authenticates users by performing an LDAP bind to the on-premises AD DS environment.

-

-Contoso would like to migrate this application to Azure. The application should continue to works as-is, with no changes needed. Additionally, users should be able to authenticate using their existing corporate credentials and without additional training. It should be transparent to end users where the application is running.

-For this scenario, Microsoft Entra Domain Services lets applications perform LDAP binds as part of the authentication process. Legacy on-premises applications can lift-and-shift into Azure and continue to seamlessly authenticate users without any change in configuration or user experience.

-### Deployment notes

-The following deployment considerations apply to this example use case:

-* Make sure that the application doesn't need to modify/write to the directory. LDAP write access to a managed domain isn't supported.

-* You can't change passwords directly against a managed domain. End users can change their password either using the [Microsoft Entra self-service password change mechanism][sspr] or against the on-premises directory. These changes are then automatically synchronized and available in the managed domain.

-## Lift-and-shift on-premises applications that use LDAP read to access the directory

-Like the previous example scenario, let's assume Contoso has an on-premises line-of-business (LOB) application that was developed almost a decade ago. This application is directory aware and was designed to use LDAP to read information/attributes about users from AD DS. The application doesn't modify attributes or otherwise write to the directory.

-Contoso wants to migrate this application to Azure and retire the aging on-premises hardware currently hosting this application. The application can't be rewritten to use modern directory APIs such as the REST-based Microsoft Graph API. A lift-and-shift option is desired where the application can be migrated to run in the cloud, without modifying code or rewriting the application.

-To help with this scenario, Microsoft Entra Domain Services lets applications perform LDAP reads against the managed domain to get the attribute information it needs. The application doesn't need to be rewritten, so a lift-and-shift into Azure lets users continue to use the app without realizing there's a change in where it runs.

-### Deployment notes

-The following deployment considerations apply to this example use case:

-* Make sure that the application doesn't need to modify/write to the directory. LDAP write access to a managed domain isn't supported.

-* Make sure that the application doesn't need a custom/extended Active Directory schema. Schema extensions aren't supported in Microsoft Entra Domain Services.

-## Migrate an on-premises service or daemon application to Azure

-Some applications include multiple tiers, where one of the tiers needs to perform authenticated calls to a backend tier, such as a database. AD service accounts are commonly used in these scenarios. When you lift-and-shift applications into Azure, Microsoft Entra Domain Services lets you continue to use service accounts in the same way. You can choose to use the same service account that is synchronized from your on-premises directory to Microsoft Entra ID or create a custom OU and then create a separate service account in that OU. With either approach, applications continue to function the same way to make authenticated calls to other tiers and services.

-

-In this example scenario, Contoso has a custom-built software vault application that includes a web front end, a SQL server, and a backend FTP server. Windows-integrated authentication using service accounts authenticates the web front end to the FTP server. The web front end is set up to run as a service account. The backend server is configured to authorize access from the service account for the web front end. Contoso doesn't want to deploy and manage their own domain controller VMs in the cloud to move this application to Azure.

-For this scenario, the servers hosting the web front end, SQL server, and the FTP server can be migrated to Azure VMs and joined to a managed domain. The VMs can then use the same service account in their on-premises directory for the app's authentication purposes, which is synchronized through Microsoft Entra ID using Microsoft Entra Connect.

-### Deployment notes

-The following deployment considerations apply to this example use case:

-* Make sure that the applications use a username and password for authentication. Certificate or smartcard-based authentication isn't supported by Microsoft Entra Domain Services.

-* You can't change passwords directly against a managed domain. End users can change their password either using the [Microsoft Entra self-service password change mechanism][sspr] or against the on-premises directory. These changes are then automatically synchronized and available in the managed domain.

-## Windows Server remote desktop services deployments in Azure

-You can use Microsoft Entra Domain Services to provide managed domain services to remote desktop servers deployed in Azure.

-For more information about this deployment scenario, see [how to integrate Microsoft Entra Domain Services with your RDS deployment][windows-rds].

-## Domain-joined HDInsight clusters

-You can set up an Azure HDInsight cluster that is joined to a managed domain with Apache Ranger enabled. You can create and apply Hive policies through Apache Ranger, and allow users, such as data scientists, to connect to Hive using ODBC-based tools like Excel or Tableau. We continue to work to add other workloads, such as HBase, Spark, and Storm to domain-joined HDInsight.

-For more information about this deployment scenario, see [how to configure domain-joined HDInsight clusters][hdinsight]

-## Next steps

-To get started, [Create and configure a Microsoft Entra Domain Services managed domain][tutorial-create-instance].

-<!-- INTERNAL LINKS -->

-[hdinsight]: /azure/hdinsight/domain-joined/apache-domain-joined-configure-using-azure-adds

-[tutorial-create-instance]: tutorial-create-instance.md

-[custom-ou]: create-ou.md

-[create-gpo]: manage-group-policy.md

-[sspr]: /azure/active-directory/authentication/overview-authentication#self-service-password-reset

-[compare]: compare-identity-solutions.md

-[azure-ad-connect]: /azure/active-directory/hybrid/connect/whatis-azure-ad-connect

-<!-- EXTERNAL LINKS -->

-[windows-rds]: /windows-server/remote/remote-desktop-services/rds-azure-adds

-description: Learn how to use the Microsoft Entra admin center to configure scoped synchronization from Microsoft Entra ID to a Microsoft Entra Domain Services managed domain

-# Configure scoped synchronization from Microsoft Entra ID to Microsoft Entra Domain Services using the Microsoft Entra admin center

-To provide authentication services, Microsoft Entra Domain Services synchronizes users and groups from Microsoft Entra ID. In a hybrid environment, users and groups from an on-premises Active Directory Domain Services (AD DS) environment can be first synchronized to Microsoft Entra ID using Microsoft Entra Connect, and then synchronized to a Domain Services managed domain.

-By default, all users and groups from a Microsoft Entra directory are synchronized to a managed domain. If only some users need to use Domain Services, you can instead choose to synchronize only groups of users. You can filter synchronization for groups on-premises, cloud only, or both.

-This article shows you how to configure scoped synchronization and then change or disable the set of scoped users using the Microsoft Entra admin center. You can also [complete these steps using PowerShell][scoped-sync-powershell].

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][tutorial-create-instance].

-* You need [Application Administrator](/azure/active-directory/roles/permissions-reference#application-administrator) and [Groups Administrator](/azure/active-directory/roles/permissions-reference#groups-administrator) Microsoft Entra roles in your tenant to change the Domain Services synchronization scope.

-## Scoped synchronization overview

-By default, all users and groups from a Microsoft Entra directory are synchronized to a managed domain. You can scope synchronization to only user accounts that were created in Microsoft Entra ID, or synchronize all users.

-If only a few groups of users need to access the managed domain, you can select **Filter by group entitlement** to synchronize only those groups. This scoped synchronization is only group-based. When you configure group-based scoped synchronization, only the user accounts that belong to the groups you specify are synchronized to the managed domain. Nested groups aren't synchronized; only the groups you specify get synchronized.

-You can change the synchronization scope before or after you create the managed domain. The scope of synchronization is defined by a service principal with the application identifier 2565bd9d-da50-47d4-8b85-4c97f669dc36. To prevent scope loss, don't delete or change the service principal. If it is accidentally deleted, the synchronization scope can't be recovered.

-Keep in mind the following caveats if you change the synchronization scope:

-To learn more about the synchronization process, see [Understand synchronization in Microsoft Entra Domain Services][concepts-sync].

-## Enable scoped synchronization

-To enable scoped synchronization in the Microsoft Entra admin center, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Microsoft Entra Domain Services**. Choose your managed domain, such as *aaddscontoso.com*.

-1. Select **Synchronization** from the menu on the left-hand side.

-1. For *Synchronization scope*, select **All** or **Cloud Only**.

-1. To filter synchronization for selected groups, click **Show selected groups**, choose whether to synchronize cloud-only groups, on-premises groups, or both. For example, the following screenshot shows how to synchronize only three groups that were created in Microsoft Entra ID. Only users who belong to those groups will have their accounts synchronized to Domain Services.

- :::image type="content" source="media/scoped-synchronization/cloud-only-groups.png" alt-text="Screenshot that shows filter by cloud-only groups." :::

-1. To add groups, click **Add groups**, then search for and choose the groups to add.

-1. When all changes are made, select **Save synchronization scope**.

-Changing the scope of synchronization causes the managed domain to resynchronize all data. Objects that are no longer required in the managed domain are deleted, and resynchronization may take some time to complete.

-## Modify scoped synchronization

-To modify the list of groups whose users should be synchronized to the managed domain, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Microsoft Entra Domain Services**. Choose your managed domain, such as *aaddscontoso.com*.

-1. Select **Synchronization** from the menu on the left-hand side.

-1. To add a group, choose **+ Add groups** at the top, then choose the groups to add.

-1. To remove a group from the synchronization scope, select it from the list of currently synchronized groups and choose **Remove groups**.

-1. When all changes are made, select **Save synchronization scope**.

-Changing the scope of synchronization causes the managed domain to resynchronize all data. Objects that are no longer required in the managed domain are deleted, and resynchronization may take some time to complete.

-## Disable scoped synchronization

-To disable group-based scoped synchronization for a managed domain, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Microsoft Entra Domain Services**. Choose your managed domain, such as *aaddscontoso.com*.

-1. Select **Synchronization** from the menu on the left-hand side.

-1. Clear the check box for **Show selected groups**, and click **Save synchronization scope**.

-Changing the scope of synchronization causes the managed domain to resynchronize all data. Objects that are no longer required in the managed domain are deleted, and resynchronization may take some time to complete.

-## Next steps

-To learn more about the synchronization process, see [Understand synchronization in Microsoft Entra Domain Services][concepts-sync].

-<!-- INTERNAL LINKS -->

-[scoped-sync-powershell]: powershell-scoped-synchronization.md

-[concepts-sync]: synchronization.md

-[tutorial-create-instance]: tutorial-create-instance.md

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-description: Learn how to secure remote access to VMs using Network Policy Server (NPS) and Microsoft Entra multifactor authentication with a Remote Desktop Services deployment in a Microsoft Entra Domain Services managed domain.

-# Secure remote access to virtual machines in Microsoft Entra Domain Services

-To secure remote access to virtual machines (VMs) that run in a Microsoft Entra Domain Services managed domain, you can use Remote Desktop Services (RDS) and Network Policy Server (NPS). Domain Services authenticates users as they request access through the RDS environment. For enhanced security, you can integrate Microsoft Entra multifactor authentication to provide another authentication prompt during sign-in events. Microsoft Entra multifactor authentication uses an extension for NPS to provide this feature.

-> [!IMPORTANT]

-> The recommended way to securely connect to your VMs in a Domain Services managed domain is using Azure Bastion, a fully platform-managed PaaS service that you provision inside your virtual network. A bastion host provides secure and seamless Remote Desktop Protocol (RDP) connectivity to your VMs directly in the Azure portal over SSL. When you connect via a bastion host, your VMs don't need a public IP address, and you don't need to use network security groups to expose access to RDP on TCP port 3389.

->

-> We strongly recommend that you use Azure Bastion in all regions where it's supported. In regions without Azure Bastion availability, follow the steps detailed in this article until Azure Bastion is available. Take care with assigning public IP addresses to VMs joined to Domain Services where all incoming RDP traffic is allowed.

->

-> For more information, see [What is Azure Bastion?][bastion-overview].

-This article shows you how to configure RDS in Domain Services and optionally use the Microsoft Entra multifactor authentication NPS extension.

-

-## Prerequisites

-To complete this article, you need the following resources:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A *workloads* subnet created in your Microsoft Entra Domain Services virtual network.

- * If needed, [Configure virtual networking for a Microsoft Entra Domain Services managed domain][configure-azureadds-vnet].

-* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

-## Deploy and configure the Remote Desktop environment

-To get started, create a minimum of two Azure VMs that run Windows Server 2016 or Windows Server 2019. For redundancy and high availability of your Remote Desktop (RD) environment, you can add and load balance hosts later.

-A suggested RDS deployment includes the following two VMs:

-* *RDGVM01* - Runs the RD Connection Broker server, RD Web Access server, and RD Gateway server.

-* *RDSHVM01* - Runs the RD Session Host server.

-Make sure that VMs are deployed into a *workloads* subnet of your Domain Services virtual network, then join the VMs to managed domain. For more information, see how to [create and join a Windows Server VM to a managed domain][tutorial-create-join-vm].

-The RD environment deployment contains a number of steps. The existing RD deployment guide can be used without any specific changes to use in a managed domain:

-1. Sign in to VMs created for the RD environment with an account that's part of the *Microsoft Entra DC Administrators* group, such as *contosoadmin*.

-1. To create and configure RDS, use the existing [Remote Desktop environment deployment guide][deploy-remote-desktop]. Distribute the RD server components across your Azure VMs as desired.

- * Specific to Domain Services - when you configure RD licensing, set it to **Per Device** mode, not **Per User** as noted in the deployment guide.

-1. If you want to provide access using a web browser, [set up the Remote Desktop web client for your users][rd-web-client].

-With RD deployed into the managed domain, you can manage and use the service as you would with an on-premises AD DS domain.

-<a name='deploy-and-configure-nps-and-the-azure-ad-mfa-nps-extension'></a>

-## Deploy and configure NPS and the Microsoft Entra multifactor authentication NPS extension

-If you want to increase the security of the user sign-in experience, you can optionally integrate the RD environment with Microsoft Entra multifactor authentication. With this configuration, users receive another prompt during sign-in to confirm their identity.

-To provide this capability, a Network Policy Server (NPS) is installed in your environment along with the Microsoft Entra multifactor authentication NPS extension. This extension integrates with Microsoft Entra ID to request and return the status of multifactor authentication prompts.

-Users must be [registered to use Microsoft Entra multifactor authentication][user-mfa-registration], which may require other Microsoft Entra ID licenses.

-To integrate Microsoft Entra multifactor authentication in to your Remote Desktop environment, create an NPS Server and install the extension:

-1. Create another Windows Server 2016 or 2019 VM, such as *NPSVM01*, that's connected to a *workloads* subnet in your Domain Services virtual network. Join the VM to the managed domain.

-1. Sign in to NPS VM as account that's part of the *Microsoft Entra DC Administrators* group, such as *contosoadmin*.

-1. From **Server Manager**, select **Add Roles and Features**, then install the *Network Policy and Access Services* role.

-1. Use the existing how-to article to [install and configure the Microsoft Entra multifactor authentication NPS extension][nps-extension].

-With the NPS server and Microsoft Entra multifactor authentication NPS extension installed, complete the next section to configure it for use with the RD environment.

-<a name='integrate-remote-desktop-gateway-and-azure-ad-multi-factor-authentication'></a>

-## Integrate Remote Desktop Gateway and Microsoft Entra multifactor authentication

-To integrate the Microsoft Entra multifactor authentication NPS extension, use the existing how-to article to [integrate your Remote Desktop Gateway infrastructure using the Network Policy Server (NPS) extension and Microsoft Entra ID][azure-mfa-nps-integration].

-The following configuration options are needed to integrate with a managed domain:

-1. Don't [register the NPS server in Active Directory][register-nps-ad]. This step fails in a managed domain.

-1. In [step 4 to configure network policy][create-nps-policy], also check the box to **Ignore user account dial-in properties**.

-1. If you use Windows Server 2019 for the NPS server and Microsoft Entra multifactor authentication NPS extension, run the following command to update the secure channel to allow the NPS server to communicate correctly:

- ```powershell

- sc sidtype IAS unrestricted

- ```

-Users are now prompted for another authentication factor when they sign in, such as a text message or prompt in the Microsoft Authenticator app.

-## Next steps

-For more information on improving resiliency of your deployment, see [Remote Desktop Services - High availability][rds-high-availability].

-For more information about securing user sign-in, see [How it works: Microsoft Entra multifactor authentication][concepts-mfa].

-<!-- INTERNAL LINKS -->

-[bastion-overview]: /azure/bastion/bastion-overview

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[configure-azureadds-vnet]: tutorial-configure-networking.md

-[tutorial-create-join-vm]: join-windows-vm.md

-[user-mfa-registration]: /azure/active-directory/authentication/howto-mfa-nps-extension#register-users-for-mfa

-[nps-extension]: /azure/active-directory/authentication/howto-mfa-nps-extension

-[azure-mfa-nps-integration]: /azure/active-directory/authentication/howto-mfa-nps-extension-rdg

-[register-nps-ad]:/azure/active-directory/authentication/howto-mfa-nps-extension-rdg#register-server-in-active-directory

-[create-nps-policy]: /azure/active-directory/authentication/howto-mfa-nps-extension-rdg#configure-network-policy

-[concepts-mfa]: /azure/active-directory/authentication/concept-mfa-howitworks

-<!-- EXTERNAL LINKS -->

-[deploy-remote-desktop]: /windows-server/remote/remote-desktop-services/rds-deploy-infrastructure

-[rd-web-client]: /windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin

-[rds-high-availability]: /windows-server/remote/remote-desktop-services/rds-plan-high-availability

-description: Learn how to disable weak ciphers, old protocols, and NTLM password hash synchronization for a Microsoft Entra Domain Services managed domain.

-# Harden a Microsoft Entra Domain Services managed domain

-By default, Microsoft Entra Domain Services enables the use of ciphers such as NTLM v1 and TLS v1. These ciphers may be required for some legacy applications, but are considered weak and can be disabled if you don't need them. If you have on-premises hybrid connectivity using Microsoft Entra Connect, you can also disable the synchronization of NTLM password hashes.

-This article shows you how to harden a managed domain by using setting setting such as:

-## Prerequisites

-To complete this article, you need the following resources:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-## Use Security settings to harden your domain

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Search for and select **Microsoft Entra Domain Services**.

-1. Choose your managed domain, such as *aaddscontoso.com*.

-1. On the left-hand side, select **Security settings**.

-1. Click **Enable** or **Disable** for the following settings:

- - **TLS 1.2 Only Mode**

- - **NTLM v1 Authentication**

- - **NTLM Password Synchronization**

- - **Kerberos RC4 Encryption**

- - **Kerberos Armoring**

- - **LDAP Signing**

- - **LDAP Channel Binding**

- 

-## Assign Azure Policy compliance for TLS 1.2 usage

-In addition to **Security settings**, Microsoft Azure Policy has a **Compliance** setting to enforce TLS 1.2 usage. The policy has no impact until it is assigned. When the policy is assigned, it appears in **Compliance**:

-

-## Audit NTLM failures

-While disabling NTLM password synchronization will improve security, many applications and services are not designed to work without it. For example, connecting to any resource by its IP address, such as DNS Server management or RDP, will fail with Access Denied. If you disable NTLM password synchronization and your application or service isnΓÇÖt working as expected, you can check for NTLM authentication failures by enabling security auditing for the **Logon/Logoff** > **Audit Logon** event category, where NTLM is specified as the **Authentication Package** in the event details. For more information, see [Enable security audits for Microsoft Entra Domain Services](security-audit-events.md).

-## Use PowerShell to harden your domain

-If needed, [install and configure Azure PowerShell](/powershell/azure/install-azure-powershell). Make sure that you sign in to your Azure subscription using the [Connect-AzAccount][Connect-AzAccount] cmdlet.

-Also if needed, [install and configure Azure AD PowerShell](/powershell/azure/active-directory/install-adv2). Make sure that you sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet.

-To disable weak cipher suites and NTLM credential hash synchronization, sign in to your Azure account, then get the Domain Services resource using the [Get-AzResource][Get-AzResource] cmdlet:

-> [!TIP]

-> If you receive an error using the [Get-AzResource][Get-AzResource] command that the *Microsoft.AAD/DomainServices* resource doesn't exist, [elevate your access to manage all Azure subscriptions and management groups][global-admin].

-```powershell

-Login-AzAccount

-$DomainServicesResource = Get-AzResource -ResourceType "Microsoft.AAD/DomainServices"

-```

-Next, define *DomainSecuritySettings* to configure the following security options:

-1. Disable NTLM v1 support.

-2. Disable the synchronization of NTLM password hashes from your on-premises AD.

-3. Disable TLS v1.

-> [!IMPORTANT]

-> Users and service accounts can't perform LDAP simple binds if you disable NTLM password hash synchronization in the Domain Services managed domain. If you need to perform LDAP simple binds, don't set the *"SyncNtlmPasswords"="Disabled";* security configuration option in the following command.

-```powershell

-$securitySettings = @{"DomainSecuritySettings"=@{"NtlmV1"="Disabled";"SyncNtlmPasswords"="Disabled";"TlsV1"="Disabled";"KerberosRc4Encryption"="Disabled";"KerberosArmoring"="Disabled"}}

-```

-Finally, apply the defined security settings to the managed domain using the [Set-AzResource][Set-AzResource] cmdlet. Specify the Domain Services resource from the first step, and the security settings from the previous step.

-```powershell

-Set-AzResource -Id $DomainServicesResource.ResourceId -Properties $securitySettings -ApiVersion ΓÇ£2021-03-01ΓÇ¥ -Verbose -Force

-```

-It takes a few moments for the security settings to be applied to the managed domain.

-> [!IMPORTANT]

-> After you disable NTLM, perform a full password hash synchronization in Microsoft Entra Connect to remove all the password hashes from the managed domain. If you disable NTLM but don't force a password hash sync, NTLM password hashes for a user account are only removed on the next password change. This behavior could allow a user to continue to sign in if they have cached credentials on a system where NTLM is used as the authentication method.

->

-> Once the NTLM password hash is different from the Kerberos password hash, fallback to NTLM won't work. Cached credentials also no longer work if the VM has connectivity to the managed domain controller.

-## Next steps

-To learn more about the synchronization process, see [How objects and credentials are synchronized in a managed domain][synchronization].

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[global-admin]: /azure/role-based-access-control/elevate-access-global-admin

-[synchronization]: synchronization.md

-<!-- EXTERNAL LINKS -->

-[Get-AzResource]: /powershell/module/az.resources/get-azresource

-[Set-AzResource]: /powershell/module/az.resources/set-azresource

-[Connect-AzAccount]: /powershell/module/Az.Accounts/Connect-AzAccount

-[Connect-AzureAD]: /powershell/module/AzureAD/Connect-AzureAD

-description: Learn how to enable security audits to centralize the logging of events for analysis and alerts in Microsoft Entra Domain Services

-# Enable security and DNS audits for Microsoft Entra Domain Services

-Microsoft Entra Domain Services security and DNS audits let Azure stream events to targeted resources. These resources include Azure Storage, Azure Log Analytics workspaces, or Azure Event Hub. After you enable security audit events, Domain Services sends all the audited events for the selected category to the targeted resource.

-You can archive events into Azure storage and stream events into security information and event management (SIEM) software (or equivalent) using Azure Event Hubs, or do your own analysis and using Azure Log Analytics workspaces from the Microsoft Entra admin center.

-## Security audit destinations

-You can use Azure Storage, Azure Event Hubs, or Azure Log Analytics workspaces as a target resource for Domain Services security audits. These destinations can be combined. For example, you could use Azure Storage for archiving security audit events, but an Azure Log Analytics workspace to analyze and report on the information in the short term.

-The following table outlines scenarios for each destination resource type.

-> [!IMPORTANT]

-> You need to create the target resource before you enable Domain Services security audits. You can create these resources using the Microsoft Entra admin center, Azure PowerShell, or the Azure CLI.

-| Target Resource | Scenario |

-|:|:|

-|Azure Storage| This target should be used when your primary need is to store security audit events for archival purposes. Other targets can be used for archival purposes, however those targets provide capabilities beyond the primary need of archiving. <br /><br />Before you enable Domain Services security audit events, first [Create an Azure Storage account](/azure/storage/common/storage-account-create).|

-|Azure Event Hubs| This target should be used when your primary need is to share security audit events with additional software such as data analysis software or security information & event management (SIEM) software.<br /><br />Before you enable Domain Services security audit events, [Create an event hub using Microsoft Entra admin center](/azure/event-hubs/event-hubs-create)|

-|Azure Log Analytics Workspace| This target should be used when your primary need is to analyze and review secure audits from the Microsoft Entra admin center directly.<br /><br />Before you enable Domain Services security audit events, [Create a Log Analytics workspace in the Microsoft Entra admin center.](/azure/azure-monitor/logs/quick-create-workspace)|

-## Enable security audit events using the Microsoft Entra admin center

-To enable Domain Services security audit events using the Microsoft Entra admin center, complete the following steps.

-> [!IMPORTANT]

-> Domain Services security audits aren't retroactive. You can't retrieve or replay events from the past. Domain Services can only send events that occur after security audits are enabled.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as a Global Administrator.

-1. Search for and select **Microsoft Entra Domain Services**. Choose your managed domain, such as *aaddscontoso.com*.

-1. In the Domain Services window, select **Diagnostic settings** on the left-hand side.

-1. No diagnostics are configured by default. To get started, select **Add diagnostic setting**.

- 

-1. Enter a name for the diagnostic configuration, such as *aadds-auditing*.

- Check the box for the security or DNS audit destination you want. You can choose from a Log Analytics workspace, an Azure Storage account, an Azure event hub, or a partner solution. These destination resources must already exist in your Azure subscription. You can't create the destination resources in this wizard.

- * **Azure Log Analytic workspaces**

- * Select **Send to Log Analytics**, then choose the **Subscription** and **Log Analytics Workspace** you want to use to store audit events.

- * **Azure storage**

- * Select **Archive to a storage account**, then choose **Configure**.

- * Select the **Subscription** and the **Storage account** you want to use to archive audit events.

- * When ready, choose **OK**.

- * **Azure event hubs**

- * Select **Stream to an event hub**, then choose **Configure**.

- * Select the **Subscription** and the **Event hub namespace**. If needed, also choose an **Event hub name** and then **Event hub policy name**.

- * When ready, choose **OK**.

- * **Partner solution**

- * Select **Send to partner solution**, then choose the **Subscription** and **Destination** you want to use to store audit events.

-1. Select the log categories you want included for the particular target resource. If you send the audit events to an Azure Storage account, you can also configure a retention policy that defines the number of days to retain data. A default setting of *0* retains all data and doesn't rotate events after a period of time.

- You can select different log categories for each targeted resource within a single configuration. This ability lets you choose which logs categories you want to keep for Log Analytics and which logs categories you want to archive, for example.

-1. When done, select **Save** to commit your changes. The target resources start to receive Domain Services audit events soon after the configuration is saved.

-## Enable security and DNS audit events using Azure PowerShell

-To enable Domain Services security and DNS audit events using Azure PowerShell, complete the following steps. If needed, first [install the Azure PowerShell module and connect to your Azure subscription](/powershell/azure/install-azure-powershell).

-> [!IMPORTANT]

-> Domain Services audits aren't retroactive. You can't retrieve or replay events from the past. Domain Services can only send events that occur after audits are enabled.

-1. Authenticate to your Azure subscription using the [Connect-AzAccount](/powershell/module/Az.Accounts/Connect-AzAccount) cmdlet. When prompted, enter your account credentials.

- ```azurepowershell

- Connect-AzAccount

- ```

-1. Create the target resource for the audit events.

- * **Azure Log Analytic workspaces** - [Create a Log Analytics workspace with Azure PowerShell](/azure/azure-monitor/logs/powershell-workspace-configuration).

- * **Azure storage** - [Create a storage account using Azure PowerShell](/azure/storage/common/storage-account-create?tabs=azure-powershell)

- * **Azure event hubs** - [Create an event hub using Azure PowerShell](/azure/event-hubs/event-hubs-quickstart-powershell). You may also need to use the [New-AzEventHubAuthorizationRule](/powershell/module/az.eventhub/new-azeventhubauthorizationrule) cmdlet to create an authorization rule that grants Domain Services permissions to the event hub *namespace*. The authorization rule must include the **Manage**, **Listen**, and **Send** rights.

- > [!IMPORTANT]

- > Ensure you set the authorization rule on the event hub namespace and not the event hub itself.

-1. Get the resource ID for your Domain Services managed domain using the [Get-AzResource](/powershell/module/az.resources/get-azresource) cmdlet. Create a variable named *$aadds.ResourceId* to hold the value:

- ```azurepowershell

- $aadds = Get-AzResource -name aaddsDomainName

- ```

-1. Configure the Azure Diagnostic settings using the [Set-AzDiagnosticSetting](/powershell/module/az.monitor/set-azdiagnosticsetting) cmdlet to use the target resource for Microsoft Entra Domain Services audit events. In the following examples, the variable *$aadds.ResourceId* is used from the previous step.

- * **Azure storage** - Replace *storageAccountId* with your storage account name:

- ```powershell

- Set-AzDiagnosticSetting `

- -ResourceId $aadds.ResourceId `

- -StorageAccountId storageAccountId `

- -Enabled $true

- ```

- * **Azure event hubs** - Replace *eventHubName* with the name of your event hub and *eventHubRuleId* with your authorization rule ID:

- ```powershell

- Set-AzDiagnosticSetting -ResourceId $aadds.ResourceId `

- -EventHubName eventHubName `

- -EventHubAuthorizationRuleId eventHubRuleId `

- -Enabled $true

- ```

- * **Azure Log Analytic workspaces** - Replace *workspaceId* with the ID of the Log Analytics workspace:

- ```powershell

- Set-AzureRmDiagnosticSetting -ResourceId $aadds.ResourceId `

- -WorkspaceID workspaceId `

- -Enabled $true

- ```

-## Query and view security and DNS audit events using Azure Monitor

-Log Analytic workspaces let you view and analyze the security and DNS audit events using Azure Monitor and the Kusto query language. This query language is designed for read-only use that boasts power analytic capabilities with an easy-to-read syntax. For more information to get started with Kusto query languages, see the following articles:

-* [Azure Monitor documentation](/azure/azure-monitor/)

-* [Get started with Log Analytics in Azure Monitor](/azure/azure-monitor/logs/log-analytics-tutorial)

-* [Get started with log queries in Azure Monitor](/azure/azure-monitor/logs/get-started-queries)

-* [Create and share dashboards of Log Analytics data](/azure/azure-monitor/visualize/tutorial-logs-dashboards)

-The following sample queries can be used to start analyzing audit events from Domain Services.

-### Sample query 1

-View all the account lockout events for the last seven days:

-```Kusto

-AADDomainServicesAccountManagement

-| where TimeGenerated >= ago(7d)

-| where OperationName has "4740"

-```

-### Sample query 2

-View all the account lockout events (*4740*) between June 3, 2020 at 9 a.m. and June 10, 2020 midnight, sorted ascending by the date and time:

-```Kusto

-AADDomainServicesAccountManagement

-| where TimeGenerated >= datetime(2020-06-03 09:00) and TimeGenerated <= datetime(2020-06-10)

-| where OperationName has "4740"

-| sort by TimeGenerated asc

-```

-### Sample query 3

-View account sign-in events seven days ago (from now) for the account named user:

-```Kusto

-AADDomainServicesAccountLogon

-| where TimeGenerated >= ago(7d)

-| where "user" == tolower(extract("Logon Account:\t(.+[0-9A-Za-z])",1,tostring(ResultDescription)))

-```

-### Sample query 4

-View account sign-in events seven days ago from now for the account named user that attempted to sign in using a bad password (*0xC0000006a*):

-```Kusto

-AADDomainServicesAccountLogon

-| where TimeGenerated >= ago(7d)

-| where "user" == tolower(extract("Logon Account:\t(.+[0-9A-Za-z])",1,tostring(ResultDescription)))

-| where "0xc000006a" == tolower(extract("Error Code:\t(.+[0-9A-Fa-f])",1,tostring(ResultDescription)))

-```

-### Sample query 5

-View account sign-in events seven days ago from now for the account named user that attempted to sign in while the account was locked out (*0xC0000234*):

-```Kusto

-AADDomainServicesAccountLogon

-| where TimeGenerated >= ago(7d)

-| where "user" == tolower(extract("Logon Account:\t(.+[0-9A-Za-z])",1,tostring(ResultDescription)))

-| where "0xc0000234" == tolower(extract("Error Code:\t(.+[0-9A-Fa-f])",1,tostring(ResultDescription)))

-```

-### Sample query 6

-View the number of account sign-in events seven days ago from now for all sign-in attempts that occurred for all locked out users:

-```Kusto

-AADDomainServicesAccountLogon

-| where TimeGenerated >= ago(7d)

-| where "0xc0000234" == tolower(extract("Error Code:\t(.+[0-9A-Fa-f])",1,tostring(ResultDescription)))

-| summarize count()

-```

-## Audit security and DNS event categories

-Domain Services security and DNS audits align with traditional auditing for traditional AD DS domain controllers. In hybrid environments, you can reuse existing audit patterns so the same logic may be used when analyzing the events. Depending on the scenario you need to troubleshoot or analyze, the different audit event categories need to be targeted.

-The following audit event categories are available:

-| Audit Category Name | Description |

-|:|:|

-| Account Logon|Audits attempts to authenticate account data on a domain controller or on a local Security Accounts Manager (SAM).<br>-Logon and Logoff policy settings and events track attempts to access a particular computer. Settings and events in this category focus on the account database that is used. This category includes the following subcategories:<br>-[Audit Credential Validation](/windows/security/threat-protection/auditing/audit-credential-validation)<br>-[Audit Kerberos Authentication Service](/windows/security/threat-protection/auditing/audit-kerberos-authentication-service)<br>-[Audit Kerberos Service Ticket Operations](/windows/security/threat-protection/auditing/audit-kerberos-service-ticket-operations)<br>-[Audit Other Logon/Logoff Events](/windows/security/threat-protection/auditing/audit-other-logonlogoff-events)|

-| Account Management|Audits changes to user and computer accounts and groups. This category includes the following subcategories:<br>-[Audit Application Group Management](/windows/security/threat-protection/auditing/audit-application-group-management)<br>-[Audit Computer Account Management](/windows/security/threat-protection/auditing/audit-computer-account-management)<br>-[Audit Distribution Group Management](/windows/security/threat-protection/auditing/audit-distribution-group-management)<br>-[Audit Other Account Management](/windows/security/threat-protection/auditing/audit-other-account-management-events)<br>-[Audit Security Group Management](/windows/security/threat-protection/auditing/audit-security-group-management)<br>-[Audit User Account Management](/windows/security/threat-protection/auditing/audit-user-account-management)|

-| DNS Server|Audits changes to DNS environments. This category includes the following subcategories: <br>- [DNSServerAuditsDynamicUpdates (preview)](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn800669(v=ws.11)#audit-and-analytic-event-logging)<br>- [DNSServerAuditsGeneral (preview)](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn800669(v=ws.11)#audit-and-analytic-event-logging)|

-| Detail Tracking|Audits activities of individual applications and users on that computer, and to understand how a computer is being used. This category includes the following subcategories:<br>-[Audit DPAPI Activity](/windows/security/threat-protection/auditing/audit-dpapi-activity)<br>-[Audit PNP activity](/windows/security/threat-protection/auditing/audit-pnp-activity)<br>-[Audit Process Creation](/windows/security/threat-protection/auditing/audit-process-creation)<br>-[Audit Process Termination](/windows/security/threat-protection/auditing/audit-process-termination)<br>-[Audit RPC Events](/windows/security/threat-protection/auditing/audit-rpc-events)|

-| Directory Services Access|Audits attempts to access and modify objects in Active Directory Domain Services (AD DS). These audit events are logged only on domain controllers. This category includes the following subcategories:<br>-[Audit Detailed Directory Service Replication](/windows/security/threat-protection/auditing/audit-detailed-directory-service-replication)<br>-[Audit Directory Service Access](/windows/security/threat-protection/auditing/audit-directory-service-access)<br>-[Audit Directory Service Changes](/windows/security/threat-protection/auditing/audit-directory-service-changes)<br>-[Audit Directory Service Replication](/windows/security/threat-protection/auditing/audit-directory-service-replication)|

-| Logon-Logoff|Audits attempts to log on to a computer interactively or over a network. These events are useful for tracking user activity and identifying potential attacks on network resources. This category includes the following subcategories:<br>-[Audit Account Lockout](/windows/security/threat-protection/auditing/audit-account-lockout)<br>-[Audit User/Device Claims](/windows/security/threat-protection/auditing/audit-user-device-claims)<br>-[Audit IPsec Extended Mode](/windows/security/threat-protection/auditing/audit-ipsec-extended-mode)<br>-[Audit Group Membership](/windows/security/threat-protection/auditing/audit-group-membership)<br>-[Audit IPsec Main Mode](/windows/security/threat-protection/auditing/audit-ipsec-main-mode)<br>-[Audit IPsec Quick Mode](/windows/security/threat-protection/auditing/audit-ipsec-quick-mode)<br>-[Audit Logoff](/windows/security/threat-protection/auditing/audit-logoff)<br>-[Audit Logon](/windows/security/threat-protection/auditing/audit-logon)<br>-[Audit Network Policy Server](/windows/security/threat-protection/auditing/audit-network-policy-server)<br>-[Audit Other Logon/Logoff Events](/windows/security/threat-protection/auditing/audit-other-logonlogoff-events)<br>-[Audit Special Logon](/windows/security/threat-protection/auditing/audit-special-logon)|

-|Object Access| Audits attempts to access specific objects or types of objects on a network or computer. This category includes the following subcategories:<br>-[Audit Application Generated](/windows/security/threat-protection/auditing/audit-application-generated)<br>-[Audit Certification Services](/windows/security/threat-protection/auditing/audit-certification-services)<br>-[Audit Detailed File Share](/windows/security/threat-protection/auditing/audit-detailed-file-share)<br>-[Audit File Share](/windows/security/threat-protection/auditing/audit-file-share)<br>-[Audit File System](/windows/security/threat-protection/auditing/audit-file-system)<br>-[Audit Filtering Platform Connection](/windows/security/threat-protection/auditing/audit-filtering-platform-connection)<br>-[Audit Filtering Platform Packet Drop](/windows/security/threat-protection/auditing/audit-filtering-platform-packet-drop)<br>-[Audit Handle Manipulation](/windows/security/threat-protection/auditing/audit-handle-manipulation)<br>-[Audit Kernel Object](/windows/security/threat-protection/auditing/audit-kernel-object)<br>-[Audit Other Object Access Events](/windows/security/threat-protection/auditing/audit-other-object-access-events)<br>-[Audit Registry](/windows/security/threat-protection/auditing/audit-registry)<br>-[Audit Removable Storage](/windows/security/threat-protection/auditing/audit-removable-storage)<br>-[Audit SAM](/windows/security/threat-protection/auditing/audit-sam)<br>-[Audit Central Access Policy Staging](/windows/security/threat-protection/auditing/audit-central-access-policy-staging)|

-|Policy Change|Audits changes to important security policies on a local system or network. Policies are typically established by administrators to help secure network resources. Monitoring changes or attempts to change these policies can be an important aspect of security management for a network. This category includes the following subcategories:<br>-[Audit Audit Policy Change](/windows/security/threat-protection/auditing/audit-audit-policy-change)<br>-[Audit Authentication Policy Change](/windows/security/threat-protection/auditing/audit-authentication-policy-change)<br>-[Audit Authorization Policy Change](/windows/security/threat-protection/auditing/audit-authorization-policy-change)<br>-[Audit Filtering Platform Policy Change](/windows/security/threat-protection/auditing/audit-filtering-platform-policy-change)<br>-[Audit MPSSVC Rule-Level Policy Change](/windows/security/threat-protection/auditing/audit-mpssvc-rule-level-policy-change)<br>-[Audit Other Policy Change](/windows/security/threat-protection/auditing/audit-other-policy-change-events)|

-|Privilege Use| Audits the use of certain permissions on one or more systems. This category includes the following subcategories:<br>-[Audit Non-Sensitive Privilege Use](/windows/security/threat-protection/auditing/audit-non-sensitive-privilege-use)<br>-[Audit Sensitive Privilege Use](/windows/security/threat-protection/auditing/audit-sensitive-privilege-use)<br>-[Audit Other Privilege Use Events](/windows/security/threat-protection/auditing/audit-other-privilege-use-events)|

-|System| Audits system-level changes to a computer not included in other categories and that have potential security implications. This category includes the following subcategories:<br>-[Audit IPsec Driver](/windows/security/threat-protection/auditing/audit-ipsec-driver)<br>-[Audit Other System Events](/windows/security/threat-protection/auditing/audit-other-system-events)<br>-[Audit Security State Change](/windows/security/threat-protection/auditing/audit-security-state-change)<br>-[Audit Security System Extension](/windows/security/threat-protection/auditing/audit-security-system-extension)<br>-[Audit System Integrity](/windows/security/threat-protection/auditing/audit-system-integrity)|

-## Event IDs per category

- Domain Services security and DNS audits record the following event IDs when the specific action triggers an auditable event:

-| Event Category Name | Event IDs |

-|:|:|

-|Account Logon security|4767, 4774, 4775, 4776, 4777|

-|Account Management security|4720, 4722, 4723, 4724, 4725, 4726, 4727, 4728, 4729, 4730, 4731, 4732, 4733, 4734, 4735, 4737, 4738, 4740, 4741, 4742, 4743, 4754, 4755, 4756, 4757, 4758, 4764, 4765, 4766, 4780, 4781, 4782, 4793, 4798, 4799, 5376, 5377|

-|Detail Tracking security|None|

-|DNS Server |513-523, 525-531, 533-537, 540-582|

-|DS Access security|5136, 5137, 5138, 5139, 5141|

-|Logon-Logoff security|4624, 4625, 4634, 4647, 4648, 4672, 4675, 4964|

-|Object Access security|None|

-|Policy Change security|4670, 4703, 4704, 4705, 4706, 4707, 4713, 4715, 4716, 4717, 4718, 4719, 4739, 4864, 4865, 4866, 4867, 4904, 4906, 4911, 4912|

-|Privilege Use security|4985|

-|System security|4612, 4621|

-## Next steps

-For specific information on Kusto, see the following articles:

-* [Overview](/azure/data-explorer/kusto/query/) of the Kusto query language.

-* [Kusto tutorial](/azure/data-explorer/kusto/query/tutorials/learn-common-operators) to familiarize you with query basics.

-* [Sample queries](/azure/data-explorer/kusto/query/tutorials/learn-common-operators) that help you learn new ways to see your data.

-* Kusto [best practices](/azure/data-explorer/kusto/query/best-practices) to optimize your queries for success.

-description: Learn about the different health states for a Microsoft Entra Domain Services managed domain and how to restore a suspended domain.

-# Understand the health states and resolve suspended domains in Microsoft Entra Domain Services

-When Microsoft Entra Domain Services is unable to service a managed domain for a long period of time, it puts the managed domain into a suspended state. If a managed domain remains in a suspended state, it's automatically deleted. To keep your Domain Services managed domain healthy and avoid suspension, resolve any alerts as quickly as you can.

-This article explains why managed domains are suspended, and how to recover a suspended domain.

-## Overview of managed domain states

-Through the lifecycle of a managed domain, there are different states that indicate its health. If the managed domain reports an issue, quickly resolve the underlying cause to stop the state from continuing to degrade.

-

-A managed domain can be in one of the following states:

-* [Running](#running-state)

-* [Needs attention](#needs-attention-state)

-* [Suspended](#suspended-state)

-* [Deleted](#deleted-state)

-## Running state

-A managed domain that's configured correctly and without problems is in the *Running* state. This is the desired state for a managed domain.

-### What to expect

-* The Azure platform can regularly monitor the health of the managed domain.

-* Domain controllers for the managed domain are patched and updated regularly.

-* Changes from Microsoft Entra ID are regularly synchronized to the managed domain.

-* Regular backups are taken for the managed domain.

-## Needs Attention state

-A managed domain with one or more issues that need to be fixed is in the *Needs attention* state. The health page for the managed domain lists the alerts, and indicate where there's a problem.

-Some alerts are transient and are automatically resolved by the Azure platform. For other alerts, you can fix the issue by following the resolution steps provided. It there's a critical alert, [open an Azure support request][azure-support] for additional troubleshooting assistance.

-One example of an alert is when there's a restrictive network security group. In this configuration, the Azure platform may not be able to update and monitor the managed domain. An alert is generated, and the state changes to *Needs attention*.

-For more information, see [How to troubleshoot alerts for a managed domain][resolve-alerts].

-### What to expect

-When a managed domain is in the *Needs Attention* state, the Azure platform may not be able to monitor, patch, update, or back-up data on a regular basis. In some cases, like an invalid network configuration, the domain controllers for the managed domain may be unreachable.

-* The managed domain is in an unhealthy state and ongoing health monitoring may stop until the alert is resolved.

-* Domain controllers for the managed domain can't be patched or updated.

-* Changes from Microsoft Entra ID may not be synchronized to the managed domain.

-* Backups for the managed domain may not be taken.

-* If you resolve non-critical alerts that are impacting the managed domain, the health should return to the *Running* state.

-* Critical alerts are triggered for configuration issues where the Azure platform can't reach the domain controllers. If these critical alerts aren't resolved within 15 days, the managed domain enters the *Suspended* state.

-## Suspended state

-A managed domain enters the **Suspended** state for one of the following reasons:

-* One or more critical alerts haven't been resolved in 15 days.

- * Critical alerts can be caused by a misconfiguration that blocks access to resources that are needed by Domain Services. For example, the alert [AADDS104: Network Error][alert-nsg] has been unresolved for more than 15 days in the managed domain.

-* There's a billing issue with the Azure subscription or the Azure subscription has expired.

-Managed domains are suspended when the Azure platform can't manage, monitor, patch, or back up the domain. A managed domain stays in a *Suspended* state for 15 days. To maintain access to the managed domain, resolve critical alerts immediately.

-### What to expect

-The following behavior is experienced when a managed domain is in the *Suspended* state:

-* Domain controllers for the managed domain are de-provisioned and aren't reachable within the virtual network.

-* Secure LDAP access to the managed domain over the internet, if enabled, stops working.

-* There are failures in authenticating to the managed domain, logging on to domain-joined VMs, or connecting over LDAP/LDAPS.

-* Backups for the managed domain are no longer taken.

-* Synchronization with Microsoft Entra ID stops.

-### How do you know if your managed domain is suspended?

-You see an [alert][resolve-alerts] on the Domain Services Health page in the Microsoft Entra admin center that notes the domain is suspended. The state of the domain also shows *Suspended*.

-### Restore a suspended domain

-To restore the health of a managed domain that's in the *Suspended* state, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Domain services**.

-1. Choose your managed domain from the list, such as *aaddscontoso.com*, then select **Health**.

-1. Select the alert, such as *AADDS503* or *AADDS504*, depending on the cause of suspension.

-1. Choose the resolution link that's provided in the alert and follow the steps to resolve it.

-A managed domain can only be restored to the date of the last backup. The date of your last backup is displayed on the **Health** page of the managed domain. Any changes that occurred after the last backup won't be restored. Backups for a managed domain are stored for up to 30 days. Backups that are older than 30 days are deleted.

-After you resolve alerts when the managed domain is in the *Suspended* state, [open an Azure support request][azure-support] to return to a healthy state. If there's a backup less than 30 days old, Azure support can restore the managed domain.

-## Deleted state

-If a managed domain stays in the *Suspended* state for 15 days, it's deleted. This process is unrecoverable.

-### What to expect

-When a managed domain enters the *Deleted* state, the following behavior is seen:

-* All resources and backups for the managed domain are deleted.

-* You can't restore the managed domain. You must create a replacement managed domain to reuse Domain Services.

-* After it's deleted, you aren't billed for the managed domain.

-## Next steps

-To keep your managed domain healthy and minimize the risk of it becoming suspended, learn how to [resolve alerts for your managed domain][resolve-alerts].

-<!-- INTERNAL LINKS -->

-[alert-nsg]: alert-nsg.md

-[azure-support]: /azure/active-directory/fundamentals/how-to-get-support

-[resolve-alerts]: troubleshoot-alerts.md

-description: Learn how the synchronization process works between Microsoft Entra ID or an on-premises environment to a Microsoft Entra Domain Services managed domain.

-# 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:

-

-<a name='synchronization-from-azure-ad-to-azure-ad-ds'></a>

-## 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](scoped-synchronization.md).

-<a name='attribute-synchronization-and-mapping-to-azure-ad-ds'></a>

-## 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 |

-| mail |mail |

-| 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) |

-| mail |mail |

-| mailNickname |msDS-AzureADMailNickname |

-| objectid |msDS-AzureADObjectId |

-| onPremiseSecurityIdentifier |sidHistory |

-| proxyAddresses | proxyAddresses |

-| securityEnabled |groupType |

-<a name='synchronization-from-on-premises-ad-ds-to-azure-ad-and-azure-ad-ds'></a>

-## 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)](create-ou.md) 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.

-<a name='what-isnt-synchronized-to-azure-ad-ds'></a>

-## 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

-* **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](create-ou.md).

-## 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](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) 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](tutorial-configure-password-hash-sync.md).

-## Next steps

-For more information on the specifics of password synchronization, see [How password hash synchronization works with Microsoft Entra Connect](/azure/active-directory/hybrid/connect/how-to-connect-password-hash-synchronization?context=/azure/active-directory-domain-services/context/azure-ad-ds-context).

-To get started with Domain Services, [create a managed domain](tutorial-create-instance.md).

-description: Learn how to configure and enable Microsoft Entra Domain Services using an Azure Resource Manager template

-# Create a Microsoft Entra Domain Services managed domain using an Azure Resource Manager template

-Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory. You consume these domain services without deploying, managing, and patching domain controllers yourself. Domain Services integrates with your existing Microsoft Entra tenant. This integration lets users sign in using their corporate credentials, and you can use existing groups and user accounts to secure access to resources.

-This article shows you how to create a managed domain using an Azure Resource Manager template. Supporting resources are created using Azure PowerShell.

-## Prerequisites

-To complete this article, you need the following resources:

-* Install and configure Azure PowerShell.

- * If needed, follow the instructions to [install the Azure PowerShell module and connect to your Azure subscription](/powershell/azure/install-azure-powershell).

- * Make sure that you sign in to your Azure subscription using the [Connect-AzAccount][Connect-AzAccount] cmdlet.

-* Install and configure Azure AD PowerShell.

- * If needed, follow the instructions to [install the Azure AD PowerShell module and connect to Microsoft Entra ID](/powershell/azure/active-directory/install-adv2).

- * Make sure that you sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet.

-* You need [Application Administrator](/azure/active-directory/roles/permissions-reference#application-administrator) and [Groups Administrator](/azure/active-directory/roles/permissions-reference#groups-administrator) Microsoft Entra roles in your tenant to enable Domain Services.

-* You need Domain Services Contributor Azure role to create the required Domain Services resources.

-## DNS naming requirements

-When you create a Domain Services managed domain, you specify a DNS name. There are some considerations when you choose this DNS name:

-* **Built-in domain name:** By default, the built-in domain name of the directory is used (a *.onmicrosoft.com* suffix). If you wish to enable secure LDAP access to the managed domain over the internet, you can't create a digital certificate to secure the connection with this default domain. Microsoft owns the *.onmicrosoft.com* domain, so a Certificate Authority (CA) won't issue a certificate.

-* **Custom domain names:** The most common approach is to specify a custom domain name, typically one that you already own and is routable. When you use a routable, custom domain, traffic can correctly flow as needed to support your applications.

-* **Non-routable domain suffixes:** We generally recommend that you avoid a non-routable domain name suffix, such as *contoso.local*. The *.local* suffix isn't routable and can cause issues with DNS resolution.

-> [!TIP]

-> If you create a custom domain name, take care with existing DNS namespaces. It's recommended to use a domain name separate from any existing Azure or on-premises DNS name space.

->

-> For example, if you have an existing DNS name space of *contoso.com*, create a managed domain with the custom domain name of *aaddscontoso.com*. If you need to use secure LDAP, you must register and own this custom domain name to generate the required certificates.

->

-> You may need to create some additional DNS records for other services in your environment, or conditional DNS forwarders between existing DNS name spaces in your environment. For example, if you run a webserver that hosts a site using the root DNS name, there can be naming conflicts that require additional DNS entries.

->

-> In this sample and how-to articles, the custom domain of *aaddscontoso.com* is used as a short example. In all commands, specify your own domain name.

-The following DNS name restrictions also apply:

-* **Domain prefix restrictions:** You can't create a managed domain with a prefix longer than 15 characters. The prefix of your specified domain name (such as *aaddscontoso* in the *aaddscontoso.com* domain name) must contain 15 or fewer characters.

-* **Network name conflicts:** The DNS domain name for your managed domain shouldn't already exist in the virtual network. Specifically, check for the following scenarios that would lead to a name conflict:

- * If you already have an Active Directory domain with the same DNS domain name on the Azure virtual network.

- * If the virtual network where you plan to enable the managed domain has a VPN connection with your on-premises network. In this scenario, ensure you don't have a domain with the same DNS domain name on your on-premises network.

- * If you have an existing Azure cloud service with that name on the Azure virtual network.

-<a name='create-required-azure-ad-resources'></a>

-## Create required Microsoft Entra resources

-Domain Services requires a service principal and a Microsoft Entra group. These resources let the managed domain synchronize data, and define which users have administrative permissions in the managed domain.

-First, register the Microsoft Entra Domain Services resource provider using the [Register-AzResourceProvider][Register-AzResourceProvider] cmdlet:

-```powershell

-Register-AzResourceProvider -ProviderNamespace Microsoft.AAD

-```

-Create a Microsoft Entra service principal using the [New-AzureADServicePrincipal][New-AzureADServicePrincipal] cmdlet for Domain Services to communicate and authenticate itself. A specific application ID is used named *Domain Controller Services* with an ID of *2565bd9d-da50-47d4-8b85-4c97f669dc36* for Azure Global. For other Azure clouds, search for AppId value *6ba9a5d4-8456-4118-b521-9c5ca10cdf84*.

-```powershell

-New-AzureADServicePrincipal -AppId "2565bd9d-da50-47d4-8b85-4c97f669dc36"

-```

-Now create a Microsoft Entra group named *AAD DC Administrators* using the [New-AzureADGroup][New-AzureADGroup] cmdlet. Users added to this group are then granted permissions to perform administration tasks on the managed domain.

-```powershell

-New-AzureADGroup -DisplayName "AAD DC Administrators" `

- -Description "Delegated group to administer Azure AD Domain Services" `

- -SecurityEnabled $true -MailEnabled $false `

- -MailNickName "AADDCAdministrators"

-```

-With the *AAD DC Administrators* group created, add a user to the group using the [Add-AzureADGroupMember][Add-AzureADGroupMember] cmdlet. You first get the *AAD DC Administrators* group object ID using the [Get-AzureADGroup][Get-AzureADGroup] cmdlet, then the desired user's object ID using the [Get-AzureADUser][Get-AzureADUser] cmdlet.

-In the following example, the user object ID for the account with a UPN of `admin@contoso.onmicrosoft.com`. Replace this user account with the UPN of the user you wish to add to the *AAD DC Administrators* group:

-```powershell

-# First, retrieve the object ID of the newly created 'AAD DC Administrators' group.

-$GroupObjectId = Get-AzureADGroup `

- -Filter "DisplayName eq 'AAD DC Administrators'" | `

- Select-Object ObjectId

-# Now, retrieve the object ID of the user you'd like to add to the group.

-$UserObjectId = Get-AzureADUser `

- -Filter "UserPrincipalName eq 'admin@contoso.onmicrosoft.com'" | `

- Select-Object ObjectId

-# Add the user to the 'AAD DC Administrators' group.

-Add-AzureADGroupMember -ObjectId $GroupObjectId.ObjectId -RefObjectId $UserObjectId.ObjectId

-```

-Finally, create a resource group using the [New-AzResourceGroup][New-AzResourceGroup] cmdlet. In the following example, the resource group is named *myResourceGroup* and is created in the *westus* region. Use your own name and desired region:

-```powershell

-New-AzResourceGroup `

- -Name "myResourceGroup" `

- -Location "WestUS"

-```

-If you choose a region that supports Availability Zones, the Domain Services resources are distributed across zones for additional redundancy. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there's a minimum of three separate zones in all enabled regions.

-There's nothing for you to configure for Domain Services to be distributed across zones. The Azure platform automatically handles the zone distribution of resources. For more information and to see region availability, see [What are Availability Zones in Azure?][availability-zones].

-<a name='resource-definition-for-azure-ad-ds'></a>

-## Resource definition for Domain Services

-As part of the Resource Manager resource definition, the following configuration parameters are required:

-| Parameter | Value |

-|-||

-| domainName | The DNS domain name for your managed domain, taking into consideration the previous points on naming prefixes and conflicts. |

-| filteredSync | Domain Services lets you synchronize *all* users and groups available in Microsoft Entra ID, or a *scoped* synchronization of only specific groups.<br /><br /> For more information about scoped synchronization, see [Microsoft Entra Domain Services scoped synchronization][scoped-sync].|

-| notificationSettings | If there are any alerts generated in the managed domain, email notifications can be sent out. <br /><br />*Global administrators* of the Azure tenant and members of the *AAD DC Administrators* group can be *Enabled* for these notifications.<br /><br /> If desired, you can add additional recipients for notifications when there are alerts that require attention.|

-| domainConfigurationType | By default, a managed domain is created as a *User* forest. This type of forest synchronizes all objects from Microsoft Entra ID, including any user accounts created in an on-premises AD DS environment. You don't need to specify a *domainConfiguration* value to create a user forest.<br /><br /> A *Resource* forest only synchronizes users and groups created directly in Microsoft Entra ID. Set the value to *ResourceTrusting* to create a resource forest.<br /><br />For more information on *Resource* forests, including why you may use one and how to create forest trusts with on-premises AD DS domains, see [Domain Services resource forests overview][resource-forests].|

-The following condensed parameters definition shows how these values are declared. A user forest named *aaddscontoso.com* is created with all users from Azure AD synchronized to the managed domain:

-```json

-"parameters": {

- "domainName": {

- "value": "aaddscontoso.com"

- },

- "filteredSync": {

- "value": "Disabled"

- },

- "notificationSettings": {

- "value": {

- "notifyGlobalAdmins": "Enabled",

- "notifyDcAdmins": "Enabled",

- "additionalRecipients": []

- }

- },

- [...]

-}

-```

-The following condensed Resource Manager template resource type is then used to define and create the managed domain. An Azure virtual network and subnet must already exist, or be created as part of Resource Manager template. The managed domain is connected to this subnet.

-```json

-"resources": [

- {

- "apiVersion": "2017-06-01",

- "type": "Microsoft.AAD/DomainServices",

- "name": "[parameters('domainName')]",

- "location": "[parameters('location')]",

- "dependsOn": [

- "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'))]"

- ],

- "properties": {

- "domainName": "[parameters('domainName')]",

- "subnetId": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/virtualNetworks/', parameters('vnetName'), '/subnets/', parameters('subnetName'))]",

- "filteredSync": "[parameters('filteredSync')]",

- "notificationSettings": "[parameters('notificationSettings')]"

- }

- },

- [...]

-]

-```

-These parameters and resource type can be used as part of a wider Resource Manager template to deploy a managed domain, as shown in the following section.

-## Create a managed domain using sample template

-The following complete Resource Manager sample template creates a managed domain and the supporting virtual network, subnet, and network security group rules. The network security group rules are required to secure the managed domain and make sure traffic can flow correctly. A user forest with the DNS name of *aaddscontoso.com* is created, with all users synchronized from Microsoft Entra ID:

-```json

-{

- "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",

- "contentVersion": "1.0.0.0",

- "parameters": {

- "apiVersion": {

- "value": "2017-06-01"

- },

- "domainConfigurationType": {

- "value": "FullySynced"

- },

- "domainName": {

- "value": "aaddscontoso.com"

- },

- "filteredSync": {

- "value": "Disabled"

- },

- "location": {

- "value": "westus"

- },

- "notificationSettings": {

- "value": {

- "notifyGlobalAdmins": "Enabled",

- "notifyDcAdmins": "Enabled",

- "additionalRecipients": []

- }

- },

- "subnetName": {

- "value": "aadds-subnet"

- },

- "vnetName": {

- "value": "aadds-vnet"

- },

- "vnetAddressPrefixes": {

- "value": [

- "10.1.0.0/24"

- ]

- },

- "subnetAddressPrefix": {

- "value": "10.1.0.0/24"

- },

- "nsgName": {

- "value": "aadds-nsg"

- }

- },

- "resources": [

- {

- "apiVersion": "2017-06-01",

- "type": "Microsoft.AAD/DomainServices",

- "name": "[parameters('domainName')]",

- "location": "[parameters('location')]",

- "dependsOn": [

- "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'))]"

- ],

- "properties": {

- "domainName": "[parameters('domainName')]",

- "subnetId": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/virtualNetworks/', parameters('vnetName'), '/subnets/', parameters('subnetName'))]",

- "filteredSync": "[parameters('filteredSync')]",

- "domainConfigurationType": "[parameters('domainConfigurationType')]",

- "notificationSettings": "[parameters('notificationSettings')]"

- }

- },

- {

- "type": "Microsoft.Network/NetworkSecurityGroups",

- "name": "[parameters('nsgName')]",

- "location": "[parameters('location')]",

- "properties": {

- "securityRules": [

- {

- "name": "AllowSyncWithAzureAD",

- "properties": {

- "access": "Allow",

- "priority": 101,

- "direction": "Inbound",

- "protocol": "Tcp",

- "sourceAddressPrefix": "AzureActiveDirectoryDomainServices",

- "sourcePortRange": "*",

- "destinationAddressPrefix": "*",

- "destinationPortRange": "443"

- }

- },

- {

- "name": "AllowPSRemoting",

- "properties": {

- "access": "Allow",

- "priority": 301,

- "direction": "Inbound",

- "protocol": "Tcp",

- "sourceAddressPrefix": "AzureActiveDirectoryDomainServices",

- "sourcePortRange": "*",

- "destinationAddressPrefix": "*",

- "destinationPortRange": "5986"

- }

- },

- {

- "name": "AllowRD",

- "properties": {

- "access": "Allow",

- "priority": 201,

- "direction": "Inbound",

- "protocol": "Tcp",

- "sourceAddressPrefix": "CorpNetSaw",

- "sourcePortRange": "*",

- "destinationAddressPrefix": "*",

- "destinationPortRange": "3389"

- }

- }

- ]

- },

- "apiVersion": "2018-04-01"

- },

- {

- "type": "Microsoft.Network/virtualNetworks",

- "name": "[parameters('vnetName')]",

- "location": "[parameters('location')]",

- "apiVersion": "2018-04-01",

- "dependsOn": [

- "[concat('Microsoft.Network/NetworkSecurityGroups/', parameters('nsgName'))]"

- ],

- "properties": {

- "addressSpace": {

- "addressPrefixes": "[parameters('vnetAddressPrefixes')]"

- },

- "subnets": [

- {

- "name": "[parameters('subnetName')]",

- "properties": {

- "addressPrefix": "[parameters('subnetAddressPrefix')]",

- "networkSecurityGroup": {

- "id": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/NetworkSecurityGroups/', parameters('nsgName'))]"

- }

- }

- }

- ]

- }

- }

- ],

- "outputs": {}

-}

-```

-This template can be deployed using your preferred deployment method, such as the [Microsoft Entra admin center][portal-deploy], [Azure PowerShell][powershell-deploy], or a CI/CD pipeline. The following example uses the [New-AzResourceGroupDeployment][New-AzResourceGroupDeployment] cmdlet. Specify your own resource group name and template filename:

-```powershell

-New-AzResourceGroupDeployment -ResourceGroupName "myResourceGroup" -TemplateFile <path-to-template>

-```

-It takes a few minutes to create the resource and return control to the PowerShell prompt. The managed domain continues to be provisioned in the background, and can take up to an hour to complete the deployment. In the Microsoft Entra admin center, the **Overview** page for your managed domain shows the current status throughout this deployment stage.

-When the Microsoft Entra admin center shows that the managed domain has finished provisioning, the following tasks need to be completed:

-* Update DNS settings for the virtual network so virtual machines can find the managed domain for domain join or authentication.

- * To configure DNS, select your managed domain in the portal. On the **Overview** window, you are prompted to automatically configure these DNS settings.

-* [Enable password synchronization to Domain Services](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) so end users can sign in to the managed domain using their corporate credentials.

-## Next steps

-To see the managed domain in action, you can [domain-join a Windows VM][windows-join], [configure secure LDAP][tutorial-ldaps], and [configure password hash sync][tutorial-phs].

-<!-- INTERNAL LINKS -->

-[windows-join]: join-windows-vm.md

-[tutorial-ldaps]: tutorial-configure-ldaps.md

-[tutorial-phs]: tutorial-configure-password-hash-sync.md

-[availability-zones]: /azure/reliability/availability-zones-overview

-[portal-deploy]: /azure/azure-resource-manager/templates/deploy-portal

-[powershell-deploy]: /azure/azure-resource-manager/templates/deploy-powershell

-[scoped-sync]: scoped-synchronization.md

-[resource-forests]: ./concepts-forest-trust.md

-<!-- EXTERNAL LINKS -->

-[Connect-AzAccount]: /powershell/module/Az.Accounts/Connect-AzAccount

-[Connect-AzureAD]: /powershell/module/AzureAD/Connect-AzureAD

-[New-AzureADServicePrincipal]: /powershell/module/AzureAD/New-AzureADServicePrincipal

-[New-AzureADGroup]: /powershell/module/AzureAD/New-AzureADGroup

-[Add-AzureADGroupMember]: /powershell/module/AzureAD/Add-AzureADGroupMember

-[Get-AzureADGroup]: /powershell/module/AzureAD/Get-AzureADGroup

-[Get-AzureADUser]: /powershell/module/AzureAD/Get-AzureADUser

-[Register-AzResourceProvider]: /powershell/module/Az.Resources/Register-AzResourceProvider

-[New-AzResourceGroup]: /powershell/module/Az.Resources/New-AzResourceGroup

-[Get-AzSubscription]: /powershell/module/Az.Accounts/Get-AzSubscription

-[cloud-shell]: /azure/active-directory/develop/configure-app-multi-instancing

-[naming-prefix]: /windows-server/identity/ad-ds/plan/selecting-the-forest-root-domain

-[New-AzResourceGroupDeployment]: /powershell/module/az.resources/new-azresourcegroupdeployment

-description: Learn how to troubleshoot common problems that cause user accounts to be locked out in Microsoft Entra Domain Services.

-#Customer intent: As a directory administrator, I want to troubleshoot why user accounts are locked out in a Microsoft Entra Domain Services managed domain.

-# Troubleshoot account lockout problems with a Microsoft Entra Domain Services managed domain

-To prevent repeated malicious sign-in attempts, a Microsoft Entra Domain Services managed domain locks accounts after a defined threshold. This account lockout can also happen by accident without a sign-in attack incident. For example, if a user repeatedly enters the wrong password or a service attempts to use an old password, the account gets locked out.

-This troubleshooting article outlines why account lockouts happen and how you can configure the behavior, and how to review security audits to troubleshoot lockout events.

-## What is an account lockout?

-A user account in a Domain Services managed domain is locked out when a defined threshold for unsuccessful sign-in attempts has been met. This account lockout behavior is designed to protect you from repeated brute-force sign-in attempts that may indicate an automated digital attack.

-**By default, if there are 5 bad password attempts in 2 minutes, the account is locked out for 30 minutes.**

-The default account lockout thresholds are configured using fine-grained password policy. If you have a specific set of requirements, you can override these default account lockout thresholds. However, it's not recommended to increase the threshold limits to try to reduce the number account lockouts. Troubleshoot the source of the account lockout behavior first.

-### Fine-grained password policy

-Fine-grained password policies (FGPPs) let you apply specific restrictions for password and account lockout policies to different users in a domain. FGPP only affects users within a managed domain. Cloud users and domain users synchronized into the managed domain from Microsoft Entra ID are only affected by the password policies within the managed domain. Their accounts in Microsoft Entra ID or an on-premises directory aren't impacted.

-Policies are distributed through group association in the managed domain, and any changes you make are applied at the next user sign-in. Changing the policy doesn't unlock a user account that's already locked out.

-For more information on fine-grained password policies, and the differences between users created directly in Domain Services versus synchronized in from Microsoft Entra ID, see [Configure password and account lockout policies][configure-fgpp].

-## Common account lockout reasons

-The most common reasons for an account to be locked out, without any malicious intent or factors, include the following scenarios:

-* **The user locked themselves out.**

- * After a recent password change, has the user continued to use a previous password? The default account lockout policy of five failed attempts in 2 minutes can be caused by the user inadvertently retrying an old password.

-* **There's an application or service that has an old password.**

- * If an account is used by applications or services, those resources may repeatedly try to sign in using an old password. This behavior causes the account to be locked out.

- * Try to minimize account use across multiple different applications or services, and record where credentials are used. If an account password is changed, update the associated applications or services accordingly.

-* **Password has been changed in a different environment and the new password hasn't synchronized yet.**

- * If an account password is changed outside of the managed domain, such as in an on-prem AD DS environment, it can take a few minutes for the password change to synchronize through Microsoft Entra ID and into the managed domain.

- * A user that tries to sign in to a resource in the managed domain before that password synchronization process has completed causes their account to be locked out.

-## Troubleshoot account lockouts with security audits

-To troubleshoot when account lockout events occur and where they're coming from, [enable security audits for Domain Services][security-audit-events]. Audit events are only captured from the time you enable the feature. Ideally, you should enable security audits *before* there's an account lockout issue to troubleshoot. If a user account repeatedly has lockout issues, you can enable security audits ready for the next time the situation occurs.

-Once you have enabled security audits, the following sample queries show you how to review *Account Lockout Events*, code *4740*.

-View all the account lockout events for the last seven days:

-```Kusto

-AADDomainServicesAccountManagement

-| where TimeGenerated >= ago(7d)

-| where OperationName has "4740"

-```

-View all the account lockout events for the last seven days for the account named *driley*.

-```Kusto

-AADDomainServicesAccountLogon

-| where TimeGenerated >= ago(7d)

-| where OperationName has "4740"

-| where "driley" == tolower(extract("Logon Account:\t(.+[0-9A-Za-z])",1,tostring(ResultDescription)))

-```

-View all the account lockout events between June 26, 2020 at 9 a.m. and July 1, 2020 midnight, sorted ascending by the date and time:

-```Kusto

-AADDomainServicesAccountManagement

-| where TimeGenerated >= datetime(2020-06-26 09:00) and TimeGenerated <= datetime(2020-07-01)

-| where OperationName has "4740"

-| sort by TimeGenerated asc

-```

-You may find on 4776 and 4740 event details of "Source Workstation: " empty. This is because the bad password happened over Network logon via some other devices.

-For example, a RADIUS server can forward the authentication to Domain Services.

-03/04 19:07:29 [LOGON] [10752] contoso: SamLogon: Transitive Network logon of contoso\Nagappan.Veerappan from (via LOB11-RADIUS) Entered

-03/04 19:07:29 [LOGON] [10752] contoso: SamLogon: Transitive Network logon of contoso\Nagappan.Veerappan from (via LOB11-RADIUS) Returns 0xC000006A

-03/04 19:07:35 [LOGON] [10753] contoso: SamLogon: Transitive Network logon of contoso\Nagappan.Veerappan from (via LOB11-RADIUS) Entered

-03/04 19:07:35 [LOGON] [10753] contoso: SamLogon: Transitive Network logon of contoso\Nagappan.Veerappan from (via LOB11-RADIUS) Returns 0xC000006A

-Enable RDP to your DCs in NSG to backend to configure diagnostics capture (netlogon). For more information about requirements, see

-[Inbound security rules](alert-nsg.md#inbound-security-rules).

-If you have modified the default NSG already, follow [Port 3389 - management using remote desktop](network-considerations.md#port-3389management-using-remote-desktop).

-To enable Netlogon log on any server, follow [Enabling debug logging for the Netlogon service](/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service).

-## Next steps

-For more information on fine-grained password policies to adjust account lockout thresholds, see [Configure password and account lockout policies][configure-fgpp].

-If you still have problems joining your VM to the managed domain, [find help and open a support ticket for Microsoft Entra ID][azure-ad-support].

-<!-- INTERNAL LINKS -->

-[configure-fgpp]: password-policy.md

-[security-audit-events]: security-audit-events.md

-[azure-ad-support]: /azure/active-directory/fundamentals/how-to-get-support

-description: Learn how to resolve common alerts generated as part of the health status for Microsoft Entra Domain Services

-# Known issues: Common alerts and resolutions in Microsoft Entra Domain Services

-As a central part of identity and authentication for applications, Microsoft Entra Domain Services sometimes has problems. If you run into issues, there are some common alerts and associated troubleshooting steps to help you get things running again. At any time, you can also [open an Azure support request][azure-support] for more troubleshooting help.

-This article provides troubleshooting information for common alerts in Domain Services.

-## AADDS100: Missing directory

-### Alert message

-*The Microsoft Entra directory associated with your managed domain may have been deleted. The managed domain is no longer in a supported configuration. Microsoft cannot monitor, manage, patch, and synchronize your managed domain.*

-### Resolution

-This error is usually caused when an Azure subscription is moved to a new Microsoft Entra directory and the old Microsoft Entra directory that's associated with Domain Services is deleted.

-This error is unrecoverable. To resolve the alert, [delete your existing managed domain](delete-aadds.md) and recreate it in your new directory. If you have trouble deleting the managed domain, [open an Azure support request][azure-support] for more troubleshooting help.

-## AADDS101: Azure AD B2C is running in this directory

-### Alert message

-*Microsoft Entra Domain Services cannot be enabled in an Azure AD B2C Directory.*

-### Resolution

-Domain Services automatically synchronizes with a Microsoft Entra directory. If the Microsoft Entra directory is configured for B2C, Domain Services can't be deployed and synchronized.

-To use Domain Services, you must recreate your managed domain in a non-Azure AD B2C directory using the following steps:

-1. [Delete the managed domain](delete-aadds.md) from your existing Microsoft Entra directory.

-1. Create a new Microsoft Entra directory that isn't an Azure AD B2C directory.

-1. [Create a replacement managed domain](tutorial-create-instance.md).

-The managed domain's health automatically updates itself within two hours and removes the alert.

-## AADDS103: Address is in a public IP range

-### Alert message

-*The IP address range for the virtual network in which you have enabled Microsoft Entra Domain Services is in a public IP range. Microsoft Entra Domain Services must be enabled in a virtual network with a private IP address range. This configuration impacts Microsoft's ability to monitor, manage, patch, and synchronize your managed domain.*

-### Resolution

-Before you begin, make sure you understand [private IP v4 address spaces](https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces).

-Inside a virtual network, VMs can make requests to Azure resources in the same IP address range as configured for the subnet. If you configure a public IP address range for a subnet, requests routed within a virtual network may not reach the intended web resources. This configuration can lead to unpredictable errors with Domain Services.

-> [!NOTE]

-> If you own the IP address range in the internet that is configured in your virtual network, this alert can be ignored. However, Microsoft Entra Domain Services can't commit to the [SLA](https://azure.microsoft.com/support/legal/sla/active-directory-ds/v1_0/) with this configuration since it can lead to unpredictable errors.

-To resolve this alert, delete your existing managed domain and recreate it in a virtual network with a private IP address range. This process is disruptive as the managed domain is unavailable and any custom resources you've created like OUs or service accounts are lost.

-1. [Delete the managed domain](delete-aadds.md) from your directory.

-1. To update the virtual network IP address range, search for and select *Virtual network* in the Microsoft Entra admin center. Select the virtual network for Domain Services that incorrectly has a public IP address range set.

-1. Under **Settings**, select *Address Space*.

-1. Update the address range by choosing the existing address range and editing it, or by adding an address range. Make sure the new IP address range is in a private IP range. When ready, **Save** the changes.

-1. Select **Subnets** in the left-hand navigation.

-1. Choose the subnet you wish to edit, or create another subnet.

-1. Update or specify a private IP address range then **Save** your changes.

-1. [Create a replacement managed domain](tutorial-create-instance.md). Make sure you pick the updated virtual network subnet with a private IP address range.

-The managed domain's health automatically updates itself within two hours and removes the alert.

-## AADDS106: Your Azure subscription is not found

-### Alert message

-*Your Azure subscription associated with your managed domain has been deleted. Microsoft Entra Domain Services requires an active subscription to continue functioning properly.*

-### Resolution

-Domain Services requires an active subscription, and can't be moved to a different subscription. If the Azure subscription that the managed domain was associated with is deleted, you must recreate an Azure subscription and managed domain.

-1. [Create an Azure subscription](/azure/cost-management-billing/manage/create-subscription).

-1. [Delete the managed domain](delete-aadds.md) from your existing Microsoft Entra directory.

-1. [Create a replacement managed domain](tutorial-create-instance.md).

-## AADDS107: Your Azure subscription is disabled

-### Alert message

-*Your Azure subscription associated with your managed domain is not active. Microsoft Entra Domain Services requires an active subscription to continue functioning properly.*

-### Resolution

-Domain Services requires an active subscription. If the Azure subscription that the managed domain was associated with isn't active, you must renew it to reactivate the subscription.

-1. [Renew your Azure subscription](/azure/cost-management-billing/manage/subscription-disabled).

-2. Once the subscription is renewed, a Domain Services notification lets you re-enable the managed domain.

-When the managed domain is enabled again, the managed domain's health automatically updates itself within two hours and removes the alert.

-## AADDS108: Subscription moved directories

-### Alert message

-*The subscription used by Microsoft Entra Domain Services has been moved to another directory. Microsoft Entra Domain Services needs to have an active subscription in the same directory to function properly.*

-### Resolution

-Domain Services requires an active subscription, and can't be moved to a different subscription. If the Azure subscription that the managed domain was associated with is moved, move the subscription back to the previous directory, or [delete your managed domain](delete-aadds.md) from the existing directory and [create a replacement managed domain in the chosen subscription](tutorial-create-instance.md).

-## AADDS109: Resources for your managed domain cannot be found

-### Alert message

-*A resource that is used for your managed domain has been deleted. This resource is needed for Microsoft Entra Domain Services to function properly.*

-### Resolution

-Domain Services creates resources to function properly, such as public IP addresses, virtual network interfaces, and a load balancer. If any of these resources are deleted, the managed domain is in an unsupported state and prevents the domain from being managed. For more information on these resources, see [Network resources used by Domain Services](network-considerations.md#network-resources-used-by-azure-ad-ds).

-This alert is generated when one of these required resources is deleted. If the resource was deleted less than 4 hours ago, there's a chance that the Azure platform can automatically recreate the deleted resource. The following steps outline how to check the health status and timestamp for resource deletion:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Domain Services**. Choose your managed domain, such as *aaddscontoso.com*.

-1. In the left-hand navigation, select **Health**.

-1. In the health page, select the alert with the ID *AADDS109*.

-1. The alert has a timestamp for when it was first found. If that timestamp is less than 4 hours ago, the Azure platform may be able to automatically recreate the resource and resolve the alert by itself.

- For different reasons, the alert may be older than 4 hours. In that case, you can [delete the managed domain](delete-aadds.md) and then [create a replacement managed domain](tutorial-create-instance.md) for an immediate fix, or you can open a support request to fix the instance. Depending on the nature of the problem, support may require a restore from backup.

-## AADDS110: The subnet associated with your managed domain is full

-### Alert message

-*The subnet selected for deployment of Microsoft Entra Domain Services is full, and does not have space for the additional domain controller that needs to be created.*

-### Resolution

-The virtual network subnet for Domain Services needs sufficient IP addresses for the automatically created resources. This IP address space includes the need to create replacement resources if there's a maintenance event. To minimize the risk of running out of available IP addresses, don't deploy other resources, such as your own VMs, into the same virtual network subnet as the managed domain.

-This error is unrecoverable. To resolve the alert, [delete your existing managed domain](delete-aadds.md) and recreate it. If you have trouble deleting the managed domain, [open an Azure support request][azure-support] for more help.

-## AADDS111: Service principal unauthorized

-### Alert message

-*A service principal that Microsoft Entra Domain Services uses to service your domain is not authorized to manage resources on the Azure subscription. The service principal needs to gain permissions to service your managed domain.*

-### Resolution

-Some automatically generated service principals are used to manage and create resources for a managed domain. If the access permissions for one of these service principals is changed, the domain is unable to correctly manage resources. The following steps show you how to understand and then grant access permissions to a service principal:

-1. Read about [Azure role-based access control and how to grant access to applications in the Microsoft Entra admin center](/azure/role-based-access-control/role-assignments-portal).

-2. Review the access that the service principal with the ID *abba844e-bc0e-44b0-947a-dc74e5d09022* has and grant the access that was denied at an earlier date.

-## AADDS112: Not enough IP address in the managed domain

-### Alert message

-*We have identified that the subnet of the virtual network in this domain may not have enough IP addresses. Microsoft Entra Domain Services needs at-least two available IP addresses within the subnet it is enabled in. We recommend having at-least 3-5 spare IP addresses within the subnet. This may have occurred if other virtual machines are deployed within the subnet, thus exhausting the number of available IP addresses or if there is a restriction on the number of available IP addresses in the subnet.*

-### Resolution

-The virtual network subnet for Domain Services needs enough IP addresses for the automatically created resources. This IP address space includes the need to create replacement resources if there's a maintenance event. To minimize the risk of running out of available IP addresses, don't deploy other resources, such as your own VMs, into the same virtual network subnet as the managed domain.

-To resolve this alert, delete your existing managed domain and re-create it in a virtual network with a large enough IP address range. This process is disruptive as the managed domain is unavailable and any custom resources you've created like OUs or service accounts are lost.

-1. [Delete the managed domain](delete-aadds.md) from your directory.

-1. To update the virtual network IP address range, search for and select *Virtual network* in the Microsoft Entra admin center. Select the virtual network for the managed domain that has the small IP address range.

-1. Under **Settings**, select *Address Space*.

-1. Update the address range by choosing the existing address range and editing it, or by adding another address range. Make sure the new IP address range is large enough for the managed domain's subnet range. When ready, **Save** the changes.

-1. Select **Subnets** in the left-hand navigation.

-1. Choose the subnet you wish to edit, or create another subnet.

-1. Update or specify a large enough IP address range then **Save** your changes.

-1. [Create a replacement managed domain](tutorial-create-instance.md). Make sure you pick the updated virtual network subnet with a large enough IP address range.

-The managed domain's health automatically updates itself within two hours and removes the alert.

-## AADDS113: Resources are unrecoverable

-### Alert message

-*The resources used by Microsoft Entra Domain Services were detected in an unexpected state and cannot be recovered.*

-### Resolution

-Domain Services creates resources to function properly, such as public IP addresses, virtual network interfaces, and a load balancer. If any of these resources are modified, the managed domain is in an unsupported state and can't be managed. For more information about these resources, see [Network resources used by Domain Services](network-considerations.md#network-resources-used-by-azure-ad-ds).

-This alert is generated when one of these required resources is modified and can't automatically be recovered by Domain Services. To resolve the alert, [open an Azure support request][azure-support] to fix the instance.

-## AADDS114: Subnet invalid

-### Alert message

-*The subnet selected for deployment of Microsoft Entra Domain Services is invalid, and cannot be used.*

-### Resolution

-This error is unrecoverable. To resolve the alert, [delete your existing managed domain](delete-aadds.md) and recreate it. If you have trouble deleting the managed domain, [open an Azure support request][azure-support] for more help.

-## AADDS115: Resources are locked

-### Alert message

-*One or more of the network resources used by the managed domain cannot be operated on as the target scope has been locked.*

-### Resolution

-Resource locks can be applied to Azure resources to prevent change or deletion. As Domain Services is a managed service, the Azure platform needs the ability to make configuration changes. If a resource lock is applied on some of the Domain Services components, the Azure platform can't perform its management tasks.

-To check for resource locks on the Domain Services components and remove them, complete the following steps:

-1. For each of the managed domain's network components in your resource group, such as virtual network, network interface, or public IP address, check the operation logs in the Microsoft Entra admin center. These operation logs should indicate why an operation is failing and where a resource lock is applied.

-1. Select the resource where a lock is applied, then under **Locks**, select and remove the lock(s).

-## AADDS116: Resources are unusable

-### Alert message

-*One or more of the network resources used by the managed domain cannot be operated on due to policy restriction(s).*

-### Resolution

-Policies are applied to Azure resources and resource groups that control what configuration actions are allowed. As Domain Services is a managed service, the Azure platform needs the ability to make configuration changes. If a policy is applied on some of the Domain Services components, the Azure platform may not be able to perform its management tasks.

-To check for applied policies on the Domain Services components and update them, complete the following steps:

-1. For each of the managed domain's network components in your resource group, such as virtual network, NIC, or public IP address, check the operation logs in the Microsoft Entra admin center. These operation logs should indicate why an operation is failing and where a restrictive policy is applied.

-1. Select the resource where a policy is applied, then under **Policies**, select and edit the policy so it's less restrictive.

-## AADDS120: The managed domain has encountered an error onboarding one or more custom attributes

-### Alert message

-*The following Microsoft Entra extension properties have not successfully onboarded as a custom attribute for synchronization. This may happen if a property conflicts with the built-in schema: \[extensions]*

-### Resolution

->[!WARNING]

->If a custom attribute's LDAPName conflicts with an existing AD built-in schema attribute, it can't be onboarded and results in an error. Contact Microsoft Support if your scenario is blocked. For more information, see [Onboarding Custom Attributes](https://aka.ms/aadds-customattr).

-Review the [Domain Services Health](check-health.md) alert and see which Microsoft Entra extension properties failed to onboard successfully. Navigate to the **Custom Attributes** page to find the expected Domain Services LDAPName of the extension. Make sure the LDAPName doesn't conflict with another AD schema attribute, or that it's one of the allowed built-in AD attributes.

-Then follow these steps to retry onboarding the custom attribute in the **Custom Attributes** page:

-1. Select the attributes that were unsuccessful, then click **Remove** and **Save**.

-1. Wait for the health alert to be removed, or verify that the corresponding attributes have been removed from the **AADDSCustomAttributes** OU from a domain-joined VM.

-1. Select **Add** and choose the desired attributes again, then click **Save**.

-Upon successful onboarding, Domain Services will back fill synchronized users and groups with the onboarded custom attribute values. The custom attribute values appear gradually, depending on the size of the tenant. To check the backfill status, go to [Domain Services Health](check-health.md) and verify the **Synchronization with Microsoft Entra ID** monitor timestamp has updated within the last hour.

-## AADDS500: Synchronization has not completed in a while

-### Alert message

-*The managed domain was last synchronized with Microsoft Entra ID on [date]. Users may be unable to sign-in on the managed domain or group memberships may not be in sync with Azure AD.*

-### Resolution

-[Check the Domain Services health](check-health.md) for any alerts that indicate problems in the configuration of the managed domain. Problems with the network configuration can block the synchronization from Microsoft Entra ID. If you're able to resolve alerts that indicate a configuration issue, wait two hours and check back to see if the synchronization has successfully completed.

-The following common reasons cause synchronization to stop in a managed domain:

-* Required network connectivity is blocked. To learn more about how to check the Azure virtual network for problems and what's required, see [troubleshoot network security groups](alert-nsg.md) and the [network requirements for Domain Services](network-considerations.md).

-* Password synchronization wasn't set up or successfully completed when the managed domain was deployed. You can set up password synchronization for [cloud-only users](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) or [hybrid users from on-prem](tutorial-configure-password-hash-sync.md).

-## AADDS501: A backup has not been taken in a while

-### Alert message

-*The managed domain was last backed up on [date].*

-### Resolution

-[Check the Domain Services health](check-health.md) for alerts that indicate problems in the configuration of the managed domain. Problems with the network configuration can block the Azure platform from successfully taking backups. If you're able to resolve alerts that indicate a configuration issue, wait two hours and check back to see if the synchronization has successfully completed.

-## AADDS503: Suspension due to disabled subscription

-### Alert message

-*The managed domain is suspended because the Azure subscription associated with the domain is not active.*

-### Resolution

-> [!WARNING]

-> If a managed domain is suspended for an extended period of time, there's a danger of it being deleted. Resolve the reason for suspension as quickly as possible. For more information, see [Understand the suspended states for Domain Services](suspension.md).

-Domain Services requires an active subscription. If the Azure subscription that the managed domain was associated with isn't active, you must renew it to reactivate the subscription.

-1. [Renew your Azure subscription](/azure/cost-management-billing/manage/subscription-disabled).

-2. Once the subscription is renewed, a Domain Services notification lets you re-enable the managed domain.

-When the managed domain is enabled again, the managed domain's health automatically updates itself within two hours and removes the alert.

-## AADDS504: Suspension due to an invalid configuration

-### Alert message

-*The managed domain is suspended due to an invalid configuration. The service has been unable to manage, patch, or update the domain controllers for your managed domain for a long time.*

-### Resolution

-> [!WARNING]

-> If a managed domain is suspended for an extended period of time, there's a danger of it being deleted. Resolve the reason for suspension as quickly as possible. For more information, see [Understand the suspended states for Domain Services](suspension.md).

-[Check the Domain Services health](check-health.md) for alerts that indicate problems in the configuration of the managed domain. If you're able to resolve alerts that indicate a configuration issue, wait two hours and check back to see if the synchronization has completed. When ready, [open an Azure support request][azure-support] to re-enable the managed domain.

-## AADDS600: Unresolved health alerts for 30 days

-### Alert Message

-*Microsoft canΓÇÖt manage the domain controllers for this managed domain due to unresolved health alerts \[IDs\]. This is blocking critical security updates as well as a planned migration to Windows Server 2019 for these domain controllers. Follow steps in the alert to resolve the issue. Failure to resolve this issue within 30 days will result in suspension of the managed domain.*

-### Resolution

-> [!WARNING]

-> If a managed domain is suspended for an extended period of time, there's a danger of it being deleted. Resolve the reason for suspension as quickly as possible. For more information, see [Understand the suspended states for Domain Services](suspension.md).

-[Check the Domain Services health](check-health.md) for alerts that indicate problems in the configuration of the managed domain. If you're able to resolve alerts that indicate a configuration issue, wait six hours and check back to see if the alert is removed. [Open an Azure support request][azure-support] if you need assistance.

-## Next steps

-If you still have issues, [open an Azure support request][azure-support] for more troubleshooting help.

-<!-- INTERNAL LINKS -->

-[azure-support]: /azure/active-directory/fundamentals/how-to-get-support

-description: Learn how to troubleshoot common problems when you try to domain-join a VM or connect an application to Microsoft Entra Domain Services and you can't connect or authenticate to the managed domain.

-#Customer intent: As a directory administrator, I want to troubleshoot why VMs can't join a Microsoft Entra Domain Services managed domain.

-# Troubleshoot domain-join problems with a Microsoft Entra Domain Services managed domain

-When you try to join a virtual machine (VM) or connect an application to a Microsoft Entra Domain Services managed domain, you may get an error that you're unable to do so. To troubleshoot domain-join problems, review at which of the following points you have an issue:

-* If you don't receive an authentication prompt, the VM or application can't connect to the Domain Services managed domain.

- * Start to troubleshoot [connectivity issues for domain-join](#connectivity-issues-for-domain-join).

-* If you receive an error during authentication, the connection to the managed domain is successful.

- * Start to troubleshoot [credentials-related issues during domain-join](#credentials-related-issues-during-domain-join).

-## Connectivity issues for domain-join

-If the VM can't find the managed domain, there's usually a network connection or configuration issue. Review the following troubleshooting steps to locate and resolve the issue:

-1. Ensure the VM is connected to the same, or a peered, virtual network as the managed domain. If not, the VM can't find and connect to the domain in order to join.

- * If the VM isn't connected to the same virtual network, confirm that the virtual networking peering or VPN connection is *Active* or *Connected* to allow the traffic to flow correctly.

-1. Try to ping the domain using the domain name of the managed domain, such as `ping aaddscontoso.com`.

- * If the ping response fails, try to ping the IP addresses for the domain displayed on the overview page in the portal for your managed domain, such as `ping 10.0.0.4`.

- * If you can successfully ping the IP address but not the domain, DNS may be incorrectly configured. Make sure that you've [configured the managed domain DNS servers for the virtual network][configure-dns].

-1. Try flushing the DNS resolver cache on the virtual machine, such as `ipconfig /flushdns`.

-### Network Security Group (NSG) configuration

-When you create a managed domain, a network security group is also created with the appropriate rules for successful domain operation. If you edit or create additional network security group rules, you may unintentionally block ports required for Domain Services to provide connection and authentication services. These network security group rules can cause issues such as password sync not completing, users not being able to sign in, or domain-join issues.

-If you continue to have connection issues, review the following troubleshooting steps:

-1. Check the health status of your managed domain in the Azure portal. If you have an alert for *AADDS001*, a network security group rule is blocking access.

-1. Review the [required ports and network security group rules][network-ports]. Make sure that no network security group rules applied to the VM or virtual network you're connecting from block these network ports.

-1. Once any network security group configuration issues are resolved, the *AADDS001* alert disappears from the health page in about 2 hours. With network connectivity now available, try to domain-join the VM again.

-## Credentials-related issues during domain-join

-If you get a dialog box that asks for credentials to join the managed domain, the VM is able to connect to the domain using the Azure virtual network. The domain-join process fails on authenticating to the domain or authorization to complete the domain-join process using the credentials provides.

-To troubleshoot credentials-related issues, review the following troubleshooting steps:

-1. Try using the UPN format to specify credentials, such as `dee@contoso.onmicrosoft.com`. Make sure that this UPN is configured correctly in Microsoft Entra ID.

- * The *SAMAccountName* for your account may be autogenerated if there are multiple users with the same UPN prefix in your tenant or if your UPN prefix is overly long. Therefore, the *SAMAccountName* format for your account may be different from what you expect or use in your on-premises domain.

-1. Try to use the credentials for a user account that's a part of the managed domain to join VMs to the managed domain.

-1. Make sure that you've [enabled password synchronization][enable-password-sync] and waited long enough for the initial password sync to complete.

-## Next steps

-For a deeper understanding of the Active Directory processes as part of the domain-join operation, see [Join and authentication issues][join-authentication-issues].

-If you still have problems joining your VM to the managed domain, [find help and open a support ticket for Microsoft Entra ID][azure-ad-support].

-<!-- INTERNAL LINKS -->

-[enable-password-sync]: tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds

-[network-ports]: network-considerations.md#network-security-groups-and-required-ports

-[azure-ad-support]: /azure/active-directory/fundamentals/how-to-get-support

-[configure-dns]: tutorial-create-instance.md#update-dns-settings-for-the-azure-virtual-network

-<!-- EXTERNAL LINKS -->

-[join-authentication-issues]: /previous-versions/windows/it-pro/windows-2000-server/cc961817(v=technet.10)

-description: Learn how to troubleshoot common user sign-in problems and errors in Microsoft Entra Domain Services.

-#Customer intent: As a directory administrator, I want to troubleshoot user account sign in problems in a Microsoft Entra Domain Services managed domain.

-# Troubleshoot account sign-in problems with a Microsoft Entra Domain Services managed domain

-The most common reasons for a user account that can't sign in to a Microsoft Entra Domain Services managed domain include the following scenarios:

-* [The account isn't synchronized into Domain Services yet.](#account-isnt-synchronized-into-azure-ad-ds-yet)

-* [Domain Services doesn't have the password hashes to let the account sign in.](#azure-ad-ds-doesnt-have-the-password-hashes)

-* [The account is locked out.](#the-account-is-locked-out)

-> [!TIP]

-> Domain Services can't synchronize in credentials for accounts that are external to the Microsoft Entra tenant. External users can't sign in to the Domain Services managed domain.

-<a name='account-isnt-synchronized-into-azure-ad-ds-yet'></a>

-## Account isn't synchronized into Domain Services yet

-Depending on the size of your directory, it may take a while for user accounts and credential hashes to be available in a managed domain. For large directories, this initial one-way sync from Microsoft Entra ID can take few hours, and up to a day or two. Make sure that you wait long enough before retrying authentication.

-For hybrid environments that user Microsoft Entra Connect to synchronize on-premises directory data into Microsoft Entra ID, make sure that you run the latest version of Microsoft Entra Connect and have [configured Microsoft Entra Connect to perform a full synchronization after enabling Domain Services][azure-ad-connect-phs]. If you disable Domain Services and then re-enable, you have to follow these steps again.

-If you continue to have issues with accounts not synchronizing through Microsoft Entra Connect, restart the Azure AD Sync Service. From the computer with Microsoft Entra Connect installed, open a command prompt window, then run the following commands:

-```console

-net stop 'Microsoft Azure AD Sync'

-net start 'Microsoft Azure AD Sync'

-```

-<a name='azure-ad-ds-doesnt-have-the-password-hashes'></a>

-## Domain Services doesn't have the password hashes

-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.

-### Hybrid environments with on-premises synchronization

-For hybrid environments using Microsoft Entra Connect to synchronize from an on-premises AD DS environment, you can locally generate and synchronize the required NTLM or Kerberos password hashes into Microsoft Entra ID. After you create your managed domain, [enable password hash synchronization to Microsoft Entra Domain Services][azure-ad-connect-phs]. Without completing this password hash synchronization step, you can't sign in to an account using the managed domain. If you disable Domain Services and then re-enable, you have to follow those steps again.

-For more information, see [How password hash synchronization works for Domain Services][phs-process].

-### Cloud-only environments with no on-premises synchronization

-Managed domains with no on-premises synchronization, only accounts in Microsoft Entra ID, also need to generate the required NTLM or Kerberos password hashes. If a cloud-only account can't sign in, has a password change process successfully completed for the account after enabling Domain Services?

-* **No, the password has not been changed.**

- * [Change the password for the account][enable-user-accounts] to generate the required password hashes, then wait for 15 minutes before you try to sign in again.

- * If you disable Domain Services and then re-enable, each account must follow the steps again to change their password and generate the required password hashes.

-* **Yes, the password has been changed.**

- * Try to sign in using the *UPN* format, such as `driley@aaddscontoso.com`, instead of the *SAMAccountName* format like `AADDSCONTOSO\deeriley`.

- * The *SAMAccountName* may be automatically generated for users whose UPN prefix is overly long or is the same as another user on the managed domain. The *UPN* format is guaranteed to be unique within a Microsoft Entra tenant.

-## The account is locked out

-A user account in a managed domain is locked out when a defined threshold for unsuccessful sign-in attempts has been met. This account lockout behavior is designed to protect you from repeated brute-force sign-in attempts that may indicate an automated digital attack.

-By default, if there are 5 bad password attempts in 2 minutes, the account is locked out for 30 minutes.

-For more information and how to resolve account lockout issues, see [Troubleshoot account lockout problems in Domain Services][troubleshoot-account-lockout].

-## Next steps

-If you still have problems joining your VM to the managed domain, [find help and open a support ticket for Microsoft Entra ID][azure-ad-support].

-<!-- INTERNAL LINKS -->

-[troubleshoot-account-lockout]: troubleshoot-account-lockout.md

-[azure-ad-connect-phs]: ./tutorial-configure-password-hash-sync.md

-[enable-user-accounts]: tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds

-[phs-process]: /azure/active-directory/hybrid/connect/how-to-connect-password-hash-synchronization#password-hash-sync-process-for-azure-ad-domain-services

-[azure-ad-support]: /azure/active-directory/fundamentals/how-to-get-support

-description: Learn how to troubleshoot common errors when you create or manage Microsoft Entra Domain Services

-# Common errors and troubleshooting steps for Microsoft Entra Domain Services

-As a central part of identity and authentication for applications, Microsoft Entra Domain Services sometimes has problems. If you run into issues, there are some common error messages and associated troubleshooting steps to help you get things running again. At any time, you can also [open an Azure support request][azure-support] for more troubleshooting help.

-This article provides troubleshooting steps for common issues in Domain Services.

-<a name='you-cannot-enable-azure-ad-domain-services-for-your-azure-ad-directory'></a>

-## You cannot enable Microsoft Entra Domain Services for your Microsoft Entra directory

-If you have problems enabling Domain Services, review the following common errors and steps to resolve them:

-| **Sample error Message** | **Resolution** |

-| |: |

-| *The name aaddscontoso.com is already in use on this network. Specify a name that is not in use.* |[Domain name conflict in the virtual network](troubleshoot.md#domain-name-conflict) |

-| *Domain Services could not be enabled in this Microsoft Entra tenant. The service does not have adequate permissions to the application called Microsoft Entra Domain Services Sync. Delete the application called 'Microsoft Entra Domain Services Sync' and then try to enable Domain Services for your Microsoft Entra tenant.* |[Domain Services doesn't have adequate permissions to the Microsoft Entra Domain Services Sync application](troubleshoot.md#inadequate-permissions) |

-| *Domain Services could not be enabled in this Microsoft Entra tenant. The Domain Services application in your Microsoft Entra tenant does not have the required permissions to enable Domain Services. Delete the application with the application identifier d87dcbc6-a371-462e-88e3-28ad15ec4e64 and then try to enable Domain Services for your Microsoft Entra tenant.* |[The Domain Services application isn't configured properly in your Microsoft Entra tenant](troubleshoot.md#invalid-configuration) |

-| *Domain Services could not be enabled in this Microsoft Entra tenant. The Microsoft Entra application is disabled in your Microsoft Entra tenant. Enable the application with the application identifier 00000002-0000-0000-c000-000000000000 and then try to enable Domain Services for your Microsoft Entra tenant.* |[The Microsoft Graph application is disabled in your Microsoft Entra tenant](troubleshoot.md#microsoft-graph-disabled) |

-### Domain Name conflict

-**Error message**

-*The name aaddscontoso.com is already in use on this network. Specify a name that is not in use.*

-**Resolution**

-Check that you don't have an existing AD DS environment with the same domain name on the same, or a peered, virtual network. For example, you may have an AD DS domain named *aaddscontoso.com* that runs on Azure VMs. When you try to enable a Domain Services managed domain with the same domain name of *aaddscontoso.com* on the virtual network, the requested operation fails.

-This failure is due to name conflicts for the domain name on the virtual network. A DNS lookup checks if an existing AD DS environment responds on the requested domain name. To resolve this failure, use a different name to set up your managed domain, or deprovision the existing AD DS domain and then try again to enable Domain Services.

-### Inadequate permissions

-**Error message**

-*Domain Services could not be enabled in this Microsoft Entra tenant. The service does not have adequate permissions to the application called Microsoft Entra Domain Services Sync. Delete the application called 'Microsoft Entra Domain Services Sync' and then try to enable Domain Services for your Microsoft Entra tenant.*

-**Resolution**

-Check if there's an application named *Microsoft Entra Domain Services Sync* in your Microsoft Entra directory. If this application exists, delete it, then try again to enable Domain Services. To check for an existing application and delete it if needed, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), select **Microsoft Entra ID** from the left-hand navigation menu.

-1. Select **Enterprise applications**. Choose *All applications* from the **Application Type** drop-down menu, then select **Apply**.

-1. In the search box, enter *Microsoft Entra Domain Services Sync*. If the application exists, select it and choose **Delete**.

-1. Once you've deleted the application, try to enable Domain Services again.

-### Invalid configuration

-**Error message**

-*Domain Services could not be enabled in this Microsoft Entra tenant. The Domain Services application in your Microsoft Entra tenant does not have the required permissions to enable Domain Services. Delete the application with the application identifier d87dcbc6-a371-462e-88e3-28ad15ec4e64 and then try to enable Domain Services for your Microsoft Entra tenant.*

-**Resolution**

-Check if you have an existing application named *AzureActiveDirectoryDomainControllerServices* with an application identifier of *d87dcbc6-a371-462e-88e3-28ad15ec4e64* in your Microsoft Entra directory. If this application exists, delete it and then try again to enable Domain Services.

-Use the following PowerShell script to search for an existing application instance and delete it if needed:

-```powershell

-$InformationPreference = "Continue"

-$WarningPreference = "Continue"

-$aadDsSp = Get-AzureADServicePrincipal -Filter "AppId eq 'd87dcbc6-a371-462e-88e3-28ad15ec4e64'" -ErrorAction Ignore

-if ($aadDsSp -ne $null)

-{

- Write-Information "Found Azure AD Domain Services application. Deleting it ..."

- Remove-AzureADServicePrincipal -ObjectId $aadDsSp.ObjectId

- Write-Information "Deleted the Azure AD Domain Services application."

-}

-$identifierUri = "https://sync.aaddc.activedirectory.windowsazure.com"

-$appFilter = "IdentifierUris eq '" + $identifierUri + "'"

-$app = Get-AzureADApplication -Filter $appFilter

-if ($app -ne $null)

-{

- Write-Information "Found Azure AD Domain Services Sync application. Deleting it ..."

- Remove-AzureADApplication -ObjectId $app.ObjectId

- Write-Information "Deleted the Azure AD Domain Services Sync application."

-}

-$spFilter = "ServicePrincipalNames eq '" + $identifierUri + "'"

-$sp = Get-AzureADServicePrincipal -Filter $spFilter

-if ($sp -ne $null)

-{

- Write-Information "Found Azure AD Domain Services Sync service principal. Deleting it ..."

- Remove-AzureADServicePrincipal -ObjectId $sp.ObjectId

- Write-Information "Deleted the Azure AD Domain Services Sync service principal."

-}

-```

-### Microsoft Graph disabled

-**Error message**

-*Domain Services could not be enabled in this Microsoft Entra tenant. The Microsoft Entra application is disabled in your Microsoft Entra tenant. Enable the application with the application identifier 00000002-0000-0000-c000-000000000000 and then try to enable Domain Services for your Microsoft Entra tenant.*

-**Resolution**

-Check if you've disabled an application with the identifier *00000002-0000-0000-c000-000000000000*. This application is the Microsoft Entra application and provides Graph API access to your Microsoft Entra tenant. To synchronize your Microsoft Entra tenant, this application must be enabled.

-To check the status of this application and enable it if needed, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Enterprise applications**.

-1. Choose *All applications* from the **Application Type** drop-down menu, then select **Apply**.

-1. In the search box, enter *00000002-0000-0000-c000-00000000000*. Select the application, then choose **Properties**.

-1. If **Enabled for users to sign-in** is set to *No*, set the value to *Yes*, then select **Save**.

-1. Once you've enabled the application, try to enable Domain Services again.

-<a name='users-are-unable-to-sign-in-to-the-azure-ad-domain-services-managed-domain'></a>

-## Users are unable to sign in to the Microsoft Entra Domain Services managed domain

-If one or more users in your Microsoft Entra tenant can't sign in to the managed domain, complete the following troubleshooting steps:

-* **Credentials format** - Try using the UPN format to specify credentials, such as `dee@aaddscontoso.onmicrosoft.com`. The UPN format is the recommended way to specify credentials in Domain Services. Make sure this UPN is configured correctly in Microsoft Entra ID.

- The *SAMAccountName* for your account, such as *AADDSCONTOSO\driley* may be autogenerated if there are multiple users with the same UPN prefix in your tenant or if your UPN prefix is overly long. Therefore, the *SAMAccountName* format for your account may be different from what you expect or use in your on-premises domain.

-* **Password synchronization** - Make sure that you've enabled password synchronization for [cloud-only users][cloud-only-passwords] or for [hybrid environments using Microsoft Entra Connect][hybrid-phs].

- * **Hybrid synchronized accounts:** If the affected user accounts are synchronized from an on-premises directory, verify the following areas:

-

- * You've deployed, or updated to, the [latest recommended release of Microsoft Entra Connect](https://www.microsoft.com/download/details.aspx?id=47594).

- * You've configured Microsoft Entra Connect to [perform a full synchronization][hybrid-phs].

- * Depending on the size of your directory, it may take a while for user accounts and credential hashes to be available in the managed domain. Make sure you wait long enough before trying to authenticate against the managed domain.

- * If the issue persists after verifying the previous steps, try restarting the *Azure AD Sync Service*. From your Microsoft Entra Connect server, open a command prompt, then run the following commands:

-

- ```console

- net stop 'Microsoft Azure AD Sync'

- net start 'Microsoft Azure AD Sync'

- ```

- * **Cloud-only accounts**: If the affected user account is a cloud-only user account, make sure that the [user has changed their password after you enabled Domain Services][cloud-only-passwords]. This password reset causes the required credential hashes for the managed domain to be generated.

-* **Verify the user account is active**: By default, five invalid password attempts within 2 minutes on the managed domain cause a user account to be locked out for 30 minutes. The user can't sign in while the account is locked out. After 30 minutes, the user account is automatically unlocked.

- * Invalid password attempts on the managed domain don't lock out the user account in Microsoft Entra ID. The user account is locked out only within the managed domain. Check the user account status in the *Active Directory Administrative Console (ADAC)* using the [management VM][management-vm], not in Microsoft Entra ID.

- * You can also [configure fine grained password policies][password-policy] to change the default lockout threshold and duration.

-* **External accounts** - Check that the affected user account isn't an external account in the Microsoft Entra tenant. Examples of external accounts include Microsoft accounts like `dee@live.com` or user accounts from an external Microsoft Entra directory. Domain Services doesn't store credentials for external user accounts so they can't sign in to the managed domain.

-## There are one or more alerts on your managed domain

-If there are active alerts on the managed domain, it may prevent the authentication process from working correctly.

-To see if there are any active alerts, [check the health status of a managed domain][check-health]. If any alerts are shown, [troubleshoot and resolve them][troubleshoot-alerts].

-<a name='users-removed-from-your-azure-ad-tenant-are-not-removed-from-your-managed-domain'></a>

-## Users removed from your Microsoft Entra tenant are not removed from your managed domain

-Microsoft Entra ID protects against accidental deletion of user objects. When you delete a user account from a Microsoft Entra tenant, the corresponding user object is moved to the recycle bin. When this delete operation is synchronized to your managed domain, the corresponding user account is marked as disabled. This feature helps you recover, or undelete, the user account.

-The user account remains in the disabled state in the managed domain, even if you re-create a user account with the same UPN in the Microsoft Entra directory. To remove the user account from the managed domain, you need to forcibly delete it from the Microsoft Entra tenant.

-To fully remove a user account from a managed domain, delete the user permanently from your Microsoft Entra tenant using the [Remove-MsolUser][Remove-MsolUser] PowerShell cmdlet with the `-RemoveFromRecycleBin` parameter.

-## Next steps

-If you continue to have issues, [open an Azure support request][azure-support] for more troubleshooting help.

-<!-- INTERNAL LINKS -->

-[cloud-only-passwords]: tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds

-[hybrid-phs]: tutorial-configure-password-hash-sync.md

-[management-vm]: tutorial-create-management-vm.md

-[password-policy]: password-policy.md

-[check-health]: check-health.md

-[troubleshoot-alerts]: troubleshoot-alerts.md

-[Remove-MsolUser]: /powershell/module/msonline/remove-msoluser

-[azure-support]: /azure/active-directory/fundamentals/how-to-get-support

-description: Learn how to troubleshoot secure LDAP (LDAPS) for a Microsoft Entra Domain Services managed domain

-# Troubleshoot secure LDAP connectivity issues to a Microsoft Entra Domain Services managed domain

-Applications and services that use lightweight directory access protocol (LDAP) to communicate with Microsoft Entra Domain Services (Microsoft Entra DS) can be [configured to use secure LDAP](tutorial-configure-ldaps.md). An appropriate certificate and required network ports must be open for secure LDAP to work correctly.

-This article helps you troubleshoot issues with secure LDAP access in Microsoft Entra DS.

-## Common connection issues

-If you have trouble connecting to a Microsoft Entra DS managed domain using secure LDAP, review the following troubleshooting steps. After each troubleshooting step, try to connect to the managed domain again:

-* The issuer chain of the secure LDAP certificate must be trusted on the client. You can add the Root certification authority (CA) to the trusted root certificate store on the client to establish the trust.

- * Make sure you [export and apply the certificate to client computers][client-cert].

-* Verify the secure LDAP certificate for your managed domain has the DNS name in the *Subject* or the *Subject Alternative Names* attribute.

- * Review the [secure LDAP certificate requirements][certs-prereqs] and create a replacement certificate if needed.

-* Verify that the LDAP client, such as *ldp.exe* connects to the secure LDAP endpoint using a DNS name, not the IP address.

- * The certificate applied to the managed domain doesn't include the IP addresses of the service, only the DNS names.

-* Check the DNS name the LDAP client connects to. It must resolve to the public IP address for secure LDAP on the managed domain.

- * If the DNS name resolves to the internal IP address, update the DNS record to resolve to the external IP address.

-* For external connectivity, the network security group must include a rule that allows the traffic to TCP port 636 from the internet.

- * If you can connect to the managed domain using secure LDAP from resources directly connected to the virtual network but not external connections, make sure you [create a network security group rule to allow secure LDAP traffic][ldaps-nsg].

-## Next steps

-If you still have issues, [open an Azure support request][azure-support] for additional troubleshooting assistance.

-<!-- INTERNAL LINKS -->

-[azure-support]: /azure/active-directory/fundamentals/how-to-get-support

-[configure-ldaps]: tutorial-configure-ldaps.md

-[certs-prereqs]: tutorial-configure-ldaps.md#create-a-certificate-for-secure-ldap

-[client-cert]: tutorial-configure-ldaps.md#export-a-certificate-for-client-computers

-[ldaps-nsg]: tutorial-configure-ldaps.md#lock-down-secure-ldap-access-over-the-internet

-description: In this tutorial, you learn how to configure secure lightweight directory access protocol (LDAPS) for a Microsoft Entra Domain Services managed domain.

-#Customer intent: As an identity administrator, I want to secure access to a Microsoft Entra Domain Services managed domain using secure Lightweight Directory Access Protocol (LDAPS)

-# Tutorial: Configure secure LDAP for a Microsoft Entra Domain Services managed domain

-To communicate with your Microsoft Entra Domain Services managed domain, the Lightweight Directory Access Protocol (LDAP) is used. By default, the LDAP traffic isn't encrypted, which is a security concern for many environments.

-With Microsoft Entra Domain Services, you can configure the managed domain to use secure Lightweight Directory Access Protocol (LDAPS). When you use secure LDAP, the traffic is encrypted. Secure LDAP is also known as LDAP over Secure Sockets Layer (SSL) / Transport Layer Security (TLS).

-This tutorial shows you how to configure LDAPS for a Domain Services managed domain.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Create a digital certificate for use with Microsoft Entra Domain Services

-> * Enable secure LDAP for Microsoft Entra Domain Services

-> * Configure secure LDAP for use over the public internet

-> * Bind and test secure LDAP for a managed domain

-If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* The *LDP.exe* tool installed on your computer.

- * If needed, [install the Remote Server Administration Tools (RSAT)][rsat] for *Active Directory Domain Services and LDAP*.

-* You need [Application Administrator](/azure/active-directory/roles/permissions-reference#application-administrator) and [Groups Administrator](/azure/active-directory/roles/permissions-reference#groups-administrator) Microsoft Entra roles in your tenant to enable secure LDAP.

-## Sign in to the Microsoft Entra admin center

-In this tutorial, you configure secure LDAP for the managed domain using the Microsoft Entra admin center. To get started, first sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).

-## Create a certificate for secure LDAP

-To use secure LDAP, a digital certificate is used to encrypt the communication. This digital certificate is applied to your managed domain, and lets tools like *LDP.exe* use secure encrypted communication when querying data. There are two ways to create a certificate for secure LDAP access to the managed domain:

-* A certificate from a public certificate authority (CA) or an enterprise CA.

- * If your organization gets certificates from a public CA, get the secure LDAP certificate from that public CA. If you use an enterprise CA in your organization, get the secure LDAP certificate from the enterprise CA.

- * A public CA only works when you use a custom DNS name with your managed domain. If the DNS domain name of your managed domain ends in *.onmicrosoft.com*, you can't create a digital certificate to secure the connection with this default domain. Microsoft owns the *.onmicrosoft.com* domain, so a public CA won't issue a certificate. In this scenario, create a self-signed certificate and use that to configure secure LDAP.

-* A self-signed certificate that you create yourself.

- * This approach is good for testing purposes, and is what this tutorial shows.

-The certificate you request or create must meet the following requirements. Your managed domain encounters problems if you enable secure LDAP with an invalid certificate:

-* **Trusted issuer** - The certificate must be issued by an authority trusted by computers connecting to the managed domain using secure LDAP. This authority may be a public CA or an Enterprise CA trusted by these computers.

-* **Lifetime** - The certificate must be valid for at least the next 3-6 months. Secure LDAP access to your managed domain is disrupted when the certificate expires.

-* **Subject name** - The subject name on the certificate must be your managed domain. For example, if your domain is named *aaddscontoso.com*, the certificate's subject name must be **.aaddscontoso.com*.

- * The DNS name or subject alternate name of the certificate must be a wildcard certificate to ensure the secure LDAP works properly with Domain Services. Domain Controllers use random names and can be removed or added to ensure the service remains available.

-* **Key usage** - The certificate must be configured for *digital signatures* and *key encipherment*.

-* **Certificate purpose** - The certificate must be valid for TLS server authentication.

-There are several tools available to create self-signed certificate such as OpenSSL, Keytool, MakeCert, [New-SelfSignedCertificate][New-SelfSignedCertificate] cmdlet, etc.

-In this tutorial, let's create a self-signed certificate for secure LDAP using the [New-SelfSignedCertificate][New-SelfSignedCertificate] cmdlet.

-Open a PowerShell window as **Administrator** and run the following commands. Replace the *$dnsName* variable with the DNS name used by your own managed domain, such as *aaddscontoso.com*:

-```powershell

-# Define your own DNS name used by your managed domain

-$dnsName="aaddscontoso.com"

-# Get the current date to set a one-year expiration

-$lifetime=Get-Date

-# Create a self-signed certificate for use with Azure AD DS

-New-SelfSignedCertificate -Subject *.$dnsName `

- -NotAfter $lifetime.AddDays(365) -KeyUsage DigitalSignature, KeyEncipherment `

- -Type SSLServerAuthentication -DnsName *.$dnsName, $dnsName

-```

-The following example output shows that the certificate was successfully generated and is stored in the local certificate store (*LocalMachine\MY*):

-```output

-PS C:\WINDOWS\system32> New-SelfSignedCertificate -Subject *.$dnsName `

->> -NotAfter $lifetime.AddDays(365) -KeyUsage DigitalSignature, KeyEncipherment `

->> -Type SSLServerAuthentication -DnsName *.$dnsName, $dnsName.com

- PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\MY

-Thumbprint Subject

-959BD1531A1E674EB09E13BD8534B2C76A45B3E6 CN=aaddscontoso.com

-```

-## Understand and export required certificates

-To use secure LDAP, the network traffic is encrypted using public key infrastructure (PKI).

-* A **private** key is applied to the managed domain.

- * This private key is used to *decrypt* the secure LDAP traffic. The private key should only be applied to the managed domain and not widely distributed to client computers.

- * A certificate that includes the private key uses the *.PFX* file format.

- * When exporting the certificate, you must specify the *TripleDES-SHA1* encryption algorithm. This is applicable to the .pfx file only and does not impact the algorithm used by the certificate itself. Note that the *TripleDES-SHA1* option is available only beginning with Windows Server 2016.

-* A **public** key is applied to the client computers.

- * This public key is used to *encrypt* the secure LDAP traffic. The public key can be distributed to client computers.

- * Certificates without the private key use the *.CER* file format.

-These two keys, the *private* and *public* keys, make sure that only the appropriate computers can successfully communicate with each other. If you use a public CA or enterprise CA, you are issued with a certificate that includes the private key and can be applied to a managed domain. The public key should already be known and trusted by client computers.

-In this tutorial, you created a self-signed certificate with the private key, so you need to export the appropriate private and public components.

-<a name='export-a-certificate-for-azure-ad-ds'></a>

-### Export a certificate for Microsoft Entra Domain Services

-Before you can use the digital certificate created in the previous step with your managed domain, export the certificate to a *.PFX* certificate file that includes the private key.

-1. To open the *Run* dialog, select the **Windows** + **R** keys.

-1. Open the Microsoft Management Console (MMC) by entering **mmc** in the *Run* dialog, then select **OK**.

-1. On the **User Account Control** prompt, then select **Yes** to launch MMC as administrator.

-1. From the **File** menu, select **Add/Remove Snap-in...**

-1. In the **Certificates snap-in** wizard, choose **Computer account**, then select **Next**.

-1. On the **Select Computer** page, choose **Local computer: (the computer this console is running on)**, then select **Finish**.

-1. In the **Add or Remove Snap-ins** dialog, select **OK** to add the certificates snap-in to MMC.

-1. In the MMC window, expand **Console Root**. Select **Certificates (Local Computer)**, then expand the **Personal** node, followed by the **Certificates** node.

- 

-1. The self-signed certificate created in the previous step is shown, such as *aaddscontoso.com*. Right-select this certificate, then choose **All Tasks > Export...**

- 

-1. In the **Certificate Export Wizard**, select **Next**.

-1. The private key for the certificate must be exported. If the private key is not included in the exported certificate, the action to enable secure LDAP for your managed domain fails.

- On the **Export Private Key** page, choose **Yes, export the private key**, then select **Next**.

-1. Managed domains only support the *.PFX* certificate file format that includes the private key. Don't export the certificate as *.CER* certificate file format without the private key.

- On the **Export File Format** page, select **Personal Information Exchange - PKCS #12 (.PFX)** as the file format for the exported certificate. Check the box for *Include all certificates in the certification path if possible*:

- 

-1. As this certificate is used to decrypt data, you should carefully control access. A password can be used to protect the use of the certificate. Without the correct password, the certificate can't be applied to a service.

- On the **Security** page, choose the option for **Password** to protect the *.PFX* certificate file. The encryption algorithm must be *TripleDES-SHA1*. Enter and confirm a password, then select **Next**. This password is used in the next section to enable secure LDAP for your managed domain.

- If you export using the [PowerShell export-pfxcertificate cmdlet](/powershell/module/pki/export-pfxcertificate), you need to pass the *-CryptoAlgorithmOption* flag using TripleDES_SHA1.

- 

-1. On the **File to Export** page, specify the file name and location where you'd like to export the certificate, such as `C:\Users\<account-name>\azure-ad-ds.pfx`. Keep a note of the password and location of the *.PFX* file as this information would be required in next steps.

-1. On the review page, select **Finish** to export the certificate to a *.PFX* certificate file. A confirmation dialog is displayed when the certificate has been successfully exported.

-1. Leave the MMC open for use in the following section.

-### Export a certificate for client computers

-Client computers must trust the issuer of the secure LDAP certificate to be able to connect successfully to the managed domain using LDAPS. The client computers need a certificate to successfully encrypt data that is decrypted by Domain Services. If you use a public CA, the computer should automatically trust these certificate issuers and have a corresponding certificate.

-In this tutorial you use a self-signed certificate, and generated a certificate that includes the private key in the previous step. Now let's export and then install the self-signed certificate into the trusted certificate store on the client computer:

-1. Go back to the MMC for *Certificates (Local Computer) > Personal > Certificates* store. The self-signed certificate created in a previous step is shown, such as *aaddscontoso.com*. Right-select this certificate, then choose **All Tasks > Export...**

-1. In the **Certificate Export Wizard**, select **Next**.

-1. As you don't need the private key for clients, on the **Export Private Key** page choose **No, do not export the private key**, then select **Next**.

-1. On the **Export File Format** page, select **Base-64 encoded X.509 (.CER)** as the file format for the exported certificate:

- 

-1. On the **File to Export** page, specify the file name and location where you'd like to export the certificate, such as `C:\Users\<account-name>\azure-ad-ds-client.cer`.

-1. On the review page, select **Finish** to export the certificate to a *.CER* certificate file. A confirmation dialog is displayed when the certificate has been successfully exported.

-The *.CER* certificate file can now be distributed to client computers that need to trust the secure LDAP connection to the managed domain. Let's install the certificate on the local computer.

-1. Open File Explorer and browse to the location where you saved the *.CER* certificate file, such as `C:\Users\<account-name>\azure-ad-ds-client.cer`.

-1. Right-select the *.CER* certificate file, then choose **Install Certificate**.

-1. In the **Certificate Import Wizard**, choose to store the certificate in the *Local machine*, then select **Next**:

- 

-1. When prompted, choose **Yes** to allow the computer to make changes.

-1. Choose to **Automatically select the certificate store based on the type of certificate**, then select **Next**.

-1. On the review page, select **Finish** to import the *.CER* certificate. file A confirmation dialog is displayed when the certificate has been successfully imported.

-<a name='enable-secure-ldap-for-azure-ad-ds'></a>

-<a name='enable-secure-ldap-for-microsoft-entra-ds'></a>

-## Enable secure LDAP for Microsoft Entra Domain Services

-With a digital certificate created and exported that includes the private key, and the client computer set to trust the connection, now enable secure LDAP on your managed domain. To enable secure LDAP on a managed domain, perform the following configuration steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), enter *domain services* in the **Search resources** box. Select **Microsoft Entra Domain Services** from the search result.

-1. Choose your managed domain, such as *aaddscontoso.com*.

-1. On the left-hand side of the Microsoft Entra Domain Services window, choose **Secure LDAP**.

-1. By default, secure LDAP access to your managed domain is disabled. Toggle **Secure LDAP** to **Enable**.

-1. Secure LDAP access to your managed domain over the internet is disabled by default. When you enable public secure LDAP access, your domain is susceptible to password brute force attacks over the internet. In the next step, a network security group is configured to lock down access to only the required source IP address ranges.

- Toggle **Allow secure LDAP access over the internet** to **Enable**.

-1. Select the folder icon next to **.PFX file with secure LDAP certificate**. Browse to the path of the *.PFX* file, then select the certificate created in a previous step that includes the private key.

- > [!IMPORTANT]

- > As noted in the previous section on certificate requirements, you can't use a certificate from a public CA with the default *.onmicrosoft.com* domain. Microsoft owns the *.onmicrosoft.com* domain, so a public CA won't issue a certificate.

- >

- > Make sure your certificate is in the appropriate format. If it's not, the Azure platform generates certificate validation errors when you enable secure LDAP.

-1. Enter the **Password to decrypt .PFX file** set in a previous step when the certificate was exported to a *.PFX* file.

-1. Select **Save** to enable secure LDAP.

- 

-A notification is displayed that secure LDAP is being configured for the managed domain. You can't modify other settings for the managed domain until this operation is complete.

-It takes a few minutes to enable secure LDAP for your managed domain. If the secure LDAP certificate you provide doesn't match the required criteria, the action to enable secure LDAP for the managed domain fails.

-Some common reasons for failure are if the domain name is incorrect, the encryption algorithm for the certificate isn't *TripleDES-SHA1*, or the certificate expires soon or has already expired. You can re-create the certificate with valid parameters, then enable secure LDAP using this updated certificate.

-## Change an expiring certificate

-1. Create a replacement secure LDAP certificate by following the steps to [create a certificate for secure LDAP](#create-a-certificate-for-secure-ldap).

-1. To apply the replacement certificate to Domain Services, in the left menu for **Microsoft Entra Domain Services** in the Microsoft Entra admin center, select **Secure LDAP**, and then select **Change Certificate**.

-1. Distribute the certificate to any clients that connect by using secure LDAP.

-## Lock down secure LDAP access over the internet

-When you enable secure LDAP access over the internet to your managed domain, it creates a security threat. The managed domain is reachable from the internet on TCP port 636. It's recommended to restrict access to the managed domain to specific known IP addresses for your environment. An Azure network security group rule can be used to limit access to secure LDAP.

-Let's create a rule to allow inbound secure LDAP access over TCP port 636 from a specified set of IP addresses. A default *DenyAll* rule with a lower priority applies to all other inbound traffic from the internet, so only the specified addresses can reach your managed domain using secure LDAP.

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select *Resource groups*.

-1. Choose your resource group, such as *myResourceGroup*, then select your network security group, such as *aaads-nsg*.

-1. The list of existing inbound and outbound security rules are displayed. On the left-hand side of the network security group window, choose **Settings > Inbound security rules**.

-1. Select **Add**, then create a rule to allow *TCP* port *636*. For improved security, choose the source as *IP Addresses* and then specify your own valid IP address or range for your organization.

- | Setting | Value |

- |--|--|

- | Source | IP Addresses |

- | Source IP addresses / CIDR ranges | A valid IP address or range for your environment |

- | Source port ranges | * |

- | Destination | Any |

- | Destination port ranges | 636 |

- | Protocol | TCP |

- | Action | Allow |

- | Priority | 401 |

- | Name | AllowLDAPS |

-1. When ready, select **Add** to save and apply the rule.

- 

-## Configure DNS zone for external access

-With secure LDAP access enabled over the internet, update the DNS zone so that client computers can find this managed domain. The *Secure LDAP external IP address* is listed on the **Properties** tab for your managed domain:

-

-Configure your external DNS provider to create a host record, such as *ldaps*, to resolve to this external IP address. To test locally on your machine first, you can create an entry in the Windows hosts file. To successfully edit the hosts file on your local machine, open *Notepad* as an administrator, then open the file `C:\Windows\System32\drivers\etc\hosts`.

-The following example DNS entry, either with your external DNS provider or in the local hosts file, resolves traffic for `ldaps.aaddscontoso.com` to the external IP address of `168.62.205.103`:

-```

-168.62.205.103 ldaps.aaddscontoso.com

-```

-## Test queries to the managed domain

-To connect and bind to your managed domain and search over LDAP, you use the *LDP.exe* tool. This tool is included in the Remote Server Administration Tools (RSAT) package. For more information, see [install Remote Server Administration Tools][rsat].

-1. Open *LDP.exe* and connect to the managed domain. Select **Connection**, then choose **Connect...**.

-1. Enter the secure LDAP DNS domain name of your managed domain created in the previous step, such as *ldaps.aaddscontoso.com*. To use secure LDAP, set **Port** to *636*, then check the box for **SSL**.

-1. Select **OK** to connect to the managed domain.

-Next, bind to your managed domain. Users (and service accounts) can't perform LDAP simple binds if you have disabled NTLM password hash synchronization on your managed domain. For more information on disabling NTLM password hash synchronization, see [Secure your managed domain][secure-domain].

-1. Select the **Connection** menu option, then choose **Bind...**.

-1. Provide the credentials of a user account that belongs to the managed domain. Enter the user account's password, then enter your domain, such as *aaddscontoso.com*.

-1. For **Bind type**, choose the option for *Bind with credentials*.

-1. Select **OK** to bind to your managed domain.

-To see of the objects stored in your managed domain:

-1. Select the **View** menu option, and then choose **Tree**.

-1. Leave the *BaseDN* field blank, then select **OK**.

-1. Choose a container, such as *AADDC Users*, then right-select the container and choose **Search**.

-1. Leave the pre-populated fields set, then select **Run**. The results of the query are displayed in the right-hand window, as shown in the following example output:

- 

-To directly query a specific container, from the **View > Tree** menu, you can specify a **BaseDN** such as *OU=AADDC Users,DC=AADDSCONTOSO,DC=COM* or *OU=AADDC Computers,DC=AADDSCONTOSO,DC=COM*. For more information on how to format and create queries, see [LDAP query basics][ldap-query-basics].

-> [!NOTE]

-> If a Self signed certificate is used, make sure Self signed certificate added on the Trusted Root Certification Authorities for LDAPS to work with LDP.exe

-## Clean up resources

-If you added a DNS entry to the local hosts file of your computer to test connectivity for this tutorial, remove this entry and add a formal record in your DNS zone. To remove the entry from the local hosts file, complete the following steps:

-1. On your local machine, open *Notepad* as an administrator

-1. Browse to and open the file `C:\Windows\System32\drivers\etc\hosts`.

-1. Delete the line for the record you added, such as `168.62.205.103 ldaps.aaddscontoso.com`

-## Troubleshooting

-If you see an error stating that LDAP.exe cannot connect, try working through the different aspects of getting the connection:

-1. Configuring the domain controller

-1. Configuring the client

-1. Networking

-1. Establishing the TLS session

-For the certificate subject name match, the DC will use the Domain Services domain name (not the Microsoft Entra domain name) to search its certificate store for the certificate. Spelling mistakes, for example, prevent the DC from selecting the right certificate.

-The client attempts to establish the TLS connection using the name you provided. The traffic needs to get all the way through. The DC sends the public key of the server auth cert. The cert needs to have the right usage in the certificate, the name signed in the subject name must be compatible for the client to trust that the server is the DNS name which youΓÇÖre connecting to (that is, a wildcard will work, with no spelling mistakes), and the client must trust the issuer. You can check for any problems in that chain in the System log in Event Viewer, and filter the events where source equals Schannel. Once those pieces are in place, they form a session key.

-For more information, see [TLS Handshake](/windows/win32/secauthn/tls-handshake-protocol).

-## Next steps

-In this tutorial, you learned how to:

-> [!div class="checklist"]

-> * Create a digital certificate for use with Microsoft Entra Domain Services

-> * Enable secure LDAP for Microsoft Entra Domain Services

-> * Configure secure LDAP for use over the public internet

-> * Bind and test secure LDAP for a managed domain

-> [!div class="nextstepaction"]

-> [Configure password hash synchronization for a hybrid Microsoft Entra environment](tutorial-configure-password-hash-sync.md)

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[secure-domain]: secure-your-domain.md

-<!-- EXTERNAL LINKS -->

-[rsat]: /windows-server/remote/remote-server-administration-tools

-[ldap-query-basics]: /windows/win32/ad/creating-a-query-filter

-[New-SelfSignedCertificate]: /powershell/module/pki/new-selfsignedcertificate

-description: In this tutorial, you learn how to create and configure an Azure virtual network subnet or network peering for a Microsoft Entra Domain Services managed domain using the Microsoft Entra admin center.

-#Customer intent: As an identity administrator, I want to create and configure a virtual network subnet or network peering for application workloads in a Microsoft Entra Domain Services managed domain

-# Tutorial: Configure virtual networking for a Microsoft Entra Domain Services managed domain

-To provide connectivity to users and applications, a Microsoft Entra Domain Services managed domain is deployed into an Azure virtual network subnet. This virtual network subnet should only be used for the managed domain resources provided by the Azure platform.

-When you create your own VMs and applications, they shouldn't be deployed into the same virtual network subnet. Instead, you should create and deploy your applications into a separate virtual network subnet, or in a separate virtual network that's peered to the Domain Services virtual network.

-This tutorial shows you how to create and configure a dedicated virtual network subnet or how to peer a different network to the Domain Services managed domain's virtual network.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Understand the virtual network connectivity options for domain-joined resources to Domain Services

-> * Create an IP address range and additional subnet in the Domain Services virtual network

-> * Configure virtual network peering to a network that's separate from Domain Services

-If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* You need [Application Administrator](/azure/active-directory/roles/permissions-reference#application-administrator) and [Groups Administrator](/azure/active-directory/roles/permissions-reference#groups-administrator) Microsoft Entra roles in your tenant to enable Domain Services.

-* You need Domain Services Contributor Azure role to create the required Domain Services resources.

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-## Sign in to the Microsoft Entra admin center

-In this tutorial, you create and configure the managed domain using the Microsoft Entra admin center. To get started, first sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).

-## Application workload connectivity options

-In the previous tutorial, a managed domain was created that used some default configuration options for the virtual network. These default options created an Azure virtual network and virtual network subnet. The Domain Services domain controllers that provide the managed domain services are connected to this virtual network subnet.

-When you create and run VMs that need to use the managed domain, network connectivity needs to be provided. This network connectivity can be provided in one of the following ways:

-* Create an additional virtual network subnet in the managed domain's virtual network. This additional subnet is where you create and connect your VMs.

- * As the VMs are part of the same virtual network, they can automatically perform name resolution and communicate with the Domain Services domain controllers.

-* Configure Azure virtual network peering from the managed domain's virtual network to one or more separate virtual networks. These separate virtual networks are where you create and connect your VMs.

- * When you configure virtual network peering, you must also configure DNS settings to use name resolution back to the Domain Services domain controllers.

-Usually, you only use one of these network connectivity options. The choice is often down to how you wish to manage separate your Azure resources.

-* If you want to manage Domain Services and connected VMs as one group of resources, you can create an additional virtual network subnet for VMs.

-* If you want to separate the management of Domain Services and then any connected VMs, you can use virtual network peering.

- * You may also choose to use virtual network peering to provide connectivity to existing VMs in your Azure environment that are connected to an existing virtual network.

-In this tutorial, you only need to configure one these virtual network connectivity options.

-For more information on how to plan and configure the virtual network, see [networking considerations for Microsoft Entra Domain Services][network-considerations].

-## Create a virtual network subnet

-By default, the Azure virtual network created with the managed domain contains a single virtual network subnet. This virtual network subnet should only be used by the Azure platform to provide managed domain services. To create and use your own VMs in this Azure virtual network, create an additional subnet.

-To create a virtual network subnet for VMs and application workloads, complete the following steps:

-1. In the Microsoft Entra admin center, select the resource group of your managed domain, such as *myResourceGroup*. From the list of resources, choose the default virtual network, such as *aadds-vnet*.

-1. In the left-hand menu of the virtual network window, select **Address space**. The virtual network is created with a single address space of *10.0.2.0/24*, which is used by the default subnet.

- Add an additional IP address range to the virtual network. The size of this address range and the actual IP address range to use depends on other network resources already deployed. The IP address range shouldn't overlap with any existing address ranges in your Azure or on-premises environment. Make sure that you size the IP address range large enough for the number of VMs you expect to deploy into the subnet.

- In the following example, an additional IP address range of *10.0.3.0/24* is added. When ready, select **Save**.

- 

-1. Next, in the left-hand menu of the virtual network window, select **Subnets**, then choose **+ Subnet** to add a subnet.

-1. Enter a name for the subnet, such as *workloads*. If needed, update the **Address range** if you want to use a subset of the IP address range configured for the virtual network in the previous steps. For now, leave the defaults for options like network security group, route table, service endpoints.

- In the following example, a subnet named *workloads* is created that uses the *10.0.3.0/24* IP address range:

- 

-1. When ready, select **OK**. It takes a few moments to create the virtual network subnet.

-When you create a VM that needs to use the managed domain, make sure you select this virtual network subnet. Don't create VMs in the default *aadds-subnet*. If you select a different virtual network, there's no network connectivity and DNS resolution to reach the managed domain unless you configure virtual network peering.

-## Configure virtual network peering

-You may have an existing Azure virtual network for VMs, or wish to keep your managed domain virtual network separate. To use the managed domain, VMs in other virtual networks need a way to communicate with the Domain Services domain controllers. This connectivity can be provided using Azure virtual network peering.

-With Azure virtual network peering, two virtual networks are connected together, without the need for a virtual private network (VPN) device. Network peering lets you quickly connect virtual networks and define traffic flows across your Azure environment.

-For more information on peering, see [Azure virtual network peering overview][peering-overview].

-To peer a virtual network to the managed domain virtual network, complete the followings steps:

-1. Choose the default virtual network created for your managed domain named *aadds-vnet*.

-1. In the left-hand menu of the virtual network window, select **Peerings**.

-1. To create a peering, select **+ Add**. In the following example, the default *aadds-vnet* is peered to a virtual network named *myVnet*. Configure the following settings with your own values:

- * **Name of the peering from aadds-vnet to remote virtual network**: A descriptive identifier of the two networks, such as *aadds-vnet-to-myvnet*

- * **Virtual network deployment type**: *Resource Manager*

- * **Subscription**: The subscription of the virtual network you want to peer to, such as *Azure*

- * **Virtual network**: The virtual network you want to peer to, such as *myVnet*

- * **Name of the peering from myVnet to aadds-vnet**: A descriptive identifier of the two networks, such as *myvnet-to-aadds-vnet*

- 

- Leave any other defaults for virtual network access or forwarded traffic unless you have specific requirements for your environment, then select **OK**.

-1. It takes a few moments to create the peering on both the Domain Services virtual network and the virtual network you selected. When ready, the **Peering status** reports *Connected*, as shown in the following example:

- 

-Before VMs in the peered virtual network can use the managed domain, configure the DNS servers to allow for correct name resolution.

-### Configure DNS servers in the peered virtual network

-For VMs and applications in the peered virtual network to successfully talk to the managed domain, the DNS settings must be updated. The IP addresses of the Domain Services domain controllers must be configured as the DNS servers on the peered virtual network. There are two ways to configure the domain controllers as DNS servers for the peered virtual network:

-* Configure the Azure virtual network DNS servers to use the Domain Services domain controllers.

-* Configure the existing DNS server in use on the peered virtual network to use conditional DNS forwarding to direct queries to the managed domain. These steps vary depending on the existing DNS server in use.

-In this tutorial, let's configure the Azure virtual network DNS servers to direct all queries to the Domain Services domain controllers.

-1. In the Microsoft Entra admin center, select the resource group of the peered virtual network, such as *myResourceGroup*. From the list of resources, choose the peered virtual network, such as *myVnet*.

-1. In the left-hand menu of the virtual network window, select **DNS servers**.

-1. By default, a virtual network uses the built-in Azure-provided DNS servers. Choose to use **Custom** DNS servers. Enter the IP addresses for the Domain Services domain controllers, which are usually *10.0.2.4* and *10.0.2.5*. Confirm these IP addresses on the **Overview** window of your managed domain in the portal.

- 

-1. When ready, select **Save**. It takes a few moments to update the DNS servers for the virtual network.

-1. To apply the updated DNS settings to the VMs, restart VMs connected to the peered virtual network.

-When you create a VM that needs to use the managed domain, make sure you select this peered virtual network. If you select a different virtual network, there's no network connectivity and DNS resolution to reach the managed domain.

-## Next steps

-In this tutorial, you learned how to:

-> [!div class="checklist"]

-> * Understand the virtual network connectivity options for domain-joined resources to Domain Services

-> * Create an IP address range and additional subnet in the Domain Services virtual network

-> * Configure virtual network peering to a network that's separate from Domain Services

-To see this managed domain in action, create and join a virtual machine to the domain.

-> [!div class="nextstepaction"]

-> [Join a Windows Server virtual machine to your managed domain](join-windows-vm.md)

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[create-join-windows-vm]: join-windows-vm.md

-[peering-overview]: /azure/virtual-network/virtual-network-peering-overview

-[network-considerations]: network-considerations.md

-description: In this tutorial, learn how to enable password hash synchronization using Microsoft Entra Connect to a Microsoft Entra Domain Services managed domain.

-#Customer intent: As an server administrator, I want to learn how to enable password hash synchronization with Microsoft Entra Connect to create a hybrid environment using an on-premises AD DS domain.

-# Tutorial: Enable password synchronization in Microsoft Entra Domain Services for hybrid environments

-For hybrid environments, a Microsoft Entra tenant can be configured to synchronize with an on-premises Active Directory Domain Services (AD DS) environment using Microsoft Entra Connect. By default, Microsoft Entra Connect doesn't synchronize legacy NT LAN Manager (NTLM) and Kerberos password hashes that are needed for Microsoft Entra Domain Services.

-To use Domain Services with accounts synchronized from an on-premises AD DS environment, you need to configure Microsoft Entra Connect to synchronize those password hashes required for NTLM and Kerberos authentication. After Microsoft Entra Connect is configured, an on-premises account creation or password change event also then synchronizes the legacy password hashes to Microsoft Entra ID.

-You don't need to perform these steps if you use cloud-only accounts with no on-premises AD DS environment.

-In this tutorial, you learn:

-> [!div class="checklist"]

-> * Why legacy NTLM and Kerberos password hashes are needed

-> * How to configure legacy password hash synchronization for Microsoft Entra Connect

-If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-## Prerequisites

-To complete this tutorial, you need the following resources:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription that's synchronized with an on-premises directory using Microsoft Entra Connect.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

- * If needed, [enable Microsoft Entra Connect for password hash synchronization][enable-azure-ad-connect].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-<a name='password-hash-synchronization-using-azure-ad-connect'></a>

-## Password hash synchronization using Microsoft Entra Connect

-Microsoft Entra Connect is used to synchronize objects like user accounts and groups from an on-premises AD DS environment into a Microsoft Entra tenant. As part of the process, password hash synchronization enables accounts to use the same password in the on-premises AD DS environment and Microsoft Entra ID.

-To authenticate users on the managed domain, Domain Services needs password hashes in a format that's suitable for NTLM and Kerberos authentication. Microsoft Entra ID doesn't 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.

-Microsoft Entra Connect can be configured to synchronize the required NTLM or Kerberos password hashes for Domain Services. Make sure that you have completed the steps to [enable Microsoft Entra Connect for password hash synchronization][enable-azure-ad-connect]. If you had an existing instance of Microsoft Entra Connect, [download and update to the latest version][azure-ad-connect-download] to make sure you can synchronize the legacy password hashes for NTLM and Kerberos. This functionality isn't available in early releases of Microsoft Entra Connect or with the legacy DirSync tool. Microsoft Entra Connect version *1.1.614.0* or later is required.

-> [!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 Domain Services managed domain to synchronize objects back to Microsoft Entra ID.

-## Enable synchronization of password hashes

-With Microsoft Entra Connect installed and configured to synchronize with Microsoft Entra ID, now configure the legacy password hash sync for NTLM and Kerberos. A PowerShell script is used to configure the required settings and then start a full password synchronization to Microsoft Entra ID. When that Microsoft Entra Connect password hash synchronization process is complete, users can sign in to applications through Domain Services that use legacy NTLM or Kerberos password hashes.

-1. On the computer with Microsoft Entra Connect installed, from the Start menu, open the **Microsoft Entra Connect > Synchronization Service**.

-1. Select the **Connectors** tab. The connection information used to establish the synchronization between the on-premises AD DS environment and Microsoft Entra ID are listed.

- The **Type** indicates either *Windows Microsoft Entra ID (Microsoft)* for the Microsoft Entra connector or *Active Directory Domain Services* for the on-premises AD DS connector. Make a note of the connector names to use in the PowerShell script in the next step.

- 

- In this example screenshot, the following connectors are used:

- * The Microsoft Entra connector is named *contoso.onmicrosoft.com - Microsoft Entra ID*

- * The on-premises AD DS connector is named *onprem.contoso.com*

-1. Copy and paste the following PowerShell script to the computer with Microsoft Entra Connect installed. The script triggers a full password sync that includes legacy password hashes. Update the `$azureadConnector` and `$adConnector` variables with the connector names from the previous step.

- Run this script on each AD forest to synchronize on-premises account NTLM and Kerberos password hashes to Microsoft Entra ID.

- ```powershell

- # Define the Azure AD Connect connector names and import the required PowerShell module

- $azureadConnector = "<CASE SENSITIVE AZURE AD CONNECTOR NAME>"

- $adConnector = "<CASE SENSITIVE AD DS CONNECTOR NAME>"

-

- Import-Module "C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1"

- Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

- # Create a new ForceFullPasswordSync configuration parameter object then

- # update the existing connector with this new configuration

- $c = Get-ADSyncConnector -Name $adConnector

- $p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter "Microsoft.Synchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null

- $p.Value = 1

- $c.GlobalParameters.Remove($p.Name)

- $c.GlobalParameters.Add($p)

- $c = Add-ADSyncConnector -Connector $c

- # Disable and re-enable Azure AD Connect to force a full password synchronization

- Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $azureadConnector -Enable $false

- Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $azureadConnector -Enable $true

- ```

- Depending on the size of your directory in terms of number of accounts and groups, synchronization of the legacy password hashes to Microsoft Entra ID may take some time. The passwords are then synchronized to the managed domain after they've synchronized to Microsoft Entra ID.

-## Next steps

-In this tutorial, you learned:

-> [!div class="checklist"]

-> * Why legacy NTLM and Kerberos password hashes are needed

-> * How to configure legacy password hash synchronization for Microsoft Entra Connect

-> [!div class="nextstepaction"]

-> [Learn how synchronization works in a Microsoft Entra Domain Services managed domain](synchronization.md)

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[enable-azure-ad-connect]: /azure/active-directory/hybrid/connect/how-to-connect-install-express

-<!-- EXTERNAL LINKS -->

-[azure-ad-connect-download]: https://www.microsoft.com/download/details.aspx?id=47594

-description: Learn how to create a one-way outbound forest to an on-premises AD DS domain in the Microsoft Entra admin center for Microsoft Entra Domain Services

-#Customer intent: As an identity administrator, I want to create a one-way outbound forest from a Microsoft Entra Domain Services forest to an on-premises Active Directory Domain Services forest to provide authentication and resource access between forests.

-# Tutorial: Create an outbound forest trust to an on-premises domain in Microsoft Entra Domain Services

-You can create a one-way outbound trust from Microsoft Entra Domain Services to one or more on-premises AD DS environments. This trust relationship lets users, applications, and computers authenticate against an on-premises domain from the Domain Services managed domain. A forest trust can help users access resources in scenarios such as:

-Trusts can be created in any domain. The domain will automatically block synchronization from an on-premises domain for any user accounts that were synchronized to Domain Services. This prevents UPN collisions when users authenticate.

-

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Configure DNS in an on-premises AD DS environment to support Domain Services connectivity

-> * Create a one-way inbound forest trust in an on-premises AD DS environment

-> * Create a one-way outbound forest trust in Domain Services

-> * Test and validate the trust relationship for authentication and resource access

-If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain.

- * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance-advanced].

-

- > [!IMPORTANT]

- > You need to use a minimum of *Enterprise* SKU for your managed domain. If needed, [change the SKU for a managed domain][howto-change-sku].

-## Sign in to the Microsoft Entra admin center

-In this tutorial, you create and configure the outbound forest trust from Domain Services using the Microsoft Entra admin center. To get started, first sign in to the [Microsoft Entra admin center](https://entra.microsoft.com). You need [Application Administrator](/azure/active-directory/roles/permissions-reference#application-administrator) and [Groups Administrator](/azure/active-directory/roles/permissions-reference#groups-administrator) Microsoft Entra roles in your tenant to modify a Domain Services instance.

-## Networking considerations

-The virtual network that hosts the Domain Services forest needs network connectivity to your on-premises Active Directory. Applications and services also need network connectivity to the virtual network hosting the Domain Services forest. Network connectivity to the Domain Services forest must be always on and stable otherwise users may fail to authenticate or access resources.

-Before you configure a forest trust in Domain Services, make sure your networking between Azure and on-premises environment meets the following requirements:

-* Use private IP addresses. Don't rely on DHCP with dynamic IP address assignment.

-* Avoid overlapping IP address spaces to allow virtual network peering and routing to successfully communicate between Azure and on-premises.

-* An Azure virtual network needs a gateway subnet to configure an [Azure site-to-site (S2S) VPN][vpn-gateway] or [ExpressRoute][expressroute] connection.

-* Create subnets with enough IP addresses to support your scenario.

-* Make sure Domain Services has its own subnet, don't share this virtual network subnet with application VMs and services.

-* Peered virtual networks are NOT transitive.

- * Azure virtual network peerings must be created between all virtual networks you want to use the Domain Services forest trust to the on-premises AD DS environment.

-* Provide continuous network connectivity to your on-premises Active Directory forest. Don't use on-demand connections.

-* Make sure there's continuous name resolution (DNS) between your Domain Services forest name and your on-premises Active Directory forest name.

-## Configure DNS in the on-premises domain

-To correctly resolve the managed domain from the on-premises environment, you may need to add forwarders to the existing DNS servers. If you haven't configured the on-premises environment to communicate with the managed domain, complete the following steps from a management workstation for the on-premises AD DS domain:

-1. Select **Start** > **Administrative Tools** > **DNS**.

-1. Select your DNS zone, such as *aaddscontoso.com*.

-1. Select **Conditional Forwarders**, then right-select and choose **New Conditional Forwarder...**

-1. Enter your other **DNS Domain**, such as *contoso.com*, then enter the IP addresses of the DNS servers for that namespace, as shown in the following example:

- 

-1. Check the box for **Store this conditional forwarder in Active Directory, and replicate it as follows**, then select the option for *All DNS servers in this domain*, as shown in the following example:

- 

- > [!IMPORTANT]

- > If the conditional forwarder is stored in the *forest* instead of the *domain*, the conditional forwarder fails.

-1. To create the conditional forwarder, select **OK**.

-## Create inbound forest trust in the on-premises domain

-The on-premises AD DS domain needs an incoming forest trust for the managed domain. This trust must be manually created in the on-premises AD DS domain, it can't be created from the Microsoft Entra admin center.

-To configure inbound trust on the on-premises AD DS domain, complete the following steps from a management workstation for the on-premises AD DS domain:

-1. Select **Start** > **Administrative Tools** > **Active Directory Domains and Trusts**.

-1. Right-click the domain, such as *onprem.contoso.com*, then select **Properties**.

-1. Choose **Trusts** tab, then **New Trust**.

-1. Enter the name for Domain Services domain name, such as *aaddscontoso.com*, then select **Next**.

-1. Select the option to create a **Forest trust**, then to create a **One way: incoming** trust.

-1. Choose to create the trust for **This domain only**. In the next step, you create the trust in the Microsoft Entra admin center for the managed domain.

-1. Choose to use **Forest-wide authentication**, then enter and confirm a trust password. This same password is also entered in the Microsoft Entra admin center in the next section.

-1. Step through the next few windows with default options, then choose the option for **No, do not confirm the outgoing trust**.

-1. Select **Finish**.

-If the forest trust is no longer needed for an environment, complete the following steps to remove it from the on-premises domain:

-1. Select **Start** > **Administrative Tools** > **Active Directory Domains and Trusts**.

-1. Right-click the domain, such as *onprem.contoso.com*, then select **Properties**.

-1. Choose **Trusts** tab, then **Domains that trust this domain (incoming trusts)**, click the trust to be removed, and then click **Remove**.

-1. On the Trusts tab, under **Domains trusted by this domain (outgoing trusts)**, click the trust to be removed, and then click Remove.

-1. Click **No, remove the trust from the local domain only**.

-<a name='create-outbound-forest-trust-in-azure-ad-ds'></a>

-## Create outbound forest trust in Domain Services

-With the on-premises AD DS domain configured to resolve the managed domain and an inbound forest trust created, now create the outbound forest trust. This outbound forest trust completes the trust relationship between the on-premises AD DS domain and the managed domain.

-To create the outbound trust for the managed domain in the Microsoft Entra admin center, complete the following steps:

-1. In the Microsoft Entra admin center, search for and select **Microsoft Entra Domain Services**, then select your managed domain, such as *aaddscontoso.com*.

-1. From the menu on the left-hand side of the managed domain, select **Trusts**, then choose to **+ Add** a trust.

-1. Enter a display name that identifies your trust, then the on-premises trusted forest DNS name, such as *onprem.contoso.com*.

-1. Provide the same trust password that was used to configure the inbound forest trust for the on-premises AD DS domain in the previous section.

-1. Provide at least two DNS servers for the on-premises AD DS domain, such as *10.1.1.4* and *10.1.1.5*.

-1. When ready, **Save** the outbound forest trust.

- 

-If the forest trust is no longer needed for an environment, complete the following steps to remove it from Domain

-1. In the Microsoft Entra admin center, search for and select **Microsoft Entra Domain Services**, then select your managed domain, such as *aaddscontoso.com*.

-1. From the menu on the left-hand side of the managed domain, select **Trusts**, choose the trust, and click **Remove**.

-1. Provide the same trust password that was used to configure the forest trust and click **OK**.

-## Validate resource authentication

-The following common scenarios let you validate that forest trust correctly authenticates users and access to resources:

-* [On-premises user authentication from the Domain Services forest](#on-premises-user-authentication-from-the-azure-ad-ds-forest)

-* [Access resources in the Domain Services forest using on-premises user](#access-resources-in-the-azure-ad-ds-forest-using-on-premises-user)

- * [Enable file and printer sharing](#enable-file-and-printer-sharing)

- * [Create a security group and add members](#create-a-security-group-and-add-members)

- * [Create a file share for cross-forest access](#create-a-file-share-for-cross-forest-access)

- * [Validate cross-forest authentication to a resource](#validate-cross-forest-authentication-to-a-resource)

-<a name='on-premises-user-authentication-from-the-azure-ad-ds-forest'></a>

-### On-premises user authentication from the Domain Services forest

-You should have Windows Server virtual machine joined to the managed domain. Use this virtual machine to test your on-premises user can authenticate on a virtual machine. If needed, [create a Windows VM and join it to the managed domain][join-windows-vm].

-1. Connect to the Windows Server VM joined to the Domain Services forest using [Azure Bastion](/azure/bastion/bastion-overview) and your Domain Services administrator credentials.

-1. Open a command prompt and use the `whoami` command to show the distinguished name of the currently authenticated user:

- ```console

- whoami /fqdn

- ```

-1. Use the `runas` command to authenticate as a user from the on-premises domain. In the following command, replace `userUpn@trusteddomain.com` with the UPN of a user from the trusted on-premises domain. The command prompts you for the user's password:

- ```console

- Runas /u:userUpn@trusteddomain.com cmd.exe

- ```

-1. If the authentication is a successful, a new command prompt opens. The title of the new command prompt includes `running as userUpn@trusteddomain.com`.

-1. Use `whoami /fqdn` in the new command prompt to view the distinguished name of the authenticated user from the on-premises Active Directory.

-<a name='access-resources-in-the-azure-ad-ds-forest-using-on-premises-user'></a>

-### Access resources in the Domain Services forest using on-premises user

-Using the Windows Server VM joined to the Domain Services forest, you can test the scenario where users can access resources hosted in the forest when they authenticate from computers in the on-premises domain with users from the on-premises domain. The following examples show you how to create and test various common scenarios.

-#### Enable file and printer sharing

-1. Connect to the Windows Server VM joined to the Domain Services forest using [Azure Bastion](/azure/bastion/bastion-overview) and your Domain Services administrator credentials.

-1. Open **Windows Settings**, then search for and select **Network and Sharing Center**.

-1. Choose the option for **Change advanced sharing** settings.

-1. Under the **Domain Profile**, select **Turn on file and printer sharing** and then **Save changes**.

-1. Close **Network and Sharing Center**.

-#### Create a security group and add members

-1. Open **Active Directory Users and Computers**.

-1. Right-select the domain name, choose **New**, and then select **Organizational Unit**.

-1. In the name box, type *LocalObjects*, then select **OK**.

-1. Select and right-click **LocalObjects** in the navigation pane. Select **New** and then **Group**.

-1. Type *FileServerAccess* in the **Group name** box. For the **Group Scope**, select **Domain local**, then choose **OK**.

-1. In the content pane, double-click **FileServerAccess**. Select **Members**, choose to **Add**, then select **Locations**.

-1. Select your on-premises Active Directory from the **Location** view, then choose **OK**.

-1. Type *Domain Users* in the **Enter the object names to select** box. Select **Check Names**, provide credentials for the on-premises Active Directory, then select **OK**.

- > [!NOTE]

- > You must provide credentials because the trust relationship is only one way. This means users from the Domain Services managed domain can't access resources or search for users or groups in the trusted (on-premises) domain.

-1. The **Domain Users** group from your on-premises Active Directory should be a member of the **FileServerAccess** group. Select **OK** to save the group and close the window.

-#### Create a file share for cross-forest access

-1. On the Windows Server VM joined to the Domain Services forest, create a folder and provide name such as *CrossForestShare*.

-1. Right-select the folder and choose **Properties**.

-1. Select the **Security** tab, then choose **Edit**.

-1. In the *Permissions for CrossForestShare* dialog box, select **Add**.

-1. Type *FileServerAccess* in **Enter the object names to select**, then select **OK**.

-1. Select *FileServerAccess* from the **Groups or user names** list. In the **Permissions for FileServerAccess** list, choose *Allow* for the **Modify** and **Write** permissions, then select **OK**.

-1. Select the **Sharing** tab, then choose **Advanced Sharing…**.

-1. Choose **Share this folder**, then enter a memorable name for the file share in **Share name** such as *CrossForestShare*.

-1. Select **Permissions**. In the **Permissions for Everyone** list, choose **Allow** for the **Change** permission.

-1. Select **OK** two times and then **Close**.

-#### Validate cross-forest authentication to a resource

-1. Sign in a Windows computer joined to your on-premises Active Directory using a user account from your on-premises Active Directory.

-1. Using **Windows Explorer**, connect to the share you created using the fully qualified host name and the share such as `\\fs1.aaddscontoso.com\CrossforestShare`.

-1. To validate the write permission, right-select in the folder, choose **New**, then select **Text Document**. Use the default name **New Text Document**.

- If the write permissions are set correctly, a new text document is created. The following steps will then open, edit, and delete the file as appropriate.

-1. To validate the read permission, open **New Text Document**.

-1. To validate the modify permission, add text to the file and close **Notepad**. When prompted to save changes, choose **Save**.

-1. To validate the delete permission, right-select **New Text Document** and choose **Delete**. Choose **Yes** to confirm file deletion.

-## Next steps

-In this tutorial, you learned how to:

-> [!div class="checklist"]

-> * Configure DNS in an on-premises AD DS environment to support Domain Services connectivity

-> * Create a one-way inbound forest trust in an on-premises AD DS environment

-> * Create a one-way outbound forest trust in Domain Services

-> * Test and validate the trust relationship for authentication and resource access

-For more conceptual information about forest in Domain Services, see [How do forest trusts work in Domain Services?][concepts-trust].

-<!-- INTERNAL LINKS -->

-[concepts-trust]: concepts-forest-trust.md

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance-advanced]: tutorial-create-instance-advanced.md

-[howto-change-sku]: change-sku.md

-[vpn-gateway]: /azure/vpn-gateway/vpn-gateway-about-vpngateways

-[expressroute]: /azure/expressroute/expressroute-introduction

-[join-windows-vm]: join-windows-vm.md

-description: In this tutorial, you learn how to create and configure a customized Microsoft Entra Domain Services managed domain and specify advanced configuration options using the Microsoft Entra admin center.

-#Customer intent: As an identity administrator, I want to create a Microsoft Entra Domain Services managed domain and define advanced configuration options so that I can synchronize identity information with my Microsoft Entra tenant and provide Domain Services connectivity to virtual machines and applications in Azure.

-# Tutorial: Create and configure a Microsoft Entra Domain Services managed domain with advanced configuration options

-Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory. You consume these domain services without deploying, managing, and patching domain controllers yourself. Domain Services integrates with your existing Microsoft Entra tenant. This integration lets users sign in using their corporate credentials, and you can use existing groups and user accounts to secure access to resources.

-You can [create a managed domain using default configuration options][tutorial-create-instance] for networking and synchronization, or manually define these settings. This tutorial shows you how to define those advanced configuration options to create and configure a Domain Services managed domain using the Microsoft Entra admin center.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Configure DNS and virtual network settings for a managed domain

-> * Create a managed domain

-> * Add administrative users to domain management

-> * Enable password hash synchronization

-If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* You need [Application Administrator](/azure/active-directory/roles/permissions-reference#application-administrator) and [Groups Administrator](/azure/active-directory/roles/permissions-reference#groups-administrator) Microsoft Entra roles in your tenant to enable Domain Services.

-* You need [Domain Services Contributor](/azure/role-based-access-control/built-in-roles#domain-services-contributor) Azure role to create the required Domain Services resources.

-Although not required for Domain Services, it's recommended to [configure self-service password reset (SSPR)][configure-sspr] for the Microsoft Entra tenant. Users can change their password without SSPR, but SSPR helps if they forget their password and need to reset it.

-> [!IMPORTANT]

-> After you create a managed domain, you can't move it to a different subscription, resource group, or region. Take care to select the most appropriate subscription, resource group, and region when you deploy the managed domain.

-## Sign in to the Microsoft Entra admin center

-In this tutorial, you create and configure the managed domain using the Microsoft Entra admin center. To get started, first sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).

-## Create a managed domain and configure basic settings

-To launch the **Enable Microsoft Entra Domain Services** wizard, complete the following steps:

-1. On the Microsoft Entra admin center menu or from the **Home** page, select **Create a resource**.

-1. Enter *Domain Services* into the search bar, then choose *Microsoft Entra Domain Services* from the search suggestions.

-1. On the Microsoft Entra Domain Services page, select **Create**. The **Enable Microsoft Entra Domain Services** wizard is launched.

-1. Select the Azure **Subscription** in which you would like to create the managed domain.

-1. Select the **Resource group** to which the managed domain should belong. Choose to **Create new** or select an existing resource group.

-When you create a managed domain, you specify a DNS name. There are some considerations when you choose this DNS name:

-* **Built-in domain name:** By default, the built-in domain name of the directory is used (a *.onmicrosoft.com* suffix). If you wish to enable secure LDAP access to the managed domain over the internet, you can't create a digital certificate to secure the connection with this default domain. Microsoft owns the *.onmicrosoft.com* domain, so a Certificate Authority (CA) won't issue a certificate.

-* **Custom domain names:** The most common approach is to specify a custom domain name, typically one that you already own and is routable. When you use a routable, custom domain, traffic can correctly flow as needed to support your applications.

-* **Non-routable domain suffixes:** We generally recommend that you avoid a non-routable domain name suffix, such as *contoso.local*. The *.local* suffix isn't routable and can cause issues with DNS resolution.

-> [!TIP]

-> If you create a custom domain name, take care with existing DNS namespaces. It's recommended to use a domain name separate from any existing Azure or on-premises DNS name space.

->

-> For example, if you have an existing DNS name space of *contoso.com*, create a managed domain with the custom domain name of *aaddscontoso.com*. If you need to use secure LDAP, you must register and own this custom domain name to generate the required certificates.

->

-> You may need to create some additional DNS records for other services in your environment, or conditional DNS forwarders between existing DNS name spaces in your environment. For example, if you run a webserver that hosts a site using the root DNS name, there can be naming conflicts that require additional DNS entries.

->

-> In these tutorials and how-to articles, the custom domain of *aaddscontoso.com* is used as a short example. In all commands, specify your own domain name.

-The following DNS name restrictions also apply:

-* **Domain prefix restrictions:** You can't create a managed domain with a prefix longer than 15 characters. The prefix of your specified domain name (such as *aaddscontoso* in the *aaddscontoso.com* domain name) must contain 15 or fewer characters.

-* **Network name conflicts:** The DNS domain name for your managed domain shouldn't already exist in the virtual network. Specifically, check for the following scenarios that would lead to a name conflict:

- * If you already have an Active Directory domain with the same DNS domain name on the Azure virtual network.

- * If the virtual network where you plan to enable the managed domain has a VPN connection with your on-premises network. In this scenario, ensure you don't have a domain with the same DNS domain name on your on-premises network.

- * If you have an existing Azure cloud service with that name on the Azure virtual network.

-Complete the fields in the *Basics* window of the Microsoft Entra admin center to create a managed domain:

-1. Enter a **DNS domain name** for your managed domain, taking into consideration the previous points.

-1. Choose the Azure **Location** in which the managed domain should be created. If you choose a region that supports Availability Zones, the Domain Services resources are distributed across zones for additional redundancy.

- > [!TIP]

- > Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there's a minimum of three separate zones in all enabled regions.

- >

- > There's nothing for you to configure for Domain Services to be distributed across zones. The Azure platform automatically handles the zone distribution of resources. For more information and to see region availability, see [What are Availability Zones in Azure?][availability-zones]

-1. The **SKU** determines the performance and backup frequency. You can change the SKU after the managed domain has been created if your business demands or requirements change. For more information, see [Domain Services SKU concepts][concepts-sku].

- For this tutorial, select the *Standard* SKU.

-1. A *forest* is a logical construct used by Active Directory Domain Services to group one or more domains.

- 

-1. To manually configure additional options, choose **Next - Networking**. Otherwise, select **Review + create** to accept the default configuration options, then skip to the section to [Deploy your managed domain](#deploy-the-managed-domain). The following defaults are configured when you choose this create option:

- * Creates a virtual network named *aadds-vnet* that uses the IP address range of *10.0.1.0/24*.

- * Creates a subnet named *aadds-subnet* using the IP address range of *10.0.1.0/24*.

- * Synchronizes *All* users from Microsoft Entra ID into the managed domain.

-## Create and configure the virtual network

-To provide connectivity, an Azure virtual network and a dedicated subnet are needed. Domain Services is enabled in this virtual network subnet. In this tutorial, you create a virtual network, though you could instead choose to use an existing virtual network. In either approach, you must create a dedicated subnet for use by Domain Services.

-Some considerations for this dedicated virtual network subnet include the following areas:

-* The subnet must have at least 3-5 available IP addresses in its address range to support the Domain Services resources.

-* Don't select the *Gateway* subnet for deploying Domain Services. It's not supported to deploy Domain Services into a *Gateway* subnet.

-* Don't deploy any other virtual machines to the subnet. Applications and VMs often use network security groups to secure connectivity. Running these workloads in a separate subnet lets you apply those network security groups without disrupting connectivity to your managed domain.

-For more information on how to plan and configure the virtual network, see [networking considerations for Microsoft Entra Domain Services][network-considerations].

-Complete the fields in the *Network* window as follows:

-1. On the **Network** page, choose a virtual network to deploy Domain Services into from the drop-down menu, or select **Create new**.

- 1. If you choose to create a virtual network, enter a name for the virtual network, such as *myVnet*, then provide an address range, such as *10.0.1.0/24*.

- 1. Create a dedicated subnet with a clear name, such as *DomainServices*. Provide an address range, such as *10.0.1.0/24*.

- [ ](./media/tutorial-create-instance-advanced/create-vnet-expanded.png#lightbox)

- Make sure to pick an address range that is within your private IP address range. IP address ranges you don't own that are in the public address space cause errors within Domain Services.

-1. Select a virtual network subnet, such as *DomainServices*.

-1. When ready, choose **Next - Administration**.

-## Configure an administrative group

-A special administrative group named *AAD DC Administrators* is used for management of the Domain Services domain. Members of this group are granted administrative permissions on VMs that are domain-joined to the managed domain. On domain-joined VMs, this group is added to the local administrators group. Members of this group can also use Remote Desktop to connect remotely to domain-joined VMs.

-> [!IMPORTANT]

-> You don't have *Domain Administrator* or *Enterprise Administrator* permissions on a managed domain using Domain Services. These permissions are reserved by the service and aren't made available to users within the tenant.

->

-> Instead, the *AAD DC Administrators* group lets you perform some privileged operations. These operations include belonging to the administration group on domain-joined VMs, and configuring Group Policy.

-The wizard automatically creates the *AAD DC Administrators* group in your Microsoft Entra directory. If you have an existing group with this name in your Microsoft Entra directory, the wizard selects this group. You can optionally choose to add additional users to this *AAD DC Administrators* group during the deployment process. These steps can be completed later.

-1. To add additional users to this *AAD DC Administrators* group, select **Manage group membership**.

- 

-1. Select the **Add members** button, then search for and select users from your Microsoft Entra directory. For example, search for your own account, and add it to the *AAD DC Administrators* group.

-1. If desired, change or add additional recipients for notifications when there are alerts in the managed domain that require attention.

-1. When ready, choose **Next - Synchronization**.

-## Configure synchronization

-Domain Services lets you synchronize *all* users and groups available in Microsoft Entra ID, or a *scoped* synchronization of only specific groups. You can change the synchronize scope now, or once the managed domain is deployed. For more information, see [Microsoft Entra Domain Services scoped synchronization][scoped-sync].

-1. For this tutorial, choose to synchronize **All** users and groups. This synchronization choice is the default option.

- 

-1. Select **Review + create**.

-## Deploy the managed domain

-On the **Summary** page of the wizard, review the configuration settings for your managed domain. You can go back to any step of the wizard to make changes. To redeploy a managed domain to a different Microsoft Entra tenant in a consistent way using these configuration options, you can also **Download a template for automation**.

-1. To create the managed domain, select **Create**. A note is displayed that certain configuration options like DNS name or virtual network can't be changed once the Domain Services managed has been created. To continue, select **OK**.

-1. The process of provisioning your managed domain can take up to an hour. A notification is displayed in the portal that shows the progress of your Domain Services deployment. Select the notification to see detailed progress for the deployment.

- 

-1. Select your resource group, such as *myResourceGroup*, then choose your managed domain from the list of Azure resources, such as *aaddscontoso.com*. The **Overview** tab shows that the managed domain is currently *Deploying*. You can't configure the managed domain until it's fully provisioned.

- 

-1. When the managed domain is fully provisioned, the **Overview** tab shows the domain status as *Running*.

- 

-> [!IMPORTANT]

-> The managed domain is associated with your Microsoft Entra tenant. During the provisioning process, Domain Services creates two Enterprise Applications named *Domain Controller Services* and *AzureActiveDirectoryDomainControllerServices* in the Microsoft Entra tenant. These Enterprise Applications are needed to service your managed domain. Don't delete these applications.

-## Update DNS settings for the Azure virtual network

-With Domain Services successfully deployed, now configure the virtual network to allow other connected VMs and applications to use the managed domain. To provide this connectivity, update the DNS server settings for your virtual network to point to the two IP addresses where the managed domain is deployed.

-1. The **Overview** tab for your managed domain shows some **Required configuration steps**. The first configuration step is to update DNS server settings for your virtual network. Once the DNS settings are correctly configured, this step is no longer shown.

- The addresses listed are the domain controllers for use in the virtual network. In this example, those addresses are *10.0.1.4* and *10.0.1.5*. You can later find these IP addresses on the **Properties** tab.

- 

-1. To update the DNS server settings for the virtual network, select the **Configure** button. The DNS settings are automatically configured for your virtual network.

-> [!TIP]

-> If you selected an existing virtual network in the previous steps, any VMs connected to the network only get the new DNS settings after a restart. You can restart VMs using the Microsoft Entra admin center, Azure PowerShell, or the Azure CLI.

-<a name='enable-user-accounts-for-azure-ad-ds'></a>

-## Enable user accounts for Domain Services

-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.

-> [!NOTE]

-> 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 re-used if you later create a 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][password-hash-sync-process].

-The steps to generate and store these password hashes are different for cloud-only user accounts created in Microsoft Entra ID versus user accounts that are synchronized from your on-premises directory using Microsoft Entra Connect.

-A cloud-only user account is an account that was created in your Microsoft Entra directory using either the Microsoft Entra admin center or Azure AD PowerShell cmdlets. These user accounts aren't synchronized from an on-premises directory.

-In this tutorial, let's work with a basic cloud-only user account. For more information on the additional steps required to use Microsoft Entra Connect, see [Synchronize password hashes for user accounts synced from your on-premises AD to your managed domain][on-prem-sync].

-> [!TIP]

-> If your Microsoft Entra tenant has a combination of cloud-only users and users from your on-premises AD, you need to complete both sets of steps.

-For cloud-only user accounts, users must change their passwords before they can use Domain Services. 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. Either expire the passwords for all cloud users in the tenant who need to use Domain Services, which forces a password change on next sign-in, or instruct cloud users to manually change their passwords. For this tutorial, let's manually change a user password.

-Before a user can reset their password, the Microsoft Entra tenant must be [configured for self-service password reset][configure-sspr].

-To change the password for a cloud-only user, the user must complete the following steps:

-1. Go to the Microsoft Entra ID Access Panel page at [https://myapps.microsoft.com](https://myapps.microsoft.com).

-1. In the top-right corner, select your name, then choose **Profile** from the drop-down menu.

- 

-1. On the **Profile** page, select **Change password**.

-1. On the **Change password** page, enter your existing (old) password, then enter and confirm a new password.

-1. Select **Submit**.

-It takes a few minutes after you've changed your password for the new password to be usable in Domain Services and to successfully sign in to computers joined to the managed domain.

-## Next steps

-In this tutorial, you learned how to:

-> [!div class="checklist"]

-> * Configure DNS and virtual network settings for a managed domain

-> * Create a managed domain

-> * Add administrative users to domain management

-> * Enable user accounts for Domain Services and generate password hashes

-To see this managed domain in action, create and join a virtual machine to the domain.

-> [!div class="nextstepaction"]

-> [Join a Windows Server virtual machine to your managed domain](join-windows-vm.md)

-<!-- INTERNAL LINKS -->

-[tutorial-create-instance]: tutorial-create-instance.md

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[network-considerations]: network-considerations.md

-[create-dedicated-subnet]: /azure/virtual-network/virtual-network-manage-subnet#add-a-subnet

-[scoped-sync]: scoped-synchronization.md

-[on-prem-sync]: tutorial-configure-password-hash-sync.md

-[configure-sspr]: /azure/active-directory/authentication/tutorial-enable-sspr

-[password-hash-sync-process]: /azure/active-directory/hybrid/connect/how-to-connect-password-hash-synchronization#password-hash-sync-process-for-azure-ad-domain-services

-[resource-forests]: ./concepts-forest-trust.md

-[availability-zones]: /azure/reliability/availability-zones-overview

-[concepts-sku]: administration-concepts.md#azure-ad-ds-skus

-<!-- EXTERNAL LINKS -->

-description: In this tutorial, you learn how to create and configure a Microsoft Entra Domain Services managed domain using the Microsoft Entra admin center.

-#Customer intent: As an identity administrator, I want to create a Microsoft Entra Domain Services managed domain so that I can synchronize identity information with my Microsoft Entra tenant and provide Domain Services connectivity to virtual machines and applications in Azure.

-# Tutorial: Create and configure a Microsoft Entra Domain Services managed domain

-Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory. You consume these domain services without deploying, managing, and patching domain controllers yourself. Domain Services integrates with your existing Microsoft Entra tenant. This integration lets users sign in using their corporate credentials, and you can use existing groups and user accounts to secure access to resources.

-You can create a managed domain using default configuration options for networking and synchronization, or [manually define these settings][tutorial-create-instance-advanced]. This tutorial shows you how to use default options to create and configure a Domain Services managed domain using the Microsoft Entra admin center.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Understand DNS requirements for a managed domain

-> * Create a managed domain

-> * Enable password hash synchronization

-If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* You need [Application Administrator](/azure/active-directory/roles/permissions-reference#application-administrator) and [Groups Administrator](/azure/active-directory/roles/permissions-reference#groups-administrator) Microsoft Entra roles in your tenant to enable Domain Services.

-* You need [Domain Services Contributor](/azure/role-based-access-control/built-in-roles#domain-services-contributor) Azure role to create the required Domain Services resources.

-* A virtual network with DNS servers that can query necessary infrastructure such as storage. DNS servers that can't perform general internet queries might block the ability to create a managed domain.

-Although not required for Domain Services, it's recommended to [configure self-service password reset (SSPR)][configure-sspr] for the Microsoft Entra tenant. Users can change their password without SSPR, but SSPR helps if they forget their password and need to reset it.

-> [!IMPORTANT]

-> You can't move the managed domain to a different subscription, resource group, or region after you create it. Take care to select the most appropriate subscription, resource group, and region when you deploy the managed domain.

-## Sign in to the Microsoft Entra admin center

-In this tutorial, you create and configure the managed domain using the Microsoft Entra admin center. To get started, first sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).

-## Create a managed domain

-To launch the **Enable Microsoft Entra Domain Services** wizard, complete the following steps:

-1. On the Microsoft Entra admin center menu or from the **Home** page, select **Create a resource**.

-1. Enter *Domain Services* into the search bar, then choose *Microsoft Entra Domain Services* from the search suggestions.

-1. On the Microsoft Entra Domain Services page, select **Create**. The **Enable Microsoft Entra Domain Services** wizard is launched.

-1. Select the Azure **Subscription** in which you would like to create the managed domain.

-1. Select the **Resource group** to which the managed domain should belong. Choose to **Create new** or select an existing resource group.

-When you create a managed domain, you specify a DNS name. There are some considerations when you choose this DNS name:

-* **Built-in domain name:** By default, the built-in domain name of the directory is used (a *.onmicrosoft.com* suffix). If you wish to enable secure LDAP access to the managed domain over the internet, you can't create a digital certificate to secure the connection with this default domain. Microsoft owns the *.onmicrosoft.com* domain, so a Certificate Authority (CA) won't issue a certificate.

-* **Custom domain names:** The most common approach is to specify a custom domain name, typically one that you already own and is routable. When you use a routable, custom domain, traffic can correctly flow as needed to support your applications.

-* **Non-routable domain suffixes:** We generally recommend that you avoid a non-routable domain name suffix, such as *contoso.local*. The *.local* suffix isn't routable and can cause issues with DNS resolution.

-> [!TIP]

-> If you create a custom domain name, take care with existing DNS namespaces. Although it's supported, you may want to use a domain name separate from any existing Azure or on-premises DNS namespace.

->

-> For example, if you have an existing DNS name space of *contoso.com*, create a managed domain with the custom domain name of *aaddscontoso.com*. If you need to use secure LDAP, you must register and own this custom domain name to generate the required certificates.

->

-> You may need to create some additional DNS records for other services in your environment, or conditional DNS forwarders between existing DNS name spaces in your environment. For example, if you run a webserver that hosts a site using the root DNS name, there can be naming conflicts that require additional DNS entries.

->

-> In these tutorials and how-to articles, the custom domain of *aaddscontoso.com* is used as a short example. In all commands, specify your own domain name.

-The following DNS name restrictions also apply:

-* **Domain prefix restrictions:** You can't create a managed domain with a prefix longer than 15 characters. The prefix of your specified domain name (such as *aaddscontoso* in the *aaddscontoso.com* domain name) must contain 15 or fewer characters.

-* **Network name conflicts:** The DNS domain name for your managed domain shouldn't already exist in the virtual network. Specifically, check for the following scenarios that would lead to a name conflict:

- * If you already have an Active Directory domain with the same DNS domain name on the Azure virtual network.

- * If the virtual network where you plan to enable the managed domain has a VPN connection with your on-premises network. In this scenario, ensure you don't have a domain with the same DNS domain name on your on-premises network.

- * If you have an existing Azure cloud service with that name on the Azure virtual network.

-Complete the fields in the *Basics* window of the Microsoft Entra admin center to create a managed domain:

-1. Enter a **DNS domain name** for your managed domain, taking into consideration the previous points.

-1. Choose the Azure **Location** in which the managed domain should be created. If you choose a region that supports Azure Availability Zones, the Domain Services resources are distributed across zones for additional redundancy.

- > [!TIP]

- > Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there's a minimum of three separate zones in all enabled regions.

- >

- > There's nothing for you to configure for Domain Services to be distributed across zones. The Azure platform automatically handles the zone distribution of resources. For more information and to see region availability, see [What are Availability Zones in Azure?][availability-zones]

-1. The **SKU** determines the performance and backup frequency. You can change the SKU after the managed domain has been created if your business demands or requirements change. For more information, see [Domain Services SKU concepts][concepts-sku].

- For this tutorial, select the *Standard* SKU.

-1. A *forest* is a logical construct used by Active Directory Domain Services to group one or more domains.

- 

-To quickly create a managed domain, you can select **Review + create** to accept additional default configuration options. The following defaults are configured when you choose this create option:

-* Creates a virtual network named *aadds-vnet* that uses the IP address range of *10.0.2.0/24*.

-* Creates a subnet named *aadds-subnet* using the IP address range of *10.0.2.0/24*.

-* Synchronizes *All* users from Microsoft Entra ID into the managed domain.

->[!NOTE]

->You shouldn't use public IP addresses for virtual networks and their subnets due to the following issues:

->

->- **Scarcity of the IP address**: IPv4 public IP addresses are limited, and their demand often exceeds the available supply. Also, there are potentially overlapping IPs with public endpoints.

->- **Security risks**: Using public IPs for virtual networks exposes your devices directly to the internet, increasing the risk of unauthorized access and potential attacks. Without proper security measures, your devices may become vulnerable to various threats.

->

->- **Complexity**: Managing a virtual network with public IPs can be more complex than using private IPs, as it requires dealing with external IP ranges and ensuring proper network segmentation and security.

->

->It is strongly recommended to use private IP addresses. If you use a public IP, ensure you are the owner/dedicated user of the chosen IPs in the public range you chose.

-Select **Review + create** to accept these default configuration options.

-## Deploy the managed domain

-On the **Summary** page of the wizard, review the configuration settings for your managed domain. You can go back to any step of the wizard to make changes. To redeploy a managed domain to a different Microsoft Entra tenant in a consistent way using these configuration options, you can also **Download a template for automation**.

-1. To create the managed domain, select **Create**. A note is displayed that certain configuration options such as DNS name or virtual network can't be changed once the Domain Services managed has been created. To continue, select **OK**.

-1. The process of provisioning your managed domain can take up to an hour. A notification is displayed in the portal that shows the progress of your Domain Services deployment. Select the notification to see detailed progress for the deployment.

- 

-1. The page will load with updates on the deployment process, including the creation of new resources in your directory.

-1. Select your resource group, such as *myResourceGroup*, then choose your managed domain from the list of Azure resources, such as *aaddscontoso.com*. The **Overview** tab shows that the managed domain is currently *Deploying*. You can't configure the managed domain until it's fully provisioned.

- 

-1. When the managed domain is fully provisioned, the **Overview** tab shows the domain status as *Running*.

- 

-> [!IMPORTANT]

-> The managed domain is associated with your Microsoft Entra tenant. During the provisioning process, Domain Services creates two Enterprise Applications named *Domain Controller Services* and *AzureActiveDirectoryDomainControllerServices* in the Microsoft Entra tenant. These Enterprise Applications are needed to service your managed domain. Don't delete these applications.

-## Update DNS settings for the Azure virtual network

-With Domain Services successfully deployed, now configure the virtual network to allow other connected VMs and applications to use the managed domain. To provide this connectivity, update the DNS server settings for your virtual network to point to the two IP addresses where the managed domain is deployed.

-1. The **Overview** tab for your managed domain shows some **Required configuration steps**. The first configuration step is to update DNS server settings for your virtual network. Once the DNS settings are correctly configured, this step is no longer shown.

- The addresses listed are the domain controllers for use in the virtual network. In this example, those addresses are *10.0.2.4* and *10.0.2.5*. You can later find these IP addresses on the **Properties** tab.

- 

-1. To update the DNS server settings for the virtual network, select the **Configure** button. The DNS settings are automatically configured for your virtual network.

-> [!TIP]

-> If you selected an existing virtual network in the previous steps, any VMs connected to the network only get the new DNS settings after a restart. You can restart VMs using the Microsoft Entra admin center, Microsoft Graph PowerShell, or the Azure CLI.

-<a name='enable-user-accounts-for-azure-ad-ds'></a>

-## Enable user accounts for Domain Services

-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.

-> [!NOTE]

-> 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 re-used if you later create a 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.

->

-> [Microsoft Entra Connect Cloud Sync is not supported with Domain Services](/azure/active-directory/hybrid/cloud-sync/what-is-cloud-sync#comparison-between-azure-ad-connect-and-cloud-sync). On-premises users need to be synced using Microsoft Entra Connect in order to be able to access domain-joined VMs. For more information, see [Password hash sync process for Domain Services and Microsoft Entra Connect][password-hash-sync-process].

-The steps to generate and store these password hashes are different for cloud-only user accounts created in Microsoft Entra ID versus user accounts that are synchronized from your on-premises directory using Microsoft Entra Connect.

-A cloud-only user account is an account that was created in your Microsoft Entra directory by using either the Microsoft Entra admin center or PowerShell. These user accounts aren't synchronized from an on-premises directory.

-> In this tutorial, let's work with a basic cloud-only user account. For more information on the additional steps required to use Microsoft Entra Connect, see [Synchronize password hashes for user accounts synced from your on-premises AD to your managed domain][on-prem-sync].

-> [!TIP]

-> If your Microsoft Entra tenant has a combination of cloud-only users and users from your on-premises AD, you need to complete both sets of steps.

-For cloud-only user accounts, users must change their passwords before they can use Domain Services. 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. Either expire the passwords for all cloud users in the tenant who need to use Domain Services, which forces a password change on next sign-in, or instruct cloud users to manually change their passwords. For this tutorial, let's manually change a user password.

-Before a user can reset their password, the Microsoft Entra tenant must be [configured for self-service password reset][configure-sspr].

-To change the password for a cloud-only user, the user must complete the following steps:

-1. Go to the Microsoft Entra ID Access Panel page at [https://myapps.microsoft.com](https://myapps.microsoft.com).

-1. In the top-right corner, select your name, then choose **Profile** from the drop-down menu.

- 

-1. On the **Profile** page, select **Change password**.

-1. On the **Change password** page, enter your existing (old) password, then enter and confirm a new password.

-1. Select **Submit**.

-It takes a few minutes after you've changed your password for the new password to be usable in Domain Services and to successfully sign in to computers joined to the managed domain.

-## Next steps

-In this tutorial, you learned how to:

-> [!div class="checklist"]

-> * Understand DNS requirements for a managed domain

-> * Create a managed domain

-> * Add administrative users to domain management

-> * Enable user accounts for Domain Services and generate password hashes

-Before you domain-join VMs and deploy applications that use the managed domain, configure an Azure virtual network for application workloads.

-> [!div class="nextstepaction"]

-> [Configure Azure virtual network for application workloads to use your managed domain](tutorial-configure-networking.md)

-<!-- INTERNAL LINKS -->

-[tutorial-create-instance-advanced]: tutorial-create-instance-advanced.md

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[network-considerations]: network-considerations.md

-[create-dedicated-subnet]: /azure/virtual-network/virtual-network-manage-subnet#add-a-subnet

-[scoped-sync]: scoped-synchronization.md

-[on-prem-sync]: tutorial-configure-password-hash-sync.md

-[configure-sspr]: /azure/active-directory/authentication/tutorial-enable-sspr

-[password-hash-sync-process]: /azure/active-directory/hybrid/connect/how-to-connect-password-hash-synchronization#password-hash-sync-process-for-azure-ad-domain-services

-[tutorial-create-instance-advanced]: tutorial-create-instance-advanced.md

-[skus]: overview.md

-[resource-forests]: ./concepts-forest-trust.md

-[availability-zones]: /azure/reliability/availability-zones-overview

-[concepts-sku]: administration-concepts.md#azure-ad-ds-skus

-<!-- EXTERNAL LINKS -->

-[naming-prefix]: /windows-server/identity/ad-ds/plan/selecting-the-forest-root-domain#selecting-a-prefix

-description: In this tutorial, you learn how to create and configure a Windows virtual machine that you use to administer Microsoft Entra Domain Services managed domain.

-#Customer intent: As an identity administrator, I want to create a management VM and install the required tools to connect to and manage a Microsoft Entra Domain Services managed domain.

-# Tutorial: Create a management VM to configure and administer a Microsoft Entra Domain Services managed domain

-Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, LDAP, and Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory. You administer this managed domain using the same Remote Server Administration Tools (RSAT) as with an on-premises Active Directory Domain Services domain. As Domain Services is a managed service, there are some administrative tasks that you can't perform, such as using remote desktop protocol (RDP) to connect to the domain controllers.

-This tutorial shows you how to configure a Windows Server VM in Azure and install the required tools to administer a Domain Services managed domain.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Understand the available administrative tasks in a managed domain

-> * Install the Active Directory administrative tools on a Windows Server VM

-> * Use the Active Directory Administrative Center to perform common tasks

-If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, see the first tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server VM that is joined to the managed domain.

- * If needed, see the previous tutorial to [create a Windows Server VM and join it to a managed domain][create-join-windows-vm].

-* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

-* An Azure Bastion host deployed in your Domain Services virtual network.

- * If needed, [create an Azure Bastion host][azure-bastion].

-## Sign in to the Microsoft Entra admin center

-In this tutorial, you create and configure a management VM using the Microsoft Entra admin center. To get started, first sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).

-<a name='available-administrative-tasks-in-azure-ad-ds'></a>

-## Available administrative tasks in Domain Services

-Domain Services provides a managed domain for your users, applications, and services to consume. This approach changes some of the available management tasks you can do, and what privileges you have within the managed domain. These tasks and permissions may be different than what you experience with a regular on-premises Active Directory Domain Services environment. You also can't connect to domain controllers on the managed domain using Remote Desktop.

-### Administrative tasks you can perform on a managed domain

-Members of the *AAD DC Administrators* group are granted privileges on the managed domain that enables them to do tasks such as:

-* Configure the built-in group policy object (GPO) for the *AADDC Computers* and *AADDC Users* containers in the managed domain.

-* Administer DNS on the managed domain.

-* Create and administer custom organizational units (OUs) on the managed domain.

-* Gain administrative access to computers joined to the managed domain.

-### Administrative privileges you don't have on a managed domain

-The managed domain is locked down, so you don't have privileges to do certain administrative tasks on the domain. Some of the following examples are tasks you can't do:

-* Extend the schema of the managed domain.

-* Connect to domain controllers for the managed domain using Remote Desktop.

-* Add domain controllers to the managed domain.

-* You don't have *Domain Administrator* or *Enterprise Administrator* privileges for the managed domain.

-## Sign in to the Windows Server VM

-In the previous tutorial, a Windows Server VM was created and joined to the managed domain. Use that VM to install the management tools. If needed, [follow the steps in the tutorial to create and join a Windows Server VM to a managed domain][create-join-windows-vm].

-> [!NOTE]

-> In this tutorial, you use a Windows Server VM in Azure that is joined to the managed domain. You can also use a Windows client, such as Windows 10, that is joined to the managed domain.

->

-> For more information on how to install the administrative tools on a Windows client, see [install Remote Server Administration Tools (RSAT)](https://social.technet.microsoft.com/wiki/contents/articles/2202.remote-server-administration-tools-rsat-for-windows-client-and-windows-server-dsforum2wiki.aspx)

-To get started, connect to the Windows Server VM as follows:

-1. In the Microsoft Entra admin center, select **Resource groups** on the left-hand side. Choose the resource group where your VM was created, such as *myResourceGroup*, then select the VM, such as *myVM*.

-1. In the **Overview** pane for your VM, select **Connect**, then **Bastion**.

- 

-1. Enter the credentials for your VM, then select **Connect**.

- 

-If needed, allow your web browser to open pop-ups for the Bastion connection to be displayed. It takes a few seconds to make the connection to your VM.

-## Install Active Directory administrative tools

-You use the same administrative tools in a managed domain as on-premises AD DS environments, such as the Active Directory Administrative Center (ADAC) or AD PowerShell. These tools can be installed as part of the Remote Server Administration Tools (RSAT) feature on Windows Server and client computers. Members of the *AAD DC Administrators* group can then administer managed domains remotely using these AD administrative tools from a computer that is joined to the managed domain.

-To install the Active Directory Administration tools on a domain-joined VM, complete the following steps:

-1. If **Server Manager** doesn't open by default when you sign in to the VM, select the **Start** menu, then choose **Server Manager**.

-1. In the *Dashboard* pane of the **Server Manager** window, select **Add Roles and Features**.

-1. On the **Before You Begin** page of the *Add Roles and Features Wizard*, select **Next**.

-1. For the *Installation Type*, leave the **Role-based or feature-based installation** option checked and select **Next**.

-1. On the **Server Selection** page, choose the current VM from the server pool, such as *myvm.aaddscontoso.com*, then select **Next**.

-1. On the **Server Roles** page, click **Next**.

-1. On the **Features** page, expand the **Remote Server Administration Tools** node, then expand the **Role Administration Tools** node.

- Choose **AD DS and AD LDS Tools** feature from the list of role administration tools, then select **Next**.

- 

-1. On the **Confirmation** page, select **Install**. It may take a minute or two to install the administrative tools.

-1. When feature installation is complete, select **Close** to exit the **Add Roles and Features** wizard.

-## Use Active Directory administrative tools

-With the administrative tools installed, let's see how to use them to administer the managed domain. Make sure that you're signed in to the VM with a user account that's a member of the *AAD DC Administrators* group.

-1. From the **Start** menu, select **Windows Administrative Tools**. The AD administrative tools installed in the previous step are listed.

- 

-1. Select **Active Directory Administrative Center**.

-1. To explore the managed domain, choose the domain name in the left pane, such as *aaddscontoso*. Two containers named *AADDC Computers* and *AADDC Users* are at the top of the list.

- 

-1. To see the users and groups that belong to the managed domain, select the **AADDC Users** container. The user accounts and groups from your Microsoft Entra tenant are listed in this container.

- In the following example output, a user account named *Contoso Admin* and a group for *AAD DC Administrators* are shown in this container.

- 

-1. To see the computers that are joined to the managed domain, select the **AADDC Computers** container. An entry for the current virtual machine, such as *myVM*, is listed. Computer accounts for all devices that are joined to the managed domain are stored in this *AADDC Computers* container.

-Common Active Directory Administrative Center actions such as resetting a user account password or managing group membership are available. These actions only work for users and groups created directly in the managed domain. Identity information only synchronizes *from* Microsoft Entra ID to Domain Services. There's no write back from Domain Services to Microsoft Entra ID. You can't change passwords or managed group membership for users synchronized from Microsoft Entra ID and have those changes synchronized back.

-You can also use the *Active Directory Module for Windows PowerShell*, installed as part of the administrative tools, to manage common actions in your managed domain.

-## Next steps

-In this tutorial, you learned how to:

-> [!div class="checklist"]

-> * Understand the available administrative tasks in a managed domain

-> * Install the Active Directory administrative tools on a Windows Server VM

-> * Use the Active Directory Administrative Center to perform common tasks

-To safely interact with your managed domain from other applications, enable secure Lightweight Directory Access Protocol (LDAPS).

-> [!div class="nextstepaction"]

-> [Configure secure LDAP for your managed domain](tutorial-configure-ldaps.md)

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[create-join-windows-vm]: join-windows-vm.md

-[azure-bastion]: /azure/bastion/tutorial-create-host-portal

-description: Learn how to create and use replica sets in the Microsoft Entra admin center for service resiliency with Microsoft Entra Domain Services

-#Customer intent: As an identity administrator, I want to create and use replica sets in Microsoft Entra Domain Services to provide resiliency or geographical distributed managed domain data.

-# Tutorial: Create and use replica sets for resiliency or geolocation in Microsoft Entra Domain Services

-To improve the resiliency of a Microsoft Entra Domain Services managed domain, or deploy to additional geographic locations close to your applications, you can use *replica sets*. Every Domain Services managed domain namespace, such as *aaddscontoso.com*, contains one initial replica set. The ability to create additional replica sets in other Azure regions provides geographical resiliency for a managed domain.

-You can add a replica set to any peered virtual network in any Azure region that supports Domain Services.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Understand the virtual network requirements

-> * Create a replica set

-> * Delete a replica set

-If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-## Prerequisites

-To complete this tutorial, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain created using the Azure Resource Manager deployment model and configured in your Microsoft Entra tenant.

- * If needed, [create and configure a Microsoft Entra Domain Services managed domain][tutorial-create-instance].

- > [!IMPORTANT]

- > You need to use a minimum of *Enterprise* SKU for your managed domain to support replica sets. If needed, [change the SKU for a managed domain][howto-change-sku].

-## Sign in to the Microsoft Entra admin center

-In this tutorial, you create and manage replica sets using the Microsoft Entra admin center. To get started, first sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).

-## Networking considerations

-The virtual networks that host replica sets must be able to communicate with each other. Applications and services that depend on Domain Services also need network connectivity to the virtual networks hosting the replica sets. Azure virtual network peering should be configured between all virtual networks to create a fully meshed network. These peerings enable effective intra-site replication between replica sets.

-Before you can use replica sets in Domain Services, review the following Azure virtual network requirements:

-* Avoid overlapping IP address spaces to allow for virtual network peering and routing.

-* Create subnets with enough IP addresses to support your scenario.

-* Make sure Domain Services has its own subnet. Don't share this virtual network subnet with application VMs and services.

-* Peered virtual networks are NOT transitive.

-> [!TIP]

-> When you create a replica set in the Microsoft Entra admin center, the network peerings between virtual networks is created for you.

->

-> If needed, you can create a virtual network and subnet when you add a replica set in the Microsoft Entra admin center. Or, you can choose existing virtual network resources in the destination region for a replica set and let the peerings be created automatically if they don't already exist.

-## Create a replica set

-When you create a managed domain, such as *aaddscontoso.com*, an initial replica set is created. Additional replica sets share the same namespace and configuration. Changes to Domain Services, including configuration, user identity and credentials, groups, group policy objects, computer objects, and other changes are applied to all replica sets in the managed domain using AD DS replication.

-In this tutorial, you create an additional replica set in an Azure region different than the initial Domain Services replica set.

-To create an additional replica set, complete the following steps:

-1. In the Microsoft Entra admin center, search for and select **Microsoft Entra Domain Services**.

-1. Choose your managed domain, such as *aaddscontoso.com*.

-1. On the left-hand side, select **Replica sets**. Each managed domain includes one initial replica set in the selected region, as shown in the following example screenshot:

- 

- To create an additional replica set, select **+ Add**.

-1. In the *Add a replica set* window, select the destination region, such as *East US*.

- Select a virtual network in the destination region, such as *vnet-eastus*, then choose a subnet such as *aadds-subnet*. If needed, choose **Create new** to add a virtual network in the destination region, then **Manage** to create a subnet for Domain Services.

- If they don't already exist, the Azure virtual network peerings are automatically created between your existing managed domain's virtual network and the destination virtual network.

- The following example screenshot shows the process to create a new replica set in *East US*:

- 

-1. When ready, select **Save**.

-The process to create the replica set takes some time as the resources are created in the destination region. The managed domain itself is then replicated using AD DS replication.

-The replica set reports as *Provisioning* as deployment continues, as shown in the following example screenshot. When complete, the replica set shows as *Running*.

-

-## Delete a replica set

-A managed domain is currently limited to five replicas - the initial replica set, and four additional replica sets. If you don't need a replica set anymore, or if you want to create a replica set in another region, you can delete unneeded replica sets.

-> [!IMPORTANT]

-> You can't delete either the last replica set or the initial replica set in a managed domain.

-To delete a replica set, complete the following steps:

-1. In the Microsoft Entra admin center, search for and select **Microsoft Entra Domain Services**.

-1. Choose your managed domain, such as *aaddscontoso.com*.

-1. On the left-hand side, select **Replica sets**. From the list of replica sets, select the **...** context menu next to the replica set you want to delete.

-1. Select **Delete** from the context menu, then confirm you want to delete the replica set.

-1. In the Domain Services management VM, access the DNS console and manually delete DNS records for the domain controllers from the deleted replica set.

-> [!NOTE]

-> Replica set deletion may be a time-consuming operation.

-If you no longer need the virtual network or peering used by the replica set, you can also delete those resources. Make sure no other application resources in the other region need the network connections before you delete them.

-## Next steps

-In this tutorial, you learned how to:

-> [!div class="checklist"]

-> * Configure virtual network peering

-> * Create a replica set in a different geographic region

-> * Delete a replica set

-For more conceptual information, learn how replica sets work in Domain Services.

-> [!div class="nextstepaction"]

-> [Replica sets concepts and features][concepts-replica-sets]

-<!-- INTERNAL LINKS -->

-[replica-sets]: concepts-replica-sets.md

-[tutorial-create-instance]: tutorial-create-instance-advanced.md

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[howto-change-sku]: change-sku.md

-[concepts-replica-sets]: concepts-replica-sets.md

-description: Learn how to perform a disaster recovery drill using replica sets in Microsoft Entra Domain Services

-#Customer intent: As an identity administrator, I want to perform a disaster recovery drill by using replica sets in Microsoft Entra Domain Services to demonstrate resiliency for geographically distributed domain data.

-# Tutorial: Perform a disaster recovery drill using replica sets in Microsoft Entra Domain Services

-This topic shows how to perform a disaster recovery (DR) drill for Microsoft Entra Domain Services using replica sets. This excercise simulates one of the replica sets going offline by making changes to the network virtual network properties to block client access to it. It's not a true DR drill in that the replica set isn't taken offline.

-The DR drill covers:

-1. A client machine is connected to a given replica set. It can authenticate to the domain and perform LDAP queries.

-1. The client's connection to the replica set will be terminated. This will happen by restricting network access.

-1. The client then establishes a new connection with the other replica set. Once that happens, the client is able to authenticate to the domain and perform LDAP queries.

-1. The domain member will be rebooted, and a domain user can sign in after reboot.

-1. The network restrictions are removed, and the client can connect to original replica set.

-## Prerequisites

-The following requirements must be in place to complete the DR drill:

-## Environment validation

-1. Log in to the client machine with a domain account.

-1. Install the Active Directory Domain Services RSAT tools.

-1. Start an elevated PowerShell window.

-1. Perform basic domain validation checks:

- - Run `nslookup [domain]` to ensure DNS resolution is working properly

- - Run `nltest /dsgetdc:` to return a success and say which domain controller is currently being used

- - Run `nltest /dclist:` to return the full list of domain controllers in the directory

-1. Perform basic domain controller validation on each domain controller in the directory (you can get the full list from the output of ΓÇ£nltest /dclist:ΓÇ¥):

- - Run `nltest /sc_reset:[domain name]\[domain controller name]` to establish a secure connection with the domain controller.

- - Run `Get-AdDomain` to retrieve the basic directory settings.

-## Perform the disaster recovery drill

-You need to perform these operations for each replica set in the Domain Services instance. The operations simulate an outage for each replica set. When domain controllers aren't reachable, the client automatically fails over to a reachable domain controller. This experience should be seamless to the end user or workload. Therefore, it's critical that applications and services don't point to a specific domain controller.

-1. Identify the domain controllers in the replica set that you want to simulate going offline.

-1. On the client machine, connect to one of the domain controllers using `nltest /sc_reset:[domain]\[domain controller name]`.

-1. In the Azure portal, go to the client virtual network peering and update the properties so that all traffic between the client and the replica set is blocked.

- 1. Select the peered network that you want to update.

- 1. Select to block all network traffic that enters or leaves the virtual network.

- 

-1. On the client machine, attempt to reestablish a secure connection with both domain controllers from step 2 using the same nltest command. These operations should fail as network connectivity has been blocked.

-1. Run `Get-AdDomain` and `Get-AdForest` to get basic directory properties. These calls will succeed because they are automatically going to one of the domain controllers in the other replica set.

-1. Reboot the client and login with the same domain account. This shows that authentication is still working as expected and logins are not blocked.

-1. In the Azure portal, go to the client virtual network peering and update the properties so that all traffic is unblocked. This reverts the changes that were made in step 3.

-1. On the client machine, attempt to reestablish a secure connection with the domain controllers from step 2 using the same nltest command. These operations should succeed as network connectivity has been unblocked.

-These operations demonstrate that the domain is still available even though one of the replica sets is unreachable by the client. Perform this set of steps for each replica set in the Domain Services instance.

-## Summary

-After you complete these steps, you see domain members continue to access the directory if one of the replica sets in the Domain Services isn't reachable. You can simulate the same behavior by blocking all network access for a replica set instead of a client machine, but we don't recommend it. It won't change the behavior from a client perspective, but it impacts the health of your Domain Services instance until the network access is restored.

-## Next steps

-In this tutorial, you learned how to:

-> [!div class="checklist"]

-> * Validate client connectivity to domain controllers in a replica set

-> * Block network traffic between the client and the replica set

-> * Validate client connectivity to domain controllers in another replica set

-For more conceptual information, learn how replica sets work in Domain Services.

-> [!div class="nextstepaction"]

-> [Replica sets concepts and features][concepts-replica-sets]

-<!-- INTERNAL LINKS -->

-[replica-sets]: concepts-replica-sets.md

-[tutorial-create-instance]: tutorial-create-instance-advanced.md

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[howto-change-sku]: change-sku.md

-[concepts-replica-sets]: concepts-replica-sets.md

-description: Learn how to use Azure Monitor Workbooks to review security audits and understand issues in a Microsoft Entra Domain Services managed domain.

-# Review security audit events in Microsoft Entra Domain Services using Azure Monitor Workbooks

-To help you understand the state of your Microsoft Entra Domain Services managed domain, you can enable security audit events. These security audit events can then be reviewed using Azure Monitor Workbooks that combine text, analytics queries, and parameters into rich interactive reports. Domain Services includes workbook templates for security overview and account activity that let you dig into audit events and manage your environment.

-This article shows you how to use Azure Monitor Workbooks to review security audit events in Domain Services.

-## Before you begin

-To complete this article, you need the following resources and privileges:

-* An active Azure subscription.

- * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

- * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

-* Security audit events enabled for your managed domain that stream data to a Log Analytics workspace.

- * If needed, [enable security audits for Domain Services][enable-security-audits].

-## Azure Monitor Workbooks overview

-When security audit events are turned on in Domain Services, it can be hard to analyze and identify issues in the managed domain. Azure Monitor lets you aggregate these security audit events and query the data. With Azure Monitor Workbooks, you can visualize this data to make it quicker and easier to identify issues.

-Workbook templates are curated reports that are designed for flexible reuse by multiple users and teams. When you open a workbook template, the data from your Azure Monitor environment is loaded. You can use templates without an impact on other users in your organization, and can save your own workbooks based on the template.

-Domain Services includes the following two workbook templates:

-* Security overview report

-* Account activity report

-For more information about how to edit and manage workbooks, see [Azure Monitor Workbooks overview](/azure/azure-monitor/visualize/workbooks-overview).

-## Use the security overview report workbook

-To help you better understand usage and identify potential security threats, the security overview report summarizes sign-in data and identifies accounts you might want to check on. You can view events in a particular date range, and drill down into specific sign-in events, such as bad password attempts or where the account was disabled.

-To access the workbook template for the security overview report, complete the following steps:

-1. Search for and select **Microsoft Entra Domain Services** in the Azure portal.

-1. Select your managed domain, such as *aaddscontoso.com*

-1. From the menu on the left-hand side, choose **Monitoring > Workbooks**

- 

-1. Choose the **Security Overview Report**.

-1. From the drop-down menus at the top of the workbook, select your Azure subscription and then an Azure Monitor workspace.

- Choose a **Time range**, such as *Last 7 days*, as shown in the following example screenshot:

- 

- The **Tile view** and **Chart view** options can also be changed to analyze and visualize the data as desired.

-1. To drill down into a specific event type, select the one of the **Sign-in result** cards such as *Account Locked Out*, as shown in the following example:

- 

-1. The lower part of the security overview report below the chart then breaks down the activity type selected. You can filter by usernames involved on the right-hand side, as shown in the following example report:

- [](./media/use-azure-monitor-workbooks/account-lockout-details.png#lightbox)

-## Use the account activity report workbook

-To help you troubleshoot issues for a specific user account, the account activity report breaks down detailed audit event log information. You can review when a bad username or password was provided during sign-in, and the source of the sign-in attempt.

-To access the workbook template for the account activity report, complete the following steps:

-1. Search for and select **Microsoft Entra Domain Services** in the Azure portal.

-1. Select your managed domain, such as *aaddscontoso.com*

-1. From the menu on the left-hand side, choose **Monitoring > Workbooks**

-1. Choose the **Account Activity Report**.

-1. From the drop-down menus at the top of the workbook, select your Azure subscription and then an Azure Monitor workspace.

- Choose a **Time range**, such as *Last 30 days*, then how you want the **Tile view** to represent the data.

- You can filter by **Account username**, such as *felix*, as shown in the following example report:

- [](./media/use-azure-monitor-workbooks/account-activity-report.png#lightbox)

- The area below the chart shows individual sign-in events along with information such as the activity result and source workstation. This information can help determine repeated sources of sign-in events that may cause account lockouts or indicate a potential attack.

-As with the security overview report, you can drill down into the different tiles at the top of the report to visualize and analyze the data as needed.

-## Save and edit workbooks

-The two template workbooks provided by Domain Services are a good place to start with your own data analysis. If you need to get more granular in the data queries and investigations, you can save your own workbooks and edit the queries.

-1. To save a copy of one of the workbook templates, select **Edit > Save as > Shared reports**, then provide a name and save it.

-1. From your own copy of the template, select **Edit** to enter the edit mode. You can choose the blue **Edit** button next to any part of the report and change it.

-All of the charts and tables in Azure Monitor Workbooks are generated using Kusto queries. For more information on creating your own queries, see [Azure Monitor log queries][azure-monitor-queries] and [Kusto queries tutorial][kusto-queries].

-## Next steps

-If you need to adjust password and lockout policies, see [Password and account lockout policies on managed domains][password-policy].

-For problems with users, learn how to troubleshoot [account sign-in problems][troubleshoot-sign-in] or [account lockout problems][troubleshoot-account-lockout].

-<!-- INTERNAL LINKS -->

-[create-azure-ad-tenant]: /azure/active-directory/fundamentals/sign-up-organization

-[associate-azure-ad-tenant]: /azure/active-directory/fundamentals/how-subscriptions-associated-directory

-[create-azure-ad-ds-instance]: tutorial-create-instance.md

-[enable-security-audits]: security-audit-events.md

-[password-policy]: password-policy.md

-[troubleshoot-sign-in]: troubleshoot-sign-in.md

-[troubleshoot-account-lockout]: troubleshoot-account-lockout.md

-[azure-monitor-queries]: /azure/data-explorer/kusto/query/

-[kusto-queries]: /azure/data-explorer/kusto/query/tutorials/learn-common-operators?pivots=azuredataexplorer

-To delete an enrolled security key, sign in to the [Microsoft Entra admin center](https://entra.microsoft.com), and then go to the **Security info** page.

-### Microsoft Admin Portals (preview)

-> [!IMPORTANT]

-> Microsoft Admin Portals (preview) is not currently supported in Government clouds.

-Microsoft recommends securing access to any Microsoft admin portals like Microsoft Entra, Microsoft 365, Exchange, and Azure. Using the [Microsoft Admin Portals (Preview)](concept-conditional-access-cloud-apps.md#microsoft-admin-portals-preview) app organizations can control interactive access to Microsoft admin portals.

-> [!IMPORTANT]

-> Microsoft Admin Poratls (preview) is not currently supported in Government clouds.

-1. Under **Target resources** > **Cloud apps** > **Include**, **Select apps**, select **Microsoft Admin Portals (Preview)**.

-As mentione in the blog post [IPv6 is coming to Microsoft Entra ID](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/ipv6-coming-to-azure-ad/ba-p/2967451) we now support IPv6 in Microsoft Entra services.

-Every time the user shares their GPS location, the app does jailbreak detection (Using the same logic as the Intune MAM SDK). If the device is jailbroken, the location isn't considered valid, and the user isn't granted access. The Microsoft Authenticator app on Android uses the Google Play Integrity API to facilitate jailbreak detection. If the Google Play Integrity API is unavailable, the request is denied and the user isn't be able to access the requested resource unless the Conditional Access policy is disabled.

-Organizations with access to Global Secure Access preview features have an another location listed that is made up of users and devices that comply with your organization's security policies. For more information, see the section [Enable Global Secure Access signaling for Conditional Access](../../global-secure-access/how-to-compliant-network.md#enable-global-secure-access-signaling-for-conditional-access). It can be used with Conditional Access policies to perform a compliant network check for access to resources.

-1. Open *src/app/app.module.ts* and replace the file contents with the following snippet:

- :::code language="csharp" source="~/ms-identity-docs-code-javascript/angular-spa/src/app/app.module.ts":::

- * `TenantId` - The identifier of the tenant where the application is registered. Replace the text in quotes with the **Directory (tenant) ID** that was recorded earlier from the overview page of the registered application.

- * `ClientId` - The identifier of the application, also referred to as the client. Replace the text in quotes with the **Directory (tenant) ID** value that was recorded earlier from the overview page of the registered application.

- * `RedirectUri` - The **Redirect URI** of the application. If necessary, replace the text in quotes with the redirect URI that was recorded earlier from the overview page of the registered application.

-1. Copy the https URL that appears in the terminal, for example, `https://localhost:4200`, and paste it into a browser. We recommend using a private or incognito browser session.

-1. The application will request permission to maintain access to data you have given it access to, and to sign you in and read your profile. Select **Accept**.

-1. The following screenshot appears, indicating that you have signed in to the application and have accessed your profile details from the Microsoft Graph API.

-1. Find the **Sign out** link in the top right corner of the page, and select it.

-1. A message appears indicating that you have signed out.

-1. Open *1-Authentication/1-sign-in/App/authConfig.js* and replace the file contents with the following snippet:

- :::code language="csharp" source="~/ms-identity-docs-code-javascript/js-spa/App/authConfig.js":::

- * `TenantId` - The identifier of the tenant where the application is registered. Replace the text in quotes with the **Directory (tenant) ID** that was recorded earlier from the overview page of the registered application.

- * `ClientId` - The identifier of the application, also referred to as the client. Replace the text in quotes with the **Directory (tenant) ID** value that was recorded earlier from the overview page of the registered application.

- * `RedirectUri` - The **Redirect URI** of the application. If necessary, replace the text in quotes with the redirect URI that was recorded earlier from the overview page of the registered application.

-1. The application will request permission to maintain access to data you have given it access to, and to sign you in and read your profile. Select **Accept**.

-1. The following screenshot appears, indicating that you have signed in to the application and have accessed your profile details from the Microsoft Graph API.

-1. Find the **Sign out** link in the top right corner of the page, and select it.

-1. A message appears indicating that you have signed out.

-1. Open *src/authConfig.js* and replace the file contents with the following snippet:

- :::code language="csharp" source="~/ms-identity-docs-code-javascript/react-spa/src/authConfig.js":::

- * `TenantId` - The identifier of the tenant where the application is registered. Replace the text in quotes with the **Directory (tenant) ID** that was recorded earlier from the overview page of the registered application.

- * `ClientId` - The identifier of the application, also referred to as the client. Replace the text in quotes with the **Directory (tenant) ID** value that was recorded earlier from the overview page of the registered application.

- * `RedirectUri` - The **Redirect URI** of the application. If necessary, replace the text in quotes with the redirect URI that was recorded earlier from the overview page of the registered application.

-1. Copy the https URL that appears in the terminal, for example, `https://localhost:3000`, and paste it into a browser. We recommend using a private or incognito browser session.

-1. The application will request permission to maintain access to data you have given it access to, and to sign you in and read your profile. Select **Accept**.

-1. The following screenshot appears, indicating that you have signed in to the application and have accessed your profile details from the Microsoft Graph API.

-1. Find the **Sign out** link in the top right corner of the page, and select it.

-1. A message appears indicating that you have signed out.

-Prior to August 2022, Microsoft Entra B2B (Microsoft Entra B2B) supported self-service sign-up for email-verified users. With this feature, users create Microsoft Entra accounts, when they verify email ownership. These accounts were created in unmanaged (or viral) tenants: users created accounts with an organization domain, not under IT team management. Access persists after users leave the organization.

->This information last updated on September 21st, 2023.<br/>You can also download a CSV version of this table [here](https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv).

-After creating a new customer tenant, you can customize the end-user experience. Create a custom look and feel for users signing in to your web-based apps by configuring **Company branding** settings for your tenant. With these settings, you can add your own background images, colors, company logos, and text to customize the sign-in experiences across your apps.

-## Comparing the default sign-in experiences between the customer tenant and the Microsoft Entra tenant

-The default sign-in experience is the global look and feel that applies across all sign-ins to your tenant. The default branding experiences between the customer tenant and the default Microsoft Entra tenant are distinct.

-Your Microsoft Entra tenant supports Microsoft look and feel as a default state for authentication experience. You can [customize the default Microsoft sign-in experience](/azure/active-directory/fundamentals/how-to-customize-branding) with a custom background image or color, favicon, layout, header, and footer. You can also upload a [custom CSS](/azure/active-directory/fundamentals/reference-company-branding-css-template). If the custom company branding fails to load for any reason, the sign-in page will revert to the default Microsoft branding.

-Microsoft provides a neutral branding as the default for the customer tenant, which can be customized to meet the specific needs of your company. The default branding for the customer tenant is neutral and doesn't include any existing Microsoft branding. If the custom company branding fails to load for any reason, the sign-in page will revert to this neutral branding. It's also possible to add each custom branding property to the custom sign-in page individually.

-The following list and image outline the elements of the default Microsoft sign-in experience in a Microsoft Entra tenant:

-1. Microsoft background image and color.

-2. Microsoft favicon.

-3. Microsoft banner logo.

-5. Microsoft footer hyperlinks, for example, Privacy & cookies, Terms of use and troubleshooting details also known as ellipsis in the right bottom corner of the screen.

-6. Microsoft overlay.

- :::image type="content" source="media/how-to-customize-branding-customers/microsoft-branding.png" alt-text="Screenshot of the Microsoft Entra ID default Microsoft branding." lightbox="media/how-to-customize-branding-customers/microsoft-branding.png":::

-The following image displays the neutral default branding of the customer tenant:

- :::image type="content" source="media/how-to-customize-branding-customers/ciam-neutral-branding.png" alt-text="Screenshot of the CIAM neutral branding." lightbox="media/how-to-customize-branding-customers/ciam-neutral-branding.png":::

- :::image type="content" source="media/how-to-customize-branding-customers/company-branding-self-service-password-reset.png" alt-text="Screenshot of the company branding Self-service password reset ." lightbox="media/how-to-customize-branding-customers/company-branding-self-service-password-reset.png":::

-For your customer tenant, you might have different requirements for the information you want to collect during sign-up and sign-in. The customer tenant comes with a built-in set of information stored in attributes, such as Given Name, Surname, City, and Postal Code. You can create custom attributes in your customer tenant using the Microsoft Graph API or in the portal under the **Text** tab in **Company Branding**.

-Your customer tenant name replaces the Microsoft banner logo in the neutral default sign-in experience. You can customize your tenant's name in the Properties area.

-## Clean up resources via the portal

-When no longer needed, you can remove the sign-in customization from your customer tenant via the Azure portal.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Global Administrator](/azure/active-directory/roles/permissions-reference#global-administrator).

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the customer tenant you created earlier.

-1. Browse to **Company branding** > **Default sign-in experience** > **Edit**.

-1. Remove the elements you no longer need.

-1. Once finished select **Review + save**.

-1. Wait a few minutes for the changes to take effect.

-## Clean up resources via the Microsoft Graph API

-When no longer needed, you can remove the sign-in customization from your customer tenant via the Microsoft Graph API.

-1. Sign in to the [MS Graph explorer](https://developer.microsoft.com/en-us/graph/graph-explorer) with your customer tenant account: `https://developer.microsoft.com/en-us/graph/graph-explorer?tenant=<your-tenant-name.onmicrosoft.com>`.

-1. Query the default branding object using the Microsoft Graph API beta version: `https://graph.microsoft.com/beta/organization/<your-tenant-ID>/branding/localizations`. To confirm that you're signed in to your customer tenant, verify the tenant name on the right side of the screen.

- :::image type="content" source="media/how-to-customize-branding-customers/msgraph-ciam-branding.png" alt-text="Screenshot of MS Graph API with CIAM tenant logged in." lightbox="media/how-to-customize-branding-customers/msgraph-ciam-branding.png":::

-3. [Remove default branding object](/graph/api/organizationalbrandinglocalization-delete) using the Microsoft Graph API beta version and the DELETE request.

-4. Wait a few minutes for the changes to take effect.

-5. Select the user flow that you want to enable for translations.

-6. Select **Languages**.

-7. On the **Languages** page for the user flow, select the language that you want to customize.

-8. Expand **Sign up and sign in (Preview)**.

-9. Select **Download defaults** (or **Download overrides** if you have previously edited this language).

-10. After making the necessary changes, you can upload the new overrides file. The changes are saved to your user flow automatically. The override appears under the **Configured** tab.

-11. To double-check your changes, select the language under the **Configured** tab and expand the **Sign up and sign in (Preview)** option. You can view your customized language file by selecting Download overrides. To remove your customized override file, select **Remove overrides**.

-12. Go to the sign-in page of your customer tenant. Make sure you have the right locale and market in your URLs, for example: ui_locales=de-DE and mkt=de-DE. The updated attributes on the sign-up page appear as follows:

-See the following articles on Microsoft Entra B2B collaboration:

-Currently there's a known issue where if Teams federation is off, Teams blocks a home identity authenticated session from joining externally hosted Teams meetings.

-|Externally issued identity (authenticated session)<br></br> Example: A user uses any identity other than their home identity (for example, user@externaltenant.com) | Authenticated as an externally issued identity | Allow or block access to the Teams meeting per Tenant restrictions v2 policy. If allowed by the policy, the user can join the meeting. Otherwise access is blocked. <br></br> Note: Currently there's a known issue where if Teams isn't explicitly federated with the external tenant, Teams and Tenant restrictions v2 block users using a home identity authenticated session from joining externally hosted Teams meetings.

-For more information, see: [Microsoft Admin Portals (preview)](../conditional-access/concept-conditional-access-cloud-apps.md#microsoft-admin-portals-preview).

-| General public | - `*.blob.core.windows.net` <br />- `*.aadconnecthealth.azure.com` <br />- `**.servicebus.windows.net` - Port: 5671 (If 5671 is blocked, the agent falls back to 443, but we recommend that you use port 5671. This endpoint isn't required in the latest version of the agent.)<br />- `*.adhybridhealth.azure.com/`<br />- `https://management.azure.com` <br />- `https://policykeyservice.dc.ad.msft.net/` <br />- `https://login.windows.net` <br />- `https://login.microsoftonline.com` <br />- `https://secure.aadcdn.microsoftonline-p.com` <br />- `https://www.office.com` (This endpoint is used only for discovery purposes during registration.)<br />- `https://aadcdn.msftauth.net` <br />- `https://aadcdn.msauth.net` |

-| Azure Germany | - `*.blob.core.cloudapi.de` <br />- `*.servicebus.cloudapi.de` <br />- `*.aadconnecthealth.microsoftazure.de` <br />- `https://management.microsoftazure.de` <br />- `https://policykeyservice.aadcdi.microsoftazure.de` <br />- `https://login.microsoftonline.de` <br />- `https://secure.aadcdn.microsoftonline-p.de` <br />- `https://www.office.de` (This endpoint is used only for discovery purposes during registration.)<br />- `https://aadcdn.msftauth.net` <br />- `https://aadcdn.msauth.net` |

-| Azure Government | - `*.blob.core.usgovcloudapi.net` <br />- `*.servicebus.usgovcloudapi.net` <br />- `*.aadconnecthealth.microsoftazure.us` <br />- `https://management.usgovcloudapi.net` <br />- `https://policykeyservice.aadcdi.azure.us` <br />- `https://login.microsoftonline.us` <br />- `https://secure.aadcdn.microsoftonline-p.com` <br />- `https://www.office.com` (This endpoint is used only for discovery purposes during registration.)<br />- `https://aadcdn.msftauth.net` <br />- `https://aadcdn.msauth.net` |

- "ResourceId" = "2cab1707-656d-40cc-8522-3178a184e03d"

-New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId '2cab1707-656d-40cc-8522-3178a184e03d' -BodyParameter $params |

-* Bynder supports **SP and IDP** initiated SSO

-* Bynder supports **Just In Time** user provisioning

-1. **[Configure Microsoft Entra SSO](#configure-azure-ad-sso)** - to enable your users to use this feature.

- 1. **[Create a Microsoft Entra test user](#create-an-azure-ad-test-user)** - to test Microsoft Entra single sign-on with Britta Simon.

- 1. **[Assign the Microsoft Entra test user](#assign-the-azure-ad-test-user)** - to enable Britta Simon to use Microsoft Entra single sign-on.

-2. **[Configure Bynder SSO](#configure-bynder-sso)** - to configure the Single Sign-On settings on application side.

-<a name='configure-azure-ad-sso'></a>

- 

- a. In the **Identifier** text box, type a URL using the following pattern:

- For a Default Domain:

- `https://<COMPANY_NAME>.bynder.com`

- For a Custom Domain:

- `https://<SUBDOMAIN>.<DOMAIN>.com`

- b. In the **Reply URL** text box, type a URL using the following pattern:

- For a Default Domain:

- `https://<COMPANY_NAME>.bynder.com/sso/SAML/authenticate/`

- For a Custom Domain:

- `https://<SUBDOMAIN>.<DOMAIN>.com/sso/SAML/authenticate/`

- In the **Sign-on URL** text box, type a URL using the following pattern:

- For a Default Domain:

- `https://<COMPANY_NAME>.bynder.com/login/`

- For a Custom Domain:

- ` https://<SUBDOMAIN>.<DOMAIN>.com/login/`

- > [!NOTE]

- > These values are not real. Update these values with the actual Identifier, Reply URL and Sign-on URL. Contact [Bynder Client support team](https://www.bynder.com/en/support/) to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section.

- 

- 

-To configure single sign-on on **Bynder** side, you need to send the downloaded **Metadata XML** and appropriate copied URLs from the application configuration to [Bynder support team](https://www.bynder.com/en/support/). They set this setting to have the SAML SSO connection set properly on both sides.

-You can also use Microsoft My Apps to test the application in any mode. When you click the Bynder tile in the My Apps, if configured in SP mode you would be redirected to the application sign on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the Bynder for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).

-1. Under the **Admin Credentials** section, input your M-Files Tenant URL and Secret Token. Click **Test Connection** to ensure Microsoft Entra ID can connect to M-Files. If the connection fails, ensure your M-Files account has Admin permissions and try again.

- 

- 

- 

- 

- 

- 

- 

- 

- 

-

-

-If you need to recover a deleted resource, see [Recover deleted Azure AI services resources](manage-resources.md).

-* See **[Use Azure AI services as containers](cognitive-services-container-support.md)** to understand how to use Azure AI services on-prem.

-If you need to recover a deleted resource, see [Recover deleted Azure AI services resources](manage-resources.md).

-> [Recover deleted Azure AI services resources](manage-resources.md)

-| Named Entity Recognition (NER) | `2021-06-01`, `2022-10-01-preview`, `2023-02-01-preview**`, `2023-04-15*`|

-| Personally Identifiable Information (PII) detection | `2021-01-15`, `2023-01-01-preview**`, `2023-04-15*` |

-| PII detection for conversations (Preview) | `2022-05-15-preview**`, `2023-04-15*` |

-To set the input speech recognition language, specify the full locale with a dash (`-`) separator. See the [speech to text language table](?tabs=stt#supported-languages). The default language is `en-US` if you don't specify a language.

-> To avoid performance issue, use persistent volume instead of inline volume when numerous pods are accessing the same file share.

-> Inline volume can only access secrets in the same namespace as the pod. To specify a different secret namespace, instead use the [persistent volume example][persistent-volume-example].

-[persistent-volume-example]: #mount-file-share-as-a-persistent-volume

-## Register customer-managed key (preview) feature

-To enable customer-managed key for ephemeral OS disk (preview) feature, you must register *EnableBYOKOnEphemeralOSDiskPreview* feature flag on *Microsoft.ContainerService* over the subscription. To perform the registration, run the following commands.

-1. Install the *aks-preview* extension:

- ```azurecli-interactive

- az extension add --name aks-preview

- ```

-1. Update to the latest version of the extension released:

- ```azurecli-interactive

- az extension update --name aks-preview

- ```

-1. Register the *EnableBYOKOnEphemeralOSDiskPreview* feature flag:

- ```azurecli-interactive

- az feature register --namespace "Microsoft.ContainerService" --name "EnableBYOKOnEphemeralOSDiskPreview"

- ```

- It takes a few minutes for the status to show *Registered*.

-1. Verify the registration status:

- ```azurecli-interactive

- az feature show --namespace "Microsoft.ContainerService" --name "EnableBYOKOnEphemeralOSDiskPreview"

- ```

-1. When the status shows *Registered*, refresh the `Microsoft.ContainerService` resource provider registration:

- ```azurecli-interactive

- az provider register --namespace Microsoft.ContainerService

- ```

-<!-- LINKS - external -->

-<!-- LINKS - internal -->

-[cis-benchmark-azure-linux]: https://www.cisecurity.org/benchmark/azure_linux

-As a secure service, Azure Kubernetes Service (AKS) complies with SOC, ISO, PCI DSS, and HIPAA standards. This article covers the security hardening applied to AKS based on the CIS Kubernetes benchmark. For more information about AKS security, see [Security concepts for applications and clusters in Azure Kubernetes Service (AKS)](./concepts-security.md). For more information on the CIS benchmark, see [Center for Internet Security (CIS) Benchmarks][cis-benchmarks].

-[azure-update-management]: ../automation/update-management/overview.md

-[azure-file-integrity-monotoring]: ../security-center/security-center-file-integrity-monitoring.md

-[azure-time-sync]: ../virtual-machines/linux/time-sync.md

-[auzre-log-analytics-agent-overview]: ../azure-monitor/platform/log-analytics-agent.md

-[cis-benchmarks]: /compliance/regulatory/offering-CIS-Benchmark

-description: Learn how AKS applies the CIS benchmark

-As a secure service, Azure Kubernetes Service (AKS) complies with SOC, ISO, PCI DSS, and HIPAA standards. This article covers the security OS configuration applied to Ubuntu imaged used by AKS. This security configuration is based on the Azure Linux security baseline, which aligns with CIS benchmark. For more information about AKS security, see Security concepts for applications and clusters in Azure Kubernetes Service (AKS). For more information about AKS security, see [Security concepts for applications and clusters in Azure Kubernetes Service (AKS)](./concepts-security.md). For more information on the CIS benchmark, see [Center for Internet Security (CIS) Benchmarks][cis-benchmarks]. For more information on the Azure security baselines for Linux, see [Linux security baseline][linux-security-baseline].

-||||||

-| 1 | Initial Setup |||

-| 1.1 | Filesystem Configuration |||

-| 1.1.1 | Disable unused filesystems |||

-| 1.1.3 | Ensure nodev option set on /tmp partition | Fail | |

-| 1.2 | Configure Software Updates |||

-| 1.3 | Filesystem Integrity Checking |||

-| 1.4 | Secure Boot Settings |||

-| 1.6 | Mandatory Access Control |||

-| 1.6.1 | Configure AppArmor |||

-| 1.8 | GNOME Display Manager |||

-| 2 | Services |||

-| 2.1 | Special Purpose Services |||

-| 2.1.1 | Time Synchronization |||

-| 3 | Network Configuration |||

-| 3.5.3.1 | Configure iptables software |||

-| 4.2.1.6 | Ensure remote rsyslog messages are only accepted on designated log hosts. | Not Applicable | |

-| 4.2.2.2 | Ensure journald is configured to compress large log files | Fail | |

-| 4.2.2.3 | Ensure journald is configured to write logfiles to persistent disk | Pass | |

-| 4.2.3 | Ensure permissions on all logfiles are configured | Fail | |

-| 4.4 | Ensure logrotate assigns appropriate permissions | Fail | |

-| 5 | Access, Authentication, and Authorization |||

-| 5.1.8 | Ensure cron is restricted to authorized users | Fail | |

-| 5.1.9 | Ensure at is restricted to authorized users | Fail | |

-| 5.2.3 | Ensure sudo log file exists | Fail | |

-| 5.3.16 | Ensure SSH Idle Timeout Interval is configured | Fail | |

-| 5.3.21 | Ensure SSH MaxStartups is configured | Fail | |

-| 5.4.2 | Ensure lockout for failed password attempts is configured | Fail | |

-| 5.4.3 | Ensure password reuse is limited | Fail | |

-| 6.1.13 | Audit SUID executables | Not Applicable | |

-| 6.1.14 | Audit SGID executables | Not Applicable | |

-[azure-update-management]: ../automation/update-management/overview.md

-[azure-file-integrity-monotoring]: ../security-center/security-center-file-integrity-monitoring.md

-[azure-time-sync]: ../virtual-machines/linux/time-sync.md

-[auzre-log-analytics-agent-overview]: ../azure-monitor/platform/log-analytics-agent.md

-[cis-benchmark-aks]: https://www.cisecurity.org/benchmark/kubernetes/

-[cis-benchmark-ubuntu]: https://www.cisecurity.org/benchmark/ubuntu/

-* If your API Management instance is deployed in a virtual network, ensure that you set up a virtual network, subnet, and public IP address in the location that you plan to add. See [virtual network prerequisites](api-management-using-with-vnet.md#prerequisites).

-Migration requires a three to six hour service window for App Service Environment v2 to v3 migrations. Up to a six hour service window is required depending on environment size for v1 to v3 migrations. During migration, scaling and environment configurations are blocked and the following events occur:

-![Screenshot that shows IP addresses.][3]

-When the inbound and outbound requirements are taken into account, the NSGs should look similar to the NSGs shown in the following screenshot:

-![Screenshot that shows inbound security rules.][4]

-If you put a *deny everything else* rule before the default rules, you prevent traffic between the VIP and the App Service Environment. To prevent traffic coming from inside the virtual network, add your own rule to allow inbound. Use a source equal to `AzureLoadBalancer`, with a destination of **Any** and a port range of **\***. Because the NSG rule is applied to the subnet, you don't need to be specific in the destination.

-All the items shown in the following outbound rules are needed, except for the rule named **ASE-internal-outbound**. They enable network access to the App Service Environment dependencies that were noted earlier in this article. If you block any of them, your App Service Environment stops working. The rule named **ASE-internal-outbound** in the list enables your App Service Environment to communicate with other resources in your virtual network.

-![Screenshot that shows outbound security rules.][5]

-> [!NOTE]

-> The IP range in the ASE-internal-outbound rule is only an example and should be changed to match the subnet range for the App Service Environment subnet.

-[3]: ./media/network_considerations_with_an_app_service_environment/networkase-ipaddresses.png

-By default, when you write to the output parameter in your function, a document is created in your database. This document has an automatically generated GUID as the document ID. You can specify the document ID of the output document by specifying the `id` property in the JSON object passed to the output parameter.

- showBuildingModels: false,

- showBuildingModels: true,