Customise Permissions After Upgrade
Concept for in-house developments
You can now assign transactions to these roles. Experience has shown that roles should remain application-specific and that a distinction between book or investing, changing and reading roles is also useful. There will be regular transactions used in multiple roles. You should not overestimate the often demanded freedom of redundancy. However, for critical transactions or transactions that are involved in a functional separation conflict, it is recommended that they be kept in a separate role. In general, roles should not contain too many transactions; Smaller roles are easier to maintain and easier to derive. Also, assigning them does not quickly lead to the problem that users have too many permissions. If you keep the necessary functional separations in place, you have already prepared them as a takeaway.
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.
Role Management
A manual comparison of role texts in an SAP system landscape with ZBV is very annoying. You can also automate the sync. I'm sure you know this. When creating or maintaining users in the Central User Administration (ZBV), you must manually start the text matching each time before assigning PFCG roles to provide you with the latest PFCG role definitions. Managing a large system landscape with many systems in your ZBV - including development, test and production systems - the text comparison can take a while.
So much information... how can you keep it so that you can find it again when you need it? That's what Scribble Papers is great for.
After you have determined the data for the website, you must now generate the initial password and send it by e-mail and unlock the user if necessary. There are also different solutions - we describe a possible course of action. You can generate a password using the GENERATE_PWD import parameter of the BAPI BAPI_USER_CHANGE. The generated password is then set as the initial password and must be changed at the next login by the user. You must also set the PASSWORDX import parameter to display a password change. The generated password is returned using the export parameter GENERATED_PASSWORD. This is required if you want to call the BAPI BAPI_USER_CHANGE from a central system (e.g. from the ZBV) and send the relevant e-mail from that system. You should never save this password, but include it directly in your application in an email. Subsequently, you send this e-mail to the user whose e-mail address you can determine either directly in the SAP system (parameter ADDSMTP of BAPI_USER_GET_DETAIL) or within the scope of your web application (e.g. from the AD). Even if you find the email address in the AD, we advise you not to send the email from there. To avoid the password being unnecessarily transferred, it is better to initiate the despatch within your central SAPS system. In addition, we strongly advise you to send the emails encrypted with the initial passwords. To do this, the implementation of your self-service must set the encryption flag when creating the email. We describe details about the encryption of emails and an alternative sending of the initial password directly from the affected SAP system in Tip 98, "Encrypt emails".
"Shortcut for SAP systems" is a tool that enables the assignment of authorizations even if the IdM system fails.
During preparation, it is therefore necessary to check whether the process has been carried out in accordance with the internal specifications, but also in accordance with possible suggestions for optimization made by the auditor, and whether all the evidence is stored ready to hand for the auditor.
You can now define the user group as a mandatory field in the user master record by inserting the default user group in the USER_GRP_REQUIRED entry of the USR_CUST client-dependent table.