Note the effect of user types on password rules
User administration (transaction SU01)
I show how SAP authorizations can be assessed and monitored by using the Three Lines of Defense model. This method can be applied even if the model is not used for all enterprise risks. You will learn how to integrate the different stakeholders into the lines of defense and harmonize the knowledge for the process. Also, what tools can be used for controls and cleanups in each case. This ensures, for example, that managers are able to assess the risks and derive measures, and that administrators can technically clean up the risks.
There are extensive revision requirements for password rules. Learn how to define these requirements globally, which special characters are accepted by the SAP standard, and how to set the parameters for generated passwords. Do you not want to use SAP's standard password creation rules, but rather make your own password requirements for your users? Do you need to implement internal or external security requirements, such as audit requirements? You do not want to allow certain words as passwords, exclude certain special characters or change the formats of passwords generated by the SAP system? In the following we give you an overview of the possible characters, the existing profile parameters and the customising settings for passwords.
RFC interfaces
An essential aspect in the risk assessment of a development system is the type of data available there. Normally, at least a 3-system landscape is used (development, test and production system). One of the purposes of this is to ensure that (possibly external) developers do not have access to productive or production-related data. Since developers with the required developer authorizations have access to all data in all clients of the system concerned, there should be no production-related data in a development system. Even a division into a development and a test client (with the sensitive data) within the system does not protect against unauthorized data access for the reasons mentioned above. In the following, it is assumed that no production-related data exists on the development system. Otherwise, extended authorization checks must be carried out in the modules and access to production-related data must be approved beforehand with respect to the production system by the respective data owners. Since developers, as described, have quasi full authorization through their developer rights, revoking the authorizations listed below can raise the inhibition threshold for performing unauthorized activities, but ultimately cannot prevent them.
This list in the AGR_1252 table contains both the organisational fields that are shipped in the standard and the fields that you have collected for organisational fields. Unfortunately, the list does not indicate what kind of organisation field it is. But you can find out: Open the PFCG_ORGFIELD_DELETE programme via transaction SA38. The Organisation Level Value Helper (Orgebene) provides a list of all customer-specific organisation fields, because only these can be converted back to normal Permissions Object Fields. Note the implications if you want to actually run this programme.
During go-live, the assignment of necessary authorizations is particularly time-critical. The "Shortcut for SAP systems" application provides functions for this purpose, so that the go-live does not get bogged down because of missing authorizations.
This change was provided through a support package; For details, see SAP Note 1611173.
Implementation in the BAdI is running.