Dynamics 365 Security Role Audit: IT Manager's Hardening Guide
Your Dynamics 365 environment is only as secure as the last person who left your organisation — and odds are, their access is still active. A Dynamics 365 security role audit is no longer an annual checkbox exercise reserved for compliance season. In 2025, with Microsoft Entra ID (formerly Azure AD) deeply entwined with Power Platform entitlements and SharePoint document libraries sharing record-level data, a single over-privileged service account or a forgotten Azure AD group assignment can expose your entire CRM estate.
This guide goes three layers deeper than the surface-level security posts you have already read. We cover role sprawl mapping, a framework-aligned audit checklist, the SharePoint ACL gap that almost every Dynamics 365 deployment ignores, and a Power Automate automation playbook that enforces quarterly hygiene at scale — without burning out your IT team.
Why Most Dynamics 365 Security Audits Fail Before They Start
The typical audit approach looks something like this: export the list of security roles, eyeball who has System Administrator, flag a few obvious outliers, and call it done. That approach misses three critical attack surfaces that adversaries — and auditors — will absolutely find.
- Ghost accounts: Disabled Azure AD users whose Dynamics 365 licences and security role assignments are never cleaned up, leaving dormant entitlements that can be reactivated.
- Inherited Azure AD group conflicts: A sales rep added to a security group for a Power BI workspace inadvertently inherits a Dynamics 365 security role mapped to that group — granting read access to financial records they should never see.
- SharePoint permission inheritance breaks: When Dynamics 365 creates a SharePoint document library for an entity, it applies its own folder-level ACLs. The moment a SharePoint admin manually adjusts inheritance on a subfolder, record-level security in Dynamics 365 and folder-level security in SharePoint diverge silently.
None of these failure modes show up in a standard role export. You need a structured audit methodology — which is exactly what the rest of this guide provides.
Step 1 — Map Current Security Role Sprawl
Identify Over-Privileged Users
Start with the Dynamics 365 Security Role report available under Settings → Security → Users. Export every user alongside their assigned roles and business unit. Then cross-reference against the principle of least privilege: does a customer service agent really need the System Customizer role? Does a read-only reporting user need Sales Manager?
Use the following Power Shell snippet via the Microsoft.Xrm.Data.PowerShell module to pull a flat CSV of all user-role assignments programmatically:
# Connect to your Dynamics 365 environment
Connect-CrmOnline -ServerUrl "https://yourorg.crm.dynamics.com" -ForceOAuth
# Retrieve all system users with their security roles
$users = Get-CrmRecords -EntityLogicalName systemuser `
-Fields fullname, domainname, isdisabled, businessunitid
$roleAssignments = @()
foreach ($user in $users.CrmRecords) {
$roles = Get-CrmUserSecurityRoles -UserId $user.systemuserid
foreach ($role in $roles) {
$roleAssignments += [PSCustomObject]@{
UserName = $user.fullname
DomainName = $user.domainname
IsDisabled = $user.isdisabled
BusinessUnit = $user.businessunitid.Name
SecurityRole = $role.name
}
}
}
$roleAssignments | Export-Csv -Path "D365_RoleAudit_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
Filter the output for IsDisabled = True immediately. Every disabled user with an active role assignment is a ghost account risk. Escalate these for licence revocation and role removal before anything else.
Uncover Azure AD Group Conflicts Across Business Units
Dynamics 365 supports assigning security roles to Microsoft Entra ID (Azure AD) groups — a powerful feature that also creates hidden entitlement chains. An individual may sit in five Entra groups, each mapped to a different Dynamics 365 role, across two business units. The cumulative permission set is almost never intentional.
To surface these conflicts, pull the group-to-role mappings from Entra ID and cross-reference against Dynamics 365 team membership. Look specifically for groups used primarily for non-CRM purposes (Teams channels, SharePoint sites, Power BI workspaces) that have been inadvertently mapped to Dynamics 365 security roles. This is the most common source of privilege creep in mature Microsoft 365 tenants.
Step 2 — Build Your RBAC Audit Checklist (NIST + ISO 27001 Aligned)
Generic RBAC checklists do not account for Dynamics 365's layered security model — organisation, business unit, team, user, and field-level security all interact. The following control points map to NIST SP 800-53 AC-2 (Account Management) and ISO 27001:2022 Annex A 5.15 (Access Control) while addressing Dynamics 365-specific architecture.
- AC-2.1 — User Account Inventory: Confirm every active Dynamics 365 user maps to an enabled Entra ID account. Orphaned accounts must be deprovisioned within 24 hours of HR offboarding notification.
- AC-2.2 — Role Assignment Justification: Each security role assignment must have a documented business justification linked to a job function. Undocumented roles default to removal at next review cycle.
- AC-2.3 — Privileged Role Separation: System Administrator and System Customizer roles must not be assigned to the same user in a production environment. Separate accounts must be used for administrative tasks.
- AC-2.4 — Business Unit Scoping: Validate that users are assigned to the correct business unit and that their roles do not grant cross-BU read access unintentionally via parent-child BU inheritance.
- AC-2.5 — Field Security Profile Audit: Review all Field Security Profiles against current role assignments. Field-level restrictions are often bypassed when a user is granted a broad role that includes field-level read via a separate profile.
- AC-2.6 — Service Account Review: Non-interactive service accounts (used by integrations and Power Automate connections) must be audited quarterly. These accounts frequently accumulate roles as new integrations are deployed and old ones are never removed.
- AC-2.7 — Azure AD Group Role Mapping Registry: Maintain a live registry of every Entra ID group mapped to a Dynamics 365 security role, the owning team, and the last review date. This registry is your primary control for inheritance conflict detection.
- AC-2.8 — SharePoint Permission Parity Check: (See Step 3 — this is the control point competitors do not implement.)
Step 3 — Close the SharePoint Document Library Permission Gap
This is the architectural gap that most Dynamics 365 security posts acknowledge but never resolve. Here is the definitive answer.
When Dynamics 365 integrates with SharePoint (Server-Based Authentication), it automatically creates a document library per entity (Accounts, Opportunities, Cases, etc.) and generates a folder per CRM record beneath it. Access to those folders is controlled by SharePoint permissions — not Dynamics 365 security roles. The two systems are connected at provisioning time but diverge the moment anyone touches SharePoint permissions manually.
The Three Divergence Scenarios
- Scenario A — Broken Inheritance: A SharePoint admin right-clicks a subfolder and stops permission inheritance to grant a vendor temporary access. That subfolder now ignores Dynamics 365 record ownership entirely. The vendor retains access even after their CRM user is disabled.
- Scenario B — SharePoint Group Expansion: The auto-created SharePoint site for Dynamics 365 documents is connected to a Teams-enabled SharePoint site. Every Teams member now has at minimum Read access to every CRM document folder — regardless of their Dynamics 365 security role.
- Scenario C — Library-Level Permission Override: A site owner grants a department Contribute access at the document library level. This overrides folder-level ACLs generated by Dynamics 365, giving broad write access across all entity records.
The Architectural Fix
The correct remediation has three components:
- Isolate the Dynamics 365 SharePoint site collection. Never co-locate CRM document libraries on a SharePoint site used for team collaboration. Provision a dedicated site collection (e.g.,
https://yourtenant.sharepoint.com/sites/crm-documents) with restricted site member access. - Enforce inheritance at the library level via site policy. Use SharePoint Site Collection Policies to prevent manual inheritance breaks on CRM entity libraries. This requires scripting via PnP PowerShell or a SharePoint admin policy applied at the tenant level.
- Run a weekly permission parity report. Use the PnP PowerShell
Get-PnPListItemandGet-PnPListItemPermissioncommands to extract folder-level ACLs and compare them against Dynamics 365 record ownership. Flag any folder where the SharePoint permission set does not match the expected CRM security role mapping.
This three-component fix closes Scenario A, B, and C simultaneously. Without it, your Dynamics 365 security role audit is incomplete — no matter how thorough the role matrix review was.
Step 4 — Automate Quarterly RBAC Hygiene with Power Automate + Entra Access Reviews
Manual audits decay within weeks. The only sustainable approach is an automated enforcement playbook that runs continuously and escalates exceptions to humans only when decision-making is genuinely required.
Configure Microsoft Entra ID Access Reviews
Entra ID Access Reviews (available with Entra ID P2 or Microsoft 365 E5) allow you to schedule recurring reviews of group memberships — including the groups mapped to Dynamics 365 security roles. Configure the following:
- Scope: All Entra groups tagged with
D365-Role-Mapped = True(apply this tag as part of your group registry from Step 2). - Reviewers: Group owner + the user's direct manager (dual-approval removes single points of failure).
- Frequency: Quarterly, with auto-apply configured to remove access if no response is received within 14 days.
- Notifications: Escalation email to the IT Security team at day 10 for non-responses.
Power Automate Enforcement Flow
Layer a Power Automate flow on top of Access Reviews to handle the Dynamics 365 side of the cleanup — because Access Reviews remove group membership in Entra but do not automatically update Dynamics 365 team assignments or trigger licence reallocation.
Build a scheduled cloud flow (weekly) with the following logic:
Trigger: Recurrence — Every Monday 06:00 UTC
Action 1: HTTP — GET /api/data/v9.2/systemusers
?$filter=isdisabled eq true
&$select=systemuserid,fullname,domainname
Action 2: Apply to Each (disabled user)
→ HTTP DELETE role assignments for systemuserid
→ HTTP PATCH systemuser: islicensed = false
→ Post Teams adaptive card to IT-Security channel
with user details + action taken
Action 3: HTTP — GET /api/data/v9.2/systemusers
?$filter=accessmode eq 0
&$expand=systemuserroles_association($select=name)
&$select=fullname,domainname
Action 4: Filter Array — roles containing "System Administrator"
Action 5: If array count > threshold (configurable)
→ Send approval email to IT Manager
→ Log to SharePoint audit list with timestamp
This flow handles ghost account cleanup automatically, flags System Administrator proliferation for human review, and creates an immutable audit log in SharePoint — satisfying both NIST AC-2 logging requirements and ISO 27001 evidence collection for external audits.
Building Your Ongoing Compliance Evidence Pack
Decision-makers undergoing SOC 2, ISO 27001 certification, or internal IT audits need to produce evidence — not just assurances. Structure your audit artefacts as follows:
- Role Assignment Matrix (CSV): Generated weekly by the PowerShell script in Step 1. Stored in a version-controlled SharePoint document library with retention policy.
- Access Review Completion Reports: Exported from Entra ID after each quarterly review cycle. Saved as PDF with reviewer names and decisions.
- SharePoint Permission Parity Report: Weekly PnP PowerShell output, flagged exceptions highlighted, stored alongside the role matrix.
- Power Automate Flow Run History: Exported monthly as evidence that automated controls are operating continuously.
- Exception Log: Any manual overrides to automated role removal, documented with business justification, approver, and expiry date.
Conclusion: Depth Wins Audits — and Protects Organisations
A Dynamics 365 security role audit that stops at the role export level is not an audit — it is a false sense of security. The organisations that pass compliance reviews and genuinely protect customer data are the ones who map Entra group conflicts, close the SharePoint ACL gap architecturally, and automate enforcement so hygiene does not depend on someone remembering to run a script.
At CRMONCE, we implement this exact hardening framework for clients across regulated industries in India and globally. Whether you are preparing for an ISO 27001 audit, responding to a security incident, or simply trying to get control of a Dynamics 365 environment that has grown organically for years — a structured, framework-aligned RBAC audit is where sustainable security begins.
Ready to run this audit against your own environment? Contact the CRMONCE team for a scoped security review engagement, or explore our related guides on SharePoint Permissions in Dynamics 365 and Security Roles vs Azure AD Groups to go deeper on the individual components covered here.