Authorization objects of the PFCG role
Maintain batch job suggestion values
No more users can be created, maintained or deleted without the assignment of a valid user group. If a user group is not assigned when a user is created, the user is automatically assigned the default user group. Before you set the USER_GRP_REQUIRED switch, a user group must have been assigned to each existing user and the administrators must have the permissions for the default user group. When creating a new user, the default user group will be used as pre-occupancy; this user group can be overridden by setting another user group in the S_USER_GRP_DEFAULT user parameter for each user administrator. The customising switch requires a valid user group, because it is used as the default user group. If a valid user group has not been entered in the customising switch, the user group is nevertheless a mandatory field. This will lead to errors in automated user creation.
Due to the complexity of an SAP® authorization concept, it is necessary that all essential aspects are set down in a written documented authorization concept. This should describe the essential processes, but also how to handle the assignment of authorizations via roles. In particular, the nomenclature of specially created roles must be clearly defined. It should therefore be checked whether all changes since the last audit have been documented in the written authorization concept. After all, this document serves the auditor as a template for the so-called target/actual comparison. This means that the auditor compares the document with the actual status in the SAP® system for the main topics relevant to the audit. Any discrepancy can lead to a finding that must be avoided.
Security in development systems
We therefore recommend that you schedule a background job on the PFUD transaction, which performs a regular user comparison (see Trick 17, "Schedule PFUD transaction on a regular basis"). By the way, did you know that the auth/tcodes_not_checked profile parameter enables you to disable the transaction startup permissions for the SU53 and SU56 transactions? To do this, enter the value SU53, SU56, or SU53 SU56 for the profile parameter. This means that the end user no longer needs the permissions to run these transaction codes from the S_TCODE authorization object.
A mass rolling out of rolls is a very useful thing. It is also possible to use Excel-based data - as in the case of the outlined application case with eCATT - because it is a one-time action for the roles considered and SAP standard programmes are used in the background. However, ongoing maintenance of the permissions system, with continuous changes to roles and their detail permissions, requires the mapping of much more complex operations. An exclusive control over Office programmes should be well considered. This does not mean, of course, that there are not very good partner products for the care of roles. Simply verify that SAP standard procedures are used and that authorisation is managed in accordance with SAP best practices.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
You can now perform the individual steps of the audit along the definition in the audit tree.
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
To implement the BAdIs, use the transaction SE18; there you can also see the example class CL_EXM_IM_IDENTITY_UPDATE.