Centrally view user favourites
Archive change document management for user and permission management
The specific SAP_NEW authorization object imprints are provided via the SAP_BASIS component. Therefore, an SAP_NEW profile is always bound to a specific base release. Proceed as follows: With the transaction SU02, you remove all old, individual profiles from the SAP_NEW composite profile, including the profile that belongs to the start release of your upgrade. Now assign the reduced SAP_NEW permission profile to all users in the upgrade preparation system, ensuring that all users can work as usual. This step can be omitted if you are following another method to identify missing permissions. Now check all permissions in all remaining profiles within the SAP_NEW summary profile that have a higher release level than the SAP_BASIS upgrade start release. Map all required permissions to all productive roles in your permission concept. You can do this for each intermediate release individually. The next step is to adjust the permissions in your productively used roles in the PFCG transaction, and then remove the corresponding permissions from the SAP_NEW profile using the SU02 transaction. Repeat steps 3 through 4 until the SAP_NEW permission profile is empty. Work in a development system during the role adjustment phase and transport the adjustments made to your eligibility roles to your quality assurance system. After successful acceptance test, you transport them to the production system. Now you can remove the SAP_NEW profile from all users. You can then proceed with role follow-up as part of the release change in the SU25 transaction (see also Tip 43, "Customise Permissions After an Upgrade").
RFC connections are interfaces for many local and global system processes, but also a security-relevant source of errors for many companies. The RFC interfaces and associated system users often have too strong authorizations and can quickly be misused by unauthorized persons to view sensitive company data. It is therefore important to always keep these system connections in the focus of global monitoring and to check which RFC destinations lead where and what they do. For this purpose there is the program RSRFCCHK which allows you to perform specific tests for your RFC system landscape. On the one hand the content of the RFCDES table is checked and on the other hand the corresponding user properties of the system users are displayed as an overview. Consequently, important parameters such as the target machine, the client, the background user or also the password property can be checked in an overview.
Implementing the authorization concept in the FIORI interface
To access business objects or execute SAP transactions, a user needs appropriate authorizations, since business objects or transactions are protected by authorization objects with multiple authorization fields. Authorizations represent instances of generic authorization objects and are defined depending on the employee's activity and responsibilities. The authorizations are combined in an authorization profile (Generated profile), which is assigned to a role. User administrators then assign the appropriate roles (single role or composite role) via the user master record so that the user can use the appropriate transactions for his or her tasks.
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 the SU53 you get the entry of the user that is stored there, and this may be old. So it is better to let the user himself display the authorization error via the menu. Maybe you create a small docu for all your users how to display the error and where to send it, so a "Cooking Recipe: How To...". In the SU53 error excerpt, the first thing that is displayed is the authorization that the user is missing. So this object has to be analyzed. In the further part of the error message, the permissions assigned to the user are displayed. This information can be used to classify the user with his role set, where he belongs etc. Finally, in our case 1, we now have the missing authorization and must now clarify whether the user should receive this authorization or not. In addition the specialist department must be contacted, which has to decide whether the user receives the permission! It can happen that the problem reported by the user is not an authorization problem at all. Then the last authorization error is displayed in the SU53 area, which is not the cause of the error at all. Therefore, it is always good to have a screen image of the actual error message sent to you as well. It is not uncommon for developers to issue an authorization error of the type "No authorization for..." from their programs, but they have not checked this with a standard authorization check at all, so that the error is not an actual authorization error.
For the assignment of existing roles, regular authorization workflows require a certain minimum of turnaround time, and not every approver is available at every go-live. With "Shortcut for SAP systems" you have options to assign urgently needed authorizations anyway and to additionally secure your go-live.
For accesses by verifier users (from the table TPCUSERN), the selection parameters of the invoked transaction are logged in the application log and can be evaluated with the report CA_TAXLOG.
If you have more than one client to maintain roles, you must also do this in the other client.