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

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

hey #SAPConsultants 👋 "Think about the capabilities of GRC Access Control – Emergency Access Management (GRC AC EAM). Are you familiar with the process for enabling “Firefighter Access” in your S/4HANA production system? Here we have a unique choreography between 2 SAP systems. The S/4HANA system and GRC interact in a way where one system totally trusts the other system to “come to its rescue”. One system sends in a firefighter. . .or multiple firefighters. These are individuals who are given temporary access to perform a specific emergency function or business process. They perform these functions while being granted “elevated permissions” via specially designated “firefighter” user IDs. Can this arrangement be abused? It most certainly can! Companies can become relaxed and begin to perform “normal” business processes through a firefighter arrangement because they do not take the time to properly configure the needed Role/Authorization/User architecture that SHOULD be in place to support the business processes. A properly designed EAM/FireFighter process is critical to enabling proper governance and implementing and enforcing guardrails around the need for elevated access. Fundamental tenets of a well governed process for elevated access include a presumption of limited use. Elevated access should only be granted under specific criteria and in limited circumstances, moreover the elevated access roles/ID’s should be designed with least privilege access in mind and be purpose built for the intended use. Many organizations tend to take the easy route and build or assign roles with widespread access to a FireFighter ID. This adds additional risk as users may have access to extremely powerful transactions or access that they may not understand. A user may execute far more transactions than intended during the session resulting in much larger logs which makes it harder for reviewers to appropriately monitor the activities performed during a FireFighter session. In other words, a support user for a procurement process should not need access to maintain security roles. " read more here: a blog post by Barry Snow - SecurityBridge in collaboration with Jonathon Pasquale - Altum Strategy Group https://lnkd.in/dCNbRWXx #SAPCyberSecurity

What’s So Bad About Giving Out SAP_ALL in Development? In many SAP projects, someone inevitably says, “It’s just a dev system, just give them SAP_ALL.” It’s a common practice, but is it really harmless? The Justifications I Hear: • “It’s only development, no real data is there.” • “It speeds up troubleshooting and testing.” • “Restricting access slows down the project.” But here’s the problem: bad habits in development create security risks that carry over into production. Why It’s a Bad Idea: 1️⃣ Unchecked Access Becomes the Norm – Once SAP_ALL is freely handed out in development, it often creeps into test and even production environments through copied user roles or requests for “temporary” elevated access. 2️⃣ Sensitive Data Still Exists – Many dev systems contain copied production data. If not properly masked, they include personal, financial, or confidential business information, exposed to anyone with SAP_ALL. 3️⃣ Malicious or Accidental Damage – SAP_ALL grants unrestricted access, including the ability to delete tables, change configurations, and create backdoor users. Whether intentional or accidental, mistakes in development can cause major project setbacks. 4️⃣ Transport Risks – If users with SAP_ALL introduce security misconfigurations in development (e.g., critical authorization objects in roles), these can easily be transported into production without realizing the impact. 5️⃣ Audit and Compliance Issues – Even in non-production environments, excessive access violates security best practices and regulatory standards. Auditors won’t accept “It’s just dev” as an excuse if security controls are consistently ignored. The Better Approach: ✔ Use Business-Appropriate Roles – Assign access based on actual job functions rather than taking the easy route. ✔ Use Firefighter/Temporary Elevation for Troubleshooting – Controlled emergency access (with logging) prevents blanket SAP_ALL assignments. ✔ Mask or Anonymize Data in Dev Systems – Minimize the impact of unauthorized access. ✔ Apply the Same Security Mindset Across All Environments – Security should be embedded in the process, not bypassed for convenience.