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*.
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.
End result should look like:
If any item has a red or yellow color you should act: link to solution.
How to detect if somebody is trying to hack a system by trying to log in using standard SAP users?
This part requires intermediate SAP knowlegde
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.
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.
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).
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.
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.