Overview of Microsoft Entra ID to Active Directory provisioning

Microsoft Entra Cloud Sync can provision users, groups, and group memberships from Microsoft Entra ID to on-premises Active Directory Domain Services (AD DS). This lets you manage the identity lifecycle from the cloud, using Microsoft Entra ID Governance, while maintaining uninterrupted access to applications that still depend on Active Directory (AD). It builds on Microsoft Entra Cloud Sync and complements the user and group Source of Authority (SOA) capabilities.

Many organizations are adopting a cloud-first identity model but still rely on AD for application access. Provisioning from Microsoft Entra ID to AD bridges this gap by allowing administrators to:

• Manage identities directly in Microsoft Entra ID as the source of authority.
• Provision cloud-native users, SOA-converted users, and guest business-to-business (B2B) users into AD.
• Provision security groups and their memberships into AD.
• Maintain identity continuity by preserving key attributes such as the security identifier (SID).
• Keep identity attributes and group memberships aligned between Microsoft Entra ID and AD.
• Ensure continued access to on-premises applications without disruption.

How it works

Microsoft Entra ID is the source of authority. The Microsoft Entra provisioning service detects changes and sends them, through the Cloud Sync provisioning agent, into the target AD domain.

1. An administrator configures a provisioning configuration in the Microsoft Entra admin center.
2. The Microsoft Entra provisioning service detects object changes (creates, updates, deletes).
3. Changes are sent to the on-premises Cloud Sync provisioning agent.
4. The agent provisions user and group objects into the target Active Directory domain.

For a detailed explanation of how the sync engine matches, provisions, and deletes objects, see How provisioning to Active Directory works. To choose between provisioning groups only, users only, or both, see Deployment options.

What you can provision

Key behaviors

• Cloud is the source of truth. Changes made directly in AD might be overwritten by Microsoft Entra ID during the next sync cycle. To protect provisioned objects from on-premises changes, see Configure AD user and group enforcement.
• SOA-converted objects remain cloud-managed. These users and groups can still be provisioned back into AD after conversion.
• Match then create. Existing objects are matched and updated; new objects are created only when no match is found.
• Target OU behavior. A default organizational unit (OU) is used unless overridden. A user whose SOA is converted to the cloud is returned to their original OU automatically. Groups aren't — to keep a converted group in its original OU, use a directory extension. See Preserve the OU path.
• Groups. Only security groups are supported. On-premises user membership must be explicitly enabled.

When to use provisioning to Active Directory

Provisioning to AD is the mechanism that supports several Source of Authority (SOA) scenarios. Rather than repeat those scenarios here, use the table to jump to the scenario that matches your goal:

What isn't supported

The following scenarios aren't supported:

• Provisioning the same user to multiple AD domains. A single target domain per user is enforced to ensure authentication consistency.
• Provisioning identities to multiple forests that share the same domain name.
• Cross-forest provisioning of user relationships (for example, manager or membership across forests).
• Provisioning custom security attributes (CSA) to AD.
• Provisioning Exchange attributes to AD. Because user SOA is in the cloud, Exchange-related information isn't needed in AD. For managing Exchange recipients without an on-premises Exchange Server, see Decommission the last Exchange Server after transferring SOA to cloud and Manage recipients in Exchange hybrid environments using management tools.
• Mail-enabled groups and distribution groups. Only security groups are supported.
• Password writeback, which applications that collect a user's password need, isn't supported. This includes applications that authenticate users by performing an LDAP bind with the user's password. Cloud-managed users have no AD DS password to present, so use passwordless authentication for applications that support Kerberos instead. For more information, see How cloud-managed users sign in to the application.
• Complex multi-domain hybrid identity architectures. Provisioning to AD is designed for single-domain identity continuity.

License requirements

Provisioning to Active Directory follows a configuration-based licensing model.

Next step

Related content

• How provisioning to Active Directory works
• Prerequisites
• Configure provisioning to Active Directory
• Test and enable provisioning
• What is Microsoft Entra Cloud Sync?
• Transfer user Source of Authority (SOA) to the cloud
• Convert group Source of Authority (SOA) to the cloud
• What is Microsoft Entra ID Governance?