Advantages of authorization tools
List of required organisational levels and their value
When you create users in the SU01 transaction, do you want to automatically pre-occupy certain fields from a data source? Use a new BAdI for which we present an implementation example. If you create a user in the SU01 transaction in an SAP system, there is almost always data about that user in other systems. A classic example is user data in the Active Directory or the personnel master data in SAP ERP HCM, which are already maintained as part of the employee recruitment process. If user data is present in multiple systems, then the first choice is to automatically create a user through an identity management system, which is resolved by an HR trigger in SAP Identity Management (ID Management). ID Management detects changes, such as personnel master data, SAP ERP HCM, or business partners in SAP CRM, and either applies the appropriate users in your systems or makes changes and deactivations. But what if you don't have an identity management system in place? Do you need to type all of this data? No - you can pre-document them automatically. You can use a Business Add-in (BAdI), which allows you to pre-define certain fields when you create a user in the SU01 transaction.
In each filter, you can define for which clients and users events should be recorded. You can record the events depending on their audit class or categorisation, or you can select them directly via the detail setting. For the Client and User selection criteria, you can use generic values, i.e. you can select all clients or users that meet specific naming criteria (e.g., Client 10* or User SOS_*). For example, you can filter the loggers of multiple emergency users.
Grant permissions for SAP background processing
SAP customers do not maintain suggested values in this transaction. However, there are cases where data in the SU22 transaction is maintained in a customer environment. If TADIR services or external services are developed by the customer or partner, these services are not available by default in the SU22 transaction or the SU24 transaction. For these services, the header data must first be written to the USOBHASH table, which serves as the basis for maintaining the services. These entries in the USOBHASH table are generated automatically when running TADIR services. Read Tip 41, "Add external services from SAP CRM to the proposal values", for dealing with external services. Once the data in this table is available, you have the option to maintain the proposed values.
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.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
For example, this is the case in the Activity field.
Double-click on the key list, and you will be taken to the care image where you have to create an entry with *. This will transport all entries in the KBEROBJ table starting with a space.