SAP Community - NW ABAP User Administration and Authorization

BW/4HANA Security: SAP BW/4HANA Migration (Remote Conversion)

2023-08-06T05:44:48+02:00

Introduction

SAP BW/4HANA is a next generation data warehouse solution developed by SAP. The underlying foundation of SAP BW/4HANA is the SAP HANA in-memory database, which means that the data is stored and processed in the main memory of the server resulting faster data retrieval, processing, and analytics compared to traditional disk-based databases.

SAP BW/4HANA simplifies data modeling, enables real-time analytics, and supports integration with advanced technologies like big data and machine learning. It helps organizations consolidate, manage, and analyze large volumes of data, providing timely insights for data-driven decision-making.

Organizations that have been using the earlier version of SAP BW can migrate to SAP BW/4HANA. The migration process involves converting the existing data models, objects, and applications to the new platform, taking advantage of the improved features and capabilities.

Business Scenario:

Organization is planning to migrate from BW to BW/4HANA solution but they are keen to know the impact on security authorizations. Also, the security authorization activities to be carried out as a part of the migration. This article will help the organization to achieve their requirements in terms of security authorizations.

Step1: Transport SU25 changes

Create a transport request in BW system for customer tables.

Transport the customer tables from BW to BW/4HANA system.

Step2: SAP BW Users.

Discuss with the business about the SAP BW user master i.e. how they want to handle the users in BW/4HANA system.

If business agrees for client copy via BW system then copy profile SAP_UONL (User Without Authorization Profiles and Roles) into BW/4HANA system.

Step3: Transport BW Analysis Authorizations

Discuss with the business and identify the list of BW analysis authorizations which are in scope i.e. BW analysis authorizations which needs to be available in BW/4HANA system.

Transport the scoped analysis authorizations from BW to BW/4HANA system.

Step4: Transport BW roles

Discuss with the business and identify the list of BW roles which are in scope i.e. BW roles which needs to be available in BW/4HANA system.

Transport the scoped roles from BW to BW/4HANA system.

Step5: Run SU25 Steps

Execute SU25 steps i.e. Step 2A, 2B, 2D and 2C

Extract the list of impacted roles, discuss with the business and remediate the roles.

Step6: Execute Transfer of Authorizations into BW/4HANA

BW specific authorizations for object types get impacted when we convert SAP BW to SAP BW/4HANA system like InfoCubes and those must be replaced by authorizations for corresponding object types like ADSO.

Program “RS_B4HTAU_CREATE_RUN” gives you the list of impacted authorizations for the corresponding object types.

Run Program “RS_B4HTAU_CREATE_RUN” into BW/4HANA system.

Fig.1.1

Create Rule ID to perform Transfer of Authorizations

Fig.1.2

Add the required BW/scoped roles which needs to be analyzed.

Fig.1.3

Click on the settings button to add the Suffix for the new BW/4HANA role i.e. when you execute this tool, system automatically creates new role with adjustment of authorizations for corresponding object types.

Fig.1.4

Selected BW/scoped roles with corresponding new BW/4HANA roles (with suffix) gets available in the Transfer of Authorizations tool.

Fig.1.5

Click on Initial Run and Delta Run to perform the analysis on the selected BW roles.

Fig.1.6

The output of Initial Run and Delta Run gives you the following Action Types:

ASSUME: No change in authorizations for object types i.e. Authorization will continue to work even after the conversion.

Fig.1.7

ADJUST: Check if there is any change in the values of authorization object and adapt it accordingly.

Fig.1.8

REPLACE: Change the Authorization Objects and adapt it's values accordingly.

Fig.1.9

Fig.1.10

OBSOLETE: Authorization object is not supported or obsolete, should be removed/deactivated from the role.

Fig.1.11

Click on the Generate button to create and generate the new BW/4HANA role with defined suffix.

Fig.1.12

Role gets created & generated into BW/4HANA system with automatically adjustments of All Action Types.

Note:

If there is a business requirement that not to create any new role and wants to make use of the existing role then based on the Action Types, existing roles must be modified manually via PFCG.
SAP BW/4HANA has some Fiori Apps which can be enabled and mapped into the roles based on the business requirement.

List of Important Notes:

2383530 - Conversion from SAP BW to SAP BW/4HANA

2468657 - BW4SL & BWbridgeSL - Standard Authorizations

2930058 - FAQ - SAP BW/4 Conversions

List of Important Links:

Security Guide SAP BW∕4HANA

Feedbacks, questions and comments are most welcome!!

Please follow my profile for future posts on SAP Security and GRC. Also, follow myself via LinkedIn

Happy Learnings!
Krishan Singh Chauhan

Filter table maintenance view rows based on user authorizations

2023-09-01T17:02:26+02:00

Requirement

We have a custom Z-table with Sales Organization and Order Type as key fields.

There's an associated maintenance view.

Users will be using this maintenance view to maintain entries in the table.

Users should only be allowed to display and edit records that belong to the sales organizations and certain order types that they are authorized to.

The usual approach

As many of the articles would suggest, the most sought-after approach would be to create 2 authorization objects (one for sales org, one for order type) and then use maintenance view Events 01 (Before saving the data in the database) and AA (Instead of the standard data read routine) to check each row's data against the authorization object and remove unauthorized entries.

Pros:

If the authorization objects are already in place and assigned to the user, there's no work to be done from the authorization (BASIS) perspective.

As this is purely a custom logic, this also gives freedom to introduce new error messages, extra validations, etc.

Cons:

There is coding involved as the authorization check happens at the code level.

As there's custom code involved, there will be increased unit test efforts for positive and negative scenarios to ensure that all scenarios (display, change, insert, delete) work as expected.

If we don't authorize the maintenance view from standard auth objects (S_TABU_DIS), the user should have "change" access to the SM30 transaction. Then the coding will have to control everything else. With the user getting "change" permissions to SM30, other Z tables will also become changeable - which is not what we expect.

One can't see from the authorization object assignment perspective whether there is an object assigned to the maintenance view or not.

The better approach

We can use the two standard authorization objects and the maintenance view's authorization group to handle this requirement with no code changes.

The authorization checks, error handling, and everything is handled by the standard itself which takes a significant burden off our shoulders. Also, we can clearly see in user roles how the assignment is done.

Here are the steps:

Authorization Group setup

This is needed only if you don't have an Authorization Group created already.

1. Go to the table maintenance view generator, and create an Authorization Group via Environment > Authorization > Authorization Group
2. In the new screen, under object S_TABU_DIS, create a new Authorization Group with a 4-character name that starts with Z. For this scenario, let's say it's ZAUT.
3. Go back, and assign this new Authorization Group in the Table Maintenance Dialog Genearator window.

Authorization Object: S_TABU_LIN setup

Go to SPRO > IMG > SAP NetWeaver > Application Server > System Administration > Users and Authorization > Line-oriented Authorization > Define organizational criteria

Create new Organization criteria entry:

We don't need to do anything for the "Assignment of authority object to organizational c" step.

Select the created entry, and go to "Attributes". Then, hit "New Entry". Here, we can list up to 8 attributes. The attributes are basically the key fields that we need to filter the records based on values that we define later. In this example, we need 2 attributes - VKORG, AUART. Create the first:

Hit the "Next Entry" button and create the second attribute as well. Note that the "Authorization fld:" value at the bottom of the screen is now changed to ORG_FIELD2 from ORG_FIELD1 for VKORG.

Then, go to "Table Fields" in the left-side tree. And create an entry specifying our custom table and field name that would align with this attribute.

Do the same for the next field (Attribute 2) as well. And continue to do this for all the attributes you've defined.

Once done, save under a workbench TR and exit.

Authorization Object configuration from BASIS

Now, it's time to set the appropriate values for the respective authorization objects so the setup starts working as we want.

Set "Change" permission for the Authorization Group via the S_TABU_DIS authorization object. To do so, set
ACTVT = 02
DICBERCLS = ZAUT (authorization group assigned to the table)
This allows the user to access the tables with auth group ZAUT in change mode.

Set row-level filtering via S_TABU_LIN authorization object. Set values as
ACTVT = 02
ORG_CRIT = ZTESTAUTH (this is the new organization criteria we created in SPRO)
ORG_FIELD1 = <sales org>
ORG_FIELD2 = <order type>

With this setup, it says that the user can insert/change/delete the entries belonging to sales org 1030 and order type ZORD.

Assign these to respective roles and to the users as usual and let the standard take care of all the validations, etc.

Useful Links

SAP's documentation on S_TABU_LIN

A step-by-step guide on setting up S_TABU_LIN including the authorization assignment

Custom Tcode Management

2023-09-22T00:31:35+02:00

As an SAP Authorization Administrator would have come across with Functional/IT team creating Custom tcodes for a specific Business purpose and requesting Auth team to include into a suitable role.

There are many projects/organizations still not managing custom tcodes methodically, leading to audit deficiency and in some cases misuse of critical access assigned via custom tcode.

Also, if custom tcodes technical name not based on functionality i.e Create/Change/Display, then it will be a tedious effort to categorize and also mapping into GRC ruleset for the first time, when there are hundreds of custom tcodes to be looked into.

Purpose

This document provides information on managing Custom Tcodes in any organization from an SAP Authorization team perspective.

Introduction

In SAP we have many modules and each module has specific tcodes in place to process Business data. There are few instances where Business team needs to be restricted with few fields or added more fields in a standard tcode provided by SAP. This type of requirement differs from Business to Business.

There also few scenarios when Custom data managed in a custom table, needs to be given access to Business/IT teams for data processing.

Business Case

Let’s take an example a Business team intend to restrict Company Code data field in the SAP standard tcode XK02 i.e changing Vendor. Hence based on Business requirement a Custom tcode copy of XK02 need to build with restricted Company Code Data field.

Based on my experience and per SAP best practice, i would suggest the below steps as a SAP Authorization Administrator.

Step 1: Whenever there is a need for Custom development, make sure it is relevant, unless the business requirement cannot be fulfilled/managed by SAP standard tcode. If there is an alternative tcode, suggest Business team to leverage with the same and avoid custom development.

SAP Functional/ABAP team should involve Authorization team from the initial discussions since Business team mostly contact Functional team. This will help Auth team to understand the requirement in terms of auth checks, objects, table access requirement etc.

Step 2: Upon the requirement is finalized, let there be a Functional/Technical Spec document for Custom tcode which includes Custom program names, objects, tables, Custom tcode and most important functionality i.e Create/Change/Display type of the tcode. As per SAP best practice it is suggested to use SAP standard objects within custom program and it is fine to create custom tables if needed.

Also, insist ABAP team to name custom tcode based on the nature of tcode i.e ending with 01 for create/ending with 02 for change etc. and update suitable Tcode description as per the type, since this will help to identify type of tcode if there is no proper documentation.

Step 3: Upon ABAP/Functional team completes necessary developments in Dev system, Authorization team can build a test role with new Custom tcode added and assign test role to a test user for further testing from Functional team.

Enable Auth trace for the test user to capture the auth check objects within the trace.

Scenario 1: If no objects traced when tcode successfully executed, it means there is no Authority check enabled in the Custom Program and hence inform ABAP team to include suitable objects under Authority-Check section of the custom program. Relevant Auth objects can also be identified if custom tcode is a copy of standard tcode in SU24 and same can be enabled for Custom tcode program.

Scenario 2: If objects are populated in the Auth trace as missing auth, then relevant object can be added into test role to make sure it executes successfully. Later inform ABAP team to include in the Authority-Check section with relevant objects, if not enabled in the custom program. Please make note of these objects which required to be added into SU24.

Step 4: Other option to get objects relevant by executing program RS_ABAP_SOURCE_SCAN with below mentioned search strings and based on the results ,we could classify Change/Display tcode ,based on objects with Activity i.e Change/Display.

AUTHORITY-CHECK
BDC_INSERT
CALL FUNCTION
Call Transaction
Call Method
Submit Report
Submit
Update table/Database
Delete from

Step 5: Maintain relevant Auth objects identified from previous steps into SU24 with required Values as well. After saving the changes, it will request for a Workbench transport request and capture in the same.

Step 6: Assign custom tcode into desired Business Role and make sure Auth objects are populated into the role, which were included in SU24.

Step 7: Get the necessary Unit testing performed to make sure Custom tcode functionality works as expected and proceed further with Quality for UAT.

Also update into GRC Ruleset if tcode is a Business sensitive Access (BSA) with relevant Risk id & objects and its values mapped and check for SOD conflict with existing tcodes in the role.

Please follow the sequence of ABAP/Functional changes to be moved first and followed by Security i.e SU24 and Role changes into Production system.

Key Take Aways

- Auth team involvement from early stage of requirement gathering.

- Avoid custom development if standard functionality is not available/possible.

- Suitable Naming Conventions, Authority-check enablement in Custom program by ABAP team.

- Update into SU24 with relevant objects/values and GRC Ruleset if tcode is BSA.

- Follow Sequencing of ABAP/Functional changes followed by Auth changes into Production system.

Relation between SAP S/4HANA System Upgrade | Migration | Conversion and SAP Security Upgrade

2023-12-20T00:13:38+01:00

In the ever-evolving world of SAP, it is indispensable to update Security and Authorizations as per Standard and Latest Controls. Upgrade | Migration | Conversion collectively known SAP Landscape Maintenance are the Core Project Transitions in SAP.

It is significant for a Security Consultant to understand | distinguish the above.

In this blog, I will present a crisp knowledge on Upgrade | Migration | Conversion and discuss how does it impact SAP Authorizations and when Security Upgrade should be performed.

What is SAP SECURITY UPGRADE?

SAP introduces New | Updated authorizations (Transaction Code | Authorization Object | Authorization Field | Authorization Check Indicator) to SAP Tables – USOBT | USOBX during Core Component Upgrade.

SU25 – Security Upgrade Tool will be used to update the authorizations to Customer Tables – USOBT_C | USOBX_C. Impact of Security Upgrade will be reflecting in roles post execution of Upgrade Steps – 2A, 2B, 2D and 2C.

Note : As of Dec 2023, customer can Upgrade | Convert to SAP S/4HANA 2020 & above versions (Reference SAP Note: 3338941)

CONVERSION : Customer who is in SAP ERP Central Component (ECC) getting CONVERTED to Latest SAP S/4HANA version

SAP Conversion

UPGRADE : Customer who is already in SAP S/4HANA getting UPGRADED to Latest SAP S/4HANA version

SAP Upgrade

Database Migration : This can be categorized into three approaches, and it accords only to Database.
- Lift & Shift : Homogeneous Migration of SAP Database without changing the Database type in source and target host.
- Export & Import : Migrating Database from one host to another host where source and target host may or may not have same Database type.
- Database Migration Option : Popularly known as DMO, is an option in Software Update Manager (SUM) to move the data from Non-HANA Database to HANA Database. SUM meanwhile offers Homogeneous DMO for SAP HANA to SAP HANA Migration.

SAP Migration

SUMMARY :

It is fundamental to perform Security Upgrade for Conversion and Upgrade scenarios as there is change | upgrade in SAP ABAP Component Version.

When Software Provisioning Manager (SWPM) is used for Homogeneous and Heterogenous Database Migration - Security Upgrade is not required as there is no change in SAP ABAP Component Version.

When Software Update Manager (SUM) is used for Database Migration combined with Upgrade or Conversion - Security Upgrade is required as there will be change in SAP ABAP Component Version.

SAP User Access Reviews: Best practices

2024-01-13T11:28:39+01:00

Let’s understand with a use case:

A global enterprise that uses SAP for its operations employed an executive who sensitive customer and financial information as part of his job. He was later promoted to a different position and was given new authorizations to carry out new tasks as part of his job duties. Unfortunately, while the new access was granted, no one looked at what he has or revoked the previous authorizations that are no longer relevant. As a result, this individual continued to retain both sets of authorizations.

He started utilizing these authorizations by creating numerous fake vendor accounts and subsequently approved payments to these non-existent vendors. Surprisingly, these actions went unnoticed within the company until an internal audit unearthed this irregularity.

Although this scenario may seem uncommon, many enterprises encounter similar situations. So, how to have a control on these kind of scenarios? Does SAP provide any tools/solutions to implement better controls?

Many compliance frameworks mandate period authorization reviews. Performing regular User Access Reviews holds importance in maintaining a secure and efficient system within an organization. Here are some of the advantages of conducting periodic User Access Reviews:

Advantages of conducting User Access Reviews

Additionally, in recent years, many regulations such as SOX/JSOX, ISMS and GDPR has mandated enterprises to perform User Access Reviews. However, executing these controls can be exceedingly time-consuming, potentially impeding core business activities.

This article puts a spotlight on User Access Reviews, offering insights into optimizing and streamlining this pivotal process for your organization's benefit.

Why are SAP User Access Reviews crucial?

Principally, User Access Reviews are primarily conducted for audit purposes. Mandates such as Sarbanes Oxley (SOX) and JSOX necessitate periodic User Access Reviews, commonly performed annually or semi-annually by listed organizations.

The crux of User Access Reviews lies in validating the relevance of SAP access that is provided to a user over a period of time at a later stage. For instance, if the user has requested access to ME21N (Create Purchase Orders) transaction code and it was approved few years back, does that access remain pertinent today, considering potential job function changes or role adjustments?

Consequently, User Access Reviews afford organizations the chance to reassess a user's access, ensuring its continued relevance amidst potential shifts in roles or job functions. An added benefit is correcting and ensuring that SAP authorizations are well managed.

Nonetheless, for many organizations, conducting a User Access Review solely to fulfil audit requirements, especially given the significant effort required from business users. However, there's a pressing need to shift the mindset surrounding User Access Reviews from a mere audit checkbox to an effective tool for managing access risks.

How can this mindset change be fostered?

To encourage a shift in thinking within organizations, it's crucial to emphasize the consequences of not performing the reviews. If the access control process is perceived as complex, the initial step is to simplify it and set up the right process of managing accesses and regular review procedures. This not only limits the authorizations, but also helps in identifying the users with unnecessary authorizations and further contributes insights for restructuring and streamlining the authorization processes. For instance, you can pinpoint users with access to critical permissions and remove those permissions when they are no longer necessary for their job duties.

Diagram that show the Mindset Shift in enterprises wrt Authorization Reviews

After simplifying the access control process and setting up regular reviews, the next step is to implement an automated system. Various solutions such as SAP GRC Access Control User Access Review (UAR), or ReviewNow streamline User Access Reviews by providing comprehensive information, aiding users in making informed decisions. Such tools can be configured to expedite the process and present technical SAP role language in user-friendly terms.

How to achieve better output?

How to achieve better output with User Access Reviews

Role Design: Many organizations adapt to role design approaches that are complex to understand and manage. For example: Enabler roles. It is highly recommend to simplify the SAP role design to aid users in comprehending user access easily. A descriptive role design facilitates informed decisions by users during the review process.

Role Methodology: Opt for a role methodology that reduces the number of role assignments, making the User Access Review less arduous for business users. Consider methodologies like task based and value based roles to streamline access.

Rule-set Customization: Customized rule-sets empower business users to better understand the potential access risks, aiding informed decisions during the review.

Split Reviews: Consider segregating reviews into User Access Reviews, Critical Authorization Reviews, Reviews for key business users and so on. This enhances the focus and efficiency of each review.

Iterative Reviews: Divide large annual reviews into smaller, more manageable reviews across geographical regions, risk levels, user groups, or SAP modules. This minimizes certification fatigue among reviewers and enhances efficiency.

By implementing these strategies and emphasizing the value of User Access Reviews beyond mere audit compliance, organizations can effectively manage access risks while ensuring the process remains user-friendly and impactful.

Conclusion:

In conclusion, SAP User Access Reviews are critical to safeguard the organization from potential inside and outside attacks and adhere to compliance with regulations like SOX and JSOX. While these reviews offer benefits, a mindset shift is needed to view them not just as audit checkboxes but as tools for effective access risk management. The article suggests simplifying access processes, establishing systematic reviews, and emphasizing the consequences of neglect. Automation tools like SAP GRC Access Control User Access Review or ReviewNow can streamline and simplify the process. Practical strategies include role design simplification, efficient methodologies, rule-set customization, and iterative reviews. Implementing these recommendations ensures a user-friendly and impactful User Access Review process that aligns with business goals.

Basis Monitoring & Tcodes with Key notes

2024-02-05T14:25:53.980000+01:00

Hi All,

I am thrilled to have the opportunity to connect with all of you through this blog.

The purpose of this blog is to aid newcomers in Basis in gaining knowledge about Basis-related Tcodes, including key notes and their usage and frequency.

I believe this will be beneficial for those who are beginning their careers in SAP Basis.

I wish you good luck and welcome to SAP Basis Team

The Daily Monitoring Basis-related Tcodes, their uses, and their related Tcodes are utilised for any future investigation.

Tcodes that pertain to operating systems and databases, their usage, and any future process.

The SAP Basis Admin is accountable for tuning performance. These Tcodes are associated with performance analysis at the application level.

Ticketing tools vary widely between organizations, including SAP ITSM (SOLMAN), Non SAP (ServiceNow, Zendesk), and others.

User Management, Role Management, and Transport Management will receive the majority of daily ticketing. Here are the Tcodes that pertain to these areas.

Tcodes that pertain to SAP Software Maintenance and related OS and other tasks.

Programs that are useful for administrative tasks related to Basis.

Thank you for taking the time to read the blog.

#SAPBasis #Basis Basis Technology EWM - Basis NW ABAP Monitoring Tools SAP EarlyWatch Alert SAP HANA Cloud, SAP HANA database SAP Advantage Database Server Oracle Database SAP S/4HANA SAP NetWeaver Application Server for SAP S/4HANA #Dailymonitoring NW Java Security and User Management Defense and Security SOLMAN Setup/Configuration/LMDB NW ABAP Monitoring Tools SOLMAN System Monitoring

User types in SAP ABAP Stack Systems

2024-02-28T14:30:09.735000+01:00

This blog will outline the various user types found in SAP ABAP Stack Systems

User Types

In SAP systems, Users play a pivotal role in accessing and utilizing the various functionalities provided by the system.

In the Transaction SU01- user management system, we primarily categorize users into five distinct types:
1.Dialog

2.System
3.Communication
4.Reference
5. Service

Dialog Users (A): These are regular users who interact with the SAP system through the graphical user interface (GUI) or web interface ( SAP GUI for HTML). They perform tasks such as entering data, running reports, and executing transactions relevant to their roles assigned to them.

Multiple logon is checked.

System Users(B): System users are typically used for background tasks, such as running batch jobs, executing automated processes, or performing system-to-system communication. They do not require direct interaction with the GUI.

Multiple logon is allowed, Only an administrator user can change the password.

Communication Users (C ) : Communication users are primarily used to establish connections and facilitate communication between SAP systems or between SAP systems and external applications, services, platforms and integration scenarios such as RFC (Remote Function Call), SOAP (Simple Object Access Protocol), HTTP (Hypertext Transfer Protocol), IDoc (Intermediate Document), ALE (Application Link Enabling), EDI (Electronic Data Interchange), and more .

Logon with SAPGUI is not possible

Reference Users (L) :Reference users are special types of user accounts that serve as templates or blueprints for creating new user accounts with predefined settings, roles, authorizations, and other attributes. They are used to streamline the process of user creation and ensure consistency across user profiles within the SAP system

No logon possible.

Service Users (S) : Service users are considered technical users because they are primarily used for technical tasks rather than human interaction. They are often assigned specific technical roles and authorizations required for performing their designated tasks.

unlike regular dialog users who interact with the SAP system through the graphical user interface (GUI), service users typically do not require direct interaction with the GUI. They may communicate with the system through interfaces, APIs (Application Programming Interfaces), or background processes.however SAP GUI logon is Possible

Multiple Log on allowed.

User Master Record
User Master Record in SAP is a fundamental component that stores and manages information about individual users who access the SAP system

Creation of user accounts in SAP systems is client-dependent, meaning that user master records must be established separately in each client where users need access.

User Master Record in SAP contains a variety of information pertaining to individual users who access the SAP system. This information is crucial for managing user access, permissions, and preferences within the SAP environment. These are the key components typically found in a user master record:

User Details Like Name, Department, function, responsibilities, user group, user type and License

User Details with Validity ,Lock Status, and authentication properties

User Settings Like parameters, spool requests, time zone.

Note : User details, such as user IDs, hashed passwords, authorizations, and related information, are stored in the USR02 table

User Deletion

User deletion is always possible and can be done using the transactions SU01 or SU10. During the deletion, all of the personal data belonging to the user master is deleted

Deletion Effects: Deleting a user account in SAP has several effect such as

The user's access to the SAP system is immediately revoked.

Any active sessions associated with the deleted user account are terminated

Authorization objects and roles assigned to the user are removed.

User-related data stored in tables such as USR02 (User Master Record) is deleted.

After deleting a user account, administrators may need to perform additional tasks, such as reassigning responsibilities to other users, updating documentation, or communicating the deletion to relevant stakeholders

#basis #abapstack #netweaver #ECC SAP S/4HANA

SAP S/4HANA - Extracting User Email Addresses from Standard Tables

2024-05-10T15:09:30.362000+02:00

What are we discussing here?

When working with SAP systems, it is fundamental to need / verify user email addresses for various purposes. Whether it is to send Automated Notifications, facilitating communication between users, or Generating Reports, having accurate and up-to-date email addresses is crucial. However, extracting the email address from SAP system is not as easy as we think. In this blog post, we will explore the simplest method to extract / find email addresses of users from SAP Standard tables.

Note : There is no direct transaction code or program to extract email addresses of users

How are we going to achieve it?

The primary table that stores user information in SAP is USR21. This table contains User Master Data, including Personal Numbers (PERSNUMBER) associated with each user. To retrieve email addresses, we will link this table with the address data table ADR6.

What is USR21?

USR21 is a standard table in SAP ERP system that assigns User Names and Address Keys.

What is ADR6?

The ADR6 table in SAP ERP system is a standard table that stores email addresses (Business Address Services) for any address record.

Procedure to Extract Email Address from SAP Tables

Execute table view transaction code: SE16 -> Enter Table Name : USR21 -> Execute

Provide the list of User ID(s) through Multiple Selection for BNAME -> Execute

Copy the list of Personnel Number (PERSNUMBER) for the users

Execute table view transaction code: SE16 -> Enter Table Name: ADR6 -> Execute

Provide the list of Personnel Number(s) through Multiple Selection for PERSNUMBER -> Execute

SMTP_ADDR column of ADR6 table will provide the list of email address for users

SAP also offers to extract the list into Spreadsheet from this screen

Tip : Ensure to select ALV Grid Display in User Specific Settings at initial screen of ADR6

What are other options?

Another approach for SAP S/4HANA is to leverage the built-in Core Data Services (CDS) view.

Table : PUSER002 can also be used | BNAME = UserName | Ensure column SMTP_ADDR is visible

Word of Caution

Avoid Unintended Disclosure

When querying SAP tables, be cautious not to inadvertently disclose email addresses to unauthorized users or external sources.

Limit access to relevant personnel and follow proper authorization procedures.

Remember, accurate and secure email addresses contribute to smooth business processes and effective communication within your organization. Handle them responsibly, and always prioritize data protection.

If you have any further questions or need assistance, do not hesitate to comment on this blog. Happy SAP querying!

Feel free to share this article with your colleagues and peers who work with SAP systems.

Unlocking the Power of RSUSR_LOCK_USERS Report in SAP

2024-05-20T16:11:52.741000+02:00

Are you finding it challenging to use EWZ5 for locking and unlocking users during upgrade activities? Have you discovered that this transaction code is now obsolete and are you relying on a custom program? If so, consider using the ABAP program RSUSR_LOCK_USERS.

This program simplifies the user locking and unlocking process, making it an invaluable tool for managing user accounts efficiently during system upgrades.

Understanding RSUSR_LOCK_USERS

RSUSR_LOCK_USERS is a simple yet effective program that is built on top of RSUSR200 program. Here is the list of options available in the program screen:

As highlighted in the picture, the RSUSR_LOCK_USERS report offers the following sections:

Section	What it offers?
User Selection	This section offers the following: User – Selection of specific users. Group for Authorization – Uses SU01 user group assignments and picks the users based on the group assignment. Security Policies – Uses the Security Policy assigned to the user in SU01. Days Since Last Logon – To specify the no.of days since last login (for eg: If you wish to lock the users who haven’t logged-in to the system in the last 90 days, enter the value as 90). Days Since Password Change – To select users based on last password change.
Selection by Validity of users	Selection by Validity of users can be filtered by today's validity or by a specific period. Today (current date) – This option will specifically check for valid and invalid users of current date. Users Valid Today – Consider the valid users of current date Users Invalid Today – Consider the Invalid users of current date Validity Period – This option will specifically check for valid and invalid users over a specified period of time. Users Valid <From> and <To> - Consider the valid users within the time period specified in the input. Users Not valid <From> and <To> - Consider the Invalid users within the time period specified in the input.
Selection by Locks	This option facilitates filtering users based on their lock status. Below are the lock criteria that can be considered. Selecting one of these options is mandatory (Radio button selection). Differentiation of Locks All users with Administrator or Password Locks Only Users without Locks *Differentiation of Locks* User Locks (Administrator) – When the value "Set" is selected, it will include the list of users who have been locked by the administrator, with lock statuses of 32 and 64. When the value " Not Set" is selected, it will exclude the list of users who have been locked by the administrator, with lock statuses of 32 and 64 Password Lock (Incorrect Logon) – When the value "Set" is selected, it will include the list of users who have been locked due to incorrect logons with the status of 128 while when the value “Not Set” is selected, it will exclude the list of users who have been locked due to incorrect logons with the status of 128 *All users with Administrator or Password Locks –* It will include all users who meet the condition of being locked by the administrator (with lock status 32 & 64) or having password locks (with lock status 128). *Only Users without Locks -* It includes users without any lock status (Active users)
Selection by Login attempts	This section sorts users based on their login attempts to the SAP system. By default, all options are selected, and you can deselect a box to exclude. Alternatively, all boxes can be unchecked if you do not wish to use this option. Users with incorrect Logon Attempts – Considers users who have made incorrect logon attempts. Users with no Incorrect Logon Attempts – Considers users who have not made any incorrect logon attempts. User Without Logon Date – Considers the users without any logon date in SU01
Selection by User Type	Selection by User Type filters users based on the user type defined in SU01. For example, you can lock only dialog users based on conditions specified within this program, such as users who have not logged into the system for a specific period of time. Below are the user types available under this criteria: Dialog Users Communication Users System Users Service Users Reference Users NOTE: By default, all options are selected, and you can deselect a box to exclude. Alternatively, all boxes can be unchecked if you do not wish to use this option.
Selection by status of password	This section will be considered the users based on the status of the user password. ·Users with Production Password – Productive user Users with Initial Password – Users who have never logged into the SAP system after the initial password was set by the admin. Users with Deactivated Password – Users who password is deactivated As selection type “Selection by Login attempts and Selection by User Type”, by default, all options are selected here as well, and you can deselect a box to exclude.
Activity selection	Once all the selection criteria are defined according to your requirements, you can proceed to the Activity selection option to specify your actions. Based on the conditions specified above, the result will now be executable. Below are the actions that can be taken when you execute the program. Test Selection – Test Selection presents the list of users on the output screen according to the criteria defined before any of the activities listed below are executed. Lock Users (Local Lock) – To Lock the user locally Unlock Users (Local Lock) – To unlock the user locally Set the End of the Validity Period to Today (Only for Valid Users) – Validity of the user will be ended with today’s date Set the End of the Validity Period to Yesterday (Only for Valid Users) – validity of the user will be ended with the yesterday’s date

As mentioned, RSUSR_LOCK_USERS aids in compliance and audit processes by providing a clear record of user account status and actions taken. This ensures that the organization can demonstrate adherence to security policies and regulations.

How to Use RSUSR_LOCK_USERS?

Execute transaction code SA38 or SE38.
Enter “RSUSR_LOCK_USERS” in the program field and execute the report.
Complete the required selections such as specific users, lock/unlock conditions, and date ranges etc.,
Run the program to generate a list of users.

Consider the following condition for ending the validity of users as a reference. I have selected dialog users regardless of their password status—whether it's production, initial, or deactivated—and those who are already locked by the admin or due to password lock. Additionally, I have chosen users without logon data under "Selection by Logon Attempts." Once users meeting the defined criteria are identified, their ID validity should be set to end with yesterday’s date.

After executing the program, the output will display the User IDs for which changes were made.

Result: According to the given criteria, user validity is ended with yesterday's date. The program was executed on 20.05.2024, so the user validity is set to end on 19.05.2024.

Additionally, the program can be scheduled to run at regular intervals, ensuring that administrators are always aware of any locked user accounts. Automation can help in maintaining continuous oversight without manual intervention.

Steps to schedule the job in the background:

To automate the locking, unlocking, and validity ending of users without manual intervention, you can schedule this job to run in the background. This enables the program to execute automatically at specified intervals, ensuring users are locked or unlocked according to predefined criteria. It's recommended to thoroughly test the program in a non-production environment before scheduling it in a production system to ensure proper functionality and minimize potential disruptions. Follow the below steps to schedule the job in the background:

Execute transaction SE38 and input the program RSUSR_LOCK_USERS, then proceed to execute it.
Define the criteria for locking/unlocking or ending the validity of the user.
Click "Program" to schedule the job in the background or press F9

4. Specify the frequency at which the job should run and click Save.

When you have multiple criteria to schedule in the background, specify your criteria and press Ctrl+S to save as a variant as shown below:

After saving the variants, the job can now be scheduled in the background via transaction code SM36.

Conclusion

The RSUSR_LOCK_USERS program is an indispensable tool for SAP administrators, providing critical insights and control over user account management. By effectively utilizing this program, organizations can enhance their security posture, ensure compliance with regulations, and maintain smooth operational workflows. Regular use and prompt action on the findings of the RSUSR_LOCK_USERS report will help in minimizing user access issues and reinforcing overall system security.

Sap Authorization Audit Readiness & Critical Access Monitoring!!!

2024-06-26T07:12:42.494000+02:00

As an SAP Authorization consultant, year on year we go through Internal/External Audit trials and provide evidence/clarifications for the samples requested.
We need to justify if there a slippage in Process/Access assignments and leading to Audit Deficiencies failed to provide evidence.
Auditors will leave no chance to find a process gap like an eagle catching a fish which is just above the river 🙂

To avoid Audit deficiencies, we need to have a detailed SOP (Standard Operating Process), religiously follow the process and document exceptions, if any.
The most important aspect is to monitor Critical authorization assignments on monthly(suggested) or quarterly to assess unwanted assignments and remediate even before noticed by Audit team.

I have outlined most of the Critical Authorization monitoring controls as follows

1. Security Audit Parameters

Below table provides generic Audit Parameters to be configured in Production systems, which are most important with regards to Audit controls. Below values specified are with respect to SAP best practices and may differ from individual organizations as well.

Password Parameters	Value
login/min_password_lng	12
login/min_password_digits	1
login/min_password_lowercase	1
login/min_password_uppercase	1
login/min_password_specials	1
login/password_history_size	4
Login and Session
login/failed_user_auto_unlock	1
login/fails_to_session_end	3
login/fails_to_user_lock	6
login/no_automatic_user_sapstar	1
rdisp/gui_auto_logout	1800
auth/object_disabling_active	N

2. SAP Standard User Password and Active Status

Sap Standard users such as SAP*, DDIC, TMSADM, SAPCPIC etc should have their initial password changed and keep locked these users in clients such as 000,001,066 & Prod client and in some cases TMSADM and DDIC will be kept unlocked in master clients.

To validate Execute Tcode RSUSR003.

3. Critical Standard Profiles (SAP_ALL and SAP_NEW)

SAP standard critical authorization profiles SAP_ALL or SAP_NEW must not be assigned
to any users in any of the clients.
To check Go to SUIM-->Users by Complex Selection Criteria-->Roles/Profiles-->Profile Name SAP_ALL and SAP_NEW.

4. Standard SAP Roles Assignment

Any users in Production client must not be assigned with SAP standard roles i.e Roles starting with SAP* or /*. To check go to SUIM-->Users by Complex Selection Criteria-->Roles/Profile--> SAP* or /*.

5. Access to Create User Master

Access to create User master in Production should be restricted to Authorization team, since they need to create Service/System users. Dialog user creation should be via GRC system.
To Check SUIM >User by Complex Selection Criteria >S_USER_GRP ACTVT = 01

6. Access to Change User Master

This access is restricted to Authorization team and any other user should not be assigned with.

SUIM report >User by Complex Selection Criteria >S_USER_GRP ACTVT = 02 or 06

7. Access to Unlock Users or Reset Password

In ideal scenario, IT/Business user login to Production system via SSO (Single Sign On). There are exceptions for password login such as IT Admin Users (Security & Basis) and few Business users, who need to connect to third party tools (example RF Gun) via Production user credentials. All the exceptions should be documented in SOP.

SUIM report > User by Complex Selection Criteria > S_USER_GRP ACTVT = 05

8. Access to Debug with Change

Debug change access must be restricted from any Dialog users in Production and it should be part of an FF user only.
To check SUIM report > User by Complex Selection Criteria > S_DEVELOP ACTVT = 02
and OBJTYPE = DEBUG

9. Access to Import Transports

Only Basis/Release team should have access to import access in Production system.
SUIM>User by Complex Selection Criteria >S_CTS_ADM > Value= IMPA or IMPS
SUIM report > User by Complex Selection Criteria > S_TRANSPRT ACTVT = 60

10. Execute Access for All Programs

No Users in Production should be assigned with all Program execute access.

SUIM >User by Complex Selection Criteria >S_PROGRAM P_ACTION = SUBMIT & P_GROUP = #*

11. Authorization Objects Added Manually or Changed in Roles

All authorization objects in the roles should be in Standard or Maintained status. Any exceptions should be documented. As per SAP best practice no objects should be added manually and there will be adverse effect during upgrades, since tcodes will fail which are dependent on manually added objects, but not linked via SU24.

12. Custom Tcodes Without Authorization Object Linkage in SU24

Custom Tcode must be associated with authorizations objects maintained in SU24.
To check, extract all custom tcodes from SE16-->TSTC-->Z*
Next copy tcodes from TSTC into table USOBT_C to check tcodes with SU24 object mappings and if tcodes not available in the report, then such custom tcodes must be added with suitable auth object into SU24.

13. Administrator Access for All Batch Jobs

Batch admin access with Administrator i.e Y access should be restricted to Basis team.
SUIM report > User by Complex Selection Criteria > S_BTCH_ADM BTCADMIN = Y

14. Access to Delete Batch Jobs

SUIM report >User by Complex Selection Criteria >S_BTCH_JOB JOBACTION = DELE

15. Access to Delete Logs or Jobs in Batch Input Processing

SUIM report > User by Complex Selection Criteria > S_BDC_MONI BDCAKTI = REOG or DELE

16. Access to All Batch Input Processing Sessions

SUIM report > User by Complex Selection Criteria > S_BDC_MONI BDCGROUPID = #*

17. RFC Administration Access

This acccess should be restricted to either basis team or Batch Monitroing teams.

SUIM report > User by Complex Selection Criteria > S_TCODE = SM59 and S_ADMI_FCD = NADM

18. Execute Access for All RFCs

This access should not be assigned to any Dialog users in Production system. For Batch job users also assign only required RFC authorization based on trace results, rather assigning full access.

SUIM report > User by Complex Selection Criteria > S_RFC = #* (or S_RFC = "*")

19. Change Access for All Tables

SUIM report >User by Complex Selection Criteria >S_TABU_DIS ACTVT = 02 and DICBERCLS = #*
SUIM report >User by Complex Selection Criteria >S_TABU_NAM ACTVT = 02 and TABLE = #*

20. Display Access for All Tables

You may be wondering why display access is critical, this is because a business user with display access on all tables can view Business critical information and leading to Business loss/audit deficiency.

SUIM report >User by Complex Selection Criteria >S_TABU_DIS ACTVT = 03 and DICBERCLS = #*

SUIM report >User by Complex Selection Criteria > S_TABU_NAM ACTVT = 03 and TABLE = #*

21. Access to Modify Client Settings

SUIM report User by Complex Selection Criteria >S_TABU_DIS ACTVT = 02 and DICBERCLS = SS
SUIM report >User by Complex Selection Criteria >S_TABU_NAM ACTVT = 02 and TABLE = T000

Note: Auth Group SS contains Security relevant tables and hence should be assigned to IT team only.

22. Access to Tables Not mapped to Authorization Groups

Tables i.e Both Standard and Custom, that are not mapped to specific authorization groups, will be automatically assigned to &NC& group. We need to make sure no users should have change access to group &NC& in Production.

23. Access to Maintain Cross-Clients Tables

SUIM report > User by Complex Selection Criteria > S_TABU_CLI CLIIDMAINT = X

Conclusion:

Frequent monitoring of above critical access assignments will help to be prepared for Audit at any day and IT HPA (High Privilege Access) review as well, to make sure only relevant IT users assigned with privileged access.

Regards

Shivkumar

Optimizing Your SAP S/4HANA Landscape with a Best Practice Role Concept

2024-08-29T23:50:00.035000+02:00

Optimizing your SAP S/4HANA Landscape with a Best Practice Role Concept

Experts familiar with SAP authorizations are well aware that quality issues and complexity of legacy role concepts often prompt the desire to start from scratch with a brand-new concept. However, the thought of the associated effort and high costs discourages many. What if there were a more efficient solution?

Typically, the following topics are initiators for a revision of authorization concepts:

SAP S/4HANA implementations in cloud or hybrid environments usually require – following the "keep the core clean" strategy – a new SAP S/4HANA authorization concept as well as an authorization concept for the SAP Business Technology Platform.
SAP S/4HANA greenfield implementations for new SAP customers as well as existing SAP customers developing new processes based on SAP S/4HANA require a new authorization concept that fits to their new process design and covers access to SAP Fiori Launchpad
SAP S/4HANA brownfield implementations that cause a redesign or at least an update of the existing authorization concept.
Audit and compliance requirements that may result in a revision or redesign of the SAP authorization concept.

In this blog post, we introduce the benefits of the “Automated Implementation of Role Concept” Service ("AIRC Service"), which shortens the efforts and duration of the projects by applying pre-defined roles and a high level of automation. Based on a clear methodology, the service has proven to be a key for the success of authorization projects within more than 200 customer projects over the past 15 years.

How does the use case look like for the implementation of a new authorization concept?

When developing a new authorization concept, the initial scope is important, i.e. which applications (i.e. Transactions as well as Fiori Apps) should be part of the authorization concept. This is a task in the responsibility of the business departments, but AIRC service supports it by offering the following approaches:

"Top-Down Approach" via SAP Signavio Extraction or manual upload:
- With the AIRC service, data can be automatically extracted from SAP Signavio. SAP Signavio is the recommended solution for the (re-) design of Business Processes.
- If other tools for modelling business processes are in place, the data can be exported and used by AIRC Service.

The Top-Down Approach is the preferred method for greenfield implementations.

Business Reverse Engineering:
- By examining the transactions used in the SAP system, which can be extracted and used as a baseline for defining the new role proposal, the AIRC ensures that only the necessary functions are authorized. For customers moving from SAP ECC to SAP S/4HANA or upgrading their SAP S/4HANA, the following analyses are also helpful:
  - SAP S/4HANA Impact Analysis: This analysis checks applications for availability in the target release and lists any corresponding successor applications (transactions or apps).
  - Fiori App Recommendations: This analysis lists which native Fiori apps can complement a defined range of SAP transactions.

“Business Reverse Engineering” is the preferred method for brownfield implementations.

Best Practice Role Proposal

Over the years, SAP Services have developed a database consisting of proven best practice roles that meet the following quality criteria:

Functional role concept
Consideration of typical segregation of duty (SoD) requirements
Display and maintenance roles
Module-specific roles
SAP Business Technology Platform (SAP BTP) authorization concept
and many more

This database is constantly being expanded based on new applications (e.g. new Fiori apps) and continuously optimized based on customer feedback.

Using the methods described above, we can quickly provide the customer with a customized role proposal from the intersection of the scope and our role database (often already at the project kick-off). We also offer role assignments for customer-specific applications using algorithms (partly AI-based).

The role proposal provides a solid framework that significantly reduces efforts in the business departments, enhances quality, and stipulates a unified format.

Role Implementation

The AIRC service considerably supports the implementation of roles through automation, greatly reducing the efforts required for implementation. The following steps outline the implementation:

Creation of roles with corresponding applications: Based on the authorization concept revised by the business departments, PFCG roles and Fiori catalogs, including assignment of transactions and Fiori apps, are generated using the AIRC service tool-based approach.
Maintenance of non-organizational authorization fields: The corresponding authorization values in the roles are manually maintained with the help of standard proposals (SU24) and feedback from the business departments.
Generation of organizational or non-organizational supplementary roles: Special authorizations require supplementary roles, consisting of distinct authorization objects (examples include release codes, order types, document types, etc.). We generate these roles from Excel files using a tool-based approach.
Generation of role derivations: We recommend using the SAP standard derivation concept. For each organization, so-called "orgsets" can be defined, which contain the specifications for the organizational restrictions of that organization (company code, plant, purchasing organization, sales organization, etc.). Role derivations can then be generated using the AIRC service based on these “orgsets”. This step is not feasible to perform manually for larger companies or projects involving around 20, 100, or 200 organizations.
Generation of SAP SAP BTP (Business Technology Platform) roles and role collections: In "side-by-side extensions", business data can also end up in the SAP BTP, which can lead to many SAP BTP roles / role collections. The AIRC service offers tools necessary for generating and transporting these roles, protecting you from unpleasant surprises such as significant manual efforts just before Go-Live.

Testing roles

For re-design projects, the SAP standard offers a very useful, currently not very well-known feature:

With the transaction "STSIMAUTHCHECK" it is possible to simulate which authorization checks would fail when using new roles instead of old ones. In our experience, for new implementations, the classic method of testing and ad hoc correcting roles individually is one of the most effective. The AIRC service can also be used in conjunction with partner products that support the tests.

Assignment of roles to users

If usage data is available, we support the assignment of roles to test users and end users with role assignment proposal, structured according to the following procedure:

Allocation of default authorization roles
If an application has been used by a user that occurs in different roles, the less critical role is initially suggested.
Organizational assignments can be made based on the user's organizational assignments or based on the organizational assignments of the old roles.

If the customer does not have their own Identity Access Management tools, we support the implementation of the assignment with corresponding tools (ABAP and SAP BTP).

Go-Live

With the use of "STSIMAUTHCHECK," you can conduct a secured Go-Live, which is carried out using old authorizations and logging of theoretical authorization errors caused by the new roles. For a re-design, the transition usually occurs in two to four increasingly larger user packages.

Do I also get support if I decide to rely on my former role concept?

If there are no major changes in business processes and the authorization concept of the customer is already at a high-quality level, customers might decide not to reimplement the authorization concept with SAP S/4HANA. For all the new topics (e.g. roles for SAP BTP) the above steps can still be applied. For the existing role concept, the differences between SAP ECC and SAP S/4HANA or between different SAP S/4HANA releases can be derived by an Impact Analysis. We will not further describe this topic in this blog post, please contact us if you want to get further details on this topic.

Wrapping It Up: Key Takeaways

The AIRC service addresses the required re-design of permissions within upcoming changes such as cloud transformations, SAP S/4HANA projects, or tightened compliance requirements. With the AIRC service's help, the implementation efforts and runtime of authorization projects can be greatly reduced. You will receive a standardized and well-proven role concept that meets common compliance requirements. The service’s automations also support newer technologies like processing Fiori artifacts and SAP BTP Roles/Role Collections, preventing issues with newer technologies in upcoming projects.

Title: S/4HANA authorization management: the SAP Activate method thought differently

2024-10-24T11:46:58.908000+02:00

The implementation or redesign of SAP authorizations is often associated with long projects, complex requirements and high resource expenditure. Especially in times of crisis, the feeling of uncertainty when implementing such projects can be overwhelming. But does it really have to be like this?

In the wake of the current economic uncertainty, I have developed a completely new approach - the Rapid System Implementation (RSI) method ‘4i’. This method is not only faster, but also eliminates many of the classic project risks. How does it work? By using established best practices in a way that minimises risks and drastically shortens the project duration.

Why is the crisis the right time for innovation?

Crises always mean opportunities! Richard David Precht summed it up perfectly: ‘If there is an opportunity to rethink, then there is an opportunity to rethink in a crisis’. For us, this means that especially in difficult economic times, the time has come to rethink old patterns and break new ground - even in the S/4HANA authorization world.

The RSI 4i method - a new approach for SAP authorization projects

The Rapid System Implementation 4i method is the key to a fast, secure and flexible implementation of SAP authorizations. Here are the four steps that make up this approach:

information: structured keycards are used to collect all relevant company information in order to optimally customize the SAP best practice building blocks.
installation: The best practice package is installed immediately at all levels - including individual roles, catalogues and business roles.
integration: Short test phases by key users ensure that everything works smoothly before we go live.
implementation: SOD-compliant roles are assigned in stages and without risk - thanks to the option of secure fallback.

What's special about this method?

Speed: The project timeframe is drastically reduced and we achieve the goals faster than ever before.
Security: The RSI method eliminates many of the classic project risks. As we do not touch the old authorizations, there is always a fallback.
Efficiency: The introduction of best-practice roles is structured and without the typical lengthy problems that often occur in complex projects.

Why SAP_BR* roles are not the answer

An important note: The SAP_BR* roles supplied by SAP are not intended for productive use (see Administration Guide to Implementation of SAP S/4HANA, SAP Help etc.). These roles are intended for demo purposes only and do not fulfil any regulatory requirements. An individually adapted authorization concept is therefore essential - and this is precisely where we come in with the best practice approach using the RSI 4i method.

Conclusion

It is possible to think differently about authorization projects and reach the goal faster - without the usual project pain. The RSI 4i method offers a real alternative that combines efficiency, security and speed.

If you too would like to think and act differently during the crisis, I invite you to a strategy meeting. Together we can discuss your individual challenges and identify concrete solutions.

Discussion & exchange

I welcome your feedback and look forward to hearing your ideas and exchanging experiences on SAP authorizations - thinking differently.

If you like, you are welcome to watch the video, which explains the method on a slightly less technical level: S/4HANA authorization management thought differently

Note: translated with DeepL

Master S/4HANA authorisation issues: A practical guide with Visio Overview

2024-10-29T12:19:43.221000+01:00

Master S/4HANA authorization issues: A practical guide with Visio overview

Authorization issues in SAP S/4HANA can significantly impact your day-to-day work. As an SAP authorization expert, I would like to present a systematic troubleshooting overview that may help you to efficiently overcome these challenges.

The challenge

SAP authorizations are as diverse as the business processes they protect. Small mistakes can have far-reaching consequences. The trick is to develop a flexible but clearly regulated authorisation concept that can adapt to changing requirements without becoming inconsistent. The world of authorizations has not become any easier with S/4HANA.

A systematic approach to troubleshooting

To effectively solve authorization problems, I have created an overview that structures the troubleshooting process from the client level to the backend system. Let's go through the key steps:

1. client level (Fiori Launchpad)

Fiori Launchpad App Support: Provides important information such as the SAP Fiori ID, business server page name, service node and OData service, as well as any authorisation, gateway or runtime errors that have occurred.
Browser Developer Tools (F12):

Elements: Check the loaded components
Console: JavaScript errors and runtime problems
Sources: Direct access to JavaScript code Custom code file debugging
Network: Checking the OData HTTP URLs Requests, responses and error messages

2. Front-End Server (FES)

/IWFND/MAINT_SERVICE (OData configuration):

Model cache cleanup
Metadata reload
SICF configuration
Service addition and configuration
Gateway client: Cache cleanup, cache rebuild, request execution
Service Implementation: Checking for errors or insufficient authorizations
RFC Connection (SM59): Ensuring the correct configuration between the front end and the back end

/IWFND/ERROR_LOG (OData Error Log): Analysing data transfer problems between FES and BES

3. Back-End Server (BES)

STAUTHTRACE: Detailed analysis of authorization problems, including CDS view level
FLP Content Manager (/UI2/FLPCM_CUST): Checking the Fiori catalogues and their configuration
PFCGUPDATEROLEMENU: Matching the catalogues with authorization roles
Profile generation and user matching: Ensuring consistency

Fiori Apps Library: An indispensable tool

The Fiori Apps Library is invaluable at every stage of the analysis. It provides detailed information on prerequisites, installation requirements, component statuses and service configurations for each Fiori app.

Conclusion

This structured approach makes it possible to systematically isolate and resolve authorization problems. Note that the order of the steps may vary depending on the specific error. Experience plays an important role, but even for experienced experts, this overview can serve as a valuable checklist.

I invite you to download the S/4HANA authorization troubleshooting overview and use it in your daily work. Feedback and suggestions for improvement are explicitly encouraged, as we can all learn from each other.

Do you have any questions or comments? I look forward to your comments and a lively exchange!

Note: translated with DeepL

ABAP AUTHORITY CHECK Explained: A Practical Guide with Real-World Example

2025-03-11T15:16:40.128000+01:00

AUTHORITY-CHECK IN ABAP:

Is a concept which enables or allow users to perform certain functions/ activities in the SAP system

So, we will look for an example of such activity:

To create a material or sales order I suppose to have authorization

System checks whether I am authorized for the task or not –then only the system will proceed further

Suppose in a general scenario while talking a leave the manager needs to authorize the request of our leave approval .

What happens in SAP ?

In SAP basis person will assign the authorization object to user id to proceed it further

Terminologies in authority-check.

Object class: it is a container for authorization objects

Authorization object: object to check authorization

Authorization field: an authorization object has the authorization field which is used to define field values

Here the hierarchy goes like

T-CODES:

Authorization field – SU20

Object class and authorization object: SU21

OVERVIEW:

The first and foremost thing is we need to check for authorization object class

Which is a container for authorization object

Once we create the object --> we need to assign the filed

Scenario:

Suppose we are using MM01 transaction to create a material, and we get an error

At this moment we can inform BASIS people to check for the authorization in case we need any.

Step;

Create a material and put external BP

2.Put breakpoint on statement AUTHORITY-CHECK .

Here we can see auth object is ‘M_MATE_NEW’

Field – ‘DUMMY'

Value - ‘*’

3.If we provide the field in SU20

Whenever we execute sy-subrc will be zero – indicates that we are authorized

Or else it will give sy-subrc 12 indicating we are not authorized to create the material

here we have provided the field ACTVT—We shall have a glance about this

The filed ACTVT has some permitted values—click on the status icon beside ACTVT

01- IT IS CREATE

02- CHANGE

03- DISPLAY

Suppose if we provide a material and put external bp –we get same authorization value

7.So, in the ACTVT we saw 02- for change and same for display

The ACTVT holds value-03 and here we can see the field value

Now let's take real time scenario:

Implementing authorization checks in ABAP program is crucial to ensure that only authorized users can perform operations like INSERT, UPDATE, or DELETE on your cylinder data, which includes delivery charges, stock, and cylinder types. Here's how you can set up and demonstrate an AUTHORITY-CHECK based on the cylinder batch ID:

Steps:

Create authorization object class in SU21

2.Save it

3.Crate the authorization field

4.Select the operation you want to do on DB

5.Select the activity and save it

Scenario – in the report we have stock table and particular user can delete update insert Once we are done with auth object—basis person will create a role using t code pfcg

If we goto to the t code SU01 – AND CLICK ON role we can be able to see the assigned roles

Authorization filed and value will be assigned by BASIS and will reflect here

After assigning role

code :

REPORT zpd_rp_auth_chek. 
 
TYPES : BEGIN OF lty_BID, 
          cylinder_batch_id TYPE zpd_de_batch_id, 
        END OF lty_BID. 
 
DATA : lwa_data TYPE zpd_t_stock. 
DATA : zpd_de_batch_id TYPE TABLE OF lty_BID. 
DATA : lwa_bid TYPE  lty_BID. 
DATA : lt_bid TYPE  TABLE OF lty_bid. 
 
 
TYPES : BEGIN OF lty_display, 
          delivery_charge TYPE zpd_de_charge, 
          cylinder_type   TYPE zpd_de_cylinder_type, 
          stock           TYPE zpd_de_stock, 
        END OF lty_display. 
 
DATA : lwa_display TYPE lty_display. 
DATA : lv_objectid TYPE cdhdr-objectid. 
*DATA : lwa_bid TYPE zpd_t_stock. 
 
 
 
PARAMETERS : p_id TYPE zpd_de_batch_id OBLIGATORY. 
PARAMETERS : p_charge TYPE  zpd_de_charge  . 
PARAMETERS : p_type TYPE zpd_de_cylinder_type . 
PARAMETERS : p_stock TYPE  zpd_de_stock MODIF ID a3. 
PARAMETERS : p_r1 TYPE c RADIOBUTTON GROUP r1  USER-COMMAND abc . 
PARAMETERS : p_r2 TYPE c RADIOBUTTON GROUP r1 . 
PARAMETERS : p_r3 TYPE c RADIOBUTTON GROUP r1.. 
 
 
 
START-OF-SELECTION. 
 
*Insert 
  IF p_r1 = 'X'. 
 
    AUTHORITY-CHECK OBJECT 'ZAUTHBID' 
ID 'ACTVT' FIELD '01'. 
  ENDIF. 
  IF sy-subrc <> 0 . 
    MESSAGE e005(zmsg_auth). 
 
    lwa_data-cylinder_batch_id =  p_id. 
    lwa_data-delivery_charge =  p_charge. 
    lwa_data-cylinder_type =  p_type. 
    lwa_data-stock =  p_stock. 
 
    INSERT zpd_t_stock FROM lwa_data. 
    IF sy-subrc = 0. 
      WRITE : TEXT-000. 
    ELSE. 
      WRITE : TEXT-001. 
    ENDIF. 
  ENDIF. 
 
 
 
*Delete. 
  IF p_r2 = 'X'. 
    AUTHORITY-CHECK OBJECT 'ZAUTHBID' 
ID 'ACTVT' FIELD '02'. 
  ENDIF. 
  IF sy-subrc <> 0 . 
    MESSAGE e007(zmsg_auth). 
 
 
 
    SELECT SINGLE * FROM zpd_t_stock INTO lwa_data WHERE cylinder_batch_id = p_id. 
    lwa_data-cylinder_batch_id = p_id. 
    DELETE zpd_t_stock FROM lwa_data. 
    IF sy-subrc = 0. 
      WRITE : TEXT-003 , ' :' , p_id. 
    ENDIF. 
  ENDIF. 
 
 
*Update 
  IF p_r3 = 'X'. 
 
    AUTHORITY-CHECK OBJECT 'ZAUTHBID' 
ID 'ACTVT' FIELD '06'. 
  ENDIF. 
  IF sy-subrc <> 0 . 
    MESSAGE e006(zmsg_auth). 
 
 
    lwa_data-cylinder_batch_id = p_id. 
    lwa_data-delivery_charge = p_charge. 
    lwa_data-cylinder_type = p_type. 
    lwa_data-stock = p_stock. 
 
    UPDATE zpd_t_stock FROM lwa_data. 
    IF sy-subrc = 0. 
      WRITE : TEXT-004, ' :' , p_id. 
    ENDIF. 
  ENDIF. 
 
 
 
 
 
AT SELECTION-SCREEN. 
  IF p_r1 = 'X'. 
    SELECT cylinder_batch_id 
    FROM zpd_t_stock 
    INTO TABLE lt_bid 
    WHERE cylinder_batch_id = p_id. 
 
    IF sy-subrc = 0. 
      MESSAGE e003(zmsg_auth) WITH p_id. 
    ENDIF. 
 
  ENDIF. 
 
  IF p_r2 = 'X'. 
 
    SELECT SINGLE cylinder_batch_id 
    FROM zpd_t_stock 
    INTO lwa_bid 
    WHERE cylinder_batch_id = p_id. 
    IF sy-subrc NE 0. 
      MESSAGE e004(zmsg_auth) WITH p_id. 
    ENDIF. 
  ENDIF. 
 
  IF p_r3 = 'X'. 
 
    SELECT SINGLE cylinder_batch_id 
    FROM zpd_t_stock 
    INTO lwa_bid 
    WHERE cylinder_batch_id = p_id. 
    IF sy-subrc NE 0. 
      MESSAGE e004(zmsg_auth) WITH p_id. 
    ELSE. 
      SELECT SINGLE   delivery_charge  stock 
      FROM zpd_t_stock 
      INTO lwa_display 
      WHERE cylinder_batch_id  = p_id. 
    ENDIF. 
  ENDIF. 
 
 
AT SELECTION-SCREEN OUTPUT. 
 
 
 
  LOOP AT SCREEN. 
    IF screen-group1 = 'A1' OR screen-group1 = 'A2'  OR screen-group1 = 'A3' OR screen-group1 = 'A4'. 
      screen-active = 0. 
      MODIFY SCREEN. 
    ENDIF. 
 
  ENDLOOP. 
 
 
  IF p_r3 = 'X'. 
    p_type = lwa_display-cylinder_type. 
    p_charge = lwa_display-delivery_charge. 
    p_stock = lwa_display-stock. 
 
  ENDIF.

Same in case of delete ..

So now lets dicuss about the key parameters present in the authorization

SAP_ALL :

The composite profile SAP_ALL contains all SAP authorizations

It means that a user with this profile can perform all tasks in the SAP system

The user which is having SAP_ALL authorization has the rights to administer the SAP system

In projects, it is recommended to have only one user with SAP_ALL authorizations, rest all users have the authorization based upon their role

Here I have authorization for SAP_ALL means I have sap all system authorization

IN CASE:

Even though I have SAP_ALL authorizations .then why is it not possible to create the records in previous program?

When we created object, we need to add that new object in SAP_ALL

And SAP_ALL has all many predefined authorizations

To add that we need to regenerate SAP_ALL

So once we regenerate it – it will be the part of SAP_ALL

Now if we try to insert a record it will show – sy-subrc will be 0

Now let's see the requirement of assigning authorization for a particular field

Suppose I want to assign auth for a custom field delivery charge – only certain people can see the delivery charges change the delivery charges

I have a custom table of cylinder data

2.Su20 – create field

3.Su21 create auth obj class—and use already existing class

4.Here I'm providing authorization on displaying the details of delivery charges

Code :

TYPES : BEGIN OF lty_display, 
          delivery_charge TYPE zpd_de_charge, 
          cylinder_type   TYPE zpd_de_cylinder_type, 
          stock           TYPE zpd_de_stock, 
        END OF lty_display. 
 
 
DATA : lt_data TYPE TABLE OF lty_display, 
       wa      TYPE lty_display. 
 
PARAMETERS : p_dc TYPE zpd_de_stock. 
 
START-OF-SELECTION. 
  SELECT delivery_charge 
          cylinder_type 
           stock FROM zpd_t_stock 
  INTO TABLE lt_data 
   WHERE delivery_charge = p_dc . 
 
  LOOP AT lt_data INTO wa. 
    WRITE : wa-delivery_charge , wa-cylinder_type , wa-stock . 
 
  ENDLOOP. 
 
  AT SELECTION-SCREEN . 
   AUTHORITY-CHECK OBJECT  'ZDELICHRG' 
   ID 'ACTVT' FIELD '03' 
   ID 'DELIVCHARG' FIELD P_DC. 
   IF SY-SUBRC <> 0. 
     MESSAGE e008(ZMSG_AUTH) WITH p_dc. 
     ENDIF.

5.We can see that we are getting sy-subrc = 12

6.So when we try to display the records with particular delivery charge we get an error

Here are some simple conclusion points:

Secure Data Access: Using AUTHORITY-CHECK ensures that only authorized users can update, delete, or insert cylinder data.

Granular Permissions: Instead of giving broad access (like SAP_ALL), you assign rights for specific fields (like a cylinder batch ID) to limit who can change data.

Role-Based Control: By creating roles in PFCG with precise authorization objects, you control access based on business needs.
Risk Reduction: Fine-grained authorizations help reduce the risk of accidental or unauthorized data changes.
Ongoing Review: Regularly reviewing and updating roles ensures that permissions stay relevant and secure.

Limited Time Activation of virtual Super-User - SAP*

2025-05-20T16:26:58.773000+02:00

SAP Note 3303172

Time-limited client-specific activation of the virtual super-user SAP*, available as of kernel release 790:

Logon to the operating system of an application server using <sid>adm user.
Start the interactive tool dpmon with menu option u to activate the virtual client-specific super-user SAP* in a chosen client. Define a period of between 10 and 30 minutes as validity. You will obtain a one-time password after successful activation.
Logon using user SAP* and the one-time password you have obtained on any currently running application server.

Point to be noted :

Any password based logon attempt for user SAP*, regardless if successful or not, invalidates the one-time password immediately.
You can (re-)activate the user using dpmon any time and will obtain a new one-time password. This is needed for example if you had a typo in your attempt to use the one-time password and could not logon.
Within dpmon you have further the possibility to see in which clients a virtual super-user does currently exist, which one still has a one-time password, their remaining existence and you are able to delete them prematurely.
An existing user SAP* (and an emergency super-user SAP* activated by the second option) is superimposed by an existing virtual super-user SAP* in a client.
A maximum of 20 virtual super-user SAP* can exist in parallel in different clients.
There is no need for an application server restart as no static profile parameter needs to be changed.
The user has no hardcoded known password but gets a new random one-time password after each activation.
The user is activated client-specific.
The user existence is limited in time, its validity is chosen during its activation within dpmon(the allowed period is between 10 and 30 minutes), and the user can also be deleted within dpmon already before its expiration. Bear in mind: a user deletion has no influence on an already established session. A session does continue to run.
Both activation and usage of the virtual super-user are logged in the security audit log event EUP (purpose 2).

Security Audit Log for virtual user SAP*

Strengthening SAP Security: A Closer Look at Authorizations and Access Control

2025-05-22T13:35:36.332000+02:00

As promised in my previous post , it's time to explore the different domains of the SAP Secure Operations Map (SOM). This series aims to highlight key areas that deserve attention and showcase tools and services that can support your company on its journey toward a more secure SAP environment.

We'll begin with a topic that most professionals associate as the cornerstone of SAP security: Authorizations and Access Control.

The cornerstone of SAP Security: Authorizations and Access Control

The Challenge: Keeping Authorization Concepts Current

One of the biggest pain points in this domain is that authorization concepts often become outdated almost immediately after implementation. You may have defined a comprehensive concept at a certain point in time, but if your access control processes are not actively maintained and updated, that concept quickly loses its relevance.

This issue is especially prevalent in ERP systems, which offer a vast range of highly specific authorization options. While SaaS applications may be less complex in this regard, challenges still arise—particularly when defining business roles that span multiple systems. Consider a purchaser who uses S/4HANA for procurement, SAP Ariba for supplier collaboration, and SAP Analytics Cloud for reporting. Understanding and managing the authorization requirements across such a landscape is far from straightforward.

Risks and Red Flags

Proper access control isn't just about functionality—it’s about minimizing risk. For example:

Critical Authorizations: Users should not have direct access to sensitive system elements such as table contents unless absolutely necessary.
Segregation of Duties (SoD): A single user should not have the ability to execute multiple critical steps in a process. For instance, allowing a purchaser to both create purchase orders and maintain vendor master data could open the door to fraud.

Where to Begin? Start with Your Access Control Processes!

To build a resilient access control framework, begin by asking key questions about your current processes:

How are access control tasks handled today?
Are access risk definitions actively managed?
How are roles assigned—manually or through tools?
Are authorizations maintained regularly?
Are there ongoing checks for SoD (segregation of duties) conflicts?
Do users only retain appropriate authorizations when their roles or positions change?
How are privileged operations (e.g., "firefighter access") managed?

Once you’ve answered these questions and established clear processes, you can explore opportunities for optimization—such as automation or dedicated tools like SAP Access Control and SAP Identity Access Governance (IAG).

Begin by asking key questions about your current access control processes

Role Optimization and Reducing Privilege Creep

As part of your access control maturity, role optimization is a logical next step. If your processes haven’t been streamlined in the past, it’s likely that "privilege creep"—the gradual accumulation of excessive authorizations—has taken hold.

One powerful tool based service to support role optimization is AIRC ("Automated Implementation of Role Concept"). AIRC generates role proposals based on actual system usage, helping you accelerate the development of a new role concept. With AIRC, time to value can be as short as three months. For more details, take a look at this informative blog post by Markus: Optimizing Your SAP S/4HANA Landscape with a Best Practice Role Concept

AIRC can also support your SAP BTP authorization journey. Learn more about that here: Authorizations for SAP Business Technology Platform – A Quick Start

Need Support?

If you need help setting up or optimizing your access control processes, we’re here to support you.

Next up, for the next post in this series, where I’ll take a deeper look at SAP Access Control and SAP IAG—and how they can be effectively leveraged across a hybrid SAP landscape.

Authorization group

2025-05-28T13:34:19.131000+02:00

How They Work

When a user attempts to access an SAP object, the system checks two things:

1️⃣Whether the user has the necessary authorization (through roles and profiles)
2️⃣Whether the user is authorized for the specific authorization group assigned to that object

If an object belongs to an authorization group that the user cannot access, the system will deny access even if the user has other relevant permissions.

Common Use Cases

Table Protection: Database tables containing sensitive information (like payroll data, financial records, or personal information) are assigned to specific authorization groups. Only users with appropriate clearance can access these tables through transactions like SE16 or development tools.

Program Security: Custom programs or reports can be assigned authorization groups to ensure only designated users can execute them, particularly useful for programs that manipulate critical business data.

Configuration and Assignment

Authorization groups are typically defined in customization tables and then assigned to objects through various methods depending on the object type. Users are granted access to authorization groups through their roles, which contain authorization objects (like S_TABU_DIS for table access) that specify which authorization groups they can access.

Demo

Create new authorization group in the SM30, view name V_TPGP.

Add this group to the program (see explanation above). Now if the user without appropriate clearance try to execute the report the error message will be appears.

Add the group to the related field of the object.

The role should be assigned to the user.

Now the program can be executed

Minimizing SAP License Costs by optimizing SAP Authorizations with MOON Services

2025-10-06T09:34:30.495000+02:00

“MOON – Minimize Overhead, Optimize Need”

Efficient authorization management is crucial within the SAP environment for optimizing license costs. MOON Services aim to reduce authorizations to their necessary minimum, ensuring that what SAP users utilize is licensed, while optimizing unused authorizations. Let's explore the three essential MOON services: "MOON License Simulation", "MOON License Quickfix" and "MOON License Service powered by AIRC", each designed to enhance license management.

MOON License Simulation

MOON License Simulation focuses on precisely defining user license types in the SAP S/4HANA system through tailored authorizations to their essential minimum. This service enables companies to manage licenses efficiently and significantly reduce unnecessary costs.

Through simulation, customers can identify potential license cost optimizations when engaging in an authorization redesign with SAP Consulting. The service includes downloading usage data and calculating license costs for a new S/4HANA authorization concept against the requirements of the current STAR Service framework. Customers gain insight into possible license cost optimizations that can be achieved after an authorization redesign.

MOON License Quickfix

The MOON License Quickfix service offers rapid modifications to existing authorization structures, ensuring efficiency in license categorization. By analyzing current authorizations and making immediate role adjustments, companies can implement instant cost-saving measures.

This service focuses on reducing effort by minimizing authorization values and adapting authorization objects. By achieving quick wins in license type optimization, companies can significantly save costs while maintaining operational efficiency.

MOON License Service powered by AIRC

MOON License Service powered by AIRC (Automated Implementation of Role Concept) elevates license cost minimization to a new level, employing advanced automation and SAP Best Practices to refine authorizations. This service is designed to decrease effort and duration in managing roles and authorizations, enabling seamless cost management.

Driven by SAP AI Core automation, MOON AIRC precisely tailors authorizations to the necessary minimum, achieving substantial cost reductions and enhanced security. The service includes scoping, functional and organizational role definitions, and strategic role assignments—all aimed at minimizing license costs. Synchronization capabilities from SAP Signavio ensure a coherent approach to authorization management. In addition to optimizing license costs, this service delivers a high-quality, secure SAP Best Practice authorization concept.

Conclusion

The MOON services are at the forefront of license cost optimization, enabling companies to efficiently reduce authorizations to their necessary minimum. By focusing on precise authorization adjustments and employing automation, MOON Services empower organizations to achieve operational efficiency and substantial cost savings. Harness the potential of MOON Services and navigate your path to optimized license management and reduced overhead.

For more information about the offering send a mail to: security.consulting@sap.com

How to Check Fiori Apps Related Authorization Object Mass

2025-10-07T10:51:37.890000+02:00

Introduction

In SAP implementations, understanding the underlying authorization objects associated with each app is crucial for secure and compliant access management. However, manually identifying these objects for multiple apps can be time-consuming and error-prone. This article presents a structured approach to mass-check authorization objects related to Fiori apps using backend SAP tables and metadata.

Objective

To extract and analyze the authorization objects linked to multiple Fiori apps by leveraging the relationship between Fiori App IDs, OData services, and SAP authorization tables.

Step-by-Step Process

1. Extract Fiori App ID – OData Service Mapping

Start by retrieving the mapping between Fiori App IDs and their corresponding OData services. This can be done using the SAP Fiori Apps Library or via internal documentation if available.

Each Fiori app typically has one or more OData services that it consumes. This mapping is essential for tracing the backend logic and authorization.

2. Match OData Services with Authorization Hashes (Table: `USOBHASH`)

Once you have the list of OData services, use the USOBHASH table to find the corresponding hash values. These hash values represent the technical linkage between services and their authorization metadata.

Key Fields:
- PGMID (usually 'R3TR')
- OBJECT (e.g., 'IWSG' for OData services)
- OBJ_NAME (OData service name)
- HASH (authorization hash)

This step helps you identify which hash is associated with each OData service.

3. Retrieve Authorization Objects via Hash (Table: `USOBTC`)

Using the hash values obtained from USOBHASH, query the USOBTC table to extract the actual authorization objects.

Key Fields:
- HASH
- AUTH_OBJ (e.g., S_SERVICE, S_RFC, etc.)

This table provides the list of authorization objects that are checked when the corresponding OData service is executed.

Example Workflow

Let’s say you want to analyze the authorization objects for a set of Fiori apps used in the Procurement module:

Extract App IDs and OData services from the Fiori Apps Library.
Query USOBHASH to get the hash values for each OData service.
Use those hash values to query USOBTC and retrieve the related authorization objects.
Compile the results into a report (e.g., Excel or JSON) for further analysis or role design.

Note: Some Fiori applications do not have an odata service. Therefore, those with a transaction code are already found in USOBTC as transaction codes. For others, e.g., webdynpro applications, I couldn't find a quick method. I added the catalog to the role, got the hash code, and manually placed it in an Excel file. Only 5 out of 300 Fiori applications worked this way.

Conclusion

By leveraging the relationship between Fiori App IDs, OData services, and SAP authorization tables (USOBHASH, USOBTC), consultants and security teams can efficiently perform mass analysis of authorization objects. This method supports better role design, compliance audits, and secure Fiori app deployments.

New access risks, new SoD matrix: How S/4HANA changes the approach to Segregation of Duties (SoD)

2025-12-30T05:39:35.532000+01:00

Introduction – can the SoD matrix from SAP ECC be simply copy&paste to S/4HANA?

Migrating authorizations from SAP ECC to SAP S/4HANA is not just a technical upgrade — it’s a moment when many organizations, often for the first time in recent years, take a holistic look at their access design. S/4HANA introduces a wide range of new business functionalities, which significantly impact the existing Segregation of Duties (SoD) matrix originally built for ECC.

Business layer

The way business processes operate in S/4HANA has changed significantly - new flexible approval workflows have been introduced (for purchase requisitions, purchase orders, and invoices), along with the centralized Business Partner model, extended budget control mechanisms, automated accounting based on the Universal Journal, and new cloud and cross-module integrations (FI–MM–CO–SD). Users now have broader decision-making and configuration capabilities directly within Fiori applications: such as managing approval rules, reassigning cost center (MPK) ownership, or creating ad-hoc reports using Embedded Analytics. All of this means that the business layer of the SoD matrix must be updated: some SAP ECC risks have lost relevance, while new S/4HANA ones have emerged, resulting from greater process flexibility.

Technical layer

There is also a technical layer of change, it focus on how SoD matrix business activities are technically defined (transactions, Fiori applications, OData services and authorization objects) in the SoD matrix. The way users interact with the system has evolved: instead of executing transactions in SAP GUI, they now operate through the Fiori Launchpad (tiles/intents), while access to data and operations is handled via OData services (controlled by objects such as S_SERVICE), Spaces/Pages, Launchpad catalogs, and classical backend authorization objects. Access that once relied on a single T-code is now the result of multiple layers working together (frontend: Fiori & OData and backend: tcodes and authorization objects). This means that an SoD risk can now materialize not just at the transaction level but also within an app or service — and therefore must be defined that way in the segregation of duties matrix. This new authorization architecture contribute to the fact that the traditional approach to SAP ECC access control is no longer sufficient.

The SoD matrix

At the center of every access redesign lies something many organizations tend to overlook — the Segregation of Duties (SoD) matrix. It defines access risks and identifies potential threats arising from excessive or conflicting authorizations. It establishes the level of risk for typical business scenarios in which users operate within the S/4HANA system. For example, the matrix describes risks that occur when a user can change a supplier’s bank account and subsequently post a fictitious liability in an invoice document, or when they can receive goods into inventory that never physically arrived — thereby triggering a payment process for non-existent items. In other words, the SoD matrix defines which activities in the system can be performed together and which must remain separated to protect business processes and data from errors or fraud.

In short, the SoD matrix is a structured set of risks and sensitive activities that should be analyzed, monitored, and incorporated into access management processes to ensure the security and integrity of both business operations and the underlying data.

It’s also a key focus area for financial auditors, since one of the fundamental control mechanisms for preventing misuse is a properly designed authorization model. Yet many organizations make the same common mistake: they build roles based on the principle of “who needs what,” only later asking whether that person should have such access in the first place.

GRC Hack #1: Don’t design or build roles without SoD matrix

Before you start designing authorizations, perform a business process risk analysis and use it to create your SoD matrix as this will serve as the foundation for all role design activities.
Anyone doing it the other way around makes a conceptual error that will eventually surface during an audit. Including a dedicated authorization workstream and engaging experts who understand business process risks is a crucial, yet often overlooked as a part of any S/4HANA implementation project. Remember, the SoD matrix is a conceptual deliverable is a single document that consolidates all key principles related to security, segregation of duties, and access management.

With the transition to S/4HANA, this map must be redrawn from scratch: names, logic, and process execution methods have all changed and with them, the sources of access risk.

How to Redesign the SoD Matrix in S/4HANA

Changes to the SoD matrix in S/4HANA occur across two dimensions: the business dimension and the technical dimension. The technical dimension is usually more challenging as it requires significantly more work, and without adapting it properly, SoD analysis and reports will produce completely inaccurate results. Let’s start with the technical perspective.

a)Technical Dimension

In the SAP ECC system, authorizations were primarily based on transaction codes (T-codes) and corresponding authorization objects. SoD analysis therefore focused on verifying whether a user or role combined, within their authorizations, two conflicting transactions (together with the necessary authorization objects) that should not be executed by the same person in a given business process that could generate access risk for the organization. In SAP S/4HANA, this logic still applies, but the way users interact with the system has changed fundamentally. This shift has a major impact on how the SoD matrix must be defined and structured for S/4HANA.

b)From Transactions to Fiori Applications

Users no longer enter transaction codes in SAP GUI. Instead, they work within the Fiori Launchpad, where they access applications assigned to their roles. Each application is linked to an Intent, as a combination of a semantic object and an action, which in turn calls a specific OData service in the backend. Data is exchanged via HTTP in JSON (Odata v2, XML, V4) format and is subject to additional authorization checks. This means that user access now depends on the interaction of several components:

the Fiori application,
an active OData service,
the assigned Launchpad catalog and Space/Page (despite missing page app can be available), and
the backend authorization objects.

Missing any of these elements results in an access error, typically a 403 Forbidden or No data found message. From an SoD perspective, this means that access risks can now arise not only at the transaction level, but also at the level of Fiori applications and OData services and therefore must be represented accordingly in the SoD matrix.

GRC Hack #2: Expand the Matrix to Include Fiori Applications

If you don’t add Fiori applications to your SoD matrix, your analysis will be incomplete as reports may both miss real user access risks as well as generate false positives. It’s important to understand that Fiori applications in S/4HANA are not all the same. They fall into two main categories:

New Fiori applications (transactional, analytical, or factsheet apps) – completely rewritten using SAPUI5 technology, communicating with the backend via OData services.
These are the ones that most often introduce new functions and risks, e.g.: Manage Purchase Orders (F0842A), Post General Journal Entries (F0718), or Manage Supplier Invoices (F0859).
Classic Fiori applications (GUI transactions in Fiori) – a modern UI wrapper for traditional SAP GUI transactions. In practice, these launch traditional T-codes (e.g. ME21N, FB60, VA01) directly from a Fiori tile. They still rely on classic authorization objects, but are accessed through the Fiori Launchpad.

Each application requires its own technical mapping sometimes identifying the relevant OData service and S_SERVICE authorization object and sometimes mapping it back to a traditional GUI transaction. In both cases, the same backend authorization objects from SAP ECC still apply, as they ultimately determine whether the user can perform a given operation in backend system.

Every Fiori app in S/4HANA is linked to an intent, a combination of two elements:

Semantic Object – describes what the action relates to (e.g. PurchaseOrder, SupplierInvoice, SalesOrder).
Action – describes what the user does (e.g. manage, create, display).

The full list of Fiori applications, including their corresponding OData services, backend objects, and system versions, can be found in the SAP Fiori Apps Reference Library – an essential source for anyone updating their SoD matrix for S/4HANA. https://fioriappslibrary.hana.ondemand.com/

This library contains hundreds in practice, thousands Fiori apps for S/4HANA.

Many standard SoD matrices provided by SAP or vendors include only about 200 Fiori applications, which is just a fraction of the real scope.
Conclusion: every Fiori app can represent a potential SoD risk so verifying and expanding the matrix is essential.

c) Fiori applications and OData services

In the S/4HANA model, access to business data and processes occurs on the frontend via dedicated OData services (Open Data Protocol) the integration layer through which Fiori applications communicate with the SAP backend, retrieving and writing data in real time. An OData service definition is registered in the S/4HANA system on the Frontend Gateway and includes, for example:

the technical service name (e.g. MM_PUR_PO_MAINT_V2_SRV),
the URL path (e.g. /sap/opu/odata/sap/MM_PUR_PO_MAINT_V2_SRV/),
mapping to a backend ABAP component,
authorization control via the S_SERVICE object.

Example mappings:

Manage Purchase Orders (V2) (F0842A) MM_PUR_PO_MAINT_V2_SRV – Purchasing (MM)
Create Supplier Invoice (F0859) MM_SUPPLIER_INVOICE_MANAGE – Accounts Payable
Post General Journal Entries (F0718) FAC_FINANCIALS_POSTING_SRV – General Ledger (FI)
Manage Bank Statements (F1564) FAR_MANAGE_BS_SRV – Banking (FI)
Manage Sales Orders (F1873) SD_F1873_SO_WL_SRV – Sales Orders (SD)

Each of these OData services must be activated in transaction /IWFND/MAINT_SERVICE and granted to users via S_SERVICE authorization before the Fiori app can read or write data to the backend. This is a major shift, because OData access is not tied to T-codes. It requires dedicated S_SERVICE authorization, and such access may not appear in classical role-based analyses based solely on transaction codes. Therefore, the SoD matrix must explicitly include OData services, Fiori applications, and related backend objects.

GRC Hack #3: Include OData and Fiori in the SoD matrix

A user might have access to the classic GUI transaction MIRO (invoice posting) with the required authorization objects, but lack access to the Fiori app “Create Incoming Invoice”, which uses the MM_SUPPLIER_INVOICE_MANAGE service to post invoices in the backend via Fiori. In a traditional SoD analysis, this would be reported as a potential risk, because the GRC system detects authorization for invoice posting. However, in organizations that operate exclusively through the Fiori interface and no longer use SAP GUI, the user would not be able to perform the transaction via browser access, even though the authorizations technically exist. This is a classic false positive, where a GRC system reports a risk that is not executable in practice. Such cases illustrate why SoD analysis must combine authorization logic with an understanding of how users actually work within the modern Fiori interface. Otherwise, SoD reports can become overloaded with irrelevant alerts leading to business and risks owners frustration.

GRC Hack #4: Don’t forget about OData service

OData services form a new access layer for business processes their authorization operates independently from classic transaction-level checks in the backend. If you fail to include them in your SoD matrix, a user may have real operational access to perform actions that your GRC system will never flag as risky. In S/4HANA, a typical role can include:

classic SAP GUI transactions,
Fiori applications,
OData services, and authorization objects.

As a result, the SoD matrix must now evaluate whether a role combines functions that should remain segregated in the new model. It is equally important to include custom transactions and customer-specific extensions as the standard out of the box vendor SAP matrix does not cover them.

GRC Hack #6: Technical definition must include custom extensions
Don’t rely on the standard transaction list. Add to your matrix:

all custom Fiori applications used in your organization,
the OData services those applications call,
and every custom app, T-code, or service built for your specific system.

Only then will your SoD matrix will better reflect the real S/4HANA environment.

Business Dimension

If your organization has implemented custom Fiori apps, OData services, or modified backend logic, they must be manually added to the SoD matrix definition. The out-of-the-box matrix won’t be good enough and in these areas, you’ll have blind spots. With the transition to SAP S/4HANA, not only the technical structure of roles and authorizations changes, but also the very way business processes are executed in the system. This means the SoD matrix must now include new risks that simply did not exist in the old ECC world. One of the best examples involves approval workflows for purchase requisitions, purchase orders, and supplier invoices processes that, in S/4HANA, are configured through new Fiori applications such as Manage Workflow for Purchase Requisition and Manage Purchase Order Workflows. Each of these applications allows users to define approval paths (approvers), under what financial thresholds, and in which order. They can modify conditions that trigger the workflow or even rearrange the approval hierarchy. This is a powerful automation feature, but also a new source of risk for critical access (restricted access) and Segregation of duties (SoD) violations. If a user simultaneously has access to workflow configuration, purchase order processing, and the ability to edit cost center (MPK) or WBS master data, they could, for example:

remove a budget approval step in WF config and trigger the procurement process,
change the approver (e.g., assign themselves as owner) in cost center or WBS master data,
modify approval thresholds or limit values effectively bypassing budget control and the SoD principle.

GRC Hack #7: Analyze new functionality for new SoD risks

Add a new activity to your SoD matrix: “Manage Workflow Configuration” (for requisitions, purchase orders, and invoices). While these authorizations do not directly post accounting entries, they can indirectly bypass procurement access controls mechanisms. User can change the procurement design approval logic. Monitor who has access to Fiori apps like Manage Workflows for Centrally Managed Purchase Requisitions and related backend services such as SWF_FLEX_DEF_SRV, which handle the workflow logic. It’s also important to add new SoD conflicts to the matrix. A good example is when a user can modify Cost Center (MPK) or WBS element master data, assigning ownership to themselves and then approve a purchase requisition for that same object. This is a real risk in S/4HANA that did not exist in ECC, because the approval of requisitions and purchase orders was previously controlled by dedicated authorization objects and the Release strategy mechanism.

In ECC, approval control for purchase requisitions (PR) and purchase orders (PO) was handled by the classic Release Strategy model, based on authorization objects such as M_EINK_FRG.
Fields of this object included FRGGR (release group) and FRGCO (release code), which determined who could approve which purchasing documents and at what level. Authorizations were tightly linked to document type, purchasing group, and release level the entire process was static and fully embedded within the transactional system.

As a result, SoD control was relatively simple: it was enough to ensure that a user could not both create and approve a requisition or order under the same release group. Everything was based on authorization objects and could be easily represented in the SoD matrix or analyzed by GRC tools.

In S/4HANA, this model has been simplified, but new business risks have emerged.
Approval processes are now driven not by static authorization objects but by flexible workflows, MPK/WBS ownership assignments, and configuration rules that can be changed from within Fiori apps.

New business SoD risk example in S/4HANA

A user has authorization to change Cost Center (MPK) or WBS master data (e.g., assign a cost owner) and the ability to approve a purchase requisition for that same object. As a result, the same person can give themselves control over a cost center or project and then approve related purchases, violating the Segregation of Duties principle, bypassing budget control, and creating the potential for fraud or misstatement.

New SoD risks aspects in S/4HANA

Business risks – new processes and functions (e.g., approval workflows, business partners, flexible budgets) reshape SoD exposure.
Configuration risks – users can modify workflow parameters, approval rules, thresholds, or budget role assignments.
Automation risks – result from background workflows or schedulers performing actions without human confirmation.
Integration risks – arise from API and OData-based integrations that link processes across modules (e.g., FI ↔ MM ↔ CO).

In the classic ECC environment, there was no concept of a user “programming” approval logic that could violate internal control policies. In S/4HANA, thanks to Fiori this is now a real, browser-based possibility. Therefore, the modern SoD matrix must include not only traditional actions such as Post, Change, and Approve, but also Manage Workflow, Configure Approval Process, and Change Budget Control Settings because today, risks often occur where the process is configured, not just where it is executed.

GRC Hack #8: New risks are where you configure the process not just where you execute it

In the S/4HANA environment, the line between a business user and a process configurator is becoming increasingly blurred. A person with authorization to manage workflows can, in practice, change how documents are approved — even if they formally lack posting rights. Including such roles in the SoD matrix is now a mandatory step for any organization that wants to maintain control over its procurement and approval processes in S/4HANA.

Business activity	T-Code	Fiori	Intent	OData	Authorization object	Operation type
Create Purchase Order	ME21N	F0842A	PurchaseOrder-manage	MM_PUR_PO_MAINT_V2_SRV	M_BEST_EKG, M_BEST_BSA, M_BEST_WRK, M_BEST_EKO, S_SERVICE	manage
Invoice posting	MIRO	F0859	SupplierInvoice-create	MM_SUPPLIER_INVOICE_MANAGE	F_BKPF_BUK, M_RECH_WRK, S_SERVICE	Create, change process
Sales order	VA01	F1873	SalesOrder-manage	SD_F1873_SO_WL_SRV	V_VBAK_AAT, V_VBAK_VKO, S_SERVICE	Manage

Tools Supporting the SoD Matrix and Access Verification Process

Building an SoD matrix is only half of the success. The other half is ensuring that its content is taking into account when access management process are executed. Another aspect is that it is regularly updated, and monitored as part of daily user to role provisioning and access review processes. This is where GRC-class tools come in — not only analyzing the SoD matrix and conflicts, but also storing knowledge about risks, linking them with business processes, and supporting audit readiness and compliance reporting.

SAP GRC Access Control 12.0 and the upcoming SAP GRC 2026

This is SAP’s flagship access governance solution and in 2026 it will be succeeded by SAP GRC 2026. It enables centralized role management, SoD conflict analysis, automated risk prevention, and end-to-end control over access request and removal workflows. With its Risk Library repository, GRC Access Control allows you to link business processes with transactions and authorization objects, including Fiori applications and OData services in newer releases. It’s an enterprise-grade solution, ideal for large organizations with complex system landscapes, multiple SAP environments, and strong audit requirements.

GRC Hack #8: If your organization plans to upgrade, ensure you migrate your risk repository and all custom extensions to the new version.

SAP IAG (Identity Access Governance)

SAP IAG is the cloud evolution of GRC that delivers the same SoD analysis capabilities, enhanced with identity management and cloud integration (e.g. SuccessFactors, Ariba, Concur). It supports real-time access analysis, automatic role recommendations (auto-proposals), and browser-based Access Request Workflow handling. In hybrid S/4HANA migration projects, IAG is increasingly becoming the central platform for access risk management.

smartGRC – a lightweight alternative and practical complement

smartGRC was designed to meet the need for simpler and more flexible access risk management. It provides a unified place to maintain the SoD matrix, analyze conflicts, manage periodic access reviews, and integrate directly with business processes. Unlike classical GRC, smartGRC can operate as both a complement to SAP tools or a standalone audit platform, particularly valuable for mid-sized organizations and multi- SAP and non- SAP centric system environments. The tool allows easy extension of the SoD matrix with custom Fiori apps, OData services, and non-SAP business applications — extracting authorization data and storing it in a universal XML format, making it possible to audit systems outside the SAP ecosystem. It is equipped with updated segregation of duties matrix risks functions definitions for the newest S/4 Hana system release. smartGRC supports import/export of the SoD matrix (CSV/XML) for non-SAP system, enabling easy synchronization with ITSM or JIRA supporting system.

Why these tools matter

While SAP GRC and IAG provide enterprise-grade control, smartGRC’s advantage lies in speed, adaptability, and cross-system risk analysis making it ideal where agility matters more than standardization. Tools enable organizations to:

store the SoD matrix in a centralized, structured repository linking processes, transactions, apps, and services,
perform preventive SoD risk analysis during role provisioning (“what-if” simulation before access approval),
conduct periodic or ad-hoc SoD access reviews in production systems,
integrate SoD analysis with change and approval workflows,
generate audit-ready compliance reports.

From my project experience, the standard SAP SoD matrix for S/4 Hana is only a starting point as it usually includes around 200 Fiori apps, while best in class, process-driven Sod matrices contain up to twice as many. That’s why it’s essential to extend and update your matrix regularly with custom and standard Fiori apps, OData services, and project-specific enhancements.

GRC Hack #9: Treat SoD matrix like a living system

An SoD matrix that isn’t updated after every system change quickly loses its control value. Establish a cyclical review process, ideally aligned with your development and change management process cycle, to ensure that every new app, workflow, or extension is captured, analyzed and included if needed in SoD matrix

Summary

In the S/4HANA world, a current and well-defined SoD matrix is the foundation of security, compliance, and access management process efficiency. It’s not a static document, rather it’s a dynamic control mechanism that must evolve together with the system and the organization.

Recommendations for Authorization, GRC, and Security Teams

Refresh your SoD matrix before migrating to S/4HANA, don’t simply copy the old ECC version; many transactions are obsolete, and key functions have moved to Fiori and OData.
Cover all authorization layers as Fiori apps, OData services, roles, authorization objects, and master data (e.g. MPK/WBS ownership).
Retain classic authorization objects since objects like M_RECH_WRK still play a vital control role and must remain part of the SoD model.
Integrate your GRC/IAG/smartGRC tool into the access request process as automated SoD analysis at request time prevents risk before it happens.
Implement a recurring verification cycle: Matrix → Roles → Users → Access → Audit Report the best practice and audit requirement.
Document every update and every role, app, or workflow change must be reflected in the matrix. The standard SAP list is now just a small fraction of your real risk landscape in S/4HANA.

Closing Thought

Your SoD matrix can become your strongest asset in the security and authorization area migration to S/4HANA, if it’s designed well, your business processes will run smoothly, risks will remain under control, and auditors will stay calm. Properly managed authorizations stop being a source of problems, they become a protective mechanism that safeguards both data and business integrity.

Filip Nowak, Partner

GRC Advisory