| TL;DR Microsoft Entra Cloud Sync can provision cloud security groups to Active Directory, but the current English feature comparison does not support general cloud user provisioning to AD. Eligible group members need a matching account in the target AD environment. Moving a source of authority does not automatically solve every provisioning dependency. Start with a small scope, confirm licensing and agent requirements, and test the resulting application access before expanding the deployment. Give each group an owner and validate both access removal and access creation. |
What can Microsoft Entra Cloud Sync provision to AD?
The direction of synchronisation matters. Cloud Sync supports bringing AD identities into Entra ID. Its documented route in the opposite direction provisions eligible cloud security groups to AD. These are different jobs with different requirements. A feature list saying “users and groups” does not establish that both object types flow in both directions.
Microsoft’s Cloud Sync decision guide marks group provisioning to AD as supported and user provisioning to AD as unsupported. This is why a deployment plan must distinguish a supported group configuration from a proposed cloud user migration.
Group Source of Authority answers another question: which directory manages the group? Provisioning answers how that group and its memberships reach AD. For the ownership background, read Your group estate is not governed. It is just synced. This guide concentrates on implementing and validating the provisioning path.
A practical hybrid identity scenario
Consider an organisation with a finance application that still checks AD group membership. Employees already have AD accounts synchronised to Entra ID. The business wants finance access approved and reviewed through its cloud identity processes, while the application continues using its existing directory integration.
A cloud security group can represent that access. Cloud Sync provisions the group to AD, and the application uses the resulting AD group. The account remains an AD dependency; the group assignment can be managed in the cloud. That gives the organisation a useful intermediate architecture without forcing an application rewrite into the same change window.
Before choosing this approach, record exactly what the application checks: a group name, a distinguished name, a SID or nested membership. A new group with a familiar display name does not automatically replace a group already referenced by the application. Test with a representative user and an application owner who can confirm the result.
Prerequisites and licensing
Microsoft’s group provisioning prerequisites require Entra ID P1, an appropriate provisioning agent, an AD schema containing msDS-ExternalDirectoryObjectId, and a Hybrid Identity Administrator for the cloud configuration. The agent needs the documented AD permissions and connectivity, including LDAP and Global Catalog access. Use a current supported agent version and review permissions explicitly when upgrading or using a custom service account.
Also check the supported topologies. A user included in a cloud group needs a matching AD account in the target forest. The matching attribute onPremisesObjectIdentifier is therefore a dependency, not an optional naming convention. In an environment with several forests, membership in a cloud group does not create missing accounts in each forest.
Treat the pilot as an application access change. Assign an owner for the configuration, identify the destination OU, record the application’s existing group references and agree on an acceptable delay for access changes. Separately check the licences for any access package or review features you intend to use.
Configure group provisioning in five stages
1. Create the correct configuration. In the Entra admin centre, open Entra ID > Entra Connect > Cloud sync, choose New configuration and select Microsoft Entra ID to AD sync. Follow the Microsoft configuration guide for the target domain. Confirm the direction before proceeding.
2. Limit the initial scope. Select a few security groups for a pilot. Give each one a known application purpose and owner. Avoid making the first test a broad export of the tenant. Microsoft’s scale guidance says that the “All security groups” mode requires attribute scope filtering; selecting every security group without that filter is unsupported.
3. Review the target OU and mappings. Use parentDistinguishedName to control the destination. Check naming expectations, especially if an application relies on sAMAccountName. Microsoft documents that this value is not synchronised by default; a custom mapping must produce unique AD values. Preserve the protected matching and membership mappings. See the attribute mapping reference.
4. Test a representative group. Use on demand provisioning before enabling the broader job. Inspect the result in AD, including the OU and actual membership. If nested groups are required, include the necessary member groups in scope and verify the application’s handling of nesting.
5. Enable a monitored pilot. Review accidental deletion protection, notifications and the people who receive them. Enable the configuration only after the test results match the intended design. Keep a record of the pilot scope and mappings so another administrator can understand what was deployed.
What if your users exist only in Entra ID?
Stop at the missing account requirement. Adding a cloud user to a provisioned group does not, by itself, create an AD user. A cloud password and an Entra sign in also do not establish that a legacy application can authenticate that person through AD.
Where the requirement is workforce account creation, Microsoft documents API driven inbound provisioning from an authoritative system such as HR. That is a different design from copying existing Entra users into AD. Decide which system owns employee attributes and lifecycle events before selecting a provisioning route.
For a future cloud user provisioning rollout, use a separate acceptance gate: confirm the official support status, tenant availability, eligible user types, credential behaviour and recovery procedure. Early screenshots, translated documentation or an agent version number are not enough evidence for a production migration plan.
Validation, troubleshooting and recovery
A successful job is the start of validation. Use a test account with a known baseline and record evidence at three points: the cloud assignment, the AD membership and the application result. Repeat the same checks after removing access.
- If the group is missing, check its scope, destination OU, naming and the agent’s permissions.
- If a member is missing, verify that the account exists in the target forest and that identity matching is correct.
- If membership is correct but access fails, check what the application actually uses to authorise the user. Include nesting and existing session behaviour in that investigation.
- If removal appears slow, distinguish the provisioning delay from cached authentication or application sessions. Do not report immediate revocation unless your test demonstrates it.
Microsoft’s guidance for AD applications describes how existing Kerberos tickets can predate a membership change. Plan application access tests around refreshed authentication rather than assuming every open session immediately reflects a directory update.
For recovery, preserve the configuration and decide who can pause the job. Pausing prevents further processing; it does not undo every change already applied. Test restoration of required group memberships and application references in a controlled environment. Accidental deletion protection can quarantine a job when a configured threshold is exceeded, but it is not a directory backup.
Make the access decision reach the application
An access package can provide the request and approval process around the cloud group. Cloud Sync provides the directory provisioning path. The application still has to consume the resulting AD membership correctly. Give each part a named owner and test the full chain, including expiry and removal.
Measure the outcome with practical evidence: which assignment granted access, when AD reflected it, whether the application accepted it, and when access ended. A completed approval or review alone does not answer those operational questions.
Interian’s recommended starting point: choose one representative application and produce a small implementation record covering its group dependency, account prerequisites, scope, mappings, access tests and recovery owner. Expand only after the application owner accepts that result. This makes a hybrid identity roadmap concrete and exposes the remaining work before a wider migration.
Frequently asked questions
Can Microsoft Entra Cloud Sync create AD users from cloud users?
Microsoft’s comparison checked on 9 September 2026 still lists that direction as unsupported. Do not infer user support from the existing group provisioning feature.
Can Cloud Sync run alongside Entra Connect?
Yes, documented coexistence scenarios exist, including using Cloud Sync for group provisioning to AD. Define the scope of each configuration and avoid overlapping ownership of the same synchronised objects.
Does group provisioning let us remove Active Directory?
No. This design deliberately serves applications that still rely on AD accounts and groups. Removing that dependency requires a separate application and authentication plan.
Is Microsoft Entra Cloud Sync a replacement for access reviews?
No. It carries supported directory changes to AD. The access decision, review process, exception handling and verification still need to be designed.
Further Reading
- Your group estate is not governed. It is just synced.
- Microsoft Entra memberOf Retirement: What Admins Should Check Before Dynamic Groups Stop Updating
- Automate Your Onboarding and Offboarding in 15 Minutes with Entra Identity Governance
- Microsoft Learn: Provision groups to Active Directory with Microsoft Entra Cloud Sync
- Microsoft Learn: Migrate from Microsoft Entra Connect to Cloud Sync
