Customizing
Preventing sprawl with the workload monitor
Initial passwords for standard users are extremely risky because they are published. Make sure that this vulnerability does not exist in your system landscape. An SAP system is always shipped with certain standard users or they are automatically set up for the transport management system, for example. These default users use initial passwords that are well known. Close this vulnerability by changing the passwords and protecting the default users from unauthorised use. In this tip we will show you how you can clarify the status of your standard users' passwords and give you recommendations on the settings of your profile parameters.
In compliance with the minimum principle and the separation of functions, the roles used must be defined, along with specifications for their naming, structure and use. Close attention should also be paid to the application and allocation process in order to prevent authorization conflicts, which arise primarily as a result of employees' changing or expanding areas of responsibility.
ACCESS CONTROL | AUTHORIZATION MANAGEMENT FOR SAP®
If a release change occurs, the adjustment of permissions is also required as a rework. You will have already learned that this task can be very complex. Many innovations make this work easier and make the whole process more transparent. In the event of a release change, not only new applications are often added, but also new or modified authorization objects, permission checks, and, as a result, modified suggestion values. With the SU25 transaction, you can update the suggestion values step by step and then update all the affected roles. So far, however, the transaction has been a kind of black box for you. You have performed each step without seeing how your suggestion values or roles have changed. We will now show you how to use the new features of the SAP NetWeaver Application Server ABAP to increase transparency in upgrading suggestion values and mixing PFCG roles.
Do you also work in a complex system landscape where roles are decentralised? Then, inconsistencies can occur by transporting profiles from different systems to a target system. We'll show you how to prevent that. In the case of decentralised maintenance of eligibility roles, i.e. maintenance of roles in different systems or clients, there is a risk that the number sequences for the generation of eligibility profiles overlap. You can then generate profiles with the same name for different roles in different clients. As soon as you transport these eponymous permission profiles into a common target system, the profile will be overwritten by the newly imported profile and inconsistencies will arise. As a result, you may, for example, assign an ERP Permissions Role an SCM permission profile. This may result in a user assigned the ERP role not obtaining the required permissions or even too many permissions. You also have a problem if you want to use the permission profile to determine the source system and the client in which this profile was generated. This is not possible if the first and third characters of the SAP System ID (SID) and the number sequence for generating the permission profile match.
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.
are displayed, which can then be processed directly with a click.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
'*' stands for any number of additional characters (wild card) and '?' for any character.