> ## Content Index > Fetch the complete content index at: https://www.sajeedmullaji.com/llms.txt > Use this file to discover other available public pages before exploring further. # D365 F&O Security Governance Phase 1 — Discovery and Baseline - URL: https://www.sajeedmullaji.com/d365-fo-security-governance-discovery-baseline/ - Published: 2026-09-07T07:19:42.000Z - Updated: 2026-09-07T07:19:51.000Z - Description: Discovery comes before remediation. Discover the verified steps to establish your D365 F&O security baseline — the foundation every subsequent phase depends on. - Author: Sajeed Mullaji - Tags: D365 FO, Security Architecture, ITGC Audit, The D365 Governance Roadmap [D365-Security-Baseline-TemplateD365-Security-Baseline-Template.xlsx10 KBdownload-circle](https://www.sajeedmullaji.com/content/files/2026/09/D365-Security-Baseline-Template.xlsx "Download") **D365 F&O Security Governance Phase 1 — Discovery and Baseline** You cannot secure a perimeter you cannot see. When most organizations evaluate their enterprise resource planning environment, they operate on assumptions. They assume offboarding processes are tight. They assume integrations are secured. They assume their architecture is clean. Assumptions fail audits. A world-class D365 F&O security governance discovery phase strips away the theory and extracts the absolute, verified truth directly from the system. We are documenting Phase 1 of a complete security governance engagement for our fictional client, Sajeed Mullaji Consulting. This phase is not about fixing problems. It is about freezing the architecture in time and quantifying the exact level of exposure currently sitting on the balance sheet. Here are the exact, verified system steps an architect takes to establish a bulletproof D365 baseline audit. **Step 1: The Perimeter Check — Entra ID vs. Manual Assignments** ![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/User-Groups-5.png) ****User groups showing manual role assignment — no Entra ID integration confirmed** Before you export a single line of data, you must understand the mechanism of control. Navigate natively to System administration, then Users, and open User groups. Look closely at the names populating this list. If you only see internal workflow groups, your IT team is assigning security roles manually inside the ERP. If you see Entra ID security group names, the entire remediation strategy pivots instantly. When Entra ID drives access, Dynamics 365 is no longer the master system of record for security provisioning. Auditing internal D365 menus becomes secondary to auditing the external Entra ID group rules. Failing to verify this first step renders the rest of the baseline obsolete. **Step 2: The Accountability Check — D365 Database Logging** **Security** ![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/Data-Base-Log-1.png) ****Database log setup — SecurityUserRole table not present — zero audit trail for security changes** Security debt does not appear out of thin air. Someone grants the access. Navigate to System administration, Setup, and open Database log setup. Search the active tracking list specifically for the `SecurityUserRole` table. If this table is missing from the list, D365 database logging security is fundamentally broken. This means there is zero historical tracking of who granted access, whose access was removed, or when a change occurred. There is no chain of custody. To an external auditor, this is an immediate, high-risk IT General Control (ITGC) finding before the role analysis even begins. **Step 3: Extracting the Master Roster** You need a flat, actionable matrix of exactly who holds the keys to the financial system. Navigate to System administration, Users, and select Users. Do not rely on native PDF reports. You cannot run data analysis against a static document. Click the 'Open in Microsoft Office' icon in the top right corner. Select Export to Excel, choose User Information, and download the file. This flat file is your baseline roster. It serves as the single source of truth that every subsequent phase of the engagement will reference. **Step 4: Exposing D365 System Administrator Sprawl** ![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/System-Administrator-Sprawl.png) ****System Administrator Sprawl — three accounts including integration service account SVC Salesforce API** The System Administrator role is the most dangerous object in the architecture. It bypasses every restriction and segregation rule. Navigate to System administration, Security, and open Assign users to roles. Select System Administrator in the left pane and aggressively review the accounts populated in the right pane. You must classify every single account on this list into three categories: human admins, vaulted break-glass accounts, or service accounts. D365 System Administrator sprawl is a universal disease, and service accounts are the primary symptom. If you find a third-party CRM integration or a payroll API mapped to the System Administrator role, you have a massive problem. Granting global admin rights to an integration instead of engineering a least-privilege service profile creates an unmonitored backdoor directly into the general ledger. **Step 5: Identifying D365 Orphaned Roles** ![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/Orphaned-Role.png) ****Budget contributor role — empty right pane — zero users assigned — orphaned configuration** Your security architecture should only contain what the business actually uses. Stay on the Assign users to roles screen. Click through the custom and standard roles listed in the left pane. If you click a role and the right pane shows zero users assigned, you have found a ghost configuration. D365 orphaned roles represent pure configuration debt. They provide zero functional value. Instead, they bloat your security exports, confuse business owners during quarterly access reviews, and generate unnecessary compliance noise. An audit-ready system strips away orphaned objects to keep the perimeter perfectly clean. **Step 6: Hunting Down D365 Ghost Accounts** ![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/Ghost-Account.png) ****Wayne user — Enabled toggle active — User's roles section empty — ghost account confirmed** An active account with no defined access is a silent liability. Navigate back to System administration, Users, and select Users. Click on an individual user profile and scroll down to the User's roles section. If the account toggle is set to 'Enabled', but the roles grid is completely blank, you are looking at a ghost account. Dynamics 365 has no native, out-of-the-box dashboard that flags these accounts. You find D365 ghost accounts by cross-referencing your master user list export against your backend role assignment matrices. To an IT team, these look like simple administrative oversights. To a threat actor, an enabled, unmonitored account with no native footprint is the perfect launchpad for credential hijacking. They indicate a broken offboarding protocol. **Step 7: The Power Platform Admin Center (PPAC) Reality** A world-class discovery phase never stops at the boundaries of the F&O front-end interface. Dynamics 365 data is deeply intertwined with Dataverse and Virtual Entities. You must run a parallel baseline extraction in the Power Platform Admin Center (PPAC). If an employee holds Environment Admin or System Customizer roles in PPAC, they possess the technical capability to bypass F&O UI restrictions entirely. They can use Power Automate to query financial tables via APIs, extracting sensitive data without ever logging into the ERP. You must also verify cross-tenant isolation restrictions and audit Copilot data sharing boundaries within PPAC. If you secure F&O but ignore the Power Platform, your financial security perimeter is a total illusion. **The Baseline Audit Deliverable** Discovery translates technical clicks into measurable executive intelligence. At the end of Phase 1, Sajeed Mullaji Consulting receives a definitive baseline template capturing the exact state of their exposure. This document logs the total number of enabled users consuming system resources. It highlights the exact System Administrator count, throwing a spotlight on integration accounts holding elevated access. It quantifies the dead weight by tracking the exact number of orphaned roles and ghost accounts. It explicitly states whether database logging is actively protecting the chain of custody. Finally, it confirms the PPAC baseline status, ensuring no API backdoors remain unmapped. **Universality of Risk** Every enterprise believes their implementation is unique. The specific numbers will always differ across different client environments. One client may have ten ghost accounts; another may have two hundred. However, the categories of failure are completely universal. Every unmanaged system suffers from integration sprawl. Every aging environment accumulates orphaned roles. Every rushed deployment neglects database logging. This diagnostic protocol exposes the identical structural flaws across any architecture. **What Comes Next: Phase 2 SoD Analysis**Data extraction is only the starting line. In Phase 2, we take the massive volume of raw access data collected during this baseline and push it through a strict ruleset. Phase 2 executes a surgical Segregation of Duties (SoD) analysis. We map the users against their precise capabilities to uncover toxic conflicts hiding deep within the matrix. We locate the users who currently possess the systemic ability to create a fictitious vendor and authorize a massive payment to that vendor without oversight. Fixing the access model is the prerequisite for financial integrity, not an afterthought. To transition your system from a compromised liability into a hardened, audit-proof asset, visit sajeedmullaji.com. **Executive Q&A** **Q: Why is an integration account holding System Administrator rights considered an immediate material weakness by external auditors?** **A:** An integration account with System Administrator rights bypasses all application-level controls, including Segregation of Duties and workflow approvals. Because these are automated, non-human accounts, they can read, modify, or delete sensitive financial data across the entire database instantly and silently. Auditors flag this as a critical failure of the principle of least privilege, as a compromised integration API key grants a threat actor total control over the balance sheet. **Q: If our user access is heavily automated through Entra ID security groups, why do we still need to audit the internal D365 role structures?** **A:** Entra ID only automates the delivery mechanism; it does not dictate the actual system permissions. If an Entra ID group automatically assigns a user to an internal D365 role that is bloated, toxic, and over-privileged, you are simply automating a compliance violation. The internal D365 roles must be engineered down to a least-privilege standard before Entra ID automation can be considered secure. **Q: Why doesn't Dynamics 365 provide a native dashboard for identifying ghost accounts, and how do auditors actually locate them?** **A:** Standard D365 interface views are designed for functional operations, not aggressive security forensics. The system allows an account to remain 'Enabled' even if all roles are stripped during a botched offboarding. Auditors bypass the front-end UI entirely to find them. They export the master active user roster and run a comparative analysis against the backend `Security user role associations` data entity. Any active user missing from the role association matrix is isolated immediately as a ghost account. ![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/User-Groups-2.png) ![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/User-Groups-1.png) ![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/User-Groups.png)