Starting reports
Permissions with status
Is it necessary for your evaluations to select the blocked or invalid users? This is now directly possible with the extensions of the user information system. There is always a requirement to evaluate the existing users in your SAP system. Examples may include lists requested by auditors. In such a case, you naturally want to exclude invalid users and those with administrator lock from the selection. Up to now, you have had to perform various evaluations with the reports RSUSR200 and RSUSR002 of the user information system (transaction SUIM) and subsequently edit the lists. The findings may not have been accepted by the auditors as the lists were visibly manipulated, even if this manipulation was justified. You can now enter this selection directly. We will show you below how to search for users with password or administrator lock or exclude them from your selection.
Create a report transaction for the report that is called in the background job. Set up the report transaction in the transaction SE93 and assign the report RHAUTUPD_NEW as a programme. Start the authorisation trace by setting the auth/ authorisation_trace profile parameter to Y or F if you want to work with filters (see tip 38, "Use the SU22 and SU24 transactions correctly"). Now run the job to collect permission checks on the permission trace. Your permission checks should now be visible in the STUSOBTRACE transaction. Now maintain the permission proposal values for your report transaction in transaction SU24 by entering the transaction code in the appropriate field. You will find that no values are maintained. Now switch to Change Mode. You can add your permission suggestions from the trace using the Object > Insert objects from Permissions Trace > Local (see Tip 40, "Use Permission Trace to Determine Suggest Values for Custom Developments"). Add the suggestion values for each displayed authorization object. Now create a PFCG role that includes the report transaction permission and maintain the open permission fields. Then test whether the job can be run with the permissions from the PFCG role.
RSRFCCHK
Existing log files are managed using the SM18 transaction. Here you can delete the log files in all active instances. This requires the indication of a minimum age in days for deletion. The smallest possible value is three days, without taking the current day into account in the calculation.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
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 possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
So first analyse the processes (if possible also technically) and then create a concept.
So much information... how can you keep it so that you can find it again when you need it? Scribble Papers is a "note box" that makes this very easy.
The majority of German companies with an SAP system do not yet use authorization tools.