Direkt zum Seiteninhalt
Handle the default users and their initial passwords
The passwords of the users are stored in the SAP system as hash values. The quality of the hash values and thus their safety, however, depends on the hash algorithms used. The hash algorithms previously used in SAP systems are no longer considered safe; They can be cracked in a short time using simple technical means. You should therefore protect the passwords in your system in various ways. First, you should severely limit access to the tables where the hash values of the passwords are stored. This applies to the USR02 and USH02 tables and in more recent releases the USRPWDHISTORY table. The best way to assign a separate table permission group to these tables is to do so, as described in Tip 55, "Maintain table permission groups". In addition, you should also control the accesses using the S_TABU_NAM authorization object.

The report RSUSR008_009_NEW (List of users with critical permissions) is provided starting with SAP Web Application Server 6.20 with the following support packages: Release 6.20, starting with SAPKB62039 Release 6.40, starting with SAPKB64003 You can continue using the old reports RSUSR008 and RSUSR009 until release 6.40. The RSUSR008_009_NEW report is delivered with the old SAI proposals for critical credentials already used in the RSUSR009 report.
Law-critical authorizations
Today we come to the error analysis with authorizations. The best thing that can happen is the error of the type: "I don't have authorization to do this and that!" (CASE1). Worse is the case that someone has too many permissions, i.e. the type: "User xy should not have this permission anymore" (CASE2). How to proceed? First of all we come to case 1 This case, that someone has no authorization for something, supports the system excellently! The code word is SU53! If a transaction encounters an authorization error, then this error is written to a memory area that can be displayed. For this there is once the transaction SU53 or the menu selection "System/Utilities/Anc authorization check". With this function, the system outputs information showing which authorization objects are missing for the user.

You can schedule background jobs in the SM36 and SA38 transactions, but also in a variety of application transactions. It is important to know that special permissions are not necessary for the installation, modification, etc. of your own jobs. An exception is the release of background jobs; it is protected by a permission. Permissions are also required for the activities on other users' background jobs, and the following authorization objects are available in SAP backend processing: S_BTCH_JOB controls the access rights to other users' jobs. S_BTCH_NAM allows you to schedule programmes under a different user ID. S_BTCH_ADM grants parent permissions that are usually only required by administrators.

Assigning a role for a limited period of time is done in seconds with "Shortcut for SAP systems" and allows you to quickly continue your go-live.

However, this does not mean that you have to care for all users individually! It is common for you to make mass changes to users in the SAP system, such as changing role assignments, locking a group of users, or having to adjust their validity dates.

To access business objects or execute SAP transactions, a user needs appropriate authorizations, since business objects or transactions are protected by authorization objects with multiple authorization fields.
Zurück zum Seiteninhalt