Eligibility proposal values
Customizing
Before you start and define critical permissions, you should identify your core business processes or functions and then map the conflicting processes in meaningful combinations as so-called risk. The RSUSR008_009_NEW report cannot replace a GRC system (GRC = Governance, Risk, and Compliance) with the SAP Access Control component. Rather, this report should be understood and used as an indicator of the current system state. The report identifies the users that have the critical permission combinations defined in the USKRIA table. The identifier, which can also be called a risk ID, describes a combination of authorization objects with field names and field values. These are linked to one of the two operatives AND or OR available.
If you set the profile parameter dynamically, no users are logged out of the application server. You can prepare maintenance work in good time. The value 2 in the profile parameter does not prevent the login with the emergency user SAP*, if this is not set as user master record and the profile parameter login/no_automatic_user_sapstar is set to 0. You can also change the value of the parameter again at the operating system level. For details on the SAP user, see Tip 91, "Handling the default users and their initial passwords".
Query the Data from an HCM Personnel Root Record
Once you have defined your criteria for executing the report, you can create different variants for the report and schedule corresponding jobs to automatically lock down or invalidate the inactive users. If you want to start the report in a system that is connected to a Central User Management, you should consider the following points: You can only set local user locks. You can set the validity period only if the maintenance is set to Local in the settings of the Central User Management (this setting is set in the SCUM transaction).
If the changes to your SU24 data have not been detected with step 2a, or if you have imported transports from other system landscapes into your system, you have the option to reset the timestamp tables and start again. To do this, run the SU24_AUTO_REPAIR report in a system that is still at the state of the legacy release so that the modification flag is set correctly (see tip 38, "Use the SU22 and SU24 transactions correctly"). Subsequently, you create a transport and transport your SU24 data to the system, which is at the state of the new release. Now delete your timestamp tables. You can use the report SU25_INITIALIZE_TSTMP. Starting with SAP NetWeaver 7.31, you have the choice to set the reference time stamp from the SU22 data or delete the contents of the time stamp tables. You can then run Step 2a again.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
Understanding the structure and functioning of the system is especially important for IT administration. It is not for nothing that "SAP Basis Administrator" is a separate professional field. On the page www.sap-corner.de you will find useful information on this topic.
After confirming your entries, you confirm the Permissions field maintenance in the Permissions proposal maintenance by clicking on the green checkmark, so that the status of the Permissions object is green (maintained).
So much information... how can you keep it so that you can find it again when you need it? That's what Scribble Papers is great for.
You can then run Step 2a again.