Ensuring secure administration
Include customising tables in the IMG
Let's say that a user - we call her Claudia - should be able to edit the spool jobs of another user - in our example Dieter - in the transaction SP01. What do you need to do as an administrator? Each spool job has a Permission field; By default, this field is blank. If Claudia wants to see a Dieter spool job, the system will check if Claudia has a specific spool job permission with a value of DIETER. Claudia does not need additional permissions for its own spool jobs that are not protected with a special permission value.
In the SU22 transaction, the developers of an application maintain the proposed values for all required authorization objects; the authorisation trace helps in this. As described in SAP Note 543164, the dynamic profile parameter auth/authorisation_trace of the trace is set to Y (active) or F (active with filter). By inserting the SAP Notes 1854561 or the relevant support package from SAP Note 1847663, it is possible to define a filter for this trace via the STUSOBTRACE transaction, which you can restrict by the type of application, authorization objects, or user criteria.
Set up permissions to access specific CO-PA measures
Now the structure must be filled "with life". To do this, you must first create meaningful subfolders in the customer's own structure. As already mentioned, these are mostly based on the SAP modules. Make sure that you also set your customising for additional add-ons, so that later the work of support organisations is easier. Call the transaction SOBJ. There, you create customising objects that will later be reused in your IMG structure. It is useful to name the object exactly as the corresponding table. This simplifies the later maintenance in the IMG structure. Here you also decide whether and how the tables can possibly be maintained in the productive system. To do this, select the appropriate entries in the Category and Transport fields and check the Current setting option. Repeat this for all custom customising tables that are still needed.
The general SAP authorizations are used most often and for many things they are sufficient. For example, if only the HR department has access to the SAP HCM system. However, if other users come onto the system and you only want to allow them access to a limited number of personnel, then in the case of the general authorizations you have to deal with the organization key of infotype 1 (VSDK1), which must be hard-coded into the authorization roles. If ESS/MSS or Manager Desktop etc. now come into play, however, this means a large number of authorization roles, namely a separate one for each manager. This makes maintenance and servicing very time-consuming and your authorization concept becomes opaque, which in turn brings the much-quoted auditor onto the scene.
However, if your Identity Management system is currently not available or the approval path is interrupted, you can still assign urgently needed authorizations with "Shortcut for SAP systems".
In most cases, the different rules according to which the risks of SAP authorizations are assessed are problematic.
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
You may ask yourself in which cases it makes sense to adjust the proposed values, since they have such a large impact on the maintenance of roles.