Hardening measures for the handling of SAP standard users are an integral part of the SAP security and audit guides. Doesn’t everyone already know that? Only at first glance. Consulting practice has shown that the implementation of these protective measures is a regular, major challenge for businesses of all types and sizes.
To protect the standard users, SAP recommends reviewing certain criteria regularly. The official SAP Security Guide contains the following information:
- Maintain an overview of the clients that you have and make sure that no unknown clients exist.
- Make sure that SAP* exists and has been deactivated in all clients.
- Ensure that default passwords for SAP*, DDIC, and EARLYWATCH have been changed.
- Guarantee that that these users belong to the group SUPER in all clients.
- Lock the users SAP*, DDIC, and EARLYWATCH. Unlock them only when necessary.
- By default, the user DDIC is set up to be used for the transport background job (RDDIMPDP). We recommend you set up a different user for this job so that you can lock DDIC.
- The user needs SAP_ALL and S_A.SYSTEM authorizations because the job calls function modules for various applications that cannot be determined for all cases ahead of time.
- Set up the user as a system user so that no one can use it as a dialog user.
- Set up the user in all clients that are used for import.
- Adjust the job RDDIMPDP so that the new user is the owner (in transaction SM37).
- Delete SAPCPIC if you do not need it. At least make sure that you have changed the default password for SAPCPIC.
- For more information, see Authorizations in Version Management.
- Change the default password of TMSADM.
Companies with complex SAP system landscapes face particular challenges here, because nobody wants to risk production downtimes.
The following difficulties arise regularly when the DDIC user needs to be locked:
- The DDIC user has been used as the batch step user for background processing since the initial implementation of the system
- No overview is available as to how many RFC interfaces use the DDIC user
- The customer program still runs with hard-coded DDIC logon data
- The IT service provider uses the DDIC user to administer the Basis client
Do any of these problems and concerns sound familiar?
We’ll show you a quick, efficient way for identifying the use of user master records in batch job steps and correcting the step users automatically.
Protecting SAP standard users in the background processing (batch job) scenario
You have been tasked with implementing the security recommendations for SAP standard users as described in the SAP Security Guide and want to lock these users. Due to the long operating history of the system, however, you’re not sure if the standard user DDIC might still be used in periodic batch jobs in application clients, for example. A hasty deactivation of the user in the application client could result in painful interruptions to operations. That’s why you want to identify critical batch jobs and correct the step users ahead of time – as automated as possible.
The implementation method
- Take stock of all affected batch jobs
- Create alternative background users with suitable authorizations to take over background operations
- Test the batch jobs with the new background users
- Automatic replacement of the step users
The method in detail
- Take stock of all affected batch jobs
One lesser-known but very useful function in more recent SAP releases is the “Extended Job Selection” in transaction SM37. Previously, if you wanted to identify the step users, you either had to evaluate the tables TBTCO/TBTCP via query or use a custom ABAP program.
To identify the batch jobs, select transaction SM37: switch to “Extended Job Selection” and then set the following filter settings:
Start the report:
- Create the new background users for the functions (such as BTCUSER200)
- Test the background functions to be rescheduled
- Replace the DDIC step user in the affected batch jobs. A lesser-known, yet efficient tool for efficient mass change of batch jobs is the report BTC_MASS_JOB_CHANGE. It supports flexible changes to the following job properties:
- Report/variant to be executed
- User name of the job user
- User name of the step user
- Execution target (server/group)
To do so, set the selection parameters. Tip: The report can also be run in test mode.
Then run the report:
Test the success of the changes in transaction SM37:
The step user for the next run has been changed successfully from DDIC to BTCUSER200; the step user of job runs that are already complete remains unchanged by the conversion.
Other aspects for protecting SAP standard users
To ensure that the use of SAP standard users does not result in interruptions in operations, you should check where they are used in at least the following areas:
- Inbound RFC interfaces
- Hard-coded logon data in customer programs
- Use in batch input sessions (SM35)
- Processing with LWMW (ERP), LTMC (S/4HANA), or eCATT
We can support you in speeding up the analysis work
Our SAST SUITE can help you identify the actual use of SAP standard users in all important areas of your system landscape quickly and effectively, enabling you to implement hardening measures safely and at practically no risk to operations management.
Ansgar Rümpker (Principal SAP Consultant, SAST SOLUTIONS)
Further interesting articles: