Access control challenges in SAP testing

🔐 Local Accounts with SSO? That’s a Red Flag! Let’s say you walk into an organization with strong SSO (Single Sign-On) policies. Everything looks secure. Azure AD or Okta is in place. MFA is active. But under the hood—a few users can still log in using old local credentials. That’s like locking the front door but leaving the backdoor wide open. In the world of IT General Controls (ITGC), this is more than just a bad habit—it's a control failure waiting to be flagged. So, how do you catch this? 🔎 But First… What’s the Problem? SSO is supposed to be your single source of truth for user access. But sometimes, local user accounts still exist and worse—they work even when SSO is enabled. This can break controls like: User Access Provisioning Periodic Access Review Termination/Deactivation Controls Why? Because SSO-based identity management assumes no one can bypass it—but these local accounts do exactly that. 🚦 Red Flags Auditors Are Looking For 1. 🔁 Accounts that authenticate via SSO AND local login 2. 🔓 Users with local passwords in apps where SSO is enforced 3. 🕵️ Accounts that remain active after termination in HR/SSO system ✅ How to Spot These Local Accounts (Before Your Auditors Do) 1. Start with the Application’s User List Export or view the user list from key applications (like SAP, Oracle Cloud, ServiceNow). Look for: User Type: “Local” or “Federated” Login Type: “Password” + “SSO” (dual access) Authentication Source: “Internal” vs “IdP” Example: SAP may show logon methods. If a user has both SAP* and SSO, that’s a red flag. 2. Cross-Check with Your Identity Provider (SSO) From Azure AD, Okta, or Ping Identity: Pull list of all federated users Compare with app-level users If someone exists only locally, why? Also, check if a user exists in both systems. If yes, see how they’re logging in. 3. Use Audit Logs to Trace Login Behavior Look for: Last login method (SSO or password?) Unusual login times or IPs Dual login records Example: User John Doe logs in at 10AM via SSO and at 2PM via local password? Big issue! 4. For Custom or On-Prem Apps: Use Scripts A quick PowerShell or Python script can help pull out local accounts and check login methods. 🧠 ITGC Angle: Tie This to Controls ITGC Control Risk Due to Local + SSO Auditor’s View User Provisioning User may bypass SSO approval Control failure De-provisioning Local account still active post-exit Control not effective Periodic Review Access not visible in SSO reports Incomplete population Logical Access Weak password policies applied locally Non-compliance 💡 Tips to Stay Ahead 🔒 Disable local logins for SSO users unless justified 🧾 Maintain documentation of local exceptions (e.g., service accounts) 📅 Include dual-login checks in periodic access reviews 🔔 Alert on local logins where SSO is expected 🎯 Final Words: It’s About Trust and Control

SAP ITGC INTERVIEW QUESTIONS THAT ACTUALLY TEST JUDGMENT Most SAP ITGC interviews don’t fail on definitions. They fail on how you think in real scenarios. Here are scenario-based SAP ITGC questions I’ve seen repeatedly across SOX, Internal Audit, and Big 4 interviews — along with the mindset interviewers look for. 1. “Management says the access issue is low risk.” Risk is based on capability, not intent. If access allows posting, master data changes, or override of approvals, it is inherently high risk — regardless of usage history. 2. Firefighter access exists, but logs are not reviewed. This is not a documentation gap. This is a control failure. Emergency access without log review defeats the control design. 3. Access reviews are performed, but reviewers don’t understand SAP roles. A review without competence is not an effective control. If approvals are blind, the control fails operating effectiveness. 4. Transports moved to Production before approval due to business urgency. Urgency does not override segregation of duties. Repeated “urgent” changes point to a breakdown in change governance. 5. Configuration changes have no testing evidence. “Standard practice” without evidence does not meet SOX expectations. Config changes directly impact financial logic — evidence is non-negotiable. 6. Developer has Production access due to team shortage. This is a direct SoD violation. Temporary access still requires enhanced monitoring and compensating controls. 7. Business process controls passed, but ITGC failed. Clean BP testing does not override failed ITGCs. If access or change controls fail, reliance on automated controls and reports collapses. Interviewers are not testing SAP. They are testing judgment, risk awareness, and audit maturity. If you can explain why a control fails — not just that it fails — you stand out.

SAP Segregation of Duties (SoD) In SAP environments, Segregation of Duties (SoD) is the fundamental internal control used to ensure that no single individual has enough system access to execute a fraudulent activity and then conceal it. Managing SoD in SAP is particularly complex because it often involves thousands of T-Codes and granular authorization objects (like S_TCODE, ACTVT, and BEGRU). Recommended Practices for Implementation 👉 Clean the Roles, Not Just the Users: Fix the "Parent" roles first. If a role itself contains a conflict, every user assigned to it will show a violation. 👉 Focus on 'Critical Actions': Not every conflict is equal. Prioritize "High" and "Critical" risks (like those involving cash or financial reporting) before tackling "Medium" or "Low" operational risks. 👉 Regular Access Reviews: Perform "User Access Reviews" (UAR) quarterly. Managers should certify that their employees still need the specific SAP roles they hold. 👉 The "Least Privilege" Principle: Only grant the specific T-Codes and organizational levels (Company Code, Plant) required for the job. To ensure these controls are effective, they are typically implemented across three technical layers: ✔️ Preventative (Role Level): Building SAP roles that do not contain internal conflicts. This is the "clean at the source" approach using SAP GRC Access Risk Analysis (ARA). ✔️ Detective (Monitoring): Running monthly reports (like S_ALR_87012011 for changes to vendor master data) to identify actions that occurred despite access being granted. ✔️ Emergency (Firefighter): Utilizing SAP GRC Access Control (EAM) to provide temporary, logged access for critical fixes, ensuring that "God-mode" access is not assigned permanently to any user.

Access issues in SAP Fiori can be related to several factors, such as roles, authorizations, or system settings. Here's a step-by-step guide to troubleshoot and resolve Fiori access issues: 1. Verify User Roles and Authorizations: Check Assigned Roles: Ensure the user has been assigned the correct roles in the SAP backend system. Go to transaction PFCG and check if the user has the appropriate roles assigned for accessing the desired Fiori app. Check Authorization Objects: Each role contains authorization objects that control access to apps. Ensure that the necessary authorization objects (e.g., S_TCODE, S_SERVICE, etc.) are assigned to the user (Use Trace to get details for Missing Authorization Objects). Check Catalog and Group Assignment: The Fiori app must be part of a catalog, and the user must be assigned to that catalog. Use the Launchpad Designer to ensure the app is included in the relevant catalog and group. Transaction - /n/UI2/FLPCM/CUST – Search for Tile (Fiori App) for which user has issue and make sure respective Role is assigned to user. You can also check which catalog or role has corresponding tiles. 2. Launchpad Configuration: Check Launchpad Designer Configuration: Go to the Fiori Launchpad Designer (/ui2/flpd_cust) and ensure that: The target mapping for the application is correctly defined. The user has access to the catalogs and groups where the Fiori app is located. Verify App is Assigned to a Tile: Make sure the Fiori app is assigned to a tile and that the tile is part of a catalog the user has access to. Missing tiles are often a sign of catalog or group misconfiguration. 3. Backend System Configuration: Check For SAP Gateway Error - /IWFND/ERROR_LOG Check System Alias: Ensure that the system alias is correctly configured in the OData service. Go to transaction SM59 to check the RFC connection and /IWFND/MAINT_SERVICE for maintaining the services. Activate OData Service: If the OData service for the Fiori app is not activated, users will experience access issues. Use transaction /IWFND/MAINT_SERVICE to activate the service. 4. Clear Cache and Renew Session: Clear Fiori Cache: Clear the browser cache or go to /UI2/INVALIDATE_GLOBAL_CACHES in the backend to invalidate the cache for the user. Check User Sessions: If the user session is locked, ask the user to log out and back in, or unlock their user using transaction SU01. 5. Transport Issues: If the Fiori app was recently transported, ensure that all related configurations, services, and authorizations have been correctly transported to the target environment. By following these steps, you can systematically identify and resolve access issues in SAP Fiori. Let me know if you need help with any specific step! https://lnkd.in/dZZCeY3Y

The Segregation of Duties Matrix continued... ⬇ The SoD matrix provides a financial risk rating of access entitlements that are assigned to a user. SoD Controls should be designed to mitigate access control violation risks. The SoD Matrix enables auditors to test the SoD Control design effectiveness, based on the risk level identified in the matrix. To ensure that the SoD matrix is accurate and complete, the auditor must obtain a complete snapshot of all user access points within the enterprise application to ensure that the SoD control design includes a level of granularity in the enterprise security model that grants user access as per the job role assignment for all the users. The application mapping is the rule-set by which sensitive transactions are tested in the relevant systems. For example, vendor-update rights may be executed through a series of menus within a given application. The presence of these menus assigned to specific users should be mapped, walked-through, and documented for the company to accurately test for a particular conflict. The challenge is that in most modern applications there is more than one way to execute the same transaction. For example, there may be more than one way to pay a vendor in an application, but typically, the company isn´t aware of all of them and usually doesn´t restrict access to or control these other methods to execute a vendor payment. The risk-based SoD process requires a company to discover all the potential methods for executing a transaction to understand the full potential for fraud, not just the limited view of the known methods. Mapping all the ways a user could potentially execute a transaction is critical to accurately depicting SoD. #segregationofduties #accessgovernance #riskmanagement #accesscontrols