Azure Active Directory Domain Services

Tell us about your PDF experience.
Azure AD Domain Services

documentation
Learn how to use Azure Active Directory Domain Services to provide Kerberos or NTLM
authentication to applications or join Azure VMs to a managed domain.
About Azure AD Domain Services
ｅ OVERVIEW
What is Azure AD Domain Services?
Compare identity solutions
ｐ CONCEPT
How does synchronization work?
FAQs
Get started
｀ DEPLOY
Create a managed domain
ｇ TUTORIAL
Domain-join a Windows Server VM
Install management tools
Configure
ｇ TUTORIAL
Configure secure LDAP
ｃ HOW-TO GUIDE
Enable password hash synchronization
Create an organizational unit (OU)
Configure Kerberos Constrained Delegation
Secure managed domain
Manage
ｃ HOW-TO GUIDE
Administer group policy
Manage DNS
Check health status
Configure email notifications
Enable security audits
Domain-join VMs
ｇ TUTORIAL
Windows Server
ｃ HOW-TO GUIDE
Ubuntu Server
Red Hat Enterprise Linux
SUSE Linux Enterprise
Troubleshoot
ｃ HOW-TO GUIDE
Common issues
Common alert messages

Network security group issues
Secure LDAP issues

What is Azure Active Directory Domain
Services?
Article • 04/03/2023
Azure Active Directory Domain Services (Azure AD DS) 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.
An Azure AD DS 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.
Azure AD DS integrates with your existing Azure AD 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.
To get started, create an Azure AD DS managed domain using the Azure portal
Take a look at our short video to learn more about Azure AD DS.
https://www.microsoft.com/en-us/videoplayer/embed/RE4LblD?postJsllMsg=true
How does Azure AD DS work?

When you create an Azure AD DS 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 Azure AD

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 Azure
AD. 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, Azure AD Connect

synchronizes identity information with Azure AD, which is then synchronized to the
managed domain.
Azure AD DS replicates identity information from Azure AD, so it works with Azure AD
tenants that are cloud-only, or synchronized with an on-premises AD DS environment.
The same set of Azure AD DS 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.
For cloud-only environments, you don't need a traditional on-premises AD DS
environment to use the centralized identity services of Azure AD DS.
You can expand a managed domain to have more than one replica set per Azure AD
tenant. Replica sets can be added to any peered virtual network in any Azure region that
supports Azure AD DS. Additional replica sets in different Azure regions 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.
Take a look at this video about how Azure AD DS integrates with your applications and
workloads to provide identity services in the cloud:
https://www.youtube-nocookie.com/embed/T1Nd9APNceQ
To see Azure AD DS deployment scenarios in action, you can explore the following
examples:
Azure AD DS for hybrid organizations

Azure AD DS for cloud-only organizations
Azure AD DS features and benefits
To provide identity services to applications and VMs in the cloud, Azure AD DS 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 Azure AD.
To learn more about your identity options, compare Azure AD DS with Azure AD, AD DS
on Azure VMs, and AD DS on-premises.
The following features of Azure AD DS simplify deployment and management

operations:
Simplified deployment experience: Azure AD DS is enabled for your Azure AD

tenant using a single wizard in the Azure portal.
Integrated with Azure AD: User accounts, group memberships, and credentials are
automatically available from your Azure AD tenant. New users, groups, or changes
to attributes from your Azure AD tenant or your on-premises AD DS environment
are automatically synchronized to Azure AD DS.
Accounts in external directories linked to your Azure AD aren't available in
Azure AD DS. 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 Azure AD DS
are the same as in your Azure AD 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: Azure AD DS 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, these domain controllers are
also distributed across zones for additional resiliency.
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 Azure AD DS to
an on-premises AD DS environment. For more information, see Forest concepts
and features for Azure AD DS.
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 Azure AD via Azure AD Connect.
These user accounts, group memberships, and credentials are automatically available
within the managed domain.
Next steps
To learn more about Azure AD DS compares with other identity solutions and how
synchronization works, see the following articles:
Compare Azure AD DS with Azure AD, Active Directory Domain Services on Azure
VMs, and Active Directory Domain Services on-premises
Learn how Azure AD Domain Services synchronizes with your Azure AD directory
To learn how to administrator a managed domain, see management concepts for
user accounts, passwords, and administration in Azure AD DS.
To get started, create a managed domain using the Azure portal.

Compare self-managed Active Directory
Domain Services, Azure Active
Directory, and managed Azure Active
Directory Domain Services
Article • 04/03/2023
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 Azure Active
Directory.
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.
Azure Active Directory (Azure AD) - Cloud-based identity and mobile device
management that provides user account and authentication services for resources
such as Microsoft 365, the Azure portal, or SaaS applications.
Azure AD 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 Azure AD, see What is Azure Active Directory?
Azure Active Directory Domain Services (Azure AD DS) - 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.
Azure AD DS integrates with Azure AD, 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 Azure AD and on-premises, see How
objects and credentials are synchronized in a managed domain.
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.
To get started, create an Azure AD DS managed domain using the Azure portal
Azure AD DS 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 Azure Active Directory Domain Services
(Azure AD DS). 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 Azure AD DS, 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).
Azure AD DS 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 Azure AD DS and on-premises
environments.
For applications and services that run in the cloud and need access to traditional
authentication mechanisms such as Kerberos or NTLM, Azure AD DS 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 Azure AD DS.
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 Azure AD DS domain or a self-managed AD DS
domain:
Feature Azure AD DS Self-managed AD DS
Managed service ✓ ✕
Secure deployments ✓ Administrator secures the

deployment
DNS server ✓ (managed service) ✓
Domain or Enterprise administrator ✕ ✓

privileges
Domain join ✓ ✓
Domain authentication using ✓ ✓

NTLM and Kerberos
Kerberos constrained delegation Resource-based Resource-based &

account-based
Custom OU structure ✓ ✓
Group Policy ✓ ✓
Schema extensions ✕ ✓
AD domain / forest trusts ✓ (one-way outbound forest ✓

trusts only)
Feature Azure AD DS Self-managed AD DS
Secure LDAP (LDAPS) ✓ ✓
LDAP read ✓ ✓
LDAP write ✓ (within the managed ✓

domain)
Geo-distributed deployments ✓ ✓
Azure AD DS and Azure AD

Azure AD 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 Azure AD, which provides the device with
an identity. Azure AD then authenticates the device when a user signs in to Azure AD
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 Azure AD. This mechanism offers the
same benefits of registering a personal device with Azure AD, such as to allow users to
sign in to the device using their corporate credentials.
Azure AD joined devices give you the following benefits:
Single-sign-on (SSO) to applications secured by Azure AD.

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 Azure AD 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, Azure AD

macOS registered
Type of device Device platforms Mechanism
Organization-owned device not joined to on- Windows 10 Azure AD joined

premises AD DS
Organization-owned device joined to an on- Windows 10 Hybrid Azure AD

premises AD DS joined
On an Azure AD-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 Azure AD DS-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 Azure AD-joined Azure AD DS-joined
Device Azure AD Azure AD DS managed domain

controlled by
Representation Device objects in the Azure Computer objects in the Azure AD DS managed
in the directory AD directory domain
Authentication OAuth / OpenID Connect Kerberos and NTLM protocols

based protocols
Management Mobile Device Group Policy

Management (MDM)
software like Intune
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 Server VMs deployed in Azure

devices
If on-premises AD DS and Azure AD are configured for federated authentication using

AD FS, then there's no (current/valid) password hash available in Azure DS. Azure AD
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. Hence Azure
AD DS won't be able to validate the users credentials
Next steps
To get started with using Azure AD DS, create an Azure AD DS managed domain using
the Azure portal.
You can also learn more about management concepts for user accounts, passwords, and
administration in Azure AD DS and how objects and credentials are synchronized in a
managed domain.
Tutorial: Create and configure an Azure
Active Directory Domain Services
managed domain
Article • 08/01/2023
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. Azure
AD DS integrates with your existing Azure AD 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. This tutorial shows you how to
use default options to create and configure an Azure AD DS managed domain using the
Azure portal.
In this tutorial, you learn how to:
＂ 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 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 .
An Azure Active Directory tenant associated with your subscription, either
synchronized with an on-premises directory or a cloud-only directory.
If needed, create an Azure Active Directory tenant or associate an Azure
subscription with your account.
You need Application Administrator and Groups Administrator Azure AD roles in
your tenant to enable Azure AD DS.
You need Domain Services Contributor Azure role to create the required Azure AD
DS 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 Azure AD DS, it's recommended to configure self-service
password reset (SSPR) for the Azure AD 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 Azure portal

In this tutorial, you create and configure the managed domain using the Azure portal. To
get started, first sign in to the Azure portal .

To launch the Enable Azure AD Domain Services wizard, complete the following steps:
1. On the Azure portal menu or from the Home page, select Create a resource.
2. Enter Domain Services into the search bar, then choose Azure AD Domain Services
from the search suggestions.
3. On the Azure AD Domain Services page, select Create. The Enable Azure AD
Domain Services wizard is launched.
4. Select the Azure Subscription in which you would like to create the managed
domain.
5. 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 Azure portal to create a managed
domain:
1. Enter a DNS domain name for your managed domain, taking into consideration
the previous points.
2. Choose the Azure Location in which the managed domain should be created. If
you choose a region that supports Azure Availability Zones, the Azure AD DS
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 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?
3. 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 Azure AD DS SKU concepts.
For this tutorial, select the Standard SKU.
4. 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 Azure AD 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 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 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.
3. The page will load with updates on the deployment process, including the creation
of new resources in your directory.
4. 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.
5. When the managed domain is fully provisioned, the Overview tab shows the
domain status as Running.
） Important
The managed domain is associated with your Azure AD tenant. During the
provisioning process, Azure AD DS creates two Enterprise Applications named
Domain Controller Services and AzureActiveDirectoryDomainControllerServices in
the Azure AD 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 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 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.
2. 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 Azure portal, Azure PowerShell, or the Azure CLI.
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.
７ 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 Azure AD 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 - Azure AD needs to generate and store the
password hashes in the new managed domain.
Azure AD Connect Cloud Sync is not supported with Azure AD DS. On-premises
users need to be synced using Azure AD Connect in order to be able to access
domain-joined VMs. For more information, see Password hash sync process for
Azure AD DS and Azure AD Connect.
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 tutorial, 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.
 Tip
If your Azure AD 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
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, let's 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 Profile 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.
Next steps
In this tutorial, you learned how to:
＂ Understand DNS requirements for a managed domain

＂ Add administrative users to domain management
＂ Enable user accounts for Azure AD DS 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.
Configure Azure virtual network for application workloads to use your managed
domain
Tutorial: Configure virtual networking
for an Azure Active Directory Domain
Services managed domain
Article • 08/23/2022
To provide connectivity to users and applications, an Azure Active Directory Domain

Services (Azure AD DS) 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 Azure AD DS 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 Azure AD DS managed domain's virtual
network.
＂ Understand the virtual network connectivity options for domain-joined resources to

Azure AD DS
＂ Create an IP address range and additional subnet in the Azure AD DS virtual
network
＂ Configure virtual network peering to a network that's separate from Azure AD DS
Prerequisites

DS resources.
An Azure Active Directory Domain Services managed domain enabled and
configured in your Azure AD tenant.
If needed, the first tutorial creates and configures an Azure Active Directory
Domain Services managed domain.

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 Azure AD DS 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 Azure AD DS 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 Azure AD DS 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 Azure AD DS 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 Azure AD DS 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 Azure Active Directory Domain Services.
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 Azure portal, 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.
2. 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.
3. Next, in the left-hand menu of the virtual network window, select Subnets, then
choose + Subnet to add a subnet.
4. 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:
5. 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 Azure AD DS 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.
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.
2. In the left-hand menu of the virtual network window, select Peerings.
3. 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.
4. It takes a few moments to create the peering on both the Azure AD DS 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 Azure AD
DS 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 Azure AD DS 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 Azure AD DS domain controllers.
1. In the Azure portal, 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.
2. In the left-hand menu of the virtual network window, select DNS servers.
3. 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 Azure AD DS 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.
4. When ready, select Save. It takes a few moments to update the DNS servers for the
virtual network.
5. 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
＂ Understand the virtual network connectivity options for domain-joined resources to

Azure AD DS
＂ Create an IP address range and additional subnet in the Azure AD DS virtual
network
＂ Configure virtual network peering to a network that's separate from Azure AD DS
To see this managed domain in action, create and join a virtual machine to the domain.
Join a Windows Server virtual machine to your managed domain

Tutorial: Join a Windows Server virtual
machine to an Azure Active Directory
Domain Services managed domain
Article • 06/22/2023
fully compatible with Windows Server Active Directory. With an Azure AD DS 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.
＂ Create a Windows Server VM

＂ Connect the Windows Server VM to an Azure virtual network
＂ Join the VM to the managed domain
Prerequisites
To complete this tutorial, you need the following resources:

If needed, create and configure an Azure Active Directory Domain Services
managed domain.
A user account that's a part of the managed domain.
Make sure that Azure AD 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 Azure AD DS virtual network.
If needed, create an Azure Bastion host.
If you already have a VM that you want to domain-join, skip to the section to join the
VM to the managed domain.

In this tutorial, you create a Windows Server VM to join to your managed domain using
the Azure portal. To get started, first sign in to the Azure portal .
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
1. From the Azure portal menu or from the Home page, select Create a resource.
2. From Get started, choose Windows Server 2016 Datacenter.

3. 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 Select or create a resource group, such as myResourceGroup

group
Virtual Enter a name for the VM, such as myVM

machine
name
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 isn't supported.
4. 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 Azure portal 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.
5. When done, select Next: Disks.
6. From the drop-down menu for OS disk type, choose Standard SSD, then select
Next: Networking.
7. 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.
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
8. 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.
9. 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.
10. Next, in the left-hand menu of the virtual network window, select Subnets, then
choose + Subnet to add a subnet.
11. 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.
12. It takes a few seconds to create the subnet. Once it's created, select the X to close
the subnet window.
13. 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.
14. 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.
15. Leave the other options as their default values, then select Management.
16. Set Boot diagnostics to Off. Leave the other options as their default values, then
select Review + create.
17. Review the VM settings, then select Create.
It takes a few minutes to create the VM. The Azure portal 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 Azure portal from your web browser. If needed, create an Azure
Bastion host.
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.
2. 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.
2. In the left pane of the Server Manager window, select Local Server. Under
Properties on the right pane, choose Workgroup.
3. In the System Properties window, select Change to join the managed domain.
4. In the Domain box, specify the name of your managed domain, such as
aaddscontoso.com, then select OK.
5. 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
Azure AD tenant - accounts from external directories associated with your Azure
AD 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 Azure AD. 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 Azure AD 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 .
6. 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.
7. 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 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 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. Otherwise, continue
to the next tutorial.
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. 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 without unjoining from the domain, an orphaned computer object
is left in Azure AD DS.
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

2. Choose your resource group, such as myResourceGroup.
3. 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.
4. 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 Azure AD DS 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 Azure AD tenant.
Accounts from external directories associated with your Azure AD 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 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 Azure AD
updates the password in Azure AD DS. It takes some time for the password to be
available for domain-join use.
Next steps
＂ 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).
Install administration tools on a management VM
Tutorial: Create a management VM to
configure and administer an Azure
managed domain
Article • 08/23/2022
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 Azure AD DS 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 an Azure AD DS managed domain.
＂ 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
Prerequisites

If needed, see the first tutorial to create and configure an Azure Active Directory
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.
A user account that's a member of the Azure AD DC administrators group in your
Azure AD tenant.
An Azure Bastion host deployed in your Azure AD DS virtual network.
If needed, create an Azure Bastion host.

In this tutorial, you create and configure a management VM using the Azure portal. To
Available administrative tasks in Azure AD DS

Azure AD DS 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.
７ 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)
To get started, connect to the Windows Server VM as follows:
1. In the Azure portal, 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.
2. In the Overview pane for your VM, select Connect, then Bastion.
3. 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:
2. In the Dashboard pane of the Server Manager window, select Add Roles and
Features.
3. On the Before You Begin page of the Add Roles and Features Wizard, select Next.
4. For the Installation Type, leave the Role-based or feature-based installation option
checked and select Next.
5. On the Server Selection page, choose the current VM from the server pool, such
as myvm.aaddscontoso.com, then select Next.
6. On the Server Roles page, click Next.
7. 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.
8. On the Confirmation page, select Install. It may take a minute or two to install the
administrative tools.
9. 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.
2. Select Active Directory Administrative Center.
3. 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.
4. To see the users and groups that belong to the managed domain, select the
AADDC Users container. The user accounts and groups from your Azure AD 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.
5. 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 Azure AD to Azure AD DS. There's no write back from Azure AD DS to
Azure AD. You can't change passwords or managed group membership for users
synchronized from Azure AD 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
＂ 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).
Configure secure LDAP for your managed domain
Tutorial: Configure secure LDAP for an
Azure Active Directory Domain Services
managed domain
Article • 03/15/2023
To communicate with your Azure Active Directory Domain Services (Azure AD DS)
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 Azure AD DS, 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 an Azure AD DS managed domain.
＂ Create a digital certificate for use with Azure AD DS

＂ Enable secure LDAP for Azure AD DS
＂ Configure secure LDAP for use over the public internet
＂ Bind and test secure LDAP for a managed domain
Prerequisites

managed domain.
The LDP.exe tool installed on your computer.
If needed, install the Remote Server Administration Tools (RSAT) for Active
Directory Domain Services and LDAP.
your tenant to enable secure LDAP.

In this tutorial, you configure secure LDAP for the managed domain using the Azure
portal. To get started, first sign in to the Azure portal .
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 the Azure AD 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 cmdlet, etc.
In this tutorial, let's create a self-signed certificate for secure LDAP using the 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.
Export a certificate for Azure AD DS

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.
2. Open the Microsoft Management Console (MMC) by entering mmc in the Run
dialog, then select OK.
3. On the User Account Control prompt, then select Yes to launch MMC as
administrator.
4. From the File menu, select Add/Remove Snap-in...
5. In the Certificates snap-in wizard, choose Computer account, then select Next.
6. On the Select Computer page, choose Local computer: (the computer this
console is running on), then select Finish.
7. In the Add or Remove Snap-ins dialog, select OK to add the certificates snap-in to
MMC.
8. In the MMC window, expand Console Root. Select Certificates (Local Computer),
then expand the Personal node, followed by the Certificates node.
9. The self-signed certificate created in the previous step is shown, such as

aaddscontoso.com. Right-select this certificate, then choose All Tasks > Export...
10. In the Certificate Export Wizard, select Next.
11. 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.
12. 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:
13. 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, you need to pass
the -CryptoAlgorithmOption flag using TripleDES_SHA1.
14. On the File to Export page, specify the file name and location where you'd like to
export the certificate, such as C:\Users\accountname\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.
15. 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.
16. 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 Azure AD DS. 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...
2. In the Certificate Export Wizard, select Next.
3. 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.
4. On the Export File Format page, select Base-64 encoded X.509 (.CER) as the file
format for the exported certificate:
5. On the File to Export page, specify the file name and location where you'd like to
export the certificate, such as C:\Users\accountname\azure-ad-ds-client.cer.
6. 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\accountname\azure-ad-ds-client.cer.
2. Right-select the .CER certificate file, then choose Install Certificate.
3. In the Certificate Import Wizard, choose to store the certificate in the Local
machine, then select Next:
4. When prompted, choose Yes to allow the computer to make changes.
5. Choose to Automatically select the certificate store based on the type of

certificate, then select Next.
6. On the review page, select Finish to import the .CER certificate. file A confirmation
dialog is displayed when the certificate has been successfully imported.
Enable secure LDAP for Azure AD DS

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 Azure portal , enter domain services in the Search resources box. Select
Azure AD Domain Services from the search result.
2. Choose your managed domain, such as aaddscontoso.com.
3. On the left-hand side of the Azure AD DS window, choose Secure LDAP.
4. By default, secure LDAP access to your managed domain is disabled. Toggle Secure
LDAP to Enable.
5. 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.
6. 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.
7. Enter the Password to decrypt .PFX file set in a previous step when the certificate
was exported to a .PFX file.
8. 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.
2. To apply the replacement certificate to Azure AD DS, in the left menu for Azure AD
DS in the Azure portal, select Secure LDAP, and then select Change Certificate.
3. 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 Azure portal, select Resource groups on the left-hand side navigation.
2. Choose your resource group, such as myResourceGroup, then select your network
security group, such as aaads-nsg.
3. 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.
4. 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
5. 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.
1. Open LDP.exe and connect to the managed domain. Select Connection, then
choose Connect....
2. 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.
3. 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.
1. Select the Connection menu option, then choose Bind....

2. 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.
3. For Bind type, choose the option for Bind with credentials.
4. 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.
2. Leave the BaseDN field blank, then select OK.

3. Choose a container, such as AADDC Users, then right-select the container and
choose Search.
4. 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.
７ 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

2. Browse to and open the file C:\Windows\System32\drivers\etc\hosts
3. 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

2. Configuring the client
3. Networking
4. Establishing the TLS session
For the certificate subject name match, the DC will use the Azure AD DS domain name
(not the Azure AD 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.
Next steps
＂ Create a digital certificate for use with Azure AD DS

＂ Enable secure LDAP for Azure AD DS
＂ Configure secure LDAP for use over the public internet
＂ Bind and test secure LDAP for a managed domain
Configure password hash synchronization for a hybrid Azure AD environment

Tutorial: Enable password
synchronization in Azure Active
Directory Domain Services for hybrid
environments
Article • 04/03/2023
For hybrid environments, an Azure Active Directory (Azure AD) tenant can be configured
to synchronize with an on-premises Active Directory Domain Services (AD DS)
environment using Azure AD Connect. By default, Azure AD Connect doesn't
synchronize legacy NT LAN Manager (NTLM) and Kerberos password hashes that are
needed for Azure Active Directory Domain Services (Azure AD DS).
To use Azure AD DS with accounts synchronized from an on-premises AD DS

environment, you need to configure Azure AD Connect to synchronize those password
hashes required for NTLM and Kerberos authentication. After Azure AD Connect is
configured, an on-premises account creation or password change event also then
synchronizes the legacy password hashes to Azure AD.
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:
＂ Why legacy NTLM and Kerberos password hashes are needed

＂ How to configure legacy password hash synchronization for Azure AD Connect
Prerequisites
To complete this tutorial, you need the following resources:

An Azure Active Directory tenant associated with your subscription that's
synchronized with an on-premises directory using Azure AD Connect.
If needed, enable Azure AD Connect for password hash synchronization.
managed domain.
Password hash synchronization using Azure AD

Connect
Azure AD Connect is used to synchronize objects like user accounts and groups from an
on-premises AD DS environment into an Azure AD tenant. As part of the process,
password hash synchronization enables accounts to use the same password in the on-
premises AD DS environment and Azure AD.

a format that's suitable for NTLM and Kerberos authentication. Azure AD doesn't 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.
Azure AD Connect can be configured to synchronize the required NTLM or Kerberos

password hashes for Azure AD DS. Make sure that you have completed the steps to
enable Azure AD Connect for password hash synchronization. If you had an existing
instance of Azure AD Connect, download and update to the latest version to make
sure you can synchronize the legacy password hashes for NTLM and Kerberos. This
functionality isn't available in early releases of Azure AD Connect or with the legacy
DirSync tool. Azure AD Connect version 1.1.614.0 or later is required.
） Important
Azure AD Connect should only be installed and configured for synchronization with
on-premises AD DS environments. It's not supported to install Azure AD Connect in
an Azure AD DS managed domain to synchronize objects back to Azure AD.
Enable synchronization of password hashes

With Azure AD Connect installed and configured to synchronize with Azure AD, 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
Azure AD. When that Azure AD Connect password hash synchronization process is
complete, users can sign in to applications through Azure AD DS that use legacy NTLM
or Kerberos password hashes.
1. On the computer with Azure AD Connect installed, from the Start menu, open the
Azure AD Connect > Synchronization Service.
2. Select the Connectors tab. The connection information used to establish the
synchronization between the on-premises AD DS environment and Azure AD are
listed.
The Type indicates either Windows Azure Active Directory (Microsoft) for the Azure
AD 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 Azure AD connector is named contoso.onmicrosoft.com - Azure AD

The on-premises AD DS connector is named onprem.contoso.com
3. Copy and paste the following PowerShell script to the computer with Azure AD
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 Azure AD.
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.ConfigurationParame
ter "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 Azure AD may take
some time. The passwords are then synchronized to the managed domain after
they've synchronized to Azure AD.
Next steps
In this tutorial, you learned:
＂ Why legacy NTLM and Kerberos password hashes are needed

＂ How to configure legacy password hash synchronization for Azure AD Connect
Learn how synchronization works in an Azure AD Domain Services managed

domain
Tutorial: Create and use replica sets for
resiliency or geolocation in Azure Active
Article • 05/25/2023
To improve the resiliency of an Azure Active Directory Domain Services (Azure AD DS)
managed domain, or deploy to additional geographic locations close to your
applications, you can use replica sets. Every Azure AD DS 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 Azure AD DS.
＂ Understand the virtual network requirements

＂ Create a replica set
＂ Delete a replica set
Prerequisites


An Azure Active Directory Domain Services managed domain created using the
Azure Resource Manager deployment model and configured in your Azure AD
tenant.
managed domain.
） 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.

In this tutorial, you create and manage replica sets using the Azure portal. To get
started, first sign in to the Azure portal .
Networking considerations
The virtual networks that host replica sets must be able to communicate with each
other. Applications and services that depend on Azure AD DS 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 Azure AD DS, 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 Azure AD DS 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 Azure portal, 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 Azure portal. 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 Azure AD DS, 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 Azure AD DS replica set.
To create an additional replica set, complete the following steps:
1. In the Azure portal, search for and select Azure AD Domain Services.
3. 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.
4. 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 Azure AD
DS.
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:
5. 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:
3. 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.
4. Select Delete from the context menu, then confirm you want to delete the replica
set.
5. In the Azure AD DS 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
＂ 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 Azure AD DS.
Replica sets concepts and features

Tutorial: Perform a disaster recovery
drill using replica sets in Azure Active
Article • 08/23/2022
This topic shows how to perform a disaster recovery (DR) drill for Azure AD Domain
Services (Azure AD DS) using replica sets. This will simulate one of the replica sets going
offline by making changes to the network virtual network properties to block client
access to it. It is not a true DR drill in that the replica set will not be taken offline.
The DR drill will cover:
1. A client machine is connected to a given replica set. It can authenticate to the

domain and perform LDAP queries.
2. The client’s connection to the replica set will be terminated. This will happen by
restricting network access.
3. The client will then establish a new connection with the other replica set. Once that
happens, the client will be able to authenticate to the domain and perform LDAP
queries.
4. The domain member will be rebooted, and a domain user will be able to log in
post reboot.
5. The network restrictions will be removed, and the client will be able to connect to
original replica set.
Prerequisites
The following requirements must be in place to complete the DR drill:
An active Azure AD DS instance deployed with at least one extra replica set in
place. The domain must be in a healthy state.
A client machine that is joined to the Azure AD DS hosted domain. The client must
be in its own virtual network, virtual network peering enabled with both replica set
virtual networks, and the virtual network must have the IP addresses of all domain
controllers in the replica sets listed in DNS.
Environment validation
1. Log in to the client machine with a domain account.
2. Install the Active Directory Domain Services RSAT tools.
3. Start an elevated PowerShell window.
4. 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
5. 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 will be performing these operations for each replica set in the Azure AD DS
instance. This will simulate an outage for each replica set. When domain controllers are
not reachable, the client will automatically fail over to a reachable domain controller and
this experience should be seamless to the end user or workload. Therefore it is 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.
2. On the client machine, connect to one of the domain controllers using nltest
/sc_reset:[domain]\[domain controller name] .
3. 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.
a. Select the peered network that you want to update.
b. Select to block all network traffic that enters or leaves the virtual network.
4. 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.
5. 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.
6. Reboot the client and login with the same domain account. This shows that
authentication is still working as expected and logins are not blocked.
7. 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.
8. 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 Azure AD DS instance.
Summary
After you complete these steps, you will see domain members continue to access the
directory if one of the replica sets in the Azure AD DS is not 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 will impact the health of your Azure AD DS instance until the network
access is restored.
Next steps
＂ 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 Azure AD DS.
Replica sets concepts and features

Tutorial: Create and configure an Azure
managed domain with advanced
configuration options
Article • 04/03/2023
You can create a managed domain using default configuration options for networking
and synchronization, or manually define these settings. This tutorial shows you how to
define those advanced configuration options to create and configure an Azure AD DS
managed domain using the Azure portal.
＂ Configure DNS and virtual network settings for a managed domain

＂ Enable password hash synchronization
Prerequisites

DS resources.
Although not required for Azure AD DS, it's recommended to configure self-service
password reset (SSPR) for the Azure AD 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.

Create a managed domain and configure basic

settings
To launch the Enable Azure AD Domain Services wizard, complete the following steps:
1. On the Azure portal menu or from the Home page, select Create a resource.
2. Enter Domain Services into the search bar, then choose Azure AD Domain Services
from the search suggestions.
3. On the Azure AD Domain Services page, select Create. The Enable Azure AD
Domain Services wizard is launched.
4. Select the Azure Subscription in which you would like to create the managed
domain.
5. 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:
applications.
 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.
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.
characters.
network.
Complete the fields in the Basics window of the Azure portal to create a managed
domain:
1. Enter a DNS domain name for your managed domain, taking into consideration
the previous points.
2. 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.
 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 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?
3. 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 Azure AD DS SKU concepts.
For this tutorial, select the Standard SKU.
4. A forest is a logical construct used by Active Directory Domain Services to group

one or more domains.
5. 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. 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 Azure AD into the managed domain.
Create and configure the virtual network

To provide connectivity, an Azure virtual network and a dedicated subnet are needed.
Azure AD DS 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 Azure AD DS.
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 Azure AD DS resources.
Don't select the Gateway subnet for deploying Azure AD DS. It's not supported to
deploy Azure AD DS 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 Azure Active Directory Domain Services.
Complete the fields in the Network window as follows:
1. On the Network page, choose a virtual network to deploy Azure AD DS into from
the drop-down menu, or select Create new.
a. 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.
b. Create a dedicated subnet with a clear name, such as DomainServices. Provide
an address range, such as 10.0.1.0/24.

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 Azure AD DS.
2. Select a virtual network subnet, such as DomainServices.
3. When ready, choose Next - Administration.
Configure an administrative group

A special administrative group named AAD DC Administrators is used for management
of the Azure AD DS 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 Azure AD DS. 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 Azure AD
directory. If you have an existing group with this name in your Azure AD 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.
2. Select the Add members button, then search for and select users from your Azure
AD directory. For example, search for your own account, and add it to the AAD DC
Administrators group.
3. If desired, change or add additional recipients for notifications when there are
alerts in the managed domain that require attention.
4. When ready, choose Next - Synchronization.
Configure synchronization
Azure AD DS lets you synchronize all users and groups available in Azure AD, 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 Azure AD
Domain Services scoped synchronization.
1. For this tutorial, choose to synchronize All users and groups. This synchronization
choice is the default option.
2. 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 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 like DNS name or virtual network can't be changed once the
Azure AD DS managed 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.
3. 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.
4. When the managed domain is fully provisioned, the Overview tab shows the
domain status as Running.
） Important
The managed domain is associated with your Azure AD tenant. During the
provisioning process, Azure AD DS creates two Enterprise Applications named
Domain Controller Services and AzureActiveDirectoryDomainControllerServices in
the Azure AD 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 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 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.
2. 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 Azure portal, Azure PowerShell, or the Azure CLI.
Enable user accounts for Azure AD DS

７ 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 Azure AD 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 - Azure AD needs to generate and store the
password hashes in the new managed domain.
For more information, see Password hash sync process for Azure AD DS and Azure
AD Connect.
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 tutorial, 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.
 Tip
If your Azure AD tenant has a combination of cloud-only users and users from your
on-premises AD, you need to complete both sets of steps.
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, let's 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 Profile 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.
Next steps
＂ Configure DNS and virtual network settings for a managed domain

＂ Enable user accounts for Azure AD DS and generate password hashes
To see this managed domain in action, create and join a virtual machine to the domain.
Join a Windows Server virtual machine to your managed domain

Tutorial: Create an outbound forest trust
to an on-premises domain in Azure
Article • 04/03/2023
You can create a one-way outbound trust from Azure AD DS 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 Azure AD DS
managed domain. A forest trust can help users access resources in scenarios such as:
Environments where you can't synchronize password hashes, or where users

exclusively sign in using smart cards and don't know their password.
Hybrid scenarios that still require access to on-premises domains.
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 Azure AD DS. This prevents UPN collisions when users authenticate.
＂ Configure DNS in an on-premises AD DS environment to support Azure AD DS

connectivity
＂ Create a one-way inbound forest trust in an on-premises AD DS environment
＂ Create a one-way outbound forest trust in Azure AD DS
＂ Test and validate the trust relationship for authentication and resource access
Prerequisites


An Azure Active Directory Domain Services managed domain.

managed domain.
） Important
You need to use a minimum of Enterprise SKU for your managed domain. If
needed, change the SKU for a managed domain.

In this tutorial, you create and configure the outbound forest trust from Azure AD DS
using the Azure portal. To get started, first sign in to the Azure portal . You need
Application Administrator and Groups Administrator Azure AD roles in your tenant to
modify an Azure AD DS instance.
Networking considerations
The virtual network that hosts the Azure AD DS forest needs network connectivity to
your on-premises Active Directory. Applications and services also need network
connectivity to the virtual network hosting the Azure AD DS forest. Network connectivity
to the Azure AD DS forest must be always on and stable otherwise users may fail to
authenticate or access resources.
Before you configure a forest trust in Azure AD DS, 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 or ExpressRoute connection.
Create subnets with enough IP addresses to support your scenario.
Make sure Azure AD DS 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 Azure AD DS 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 Azure AD DS
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.
2. Select your DNS zone, such as aaddscontoso.com.
3. Select Conditional Forwarders, then right-select and choose New Conditional

Forwarder...
4. 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:
5. 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.
6. 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 Azure portal.
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.
2. Right-click the domain, such as onprem.contoso.com, then select Properties.
3. Choose Trusts tab, then New Trust.
4. Enter the name for Azure AD DS domain name, such as aaddscontoso.com, then
select Next.
5. Select the option to create a Forest trust, then to create a One way: incoming
trust.
6. Choose to create the trust for This domain only. In the next step, you create the
trust in the Azure portal for the managed domain.
7. Choose to use Forest-wide authentication, then enter and confirm a trust
password. This same password is also entered in the Azure portal in the next
section.
8. Step through the next few windows with default options, then choose the option
for No, do not confirm the outgoing trust.
9. 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.
2. Right-click the domain, such as onprem.contoso.com, then select Properties.
3. Choose Trusts tab, then Domains that trust this domain (incoming trusts), click
the trust to be removed, and then click Remove.
4. On the Trusts tab, under Domains trusted by this domain (outgoing trusts), click
the trust to be removed, and then click Remove.
5. Click No, remove the trust from the local domain only.
Create outbound forest trust in Azure AD DS

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 Azure portal, complete the
following steps:
1. In the Azure portal, search for and select Azure AD Domain Services, then select
your managed domain, such as aaddscontoso.com.
2. From the menu on the left-hand side of the managed domain, select Trusts, then
choose to + Add a trust.
3. Enter a display name that identifies your trust, then the on-premises trusted forest
DNS name, such as onprem.contoso.com.
4. 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.
5. Provide at least two DNS servers for the on-premises AD DS domain, such as
10.1.1.4 and 10.1.1.5.
6. 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 Azure AD DS:
1. In the Azure portal, search for and select Azure AD Domain Services, then select
your managed domain, such as aaddscontoso.com.
2. From the menu on the left-hand side of the managed domain, select Trusts,
choose the trust, and click Remove.
3. 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 Azure AD DS forest

Access resources in the Azure AD DS forest using on-premises user
Enable file and printer sharing
Create a security group and add members
Create a file share for cross-forest access
Validate cross-forest authentication to a resource
On-premises user authentication from the Azure AD DS

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.
1. Connect to the Windows Server VM joined to the Azure AD DS forest using Azure
Bastion and your Azure AD DS administrator credentials.
2. Open a command prompt and use the whoami command to show the
distinguished name of the currently authenticated user:
Console
whoami /fqdn
3. 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
4. If the authentication is a successful, a new command prompt opens. The title of the
new command prompt includes running as userUpn@trusteddomain.com .
5. Use whoami /fqdn in the new command prompt to view the distinguished name of
the authenticated user from the on-premises Active Directory.
Access resources in the Azure AD DS forest using on-

premises user
Using the Windows Server VM joined to the Azure AD DS 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.
1. Connect to the Windows Server VM joined to the Azure AD DS forest using Azure
Bastion and your Azure AD DS administrator credentials.
2. Open Windows Settings, then search for and select Network and Sharing Center.
3. Choose the option for Change advanced sharing settings.
4. Under the Domain Profile, select Turn on file and printer sharing and then Save
changes.
5. Close Network and Sharing Center.

1. Open Active Directory Users and Computers.
2. Right-select the domain name, choose New, and then select Organizational Unit.
3. In the name box, type LocalObjects, then select OK.
4. Select and right-click LocalObjects in the navigation pane. Select New and then
Group.
5. Type FileServerAccess in the Group name box. For the Group Scope, select Domain
local, then choose OK.
6. In the content pane, double-click FileServerAccess. Select Members, choose to

Add, then select Locations.
7. Select your on-premises Active Directory from the Location view, then choose OK.
8. 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 Azure AD DS managed domain can't access
resources or search for users or groups in the trusted (on-premises) domain.
9. 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.

1. On the Windows Server VM joined to the Azure AD DS forest, create a folder and
provide name such as CrossForestShare.
2. Right-select the folder and choose Properties.
3. Select the Security tab, then choose Edit.
4. In the Permissions for CrossForestShare dialog box, select Add.
5. Type FileServerAccess in Enter the object names to select, then select OK.
6. 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.
7. Select the Sharing tab, then choose Advanced Sharing….
8. Choose Share this folder, then enter a memorable name for the file share in Share
name such as CrossForestShare.
9. Select Permissions. In the Permissions for Everyone list, choose Allow for the
Change permission.
10. Select OK two times and then Close.
1. Sign in a Windows computer joined to your on-premises Active Directory using a

user account from your on-premises Active Directory.
2. Using Windows Explorer, connect to the share you created using the fully qualified
host name and the share such as \\fs1.aaddscontoso.com\CrossforestShare .
3. 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.
4. To validate the read permission, open New Text Document.
5. To validate the modify permission, add text to the file and close Notepad. When
prompted to save changes, choose Save.
6. To validate the delete permission, right-select New Text Document and choose
Delete. Choose Yes to confirm file deletion.
Next steps
＂ Configure DNS in an on-premises AD DS environment to support Azure AD DS

connectivity
＂ Create a one-way outbound forest trust in Azure AD DS
For more conceptual information about forest in Azure AD DS, see How do forest trusts
work in Azure AD DS?.
Enable Azure Active Directory Domain
Services using PowerShell
Article • 05/11/2023
This article shows you how to enable Azure AD DS using PowerShell.
７ Note
We recommend that you use the Azure Az PowerShell module to interact with
Azure. See Install Azure PowerShell to get started. To learn how to migrate to the
Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.
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.
Make sure that you sign in to your Azure subscription using the Connect-
AzAccount cmdlet.
Install and configure Azure AD PowerShell.

If needed, follow the instructions to install the Azure AD PowerShell module and
connect to Azure AD.
Make sure that you sign in to your Azure AD tenant using the Connect-AzureAD
cmdlet.
You need global administrator privileges in your Azure AD tenant to enable Azure
AD DS.
You need Contributor privileges in your Azure subscription to create the required
Azure AD DS resources.
） Important
While the Az.ADDomainServices PowerShell module is in preview, you must

install it separately using the Install-Module cmdlet.
Azure PowerShell
Install-Module -Name Az.ADDomainServices
Create required Azure AD resources

Azure AD DS requires a service principal to authenticate and communicate and an Azure
AD group to define which users have administrative permissions in the managed
domain.
First, create an Azure AD 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 an Azure AD service principal using the New-AzureADServicePrincipal cmdlet:
PowerShell
New-AzureADServicePrincipal -AppId "2565bd9d-da50-47d4-8b85-4c97f669dc36"
Now create an Azure AD 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
cmdlet. If the group doesn't exist, create it with the AAD DC Administrators group using
the 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 cmdlet, then add the user to the group using the 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'" | `
# Add the user to the 'AAD DC Administrators' group.

Add-AzureADGroupMember -ObjectId $GroupObjectId.ObjectId -RefObjectId
$UserObjectId.ObjectId
Create network resources

First, register the Azure AD Domain Services resource provider using the Register-
AzResourceProvider cmdlet:
Azure PowerShell
Register-AzResourceProvider -ProviderNamespace Microsoft.AAD
Next, create a resource group using the 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:
Azure PowerShell
$ResourceGroupName = "myResourceGroup"
$AzureLocation = "westus"
# Create the resource group.

New-AzResourceGroup `
-Name $ResourceGroupName `
-Location $AzureLocation
Create the virtual network and subnets for Azure AD Domain Services. Two subnets are
created - one for DomainServices, and one for Workloads. Azure AD DS 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 cmdlet, then create

the virtual network using the New-AzVirtualNetwork cmdlet.
Azure PowerShell
$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 `
# 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

Azure AD DS 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)
contains a list of rules that allow or deny network traffic to traffic in an Azure virtual
network. In Azure AD DS, 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.
The following PowerShell cmdlets use New-AzNetworkSecurityRuleConfig to create the

rules, then 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 cmdlet.
Azure PowerShell
$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 `
-Priority 301 `
-SourceAddressPrefix AzureActiveDirectoryDomainServices `
# Create the network security group and rules

$nsg = New-AzNetworkSecurityGroup -Name $NSGName `
-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

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 cmdlet.
If you choose a region that supports Availability Zones, the Azure AD DS 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 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?.
Azure PowerShell
$AzureSubscriptionId = "YOUR_AZURE_SUBSCRIPTION_ID"
$ManagedDomainName = "aaddscontoso.com"
# Enable Azure AD Domain Services for the directory.

$replicaSetParams = @{
Location = $AzureLocation
SubnetId =
"/subscriptions/$AzureSubscriptionId/resourceGroups/$ResourceGroupName/provi
ders/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 Azure portal, the Overview page
for your managed domain shows the current status throughout this deployment stage.
When the Azure portal 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 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.
７ Note
To enable Azure AD DS, you must be a global administrator for the Azure AD
tenant. You also need at least Contributor privileges in the Azure subscription.
Azure PowerShell
# 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.

# First, retrieve the object ID of the 'AAD DC Administrators' group.
# 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" `
-SecurityEnabled $true `
-MailEnabled $false `
}
else {
Write-Output "Admin group already exists."
}
# Now, retrieve the object ID of the user you'd like to add to the group.
-Filter "UserPrincipalName eq '$AaddsAdminUserUpn'" | `

# Register the resource provider for Azure AD Domain Services with Resource
Manager.
# Create the resource group.

-Name $ResourceGroupName `
-Location $AzureLocation
# Create the dedicated subnet for AAD Domain Services.

$SubnetName = "DomainServices"
$AaddsSubnet = New-AzVirtualNetworkSubnetConfig `
-Name DomainServices `
$WorkloadSubnet = New-AzVirtualNetworkSubnetConfig `
-Name Workloads `
# Create the virtual network in which you will enable Azure AD Domain
Services.
$Vnet=New-AzVirtualNetwork `
-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 `
-Priority 201 `
-SourceAddressPrefix CorpNetSaw `
# Create a rule to allow TCP port 5986 traffic for PowerShell remote
management
$nsg301 = New-AzNetworkSecurityRuleConfig -Name AllowPSRemoting `
-Access Allow `
-Protocol Tcp `
-Priority 301 `
-SourceAddressPrefix AzureActiveDirectoryDomainServices `
# Create the network security group and rules

$nsg = New-AzNetworkSecurityGroup -Name $NSGName `
-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/provi
ders/Microsoft.Network/virtualNetworks/$VnetName/subnets/DomainServices"
}
$replicaSet = New-AzADDomainServiceReplicaSet @replicaSetParams
$domainServiceParams = @{
Name = $ManagedDomainName
ResourceGroupName = $ResourceGroupName
DomainName = $ManagedDomainName
ReplicaSet = $replicaSet
}
New-AzADDomainService @domainServiceParams
Next steps
To see the managed domain in action, you can domain-join a Windows VM, configure
secure LDAP, and configure password hash sync.
Create an Azure Active Directory
using an Azure Resource Manager
template
Article • 06/01/2023
This article shows you how to create a managed domain using an Azure Resource
Manager template. Supporting resources are created using Azure PowerShell.
Prerequisites

AzAccount cmdlet.
cmdlet.
DS resources.
DNS naming requirements

When you create an Azure AD DS managed domain, you specify a DNS name. There are
some considerations when you choose this DNS name:
applications.
 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.
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.
characters.
network.
Create required Azure AD resources

Azure AD DS requires a service principal and an Azure AD group. These resources let the
managed domain synchronize data, and define which users have administrative
permissions in the managed domain.
First, register the Azure AD Domain Services resource provider using the Register-
AzResourceProvider cmdlet:
PowerShell
Create an Azure AD service principal using the New-AzureADServicePrincipal cmdlet for

Azure AD DS 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
Now create an Azure AD group named AAD DC Administrators using the 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" `

-SecurityEnabled $true -MailEnabled $false `
With the AAD DC Administrators group created, add a user to the group using the Add-
AzureADGroupMember cmdlet. You first get the AAD DC Administrators group object ID
using the Get-AzureADGroup cmdlet, then the desired user's object ID using the 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.
# Now, retrieve the object ID of the user you'd like to add to the group.
-Filter "UserPrincipalName eq 'admin@contoso.onmicrosoft.com'" | `

Finally, create a resource group using the 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
-Name "myResourceGroup" `
-Location "WestUS"
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?.
Resource definition for Azure AD DS

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 Azure AD DS lets you synchronize all users and groups available in
Azure AD, or a scoped synchronization of only specific groups.
For more information about scoped synchronization, see Azure AD

Domain Services scoped synchronization.
notificationSettings If there are any alerts generated in the managed domain, email
notifications can be sent out.
Global administrators of the Azure tenant and members of the AAD

DC Administrators group can be Enabled for these notifications.
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 Azure AD, 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.
A Resource forest only synchronizes users and groups created directly

in Azure AD. Set the value to ResourceTrusting to create a resource
forest.
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.
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 Azure AD:
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')]",
"dependsOn": [
"[concat('Microsoft.Network/virtualNetworks/',
parameters('vnetName'))]"
],
"properties": {
"domainName": "[parameters('domainName')]",
"subnetId": "[concat('/subscriptions/',
'/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')]",
"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,
"protocol": "Tcp",
"sourceAddressPrefix":
"AzureActiveDirectoryDomainServices",
}
},
{
"name": "AllowRD",
"properties": {
"access": "Allow",
"priority": 201,
"protocol": "Tcp",
"sourceAddressPrefix": "CorpNetSaw",
}
}
]
},
"apiVersion": "2018-04-01"
},
{
"type": "Microsoft.Network/virtualNetworks",
"name": "[parameters('vnetName')]",
"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/',
'/providers/Microsoft.Network/NetworkSecurityGroups/',
parameters('nsgName'))]"
}
}
}
]
}
}
],
"outputs": {}
}
This template can be deployed using your preferred deployment method, such as the
Azure portal, Azure PowerShell, or a CI/CD pipeline. The following example uses the
New-AzResourceGroupDeployment cmdlet. Specify your own resource group name and
template filename:
PowerShell
New-AzResourceGroupDeployment -ResourceGroupName "myResourceGroup" -

TemplateFile <path-to-template>
Next steps
To see the managed domain in action, you can domain-join a Windows VM, configure
secure LDAP, and configure password hash sync.
Configure scoped synchronization from
Azure AD to Azure Active Directory
Domain Services using Azure AD
PowerShell
Article • 01/30/2023
To provide authentication services, Azure Active Directory Domain Services (Azure AD

DS) synchronizes users and groups from Azure AD. In a hybrid environment, users and
groups from an on-premises Active Directory Domain Services (AD DS) environment can
be first synchronized to Azure AD using Azure AD Connect, and then synchronized to
Azure AD DS.
By default, all users and groups from an Azure AD directory are synchronized to an
Azure AD DS 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 Azure portal.
Before you begin

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

If needed, complete the tutorial to create and configure an Azure Active
Directory Domain Services managed domain.
your tenant to change the Azure AD DS synchronization scope.
Scoped synchronization overview
By default, all users and groups from an Azure AD 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:
A full synchronization occurs.

Objects that are no longer required in the managed domain are deleted. New
objects are created in the managed domain.
To learn more about the synchronization process, see Understand synchronization in

Azure AD Domain Services.
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 Azure AD DS to synchronize selected groups from Azure AD. 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
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 Azure AD DS resource, then update the
managed domain.
When prompted, specify the credentials for a global admin to sign in to your Azure
AD tenant using the 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
2. 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 Azure AD
tenant using the Connect-AzureAD cmdlet:
PowerShell
.\Select-GroupsToSync.ps1 -groupsToAdd @("AAD DC Administrators",

"GroupName1", "GroupName3")
Disable scoped synchronization

To disable group-based scoped synchronization for a managed domain, set
"filteredSync" = "Disabled" on the Azure AD DS resource, then update the managed
domain. When complete, all users and groups are set to synchronize from Azure AD.
When prompted, specify the credentials for a global admin to sign in to your Azure AD
tenant using the Connect-AzureAD cmdlet:
PowerShell
# Connect to your Azure AD tenant

Connect-AzureAD
# Retrieve the Azure AD DS resource.

# Disable group-based scoped synchronization.

$disableScopedSync = @{"filteredSync" = "Disabled"}
# Update the Azure AD DS resource

$disableScopedSync
Next steps
Create an Azure Active Directory
Domain Services forest trust to an on-
premises domain using Azure
PowerShell
Article • 04/03/2023
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 Azure Active Directory Domain Services (Azure AD DS) 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
Azure AD DS managed domain. In this case, on-premises password hashes are never
synchronized.
In this article, you learn how to:
＂ Create an Azure AD DS 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
） 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



AzAccount cmdlet.

cmdlet.

DS resources.

In this article, you create and configure the outbound forest trust from a managed
domain using the Azure portal. To get started, first sign in to the Azure portal .
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.

2. Create a managed domain forest.
3. Create hybrid network connectivity using site-to-site VPN or Express Route.
4. Create the managed domain side of the trust relationship.
5. 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. You can't change the managed domain forest name once it's
deployed.
Create the Azure AD service principal

Azure AD DS requires a service principal synchronize data from Azure AD. This principal
must be created in your Azure AD tenant before you created the managed domain
forest.
Create an Azure AD service principal for Azure AD DS 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 an Azure AD service principal using the New-AzureADServicePrincipal cmdlet:
PowerShell
New-AzureADServicePrincipal -AppId "6ba9a5d4-8456-4118-b521-9c5ca10cdf84"

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 and are digitally signed by the Azure AD engineering team.
1. First, create a resource group using the 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:
Azure PowerShell
-Name "myResourceGroup" `
-Location "WestUS"
2. Install the New-AaddsResourceForestTrust script from the PowerShell Gallery

using the Install-Script cmdlet:
PowerShell
Install-Script -Name New-AaddsResourceForestTrust
3. 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 Azure AD DS billing.

You can get the list of subscriptions using the
Get-AzureRMSubscription cmdlet.
Resource - Name of the resource group for the

Group aaddsResourceGroupName managed domain and associated resources.
Location -aaddsLocation The Azure region to host your managed

domain. For available regions, see supported
regions for Azure AD DS.
Azure AD DS -aaddsAdminUser The user principal name of the first managed

administrator domain administrator. This account must be
an existing cloud user account in your Azure
Active Directory. The user, and the user
running the script, is added to the AAD DC
Administrators group.
Azure AD DS -aaddsDomainName The FQDN of the managed domain, based

domain name on the previous guidance on how to choose
a forest name.
The New-AzureAaddsForest script can create the Azure virtual network and Azure
AD DS subnet if these resources don't already exist. The script can optionally
create the workload subnets, when specified:
Virtual -aaddsVnetName Name of the virtual network for the

network managed domain.
name
Address -aaddsVnetCIDRAddressSpace Virtual network's address range in CIDR

space notation (if creating the virtual
network).
Azure AD -aaddsSubnetName Name of the subnet of the

DS subnet aaddsVnetName virtual network
name hosting the managed domain. Don't
deploy your own VMs and workloads
into this subnet.
Azure AD -aaddsSubnetCIDRAddressRange Subnet address range in CIDR notation

DS address for the Azure AD DS instance, such as
range 192.168.1.0/24. Address range must be
contained by the address range of the
virtual network, and different from
other subnets.
Workload -workloadSubnetName Optional name of a subnet in the

subnet aaddsVnetName virtual network to
name create for your own application
(optional) workloads. VMs and applications and
also be connected to a peered Azure
virtual network instead.
Workload - Optional subnet address range in CIDR

address workloadSubnetCIDRAddressRange notation for application workload, such
range as 192.168.2.0/24. Address range must
(optional) be contained by the address range of
the virtual network, and different from
other subnets.
4. 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.
Azure PowerShell
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 Azure AD 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.
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 ExpressRoute Overview.
） 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.
2. 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 then
install the core AD DS management tools 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.
3. 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 .
4. In the Azure portal, search for and select Azure AD 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 and then enable
user accounts for Azure AD DS to finalize the configurations for your managed
domain.
5. 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.
6. Restart the management VM for it to receive the new DNS settings, then join the
7. 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 using the Install-Script cmdlet:
PowerShell
Install-Script -Name Add-AaddsResourceForestTrust
Now provide the script the following information:
Azure AD DS - FQDN of the managed domain, such as

domain name ManagedDomainFqdn aaddscontoso.com
On-premises AD -TrustFqdn The FQDN of the trusted forest, such as

DS domain name onprem.contoso.com
Trust friendly -TrustFriendlyName Friendly name of the trust relationship.

name
On-premises AD -TrustDnsIPs A comma-delimited list of DNS server IPv4 addresses

DS DNS IP for the trusted domain listed.
addresses
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:.
Azure PowerShell
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

2. Right-select DNS server, such as myAD01, select Properties
3. Choose Forwarders, then Edit to add additional forwarders.
4. Add the IP addresses of the managed domain, such as 10.0.1.4 and 10.0.1.5.
5. 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 Azure portal.
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

2. Right-select domain, such as onprem.contoso.com, select Properties
3. Choose Trusts tab, then New Trust
4. Enter the name of the managed domain, such as aaddscontoso.com, then select
Next
5. Select the option to create a Forest trust, then to create a One way: incoming
trust.
6. Choose to create the trust for This domain only. In the next step, you create the
trust in the Azure portal for the managed domain.
7. Choose to use Forest-wide authentication, then enter and confirm a trust
password. This same password is also entered in the Azure portal in the next
section.
8. 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.
9. 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 Azure AD DS forest

Access resources in the Azure AD DS forest as an on-premises user
On-premises user authentication from the Azure AD DS

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 Azure AD Domain Services, you can
use the Azure Bastion Host Service in supported Azure regions.
2. Open a command prompt and use the whoami command to show the
distinguished name of the currently authenticated user:
Console
whoami /fqdn
3. 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
4. If the authentication is a successful, a new command prompt opens. The title of the
new command prompt includes running as userUpn@trusteddomain.com .
5. Use whoami /fqdn in the new command prompt to view the distinguished name of
the authenticated user from the on-premises Active Directory.
Access resources in Azure AD DS 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.
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 Azure AD Domain Services, you can
use the Azure Bastion Host Service in supported Azure regions.
2. Open Windows Settings, then search for and select Network and Sharing Center.
3. Choose the option for Change advanced sharing settings.
4. Under the Domain Profile, select Turn on file and printer sharing and then Save
changes.
5. Close Network and Sharing Center.

1. Open Active Directory Users and Computers.
2. Right-select the domain name, choose New, and then select Organizational Unit.
3. In the name box, type LocalObjects, then select OK.
4. Select and right-click LocalObjects in the navigation pane. Select New and then
Group.
5. Type FileServerAccess in the Group name box. For the Group Scope, select Domain
local, then choose OK.
6. In the content pane, double-click FileServerAccess. Select Members, choose to

Add, then select Locations.
7. Select your on-premises Active Directory from the Location view, then choose OK.
8. 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.
9. 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.

1. On the Windows Server VM joined to the managed domain, create a folder and
provide name such as CrossForestShare.
2. Right-select the folder and choose Properties.
3. Select the Security tab, then choose Edit.
4. In the Permissions for CrossForestShare dialog box, select Add.
5. Type FileServerAccess in Enter the object names to select, then select OK.
6. 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.
7. Select the Sharing tab, then choose Advanced Sharing…
8. Choose Share this folder, then enter a memorable name for the file share in Share
name such as CrossForestShare.
9. Select Permissions. In the Permissions for Everyone list, choose Allow for the
Change permission.
10. Select OK two times and then Close.

1. Sign in a Windows computer joined to your on-premises Active Directory using a
user account from your on-premises Active Directory.
2. Using Windows Explorer, connect to the share you created using the fully qualified
host name and the share such as \\fs1.aaddscontoso.com\CrossforestShare .
3. 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.
4. To validate the read permission, open New Text Document.
5. To validate the modify permission, add text to the file and close Notepad. When
prompted to save changes, choose Save.
6. 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.
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 using the Install-Script cmdlet:
PowerShell
Install-Script -Name Get-AaddsResourceForestTrusts,Set-

AaddsResourceForestTrust
2. 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 `
-TrustFriendlyName "myAzureADDSTrust"
3. 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

using the Install-Script cmdlet:
PowerShell
Install-Script -Name Remove-AaddsResourceForestTrust
2. 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 `
-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.

2. Right-select domain, such as onprem.contoso.com, select Properties.
3. Choose Trusts tab, then select the existing incoming trust from your managed
domain forest.
4. Select Remove, then confirm that you wish to remove the incoming trust.
Next steps
In this article, you learned how to:
＂ 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
For more conceptual information about forest types in Azure AD DS, see How do forest
trusts work in Azure AD DS?
Management concepts for user
accounts, passwords, and administration
in Azure Active Directory Domain
Services
Article • 04/03/2023
When you create and run an Azure Active Directory Domain Services (AD DS) managed
domain, there are some differences in behavior compared to a traditional on-premises
AD DS environment. You use the same administrative tools in Azure AD DS 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 Azure AD, 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 Azure AD. This includes cloud-only
user accounts created directly in Azure AD, and hybrid user accounts synchronized
from an on-premises AD DS environment using Azure AD Connect.
The majority of user accounts in a managed domain are created through the
synchronization process from Azure AD.
The user account can be manually created in a managed domain, and doesn't exist
in Azure AD.
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 Azure AD, user accounts created in the
managed domain aren't synchronized back to Azure AD.
Password policy
Azure AD DS includes a default password policy that defines settings for things like
account lockout, maximum password age, and password complexity. Settings like
account lockout policy apply to all users in a managed domain, regardless of how the
user was created as outlined in the previous section. A few settings, like minimum
password length and password complexity, only apply to users created directly in a
managed domain.
You can create your own custom password policies to override the default policy in a
managed domain. These custom policies can then be applied to specific groups of users
as needed.
For more information on the differences in how password policies are applied
depending on the source of user creation, see Password and account lockout policies on
managed domains.
Password hashes
the managed domain. 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.
For users synchronized from an on-premises AD DS environment using Azure AD

Connect, enable synchronization of password hashes.
） Important
Azure AD Connect only synchronizes legacy password hashes when you enable
Azure AD DS for your Azure AD tenant. Legacy password hashes aren't used if you
only use Azure AD Connect to synchronize an on-premises AD DS environment
with Azure AD.
If your legacy applications don't use NTLM authentication or LDAP simple binds, we
recommend that you disable NTLM password hash synchronization for Azure AD
DS. For more information, see Disable weak cipher suites and NTLM credential
hash synchronization.
Once appropriately configured, the usable password hashes are stored in the managed
domain. If you delete the managed domain, any password hashes stored at that point
are also deleted. Synchronized credential information in Azure AD 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 - Azure AD needs to generate and store
the password hashes in the new managed domain. For more information, see Password
hash sync process for Azure AD DS and Azure AD Connect.
） Important
a managed domain to synchronize objects back to Azure AD.
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 Azure AD DS, 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 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. User accounts can directly authenticate against the
managed domain, such as to sign in to a domain-joined VM. A user forest works when
the password hashes can be synchronized and users aren't using exclusive sign-in
methods like smart card authentication.
In an Azure AD DS resource forest, users authenticate over a one-way forest trust from
their on-premises AD DS. With this approach, the user objects and password hashes
aren't synchronized to Azure AD DS. 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.
Azure AD DS SKUs
In Azure AD DS, 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 Azure AD DS 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 Azure AD DS pricing page .
Managed domain performance

Domain performance varies based on how authentication is implemented for an
application. Additional compute resources may help improve query response time and
reduce time spent in sync operations. As the SKU level increases, the compute resources
available to the managed domain is increased. Monitor the performance of your
applications and plan for the required resources.
If your business or application demands change and you need additional compute
power for your managed domain, you can switch to a different SKU.
Backup frequency
The backup frequency determines how often a snapshot of the managed domain is
taken. Backups are an automated process managed by the Azure platform. In the event
of an issue with your managed domain, Azure support can assist you in restoring from
backup. As synchronization only occurs one way from Azure AD, any issues in a
managed domain won't impact Azure AD 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 an Azure AD DS managed domain.
Common use-cases and scenarios for
Article • 01/30/2023
services such as domain join, group policy, lightweight directory access protocol (LDAP),
and Kerberos / NTLM authentication. Azure AD DS integrates with your existing Azure
AD 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 Azure AD DS 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.
Azure AD DS 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, Azure AD DS reduces the complexity to create an
integrated identity solution for both hybrid and cloud-only environments.
Compare Azure AD DS with Azure AD and self-managed AD DS on Azure VMs or

on-premises
Azure AD DS 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 an Azure AD tenant. Azure AD DS 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 Azure
AD tenant, Litware Corporation deploys Azure AD Connect.
Identity information that is synchronized includes user accounts and group
memberships.
Litware's IT team enables Azure AD DS for their Azure AD tenant in this, or a
peered, virtual network.
Applications and VMs deployed in the Azure virtual network can then use Azure
AD DS features like domain join, LDAP read, LDAP bind, NTLM and Kerberos
authentication, and Group Policy.
） Important
Azure AD DS for cloud-only organizations

A cloud-only Azure AD tenant doesn't have an on-premises identity source. User
accounts and group memberships, for example, are created and managed directly in
Azure AD.
Now let's look at an example for Contoso, a cloud-only organization that uses Azure AD
for identity. All user identities, their credentials, and group memberships are created and
managed in Azure AD. There is no additional configuration of Azure AD 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 Azure AD DS for their Azure AD tenant in this, or a
peered, virtual network.
Applications and VMs deployed in the Azure virtual network can then use Azure
AD DS 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 an Azure AD DS 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.
Azure AD DS 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.
Azure AD DS uses a built-in GPO each for the users and computers containers. For
additional control, you can create custom GPOs and target them to custom OUs.
Azure AD DS 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, Azure AD DS 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
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 Azure AD's self-service password change
mechanism 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, Azure AD DS 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
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 Azure AD DS.
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,
Azure AD DS 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
Azure AD 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 Azure AD using Azure AD Connect.
Deployment notes
Make sure that the applications use a username and password for authentication.
Certificate or smartcard-based authentication isn't supported by Azure AD DS.
You can't change passwords directly against a managed domain. End users can
change their password either using Azure AD's self-service password change
mechanism 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 Azure AD DS to provide managed domain services to remote desktop
servers deployed in Azure.
For more information about this deployment scenario, see how to integrate Azure AD
Domain Services with your RDS deployment.
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
Next steps
To get started, Create and configure an Azure Active Directory Domain Services
managed domain.
Replica sets concepts and features for
Article • 01/30/2023
When you create an Azure Active Directory Domain Services (Azure AD DS) 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 Azure AD
tenant. Replica sets can be added to any peered virtual network in any Azure region that
supports Azure AD DS. 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 Azure AD DS, 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 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 Azure AD. 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. 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 an Azure AD DS managed domain.
When deployed, create and use additional replica sets.
How trust relationships work for forests
in Active Directory
Article • 04/03/2023
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
Azure AD DS 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 Azure AD DS, see Forest concepts and features.
To get started using trusts in Azure AD DS, create a managed domain that uses forest
trusts.
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
Azure AD 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 Azure AD 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 Azure AD 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 Azure AD Domain Services is created in
the Azure portal. 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
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 Azure AD DS, 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 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 an Azure AD DS managed domain. You can then Create an outbound forest
trust to an on-premises domain.
How objects and credentials are
synchronized in an Azure Active
Directory Domain Services managed
domain
Article • 04/03/2023
Objects and credentials in an Azure Active Directory Domain Services (Azure AD DS)
managed domain can either be created locally within the domain, or synchronized from
an Azure Active Directory (Azure AD) tenant. When you first deploy Azure AD DS, an
automatic one-way synchronization is configured and started to replicate the objects
from Azure AD. This one-way synchronization continues to run in the background to
keep the Azure AD DS managed domain up-to-date with any changes from Azure AD.
No synchronization occurs from Azure AD DS back to Azure AD.
In a hybrid environment, objects and credentials from an on-premises AD DS domain

can be synchronized to Azure AD using Azure AD Connect. Once those objects are
successfully synchronized to Azure AD, 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 Azure AD DS,
Azure AD, and an optional on-premises AD DS environment:
Synchronization from Azure AD to Azure AD DS

User accounts, group memberships, and credential hashes are synchronized one way
from Azure AD to Azure AD DS. 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 Azure AD directory. After the initial synchronization is complete, changes
that are made in Azure AD, such as password or attribute changes, are then
automatically synchronized to Azure AD DS.
When a user is created in Azure AD, they're not synchronized to Azure AD DS until they
change their password in Azure AD. This password change process causes the password
hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD.
The password hashes are needed to successfully authenticate a user in Azure AD DS.
The synchronization process is one-way by design. There's no reverse synchronization of

changes from Azure AD DS back to Azure AD. A managed domain is largely read-only
except for custom OUs that you can create. You can't make changes to user attributes,
user passwords, or group memberships within a managed domain.
Scoped synchronization and group filter

You can scope synchronization to only user accounts that originated in the cloud. Within
that synchronization scope, you can filter for specific groups or users. You can choose
between cloud only groups, on-premises groups, or both. For more information about
how to configure scoped synchronization, see Configure scoped synchronization.
Attribute synchronization and mapping to
Azure AD DS
The following table lists some common attributes and how they're synchronized to
Azure AD DS.
Attribute in Source Notes

Azure AD DS
UPN User's UPN The UPN attribute from the Azure AD tenant is
attribute in synchronized as-is to Azure AD DS. The most reliable way
Azure AD to sign in to a managed domain is using the UPN.
tenant
SAMAccountName User's The SAMAccountName attribute is sourced from the

mailNickname mailNickname attribute in the Azure AD tenant. If multiple
attribute in user accounts have the same mailNickname attribute, the
Azure AD SAMAccountName is autogenerated. If the user's
tenant or mailNickname or UPN prefix is longer than 20 characters,
autogenerated the SAMAccountName is autogenerated to meet the 20
character limit on SAMAccountName attributes.
Passwords User's Legacy password hashes required for NTLM or Kerberos

password from authentication are synchronized from the Azure AD
the Azure AD tenant. If the Azure AD tenant is configured for hybrid
tenant synchronization using Azure AD Connect, these password
hashes are sourced from the on-premises AD DS
environment.
Primary Autogenerated The primary SID for user/group accounts is autogenerated

user/group SID in Azure AD DS. 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 On-premises The SidHistory attribute for users and groups in Azure AD
users and groups primary user DS is set to match the corresponding primary user or
and group SID group SID in an on-premises AD DS environment. This
feature helps make lift-and-shift of on-premises
applications to Azure AD DS 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 Azure AD are
synchronized to corresponding attributes in Azure AD DS.
User attribute in Azure User attribute in Azure AD DS

AD
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
User attribute in Azure User attribute in Azure AD DS
AD
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 Azure AD are
synchronized to corresponding attributes in Azure AD DS.
Group attribute in Azure AD Group attribute in Azure AD DS
displayName displayName
displayName SAMAccountName (may sometimes be autogenerated)
mail mail
mailNickname msDS-AzureADMailNickname
objectid msDS-AzureADObjectId
onPremiseSecurityIdentifier sidHistory
proxyAddresses proxyAddresses
securityEnabled groupType
Synchronization from on-premises AD DS to
Azure AD and Azure AD DS
Azure AD Connect is used to synchronize user accounts, group memberships, and
credential hashes from an on-premises AD DS environment to Azure AD. Attributes of
user accounts such as the UPN and on-premises security identifier (SID) are
synchronized. To sign in using Azure AD DS, legacy password hashes required for NTLM
and Kerberos authentication are also synchronized to Azure AD.
） Important
If you configure writeback, changes from Azure AD are synchronized back to the on-
premises AD DS environment. For example, if a user changes their password using Azure
AD self-service password management, the password is updated back in the on-
７ Note
Always use the latest version of Azure AD 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. Azure AD Connect supports synchronizing users, groups, and credential
hashes from multi-forest environments to Azure AD.
Azure AD has a much simpler and flat namespace. To enable users to reliably access
applications secured by Azure AD, resolve UPN conflicts across user accounts in
different forests. Managed domains use a flat OU structure, similar to Azure AD. 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 Azure AD DS back to Azure AD.
You can create a custom Organizational Unit (OU) in Azure AD DS and then users,
groups, or service accounts within those custom OUs. None of the objects created in
custom OUs are synchronized back to Azure AD. These objects are available only within
the managed domain, and aren't visible using Azure AD PowerShell cmdlets, Microsoft
Graph API, or using the Azure AD management UI.
What isn't synchronized to Azure AD DS

The following objects or attributes aren't synchronized from an on-premises AD DS
environment to Azure AD or Azure AD DS:
Excluded attributes: You can choose to exclude certain attributes from

synchronizing to Azure AD from an on-premises AD DS environment using Azure
AD Connect. These excluded attributes aren't then available in Azure AD DS.
Group Policies: Group Policies configured in an on-premises AD DS environment
aren't synchronized to Azure AD DS.
Sysvol folder: The contents of the Sysvol folder in an on-premises AD DS
environment aren't synchronized to Azure AD DS.
Computer objects: Computer objects for computers joined to an on-premises AD
DS environment aren't synchronized to Azure AD DS. These computers don't have
a trust relationship with the managed domain and only belong to the on-premises
AD DS environment. In Azure AD DS, 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 Azure AD DS.
However, existing SidHistory attributes for users and groups aren't synchronized
from the on-premises AD DS environment to Azure AD DS.
Organization Units (OU) structures: Organizational Units defined in an on-
premises AD DS environment don't synchronize to Azure AD DS. There are two
built-in OUs in Azure AD DS - one for users, and one for computers. The managed
domain has a flat OU structure. You can choose to create a custom OU in your
managed domain.
Password hash synchronization and security

considerations
When you enable Azure AD DS, legacy password hashes for NTLM and Kerberos
authentication are required. Azure AD 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 Azure AD.
The encryption keys are unique to each Azure AD tenant. These hashes are encrypted
such that only Azure AD DS has access to the decryption keys. No other service or
component in Azure AD has access to the decryption keys.
Legacy password hashes are then synchronized from Azure AD into the domain
controllers for a managed domain. The disks for these managed domain controllers in
Azure AD DS 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-
For cloud-only Azure AD environments, users must reset/change their password in order
for the required password hashes to be generated and stored in Azure AD. For any
cloud user account created in Azure AD after enabling Azure AD 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 Azure AD DS.
For hybrid user accounts synced from on-premises AD DS environment using Azure AD
Connect, you must configure Azure AD Connect to synchronize password hashes in the
NTLM and Kerberos compatible formats.
Next steps
For more information on the specifics of password synchronization, see How password
hash synchronization works with Azure AD Connect.
To get started with Azure AD DS, create a managed domain.

Implement password hash
synchronization with Azure AD Connect
sync
Article • 05/18/2023
This article provides information that you need to synchronize your user passwords from
an on-premises Active Directory instance to a cloud-based Azure Active Directory (Azure
AD) instance.
How password hash synchronization works

The Active Directory domain service stores passwords in the form of a hash value
representation, of the actual user password. A hash value is a result of a one-way
mathematical function (the hashing algorithm). There is no method to revert the result
of a one-way function to the plain text version of a password.
To synchronize your password, Azure AD Connect sync extracts your password hash
from the on-premises Active Directory instance. Extra security processing is applied to
the password hash before it is synchronized to the Azure Active Directory authentication
service. Passwords are synchronized on a per-user basis and in chronological order.
The actual data flow of the password hash synchronization process is similar to the
synchronization of user data. However, passwords are synchronized more frequently
than the standard directory synchronization window for other attributes. The password
hash synchronization process runs every 2 minutes. You cannot modify the frequency of
this process. When you synchronize a password, it overwrites the existing cloud
password.
The first time you enable the password hash synchronization feature, it performs an
initial synchronization of the passwords of all in-scope users. Staged Rollout allows you
to selectively test groups of users with cloud authentication capabilities like Azure AD
Multi-Factor Authentication (MFA), Conditional Access, Identity Protection for leaked
credentials, Identity Governance, and others, before cutting over your domains. You
cannot explicitly define a subset of user passwords that you want to synchronize.
However, if there are multiple connectors, it is possible to disable password hash sync
for some connectors but not others using the Set-
ADSyncAADPasswordSyncConfiguration cmdlet.
When you change an on-premises password, the updated password is synchronized,
most often in a matter of minutes. The password hash synchronization feature
automatically retries failed synchronization attempts. If an error occurs during an
attempt to synchronize a password, an error is logged in your event viewer.
The synchronization of a password has no impact on the user who is currently signed in.
Your current cloud service session is not immediately affected by a synchronized
password change that occurs, while you are signed in, to a cloud service. However, when
the cloud service requires you to authenticate again, you need to provide your new
password.
A user must enter their corporate credentials a second time to authenticate to Azure AD,
regardless of whether they're signed in to their corporate network. This pattern can be
minimized, however, if the user selects the Keep me signed in (KMSI) check box at sign-
in. This selection sets a session cookie that bypasses authentication for 180 days. KMSI
behavior can be enabled or disabled by the Azure AD administrator. In addition, you can
reduce password prompts by configuring Azure AD join or Hybrid Azure AD join, which
automatically signs users in when they are on their corporate devices connected to your
corporate network.
Additional advantages
Generally, password hash synchronization is simpler to implement than a
federation service. It doesn't require any additional servers, and eliminates
dependence on a highly available federation service to authenticate users.
Password hash synchronization can also be enabled in addition to federation. It
may be used as a fallback if your federation service experiences an outage.
７ Note
Password sync is only supported for the object type user in Active Directory. It is
not supported for the iNetOrgPerson object type.
Detailed description of how password hash

synchronization works
The following section describes, in-depth, how password hash synchronization works
between Active Directory and Azure AD.

1. Every two minutes, the password hash synchronization agent on the AD Connect
server requests stored password hashes (the unicodePwd attribute) from a DC. This
request is via the standard MS-DRSR replication protocol used to synchronize data
between DCs. The service account must have Replicate Directory Changes and
Replicate Directory Changes All AD permissions (granted by default on installation)
to obtain the password hashes.
2. Before sending, the DC encrypts the MD4 password hash by using a key that is a
MD5 hash of the RPC session key and a salt. It then sends the result to the
password hash synchronization agent over RPC. The DC also passes the salt to the
synchronization agent by using the DC replication protocol, so the agent will be
able to decrypt the envelope.
3. After the password hash synchronization agent has the encrypted envelope, it uses
MD5CryptoServiceProvider and the salt to generate a key to decrypt the received
data back to its original MD4 format. The password hash synchronization agent
never has access to the clear text password. The password hash synchronization
agent’s use of MD5 is strictly for replication protocol compatibility with the DC,
and it is only used on-premises between the DC and the password hash
synchronization agent.
4. The password hash synchronization agent expands the 16-byte binary password
hash to 64 bytes by first converting the hash to a 32-byte hexadecimal string, then
converting this string back into binary with UTF-16 encoding.
5. The password hash synchronization agent adds a per user salt, consisting of a 10-
byte length salt, to the 64-byte binary to further protect the original hash.
6. The password hash synchronization agent then combines the MD4 hash plus the
per user salt, and inputs it into the PBKDF2 function. 1000 iterations of the
HMAC-SHA256 keyed hashing algorithm are used. For additional details, refer to
the Azure AD Whitepaper .
7. The password hash synchronization agent takes the resulting 32-byte hash,
concatenates both the per user salt and the number of SHA256 iterations to it (for
use by Azure AD), then transmits the string from Azure AD Connect to Azure AD
over TLS.
8. When a user attempts to sign in to Azure AD and enters their password, the
password is run through the same MD4+salt+PBKDF2+HMAC-SHA256 process. If
the resulting hash matches the hash stored in Azure AD, the user has entered the
correct password and is authenticated.
７ Note
The original MD4 hash is not transmitted to Azure AD. Instead, the SHA256 hash of
the original MD4 hash is transmitted. As a result, if the hash stored in Azure AD is
obtained, it cannot be used in an on-premises pass-the-hash attack.
７ Note
The password hash value is NEVER stored in SQL. These values are only processed
in memory prior to being sent to Azure AD.
Security considerations
When synchronizing passwords, the plain-text version of your password is not exposed
to the password hash synchronization feature, to Azure AD, or any of the associated
services.
User authentication takes place against Azure AD rather than against the organization's
own Active Directory instance. The SHA256 password data stored in Azure AD--a hash
of the original MD4 hash--is more secure than what is stored in Active Directory.
Further, because this SHA256 hash cannot be decrypted, it cannot be brought back to
the organization's Active Directory environment and presented as a valid user password
in a pass-the-hash attack.
Password policy considerations

There are two types of password policies that are affected by enabling password hash
synchronization:
Password complexity policy

Password expiration policy
Password complexity policy
When password hash synchronization is enabled, the password complexity policies in
your on-premises Active Directory instance override complexity policies in the cloud for
synchronized users. You can use all of the valid passwords from your on-premises Active
Directory instance to access Azure AD services.
７ Note
Passwords for users that are created directly in the cloud are still subject to
password policies as defined in the cloud.
Password expiration policy

If a user is in the scope of password hash synchronization, by default the cloud account
password is set to Never Expire.
You can continue to sign in to your cloud services by using a synchronized password
that is expired in your on-premises environment. Your cloud password is updated the
next time you change the password in the on-premises environment.
CloudPasswordPolicyForPasswordSyncedUsersEnabled
If there are synchronized users that only interact with Azure AD integrated services and
must also comply with a password expiration policy, you can force them to comply with
your Azure AD password expiration policy by enabling the
CloudPasswordPolicyForPasswordSyncedUsersEnabled feature (in the deprecated
MSOnline PowerShell module it was called
EnforceCloudPasswordPolicyForPasswordSyncedUsers).
When CloudPasswordPolicyForPasswordSyncedUsersEnabled is disabled (which is the

default setting), Azure AD Connect sets the PasswordPolicies attribute of synchronized
users to "DisablePasswordExpiration". This is done every time a user's password is
synchronized and instructs Azure AD to ignore the cloud password expiration policy for
that user. You can check the value of the attribute using the Azure AD PowerShell
module with the following command:
(Get-MgUser -UserId <User Object ID> -Property PasswordPolicies).PasswordPolicies
To enable the CloudPasswordPolicyForPasswordSyncedUsersEnabled feature, run the

following commands using the Graph PowerShell module as shown below:
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.CloudPasswordPolicyForPasswordSyncedUsersEnabled =
$true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Features
Once enabled, Azure AD does not go to each synchronized user to remove the
DisablePasswordExpiration value from the PasswordPolicies attribute. Instead, the
DisablePasswordExpiration value is removed from PasswordPolicies during the next
password hash sync for each user, upon their next password change in on-premises AD.
After the CloudPasswordPolicyForPasswordSyncedUsersEnabled feature is enabled, new

users are provisioned without a PasswordPolicies value.
 Tip
It is recommended to enable CloudPasswordPolicyForPasswordSyncedUsersEnabled

prior to enabling password hash sync, so that the initial sync of password hashes
does not add the DisablePasswordExpiration value to the PasswordPolicies
attribute for the users.
The default Azure AD password policy requires users to change their passwords every 90
days. If your policy in AD is also 90 days, the two policies should match. However, if the
AD policy is not 90 days, you can update the Azure AD password policy to match by
using the Update-MgDomain PowerShell command (previously: Set-
MsolPasswordPolicy).
Azure AD supports a separate password expiration policy per registered domain.
Caveat: If there are synchronized accounts that need to have non-expiring passwords in
Azure AD, you must explicitly add the DisablePasswordExpiration value to the
PasswordPolicies attribute of the user object in Azure AD. You can do this by running the
following command.
Update-MgUser -UserID <User Object ID> -PasswordPolicies
"DisablePasswordExpiration"
７ Note
For hybrid users that have a PasswordPolicies value set to
DisablePasswordExpiration , this value switches to None after a password change is
executed on-premises.
７ Note
Neither the Update-MgDomain, nor the deprecated Set-MsolPasswordPolicy

PowerShell commands will work on federated domains.
７ Note
Neither the Set-MgUser, nor the deprecated Set-AzureADUser PowerShell

commands will work on federated domains.
Synchronizing temporary passwords and "Force Password Change

on Next Logon"
It is typical to force a user to change their password during their first logon, especially
after an admin password reset occurs. It is commonly known as setting a "temporary"
password and is completed by checking the "User must change password at next logon"
flag on a user object in Active Directory (AD).
The temporary password functionality helps to ensure that the transfer of ownership of
the credential is completed on first use, to minimize the duration of time in which more
than one individual has knowledge of that credential.
To support temporary passwords in Azure AD for synchronized users, you can enable
the ForcePasswordChangeOnLogOn feature, by running the following command on your
Azure AD Connect server:
Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn $true
７ Note
Forcing a user to change their password on next logon requires a password change
at the same time. Azure AD Connect will not pick up the force password change
flag by itself; it is supplemental to the detected password change that occurs
during password hash sync.
If the user has the option "Password never expires" set in Active Directory (AD), the
force password change flag will not be set in Active Directory (AD), so the user will
not be prompted to change the password during the next sign-in.
A new user created in Active Directory with "User must change password at next
logon" flag will always be provisioned in Azure AD with a password policy to "Force
change password on next sign-in", irrespective of the
ForcePasswordChangeOnLogOn feature being true or false. This is an Azure AD
internal logic since the new user is provisioned without a password, whereas
ForcePasswordChangeOnLogOn feature only affects admin password reset
scenarios.
If a user was created in Active Directory with "User must change password at next
logon" before the feature was enabled, the user will receive an error while signing
in. To remediate this issue, un-check and re-check the field "User must change
password at next logon" in Active Directory Users and Computers. After
synchronizing the user object changes, the user will receive the expected prompt in
Azure AD to update their password.
Ｕ Caution
You should only use this feature when SSPR and Password Writeback are enabled
on the tenant. This is so that if a user changes their password via SSPR, it will be
synchronized to Active Directory.
Account expiration
If your organization uses the accountExpires attribute as part of user account
management, this attribute is not synchronized to Azure AD. As a result, an expired
Active Directory account in an environment configured for password hash
synchronization will still be active in Azure AD. We recommend using a scheduled
PowerShell script that disables users' AD accounts, once they expire (use the Set-ADUser
cmdlet). Conversely, during the process of removing the expiration from an AD account,
the account should be re-enabled.
Overwrite synchronized passwords

An administrator can manually reset your password directly in Azure AD by using
Windows PowerShell (unless the user is in a Federated Domain).
In this case, the new password overrides your synchronized password, and all password
policies defined in the cloud are applied to the new password.
If you change your on-premises password again, the new password is synchronized to
the cloud, and it overrides the manually updated password.
The synchronization of a password has no impact on the Azure user who is signed in.
Your current cloud service session is not immediately affected by a synchronized
password change that occurs while you're signed in to a cloud service. KMSI extends the
duration of this difference. When the cloud service requires you to authenticate again,
you need to provide your new password.
Password hash sync process for Azure AD

Domain Services
If you use Azure AD Domain Services to provide legacy authentication for applications
and services that need to use Kerberos, LDAP, or NTLM, some additional processes are
part of the password hash synchronization flow. Azure AD Connect uses the additional
following process to synchronize password hashes to Azure AD for use in Azure AD
Domain Services:
） Important
an Azure AD DS managed domain to synchronize objects back to Azure AD.
Azure AD Connect only synchronizes legacy password hashes when you enable
Azure AD DS for your Azure AD tenant. The following steps aren't used if you only
use Azure AD Connect to synchronize an on-premises AD DS environment with
Azure AD.
If your legacy applications don't use NTLM authentication or LDAP simple binds, we
recommend that you disable NTLM password hash synchronization for Azure AD
DS. For more information, see Disable weak cipher suites and NTLM credential
1. Azure AD Connect retrieves the public key for the tenant's instance of Azure AD
Domain Services.
2. When a user changes their password, the on-premises domain controller stores the
result of the password change (hashes) in two attributes:
unicodePwd for the NTLM password hash.
supplementalCredentials for the Kerberos password hash.
3. Azure AD Connect detects password changes through the directory replication
channel (attribute changes needing to replicate to other domain controllers).
4. For each user whose password has changed, Azure AD Connect performs the
following steps:
Generates a random AES 256-bit symmetric key.

Generates a random initialization vector needed for the first round of
encryption.
Extracts Kerberos password hashes from the supplementalCredentials
attributes.
Checks the Azure AD Domain Services security configuration
SyncNtlmPasswords setting.
If this setting is disabled, generates a random, high-entropy NTLM hash
(different from the user's password). This hash is then combined with the
exacted Kerberos password hashes from the supplementalCrendetials
attribute into one data structure.
If enabled, combines the value of the unicodePwd attribute with the
extracted Kerberos password hashes from the supplementalCredentials
attribute into one data structure.
Encrypts the single data structure using the AES symmetric key.
Encrypts the AES symmetric key using the tenant's Azure AD Domain Services
public key.
5. Azure AD Connect transmits the encrypted AES symmetric key, the encrypted data
structure containing the password hashes, and the initialization vector to Azure AD.
6. Azure AD stores the encrypted AES symmetric key, the encrypted data structure,
and the initialization vector for the user.
7. Azure AD pushes the encrypted AES symmetric key, the encrypted data structure,
and the initialization vector using an internal synchronization mechanism over an
encrypted HTTP session to Azure AD Domain Services.
8. Azure AD Domain Services retrieves the private key for the tenant's instance from
Azure Key vault.
9. For each encrypted set of data (representing a single user's password change),
Azure AD Domain Services then performs the following steps:
Uses its private key to decrypt the AES symmetric key.

Uses the AES symmetric key with the initialization vector to decrypt the
encrypted data structure that contains the password hashes.
Writes the Kerberos password hashes it receives to the Azure AD Domain
Services domain controller. The hashes are saved into the user object's
supplementalCredentials attribute that is encrypted to the Azure AD Domain
Services domain controller's public key.
Azure AD Domain Services writes the NTLM password hash it received to the
Azure AD Domain Services domain controller. The hash is saved into the user
object's unicodePwd attribute that is encrypted to the Azure AD Domain
Services domain controller's public key.
Enable password hash synchronization
） Important
If you are migrating from AD FS (or other federation technologies) to Password

Hash Synchronization, view Resources for migrating applications to Azure AD.
When you install Azure AD Connect by using the Express Settings option, password
hash synchronization is automatically enabled. For more information, see Getting started
with Azure AD Connect using express settings.
If you use custom settings when you install Azure AD Connect, password hash
synchronization is available on the user sign-in page. For more information, see Custom
installation of Azure AD Connect.
Password hash synchronization and FIPS
If your server has been locked down according to Federal Information Processing
Standard (FIPS), then MD5 is disabled.
To enable MD5 for password hash synchronization, perform the following steps:
1. Go to %programfiles%\Microsoft Azure AD Sync\Bin.

2. Open miiserver.exe.config.
3. Go to the configuration/runtime node at the end of the file.
4. Add the following node: <enforceFIPSPolicy enabled="false"/>
5. Save your changes.
6. Reboot for the changes to take effect.
For reference, this snippet is what it should look like:
<configuration>
<runtime>
<enforceFIPSPolicy enabled="false"/>
</runtime>
</configuration>
For information about security and FIPS, see Azure AD password hash sync, encryption,
and FIPS compliance .
Troubleshoot password hash synchronization

If you have problems with password hash synchronization, see Troubleshoot password
Next steps
Azure AD Connect sync: Customizing synchronization options
Integrating your on-premises identities with Azure Active Directory
Resources for migrating applications to Azure AD
Custom attributes for Azure Active
Article • 03/31/2023
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.
Azure AD supports adding custom data to resources using extensions. Azure Active
Directory Domain Services (Azure AD DS) can synchronize the following types of
extensions from Azure AD, so you can also use apps that depend on custom attributes
with Azure AD DS:
onPremisesExtensionAttributes are a set of 15 attributes that can store extended

user string attributes.
Directory extensions allow the schema extension of specific directory objects, such
as users and groups, with strongly typed attributes through registration with an
application in the tenant.
Both types of extensions can be configured by using Azure AD 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 Azure AD (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 the managed domain to Enterprise or Premium. For
more information, see Azure Active Directory Domain Pricing .
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.
Synchronize Azure AD directory extension

attributes
These are the extended user or group attributes defined in your Azure AD 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 Azure AD Connect,

click Enterprise App and look for the Application ID of the Tenant Schema
Extension App. For more information, see Azure AD Connect sync: Directory
extensions.
Click Select, and then Save to confirm the change.
Azure AD DS 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 Azure AD. During the backfill synchronization process,
incremental changes in Azure AD are paused, and the sync time depends on the size of
the tenant.
To check the backfilling status, click Azure AD DS Health and verify the Synchronization
with Azure AD 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 Azure AD, see Custom data options in Microsoft Graph.
To sync onPremisesExtensionAttributes or directory extensions from on-premises to

Azure AD, configure Azure AD Connect.
Virtual network design considerations and configuration
options for Azure Active Directory Domain Services
Article • 08/01/2023
Azure Active Directory Domain Services (Azure AD DS) 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 Azure AD DS. Plan your
virtual network requirements to make sure that Azure AD DS can serve your applications and workloads as needed.
This article outlines design considerations and requirements for an Azure virtual network to support Azure AD DS.
Azure virtual network design

To provide network connectivity and allow applications and services to authenticate against an Azure AD DS 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 Azure AD DS
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 Azure AD DS, the following considerations apply:
Azure AD DS must be deployed into the same Azure region as your virtual network.
At this time, you can only deploy one managed domain per Azure AD tenant. The managed domain is deployed to
single region. Make sure that you create or select a virtual network in a region that supports Azure AD DS .
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.
Azure AD DS 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 Azure AD DS 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 Azure AD DS 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:
Connections to the Azure AD DS 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 Azure AD 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.
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 Azure 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.
Network resources used by Azure AD DS

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 Azure AD DS. 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 Azure AD DS hosts the managed domain on two domain controllers (DCs) that run on Windows Server as Azure
card VMs. Each VM has a virtual network interface that connects to your virtual network subnet.
Dynamic standard Azure AD DS communicates with the synchronization and management service using a Standard SKU public IP
public IP address address. For more information about public IP addresses, see IP address types and allocation methods in Azure.
Azure standard load Azure AD DS uses a Standard SKU load balancer for network address translation (NAT) and load balancing (when
balancer used with secure LDAP). For more information about Azure load balancers, see What is Azure Load Balancer?
Network address Azure AD DS creates and uses two Inbound NAT rules on the load balancer for secure PowerShell remoting. If a
translation (NAT) rules 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 Azure AD DS, such as manually configuring the load
balancer or rules. If you delete or modify any of the network resources, an Azure AD DS service outage may occur.
Network security groups and required ports

A network security group (NSG) 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 Destination Service Destination Protocol Action Required Purpose
port port
ranges ranges
Service AzureActiveDirectoryDomainServices * Any WinRM 5986 TCP Allow Yes Management

tag of your
domain.
Service CorpNetSaw * Any RDP 3389 TCP Allow Optional Debugging

tag for support
Note that the CorpNetSaw service tag isn't available by using Azure portal, and the network security group rule for
CorpNetSaw has to be added by using PowerShell.
Azure AD DS 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.
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 Azure AD DS 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.
２ 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 Azure AD 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
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. 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 Protocol Source Destination Action Required Purpose

port number
443 TCP Any AzureActiveDirectoryDomainServices Allow Yes Communication with the Azure AD
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 AzureActiveDirectory Allow Yes Communication with Azure Active
Directory.
443 TCP Any AzureUpdateDelivery Allow Yes Communication with Windows

Update.
80 TCP Any AzureFrontDoor.FirstParty Allow Yes Download of patches from Windows

Update.
Outbound Protocol Source Destination Action Required Purpose
port number
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 Azure AD DS 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 Azure AD DS 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 .
Ｕ 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 Azure AD DS, see the
following articles:
Azure virtual network peering

Azure VPN gateways
Azure network security groups
What is Azure Active Directory?
Article • 08/02/2023
Azure Active Directory (Azure AD) is a cloud-based identity and access management
service. Azure AD enables your employees access external resources, such as Microsoft
365, the Azure portal, and thousands of other SaaS applications. Azure Active Directory
also helps them access internal resources like apps on your corporate intranet, and any
cloud apps developed for your own organization. To learn how to create a tenant, see
Quickstart: Create a new tenant in Azure Active Directory.
To learn the differences between Active Directory and Azure Active Directory, see
Compare Active Directory to Azure Active Directory. You can also refer Microsoft Cloud
for Enterprise Architects Series posters to better understand the core identity services in
Azure like Azure AD and Microsoft-365.
Who uses Azure AD?

Azure AD provides different benefits to members of your organization based on their
role:
IT admins use Azure AD to control access to apps and app resources, based on
business requirements. For example, as an IT admin, you can use Azure AD to
require multi-factor authentication when accessing important organizational
resources. You could also use Azure AD to automate user provisioning between
your existing Windows Server AD and your cloud apps, including Microsoft 365.
Finally, Azure AD gives you powerful tools to automatically help protect user
identities and credentials and to meet your access governance requirements. To
get started, sign up for a free 30-day Azure Active Directory Premium trial .
App developers can use Azure AD as a standards-based authentication provider

that helps them add single sign-on (SSO) to apps that works with a user's existing
credentials. Developers can also use Azure AD APIs to build personalized
experiences using organizational data. To get started, sign up for a free 30-day
Azure Active Directory Premium trial . For more information, you can also see
Azure Active Directory for developers.
Microsoft 365, Office 365, Azure, or Dynamics CRM Online subscribers already
use Azure AD as every Microsoft 365, Office 365, Azure, and Dynamics CRM Online
tenant is automatically an Azure AD tenant. You can immediately start managing
access to your integrated cloud apps.
What are the Azure AD licenses?
Microsoft Online business services, such as Microsoft 365 or Microsoft Azure, use Azure
AD for sign-in activities and to help protect your identities. If you subscribe to any
Microsoft Online business service, you automatically get access to Azure AD free .
To enhance your Azure AD implementation, you can also add paid features by
upgrading to Azure Active Directory Premium P1 or Premium P2 licenses. Azure AD paid
licenses are built on top of your existing free directory. The licenses provide self-service,
enhanced monitoring, security reporting, and secure access for your mobile users.
７ Note
For the pricing options of these licenses, see Azure Active Directory Pricing .
For more information about Azure AD pricing, contact the Azure Active Directory
Forum .
Azure Active Directory Free. Provides user and group management, on-premises
directory synchronization, basic reports, self-service password change for cloud
users, and single sign-on across Azure, Microsoft 365, and many popular SaaS
apps.
Azure Active Directory Premium P1. In addition to the Free features, P1 also lets
your hybrid users access both on-premises and cloud resources. It also supports
advanced administration, such as dynamic groups, self-service group management,
Microsoft Identity Manager, and cloud write-back capabilities, which allow self-
service password reset for your on-premises users.
Azure Active Directory Premium P2. In addition to the Free and P1 features, P2
also offers Azure Active Directory Identity Protection to help provide risk-based
Conditional Access to your apps and critical company data and Privileged Identity
Management to help discover, restrict, and monitor administrators and their access
to resources and to provide just-in-time access when needed.
"Pay as you go" feature licenses. You can also get licenses for features such as,
Azure Active Directory Business-to-Customer (B2C). B2C can help you provide
identity and access management solutions for your customer-facing apps. For
more information, see Azure Active Directory B2C documentation.
For more information about associating an Azure subscription to Azure AD, see
Associate or add an Azure subscription to Azure Active Directory. For more information
about assigning licenses to your users, see How to: Assign or remove Azure Active
Directory licenses.
Which features work in Azure AD?

After you choose your Azure AD license, you'll get access to some or all of the following
features:
Category Description
Application Manage your cloud and on-premises apps using Application Proxy, single
management sign-on, the My Apps portal, and Software as a Service (SaaS) apps. For
more information, see How to provide secure remote access to on-
premises applications and Application Management documentation.
Authentication Manage Azure Active Directory self-service password reset, Multi-Factor

Authentication, custom banned password list, and smart lockout. For more
information, see Azure AD Authentication documentation.
Azure Active Build apps that sign in all Microsoft identities, get tokens to call Microsoft
Directory for Graph, other Microsoft APIs, or custom APIs. For more information, see
developers Microsoft identity platform (Azure Active Directory for developers).
Business-to- Manage your guest users and external partners, while maintaining control
Business (B2B) over your own corporate data. For more information, see Azure Active
Directory B2B documentation.
Business-to- Customize and control how users sign up, sign in, and manage their
Customer (B2C) profiles when using your apps. For more information, see Azure Active
Directory B2C documentation.
Conditional Access Manage access to your cloud apps. For more information, see Azure AD
Conditional Access documentation.
Device Manage how your cloud or on-premises devices access your corporate
Management data. For more information, see Azure AD Device Management
documentation.
Domain services Join Azure virtual machines to a domain without using domain controllers.
For more information, see Azure AD Domain Services documentation.
Enterprise users Manage license assignments, access to apps, and set up delegates using
groups and administrator roles. For more information, see Azure Active
Directory user management documentation.
Hybrid identity Use Azure Active Directory Connect and Connect Health to provide a single
user identity for authentication and authorization to all resources,
regardless of location (cloud or on-premises). For more information, see
Hybrid identity documentation.
Category Description
Identity governance Manage your organization's identity through employee, business partner,
vendor, service, and app access controls. You can also perform access
reviews. For more information, see Azure AD identity governance
documentation and Azure AD access reviews.
Identity protection Detect potential vulnerabilities affecting your organization's identities,

configure policies to respond to suspicious actions, and then take
appropriate action to resolve them. For more information, see Azure AD
Identity Protection.
Managed identities Provide your Azure services with an automatically managed identity in
for Azure resources Azure AD that can authenticate any Azure AD-supported authentication
service, including Key Vault. For more information, see What is managed
identities for Azure resources?.
Privileged identity Manage, control, and monitor access within your organization. This feature
management (PIM) includes access to resources in Azure AD and Azure, and other Microsoft
Online Services, like Microsoft 365 or Intune. For more information, see
Azure AD Privileged Identity Management.
Reports and Gain insights into the security and usage patterns in your environment. For
monitoring more information, see Azure Active Directory reports and monitoring.
Workload identities Give an identity to your software workload (such as an application, service,
script, or container) to authenticate and access other services and
resources. For more information, see workload identities faqs.
Terminology
To better understand Azure AD and its documentation, we recommend reviewing the
following terms.
Term or Description
concept
Identity A thing that can get authenticated. An identity can be a user with a username
and password. Identities also include applications or other servers that might
require authentication through secret keys or certificates.
Account An identity that has data associated with it. You can’t have an account without
an identity.
Azure AD An identity created through Azure AD or another Microsoft cloud service, such
account as Microsoft 365. Identities are stored in Azure AD and accessible to your
organization's cloud service subscriptions. This account is also sometimes
called a Work or school account.
Term or Description
concept
Account This classic subscription administrator role is conceptually the billing owner of
Administrator a subscription. This role enables you to manage all subscriptions in an account.
For more information, see Azure roles, Azure AD roles, and classic subscription
administrator roles.
Service This classic subscription administrator role enables you to manage all Azure
Administrator resources, including access. This role has the equivalent access of a user who is
assigned the Owner role at the subscription scope. For more information, see
Azure roles, Azure AD roles, and classic subscription administrator roles.
Owner This role helps you manage all Azure resources, including access. This role is
built on a newer authorization system called Azure role-based access control
(Azure RBAC) that provides fine-grained access management to Azure
resources. For more information, see Azure roles, Azure AD roles, and classic
subscription administrator roles.
Azure AD This administrator role is automatically assigned to whomever created the

Global Azure AD tenant. You can have multiple Global administrators, but only Global
administrator administrators can assign administrator roles (including assigning other Global
administrators) to users. For more information about the various administrator
roles, see Administrator role permissions in Azure Active Directory.
Azure Used to pay for Azure cloud services. You can have many subscriptions and
subscription they're linked to a credit card.
Azure tenant A dedicated and trusted instance of Azure AD. The tenant is automatically
created when your organization signs up for a Microsoft cloud service
subscription. These subscriptions include Microsoft Azure, Microsoft Intune, or
Microsoft 365. An Azure tenant represents a single organization.
Single tenant Azure tenants that access other services in a dedicated environment are
considered single tenant.
Multi-tenant Azure tenants that access other services in a shared environment, across
multiple organizations, are considered multi-tenant.
Azure AD Each Azure tenant has a dedicated and trusted Azure AD directory. The Azure
directory AD directory includes the tenant's users, groups, and apps and is used to
perform identity and access management functions for tenant resources.
Custom domain Every new Azure AD directory comes with an initial domain name, for example
domainname.onmicrosoft.com . In addition to that initial name, you can also add
your organization's domain names. Your organization's domain names include
the names you use to do business and your users use to access your
organization's resources, to the list. Adding custom domain names helps you
to create user names that are familiar to your users, such as
alain@contoso.com.
Term or Description
concept
Microsoft Personal accounts that provide access to your consumer-oriented Microsoft

account (also products and cloud services. These products and services include Outlook,
called, MSA) OneDrive, Xbox LIVE, or Microsoft 365. Your Microsoft account is created and
stored in the Microsoft consumer identity account system that's run by
Microsoft.
Next steps
Sign up for Azure Active Directory Premium
Associate an Azure subscription to your Azure Active Directory
Azure Active Directory Premium P2 feature deployment checklist

What is the Azure Active Directory
architecture?
Article • 07/28/2023
Azure Active Directory (Azure AD) enables you to securely manage access to Azure
services and resources for your users. Included with Azure AD is a full suite of identity
management capabilities. For information about Azure AD features, see What is Azure
Active Directory?
With Azure AD, you can create and manage users and groups, and enable permissions
to allow and deny access to enterprise resources. For information about identity
management, see The fundamentals of Azure identity management.
Azure AD architecture
Azure AD's geographically distributed architecture combines extensive monitoring,
automated rerouting, failover, and recovery capabilities, which deliver company-wide
availability and performance to customers.
The following architecture elements are covered in this article:
Service architecture design

Scalability
Continuous availability
Datacenters
Service architecture design

The most common way to build an accessible and usable, data-rich system is through
independent building blocks or scale units. For the Azure AD data tier, scale units are
called partitions.
The data tier has several front-end services that provide read-write capability. The
diagram below shows how the components of a single-directory partition are delivered
throughout geographically distributed datacenters.
The components of Azure AD architecture include a primary replica and secondary
replicas.
Primary replica
The primary replica receives all writes for the partition it belongs to. Any write operation
is immediately replicated to a secondary replica in a different datacenter before
returning success to the caller, thus ensuring geo-redundant durability of writes.
Secondary replicas
All directory reads are serviced from secondary replicas, which are at datacenters that are
physically located across different geographies. There are many secondary replicas, as
data is replicated asynchronously. Directory reads, such as authentication requests, are
serviced from datacenters that are close to customers. The secondary replicas are
responsible for read scalability.
Scalability
Scalability is the ability of a service to expand to meet increasing performance demands.
Write scalability is achieved by partitioning the data. Read scalability is achieved by
replicating data from one partition to multiple secondary replicas distributed
throughout the world.
Requests from directory applications are routed to the closest datacenter. Writes are
transparently redirected to the primary replica to provide read-write consistency.
Secondary replicas significantly extend the scale of partitions because the directories are
typically serving reads most of the time.
Directory applications connect to the nearest datacenters. This connection improves

performance, and therefore scaling out is possible. Since a directory partition can have
many secondary replicas, secondary replicas can be placed closer to the directory
clients. Only internal directory service components that are write-intensive target the
active primary replica directly.
Continuous availability
Availability (or uptime) defines the ability of a system to perform uninterrupted. The key
to Azure AD’s high-availability is that the services can quickly shift traffic across multiple
geographically distributed datacenters. Each datacenter is independent, which enables
de-correlated failure modes. Through this high availability design, Azure AD requires no
downtime for maintenance activities.
Azure AD’s partition design is simplified compared to the enterprise AD design, using a
single-master design that includes a carefully orchestrated and deterministic primary
replica failover process.
Fault tolerance
A system is more available if it is tolerant to hardware, network, and software failures.
For each partition on the directory, a highly available master replica exists: The primary
replica. Only writes to the partition are performed at this replica. This replica is being
continuously and closely monitored, and writes can be immediately shifted to another
replica (which becomes the new primary) if a failure is detected. During failover, there
could be a loss of write availability typically of 1-2 minutes. Read availability isn't
affected during this time.
Read operations (which outnumber writes by many orders of magnitude) only go to

secondary replicas. Since secondary replicas are idempotent, loss of any one replica in a
given partition is easily compensated by directing the reads to another replica, usually in
the same datacenter.
Data durability
A write is durably committed to at least two datacenters prior to it being acknowledged.
This happens by first committing the write on the primary, and then immediately
replicating the write to at least one other datacenter. This write action ensures that a
potential catastrophic loss of the datacenter hosting the primary doesn't result in data
loss.
Azure AD maintains a zero Recovery Time Objective (RTO) to not lose data on
failovers. This includes:
Token issuance and directory reads

Allowing only about 5 minutes RTO for directory writes
Datacenters
Azure AD’s replicas are stored in datacenters located throughout the world. For more
information, see Azure global infrastructure .
Azure AD operates across datacenters with the following characteristics:
Authentication, Graph, and other AD services reside behind the Gateway service.
The Gateway manages load balancing of these services. It will fail over
automatically if any unhealthy servers are detected using transactional health
probes. Based on these health probes, the Gateway dynamically routes traffic to
healthy datacenters.
For reads, the directory has secondary replicas and corresponding front-end
services in an active-active configuration operating in multiple datacenters. If a
datacenter fails, traffic is automatically routed to a different datacenter.
For writes, the directory will fail over the primary replica across datacenters via
planned (new primary is synchronized to old primary) or emergency failover
procedures. Data durability is achieved by replicating any commit to at least two
datacenters.
Data consistency
The directory model is one of eventual consistencies. One typical problem with
distributed asynchronously replicating systems is that the data returned from a
“particular” replica may not be up-to-date.
Azure AD provides read-write consistency for applications targeting a secondary replica

by routing its writes to the primary replica, and synchronously pulling the writes back to
the secondary replica.
Application writes using the Microsoft Graph API of Azure AD are abstracted from
maintaining affinity to a directory replica for read-write consistency. The Microsoft
Graph API service maintains a logical session, which has affinity to a secondary replica
used for reads; affinity is captured in a “replica token” that the service caches using a
distributed cache in the secondary replica datacenter. This token is then used for
subsequent operations in the same logical session. To continue using the same logical
session, subsequent requests must be routed to the same Azure AD datacenter. It isn't
possible to continue a logical session if the directory client requests are being routed to
multiple Azure AD datacenters; if this happens then the client has multiple logical
sessions that have independent read-write consistencies.
７ Note
Writes are immediately replicated to the secondary replica to which the logical
session's reads were issued.
Service-level backup
Azure AD implements daily backup of directory data and can use these backups to
restore data if there is any service-wide issue.
The directory also implements soft deletes instead of hard deletes for selected object
types. The tenant administrator can undo any accidental deletions of these objects
within 30 days. For more information, see the API to restore deleted objects.
Metrics and monitors

Running a high availability service requires world-class metrics and monitoring
capabilities. Azure AD continually analyzes and reports key service health metrics and
success criteria for each of its services. There is also continuous development and tuning
of metrics and monitoring and alerting for each scenario, within each Azure AD service
and across all services.
If any Azure AD service isn't working as expected, action is immediately taken to restore
functionality as quickly as possible. The most important metric Azure AD tracks is how
quickly live site issues can be detected and mitigated for customers. We invest heavily in
monitoring and alerts to minimize time to detect (TTD Target: <5 minutes) and
operational readiness to minimize time to mitigate (TTM Target: <30 minutes).
Secure operations
Using operational controls such as multi-factor authentication (MFA) for any operation,
and auditing of all operations. In addition, using a just-in-time elevation system to grant
necessary temporary access for any operational task-on-demand on an ongoing basis.
For more information, see The Trusted Cloud .
Next steps
Azure Active Directory developer's guide
Configure scoped synchronization from
Azure AD to Azure Active Directory
Domain Services using the Azure portal
Article • 04/03/2023
To provide authentication services, Azure Active Directory Domain Services (Azure AD

DS) synchronizes users and groups from Azure AD. In a hybrid environment, users and
groups from an on-premises Active Directory Domain Services (AD DS) environment can
be first synchronized to Azure AD using Azure AD Connect, and then synchronized to an
Azure AD DS managed domain.
managed domain. If only some users need to use Azure AD DS, 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 Azure portal. You can also complete these
steps using PowerShell.
Before you begin

your tenant to change the Azure AD DS synchronization scope.
Scoped synchronization overview

managed domain. You can scope synchronization to only user accounts that were
created in Azure AD, 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:
A full synchronization occurs.

Objects that are no longer required in the managed domain are deleted. New
objects are created in the managed domain.

Enable scoped synchronization

To enable scoped synchronization in the Azure portal, complete the following steps:
managed domain, such as aaddscontoso.com.
2. Select Synchronization from the menu on the left-hand side.
3. For Synchronization scope, select All or Cloud Only.
4. 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 Azure AD. Only users who belong to those groups will have
their accounts synchronized to Azure AD DS.
5. To add groups, click Add groups, then search for and choose the groups to add.
6. When all changes are made, select Save synchronization scope.
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:
3. To add a group, choose + Add groups at the top, then choose the groups to add.
4. To remove a group from the synchronization scope, select it from the list of
currently synchronized groups and choose Remove groups.
5. When all changes are made, select Save synchronization scope.
Disable scoped synchronization

To disable group-based scoped synchronization for a managed domain, complete the
following steps:
3. Clear the check box for Show selected groups, and click Save synchronization
scope.
Next steps
Create an Organizational Unit (OU) in an
managed domain
Article • 01/30/2023
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.
Azure AD DS 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 Azure AD
tenant.
As you create and run workloads that use Azure AD DS, 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


A Windows Server management VM that is joined to the Azure AD DS managed
domain.
If needed, complete the tutorial to create a management VM.
Azure AD 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 Azure AD 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 Azure AD tenant.
These objects don't show up using the Microsoft Graph API or in the Azure AD
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 Azure
portal, see Connect to a Windows Server VM.
2. 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.
3. To create and manage OUs, select Active Directory Administrative Center from
the list of administrative tools.
4. In the left pane, choose your managed domain, such as aaddscontoso.com. A list of
existing OUs and resources is shown:
5. 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.
6. 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.
7. 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

Service Accounts Step-by-Step Guide
Create a group managed service
account (gMSA) in Azure Active
Article • 01/30/2023
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 Azure Active
Directory Domain Services (Azure AD DS) 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


domain.
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.
Using service accounts in Azure AD DS

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 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
Azure AD DS, 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 cmdlet. For more
information on creating and managing custom OUs, see Custom OUs in Azure AD DS.
 Tip
To complete these steps to create a gMSA, use your 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 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.
Administer Group Policy in an Azure
managed domain
Article • 01/30/2023
Settings for user and computer objects in Azure Active Directory Domain Services (Azure
AD DS) are often managed using Group Policy Objects (GPOs). Azure AD DS 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 Azure AD DC administrators group have Group Policy
administration privileges in the Azure AD DS 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.
In a hybrid environment, group policies configured in an on-premises AD DS

environment aren't synchronized to Azure AD DS. To define configuration settings for
users or computers in Azure AD DS, 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, consider reading about the guest configuration feature of Azure
Policy.
Before you begin


domain.
If needed, complete the tutorial to create a Windows Server VM and join it to a
managed domain.
Azure AD 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).
2. Server Manager should open by default when you sign in to the VM. If not, on the
Start menu, select Server Manager.
Features.
8. On the Features page, select the Group Policy Management feature.
Group Policy Management tools.
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

tools is shown, including Group Policy Management installed in the previous
section.
2. 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.
2. 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....
3. 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 Azure AD DS, 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.
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...:
2. 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.
3. 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...:
4. 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.
Administer DNS and create conditional
forwarders in an Azure Active Directory
Article • 01/30/2023
Azure AD DS 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 Azure AD DS
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 Azure AD DS.
７ Note
Creating or changing root hints or server-level DNS forwarders is not supported

and will cause issues for the Azure AD DS managed domain.
Before you begin


Connectivity from your Azure AD DS virtual network to where your other DNS
namespaces are hosted.
This connectivity can be provided with an Azure ExpressRoute or Azure VPN
Gateway connection.
A Windows Server management VM that is joined to the managed domain.
managed domain.
Azure AD 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).
Features.
8. 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.
DNS Server Tools.
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.
tools is shown, including DNS installed in the previous section. Select DNS to
launch the DNS Management console.
2. 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:
3. 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 Azure AD DS. 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

An Azure AD DS 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.
2. Select Conditional Forwarders, then right-select and choose New Conditional

Forwarder...
3. 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:
4. 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.
5. 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.
Check the health of an Azure Active
Directory Domain Services managed
domain
Article • 01/30/2023
Azure Active Directory Domain Services (Azure AD DS) 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 Azure AD. If there are issues
with the Azure AD DS 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 Azure portal.
This article shows you how to view the Azure AD DS health status and understand the
information or alerts shown.
View the health status

The health status for a managed domain is viewed using the Azure portal. Information
on the last backup time and synchronization with Azure AD 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:
2. Select your managed domain, such as aaddscontoso.com.
3. On the left-hand side of the Azure AD DS 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 The managed domain is running correctly and doesn't have any critical or
warning alerts. The domain may have informational alerts.
Needs There are no critical alerts on the managed domain, but there are one or
attention more warning alerts that should be addressed.
(warning)
Needs There are one or more critical alerts on the managed domain that must be
attention addressed. You may also have warning and / or informational alerts.
(critical)
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. Azure AD DS currently has monitors for the following areas:
Backup
Synchronization with Azure AD
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 Explanation
value
Never This state is normal for new managed domains. The first backup should be created 24
backed hours after the managed domain is deployed. If this status persists, open an Azure
up support request.
Last This time range is the expected status for the backup monitor. Automated regular
backup backups should occur in this period.
was
taken 1
to 14
days ago
Last A timespan longer than two weeks indicates there's an issue with the automated
backup regular backups. Active critical alerts may prevent the managed domain from being
was backed up. Resolve any active alerts for the managed domain. If the backup monitor
taken doesn't then update the status to report a recent backup, open an Azure support
more request.
than 14
days ago.
Synchronization with Azure AD monitor
A managed domain regularly synchronizes with Azure Active Directory. The number of
users and group objects, and the number of changes made in the Azure AD 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.
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.
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
Check fleet metrics of Azure Active
Article • 01/30/2023
Administrators can use Azure Monitor Metrics to configure a scope for Azure Active
Directory Domain Services (Azure AD DS) and gain insights into how the service is
performing. You can access Azure AD DS metrics from two places:
In Azure Monitor Metrics, click New chart > Select a scope and select the Azure
AD DS instance:
In Azure AD DS, under Monitoring, click Metrics:

The following screenshot shows how to select combined metrics for Total
Processor Time and LDAP searches:
You can also view metrics for a fleet of Azure AD DS instances:
The following screenshot shows combined metrics for Total Processor Time, DNS
Queries, and LDAP searches by role 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 Azure AD DS.
Metric Description
DNS - Total The average number of queries received by DNS server in each second. It's
Query backed by performance counter data from the domain controller, and can be
Received/sec filtered or split by role instance.
Metric Description
Total Response The average number of responses sent by DNS server in each second. It's
Sent/sec backed by performance counter data from the domain controller, and can be
filtered or split by role instance.
NTDS - LDAP The number of LDAP successful binds per second for the NTDS object. It's
Successful backed by performance counter data from the domain controller, and can be
Binds/sec filtered or split by role instance.
% Committed The ratio of Memory\\Committed Bytes to the Memory\\Commit Limit.

Bytes In Use 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 The percentage of elapsed time that the processor spends to execute a non-
Time 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 The number of times that clients use a ticket to authenticate to this computer
Authentications per second. It's backed by performance counter data from the domain
controller, and can be filtered or split by role instance.
NTLM The number of NTLM authentications processed per second for the Active
Authentications 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.
Metric Description
% Processor The percentage of elapsed time that all of dns process threads used the
Time (dns) 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 The percentage of elapsed time that all of lsass process threads used the
Time (lsass) 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
NTDS - LDAP The average number of searches per second for the NTDS object. It's backed by
Searches/sec performance counter data from the domain controller, and can be filtered or
Azure Monitor alert

You can configure metric alerts for Azure AD DS 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?.
To view and manage Azure Monitor alert, a user needs to be assigned Azure Monitor
roles.
In Azure Monitor or Azure AD DS Metrics, click New alert and configure an Azure AD DS
instance as the scope. Then choose the metrics you want to measure from the list of
available signals:
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
Check the health of an Azure Active Directory Domain Services managed domain
Configure email notifications for issues
in Azure Active Directory Domain
Services
Article • 01/30/2023
The health of an Azure Active Directory Domain Services (Azure AD DS) managed
domain is monitored by the Azure platform. The health status page in the Azure portal
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 Azure AD DS 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, as
well as giving the time of detection and a link to the health page in the Azure portal. 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?

Azure AD DS 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 Azure portal and can be viewed on the
Azure AD DS health page.
Azure AD DS doesn't send emails for advertisement, updates, or sales purposes.
When will I receive email notifications?

A notification is sent immediately when a new alert is found on a managed domain. If
the alert isn't resolved, additional email notifications are sent as a reminder every four
days.
Who should receive the email notifications?

The list of email recipients for Azure AD DS 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 additional emails 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 Azure AD directory and
every member of the AAD DC Administrators group receive email notifications. Azure
AD DS 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 additional recipients, complete
2. Select your managed domain, such as aaddscontoso.com.
3. On the left-hand side of the Azure AD DS resource window, select Notification
settings. The existing recipients for email notifications are shown.
4. To add an email recipient, enter the email address in the additional recipients table.
5. 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 Azure portal there was no alert. What
happened?
If an alert is resolved, the alert is cleared from the Azure portal. The most likely reason is
that someone else who receives email notifications resolved the alert on the managed
domain, or it was autoresolved by Azure platform.
Why can I not edit the notification settings?

If you're unable to access the notification settings page in the Azure portal, you don't
have the permissions to edit the managed domain. Contact a global administrator to
either get permissions to edit Azure AD DS 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.
Delete an Azure Active Directory
using the Azure portal
Article • 01/30/2023
If you no longer need an Azure Active Directory Domain Services (Azure AD DS)
managed domain, you can delete it. There's no option to turn off or temporarily disable
an Azure AD DS managed domain. Deleting the managed domain doesn't delete or
otherwise adversely impact the Azure AD tenant.
This article shows you how to use the Azure portal 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 de-provisioned 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:
2. Select the name of your managed domain, such as aaddscontoso.com.
3. 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 for the features that you would like to see in Azure AD DS.
If you want to get started with Azure AD DS again, see Create and configure an Azure
Active Directory Domain Services managed domain.
Change the SKU for an existing Azure
managed domain
Article • 04/03/2023
In Azure Active Directory Domain Services (Azure AD DS), 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 Azure AD DS SKU concepts and Azure AD DS pricing pages.
This article shows you how to change the SKU for an existing Azure AD DS managed
domain using the Azure portal.
Before you begin


If needed, complete the tutorial to create and configure a managed domain.
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 Azure AD DS SKU features and limits.
Select a new SKU

To change the SKU for a managed domain using the Azure portal, complete the
following steps:
1. At the top of the Azure portal, search for and select Azure AD Domain Services.
Choose your managed domain from the list, such as aaddscontoso.com.
2. In the menu on the left-hand side of the Azure AD DS page, select Settings > SKU.
3. 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 Azure AD DS.
Azure AD DS instructions for data
retrieval
Article • 08/23/2022
This document describes how to retrieve data from Azure Active Directory Domain
Services (Azure AD DS).
７ Note
This article provides steps about how to delete personal data from the device or
service and can be used to support your obligations under the GDPR. For general
information about GDPR, see the GDPR section of the Microsoft Trust Center
and the GDPR section of the Service Trust portal .
Use Azure Active Directory to create, read,

update, and delete user objects
You can create a user in the Azure AD portal 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 Azure AD portal.
Create, read, or update a user

You can create a new user using the Azure Active Directory portal. To add a new user,
follow these steps:
1. Sign in to the Azure portal in the User Administrator role for the organization.
2. Search for and select Azure Active Directory from any page.
3. Select Users, and then select New user.

4. 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 Azure AD administrative permissions for the

user, you can add them to an Azure AD role.
Job info: You can add more information about the user here.
5. 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.
6. Select Create.
The user is created and added to your Azure AD 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 Azure AD tenant. For
example, Mary Parker.
2. 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.
Use RSAT tools to connect to an Azure AD DS

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).
1. From the Start menu, select Windows Administrative Tools. The Active Directory
Administration Tools are listed.
2. Select Active Directory Administrative Center.
3. 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.
4. To see the users and groups that belong to the managed domain, select the
AADDC Users container. The user accounts and groups from your Azure AD 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.
5. 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
Azure AD DS Overview
Harden an Azure Active Directory
Article • 05/11/2023
By default, Azure Active Directory Domain Services (Azure AD DS) 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 Azure AD 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:
Disable NTLM v1 and TLS v1 ciphers

Disable NTLM password hash synchronization
Disable the ability to change passwords with RC4 encryption
Enable Kerberos armoring
LDAP signing
LDAP channel binding
Prerequisites

managed domain.
Use Security settings to harden your domain

1. Sign in to the Azure portal .
2. Search for and select Azure AD Domain Services.

4. On the left-hand side, select Security settings.
5. 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:
If the assignment is Audit, the compliance will report if the Azure AD DS instance is
compliant.
If the assignment is Deny, the compliance will prevent an Azure AD DS instance
from being created if TLS 1.2 is not required and prevent any update to an Azure
AD DS instance until TLS 1.2 is required.
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 Azure Active Directory Domain Services.
Use PowerShell to harden your domain

If needed, install and configure Azure PowerShell. Make sure that you sign in to your
Azure subscription using the Connect-AzAccount cmdlet.
Also if needed, install and configure Azure AD PowerShell. Make sure that you sign in to
your Azure AD tenant using the Connect-AzureAD cmdlet.
To disable weak cipher suites and NTLM credential hash synchronization, sign in to your
Azure account, then get the Azure AD DS resource using the Get-AzResource cmdlet:
 Tip
If you receive an error using the Get-AzResource command that the

Microsoft.AAD/DomainServices resource doesn't exist, elevate your access to
manage all Azure subscriptions and management groups.
PowerShell
Login-AzAccount

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 Azure AD DS 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"="Disabl
ed";"TlsV1"="Disabled";"KerberosRc4Encryption"="Disabled";"KerberosArmoring"
="Disabled"}}
Finally, apply the defined security settings to the managed domain using the Set-
AzResource cmdlet. Specify the Azure AD DS resource from the first step, and the
security settings from the previous step.
PowerShell

$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 Azure AD
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.
Configure Kerberos constrained
delegation (KCD) in Azure Active
Article • 01/30/2023
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.
Azure Active Directory Domain Services (Azure AD DS) 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 an Azure AD DS managed domain.
Prerequisites

managed domain.
domain.
managed domain then install the AD DS management tools.
Azure AD 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 or

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. You can delegate permissions to manage this custom OU to
users within the managed domain.
2. Domain-join the virtual machines, 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 AAD DC
Computers container.
3. Finally, configure resource-based KCD using the Set-ADComputer PowerShell

cmdlet.
From your domain-joined management VM and logged in as user account that's a

member of the Azure AD 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:
users within the managed domain.
2. Domain-join the virtual machines that run the backend web API/resource to the
managed domain. Create its computer account within the custom OU.
3. 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 AAD DC Computers or AAD DC Users containers. This
also means that you can't use user accounts synchronized from Azure AD to
set up resource-based KCD. You must create and use service accounts
specifically created in Azure AD DS.
4. Finally, configure resource-based KCD using the Set-ADUser PowerShell cmdlet.
From your domain-joined management VM and logged in as user account that's a

member of the Azure AD 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.
Password and account lockout policies
on Azure Active Directory Domain
Services managed domains
Article • 05/09/2023
To manage user security in Azure Active Directory Domain Services (Azure AD DS), 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 an Azure AD DS 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
Azure AD DS 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


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.
Azure AD 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

Configure fine-grained password policies using AD Administration Center
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 Azure AD
DS:
The user account can be synchronized in from Azure AD. This includes cloud-only
user accounts created directly in Azure, and hybrid user accounts synchronized
from an on-premises AD DS environment using Azure AD Connect.
The majority of user accounts in Azure AD DS are created through the
synchronization process from Azure AD.
The user account can be manually created in a managed domain, and doesn't exist
in Azure AD.
All users, regardless of how they're created, have the following account lockout policies
applied by the default password policy in Azure AD DS:
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 Azure AD DS, and only due to failed sign-in attempts against the managed
domain. User accounts that were synchronized in from Azure AD or on-premises aren't
locked out in their source directories, only in Azure AD DS.
If you have an Azure AD password policy that specifies a maximum password age
greater than 90 days, that password age is applied to the default policy in Azure AD DS.
You can configure a custom password policy to define a different maximum password
age in Azure AD DS. Take care if you have a shorter maximum password age configured
in an Azure AD DS password policy than in Azure AD or an on-premises AD DS
environment. In that scenario, a user's password may expire in Azure AD DS before
they're prompted to change in Azure AD 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 Azure AD, as a user can't update their password
directly in Azure AD DS.
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.
2. To create and manage OUs, select Active Directory Administrative Center from
the list of administrative tools.
3. In the left pane, choose your managed domain, such as aaddscontoso.com.
4. 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.
5. In the Tasks panel on the right, select New > Password Settings.
6. In the Create Password Settings dialog, enter a name for the policy, such as
MyCustomFGPP.
7. 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.
8. 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 Azure AD
itself.
9. Uncheck Protect from accidental deletion. If this option is selected, you can't save
the FGPP.
10. In the Directly Applies To section, select the Add button. In the Select Users or
Groups dialog, select the Locations button.
11. 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.
12. Type the name of the user or group you wish to apply the policy to. Select Check
Names to validate the account.
13. 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

Configure fine-grained password policies using AD Administration Center
Enable security and DNS audits for
Article • 05/10/2023
Azure Active Directory Domain Services (Azure AD DS) 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, Azure
AD DS 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 Azure portal.
Security audit destinations

You can use Azure Storage, Azure Event Hubs, or Azure Log Analytics workspaces as a
target resource for Azure AD DS 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 Azure AD DS security
audits. You can create these resources using the Azure portal, Azure PowerShell, or
the Azure CLI.
Target Scenario
Resource
Azure This target should be used when your primary need is to store security audit events
Storage for archival purposes. Other targets can be used for archival purposes, however
those targets provide capabilities beyond the primary need of archiving.
Before you enable Azure AD DS security audit events, first Create an Azure Storage
account.
Target Scenario
Resource
Azure This target should be used when your primary need is to share security audit events
Event with additional software such as data analysis software or security information &
Hubs event management (SIEM) software.
Before you enable Azure AD DS security audit events, Create an event hub using
Azure portal
Azure Log This target should be used when your primary need is to analyze and review secure
Analytics audits from the Azure portal directly.
Workspace
Before you enable Azure AD DS security audit events, Create a Log Analytics
workspace in the Azure portal.
Enable security audit events using the Azure

portal
To enable Azure AD DS security audit events using the Azure portal, complete the
following steps.
） Important
Azure AD DS security audits aren't retroactive. You can't retrieve or replay events
from the past. Azure AD DS can only send events that occur after security audits are
enabled.
1. Sign in to the Azure portal.
2. At the top of the Azure portal, search for and select Azure AD Domain Services.
Choose your managed domain, such as aaddscontoso.com.
3. In the Azure AD DS window, select Diagnostic settings on the left-hand side.
4. No diagnostics are configured by default. To get started, select Add diagnostic

setting.
5. 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.
6. 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.
7. When done, select Save to commit your changes. The target resources start to
receive Azure AD DS audit events soon after the configuration is saved.
Enable security and DNS audit events using

Azure PowerShell
To enable Azure AD DS 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.
） Important
Azure AD DS audits aren't retroactive. You can't retrieve or replay events from the
past. Azure AD DS can only send events that occur after audits are enabled.
1. Authenticate to your Azure subscription using the Connect-AzAccount cmdlet.

When prompted, enter your account credentials.
Azure PowerShell
Connect-AzAccount
2. Create the target resource for the audit events.
Azure Log Analytic workspaces - Create a Log Analytics workspace with

Azure PowerShell.
Azure storage - Create a storage account using Azure PowerShell

Azure event hubs - Create an event hub using Azure PowerShell. You may
also need to use the New-AzEventHubAuthorizationRule cmdlet to create an
authorization rule that grants Azure AD DS 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.
3. Get the resource ID for your Azure AD DS managed domain using the Get-
AzResource cmdlet. Create a variable named $aadds.ResourceId to hold the value:
Azure PowerShell
$aadds = Get-AzResource -name aaddsDomainName
4. Configure the Azure Diagnostic settings using the Set-AzDiagnosticSetting cmdlet

to use the target resource for Azure AD 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

Get started with Log Analytics in Azure Monitor
Get started with log queries in Azure Monitor
Create and share dashboards of Log Analytics data
The following sample queries can be used to start analyzing audit events from Azure AD
DS.
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
| where TimeGenerated >= datetime(2020-06-03 09:00) and TimeGenerated <=
datetime(2020-06-10)
| 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 "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
| 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
| where "0xc0000234" == tolower(extract("Error Code:\t(.+[0-9A-Fa-
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
| where "0xc0000234" == tolower(extract("Error Code:\t(.+[0-9A-Fa-
| summarize count()
Audit security and DNS event categories

Azure AD DS 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 Description
Category
Name
Account Audits attempts to authenticate account data on a domain controller or on a local

Logon Security Accounts Manager (SAM).
-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:
-Audit Credential Validation
-Audit Kerberos Authentication Service
-Audit Kerberos Service Ticket Operations
-Audit Other Logon/Logoff Events
Account Audits changes to user and computer accounts and groups. This category
Management includes the following subcategories:
-Audit Application Group Management
-Audit Computer Account Management
-Audit Distribution Group Management
-Audit Other Account Management
-Audit Security Group Management
-Audit User Account Management
Audit Description
Category
Name
DNS Server Audits changes to DNS environments. This category includes the following
subcategories:
- DNSServerAuditsDynamicUpdates (preview)
- DNSServerAuditsGeneral (preview)
Detail Audits activities of individual applications and users on that computer, and to
Tracking understand how a computer is being used. This category includes the following
subcategories:
-Audit DPAPI Activity
-Audit PNP activity
-Audit Process Creation
-Audit Process Termination
-Audit RPC Events
Directory Audits attempts to access and modify objects in Active Directory Domain Services
Services (AD DS). These audit events are logged only on domain controllers. This category
Access includes the following subcategories:
-Audit Detailed Directory Service Replication
-Audit Directory Service Access
-Audit Directory Service Changes
-Audit Directory Service Replication
Logon- Audits attempts to log on to a computer interactively or over a network. These

Logoff events are useful for tracking user activity and identifying potential attacks on
network resources. This category includes the following subcategories:
-Audit Account Lockout
-Audit User/Device Claims
-Audit IPsec Extended Mode
-Audit Group Membership
-Audit IPsec Main Mode
-Audit IPsec Quick Mode
-Audit Logoff
-Audit Logon
-Audit Network Policy Server
-Audit Other Logon/Logoff Events
-Audit Special Logon
Audit Description
Category
Name
Object Audits attempts to access specific objects or types of objects on a network or

Access computer. This category includes the following subcategories:
-Audit Application Generated
-Audit Certification Services
-Audit Detailed File Share
-Audit File Share
-Audit File System
-Audit Filtering Platform Connection
-Audit Filtering Platform Packet Drop
-Audit Handle Manipulation
-Audit Kernel Object
-Audit Other Object Access Events
-Audit Registry
-Audit Removable Storage
-Audit SAM
-Audit Central Access Policy Staging
Policy Audits changes to important security policies on a local system or network.

Change 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:
-Audit Audit Policy Change
-Audit Authentication Policy Change
-Audit Authorization Policy Change
-Audit Filtering Platform Policy Change
-Audit MPSSVC Rule-Level Policy Change
-Audit Other Policy Change
Privilege Use Audits the use of certain permissions on one or more systems. This category
includes the following subcategories:
-Audit Non-Sensitive Privilege Use
-Audit Sensitive Privilege Use
-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:
-Audit IPsec Driver
-Audit Other System Events
-Audit Security State Change
-Audit Security System Extension
-Audit System Integrity
Event IDs per category
Azure AD DS security and DNS audits record the following event IDs when the specific
action triggers an auditable event:
Event Event IDs

Category
Name
Account 4767, 4774, 4775, 4776, 4777

Logon
security
Account 4720, 4722, 4723, 4724, 4725, 4726, 4727, 4728, 4729, 4730, 4731, 4732, 4733,
Management 4734, 4735, 4737, 4738, 4740, 4741, 4742, 4743, 4754, 4755, 4756, 4757, 4758,
security 4764, 4765, 4766, 4780, 4781, 4782, 4793, 4798, 4799, 5376, 5377
Detail None
Tracking
security
DNS Server 513-523, 525-531, 533-537, 540-582
DS Access 5136, 5137, 5138, 5139, 5141

security
Logon- 4624, 4625, 4634, 4647, 4648, 4672, 4675, 4964

Logoff
security
Object None
Access
security
Policy 4670, 4703, 4704, 4705, 4706, 4707, 4713, 4715, 4716, 4717, 4718, 4719, 4739,
Change 4864, 4865, 4866, 4867, 4904, 4906, 4911, 4912
security
Privilege Use 4985

security
System 4612, 4621

security
Next steps
For specific information on Kusto, see the following articles:
Overview of the Kusto query language.
Kusto tutorial to familiarize you with query basics.
Sample queries that help you learn new ways to see your data.
Kusto best practices to optimize your queries for success.
Review security audit events in Azure
Active Directory Domain Services using
Azure Monitor Workbooks
Article • 08/23/2022
To help you understand the state of your Azure Active Directory Domain Services (Azure
AD DS) 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. Azure AD DS 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 Azure AD DS.
Before you begin


Security audit events enabled for your managed domain that stream data to a Log
Analytics workspace.
If needed, enable security audits for Azure AD DS.
Azure Monitor Workbooks overview

When security audit events are turned on in Azure AD DS, 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.
Azure AD DS 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.
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 Azure AD Domain Services in the Azure portal.
2. Select your managed domain, such as aaddscontoso.com
3. From the menu on the left-hand side, choose Monitoring > Workbooks
4. Choose the Security Overview Report.
5. 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.
6. 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:
7. 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:
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 Azure AD Domain Services in the Azure portal.
2. Select your managed domain, such as aaddscontoso.com
3. From the menu on the left-hand side, choose Monitoring > Workbooks
4. Choose the Account Activity Report.
5. 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:
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 Azure AD DS 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.
2. 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 and Kusto queries tutorial.
Next steps
If you need to adjust password and lockout policies, see Password and account lockout
policies on managed domains.
For problems with users, learn how to troubleshoot account sign-in problems or
account lockout problems.
Secure remote access to virtual
machines in Azure Active Directory
Domain Services
Article • 01/30/2023
To secure remote access to virtual machines (VMs) that run in an Azure Active Directory
Domain Services (Azure AD DS) managed domain, you can use Remote Desktop Services
(RDS) and Network Policy Server (NPS). Azure AD DS authenticates users as they request
access through the RDS environment. For enhanced security, you can integrate Azure
AD Multi-Factor Authentication to provide an additional authentication prompt during
sign-in events. Azure AD Multi-Factor Authentication uses an extension for NPS to
provide this feature.
） Important
The recommended way to securely connect to your VMs in an Azure AD DS

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 Azure AD DS where all incoming RDP traffic is allowed.
For more information, see What is Azure Bastion?.
This article shows you how to configure RDS in Azure AD DS and optionally use the
Azure AD Multi-Factor Authentication NPS extension.
Prerequisites

managed domain.
A workloads subnet created in your Azure Active Directory Domain Services virtual
network.
If needed, Configure virtual networking for an Azure Active Directory Domain
Services managed domain.
Azure AD 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 additional 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 Azure AD DS 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.
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
Azure AD DC Administrators group, such as contosoadmin.
2. To create and configure RDS, use the existing Remote Desktop environment
deployment guide. Distribute the RD server components across your Azure VMs as
desired.
Specific to Azure AD DS - when you configure RD licensing, set it to Per

Device mode, not Per User as noted in the deployment guide.
3. If you want to provide access using a web browser, set up the Remote Desktop
web client for your users.
With RD deployed into the managed domain, you can manage and use the service as
you would with an on-premises AD DS domain.
Deploy and configure NPS and the Azure AD

MFA NPS extension
If you want to increase the security of the user sign-in experience, you can optionally
integrate the RD environment with Azure AD Multi-Factor Authentication. With this
configuration, users receive an additional prompt during sign-in to confirm their
identity.
To provide this capability, an additional Network Policy Server (NPS) is installed in your
environment along with the Azure AD Multi-Factor Authentication NPS extension. This
extension integrates with Azure AD to request and return the status of multi-factor
authentication prompts.
Users must be registered to use Azure AD Multi-Factor Authentication, which may

require additional Azure AD licenses.
To integrate Azure AD Multi-Factor Authentication in to your Azure AD DS Remote
Desktop environment, create an NPS Server and install the extension:
1. Create an additional Windows Server 2016 or 2019 VM, such as NPSVM01, that's
connected to a workloads subnet in your Azure AD DS virtual network. Join the VM
to the managed domain.
2. Sign in to NPS VM as account that's part of the Azure AD DC Administrators group,
such as contosoadmin.
3. From Server Manager, select Add Roles and Features, then install the Network
Policy and Access Services role.
4. Use the existing how-to article to install and configure the Azure AD MFA NPS
extension.
With the NPS server and Azure AD Multi-Factor Authentication NPS extension installed,
complete the next section to configure it for use with the RD environment.
Integrate Remote Desktop Gateway and Azure

AD Multi-Factor Authentication
To integrate the Azure AD Multi-Factor Authentication NPS extension, use the existing
how-to article to integrate your Remote Desktop Gateway infrastructure using the
Network Policy Server (NPS) extension and Azure AD.
The following additional configuration options are needed to integrate with a managed
domain:
1. Don't register the NPS server in Active Directory. This step fails in a managed
domain.
2. In step 4 to configure network policy, also check the box to Ignore user account
dial-in properties.
3. If you use Windows Server 2019 for the NPS server and Azure AD Multi-Factor
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 an additional 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.
For more information about securing user sign-in, see How it works: Azure AD Multi-
Factor Authentication.
Azure security baseline for Azure Active
Article • 04/12/2023
This security baseline applies guidance from the Microsoft cloud security benchmark
version 1.0 to Azure Active Directory Domain Services. The Microsoft cloud security
benchmark provides recommendations on how you can secure your cloud solutions on
Azure. The content is grouped by the security controls defined by the Microsoft cloud
security benchmark and the related guidance applicable to Azure Active Directory
Domain Services.
You can monitor this security baseline and its recommendations using Microsoft
Defender for Cloud. Azure Policy definitions will be listed in the Regulatory Compliance
section of the Microsoft Defender for Cloud dashboard.
When a feature has relevant Azure Policy Definitions, they are listed in this baseline to
help you measure compliance to the Microsoft cloud security benchmark controls and
recommendations. Some recommendations may require a paid Microsoft Defender plan
to enable certain security scenarios.
７ Note
Features not applicable to Azure Active Directory Domain Services have been
excluded. To see how Azure Active Directory Domain Services completely maps to
the Microsoft cloud security benchmark, see the full Azure Active Directory
Domain Services security baseline mapping file .
Security profile
The security profile summarizes high-impact behaviors of Azure Active Directory
Domain Services, which may result in increased security considerations.
Service Behavior Attribute Value
Product Category Identity
Customer can access HOST / OS No Access
Service can be deployed into customer's virtual network True
Stores customer content at rest True

Network security
For more information, see the Microsoft cloud security benchmark: Network security.
NS-1: Establish network segmentation boundaries
Features
Virtual Network Integration
Description: Service supports deployment into customer's private Virtual Network

(VNet). Learn more.
Supported Enabled By Default Configuration Responsibility
True True Microsoft
Configuration Guidance: No additional configurations are required as this is enabled on

a default deployment.
Reference: Virtual network design considerations and configuration options for Azure
Network Security Group Support
Description: Service network traffic respects Network Security Groups rule assignment
on its subnets. Learn more.
True False Customer
Configuration Guidance: Use network security groups (NSG) to restrict or monitor traffic
by port, protocol, source IP address, or destination IP address. Create NSG rules to
restrict your service's open ports (such as preventing management ports from being
accessed from untrusted networks). Be aware that by default, NSGs deny all inbound
traffic but allow traffic from virtual network and Azure Load Balancers.
Reference: Virtual network design considerations and configuration options for Azure
NS-2: Secure cloud services with network controls
Features
Azure Private Link
Description: Service native IP filtering capability for filtering network traffic (not to be
confused with NSG or Azure Firewall). Learn more.
False Not Applicable Not Applicable
Configuration Guidance: This feature is not supported to secure this service.
Disable Public Network Access
Description: Service supports disabling public network access either through using
service-level IP ACL filtering rule (not NSG or Azure Firewall) or using a 'Disable Public
Network Access' toggle switch. Learn more.
Identity management
For more information, see the Microsoft cloud security benchmark: Identity management.
IM-1: Use centralized identity and authentication system
Features
Azure AD Authentication Required for Data Plane Access
Description: Service supports using Azure AD authentication for data plane access.
Learn more.
Local Authentication Methods for Data Plane Access
Description: Local authentications methods supported for data plane access, such as a
local username and password. Learn more.
True False Customer
Feature notes: Avoid the usage of local authentication methods or accounts, these
should be disabled wherever possible. Instead use Azure AD to authenticate where
possible.
Configuration Guidance: Avoid the usage of local authentication methods or accounts,

these should be disabled wherever possible. Instead use accounts synchronized from
Azure AD to authenticate where possible.
Reference: User account creation
IM-3: Manage application identities securely and

automatically
Features
Managed Identities
Description: Data plane actions support authentication using managed identities. Learn
more.
Service Principals
Description: Data plane supports authentication using service principals. Learn more.
Privileged access
For more information, see the Microsoft cloud security benchmark: Privileged access.
PA-1: Separate and limit highly privileged/administrative

users
Features
Local Admin Accounts
Description: Service has the concept of a local administrative account. Learn more.
PA-7: Follow just enough administration (least privilege)

principle
Features
Azure RBAC for Data Plane
Description: Azure Role-Based Access Control (Azure RBAC) can be used to managed
access to service's data plane actions. Learn more.

PA-8: Determine access process for cloud provider

support
Features
Customer Lockbox
Description: Customer Lockbox can be used for Microsoft support access. Learn more.
Data protection
For more information, see the Microsoft cloud security benchmark: Data protection.
DP-1: Discover, classify, and label sensitive data
Features
Sensitive Data Discovery and Classification
Description: Tools (such as Azure Purview or Azure Information Protection) can be used
for data discovery and classification in the service. Learn more.
DP-2: Monitor anomalies and threats targeting sensitive

data
Features
Data Leakage/Loss Prevention
Description: Service supports DLP solution to monitor sensitive data movement (in
customer's content). Learn more.
DP-3: Encrypt sensitive data in transit
Features
Data in Transit Encryption
Description: Service supports data in-transit encryption for data plane. Learn more.
True False Customer
Configuration Guidance: Enable secure transfer in services where there is a native data
in transit encryption feature built in. Enforce HTTPS on any web applications and
services and ensure TLS v1.2 or later is used. Legacy versions such as SSL 3.0, TLS v1.0
should be disabled. For remote management of Virtual Machines, use SSH (for Linux) or
RDP/TLS (for Windows) instead of an unencrypted protocol.
Reference: Tutorial: Configure secure LDAP for an Azure Active Directory Domain
DP-4: Enable data at rest encryption by default
Features
Data at Rest Encryption Using Platform Keys

Description: Data at-rest encryption using platform keys is supported, any customer
content at rest is encrypted with these Microsoft managed keys. Learn more.
True True Microsoft
Feature notes: The users cannot configure the feature and it is enabled by default.

DP-5: Use customer-managed key option in data at rest

encryption when required
Features
Data at Rest Encryption Using CMK
Description: Data at-rest encryption using customer-managed keys is supported for

customer content stored by the service. Learn more.
DP-6: Use a secure key management process
Features
Key Management in Azure Key Vault
Description: The service supports Azure Key Vault integration for any customer keys,
secrets, or certificates. Learn more.

Asset management
For more information, see the Microsoft cloud security benchmark: Asset management.
AM-2: Use only approved services
Features
Azure Policy Support
Description: Service configurations can be monitored and enforced via Azure Policy.
Learn more.
True True Microsoft
Feature notes: Customer does not have the ability to configure the feature on the
product.

Reference: Azure Active Directory built-in Policy
Logging and threat detection

For more information, see the Microsoft cloud security benchmark: Logging and threat
detection.
LT-1: Enable threat detection capabilities
Features
Microsoft Defender for Service / Product Offering
Description: Service has an offering-specific Microsoft Defender solution to monitor and

alert on security issues. Learn more.
LT-4: Enable logging for security investigation
Features
Azure Resource Logs
Description: Service produces resource logs that can provide enhanced service-specific
metrics and logging. The customer can configure these resource logs and send them to
their own data sink like a storage account or log analytics workspace. Learn more.
True False Customer
Configuration Guidance: Azure Active Directory Domain Services (Azure AD DS) security
audits lets Azure stream security events to targeted resources. These resources include
Azure Storage, Azure Log Analytics workspaces, or Azure Event Hub. After you enable
security audit events, Azure AD DS 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 Azure portal.
Reference: Enable security audits for Azure Active Directory Domain Services
Backup and recovery

For more information, see the Microsoft cloud security benchmark: Backup and recovery.
BR-1: Ensure regular automated backups
Features
Service Native Backup Capability
Description: Service supports its own native backup capability (if not using Azure
Backup). Learn more.
True True Microsoft
Feature notes: The user cannot configure the service, the backup is enabled by default
and its frequency is determined by the SKU.

Reference: Backup and SKU details for Azure AD Domain Services
Next steps
See the Microsoft cloud security benchmark overview
Learn more about Azure security baselines
Join a Windows Server virtual machine
to an Azure Active Directory Domain
Services managed domain using a
Resource Manager template
Article • 08/01/2023
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 Azure Active Directory Domain Services (Azure AD DS) managed
domains.
This article shows you how to create and join a Windows Server VM to an Azure AD DS
managed domain using Resource Manager templates. You also learn how to join an
existing Windows Server VM to an Azure AD DS domain.
Prerequisites

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.
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')]",
"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

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.
To create a Windows Server VM then join it to a managed domain, complete the

following steps:
1. Browse to the quickstart template . Select the option to Deploy to Azure.
2. 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 Azure AD
Domain Services.
Resource Choose the resource group for your VM.

group
Location Select the location of for your VM.
Existing VNET The name of the existing virtual network to connect the VM to, such as
Name myVnet.
Existing The name of the existing virtual network subnet, such as Workloads.
Subnet Name
DNS Label Enter a DNS name to use for the VM, such as myvm.
Prefix
VM size Specify a VM size, such as Standard_DS2_v2.
Domain To The managed domain DNS name, such as aaddscontoso.com.

Join
Domain The user account in the managed domain that should be used to join the
Username VM to the managed domain, such as contosoadmin@aaddscontoso.com . This
account must be a part of the managed domain.
Domain The password for the user account specified in the previous setting.
Password
Optional OU The custom OU in which to add the VM. If you don't specify a value for
Setting Value
Path this parameter, the VM is added to the default AAD DC Computers OU.
VM Admin Specify a local administrator account to create on the VM.

Username
VM Admin Specify a local administrator password for the VM. Create a strong local
Password administrator password to protect against password brute-force attacks.
3. 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
２ 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 . Select the option to Deploy to Azure.
2. 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 Azure AD
Domain Services.
Setting Value
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 The user account in the managed domain that should be used to join the
User Name VM to the managed domain, such as contosoadmin@aaddscontoso.com .
This account must be a part of the managed domain.
Domain Join The password for the user account specified in the previous setting.
User Password
Optional OU The custom OU in which to add the VM. If you don't specify a value for
Path this parameter, the VM is added to the default AAD DC Computers OU.
3. 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 or the Azure CLI.
Join a CentOS Linux virtual machine to
an Azure Active Directory Domain
Article • 03/30/2023
To let users sign in to virtual machines (VMs) in Azure using a single set of credentials,
you can join VMs to an Azure Active Directory Domain Services (Azure AD DS) managed
domain. When you join a VM to an Azure AD DS 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

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.
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:
Azure portal
Azure CLI
Azure 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 Azure AD 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.
2. 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 Azure AD.
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
3. 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
2. 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.
3. 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
2. 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

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 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 a CoreOS virtual machine to an
managed domain
Article • 08/23/2022
This article shows you how to join a CoreOS VM to a managed domain.
Prerequisites

Create and connect to a CoreOS Linux VM

If you have an existing CoreOS Linux VM in Azure, connect to it using SSH, then
If you need to create a CoreOS Linux VM, or want to create a test VM for use with this
Azure portal
Azure CLI
Azure PowerShell
Deploy the VM into a different subnet than your Azure AD Domain Services
managed domain.

Console
sudo vi /etc/hosts

coreos is the hostname of your CoreOS VM that you're joining to the managed
domain.
Console
127.0.0.1 coreos coreos.aaddscontoso.com
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:

2. 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 Azure AD.
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.
3. To apply the domain-join configuration, start the SSSD service:
Console
sudo systemctl start sssd.service

coreos.aaddscontoso.com. If you use the Azure Cloud Shell, use the public IP
Console
ssh -l contosoadmin@AADDSCONTOSO.com coreos.aaddscontoso.com
Console
id
Next steps
Join a Red Hat Enterprise Linux virtual
Article • 03/30/2023
This article shows you how to join a Red Hat Enterprise Linux (RHEL) VM to a managed
domain.
Prerequisites

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.
If you need to create a RHEL Linux VM, or want to create a test VM for use with this
Azure portal
Azure CLI
Azure PowerShell
managed domain.

Bash
sudo vi /etc/hosts

rhel is the hostname of your RHEL VM that you're joining to the managed domain.
config
127.0.0.1 rhel rhel.aaddscontoso.com
RHEL 6
） 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 , which will end on
06/2024 .

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

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
Check that the VM is deployed to the same, or a peered, virtual network

in which the managed domain is available.
2. 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
3. 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
Update the sssd.conf file to match the following sample:
config
[sssd]
services = nss, pam, ssh, autofs
domains = AADDSCONTOSO.COM
[domain/AADDSCONTOSO.COM]
id_provider = ad
4. 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
5. Use authconfig to instruct the VM about the AD Linux integration:
Bash
sudo authconfig --enablesssd --enablesssd auth --update
6. 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

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.
Bash
config
When done, save and exit the sshd_conf file using the :wq command of the
editor.
service for your RHEL distro version:
Bash
sudo service sshd restart

privileges
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.
Bash
sudo visudo
config


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
Bash
pwd
user account.
Bash
id

Bash
sudo yum update
Next steps
Join an Ubuntu Linux virtual machine to
Article • 03/30/2023
This article shows you how to join an Ubuntu Linux VM to a managed domain.
Prerequisites

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 Azure AD 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 an Azure 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
If you need to create an Ubuntu Linux VM, or want to create a test VM for use with this
Azure portal
Azure CLI
Azure PowerShell
managed domain.

Bash
sudo vi /etc/hosts

ubuntu is the hostname of your Ubuntu VM that you're joining to the managed
domain.
config
127.0.0.1 ubuntu.aaddscontoso.com ubuntu
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
2. 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.
3. 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

Now that the required packages are installed on the VM and NTP is configured, join the
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

2. 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 Azure AD.
domain:
Bash
sudo kinit -V contosoadmin@AADDSCONTOSO.COM
3. 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 Azure AD DS
to authenticate the request.
1. Open the sssd.conf file with an editor:
Bash
2. 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.
3. 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.

Bash

config
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
1. Open the /etc/pam.d/common-session file in an editor:
Bash
sudo vi /etc/pam.d/common-session
2. 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

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.
Bash
sudo visudo
2. Add the following entry to the end of /etc/sudoers file:
config

%AAD\ DC\ Administrators ALL=(ALL) NOPASSWD:ALL
When done, save and exit the editor using the Ctrl-X command.

ubuntu.aaddscontoso.com. If you use the Azure Cloud Shell, use the public IP
Bash
sudo ssh -l contosoadmin@AADDSCONTOSO.com ubuntu.aaddscontoso.com
Bash
sudo pwd
user account.
Bash
sudo id

Bash
sudo apt-get update
Next steps
Join a SUSE Linux Enterprise virtual
Article • 03/30/2023
This article shows you how to join a SUSE Linux Enterprise (SLE) VM to a managed
domain.
Prerequisites

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.
If you need to create a SLE Linux VM, or want to create a test VM for use with this
Azure portal
Azure CLI
Azure PowerShell
managed domain.

Bash
sudo vi /etc/hosts

linux-q2gr is the hostname of your SLE VM that you're joining to the managed
domain.
config
127.0.0.1 linux-q2gr linux-q2gr.aaddscontoso.com
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
2. Open YaST.
3. 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.
4. 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 Azure portal 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.
5. 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.

2. 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.
3. When ready, select OK.
4. Accept the default settings in the following dialog, then select OK.
5. 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.
6. 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 Azure AD.
To make sure that the current domain is enabled for Samba, activate Overwrite
Samba configuration to work with this AD.
7. To enroll, select OK.
8. 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.
2. 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.
3. To allow users in the managed domain to have home directories on the VM, check
the box for Create Home Directories.
4. 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.
5. 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.
6. Select OK.
7. To save the changes, select OK. Then make sure that the values displayed now are
correct. To leave the dialog, select Cancel.
8. 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.
2. Enter the domain to join at Domain or Workgroup in the Windows Domain

Membership screen. Enter the managed domain name, such as aaddscontoso.com.
3. To use the SMB source for Linux authentication, check the option for Use SMB
Information for Linux Authentication.
4. To automatically create a local home directory for managed domain users on the
VM, check the option for Create Home Directory on Login.
5. Check the option for Offline Authentication to allow your domain users to sign in
even if the managed domain is temporarily unavailable.
6. If you want to change the UID and GID ranges for the Samba users and groups,
select Expert Settings.
7. 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 Azure
portal for your managed domain, such as 10.0.2.4 and 10.0.2.5.
8. Select OK and confirm the domain join when prompted for it.
9. 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.

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>

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 Azure AD and Linux are in sync. You can do this by
adding the Azure AD server to the NTP service:
a. Add the following line to /etc/ntp.conf :
config
server aaddscontoso.com
b. 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

Bash
config
service:
Bash
sudo systemctl restart sshd

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

Bash
sudo visudo
config


linux-q2gr.aaddscontoso.com. If you use the Azure Cloud Shell, use the public IP
Bash
sudo ssh -l contosoadmin@AADDSCONTOSO.com linux-q2gr.aaddscontoso.com
Bash
sudo pwd
user account.
Bash
sudo id

Bash
sudo zypper update
Next steps
Active Directory authentication non
domain joined Linux Virtual Machines
Article • 04/09/2023
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
７ 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
Example sssd.conf:
config
[sssd]
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.

Deploy Azure AD Application Proxy for
secure access to internal applications in
Article • 01/30/2023
With Azure AD Domain Services (Azure AD DS), you can lift-and-shift legacy applications
running on-premises into Azure. Azure Active Directory (AD) Application Proxy then
helps you support remote workers by securely publishing those internal applications
part of an Azure AD DS managed domain so they can be accessed over the internet.
If you're new to the Azure AD Application Proxy and want to learn more, see How to
provide secure remote access to internal applications.
This article shows you how to create and configure an Azure AD Application Proxy
connector to provide secure access to applications in a managed domain.
Before you begin


An Azure AD Premium license is required to use the Azure AD Application
Proxy.
managed domain.
Create a domain-joined Windows VM

To route traffic to applications running in your environment, you install the Azure AD
Application Proxy connector component. This Azure AD 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 Azure AD 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 Azure AD Application Proxy connector, complete the following
steps:
users within the managed domain. The VMs for Azure AD Application Proxy and
that run your applications must be a part of the custom OU, not the default AAD
DC Computers OU.
2. Domain-join the virtual machines, both the one that runs the Azure AD 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.
Download the Azure AD Application Proxy

connector
Perform the following steps to download the Azure AD Application Proxy connector. The
setup file you download is copied to your App Proxy VM in the next section.
1. Sign in to the Azure portal with a user account that has Enterprise administrator
permissions in Azure AD.
2. Search for and select Azure Active Directory at the top of the portal, then choose
Enterprise applications.
3. 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.
4. On the download page, accept the license terms and privacy agreement, then
select Accept terms & Download.
Install and register the Azure AD Application
Proxy connector
With a VM ready to be used as the Azure AD Application Proxy connector, now copy
and run the setup file downloaded from the Azure portal.
1. Copy the Azure AD Application Proxy connector setup file to your VM.
2. Run the setup file, such as AADApplicationProxyConnectorInstaller.exe. Accept the

software license terms.
3. During the install, you're prompted to register the connector with the Application
Proxy in your Azure AD directory.
Provide the credentials for a global administrator in your Azure AD directory.

The Azure AD 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 Azure AD 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.
4. At the end of the setup, a note is shown for environments with an outbound proxy.
To configure the Azure AD 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 .
5. On the Application proxy page in the Azure portal, 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 Azure AD

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
Enable resource-based Kerberos constrained

delegation
If you want to use single sign-on to your applications using integrated Windows
authentication (IWA), grant the Azure AD 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 Azure
Active Directory Domain Services.
７ Note
You must be signed in to a user account that's a member of the Azure AD DC

administrators group in your Azure AD 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 AAD DC Computers container.
Use the Get-ADComputer to retrieve the settings for the computer on which the Azure
AD Application Proxy connector is installed. From your domain-joined management VM
and logged in as user account that's a member of the Azure AD 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 Azure AD
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 Azure AD Application Proxy use
the Set-ADComputer PowerShell cmdlet to configure resource-based KCD. In the
following example, the Azure AD 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 Azure AD Application Proxy connectors, you must configure
resource-based KCD for each connector instance.
Next steps
With the Azure AD Application Proxy integrated with Azure AD DS, publish applications
for users to access. For more information, see publish applications using Azure AD
Application Proxy.
Configure Azure Active Directory
Domain Services to support user profile
synchronization for SharePoint Server
Article • 01/30/2023
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 an Azure Active Directory Domain Services (Azure AD
DS) managed domain. For more information, see user profile synchronization in
SharePoint Server.
This article shows you how to configure Azure AD DS to allow the SharePoint Server user
profile sync service.
Before you begin


domain.
Azure AD 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. 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.
Service accounts overview

In a managed domain, a security group named AAD DC Service Accounts exists as part
of the Users organizational unit (OU). Members of this security group are delegated the
following privileges:
Replicate Directory Changes privilege on the root DSE.

Replicate Directory Changes privilege on the Configuration naming context
( cn=configuration container).
The AAD 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 AAD DC Service Accounts group.
From your Azure AD DS management VM, complete the following steps:
７ Note
To edit group membership in a managed domain, you must be signed in to a user

2. To manage group membership, select Active Directory Administrative Center

from the list of administrative tools.
3. In the left pane, choose your managed domain, such as aaddscontoso.com. A list of
existing OUs and resources is shown.
4. Select the Users OU, then choose the AAD DC Service Accounts security group.
5. Select Members, then choose Add....
6. Enter the name of the SharePoint service account, then select OK. In the following
example, the SharePoint service account is named spadmin:
Common errors and troubleshooting
steps for Azure Active Directory Domain
Services
Article • 01/30/2023
As a central part of identity and authentication for applications, Azure Active Directory
Domain Services (Azure AD DS) 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 for
additional troubleshooting assistance.
This article provides troubleshooting steps for common issues in Azure AD DS.
You cannot enable Azure AD Domain Services

for your Azure AD directory
If you have problems enabling Azure AD DS, 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 Domain name
name that is not in use. conflict in the virtual
network
Domain Services could not be enabled in this Azure AD tenant. The service Domain Services
does not have adequate permissions to the application called 'Azure AD doesn't have
Domain Services Sync'. Delete the application called 'Azure AD Domain adequate
Services Sync' and then try to enable Domain Services for your Azure AD permissions to the
tenant. Azure AD Domain
Services Sync
application
Domain Services could not be enabled in this Azure AD tenant. The Domain The Domain Services
Services application in your Azure AD tenant does not have the required application isn't
permissions to enable Domain Services. Delete the application with the configured properly
application identifier d87dcbc6-a371-462e-88e3-28ad15ec4e64 and then in your Azure AD
try to enable Domain Services for your Azure AD tenant. tenant
Sample error Message Resolution
Domain Services could not be enabled in this Azure AD tenant. The The Microsoft Graph
Microsoft Azure AD application is disabled in your Azure AD tenant. Enable application is
the application with the application identifier 00000002-0000-0000-c000- disabled in your
000000000000 and then try to enable Domain Services for your Azure AD Azure AD tenant
tenant.
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 an Azure AD
DS 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
de-provision the existing AD DS domain and then try again to enable Azure AD DS.
Inadequate permissions
Error message
Domain Services could not be enabled in this Azure AD tenant. The service does not have
adequate permissions to the application called 'Azure AD Domain Services Sync'. Delete
the application called 'Azure AD Domain Services Sync' and then try to enable Domain
Services for your Azure AD tenant.
Resolution
Check if there's an application named Azure AD Domain Services Sync in your Azure AD
directory. If this application exists, delete it, then try again to enable Azure AD DS. To
check for an existing application and delete it if needed, complete the following steps:
1. In the Azure portal, select Azure Active Directory from the left-hand navigation
menu.
2. Select Enterprise applications. Choose All applications from the Application Type
drop-down menu, then select Apply.
3. In the search box, enter Azure AD Domain Services Sync. If the application exists,
select it and choose Delete.
4. Once you've deleted the application, try to enable Azure AD DS again.
Invalid configuration
Error message
Domain Services could not be enabled in this Azure AD tenant. The Domain Services
application in your Azure AD 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 Azure AD
tenant.
Resolution
Check if you have an existing application named

AzureActiveDirectoryDomainControllerServices with an application identifier of
d87dcbc6-a371-462e-88e3-28ad15ec4e64 in your Azure AD directory. If this application
exists, delete it and then try again to enable Azure AD DS.
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 Azure AD tenant. The Microsoft Azure AD
application is disabled in your Azure AD tenant. Enable the application with the
application identifier 00000002-0000-0000-c000-000000000000 and then try to enable
Domain Services for your Azure AD tenant.
Resolution
Check if you've disabled an application with the identifier 00000002-0000-0000-c000-

000000000000. This application is the Microsoft Azure AD application and provides
Graph API access to your Azure AD tenant. To synchronize your Azure AD tenant, this
application must be enabled.
To check the status of this application and enable it if needed, complete the following
steps:
menu.
3. In the search box, enter 00000002-0000-0000-c000-00000000000. Select the
application, then choose Properties.
4. If Enabled for users to sign-in is set to No, set the value to Yes, then select Save.
5. Once you've enabled the application, try to enable Azure AD DS again.
Users are unable to sign in to the Azure AD
If one or more users in your Azure AD 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 Azure AD DS. Make sure this UPN is configured correctly in
Azure AD.
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 or for hybrid environments using Azure AD
Connect.
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 Azure AD

Connect .
You've configured Azure AD Connect to perform a full synchronization.
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
Microsoft Azure AD Sync Service. From your Azure AD 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 Azure
AD DS. 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 Azure AD. 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, not in Azure AD.
You can also configure fine grained password policies to change the default
lockout threshold and duration.
External accounts - Check that the affected user account isn't an external account
in the Azure AD tenant. Examples of external accounts include Microsoft accounts
like dee@live.com or user accounts from an external Azure AD directory. Azure AD
DS 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. If any
alerts are shown, troubleshoot and resolve them.
Users removed from your Azure AD tenant are

not removed from your managed domain
Azure AD protects against accidental deletion of user objects. When you delete a user
account from an Azure AD 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 Azure AD directory. To remove the user
account from the managed domain, you need to forcibly delete it from the Azure AD
tenant.
To fully remove a user account from a managed domain, delete the user permanently
from your Azure AD tenant using the Remove-MsolUser PowerShell cmdlet with the -
RemoveFromRecycleBin parameter.
Next steps
If you continue to have issues, open an Azure support request for additional
troubleshooting assistance.
Troubleshoot domain-join problems
with an Azure Active Directory Domain
Article • 01/30/2023
When you try to join a virtual machine (VM) or connect an application to an Azure
Active Directory Domain Services (Azure AD DS) 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 Azure AD DS managed domain.
Start to troubleshoot 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.
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.
2. 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.
3. 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 Azure AD
DS 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.
2. Review the required ports and network security group rules. Make sure that no
network security group rules applied to the VM or virtual network you're
connecting from block these network ports.
3. 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
Azure AD.
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.
2. Try to use the credentials for a user account that's a part of the managed domain
to join VMs to the managed domain.
3. Make sure that you've enabled password synchronization 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.
If you still have problems joining your VM to the managed domain, find help and open a
support ticket for Azure Active Directory.
Troubleshoot account lockout problems
Article • 01/30/2023
To prevent repeated malicious sign-in attempts, an Azure Active Directory Domain

Services (Azure AD DS) 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 an Azure AD DS 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 Azure AD are only affected by the password policies within the
managed domain. Their accounts in Azure AD 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 Azure AD DS versus synchronized in from Azure AD, see
Configure password and account lockout policies.
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 Azure AD 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 Azure AD DS. 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
View all the account lockout events for the last seven days for the account named driley.
Kusto
| where "driley" == tolower(extract("Logon Account:\t(.+[0-9A-Za-
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
| where TimeGenerated >= datetime(2020-06-26 09:00) and TimeGenerated <=
datetime(2020-07-01)
| 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 Azure AD DS.
03/04 19:07:29 [LOGON] [10752] contoso: SamLogon: Transitive Network logon of

contoso\Nagappan.Veerappan from (via LOB11-RADIUS) Entered

contoso\Nagappan.Veerappan from (via LOB11-RADIUS) Returns 0xC000006A
contoso\Nagappan.Veerappan from (via LOB11-RADIUS) Entered

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.
If you have modified the default NSG already, follow Port 3389 - management using
remote desktop.
To enable Netlogon log on any server, follow Enabling debug logging for the Netlogon
service.
Next steps
For more information on fine-grained password policies to adjust account lockout
thresholds, see Configure password and account lockout policies.
Troubleshoot account sign-in problems
Article • 01/30/2023
The most common reasons for a user account that can't sign in to an Azure Active
Directory Domain Services (Azure AD DS) managed domain include the following
scenarios:
The account isn't synchronized into Azure AD DS yet.

Azure AD DS doesn't have the password hashes to let the account sign in.
The account is locked out.
 Tip
Azure AD DS can't synchronize in credentials for accounts that are external to the
Azure AD tenant. External users can't sign in to the Azure AD DS managed domain.
Account isn't synchronized into Azure AD DS

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 Azure AD 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 Azure AD Connect to synchronize on-premises

directory data into Azure AD, make sure that you run the latest version of Azure AD
Connect and have configured Azure AD Connect to perform a full synchronization after
enabling Azure AD DS. If you disable Azure AD DS and then re-enable, you have to
follow these steps again.
If you continue to have issues with accounts not synchronizing through Azure AD
Connect, restart the Azure AD Sync Service. From the computer with Azure AD 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'
Azure AD DS doesn't have the password hashes

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.
Hybrid environments with on-premises synchronization

For hybrid environments using Azure AD Connect to synchronize from an on-premises
AD DS environment, you can locally generate and synchronize the required NTLM or
Kerberos password hashes into Azure AD. After you create your managed domain,
enable password hash synchronization to Azure Active Directory Domain Services.
Without completing this password hash synchronization step, you can't sign in to an
account using the managed domain. If you disable Azure AD DS and then re-enable,
you have to follow those steps again.
For more information, see How password hash synchronization works for Azure AD DS.
Cloud-only environments with no on-premises

synchronization
Managed domains with no on-premises synchronization, only accounts in Azure AD,
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 Azure AD DS?
No, the password has not been changed.

Change the password for the account to generate the required password
hashes, then wait for 15 minutes before you try to sign in again.
If you disable Azure AD DS 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 an Azure AD 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 Azure AD DS.
Next steps
Resolve mismatched directory errors for
existing Azure Active Directory Domain
Services managed domains
Article • 01/30/2023
If an Azure Active Directory Domain Services (Azure AD DS) 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 Azure AD
directory.
This article explains why the error occurs and how to resolve it.
What causes this error?

A mismatched directory error happens when an Azure AD DS managed domain and
virtual network belong to two different Azure AD tenants. For example, you may have a
managed domain called aaddscontoso.com that runs in Contoso's Azure AD tenant.
However, the Azure virtual network for managed domain is part of the Fabrikam Azure
AD tenant.
Azure role-based access control (Azure RBAC) is used to limit access to resources. When
you enable Azure AD DS in an Azure AD tenant, credential hashes are synchronized to
the managed domain. This operation requires you to be a tenant admin for the Azure
AD 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 Azure AD DS
uses, the managed domain and the virtual network must belong to the same Azure AD
tenant.
The following rules apply for deployments:
An Azure AD directory may have multiple Azure subscriptions.

An Azure subscription may have multiple resources such as virtual networks.
A single managed domain is enabled for an Azure AD directory.
A managed domain can be enabled on a virtual network belonging to any of the
Azure subscriptions within the same Azure AD tenant.
Valid configuration
In the following example deployment scenario, the Contoso managed domain is
enabled in the Contoso Azure AD tenant. The managed domain is deployed in a virtual
network that belongs to an Azure subscription owned by the Contoso Azure AD tenant.
Both the managed domain and the virtual network belong to the same Azure AD 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 Azure AD tenant. However, the managed domain is deployed in a virtual
network that belongs to an Azure subscription owned by the Fabrikam Azure AD tenant.
The managed domain and the virtual network belong to two different Azure AD tenants.
This example configuration is a mismatched tenant and isn't supported. The virtual
network must be moved to the same Azure AD tenant as the managed domain.
Resolve mismatched tenant error
The following two options resolve the mismatched directory error:
First, delete the managed domain from your existing Azure AD directory. Then,
create a replacement managed domain in the same Azure AD 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 containing the virtual network to the same Azure AD
directory as the managed domain.
Next steps
For more information on troubleshooting issues with Azure AD DS, see the
troubleshooting guide.
Understand the health states and
resolve suspended domains in Azure
Article • 01/30/2023
When Azure Active Directory Domain Services (Azure AD DS) 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 Azure AD DS 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
Needs attention
Suspended
Deleted
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 Azure Active Directory 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 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.
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 Azure Active Directory 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 Azure AD DS. For example, the alert AADDS104:
Network Error 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 Azure AD stops.
How do you know if your managed domain is

suspended?
You see an alert on the Azure AD DS Health page in the Azure portal 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 Azure portal, search for and select Domain services.

2. Choose your managed domain from the list, such as aaddscontoso.com, then select
Health.
3. Select the alert, such as AADDS503 or AADDS504, depending on the cause of
suspension.
4. 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 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 Azure AD DS.
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.
Troubleshoot secure LDAP connectivity
issues to an Azure Active Directory
Article • 01/30/2023
Applications and services that use lightweight directory access protocol (LDAP) to
communicate with Azure Active Directory Domain Services (Azure AD DS) can be
configured to use secure LDAP. 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 Azure AD DS.
Common connection issues

If you have trouble connecting to an Azure AD 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.
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 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.
Next steps
If you still have issues, open an Azure support request for additional troubleshooting
assistance.
Known issues: Common alerts and
resolutions in Azure Active Directory
Domain Services
Article • 03/15/2023
As a central part of identity and authentication for applications, Azure Active Directory
Domain Services (Azure AD DS) 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 for additional
troubleshooting assistance.
This article provides troubleshooting information for common alerts in Azure AD DS.
AADDS100: Missing directory
Alert message
The Azure AD 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 Azure AD
directory and the old Azure AD directory that's associated with Azure AD DS is deleted.
This error is unrecoverable. To resolve the alert, delete your existing managed domain
and recreate it in your new directory. If you have trouble deleting the managed domain,
open an Azure support request for additional troubleshooting assistance.
AADDS101: Azure AD B2C is running in this

directory
Alert message
Azure AD Domain Services cannot be enabled in an Azure AD B2C Directory.
Resolution
Azure AD DS automatically synchronizes with an Azure AD directory. If the Azure AD
directory is configured for B2C, Azure AD DS can't be deployed and synchronized.
To use Azure AD DS, you must recreate your managed domain in a non-Azure AD B2C
directory using the following steps:
1. Delete the managed domain from your existing Azure AD directory.

2. Create a new Azure AD directory that isn't an Azure AD B2C directory.
3. Create a replacement managed domain.
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 Azure AD Domain
Services is in a public IP range. Azure AD 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 .
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 Azure AD DS.
７ Note
If you own the IP address range in the internet that is configured in your virtual
network, this alert can be ignored. However, Azure AD Domain Services can't
commit to the SLA 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 from your directory.

2. To update the virtual network IP address range, search for and select Virtual
network in the Azure portal. Select the virtual network for Azure AD DS that
incorrectly has a public IP address range set.
3. Under Settings, select Address Space.
4. Update the address range by choosing the existing address range and editing it, or
adding an additional address range. Make sure the new IP address range is in a
private IP range. When ready, Save the changes.
5. Select Subnets in the left-hand navigation.
6. Choose the subnet you wish to edit, or create an additional subnet.
7. Update or specify a private IP address range then Save your changes.
8. Create a replacement managed domain. Make sure you pick the updated virtual
network subnet with a private IP address range.
removes the alert.
AADDS106: Your Azure subscription is not

found
Alert message
Your Azure subscription associated with your managed domain has been deleted. Azure
AD Domain Services requires an active subscription to continue functioning properly.
Resolution
Azure AD DS 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.

2. Delete the managed domain from your existing Azure AD directory.
3. Create a replacement managed domain.
AADDS107: Your Azure subscription is disabled
Alert message
Your Azure subscription associated with your managed domain is not active. Azure AD
Domain Services requires an active subscription to continue functioning properly.
Resolution
Azure AD DS 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.

2. Once the subscription is renewed, an Azure AD DS 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 Azure AD Domain Services has been moved to another directory.
Azure AD Domain Services needs to have an active subscription in the same directory to
function properly.
Resolution
Azure AD DS 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 from the existing directory and create a replacement managed domain in the
chosen subscription.
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 Azure AD Domain Services to function properly.
Resolution
Azure AD DS creates additional 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 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 Azure portal, search for and select Domain Services. Choose your managed
domain, such as aaddscontoso.com.
2. In the left-hand navigation, select Health.
3. In the health page, select the alert with the ID AADDS109.
4. 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 and then create a replacement managed domain 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 Azure AD 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 Azure AD DS 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 additional resources, such as your own VMs,
into the same virtual network subnet as the managed domain.
and recreate it. If you have trouble deleting the managed domain, open an Azure
support request for additional troubleshooting assistance.
AADDS111: Service principal unauthorized
Alert message
A service principal that Azure AD 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 Azure 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. Azure AD 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 Azure AD DS 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 additional 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 from your directory.

2. To update the virtual network IP address range, search for and select Virtual
network in the Azure portal. Select the virtual network for the managed domain
that has the small IP address range.
3. Under Settings, select Address Space.
4. Update the address range by choosing the existing address range and editing it, or
adding an additional address range. Make sure the new IP address range is large
enough for the managed domain's subnet range. When ready, Save the changes.
5. Select Subnets in the left-hand navigation.
6. Choose the subnet you wish to edit, or create an additional subnet.
7. Update or specify a large enough IP address range then Save your changes.
8. Create a replacement managed domain. Make sure you pick the updated virtual
network subnet with a large enough IP address range.
removes the alert.
AADDS113: Resources are unrecoverable
Alert message
The resources used by Azure AD Domain Services were detected in an unexpected state
and cannot be recovered.
Resolution
Azure AD DS creates additional 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 Azure AD DS.
This alert is generated when one of these required resources is modified and can't
automatically be recovered by Azure AD DS. To resolve the alert, open an Azure support
request to fix the instance.
AADDS114: Subnet invalid
Alert message
The subnet selected for deployment of Azure AD Domain Services is invalid, and cannot be
used.
Resolution
and recreate it. If you have trouble deleting the managed domain, open an Azure
support request for additional troubleshooting assistance.
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
Azure AD DS is a managed service, the Azure platform needs the ability to make
configuration changes. If a resource lock is applied on some of the Azure AD DS
components, the Azure platform can't perform its management tasks.
To check for resource locks on the Azure AD DS 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 Azure portal. These operation logs should indicate why an
operation is failing and where a resource lock is applied.
2. 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 Azure AD DS is a managed service, the Azure
platform needs the ability to make configuration changes. If a policy is applied on some
of the Azure AD DS components, the Azure platform may not be able to perform its
management tasks.
To check for applied policies on the Azure AD DS 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
Azure portal. These operation logs should indicate why an operation is failing and
where a restrictive policy is applied.
2. 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 Azure AD 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 .
Review the Azure AD DS Health alert and see which Azure AD extension properties
failed to onboard successfully. Navigate to the Custom Attributes page to find the
expected Azure AD DS 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.
2. 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.
3. Select Add and choose the desired attributes again, then click Save.
Upon successful onboarding, Azure AD DS 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 Azure
AD DS Health and verify the Synchronization with Azure AD 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 Azure AD 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 Azure AD DS health for any alerts that indicate problems in the configuration
of the managed domain. Problems with the network configuration can block the
synchronization from Azure AD. 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 and the network requirements for Azure AD DS.
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 or hybrid users from on-prem.
AADDS501: A backup has not been taken in a

while
Alert message
The managed domain was last backed up on [date].
Resolution
Check the Azure AD DS health 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 Azure AD DS.
Azure AD DS 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.

2. Once the subscription is renewed, an Azure AD DS 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

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

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 if you need assistance.
Next steps
assistance.
Known issues: Network configuration alerts in
Article • 01/30/2023
To let applications and services correctly communicate with an Azure Active Directory Domain Services (Azure
AD DS) 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 an Azure AD DS 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 Azure AD DS. 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 Azure AD directory and Azure AD DS 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 Azure AD DS 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 Deny1
65000 AllVnetInBound Any Any VirtualNetwork VirtualNetwork Allow
65001 AllowAzureLoadBalancerInBound Any Any AzureLoadBalancer Any Allow
65500 DenyAllInBound Any Any Any Any Deny
1Optional 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. 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
Azure AD DS 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 Azure portal, search for and select Network security groups.
2. Choose the network security group associated with your managed domain, such as AADDS-
contoso.com-NSG.
3. 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:
2. Choose the network security group associated with your managed domain, such as AADDS-
contoso.com-NSG.
3. Under Settings in the left-hand panel, click Inbound security rules or Outbound security rules depending
on which rule you need to add.
4. 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 for additional troubleshooting assistance.
Known issues: Service principal alerts in
Article • 01/30/2023
Service principals are applications that the Azure platform uses to manage, update, and
maintain an Azure Active Directory Domain Services (Azure AD DS) 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 Azure AD Domain Services to function properly has been
deleted from your Azure AD 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:
menu.
3. 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
443155a6-77f3-45e3-882b-22b3a8d431fb Re-register the Microsoft.AAD namespace
abba844e-bc0e-44b0-947a-dc74e5d09022 Re-register the Microsoft.AAD namespace
d87dcbc6-a371-462e-88e3-28ad15ec4e64 Re-register the Microsoft.AAD namespace
Recreate a missing Service Principal

If application ID 2565bd9d-da50-47d4-8b85-4c97f669dc36 is missing from your Azure
AD 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.
1. If needed, install the Azure AD PowerShell module and import it as follows:
PowerShell
Install-Module AzureAD
Import-Module AzureAD
2. Now recreate the service principal using the New-AzureAdServicePrincipal cmdlet:
PowerShell
New-AzureAdServicePrincipal -AppId "2565bd9d-da50-47d4-8b85-

4c97f669dc36"
removes the alert.
Re-register the Microsoft AAD namespace

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

2. Choose the subscription associated with your managed domain.
3. From the left-hand navigation, choose Resource Providers.
4. Search for Microsoft.AAD, then select Re-register.
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
Azure AD Domain Services resources needed to service your managed domain.
Synchronization of passwords on your managed domain could be affected.
Azure AD DS automatically synchronizes user accounts and credentials from Azure AD. If
there's a problem with the Azure AD application used for this process, credential
synchronization between Azure AD DS and Azure AD fails.
Resolution
To recreate the Azure AD application used for credential synchronization, use Azure AD
PowerShell to complete the following steps. For more information, see install Azure AD
PowerShell.
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
assistance.
Known issues: Secure LDAP alerts in
Article • 01/30/2023
Applications and services that use lightweight directory access protocol (LDAP) to
communicate with Azure Active Directory Domain Services (Azure AD DS) can be
configured to use secure LDAP. 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
Azure AD DS.
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 additional 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:
2. Choose the network security group associated with your managed domain, such as
AADDS-contoso.com-NSG, then select Inbound security rules
3. Select + Add to create a rule for TCP port 636. If needed, select Advanced in the
window to create a rule.
4. 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.
5. Choose Any as the Destination, then enter 636 for Destination port ranges.
6. Set the Protocol as TCP and the Action to Allow.
7. Specify the priority for the rule, then enter a name such as RestrictLDAPS.
8. When ready, select Add to create the rule.
removes the alert.
 Tip
TCP port 636 isn't the only rule needed for Azure AD DS to run smoothly. To learn
more, see the Azure AD DS 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. Apply the replacement certificate to Azure AD DS, and
distribute the certificate to any clients that connect using secure LDAP.
Next steps
assistance.
Az.ADDomainServices
Reference
Microsoft Azure PowerShell: AdDomainServices cmdlets
Active Directory Domain Service

Get-AzADDomainService The Get Domain Service operation retrieves a json
representation of the Domain Service.
New-AzADDomainService The Create Domain Service operation creates a new

domain service with the specified parameters. If the
specific service already exists, then any patchable
properties will be updated and any immutable properties
will remain unchanged.
New- Create an in-memory object for ForestTrust.

AzADDomainServiceForestTrustObject
New- Create an in-memory object for ReplicaSet.

AzADDomainServiceReplicaSetObject
Remove-AzADDomainService The Delete Domain Service operation deletes an existing

Domain Service.
Update-AzADDomainService The Update Domain Service operation can be used to

update the existing deployment. The update call only
supports the properties listed in the PATCH body.
Azure Policy built-in definitions for
Article • 08/08/2023
This page is an index of Azure Policy built-in policy definitions for Azure Active Directory
Domain Services. For additional Azure Policy built-ins for other services, see Azure Policy
built-in definitions.
The name of each built-in policy definition links to the policy definition in the Azure
portal. Use the link in the Version column to view the source on the Azure Policy GitHub
repo .

Name Description Effect(s) Version
(Azure portal) (GitHub)
Azure Active Use TLS 1.2 only mode for your managed domains. Audit, Deny, 1.1.0
Directory By default, Azure AD Domain Services enables the Disabled
Domain use of ciphers such as NTLM v1 and TLS v1. These
Services ciphers may be required for some legacy
managed applications, but are considered weak and can be
domains disabled if you don't need them. When TLS 1.2
should use only mode is enabled, any client making a request
TLS 1.2 only that is not using TLS 1.2 will fail. Learn more at
mode https://docs.microsoft.com/azure/active-directory-
domain-services/secure-your-domain.
Azure Active Azure Private Link lets you connect your virtual AuditIfNotExists, 1.0.0
Directory networks to Azure services without a public IP Disabled
should use address at the source or destination. The Private
private link Link platform handles the connectivity between
to access the consumer and services over the Azure
Azure backbone network. By mapping private endpoints
services to Azure AD, you can reduce data leakage risks.
Learn more at:
https://aka.ms/privateLinkforAzureADDocs . It
should be only used from isolated VNETs to Azure
services, with no access to the Internet or other
services (M365).
Configure Private endpoints connect your virtual networks to DeployIfNotExists, 1.0.0

Private Link Azure services without a public IP address at the Disabled
for Azure AD source or destination. By mapping private
endpoints to Azure AD, you can reduce data
Name Description Effect(s) Version
(Azure portal) (GitHub)
with private leakage risks. Learn more at:

endpoints https://aka.ms/privateLinkforAzureADDocs . It
should be only used from isolated VNETs to Azure
services, with no access to the Internet or other
services (M365).
Next steps
See the built-ins on the Azure Policy GitHub repo .
Review the Azure Policy definition structure.
Review Understanding policy effects.
Frequently asked questions (FAQs)
about Azure Active Directory (AD)
Domain Services
FAQ
This page answers frequently asked questions about Azure Active Directory Domain
Services.
Configuration
Can I create multiple managed domains for a
single Azure AD directory?
No. You can only create a single managed domain serviced by Azure AD Domain
Services for a single Azure AD directory.
Can I enable Azure AD Domain Services in a

Classic virtual network?
Classic virtual networks aren't supported.
For more information, see the official deprecation notice .
Can I enable Azure AD Domain Services in an

Azure Resource Manager virtual network?
Yes. Azure AD Domain Services can be enabled in an Azure Resource Manager virtual
network. Classic Azure virtual networks are no longer available when you create a
managed domain.
Can I enable Azure AD Domain Services in an

Azure CSP (Cloud Solution Provider)
subscription?
Yes. For more information, see how to enable Azure AD Domain Services in Azure CSP
subscriptions.
Can I enable Azure AD Domain Services in a

federated Azure AD directory? I do not
synchronize password hashes to Azure AD. Can I
enable Azure AD Domain Services for this
directory?
No. To authenticate users via NTLM or Kerberos, Azure AD Domain Services needs
access to the password hashes of user accounts. In a federated directory, password
hashes aren't stored in the Azure AD directory. Therefore, Azure AD Domain Services
doesn't work with such Azure AD directories.
However, if you're using Azure AD Connect for password hash synchronization, you can
use Azure AD Domain Services because the password hash values are stored in Azure
AD.
Can I make Azure AD Domain Services available

in multiple virtual networks within my
subscription?
The service itself doesn't directly support this scenario. Your managed domain is
available in only one virtual network at a time. However, you can configure connectivity
between multiple virtual networks to expose Azure AD Domain Services to other virtual
networks. For more information, see how to connect virtual networks in Azure using
VPN gateways or virtual network peering.
Can I enable Azure AD Domain Services using

PowerShell?
Yes. For more information, see how to enable Azure AD Domain Services using
PowerShell.
Can I enable Azure AD Domain Services using a

Resource Manager Template?
Yes, you can create an Azure AD Domain Services managed domain using a Resource
Manager template. A service principal and Azure AD group for administration must be
created using the Azure portal or Azure PowerShell before the template is deployed. For
more information, see Create an Azure AD DS managed domain using an Azure
Resource Manager template. When you create an Azure AD Domain Services managed
domain in the Azure portal, there's also an option to export the template for use with
additional deployments.
Can I add domain controllers to an Azure AD

Domain Services managed domain?
No. The domain provided by Azure AD Domain Services is a managed domain. You
don't need to provision, configure, or otherwise manage domain controllers for this
domain. These management activities are provided as a service by Microsoft. Therefore,
you can't add additional domain controllers (read-write or read-only) for the managed
domain.
Can guest users be invited to my directory use

Azure AD Domain Services?
No. Guest users invited to your Azure AD directory using the Azure AD B2B invite
process are synchronized into your Azure AD Domain Services managed domain.
However, passwords for these users aren't stored in your Azure AD directory. Therefore,
Azure AD Domain Services has no way to synchronize NTLM and Kerberos hashes for
these users into your managed domain. Such users can't sign in or join computers to the
managed domain.
Can a two-way forest trust be created between

Azure AD DS and an on-premises forest?
No. A managed domain supports up to five one-way outbound forest trusts to on-
premises forests.
Can I move a managed domain?

After you create an Azure AD Domain Services managed domain, you can't move it to a
different subscription, resource group, or region. As a workaround, you can delete the
managed domain by using PowerShell or the Azure portal and re-create it with your
desired setup. No restore operations can be provided while the managed domain is re-
created.
Can I rename an existing Azure AD Domain

Services domain name?
No. After you create an Azure AD Domain Services managed domain, you can't change
the DNS domain name. Choose the DNS domain name carefully when you create the
managed domain. For considerations when you choose the DNS domain name, see the
tutorial to create and configure an Azure AD Domain Services managed domain.
Does Azure AD Domain Services include high

availability options?
Yes. Each Azure AD Domain Services managed domain includes two domain controllers.
You don't manage or connect to these domain controllers, they're part of the managed
service. If you deploy Azure AD Domain Services into a region that supports Availability
Zones, the domain controllers are distributed across zones. In regions that don't support
Availability Zones, the domain controllers are distributed across Availability Sets. You
have no configuration options or management control over this distribution. For more
information, see Availability options for virtual machines in Azure.
Administration and operations

Can I connect to the domain controller for my
managed domain using Remote Desktop?
No. You don't have permissions to connect to domain controllers for the managed
domain using Remote Desktop. Members of the Azure AD DC Administrators group can
administer the managed domain using AD administration tools such as the Active
Directory Administration Center (ADAC) or AD PowerShell. These tools are installed
using the Remote Server Administration Tools feature on a Windows server joined to the
managed domain. For more information, see Create a management VM to configure
and administer an Azure AD Domain Services managed domain.
I've enabled Azure AD Domain Services. What

user account do I use to domain join machines
to this domain?
Any user account that's part of the managed domain can join a VM. Members of the
Azure AD DC Administrators group are granted remote desktop access to machines that
have been joined to the managed domain.
Do I have domain administrator privileges for

the managed domain provided by Azure AD
Domain Services?
No. You aren't granted administrative privileges on the managed domain. Domain
Administrator and Enterprise Administrator privileges aren't available for you to use
within the domain. Members of the domain administrator or enterprise administrator
groups in your on-premises Active Directory are also not granted domain / enterprise
administrator privileges on the managed domain.
Can I modify group memberships using LDAP or

other AD administrative tools on managed
domains?
Users and groups that are synchronized from Azure Active Directory to Azure AD
Domain Services cannot be modified because their source of origin is Azure Active
Directory. This includes moving users or groups from the AADDC Users managed
organizational unit to a custom organizational unit. Any user or group originating in the
managed domain may be modified.
How long does it take for changes I make to my

Azure AD directory to be visible in my managed
domain?
Changes made in your Azure AD directory using either the Azure AD UI or PowerShell
are automatically synchronized to your managed domain. This synchronization process
runs in the background. There's no defined time period for this synchronization to
complete all the object changes.
Can I extend the schema of the managed

domain provided by Azure AD Domain Services?
No. The schema is administered by Microsoft for the managed domain. Schema
extensions aren't supported by Azure AD Domain Services.
Can I modify or add DNS records in my managed

domain?
Yes. Members of the Azure AD DC Administrators group are granted DNS Administrator
privileges to modify DNS records in the managed domain. Those users can use the DNS
Manager console on a machine running Windows Server joined to the managed domain
to manage DNS. To use the DNS Manager console, install DNS Server Tools, which are
part of the Remote Server Administration Tools optional feature on the server. For more
information, see Administer DNS in an Azure AD Domain Services managed domain.
What is the password lifetime policy on a

managed domain?
The default password lifetime on an Azure AD Domain Services managed domain is 90
days. This password lifetime is not synchronized with the password lifetime configured
in Azure AD. Therefore, you may have a situation where users' passwords expire in your
managed domain, but are still valid in Azure AD. In such scenarios, users need to change
their password in Azure AD and the new password will synchronize to your managed
domain. If you want to change the default password lifetime in a managed domain, you
can create and configure custom password policies..
Additionally, the Azure AD password policy for DisablePasswordExpiration is

synchronized to a managed domain. When DisablePasswordExpiration is applied to a
user in Azure AD, the UserAccountControl value for the synchronized user in the
managed domain has DONT_EXPIRE_PASSWORD applied.
When users reset their password in Azure AD, the forceChangePasswordNextSignIn=True

attribute is applied. A managed domain synchronizes this attribute from Azure AD.
When the managed domain detects forceChangePasswordNextSignIn is set for a
synchronized user from Azure AD, the pwdLastSet attribute in the managed domain is
set to 0, which invalidates the currently set password.
Does Azure AD Domain Services provide AD

account lockout protection?
Yes. Five invalid password attempts within 2 minutes on the managed domain cause a
user account to be locked out for 30 minutes. After 30 minutes, the user account is
automatically unlocked. Invalid password attempts on the managed domain don't lock
out the user account in Azure AD. The user account is locked out only within your Azure
AD Domain Services managed domain. For more information, see Password and account
lockout policies on managed domains.
Can I configure Distributed File System and

replication within Azure AD Domain Services?
No. Distributed File System (DFS) and replication aren't available when using Azure AD
Domain Services.
How are Windows Updates applied in Azure AD

Domain Services?
Domain controllers in a managed domain automatically apply required Windows
updates. There's nothing for you to configure or administer here. Make sure you don't
create network security group rules that block outbound traffic to Windows Updates.
For your own VMs joined to the managed domain, you are responsible for configuring
and applying any required OS and application updates.
Why do my domain controllers change names?

It is possible that during the maintenance of domain controllers there is a change in
their names. To avoid problems with this type of change, it is recommended to not use
the names of the domain controllers hardcoded in applications and/or other domain
resources, but the FQDN of the domain. This way, no matter what the names of the
domain controllers are, you won't need to reconfigure anything after a name change.
Is the password of the KRBTGT account in a

managed domain rolled periodically? If so, what
is the frequency?
The password of the KRBTGT account in a managed domain is rolled over every seven
(7) days.
Billing and availability

Is Azure AD Domain Services a paid service?
Yes. For more information, see the pricing page .
Is there a free trial for the service?

Azure AD Domain Services is included in the free trial for Azure. You can sign up for a
free one-month trial of Azure .
Can I pause an Azure AD Domain Services

managed domain?
No. Once you've enabled an Azure AD Domain Services managed domain, the service is
available within your selected virtual network until you delete the managed domain.
There's no way to pause the service. Billing continues on an hourly basis until you delete
the managed domain.
Can I fail over Azure AD Domain Services to

another region for a DR event?
Yes, to provide geographical resiliency for a managed domain, you can create an
additional replica set to a peered virtual network in any Azure region that supports
Azure AD DS. Replica sets share the same namespace and configuration with the
managed domain.
Can I get Azure AD Domain Services as part of

Enterprise Mobility Suite (EMS)? Do I need Azure
AD Premium to use Azure AD Domain Services?
No. Azure AD Domain Services is a pay-as-you-go Azure service and isn't part of EMS.
Azure AD Domain Services can be used with all editions of Azure AD (Free and
Premium). You're billed on an hourly basis, depending on usage.
Can I create a child domain under a managed

domain?
No. Azure AD Domain Services has a single-domain, single-forest design, and you can't
create child domains.
Which Azure regions have the service available?

Refer to the Azure Services by region page to see a list of the Azure regions where
Azure AD Domain Services is available.
Troubleshooting
Refer to the Troubleshooting guide for solutions to common issues with configuring or
administering Azure AD Domain Services.
Next steps
To learn more about Azure AD Domain Services, see What is Azure Active Directory
Domain Services?.
To get started, see Create and configure an Azure Active Directory Domain Services
managed domain.
feature availability
Article • 01/30/2023
This following table lists Azure Active Directory Domain Services (Azure AD DS) feature
availability in Azure Government.
Feature Availability
Configure LDAPS ✅
Create trusts ✅
Create replica sets ✅
Configure and scope user and group sync ✅
Configure password hash sync ✅
Configure password and account lockout policies ✅
Manage Group Policy ✅
Manage DNS ✅
Email notifications ✅
Configure Kerberos constrained delegation ✅
Auditing and Azure Monitor Workbooks templates ✅
Domain join Windows VMs ✅
Domain join Linux VMs ✅
Deploy Azure AD Application Proxy ✅
Enable profile sync for SharePoint ✅
Next steps
FAQs
Service updates
Pricing
deployment and management for Azure
Cloud Solution Providers
Article • 01/30/2023
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 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 an Azure Active Directory (Azure AD) 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 Azure
AD tenant. As a result, a user belonging to the CSP partner's admin agents group has
tenant admin privileges in Contoso's Azure AD 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 Azure AD Domain Services on behalf of Contoso.
For more information, see the Azure CSP overview
Benefits of using Azure AD DS in an Azure CSP

subscription
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.
Azure AD DS supports Azure CSP subscriptions. You can deploy your application in an
Azure CSP subscription tied to your customer's Azure AD 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 an Azure AD DS managed domain in your customer's Azure AD
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 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 Azure AD DS,
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.
CSP deployment models for Azure AD DS

There are two ways in which you can use Azure AD DS 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, Azure AD DS 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 Azure AD 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 Azure AD 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, Azure AD DS 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 Azure AD 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
Azure AD.
Administer Azure AD DS 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:
Azure AD DS 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 Azure AD DS using PowerShell 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 Azure AD tenant and their credentials aren't
available within the customer's Azure AD tenant. Azure AD DS 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
Azure AD 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 Azure AD 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. You can then enable Azure AD Domain
Services using the Azure portal or Azure PowerShell.

Azure Active Directory Domain Services

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Azure Active Directory Domain Services

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Azure Active Directory Domain Services

Uploaded by

Copyright:

Available Formats

Tell us about your PDF experience.

Azure AD Domain Services

About Azure AD Domain Services

What is Azure AD Domain Services?

Compare identity solutions

How does synchronization work?

Create a managed domain

Domain-join a Windows Server VM

Install management tools

Configure secure LDAP

Create an organizational unit (OU)

Configure Kerberos Constrained Delegation

Secure managed domain

Administer group policy

Check health status

Configure email notifications

Enable security audits

Red Hat Enterprise Linux

SUSE Linux Enterprise

Common alert messages

Secure LDAP issues

How does Azure AD DS work?

A managed domain is configured to perform a one-way synchronization from Azure AD

In a hybrid environment with an on-premises AD DS environment, Azure AD Connect

If you have an existing on-premises AD DS environment, you can synchronize user

Azure AD DS for hybrid organizations

The following features of Azure AD DS simplify deployment and management

Simplified deployment experience: Azure AD DS is enabled for your Azure AD

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-

To get started, create a managed domain using the Azure portal.

Active Directory Domain Services (AD DS) - Enterprise-ready lightweight directory

Azure AD DS and self-managed AD DS

Azure AD DS provides a smaller subset of features to traditional self-managed AD DS

Standalone cloud-only AD DS - Azure VMs are configured as domain controllers

Feature Azure AD DS Self-managed AD DS

Secure deployments ✓ Administrator secures the

DNS server ✓ (managed service) ✓

Domain or Enterprise administrator ✕ ✓

Domain authentication using ✓ ✓

Kerberos constrained delegation Resource-based Resource-based &

AD domain / forest trusts ✓ (one-way outbound forest ✓

Secure LDAP (LDAPS) ✓ ✓

LDAP write ✓ (within the managed ✓

Azure AD DS and Azure AD

Azure AD joined devices give you the following benefits:

Single-sign-on (SSO) to applications secured by Azure AD.

Type of device Device platforms Mechanism

Personal devices Windows 10, iOS, Android, Azure AD

Organization-owned device not joined to on- Windows 10 Azure AD joined

Organization-owned device joined to an on- Windows 10 Hybrid Azure AD

On an Azure AD-joined or registered device, user authentication happens using modern

Aspect Azure AD-joined Azure AD DS-joined

Device Azure AD Azure AD DS managed domain

Authentication OAuth / OpenID Connect Kerberos and NTLM protocols

Management Mobile Device Group Policy

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

If on-premises AD DS and Azure AD are configured for federated authentication using