We’re experiencing an issue where financial accounting users are not inheriting security roles from their Azure AD group assignments. Users are correctly added to AD groups that are mapped to D365 security roles, but when they log into the system, they don’t have the expected accounting functions available.
Our setup uses nested AD groups where users belong to department groups, which are then members of role-based groups. For example, users in the Accounting Department group should inherit roles from the Financial Accountant group. This worked perfectly before, but after some recent Azure AD changes, the role inheritance chain seems broken.
We’ve verified the group assignments in Azure AD are correct, and the role mapping in D365 shows the proper connections between AD groups and security roles. Other departments using similar nested group structures don’t have this problem - it’s specifically affecting our financial accounting team.
The permission sync appears to run successfully without errors, but the actual role assignments don’t propagate to users. Has anyone dealt with role inheritance or group assignment issues in financial accounting after Azure AD configuration changes?
I’ve successfully resolved this exact role inheritance issue for financial accounting users multiple times. The problem involves three interconnected areas that all need proper configuration for nested group role inheritance to work correctly in D365 Finance.
Group Assignment Architecture:
D365’s role mapping system has specific requirements for nested group structures, especially for financial modules. The issue is that standard Azure AD sync doesn’t automatically resolve nested memberships for security-sensitive modules like financial accounting.
To fix this:
Go to System Administration > Setup > Azure Active Directory applications
Verify your application registration is configured for group claims
Enable “Emit groups as role claims” in your Azure AD app’s token configuration
Critical step: In Azure AD, go to your D365 enterprise application > Properties > Set “User assignment required” to Yes
Then explicitly assign both the parent role groups AND the nested department groups to the application
This forces Azure AD to resolve the full group membership chain and include all relevant groups in the authentication token.
Role Mapping Configuration:
The role mapping in D365 needs to be explicit about how it handles group hierarchies. Navigate to System Administration > Security > Map roles to Azure AD groups:
Map your Financial Accountant role directly to BOTH the role group AND the department groups
Don’t rely on transitive resolution - create explicit mappings for each group in the chain
For each mapping, set Assignment mode to “Automatic”
Ensure “Enabled” is checked for all mappings
Document the Object ID of each group (use PowerShell: Get-AzureADGroup -SearchString “groupname” | Select ObjectId)
The key insight: Financial accounting roles require explicit mapping at each level because they involve sensitive financial data access. D365 won’t automatically inherit these roles through nested groups as a security measure.
Permission Sync Process:
The permission synchronization for financial accounting has additional requirements:
Run the full security sync: System Administration > Periodic tasks > Security > Update role mapping (not just user sync)
Then run: System Administration > Periodic tasks > Security > Update security - this rebuilds privilege cache
Force a token refresh by having users fully sign out and clear browser cookies
Users must sign back in to receive new tokens with updated group claims
The root cause in your case is likely that Azure AD made changes to how group claims are issued (common with Azure AD updates), and now the nested group memberships aren’t being included in authentication tokens. By explicitly assigning all groups in the hierarchy to the D365 application and creating direct role mappings for each level, you bypass the nested group resolution issue.
After implementing these changes, the role inheritance should work immediately upon user login. Monitor the first few logins to confirm users receive all expected roles. If issues persist for specific users, check their individual user record in D365 to see which groups are actually being recognized in their authentication token - this will show you if the problem is with Azure AD group resolution or D365 role mapping.
One additional consideration: If your recent Azure AD changes involved moving from Azure AD Graph API to Microsoft Graph API, the group claim format may have changed. Verify that your D365 instance is configured to parse group claims in the format being sent by your current Azure AD configuration.
This draft is based on general Microsoft Dynamics 365 knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Nested group inheritance can be problematic with D365 security role mapping. By default, D365 only reads direct group memberships, not nested groups. If your users are in a department group that’s nested within a role group, D365 might not see that relationship. You need to enable transitive group membership queries in your Azure AD synchronization settings for D365 to recognize nested group structures.
That’s interesting - we’ve been using nested groups for over a year without issues though. Is this a recent change in how D365 handles group membership? And if we need to enable transitive membership, where exactly is that setting configured? I don’t see it in the standard Azure AD application settings for D365.
The recent Azure AD changes you mentioned might have affected how group claims are sent in authentication tokens. Check your Azure AD app registration for D365 and look at the token configuration. Make sure the groups claim is configured to include security groups and that there’s no filter limiting which groups are included. Financial accounting roles might require specific group claim settings that weren’t necessary before. Also verify that the groups claim is being emitted in both ID tokens and access tokens.
Tested this on D365 Finance 10.0.35 and forcing Azure AD nested group resolution via the Security role assignment batch job fixed our financial accounting users’ inheritance issues immediately.
I’ve seen this happen when the Azure AD group object IDs change or when groups are recreated. Even if the group name is the same, if the object ID changed, D365’s role mapping won’t recognize it. Go to your role mapping configuration in D365 and check if the mapped Azure AD group object IDs still match the current groups in Azure AD. You might need to remap the groups even though everything looks correct on the surface.
Don’t forget about the role mapping synchronization job. Even with correct group assignments and mappings, if the sync job isn’t running or is encountering errors, users won’t get their roles. Check System Administration > Periodic tasks > Security > Update role mapping. This batch job needs to run regularly to keep role assignments current. If it’s failing silently, you’d see exactly the symptoms you’re describing - correct configuration but no actual role assignment.