Create and Configure Microsoft Azure AD Domain Services

The first step for deploying DigitalPersona product on Microsoft Azure AD is to create and configure Azure AD Domain Services (Azure AD DS).

For further information about Microsoft Azure AD DS, see https://docs.microsoft.com/en-us/azure/active-directory-domain-services/overview and https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-instance

Create Domain Services

1. Log on to the Microsoft Azure portal.

2. Launch the Enable Azure AD Domain Services wizard from the Azure portal menu (or from the Home page) by selecting Create a resource.

3. Enter Domain Services into the search bar, then choose Azure AD Domain Services from the search suggestions.

   

   After clicking Azure AD Domain Services the following page is displayed.

   

4. On the Azure AD Domain Services page, select Create.

   The Enable Azure AD Domain Services wizard is launched.

   

5. Select the Azure Subscription in which you would like to create the managed domain.

6. Select the Resource group to which the managed domain should belong. Choose to Create new or select an existing resource group.

7. Enter a DNS domain name for your managed domain.

   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 (an .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.

   It is also strongly recommend using custom domain names here. 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.

     

8. Choose the Azure Location in which the managed domain should be created. If you choose a region that supports Availability Zones, the Azure AD DS 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 Azure AD DS 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?

   

9. The SKU determines the performance, backup frequency, and maximum number of forest trusts you can create. You can change the SKU after the managed domain has been created according to your business demands or if requirements change. For more information, see Azure AD DS SKU concepts.

   For DigitalPersona deployment, a Standard SKU. For larger enterprises (25K users or more) we would suggest using the Enterprise SKU.

   

10. A forest is a logical construct used by Active Directory Domain Services to group one or more domains. By default, a managed domain is created as a User forest. This type of forest synchronizes all objects from Azure AD, including any user accounts created in an on-premises AD DS environment. A Resource forest only synchronizes users and groups created directly in Azure AD. Resource forests are currently in preview.

    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 Azure AD DS resource forests overview.

    It is recommended using the User forest for DigitalPersona deployment.

    Here is the final view of the Basics configuration.

    

11. Click Next to display the Networking tab.

    

12. 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 Azure AD into the managed domain.

Select Review + create to accept these default configuration options.

Deploy Azure AD DS

On the Summary page of the wizard, review the configuration settings for the managed domain. You can go back to any step of the wizard to make changes.

To redeploy a managed domain to a different Azure AD 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 Azure AD DS managed domain has been created. To continue, select OK.

2. 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 Azure AD DS deployment.

   Select the notification to see detailed progress for the deployment.

   

   Deployment of Azure AD DS may take several hours.

3. Once deployment is complete the Overview tab displays Your deployment is complete.

   

   When the managed domain is fully provisioned, the Overview tab shows the domain status as Running.

   

Configure Azure AD DS

With Azure AD DS 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 Azure AD DS is deployed.

The Overview tab for your managed domain shows some Required configuration steps.

The addresses listed are the domain controllers for use in the virtual network. In this example, those addresses are 10.0.0.5 and 10.0.0.4. You can later find these IP addresses on the Properties tab.

To update the DNS server settings for the virtual network, select Configure.

The DNS settings are automatically configured for your virtual network.

Once the DNS settings are correctly configured, this step is no longer shown.

Enable User Accounts for Azure AD DS

To authenticate users on the managed domain, Azure AD DS needs password hashes in a format that's suitable for NT LAN Manager (NTLM) and Kerberos authentication. Azure AD doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Azure AD DS for your tenant.

For security reasons, Azure AD also doesn't store any password credentials in clear-text form. Therefore, Azure AD can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials.

The steps to generate and store these password hashes are different for cloud-only user accounts created in Azure AD versus user accounts that are synchronized from your on-premises directory using Azure AD Connect.

A cloud-only user account is an account that was created in your Azure AD directory using either the Azure portal or Azure AD PowerShell cmdlets. These user accounts aren't synchronized from an on-premises directory. In this document, let's work with a basic cloud-only user account.

For more information on the additional steps required to use Azure AD Connect, see Synchronize password hashes for user accounts synced from your on-premises AD to your managed domain.

For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed. Either expire the passwords for all cloud users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct cloud users to manually change their passwords.

For this tutorial, we will manually change a user password.

Before a user can reset their password, the Azure AD tenant must be configured for self-service password reset.

To change the password for a cloud-only user, the user must complete the following steps:

1. Go to the Azure AD Access Panel page at https://myapps.microsoft.com.

2. In the top-right corner, select your name, then choose View account from the drop-down menu.

3. On the Profile page, select Change password.

   

   

4. On the Change password page, enter your existing (old) password, then enter and confirm a new password.

5. Select Submit.

It takes a few minutes after you've changed your password for the new password to be usable in Azure AD DS and to successfully sign in to computers joined to the managed domain.