SAP Authorizations Maintaining Authorization Objects (Transaction SU21) - SAP Basis

Direkt zum Seiteninhalt
Maintaining Authorization Objects (Transaction SU21)
Security Automation for HR Authorizations
However, the permission trace is a long-term trace that you can turn on using the auth/authorisation_trace dynamic profile parameter. This trace is user- and client-independent. In the USOB_AUTHVALTRC table, the trace supplements the permissions checks that were not captured before the application ran. This function can also be used for customer-specific developments. Now, go to the RZ11 transaction, enter the auth/authorisation_trace parameter name in the selection box, and click View. You will now get to the detailed view of the profile parameter with all properties and the link to a documentation. To turn the trace on, click Change Value and a pop-up window will open. Enter "Y" or "F" for filters here if you want to define a filter (see Tip 38, "Use SU22 and SU24 transactions correctly") and save your input. A warning appears informing you that the parameter value would be reset when the application server is launched.

Now check the SY-SUBRC system variable. If the value is 0, the Permissions Check succeeded. If the value is 4, the test did not pass. At a value of 8, there is an inconsistency in the definition of the authorization object and the verification in the code - this should not happen! If the value is 12, the permission is not part of your permission buffer.
Law-critical authorizations
Transaction SU53 can be used to immediately display the missing authorizations for a single SAP user. This is advantageous when individual background processing or activities are not executed correctly and the cause is suspected to be missing authorizations. In this way, the cause of the error can be narrowed down more quickly.

Your system landscape does not correspond to a typical three-system landscape? Find out what you should consider when upgrading the suggested values of roles. Your system landscape may differ from the typical three-system landscapes, for example, because you have several development systems or development mandates. Transports are then used to merge all developments and customising entries into one consolidation system. Perform your upgrade work in the SU25 transaction and use Step 3 to transport your SU24 data. By contrast, perform this step in all development systems, run all transports together in your consolidation system, and only the last import of the tables is used. The same entries are also recognised as deleted entries. The same is true with your PFCG rolls. Maintain these in multiple development systems or mandates, and if you now want to transport the rolls with their generated profiles, there is a risk that the profile numbers will be the same, as the profile names consist of the first and third characters of the system ID and a six-digit number. If the profiles originate from the same system (even if the client is a different one), import errors may occur due to the same profile names. In addition, the origin of the profile can no longer be traced afterwards. Therefore, you need a way to transport the data for the permission proposal values and the PFCG rolls in Y landscapes in a transparent and consistent way.

During go-live, the assignment of necessary authorizations is particularly time-critical. The "Shortcut for SAP systems" application provides functions for this purpose, so that the go-live does not get bogged down because of missing authorizations.

The Saved Checks button also gives you access to this information afterwards.

For a representative period, a minimum of 14 months and a maximum of 24 months shall be sufficient.
SAP BASIS
Zurück zum Seiteninhalt