Use of On-Premises AD Groups (Synced to Microsoft Entra ID) in Power Platform Environments

(1) Share

Report

Posted on by CU27031833-0

Hi,

I found some Microsoft documentation mentioning that on-premises Active Directory groups are not supported in Power Platform. However, it doesn’t clearly state whether this also applies when those groups are synchronized to the cloud (Microsoft Entra ID).

I ran some tests using on-premises groups synced to the cloud, and they seem to work well when used as environment security groups. I was able to assign roles and permissions, and users were able to create apps and flows without issues.

Are there any limitations, risks, or considerations when using on-premises AD groups synchronized to the cloud for controlling access to Power Platform environments (environment-level security groups) that we should be aware of?

I’m asking because many organizations still follow a hybrid approach, using on-premises groups synchronized to the cloud.

Categories:

Governance & administering

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Suggested answer

Vish WR 604 on at

Like (0)

Report
Copy link

Link copied!

@CU27031833-0

You’re right, it will work

if the accounts and groups are synchronized to Microsoft Entra ID, they can be used in Power Platform. Access and ability to update records will still depend on Azure AD (Entra ID) settings and whether write-back is allowed.

Some organizations use a one-way sync from on-premises AD to Entra ID, in which case changes made in the cloud cannot be written back to on-premises AD objects (users or groups).

So in general, on-prem AD groups synced to Entra ID are supported for Power Platform environment security groups, but governance depends on your identity configuration and directory synchronization rules.

Vishnu WR

LinkedIn - My Tech Space

Please ✅ Does this answer your question if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider answering Yes to Was this reply helpful? or give it a Like ♥

Was this reply helpful? Yes No
Suggested answer

Pstork1 69,264 Most Valuable Professional on at

Like (2)

Report
Copy link

Link copied!

As long as the on-premises domain is synced to the cloud then the groups should work because they exist in the cloud. But at that point they aren't really just on-premises AD groups anymore. The only real issue is that timing can be a bit slower because things like adding users to a group in the on-premises AD may not be reflected immediately in the cloud. But since group membership is cached and it already takes overnight in many cases before a change is registered it really shouldn't be an issue.

----------------------------------------------------------------------------------
If this Post helped you, please click "Does this answer your question" and give it a like to help others in the community find the answer too!

Paul Papanek Stork, MVP
Blog: https://www.dontpapanic.com/blog

Was this reply helpful? Yes No
Suggested answer

11manish 1,196 on at

Like (0)

Report
Copy link

Link copied!
When Microsoft says “on-premises AD groups are not supported” in Power Platform, it specifically refers to:

Direct use of on-premises-only AD groups (not synced)

But in your case:

On-premises AD groups synchronized to Microsoft Entra ID (Azure AD)

are treated as cloud security objects

So what you tested is expected to work.

Was this reply helpful? Yes No
Suggested answer

Valantis 3,045 on at

Like (2)

Report
Copy link

Link copied!

Hi @CU27031833-0,

Good question and your testing observation is correct. Once on-premises AD groups are synced to Entra ID via Microsoft Entra Connect (formerly Azure AD Connect), Power Platform sees them as Entra ID security groups, not as on-premises groups. The Microsoft docs warning against "on-premises Windows AD security groups" refers to groups that only exist on-premises and have not been synced. Synced groups are a different object type in Entra ID and do work as environment security groups, which matches what you found in testing.

be aware of:
1. Sync delay. Changes made on-premises (adding or removing users from the group) do not reflect in Entra ID and therefore Power Platform immediately. Entra Connect sync runs on a schedule (default 30 minutes). During that window users may still have access they should not, or may lose access before the sync completes.

2. Group type limitations. Entra Connect only syncs Security groups, not Distribution groups. Make sure your on-premises groups are Security groups, not Distribution lists.

3. Nested group behavior. Members of nested groups are not pre-provisioned in the environment. They get added at runtime when they first access the environment. This applies to all Entra ID groups but is worth knowing.

4. Group writeback. If you use group writeback (writing cloud changes back to on-premises), changes made directly in Entra ID to the synced group may be overwritten by the next sync from on-premises. This could cause unexpected access changes if someone edits the group in the cloud thinking it is cloud-managed.

5. Microsoft's documented recommendation is to use cloud-only Entra ID groups for Power Platform to avoid dependency on on-premises infrastructure. If your Entra Connect service has an outage or sync issue, membership changes are blocked until sync is restored.

For most hybrid organizations what you are doing is the standard approach and works well. Just make sure sync latency is acceptable for your security requirements and that your group type is Security.

Ref: https://learn.microsoft.com/en-us/power-platform/admin/control-user-access

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

Was this reply helpful? Yes No