There is a client – there is no access

The situation encountered by many administrators – we have the SAP ABAP system (R/3, ERP, S/4HANA, etc.) acting as a configuration or test system and in this system there are several clients serving specific purposes (configuration, unit tests, acceptance tests, etc.).  Sometimes, however, looking inside  SCC4 transaction, we see clients that are not used:

Fig1. List of clients in SAP system

In the above illustration we can see client 000 – i.e. a client provided by SAP used among others as a source for creating (by copying) new clients in the system, client 100 – used for development and development activities and client 200 – well, currently serving no purpose. Key users who took part in the implementation of the system a few years ago remember that in this client tests of data migration from previously used systems were made – before the test system was installed, but it was not possible to find anyone who could log in to the client at the moment.  And we are often  lacking documentation of administrative user passwords (SAP*, DDIC) created in this kind of “additional”, clients created “only for a while” (sometimes this “moment” takes years…), often they are simply not recorded in any document stored securely (safe or cryptographically secured medium).
So we have a client  to which we can not log in, which has the following consequences:
– we are not able to  conduct a security audit in it – and maybe someone can log in there and use tools independent of the client  to wreak havoc on the system (even by removing tables from the database);
– client takes up space in the database, increasing the occupancy of backup media;
– we cannot delete the client (using the SCC5 transaction requires  login into client  to be deleted).

Getting started
To sum up – we need   a way that will allow us to log in with a user with wide permissions to such “forgotten” clients.  Where to start? First of all –  running the RSUSR003 report in another client (in our example – in the 000 or 100 client)  which checks whether there are  SAP* and DDIC users and whether standard passwords have been used for these users:

Fig2. Result of report RSUSR003

If the report shows that standard passwords have been used for the SAP* or DDIC user, we need to look into  SAP note 8852 or 389530 to find them.   In our example, this is not the case – in the 200 client the DDIC user does not exist, the SAP* user has a password different from the standard one.
In this case, it is necessary to lead to a situation in which:
– login/no_automatic_user_sapstar parameter will be set to 0
– in the client to which we want to log in  the user SAP* will be absent.
Meeting these two conditions will allow us to log in to the client with an SAP* user with the default password pass.
The login/no_automatic_user_sapstar parameter in our example has a value of 1 (please look above, on the RSUSR003  report screen) – this value can be changed by logging in to another client and using the RZ10 transaction.

Fig3. Change of  login/no_automatic_user_sapstar  parameter value

After changing (or adding) the parameter, remember to save and activate the changed profile.

Fig4. Activation of profile after changes

In order for the change in the profile to take effect, you still need to restart the SAP application instance – using the MC console, MMC console or operating system commands.

Delete SAP* user
How to remove SAP* user from the client to which we want to log in?  Due to the lack of access to the client, the use of SU01 transactions is impossible, but the possibility of removing the user using database tools from the server operating system level still remains.
For our sample S6T system, MaxDB database  and Linux operating system are in use.
We will need the following data:
– logon data for user  <sid>adm at the level of operating system  of the database server
– database name
– the name of the user who owns the schema in the database storing the tables of the SAP system|
– password of the user who owns the schema in the database
User <sid>adm logon data  we usually have at hand, the name of the database and the name  of the user who owns the scheme in the database we can  determine by logging in to the SAP system and on any screen selecting the System ->  Status… option from the menu:

Fig5. Determining scheme owner

Remark:
SQL syntax and SQL tool described here are specific to MaxDB.   For another database, the tool and syntax specific to that database must be used.
We log in to the server via ssh on the user <sid>adm (in our case s6tadm) and call the command:
sqlcli  -d <DBN> -u <USER>,<password>
Where:
sqlcli – SQL  command line tool
<DBN> – database name (3 characters)
<USER> – the name of the user who owns the schema in the database
<password> – password of the user who owns the schema in the database
In our example, the call line will look like this:
sqlcli -d S6T -u SAPS6T,qqa41mfr

After calling the sqlcli tool, a prompt of SQL query appears, so we can use the select command  to list records from SAP tables or delete the  selected record from the table.

Remark:

In each case of any operation using the SQL tool, it is recommended  to take  full backup of the database.  Any mistake can have severe consequences, for example, accidental deletion of all entries from the USR02 table will remove all users from SAP system – all clients!
So let’s make sure that in the 200 client  SAP* user exists.  The user logons are  stored in the usr02 table, the MANDT column contains the clent number, the BNAME column – the user name (usr02 table has many more columns of course but their content in this case is beyond our interest).  So let’s execute the SQL query by pressing the <ENTER> key:
select MANDT, BNAME from usr02 where MANDT = ‘200’ and BNAME = ‘SAP*’

As you can see, the SAP* user record has been listed in the 200 clent.
We want to delete this record, for this we will use the SQL delete command:
delete from usr02 where MANDT = ‘200’ and BNAME = ‘SAP*’

As we can see, as a  result  one record was deleted from the usr02 table  of the database, so let’s repeat the select command  to see that  the rekord of the SAP* user in the 200 client has disappeared:

As you can see – the SAP* user in the 200 client does not exist anymore.
We finish working with the SQL tool with the exit command:

If in the USR02 table there is no SAP* user for client 200 and in the system the login/no_automatic_user_sapstar parameter  is set to 0, we can proceed with our try to log in the SAP* user using the pass password – this password is stored in the code of the authorization mechanism and can be used only if the two conditions described above are met:

Fig6. SAP* logon

Final steps
Further actions after changing the password should include:
– creation an SAP* user in the client
– creation of a user for administrative purposes, accompanied by appropriate authorizations
– change the value of the login/no_automatic_user_sapstar parameter  to 0 (RZ10 transaction)
– restart the system instance
After performing these actions, we have access to the client and can carry out activities related to its removal, security analysis, etc.