Security – Page 3 – Saptechnicalguru.com

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?

SUIM

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.

SUIM_CHDOC_USER

This is new transaction to show user changes. Read more in this blog.

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?

Hacking using RFC connections

RFC callback hacking: read this blog.

RFC jump hacking: read this blog.

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.

OSS notes: 3283474 – Adjustment of authorization for program RSRFCCHK.

Check trusted connections

To check trusted connections run program RS_SECURITY_TRUST_RELATIONS. Output example:

The red lights should be investigated and fixed.

More on setting up trusted RFC’s is written in this blog.

SAP standard on RFC security

OSS note 2008727 – Securing Remote Function Calls (RFC) contains a very extensive PDF explaining all ins and outs on RFC security.

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.

For ITS webgui the calling of the logon user-exit can be skipped with a URL parameter. See OSS note 1465767 – Logon user exit SUSR0001 not called.

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.    
  CALL Z function ZPASSWORDCHECK.    
  Store capturing.     
  Set capture flag.
ENDIF.

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?
Is CUA working is S4HANA?

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:

BAT_CUA_USER_MASTER_DATA
BAT_CUA_SEND_IDOCS
BAT_CUA_COMPARISON_PROFILES
BAT_CUA_SEND_IDOC_ERRORS

In the child systems the next standard jobs are scheduled:

BAT_CUA_PROCESS_IDOCS
BAT_CUA_COMPARISON_PROFILES

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.

CUA and S4HANA

Despite several rumors, CUA is fully supported with S4HANA. See help.sap.com on CUA in S4HANA 2021.

Background information

More background information:

SAP blog on CUA
SAP help on CUA
SAP CUA cookbook document

Central-User-Administration-Cookbook Download

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.

Logging for users is described in OSS note 139418 – Logging of user actions (ABAP server).

Bug fix OSS notes

Bug fix notes:

2995697 – SAIS_MONI | dialog optimization

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:

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:

An extra authorization check
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.
 
   AUTHORITY-CHECK OBJECT 'S_CDMC'
   ID 'CDMC_AREA' FIELD 'A'
   ID 'CDMC_ROLE' FIELD 'U'.
   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.
       WHEN OTHERS.
         RAISE not_found.
     ENDCASE.
 
   ELSE.
     RAISE not_authorized_business.
   ENDIF.

What is important here in this source code:

The authorization check is implemented and raises an error
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:

  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:

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

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

NOT_AUTHORIZED: this is the RFC authorization, which will be explained next chapter
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)
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.
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:

The RFC layer
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).

Best practice 3: check in transaction SM59 that the RFC callback protection is activated. Read this blog how a hacker can easily misuse if not properly setup.

Best practice 4: be careful on the RFC setup to avoid that hackers misuse the RFC jumping option. Read more in this blog.

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.

Setting up trusted RFC connections

Set up of trusted RFC connections are explained in this blog.

RFC performance

Check if you can use the RFC fast serialization option. This option is available for a lot of modern SAP systems. It is not activated by default. Read more on the fast serialization option in this blog.

Security patch day

This blog will explain more on the SAP security patch day.

Questions that will be answered are:

What is security patch day?
Where can I find the recently released security OSS notes?
Where can I find more background information on security patch day?
Where to find more information on the CVSS scoring mechanism?
What is a practical approach to security patch day and security OSS notes?

Security patch day

Security patch day is every second Tuesday of each month (for more on security patch day itself, you can read the FAQ). The actual OSS notes as summary can be found at the Security response at SAP support security notes page. The patch days themselves are planned and published on this page.

The wiki pages also include a suggested process for dealing with the security patch day OSS notes.

SAP uses the CVSS scoring mechanism to determine the risk a security leak. The scoring mechanism is explained in this blog.

SAP solution manager system recommendations

If you setup SAP solution manager system recommendations, than you will get an always current overview of security notes. With the system recommendations you can mark notes as reviewed, so they don’t appear any more. Applied ABAP notes will be automatically be removed by the tool. Newly released security notes and updated are added to the overview. For setup information on SAP solution manager system recommendations, read this blog.

SAP Focused Run configuration and security validation

SAP Focused Run configuration and security validation can be used to check the application of security notes in your system landscape. For more information, read this blog.

Practical approach to security notes

A pragmatic approach for security notes is the following:

Every 6 to 12 months update your SAP kernel
Apply every 3 month the ABAP OSS notes which can be done automatically (don’t look at the score, just apply them). Leave them on your test and/or acceptance system. This will normally make sure you have no negative side effects. Then move them to production.
Apply every 3 month the ABAP OSS notes with manual actions for the processes you use and for CVSS score you deem high enough to justify the effort of the manual actions

Feel free to increase the frequency of the above proposal.

Adjusting standard SAP code in S4HANA

In S4HANA the SSCR and developer key procedure are no longer present. This means you have to use proper authorization concept to determine which person is allowed to developer Z ABAP code and which developer is allowed to modify standard SAP ABAP code.

Questions that will be answered in this blog are:

Why has the has the procedure been removed?
How do I protect code adjustments from unauthorized changes?

S4HANA developer key

The title is a bit misleading. In S4HANA there are no developer keys and object keys any more.

Background of this change be SAP can be found in OSS note: 2309060 – The SSCR license key procedure is not supported in SAP S/4 HANA.

So in S4HANA, you must set up authorizations for S_DEVELOP properly. The development key and SSCR procedure are hacked anyhow (see blog).

With S_DEVELOP you have to set create/change rights for the packages and or objects. For custom code only hand out Z* privileges.

If you hand out a * for the objects or classes, then the developer can also change standard SAP.

Changes to standard SAP in S4HANA

The SCCR procedure is gone in S4HANA. This means if you want to adjust standard SAP code and you have the authorizations, you can without any SSCR screen asking you for the modification key.

Again also here: i you hand out a * for the objects or classes, then the developer can also change standard SAP.

All protection of ABAP code in S4HANA is arranged via authorization.

Developer license measurement in S4HANA

The move away from DEVACCESS has also made the developer license measurement in S4HANA complex. Read more in this blog.

Table logging

Table logging captures all table changes. This blog will answer the following questions:

How to activate table logging in general?
How to check if for specific table the logging is active?
How to check table changes for a specific customizing action?
How to check general table change?
How to delete table logging?
When not to use table logging?
How can I review table logging for audit purposes?

Table logging activation

In RZ11 system parameter Rec/Client determines the table logging for the complete system. Make sure the value is set to ALL.

As of new S4HANA 2021 installations or upgrades the activation is done by default: 3093760 – Table Data Change Logs In ABAP Platform.

Table logging per table

In transaction SE11 enter the table you want to check and then go to the technical settings. As example table T000:

At the section Data Changes you can see that Log Changes has been activated.

Mandatory table logging

In OSS note 112388 – Tables with obligatory logging the mandatory table logging is explained. Which tables are logged is explained in OSS note 2543478 – SCU3 | Which tables are logged?.

How to view table changes?

The common way to view table changes is via transaction SCU3. At the start screen press the button analyze logs:

In the next selection screen enter the table to analyze. In this example we analyze table T000:

Make sure to set the radio button to Tables. Output of the changes to table T000 then looks as follows:

Here you can see changes done by user ILLEGALUSER. At which date and time they were done, and the old and new value.

Bug fixes:

Checking table changes from customizing

If you are in a customizing action and you want to see who did perform changes, select the menu Utilities and then option Change Log. Select date and time frame to analyze and press Execute. As example here changes to Plant Definition (table T001W):

Custom tables and standard SAP tables

By default a lot of SAP configuration and important setting tables have the log changes activated. But not all. It is not uncommon to activate table logging for standard SAP configuration tables important for your business. For important custom configuration Z tables you might want to activate table logging.

Table logging is not a replacement for change documents. Standard SAP generates change documents for changes to documents that must be kept for tracking and audit purposes. This is common for all major transnational objects and its underlying tables. That is why for example for an important table like VBAK (sales order header) the table logging is off: change documents are already generated.

It is very bad practice to make use of table logging for business data reasons. Table logging is used for recording changes to configuration and if all theses logs are deleted there should be no business impact.

Background OSS note: 3153906 – SCU3 | How to enable logging for tables in customer name space.

Deletion of table logging

Table logging can be deleted with transaction SLG2.

Make sure only very limited amount of people have access to SLG2 and the below program SBAL_DELETE.

SLG2 can run for a long time. For background read OSS note 2507213 – SBAL_DELETE runs too long.

Please be aware the deletion is cross client! See OSS note 3000914 – SCU3 | RSTBPDEL | Caution: The table is cross-client.

Other bug fix notes:

Review of table logging for audit

OSS note 112388 – SAP system audit | Tables requiring logging explains the audit relevance of table logging and explanation about program RDDPRCHK.

Table logging can be reviewed with program RDDPRCHK:

Bug fixes for RDDPRCHK:

Direct table hacking

Changing directly data on an SAP table is the IT admin and IT auditors worst nightmare. This blog will show you the ways it can be done.

Questions that will be answered in this blog are:

How can I directly edit tables?
How can I prevent direct table editing?
How can I detect direct table editing?

Overview of methods

Function module SE16N_INTERFACE
Debug & replace
SE16N_EMERGENCY mode
Re-enable &sap_edit for SE16N

Direct table editing method 1: function module SE16N_INTERFACE

This method is available in the SAP S4HANA system. Start with transaction SE37 and key in function module SE16N_INTERFACE. Now press the test button. In this demo we will change dates for sales order table VBAK. In the SE37 test screen enter table VBAK and very important put X in the I_EDIT and I_SAPEDIT fields.

Now hit execute and voila: you are in direct edit mode:

Now we change a few values (date to the year 2027…) and press save:

Data is changed.

Detection of this method: audit logging. In audit logging you can see the user started SE37 and then used report RS_TEST_FRAME_CALL, but you cannot see which module was done, neither is the data change logged.

Prevention of this method:

Debug/replace is needed to change the data: don’t hand out debug/replace.
Deny access to this function module.

Direct table editing method 2: debug/replace

Start transaction SE16 and show the data of the table to edit. Example in this case VBAK data:

Now select a line and put /h for debugging in the command line input. Press enter and the debug screen will open. Double click on the SY-UCOMM field:

In the variables screen now change the value ENTR (for the enter command you gave) to value AEN2 (command to change). Make sure the value is accepted. Now hit F8 to continue. And voila: edit mode:

Change the values (dates in this example) and press save:

How to detect this method: in the SAP audit log (activation of audit log is explained in this blog) show the change in debug/replace mode:

Prevention of this method: don’t hand out debug/replace rights.

And configure the audit log for detection: 3226223 – How to monitor debug activities in SAP Netweaver.

Direct table editing method 3: SE16N emergency mode

In newer SAP netweaver releases there is a new SE16N emergency mode which can be started with transaction SE16N_EMERGENCY. Read all the details in this special blog on this topic.

Direct table editing method 4: re-enable &sap_edit again in SE16N and use it

Apply OSS note 1468636 – CO-OM tools: SE16N: Use of &SAP_EDIT. This seems old, but it is still valid for all S4HANA releases as well. After the note is installed run program RKSE16N_EDIT and activate the function:

Now start SE16N and select your inputs. Before hitting the execute button, enter the command &sap_edit:

Only now press execute. The result is fully editable table.

Audit log detection

Apply/configure OSS note 3140539 – SAL | New event definition for change access in SE16N for detection of table changes in the audit log.

Also check these notes: