Securing User SAP* Against Misuse

The R/3 System has a default superuser, SAP*, in the clients 000 and 001. A user master record is defined for SAP* when the system is installed. However, SAP* is programmed in the system and does not require a user master record.

If you delete the SAP* user master record and log on again as SAP* with initial password PASS, then SAP* has the following attributes:

If you want to deactivate the special properties of SAP*, set the system profile parameter login/no_automatic_user_sapstar to a value greater than zero. If the parameter is set, then SAP* has no special default properties. If there is no SAP* user master record, then SAP* cannot be used to log on.

You should set the parameter in the global system profile, DEFAULT.PFL, so that it is effective in all instances of an R/3 System. You should ensure that there is a user master record for SAP* even if you set the parameter. Otherwise, resetting the parameter to the value 0 would once again allow you to log on with SAP*, the password "PASS" and unrestricted system authorizations.

You can find information on this in the Computing Center Management System documentation under R/3 System Administration.

If a user master record exists for SAP*, it behaves like a normal user. It is subject to authorization checks and its password can be changed.

Deactivating User SAP*

As SAP* is a known superuser, SAP recommends that you deactivate it and replace it with your own superuser. In the SAP* user master record, you should proceed as follows:

The SUPER user group has a special status in the predefined user profiles. (They are described later in this topic.)

The users that are assigned to group SUPER can be maintained or deleted only by the new superuser that you define, provided that:

Defining a New Superuser

To define a superuser to replace SAP*, you need only give a user the SAP_ALL profile. SAP_ALL contains all R/3 authorizations, including new authorizations released in the SAP_NEW profile.

SAP_NEW assures upward compatibility of authorizations. The profile ensures that users are not inconvenienced when a release or update includes new authorization checks for functions that were previously unprotected.