Customizing
Use timestamp in transaction SU25
New AP implementation, S/4HANA conversion or redesign of an SAP authorization concept - the complexity has increased enormously and requires a clear structure of processes, responsibilities and the associated technical implementation. New technologies such as Fiori and Launchpads are challenges and reasons to rethink authorization structures.
Finally, we would like to draw your attention to SAP Note 1781328, which provides the report PFCG_ORGFIELD_ROLES_UPD. This report enables a mass update of existing role derivations. However, you do not use the concept of the organisational matrix, but you have to store the new organisational values directly when the report is called. Therefore, this function requires a high degree of understanding for the adjustments that are running in the background and is therefore only available as a pilot note. This means that this message must be explicitly requested via a customer message and only then will SAP support release it for you if necessary. It is not currently planned to make the information generally available via a support package.
Authorization concepts in SAP systems
When you mix roles, either after upgrading or during role menu changes, changes are made to the permission values. You can view these changes as a simulation in advance. As described in Tip 43, "Customising Permissions After Upgrading," administrators may see some upgrade work as a black box. You click on any buttons, and something happens with the permissions in their roles. For example, if you call step 2c (Roles to be reviewed) in the SU25 transaction, all roles will be marked with a red light, which requires mixing based on the changed data from the SU24 transaction. Once you call one of these roles and enter the Permissions Care, the permission values change immediately. Using the Alt, New, or Modified update status, you can see where something has changed, but you cannot see the changed or deleted values. A simple example of how to play this behaviour without an upgrade scenario is changing the role menu. Delete a transaction from a test role and remix that role. You are aware that certain authorization objects have now been modified and others have even been completely removed, but can't all changes at the value level be replicated? Thanks to new features, this uncertainty is now over.
So much information... how can you keep it so that you can find it again when you need it? Scribble Papers is a "note box" that makes this very easy.
In principle, the SAP_NEW permission should not be granted in the production system. The Profiles tab displays the generated profiles in the user master record that are associated with a specific user. Here you can also assign manually created permission profiles from the transaction SU02 - even without direct role mapping. In principle, the recommendation is to use the profile generator (transaction PFCG) to generate authorisation profiles automatically. Special caution is taken when you enter generated permission profiles directly on the Profiles tab, as these assignments will be deleted by matching user assignments with the transaction PFUD if no entry is on the Roles tab for the assignment. You have probably assigned SAP_ALL and SAP_NEW to users for whom there should be no restrictions in the SAP system. But what are these two profiles different from each other and why are they necessary?
"Shortcut for SAP systems" is a tool that enables the assignment of authorizations even if the IdM system fails.
These RFC connections can be used for the so-called RFC-Hopping, where access to an SAP system is made via such an extensively authorised RFC connection.
Setting the confidentiality or encryption markers in the SEND_EMAIL_FOR_USER method affects the display of the e-mail in Business Communication Services Administration (transaction SCOT).