Law-critical authorizations
Eligibility proposal values
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.
As in other systems, user maintenance and role/profile assignment must be restricted to the group of user administrators. In contrast to the previous systems, however, roles and profiles are maintained here, so that appropriate rights must be assigned to the role/profile administrators.
Query Data from Active Directory
In principle, all eligibility fields can be upgraded to the organisational level; there are, however, technical exceptions and fields where this is not useful. Technically, the fields that are in the context of testing the startup capability of an application are excluded, i.e. the fields of the S_TCODE, S_START, S_USER_STA, S_SERVICE, S_RFC, S_PROGRAM and S_USER_VAL authorization objects. In addition, you cannot elevate the ACTVT field to the organisation level. Only the fields that can be assigned a value range within a role are meaningful. This must of course be considered across the board for the authorisation concept. For example, fields that have more than one meaning, such as the Authorisation Group (BEGRU), are not suitable for material management. The PFCG_ORGFIELD_CREATE report allows you to define a permission field as an organisation level. The report enters the field in the USORG table, changes the permission proposal values to that field, and performs all the roles that have a shape in the field.
As a result, you will get an advanced IMG structure, in our example FF Log settings, which you can access via the transaction SPRO. Finally, you could use the transaction COAT (see SAP Note 1089923) to assign additional attributes to your own tables and reports, for example. For example, this could be relevant for the tax audit and final reports or performance critical.
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
There are several ways to restrict access to tables by using table tools.
Alternatively, you can also use the Use only users without locks option and additionally, in the Selecting after the user is valid between user today and user today, select not valid.