This blog post will explain the process for dealing with SAP standard users.
Questions that will be addressed:
- Why are there SAP standard users?
- Which users are there?
- How to check if the standard SAP users are dealt with properly to avoid security issues and how to solve them?
- How to detect if somebody is trying to logon with standard SAP user?
- How to deal with standard SAP user DDIC in client 000?
- How to deal with standard SAP user TMSADM
Why SAP standard users and which ones are there?
After initial installation of SAP there is only one way to login: is via the standard user SAP* with password PASS. After logon, create your own user and disable user SAP* by giving it a new password and lock it. SAP* can be there without profiles and roles. Also set parameter login/no_automatic_user_sapstar to 1 to avoid automatic re-creation of SAP*. SAP has new way of dealing with superuser SAP*; read this dedicated blog.
Also to set up the SAP ABAP system code the standard user DDIC is used. This user compiles the ABAP code.
For software deployments the initial setup must be done by user TMSADM (TMS = transport management system, ADM = admin).
For historical reasons also the EARLYWATCH and SAPCPIC user are still present.
How to check standard SAP user settings and how to solve issues?
SAP delivers standard program RSUSR003 to check for correct setting of these users ID’s and passwords. Transaction code for this program is also RSUSR003.
End result should look like:
If any item has a red or yellow color you should act: link to solution.
How to check if standard users are being unlocked?
You can use SAP Focused Run to have a custom metric to detect when a standard user is unlocked. You can configure an alert mail to be sent 5 minutes after the unlock happens. More information on this: read this blog.
How to detect if somebody is trying to hack a system by trying to log in using standard SAP users?
There are 2 main ways of finding if standard SAP users are being tested for system access:
- Somebody runs report RSUSR003 (whitebox method)
- Somebody tries to use the users and passwords from outside (blackbox method)
Detection of running RSUSR003
Two ways of detection of running RSUSR003:
SM21 system log will show similar entry:
In this log you can see the user of the program and by double clicking you can also retrieve the terminal ID from which the user ran the program.
More background in OSS note 2248319 – Program RSUSR003 reports “Security violation” in SM21 system log.
SM20 audit log can show similar entry (provided the start of report is configured properly):
Also here you can see the user who ran it and from which terminal.
The exact scope of program RSUSR003 is described in OSS note 2481566 – Functional scope of report RSUSR003.
Bug fix note: 3224200 – SUIM | RSUSR003 displays lock by unsuccessful logon.
Detection of black box standard SAP user testing
SM20 audit log can show similar entry (incorrect logon attempts configured properly):
User DDIC in client 000
In many blogs there is a lot of discussion on how to deal with DDIC in client 000. There is no one size fits all approach here.
SAP standard recommendation is:
“To make sure everything runs smoothly, give DDIC the authorizations for SAP_ALL during an installation or upgrade and then lock it afterwards. Only unlock it when necessary.”
This is fine for smaller systems on which little maintenance is ongoing. If more frequently support packs, upgrades and/or installations are happening this is more annoying.
The main issue is when a system is using third party solutions which are provided by external parties in transports. When DDIC is locked in client 000 and the foreign transport is imported, this import will not finish and continues forever until DDIC is unlocked.
That is why on systems with more maintenance, and less strict regimes (business without SoX and FDA, etc), DDIC will not be locked on client 000 and the password is known to basis team. DDIC should be locked in all the other clients.
DDIC unlock in main client is needed only when implementing a TCI based OSS note (see blog on OSS notes).
Background OSS note on DDIC: 1998382 – User DDIC for Transport Activities.
Also read this note: 3035580 – Job RDDIMPDP running as DDIC to replace DDIC with different job user for import dispatchers.
User TMSADM
User TMSADM needs to exist in client 000. It can be deleted in all the other clients (including the main data client). Background on SAP help.
Password change instructions for user TMSADM: 1568362 – TMSADM password change.
User SAPSYS
SAPSYS is used for OS jobs, CCMS monitoring, running the background processing scheduler, and performing other system-internal operations (most of them executed as so-called AutoABAP programs). Don’t lock SAPSYS otherwise you get big issues.
Reference OSS note: 3195498 – SAPSYS user modifying background jobs.
Cross client hacking
See this blog on how a hacker can jump from one client to the other.
Client 001 and 006 deletion
To reduce the attack surface, you can also delete clients 001 and 066. See this blog for more background information.
Standard users in the Early Watch
Standard users are also listed in the early watch. Sometimes with a little different logic. The explanation of standard users in the EWA is kept in OSS note 1610103 – EWA : Default Password of Standard Users – Detailed overview for T/S.
3 thoughts on “SAP standard users”