SAP trust center

As company you are relying on SAP to provide support and services. But how do you know if SAP is doing a good job on this part?

If an internal auditor or external auditor asks you to show or explain the elements of SAP delivered support, where do you get the information?

SAP trust center

SAP has a good site to start with this information: the SAP trust center.

Here you can find:

  • Security policies
  • Security frameworks
  • List of sub-processors employed by SAP to provide services (sub-processor can be on infrastructure level like AWS, Azure, etc, but also manpower like Accenture, TCS, etc.)
  • Compliance documents like SOC1, SOC2, ISO 27001, ISO 9001, etc reports (or go directly to the compliance finder)

Not all reports are public. For some you must be customer of the product or service. Some parts require acknowledgement of non-disclosure agreement before you can get the report.

Security white paper

Another good document is the SAP security white paper.

STDDAT: consistency check for generic table access authorization group

Tables are protected for data access by the S_TABU_DIS object. An important input here is the authorization group. The relationship between tables and authorization group is stored in table TDDAT. STDDAT has functions to mass maintain and check the authorization group to table relationships.

Questions that will be answered in this blog are:

  • How do I find and remove inconsistent entries in TDDAT table?
  • How do I find dangerous items in TDDAT table?

Consistency check

When you start transaction STDDAT, hit the button Consistency in the first screen:

Wait for the results:

Select the entries and delete with or without transport.

Finding dangerous entries in TDDAT

In the Authorisation group there are two types of entries to check:

  • Space: what will happen?? Vague!
  • &NC&: everybody can access

Select these on the first screen as input for field Authorization Group and press execute:

Select the entries you want to change and press the Assign button:

Save the result in transport.

OSS notes

For versions 7.40 and 7.50 you need to apply OSS note 2577419 – STDDAT | consistency check for table TDDAT to get the consistency check button.

Generic FAQ on table access: 1434284 – FAQ | Authorization concept for generic table access.

SE16N emergency edit mode

For emergency cases you might need to edit table data directly. This blog will describe the emergency edit mode of SE16N.

Questions that will be answered are:

  • How to get the SE16N emergency edit mode?
  • How to enable the SE16N emergency edit mode?
  • How to use the SE16N emergency edit mode?

Getting the SE16N emergency edit mode

The SE16N emergency edit mode is standard installed as of S4HANA 2020. For older versions, you need to apply OSS note 2911103 – SE16N: Alternative edit mode.

Enabling SE16N emergency mode

The SE16N emergency mode is started via transaction SE16N_EMERGENCY. This transaction is locked by default:

Please consult your security team before unlocking this powerful transaction.

Use transaction SM01_CUS to unlock the SE16N_EMERGENCY transaction. Read this blog on the use of SM01_CUS.

Use of the SE16N emergency mode

Use of the emergency mode is pretty simple. Start transaction SE16N_EMERGENCY enter the table and you are launched into edit mode immediately. Example is here for table T001:

Other ways

For more different ways of direct table hacking, read this blog.

Bug fix OSS notes

Bug fix note:

SAP password hash hacking Part V: optimizing the attack speed

This blog series will explain the process of hacking SAP password hashes: also know as SAP password hacking. The process of hacking will be explained and appropriate countermeasures will be explained.

In this fifth blog we will focus on optimizing the speed of attack. The preventive measures will focus on reducing the attack speed.

For the first blog on attacking the SAP BCODE hash click here.

For the second blog on attacking the SAP PASSCODE has click here.

For the third blog on attacking the SAP PWDSALTEDHASH has click here.

For the fourth blog on advanced topics, like the rule based attack, click here.

Questions that will be answered in this blog are:

  • How to optimize the attack speed?
  • How to optimize getting hashes converted into real passwords?

Optimizing the attack

First check if you can get hold of PASSCODE or preferably BCODE hashes. These ones are 10 to 20 times faster to hack than PWDSALTEDHASH codes.

Assuming the administrators have done their work and only PWDSALTEDHASH remains, there are still options to speed up the attack.

Get faster graphical card(s)

Don’t do password hacking on a laptop. The graphical card in any laptop is simply too slow. Use a gaming specification graphical card or cards (cost range is about 300 to 500 dollar or Euro per card).

Preparation of the attack

First thing to do is to get the password rules. Most common is 1 letter, 1 digit, 1 special and minimum length of 8. But differences occur. If for example minimum length is 10, you can adjust your dictionaries to remove all small words that will not comply.

Check the language: use the webster dictionary for English in all cases, but based on language of the company, you must use German, French, Spanish, Italian, Dutch, etc dictionaries as well.

If possible filter out high potential targets from you list. It is best to have a high value administrator or CEO, then a warehouse person who can do simple movements and write time.

Sequence of attacks

Start first with your library of most frequently used passwords. Maybe there is already a hit.

You will be surprised that about 1% will hit.

Second run is with a list of company, product and department names. If you want to target company called TARGET with product name PRODUCT, make a special file with names like:



Use the password rulebooks to generate as many variations as possible (examples are T@rget2021, Pr0duct2021!).

You will be surprised that about another 1% will hit. Who is using these simple to guess passwords? More people than you think!

Third run should be dictionary run with rulebook. Start with English and primary language of the company. Most successful Rule is word plus digit plus special.

You will be surprised that about another 1 to 3% will hit.

Pending on the speed and sizes the rulebook is a very good one to run for a longer time (consider 1 week constantly running this).

Fourth run should be a keyboard walk rulebook. The keyboard walk contains passwords like QWERtyui1234%^&*, or 1qaz@WSX (walk on keyboard…).

You will be surprised that about another 1% will hit.

Re-using the output file to generate new attack: fingerprint attack

When your first attacks are done, there is one final surprisingly successful last attack possible. For this you take your file with all the passwords you have already cracked.

These passwords you now cut into 2. Example Target2021! is cut into:

T and arget2021!

Ta and rget2021!


Target2021 and !

And the word itself Target2021!

Now you have 2 files. Use these into a combinator attack mode (see hashcat wiki for the exact syntax to use).

This procedure is called a fingerprint attack.

This might give surprising results like TargetProduct2021!

This attack will bring a surprising high number of hits. The better the first passwords you have cracked, the better the result here. Save this attack till last, since it can be a very lengthy one, and a lot of duplication with the previous attacks can happen.

Strengthening password technical strength

The ABAP password can be made more strong by technical means, by increasing the hash salt size. This will take longer time to crack. OSS notes:

SUIM User Information System

SUIM is like a swiss knife for the authorization consultant. It has so many reporting tools it can basically answer any question.

Questions that will be answered in this blog are:

  • What are the most useful tools in SUIM?
  • How can I list users that never logged on to the system?
  • How can I list users that are locked, or have password issues?
  • How can I list users with critical authorizations?


The SUIM tool is started with transaction SUIM:

Here you can select the reports from the different categories.

Most useful SUIM reports

In the subsections below you can find the most useful and most used SUIM reports.

Actual user columns are hidden in the examples below for privacy protection.

User with logon data and password change

Query need: to list when users did logon for the last time and when they last changed their password. This query can be very useful when you have to clean up for the yearly license measurement.

In SUIM select this report:

Start screen:

Example result screen:

Check on users with specific authorization value

One of the most used SUIM reports is to list which users have a specific authorization value:

In this example we will lookup users which have rights for debugging (object S_DEVELOP, value DEBUG):

On the result list you can see all users. Select the user you are interested in and select the button In Accordance with Selection to find out which role has the specifically requested authorization object:

Result can be multiple roles as well:

Remark: there are 3 single roles here which contain the object. The 3 roles are in 1 composite role that is assigned. That is why the number on top shows 1 roles and there are 3 detail lines.

Check on most common critical authorizations

SUIM has a nice check program to check on the most common critical authorizations:

You can select the default SAP variant and use display variant to see the list of checks:

Open the checks to see the details:

The result list can have many potential issues:

You again use the button In Accordance with Selection to find out which role is cause of the potential issue.

Be careful with the reporting of the numbers. A lot of managers cannot deal with the high amount reported. 'It is unbelievable that I have 91.493 critical authorization issues in my system!'. Most of the issues are simple to fix and bring the numbers down dramatically. Or some of the items are not relevant in your situation. Always handle the numbers with care.

OSS notes

SUIM is constantly being improved. There are many small bug fix OSS notes. Don’t be scared off by the length of the list. SUIM is a very large function. So it will have many OSS notes.

Bug fix notes to consider:

Checking RFC security settings

RFC security is a cumbersome job. There are programs to help speed up the security checks for RFC connections.

Questions that will be answered in this blog:

  • How to quickly check all the RFC’s in my system?
  • How to quickly check the trusted RFC’s in my system?

Check RFC connections

Program RSRFCCHK (which also has the same transaction code RSRFCCHK) can quickly scan all your RFC’s. In the selection screen, please make sure to select the 2 extra boxes for “Also check RFC destinations without explicit password” and the “Select destinations without target system too”:

The connection test is optional. But if the RFC is not working, then you might consider it old and no longer needed. In this case you can perform the clean up by deleting the RFC.

The output of the report RSRFCCHK, you can use to look for:

  • RFC’s with personal user ID
  • Cross system layer RFC’s (from production to development, or from development to production)
  • Trusted connections where you don’t expect them
  • Old destinations no longer in use
As a best practice at least yearly check on every system the RFC's that are setup there. Read this blog on how easy it is to use wrongly configured RFC's to hack a system.

Check trusted connections

To check trusted connections run program RS_SECURITY_TRUST_RELATIONS. Output example:

The red lights should be investigated and fixed.

SAP logon user exit hack

In SAP there is a user exit just behind the logon of a user. This can be used correctly, but also used for hacking.

Questions that will be answered in this blog are:

  • How to switch on the user exit after logon?
  • What is good use of the user exit after logon?
  • How to use the user exit for hacking?

Activation of the user exit

In transaction SMOD you can call up user exit SUSR0001:

This exit has only one component:

Double click on the exit to go to the Z code include:

To activate the exit, create a project in CMOD and and include this enhancement. Then double click on the include code ZXUSRU01 to activate the code.

Good use of the user exit

The user exit itself is described in OSS note 37724 – Customer exits in SAP logon. Example of good use it to restrict multiple logons in case you cannot switch on parameter login/disable_multi_gui_login. See OSS note 142724 – Prevention of multiple SAPGUI logons.

The exit is also used a lot by GRC and firefighter type of tools.

The user exit logon hack

In the user exit code, you can put in your own stuff.

As hacking example: copy function module PASSWORDCHECK and the screen that belongs to it to your own ZPASSWORDCHECK.

Modify the screen logic a bit. This is the original code:

Now change the code: the password is always reported back as ok. And the user input you catch in the field password is yours: you can mail it or store it somewhere for you to pick up later.

Put the altered code in the user-exit with logic:

IF SY-UNAME = 'target user name' and not capture before.    
  Store capturing.     
  Set capture flag.

This looks as follows at runtime:

Many end users (and even auditors) will enter their password without thinking twice.

Alternatively you can use function module POPUP_GET_USER_PASSWORD as a basis for your copy: this has also clear text password:

The password field can be stored.

This has the following look and feel:

Detection and protection

It is wise to shield off this user exit from improper use and to yearly check the content of what is inside this user exit.

Central user administration (CUA)

Central user administration (CUA) is a great tool. Despite the fact that SAP has tried to replace it with IDM tools (IDentity Management). CUA remains efficient and reliable.

Questions that will be answered in this blog are:

  • What are use cases for CUA?
  • How to setup CUA?
  • How to monitor CUA?

Use cases for central user administration

Use cases for central user administration:

  • Management of users in the entire landscape (including production servers)
  • Management of users in non-production (sandbox, development, acceptance)
  • Management of users in client 000

Suppose you have a larger landscape consisting of 100 SAP systems and a new basis person will join. Good luck creating 100 user accounts… With CUA connected this is done in one shot.

And every now and then you need to go to client 000. You have forgotten the password, or due to security settings you users is automatically locked there after xx amount of days. With CUA you can simply reset your password there and log on.

Check if you are using to use SAP-GRC access control. This might conflict with CUA.

Set up of central user administration

In the central CUA system (also called CUA master) you need to set up a logical system for each CUA child system. Use transaction BD54 to create them.

Also setup 1 RFC in SM59 to each child system with this naming convention:


Use a non-expiring background user, with the appropriate rights, in this RFC. Make sure you update the whitelist for CUA in the RFC, otherwise you might get RFC callback error. See this blog.

Now start transaction SCUA:

Create a new model view and add the child system:

Do check that the RFC status is fine.

Save and activate the CUA model view:

Check in the master CUA system that the distribution model is created correctly. Start transaction BD64 and look for the CUA model:

Check in WE20 in the master CUA system that the partner profiles are correctly generated towards the child system:

Check that the outbound settings are set to collect the idocs.

If you have a user base up to 1000 users, you could set the idocs to immediately. With larger user bases: set to collect. Reason is that CUA will daily compare the child and master. It will generate 1 idoc per user. This will clog the child system if you do not set to collect. 

Check on the CUA child system that the WE20 partner profiles are also created correctly:

Also here, set the processing to collect in stead of process immediately.

In transaction SCUM you can make a very detailed configuration per field on which fields are globally maintained in the CUA master, and which local:

First synchronisation

After the first setup you need to do an initial synchronisation.

Start transaction SCUG:

First synchronise the Company address. Then synchronise the users. During user synchronisation you will get errors due to user groups. Each user group in the CUA child system needs to be defined in the CUA master system as well.

Transaction SCUL can be used to check the logging:

For text comparison a traffic light shows whether the child system supports it or not. See SAP note 1642106 – CUA|PFCG: Automatic text comparison of roles for central system. This note explains to update table USR_CUST:

For issues remaining with first setup, read OSS note 333441 – CUA: Tips for problem analysis.

Regular batch jobs

In the CUA master system plan the following batch jobs:

  • RSCCUSND (Send user master data to child systems), daily
  • SUSR_ZBV_GET_RECEIVER_PROFILES (text comparison between child and central), daily
  • RSEOUT00 (Send idocs to child systems), every 5 minutes

In the CUA child system plan the following batch jobs:

  • SUSR_ZBV_GET_RECEIVER_PROFILES (text comparison between central and child), daily
  • RBDAPP01 (Process idocs from the master system), every 5 minutes
Due to the jobs, a change in CUA master can take up to 10 minutes to be effective in the child system.

In the central system the next standard jobs are scheduled:


In the child systems the next standard jobs are scheduled:


More background information can be found in OSS note 399271 – CUA: Tips for optimizing ALE distribution performance.

CUA in action

If you goto SU01 in the master system, you see there is an extra tab called systems. And you have to specify the system for each role you assign to a user:

Copying a user can be done for multiple systems.

Also password resets can now be done for multiple systems in one shot.

Emergency cases

There might be emergency cases when CUA master is down or is having maintenance or issues, you might need to temporarily disconnect CUA.

Read OSS note 320449 – Deactivating the CUA temporarily. Run program RSDELCUA in the child system.

Background information

More background information:

SAIS_MONI: Generic audit report about system changes

SAIS_MONI is a central audit report about system changes. It collect changes from client opening, audit log, change log, transport log and more, in one central place.

Questions that will be answered in this blog are:

  • How to install the SAIS_MONI tool?
  • How to run the SAIS_MONI tool?

How to install the SAIS_MONI tool?

The SAIS_MONI tool is installed via OSS note 2423576 – SAIS | Generic audit report about system changes. Or it is standard as of the basis support package stated in this note.

Bug fix notes:

How to run the SAIS_MONI tool?

You start the tool with transaction SAIS_MONI:

Depending on your input the output will be shown as ALV output.

For a full description of each option, read OSS note 2915635 – SAIS | Generic audit report about system changes.

Bug fix OSS notes

Bug fix notes:

SAP interfacing: RFC

SAP has many different ways to interface. The RFC (Remote Function Call) protocol is one of the most wide used.

This blog will explain best practices around secure and correct setup of custom built ABAP RFC function modules.

Questions that will be answered are:

  • How to setup RFC enabled function module?
  • How to setup proper RFC error handling?
  • How to setup security in RFC enabled function module?
  • How strict is the S_RFC authorization handling?
  • Why is SAP_ALL not sufficient for RFC handling?

Creation of test RFC enabled function module

In SE37 you can setup an RFC enabled function module just like a normal function module. First create a function group. Activate that function group in SE80. Now you can create the function module. We will call our test module ZBAPIDEMO:

Important here in the first tab is to set the processing type to Remote-Enabled Module.

For testing we setup import and export tabs:

RFC export tab

Important here with RFC: set the Pass by value tickbox.

For tables use a suitable table type:

And setup the correct exceptions:

Here you can see 2 very important error messages that should always be implemented:

  1. An extra authorization check
  2. An error message when no data is found

Now we can implement the following simple source code:

   DATA: zls_coms_gen_textline TYPE coms_gen_textline.
   IF sy-subrc EQ 0.
     CASE zimport.
       WHEN 1.
         zexport = 'Hello world'.
       WHEN 2.
         zls_coms_gen_textline-entry = 'Hello world table 1'.
         APPEND zls_coms_gen_textline TO ztable.
         zls_coms_gen_textline-entry = 'Hello world table 2'.
         APPEND zls_coms_gen_textline TO ztable.
         RAISE not_found.
     RAISE not_authorized_business.

What is important here in this source code:

  1. The authorization check is implemented and raises an error
  2. If no data is found the NOT_FOUND error is raised

With the SE37 test suite you can test diverse scenario’s now.

Calling RFC function module from another ABAP system

If you call this RFC function module form another ABAP sytem you have to make sure you have set and check the following exceptions:

      not_authorized_business = 1
      not_authorized          = 2
      system_failure          = 3
      communication_failure   = 4
      not_found               = 5
      OTHERS                  = 6.

There are 2 exceptions from the BAPI definition:

  1. NOT_FOUND (nothing found)
  2. NOT_AUTHORIZED_BUSINESS (our own implemented business authorization check)

4 exceptions should be implemented as part of the RFC framework:

  1. NOT_AUTHORIZED: this is the RFC authorization, which will be explained next chapter
  2. SYSTEM_FAILURE: the coding has caused a dump and the system returns and error message (see OSS note 2484377 – Error Message: “RFC Exception SYSTEM_FAILURE Raised; No More Memory Available to Extend an Internal Tab” Upon Executing a Data Extraction Run as an example)
  3. COMMUNICATION_FAILURE: the call to the other system fails. Most likely if you go to SM59 to the RFC destination and perform a connection test you will get a failure.
  4. OTHERS: something else went wrong

The developer should take proper care of these error situations.

Dear ABAP developers: the basis team member are also humans. They will make RFC configuration errors, they rely on the authorization team to assign the correct roles and they rely on infrastructure providers to make sure systems are up and running. Also the basis team will need to perform patching and upgrades to the system, which you as ABAP developer, are calling. So please don't blame the basis team for these exceptions, but please be a good developer and implement proper error handling. If you didn't implement proper error handling, and something went wrong on basis side, that caused your code to go wrong, think twice before putting blame on basis if your code is not handling the situation properly.

For reference: OSS note 1371131 – Correct error handling of RFC calls.

Security of RFC calls

Security of RFC calls is consisting of 2 layers:

  1. The RFC layer
  2. The business application code

You should always implement both layers!

The RFC layer is protected by authorization object S_RFC:

Here you can choose between a function group or even allowing per function module. Personally I would protect by function module. Background: create, change and display BAPI’s will normally be developed inside same function group.

There is a common misunderstanding that if you give SAP_ALL to a (background) user, this would solve the RFC authorization issues. This is not true. SAP_ALL does not contain the S_RFC rights. You have to hand them out separately.

Best practice 1: you might want to start with broad authorizations at the beginning of a development to rule out authorization issues. But you must definitely limit the rights before you make the development go productively live.

Best practice 2: as first statement inside each and every RFC function module, program a relevant business authorization check statement. This is an extra safety measure that is needed to protect important business data from authorization consultants that have handed out * authorizations in object S_RFC (* means all).

More on checking the basis RFC security: read this blog.

Generic S_RFC check handling at basis level

The behavior of the S_RFC check is driven by the settings of RZ11 profile parameter auth/rfc_authorithy_check. Please make sure it has a setting of 6 or higher. Best is 9. A system with 5 or lower can be considered as insecure!

Background OSS note: 2216306 – S_RFC check and profile parameter auth/rfc_authority_check.