2
Implementing and Managing Azure Active Directory Domain Services
This chapter covers the AZ-800 Administering Windows Server Hybrid Core Infrastructure exam learning objective: Deploy and manage AD DS in on-premises and cloud environments.
In the previous chapter, we added skills to understand AD DS’s concepts, creation, and management in on-premises environments.
We will start this chapter with some concepts and an understanding of Azure AD and then how it compares to Active Directory. We will then look at creating and managing an Azure AD DS managed domain. We will then conclude with a hands-on exercise to develop your skills further.
The following topics will be covered in this chapter:
- What is Azure AD?
- What is Azure AD DS?
- Creating an Azure AD DS managed domain
- Managing an Azure AD DS managed domain
- Exercise – Installing Azure AD DS
Before we dive into any service creation or management, we will look at some definitions and concepts to set a baseline and foundation of knowledge to build upon. We start this chapter by defining Azure AD.
What is Azure AD?
When is AD not AD? When it is Azure AD!
We will take a brief moment to introduce the tale of two directories.
Azure AD is often shrouded in the misconception that it is purely the cloud equivalent of the traditional Windows Server-based AD; in some respects, it’s quite close. In others, it’s not, so it is essential to understand that this is not the case, and we should not think of this as AD in the cloud, as it were; if only it were that simple.
While both AD and Azure AD are identity providers (IDPs) and share AD in the name, they function very differently.
At the moment, at least at the time of publishing, Azure AD cannot fully replace the functionality and capabilities of traditional Windows Server AD implementations. However, this may not be a bad thing, and the solution you need may not require the full functionality and capabilities of what we can refer to as traditional AD.
Microsoft provides Azure AD as a fully managed IDP platform, provided as software as a service (SaaS).
AD can be connected to Azure AD using Azure AD Connect, a free download tool to allow an organization to establish a hybrid identity. This tool synchronizes user identities, attributes, and objects between both IDPs.
Unlike AD, there is nothing to install for Azure AD, and no DCs are required while still allowing devices, users, and groups to appear as objects in the directory.
Some of the most common services offered by AD and Azure AD are shown in the following figure:
A hybrid identity approach allows users to access resources in Azure AD using their AD identity; the same username and password are used to access resources accessed in both IDP environments. Further reading can be found at this URL if you wish to continue learning more about hybrid identities and Azure AD Connect: https://docs.microsoft.com/azure/active-directory/hybrid/whatis-azure-ad-connect.
What is Azure AD DS?
Azure AD DS is a managed Azure identity service provided as a Platform as a Service (PaaS); in simple terms, it provides Domain Services as a service.
When you implement Azure AD DS as part of an Azure AD tenant, you create a Microsoft managed domain, which is a managed implementation of AD DS. This provides the functions of Kerberos/NTLM authentication, lightweight directory access protocol (LDAP), domain join, and group policy.
The use case for Azure AD DS is where workloads running in Azure depend on Domain Services functions and where apps or services cannot be modified or rewritten to utilize Azure AD and modern authentication, such as OAuth, SAML, and REST.
The following diagram outlines the question of how to provide the same on-premises domain functions for workloads once moved into Azure without having to provide an instance of AD DS that you manage:
Figure 2.2 – Azure AD DS use case scenario
An Azure AD DS managed domain could be a solution for scenarios such as Azure Virtual Desktop (AVD), where you may have cloud-only identities but still depend on Domain Services not yet supported by Azure AD. This allows you to utilize the PaaS capabilities of Azure AD DS rather than self-managed DCs. Combined with Microsoft 365, this approach can provide a tightly integrated solution.
The advantage of providing AD DS DCs as a PaaS service includes not considering the physical infrastructure or logical components, such as data store, schema, trusts, and partitions, and AD DS’s availability and protection.
The managed domain instance is created by Microsoft with two DCs for high availability, with additional region redundancy across two availability zones if available in that region. Microsoft will automatically configure the distribution of DCs across the zones.
The following are some characteristics of a managed domain:
- Microsoft-managed, not self-managed.
- A standalone domain–no possibility of extension or joining the managed domain to an existing AD DS forest.
- The trusts are one-way outbound forest trusts only.
- No domain or enterprise administrator privileges.
- Supports domain join, LDAP, and Kerberos/NTLM.
- Two built-in OU containers for computers and users are provided, with an associated built-in Group Policy Object (GPO).
- Supports custom OU structure and group policy via a flat structure.
- No schema extensions.
- DCs are provided as a service and managed by Microsoft.
- Azure AD DS is integrated into the Azure AD tenant for cloud-only identity scenarios and can be combined with AD DS for hybrid identity scenarios.
- Azure AD DS can be managed similarly to AD DS through the RSAT tools.
- Object sync is one-way, from Azure AD to Azure AD DS; any changes made directly to Azure AD DS will be overwritten at the next sync. These should be considered read-only DCs with no direct creation or changes to objects with DCs.
- Passwords cannot be reset in the managed domain; they must be reset in AD/Azure AD and synchronized into the managed domain.
You can review the complete list of differences between Azure AD DS and AD DS in the links provided in the Further reading section at the end of this chapter.
In the cloud-only identity scenario, users, passwords, and groups are created and managed in the Azure AD tenant, which is the authoritative directory service and IDP; these objects are synced to the Azure AD DS managed domain.
There are no direct changes to objects in the managed domain. Any changes should be made in the authoritative IDP, which is Azure AD in this scenario, and those changes must then be synchronized to the managed domain to become effective.
This is done in Azure AD if a user’s password needs to be reset. This change is then synchronized to the managed domain DCs; enabling self-service password reset (SSPR) in the AD tenant is recommended.
The following figure shows the relationship between Azure AD and the Azure AD DS managed domain in the cloud-only identity scenario:
Figure 2.3 – Azure AD cloud-only identity scenario
If a user’s password needs to be reset, this is reset in Azure AD. This change is then synchronized to the managed domain DCs; enabling SSPR in the AD tenant is recommended.
The following figure shows the relationship between AD, Azure AD, and the Azure AD DS managed domain in the hybrid identity scenario:
Figure 2.4 – Azure AD hybrid identity scenario
In the hybrid identity scenario, users, passwords, and groups are created and managed in the AD forest, which is the authoritative directory service and IDP.
These objects are then synchronized two-way into the Azure AD tenant using AD Connect, and then the objects are synchronized one-way to the Azure AD DS managed domain. There are no direct changes to objects to be made in the managed domain; any changes should be made in the authoritative IDP, which in this case is the AD forest. These changes must then be synchronized to the Azure AD tenant using AD Connect and then synchronized from the Azure AD tenant to the managed domain to become effective.
In summary, no changes will be made in the Azure AD DS managed domain in the previous cloud-only and hybrid identities scenarios. All objects are synchronized from the Azure AD tenant, so the only query is how the objects get created in Azure AD in the first instance. This will be done by creating objects directly in the Azure AD tenant in the case of cloud-only accounts or by allowing these objects to be created in the Azure AD tenant from the AD Connect sync from the AD domain controllers.
This section concludes the first of this chapter’s three skills areas: What is Azure AD DS? We have looked at how it provides managed domain services. In the next section, we will look at the second of this chapter’s three skills areas: Creating Azure AD DS.
Creating an Azure AD DS managed domain
This section will cover some planning aspects and information needed for creating Azure AD DS managed domains, and we will finish this chapter with a hands-on exercise section.
The installation of Azure AD DS is carried out in the Azure portal and requires an Azure AD tenant and an Azure subscription. The objects can be cloud-only or synchronized from AD for a hybrid identity scenario.
Two enterprise applications are created in the Azure AD tenant to support the operation of the domain; these should not be removed or edited and consist of the following:
- Domain Controller Services
- Azure AD Domain Controller Service
The managed domain instance is created by Microsoft, which will automatically configure the distribution of the managed DCs across the zones.
The following section will examine the planning aspects required before creating an Azure AD DS managed domain.
Azure AD tenant and subscription
To create Azure resources, you will need an Azure subscription. This will act as a logical container, access control, and billing mechanism for the resources created and consumed. You must associate an Azure AD tenant with this subscription; this tenant can be synchronized with AD for a hybrid identity scenario or a cloud-only identity approach.
The Azure AD tenant can only have one Azure AD DS managed domain. Ensure you plan adequately first, as once you have created the managed domain; you cannot change any of the following fields: tenant, subscription, region, resource group, VNet, or subnet.
Privileges to create an Azure AD DS managed domain
You should ensure you have the following privileges for an account you wish to use to create Azure AD DS managed domains:
An account with Owner or Contributor rights at the subscription level or an account with Domain Services Contributor, Groups Administrator, and Application Administrator Azure AD roles.
Network and DNS
The default virtual network (VNet) created through the deployment wizard for Azure AD DS uses a dedicated Azure AD DS subnet named aadds-vnet. A single subnet is only created within the VNet named aadds-subnet. This subnet should not be used for anything other than the managed domain resources; do not add any workloads to this subnet.
VMs or resources you create should be in their own workload subnet in the aadds-vnet; alternatively, you can create another workload VNet and connect it to the Azure AD DS VNet using VNet peering.
The following figure outlines both approaches to the network topology:
Figure 2.5 – Azure AD DS network topology
When Azure AD DS is created, you will be given two IP addresses, the Microsoft-managed DCs; these act as the DNS servers for the managed domain.
You must configure the DNS on the peered VNets to allow resources to talk to the Azure AD DS VNet. This can be done using the IP address of the managed domain DCs or existing DNS servers configured in the peered VNets. DNS should be configured to direct queries to the managed domain by allowing conditional DNS forwarding.
Domain name
You must specify a DNS name for the domain name of the managed domain. It is essential to ensure that you choose the correct DNS domain name, as once created, you cannot change it without deleting the managed domain and recreating it.
Note
You should plan the domain names to avoid conflict with any existing DNS namespace or planned namespace.
The prefix for the managed domain cannot be longer than 15 characters; this is because that is the maximum supported for the NetBIOS hostname.
For the suffix, you should not use a domain name with a non-routable suffix, such as .local; this can cause DNS-related issues. Instead, you can use the default built-in domain name for the tenant directory; this will use the .onmicrosoft.com suffix. The problem with this approach is that the Certificate Authority (CA) won’t issue you a certificate, so you cannot secure this domain, as Microsoft owns that domain.
To address this, you can use a routable custom domain that you own and have registered in DNS, where you have access to create and edit the DNS records and generate a certificate if needed. It is recommended to keep this separate from any existing domain name in the organization for a custom domain name. It must not conflict with any current namespace in a VNet or connected via a VPN or ExpressRoute to on-premises.
In the case of the existing domain name, milesbetter.solutions, a recommended naming approach could be to use a subdomain, aadds.milesbetter.solutions, to avoid conflict with the existing root namespace.
Location
You should deploy the Azure AD DS managed domain in the same region where the implemented workloads need to use the managed domain. An Azure availability zone can be selected for additional redundancy in that region if available.
You should ensure to deploy to the correct region, as once created, you cannot change without deleting and recreating.
SKU
The purpose of the SKU is to choose the performance and backup frequency of the managed domain. All SKUs provide the same unlimited object count, although a suggested object count is given as a guideline.
The SKUs at the time of publishing are as follows:
- Standard:
- Suggested auth load (peak, per hour): 0 to 3,000
- Suggested object count: 0 to 25,000
- Backup frequency: every 5 days
- User forest only
- Enterprise:
- Suggested auth load (peak, per hour): 3,000 to 10,000
- Suggested object count: 25,000 to 100,000
- Backup frequency: every 3 days
- User forest and resource forest
- Five resource forest trusts
- Premium:
- Suggested auth load (peak, per hour): 10,000 to 70,000
- Suggested object count: 100,000 to 500,000
- Backup frequency: every 5 days
- User forest and resource forest
- Ten resource forest trusts
You can change between SKUs after they are created without deleting and recreating the managed domain.
Forest type
The default forest type created is the user forest; this synchronizes objects from Azure AD into the managed domain. These objects can also be those created and synchronized from AD DS forests. A resource forest synchronizes only users and groups created in Azure AD.
This section concludes the second of this chapter’s three skills areas: Creating Azure AD DS. We looked at planning and deployment information. In the next section, we will look at the last of this chapter’s three skills areas: Managing Azure AD DS.
Managing an Azure AD DS managed domain
This section will cover information for managing an Azure AD DS managed domain instance.
As this is a Microsoft-managed service, there is a limit on what administrative tasks can be carried out. You don’t have access to some administrative capabilities in the managed domain; we will cover these areas in this section. We will finish this chapter with a hands-on exercise section.
Management tools
The same set of management tools used for managing AD DS can be used for managing an instance of Azure AD DS, such as Active Directory Administrative Center (ADAC), Active Directory Users and Computers snap-in, and AD PowerShell. AAD DC Administrators group members can use these tools to administer managed domains.
As these are Microsoft-managed DCs, these are locked down, and there is no direct access to the DCs for the managed domain, such as by Remote Desktop Protocol (RDP). All administrative tasks are intended to be run remotely from a domain-joined management machine on the network.
These remote management tools can be installed on a domain-joined VM (server or client) as a management machine using the Remote Server Administration Tools (RSAT) feature.
Managing Azure AD DS administrative privileges
The managed domain will not provide access to the Domain Administrator or Enterprise Administrator permissions. Instead, when Azure AD DS is created, an administrative group for managing the managed domain is created, and this group is named Azure AD DC Administrators.
User accounts that are members of this group are granted admin permissions on domain-joined VMs; this group is added to the local administrator’s group. This group also provides remote desktop rights to connect to a domain-joined VM.
You should add users from the Azure AD directory that you wish to be a member of this group.
The following are the administrative tasks that you can carry out in the managed domain:
- Join computers in the managed domain
- Manage the built-in GPO for the containers AADDC Computers and AADDC Users
- Create and manage custom OUs and GPOs
- Manage DNS
The following are the capabilities that you cannot carry out on the managed domain:
- Connect to DCs via remote desktop
- Add DCs to the managed domain
- Extend an existing AD DS forest to Azure AD DS; the managed domain is a standalone forest instance
- No domain administrator or enterprise administrator privileges
- Extend the schema
The previous points should be carefully considered to aid in the decision process of whether Azure AD is the most appropriate identity solution for your needs.
Configuring VNets to use the managed domain
By default, the managed domain VNet only contains one subnet. This is only for the use of the managed domain service, and you should not add any other resources or VMs into this subnet. If you wish to create resources or VMs within the managed domain VNet, you should create additional subnets for these.
However, you may use an existing VNet or create a new VNet and use network segmentation to separate off the managed domain VNet; this recommended approach will vary based on your needs.
To allow resources in other VNets to use the managed domain, the first step is to ensure that those VNets have connectivity to the managed domain VNet (through VNet peering). The DNS server settings for the VNet should be updated to reflect those that can perform lookups against managed domain DCs.
VMs may be required to be restarted to receive new DNS settings; you can run an ipconfig /all CLI command on the VM to check what DNS settings are being used before and after the restart.
Managing user accounts
User accounts are not created directly in the managed domain; they are synchronized from Azure AD.
Azure AD DS requires password hashes to be in the format required by NTLM or Kerberos, and Azure AD doesn’t provide this format until after the managed domain is enabled on the tenant. Existing users won’t be able to authenticate to the managed domain immediately; their password hashes will not have been synchronized to Azure AD DS in the format it uses. Therefore, we need to generate usable password hashes in Azure AD so they can be synchronized to the Azure AD DS managed domain.
The user’s password must be changed for this generation of the new password hash to occur; this can be forced so that a user must change it at the next sign-in, or they can change it manually. This change causes the password to be recreated in the correct format for Azure AD DS support and correct Kerberos and NTLM authentication.
Once this password is changed, Azure AD stores this new password hash, and the account will be synchronized to the managed domain. Users can now successfully sign in to the managed domain with their Azure AD account credentials.
It should be noted that Azure AD Connect Cloud Sync is not supported with Azure AD DS; AD users need to be synchronized using Azure AD Connect.
This password hash regeneration scenario does not occur for accounts created after the managed domain is created in the tenant; for these accounts, Azure AD will create password hashes in the correct format that Azure AD DS requires.
SSPR must be implemented in the Azure AD tenant to allow users to reset their passwords.
There is a default password policy in the managed domain, where complexity, age, and lockout are defined; custom password policies can be created to override this.
Managing OUs
There are two built-in Organizational Units (OUs) created for the managed domain; these are as follows:
- AADDC Users: This is the default location for all user and group objects synchronized into the managed domain from the Azure AD tenant. Includes users and groups synchronized in from the Azure AD tenant.
- AADDC Computers: This is the default location for all computer objects joined to the managed domain.
In a hybrid identity scenario where user accounts and groups are synchronized from AD DS, the OU objects are not synchronized because the managed domain only supports a flat OU structure. Creating custom OUs and associated GPOs to meet your needs is recommended.
Managing VM domain join
Azure AD DS provides managed domain services so that you can provide VM join capabilities without the need for self-managing IaaS VM DCs. You can authenticate to this managed domain using your Azure AD credentials. User accounts can be cloud-only or synchronized from AD into Azure AD via Azure AD Connect.
This gives us a common identity that can be used across AD DS, Azure AD, and Azure AD DS. With user account password hashes synchronized from AD into the managed domain via Azure AD, this gives us a lot of choice as to what is then possible.
The account to join the computer to the domain must be synchronized to the managed domain or from the Azure AD tenant; external directory accounts cannot be used.
If the VM cannot join the managed domain, it is often because of three common causes:
- Connectivity issues: Ensure you can reach the managed domain DC’s IP addresses; you may need to check that the VNets are peered if you have workloads in a different VNet to the VNet where Azure AD was created. Ensure that there is no network security filtering traffic for the managed domain.
- DNS issues: Ensure the VM has the correct DNS servers listed to look up the managed domain; check that the IPs of the managed domain DCs have been set as the DNS servers to use for the VNet where the VM is attempting to do the Domain join.
- Credentials: Make sure the account used belongs to the Azure AD tenant or has successfully synchronized to the managed domain and that the password hashes are the correct format for Azure AD DS. We learned earlier in this section that the correct password hash may not have been synchronized into the managed domain and that a password reset will generate the correct password hash format; you should wait for this to be synchronized to the managed domain.
It is recommended that the account credentials are in the UPN suffix format; for example, for a domainjoin user, you would use a [email protected] UPN suffix. Alternatively, the SAMAccountName format can be used; for example, for a domainjoin user, you would use an AADDSdomainjoin SAMAccountName format.
In this section, we looked at managing Azure AD DS. In the next section, we will complete a hands-on exercise to reinforce some of the concepts covered in this chapter.
Hands-on exercise
To support your learning with some practical skills, we will learn how to create Azure AD DS, which we looked at in this chapter.
We will look at the following exercise:
- Exercise – Installing Azure AD DS
Getting started
To get started with this hands-on exercise section, if you do not already have an Azure subscription, you can create a free Azure account at https://Azure.microsoft.com/free. This free Azure account provides the following:
- 12 months of free services
- $200 credit to explore Azure for 30 days
- 25+ services that are always free
Let’s move on to the exercise for this chapter.
Exercise – Installing Azure AD DS
In this section, we will learn how to install Azure AD DS. The steps in the exercise will be carried out in the Azure portal: https://portal.Azure.com/.
Follow these steps to create an Azure AD DS instance:
- Log in to the Azure portal at https://portal.Azure.com. Alternatively, you can use the Azure desktop app: https://portal.Azure.com/App/Download.
- Type Azure AD Domain Services in the search bar and click on the Azure AD Domain Services blade from the list of services shown.
Figure 2.6 – Search for the service in the Azure portal
- On the Azure AD Domain Services blade, click the + Create resource. It should be at the top left of the blade.
Figure 2.7 – Azure AD Domain Services blade
- For reference purposes, review the information provided about the functionality of Azure AD Domain Services and the information in the Project details section.
Figure 2.8 – Review creation information
- Review the information from the Help me choose the subscription and resource group helper link; then select Subscription and Resource group or create a new Resource group as required.
Figure 2.9 – Choose subscription and resource group
- Review the information from the Help me choose the DNS name helper link; then enter a domain name. For this exercise, we will modify the default to use a subdomain to avoid conflict with the default namespace; you should set it as required for your scenario.
Figure 2.10 – Choose DNS domain name
- Set Region.
Figure 2.11 – Choose the region
Figure 2.12 – Choose SKU
- Review the information from the Help me choose a forest type helper link; then set Forest type.
Figure 2.13 – Setting Forest type
- Click Next.
- On the Networking tab, review the reference information about using an existing network.
Figure 2.14 – Review network information
- Review the information from the Help me choose the virtual network and address helper link; then set Virtual network or click Create new as required.
Figure 2.15 – Choose a virtual network
Figure 2.16 – Choose the subnet
- Click Next.
- On the Administration tab, review the information from the Help me choose AAD DC Admins helper link; complete the AAD DC Administrators group membership as required, or skip and manage later.
Figure 2.17 – Choose admin group membership
- Review the information from the Help me choose who gets notifications helper link; set as required.
Figure 2.18 – Choose notifications
- Click Next.
- Review the Synchronization tab’s reference information about synchronization and scoped synchronization.
Figure 2.19 – Review synchronization information
- Review the information from the Help me choose the synchronization type helper link; set it as All or Scoped as required.
Figure 2.20 – Choose synchronization
- Click Next.
- On the Security Settings tab, review the information from the three helper links, then leave the set defaults or change as required.
Figure 2.21 – Choose security settings
- Click Next.
- On the Tags tab, leave the set defaults or change as required. Then, click Next: Review + create.
Figure 2.22 – Add tags
- On the Review + create tab, review your settings; you may go back to the previous tabs and make any edits if required. Once you have confirmed your settings, click Create.
Figure 2.23 – Review creation options
- You will see a pop-up screen asking you to acknowledge your choices, as these cannot be changed after the managed domain has been created. Review this information, click OK to continue, or go back and review the change as required.
Figure 2.24 – Review final choices
- You will now see a Deployment is in progress screen; this will take approximately an hour to complete.
Figure 2.25 – Deployment progress
- You will see a Your deployment is complete message and will receive a Deployment succeeded notification.
Figure 2.26 – Deployment completion
- Click Go to resource or navigate to the Azure AD Domain Services blade; the created Azure AD Domain Services instance can be seen.
Figure 2.27 – Azure AD Domain Services blade
- From the Overview page, review the information in the Required configuration steps section to complete the configuration.
Figure 2.28 – Final configuration steps
With this, we have finished the creation of AD DS.
In this exercise, we looked at creating an Azure AD Domain Services instance.
Summary
This chapter has provided coverage for the AZ-800 Administering Windows Server Hybrid Core Infrastructure exam learning objective: Deploy and manage AD DS in on-premises and cloud environments.
We learned about the concepts of Azure AD and how it compares with AD. We looked at creating and managing an Azure AD DS managed domain. A hands-on exercise then finished the chapter to provide you with additional practical skills.
This chapter aimed to take your knowledge beyond the exam objectives; we added new skills and learning with the content provided. This further develops your knowledge and skills for on-premises network infrastructure services and enables you to be prepared for a real-world, day-to-day hybrid environment-focused role. In the next chapter, we learn the essential skills of managing users and computers with group policy.
Further reading
This section provides links to additional exam information and study references:
- Microsoft Certified: Windows Server Hybrid Administrator Associate: https://docs.microsoft.com/en-us/learn/certifications/windows-server-hybrid-administrator/
- Exam AZ-800: Administering Windows Server Hybrid Core Infrastructure: https://docs.microsoft.com/en-us/learn/certifications/exams/az-800
- Exam AZ-800: skills outline: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWKI0r
- Microsoft Learn: Deploy and manage identity infrastructure: https://docs.microsoft.com/en-us/learn/paths/deploy-manage-identity-infrastructure/
- What is Azure Active Directory Domain Services: https://docs.microsoft.com/en-gb/Azure/active-directory-domain-services/overview
- Compare self-managed Active Directory Domain Services, Azure Active Directory, and managed Azure Active Directory Domain Services: https://docs.microsoft.com/en-gb/Azure/active-directory-domain-services/compare-identity-solutions
- Tutorial: Configure virtual networking for an Azure Active Directory Domain Services managed domain: https://docs.microsoft.com/en-us/Azure/active-directory-domain-services/tutorial-configure-networking
- Tutorial: Create and configure an Azure Active Directory Domain Services managed domain: https://docs.microsoft.com/en-us/Azure/active-directory-domain-services/tutorial-create-instance
Skills check
Challenge yourself with what you have learned in this chapter by answering the following questions:
- What is Azure AD DS?
- Explain the differences between Azure AD DS and AD DS.
- What are the use cases for Azure AD DS?
- What is the relationship between Azure AD and Azure AD DS in the cloud-only identity scenario?
- What is the relationship between AD, Azure AD, and Azure AD DS in the hybrid identity scenario?
- List five crucial characteristics of Azure AD DS.
- What are the two enterprise applications created in the Azure AD tenant when the managed domain is created, and what are their purposes?
- What privileges are required to create an instance of Azure AD DS in the Azure AD tenant?
- What are the two approaches to the VNets used for the Azure AD DS and for workloads that will need to use Azure AD DS?
- Name some crucial considerations for choosing the domain name used for Azure AD DS.
- What are the SKUs for Azure AD DS, and what are their differences?
- Why is it essential to select the correct name, location, and SKU for Azure AD DS?
- What is the default forest type for Azure AD DS?
- What management tools can be used with Azure AD DS?
- List some of the limitations of the administrative aspects of a managed domain.