Prevent excessive permissions on HR reporting
CONCLUSION
With the help of the transaction SU22, the software developers can deliver their application with the appropriate authorization objects. After the transfer of the data from the transaction SU22 to the tables from the transaction SU24, the role developer may further process the proposed values with the transactions SU24 or SU25 for use in the transaction PFCG. Please also refer to the SPA 1539556.
If the authorization objects also require permission fields, you can create them in the SU20 transaction. When creating a authorization object in the SU21 transaction, you first set a name and description for the authorization object, and then assign it to an object class. Then assign the necessary permission fields. If any of these fields are ACTVT, you can select all of the activities to be checked by clicking the Activities button. The navigation behaviour has been improved here a lot.
Authorization Analysis
A troublesome scenario you're probably familiar with: You will soon be going live with a new business process and must now derive your roles in 97 accounting circles. Here eCATT can make your life easier. It's time again: If you don't have anyone in your department who likes to press the Copy button for several hours in the PFCG transaction, replace the Derive shortcut, and then customise the Organisation Levels (Origen) in the new roles on the Permissions tab (repeatedly connected to memory), the job will hang on you. Because there is hardly anything more boring, at the latest after one hour the first errors creep in. Whenever you have to roll out new roles, for example for your new premium business, to all your divisions, plants, etc. , the creation of the derived roles is tedious - because SAP does not offer smart mass maintenance. The SAP standard offers various ways to record and play on a massive scale. These tools are generally available for all operations in the SAP system, not just for role maintenance. Therefore, they are also more complex to operate, in order to be able to cover as flexibly as possible all possible application scenarios. eCATT is also no exception, so many users are still afraid to use it. But we can tell you from experience: After the second or third time, the creation of the test scripts is so quick that you'll wonder why you haven't always done it this way.
The test for the assignment of the SAP_ALL profile is carried out in the SOS differently than in the EWA: If a user is found, assigned to SAP_ALL, and you have not entered it in the corresponding whitelist, it will still be hidden in the subsequent permission checks. Identified users will be output either through a complete list or through examples of specific users. In both cases, you can download the full list in the SAP Solution Manager's ST14 transaction. You can use the Check ID to map user lists to the permission checks. However, you should note that these lists do not contain the evaluations of the whitelists.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
Warning: Do not perform step 1 (customer tables were initially filled), because this overwrites the USOBT_C and USOBX_C customer tables, i.e. the SU24 data, completely with the SAP suggestion values.
You can simply export this table to Microsoft Excel and then evaluate it.