Background processing
Sustainably protect your data treasures with the right authorization management
Confirmation of the dialogue will immediately start the recording; They therefore end up in the PFCG transaction. We want to record the creation of a single role derived from a reference role. Complete the appropriate steps in the PFCG transaction and try to avoid unnecessary steps - every step you take will make your recording bigger and less cluttered. Enter the name of the derived role - we can influence it later when playing with eCATT - and specify the role. Now assign the reference role. Note that the PFCG transaction is actually executed, so the role is actually created in the system! In the SCC4 transaction, first check whether eCATT is allowed to run. Then start the SECATT transaction. As you get started, you can define and modify test scripts and test configurations. First, create a test script. Think of it as a blueprint or a flow rule for how to create new derived roles. The test script will contain your recording later. Give the script a talking name, such as Z_MASSENGERATION_DERIVATIVES. Then click the Create Object button. You will now go to the Attribute tab, where you specify the general frame data. Then click the Editor tab. Now it goes to the recording, in the eCATT language called patterns. Click the Pattern button and specify that you want to record the PFCG transaction by selecting the UIAncontrol and TCD (Record) settings. The system will propose to call the interface "PFCG_1"; You can simply confirm this.
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".
Organisationally restrict table editing permissions
Have you ever tried to manually track who among the users in your SAP system has critical authorizations? Depending on your level of knowledge and experience, this work can take a lot of time. If audits have also been announced, the pressure is particularly high. After all, it is difficult to fulfill all requirements regarding SAP authorizations manually.
Depending on the configuration of root data and processes, different permission checks can be relevant, so that it makes sense to adjust the proposed values. If custom applications have been created in the form of Z-transactions, Web-Dynpro applications, or external services, you must maintain suggestion values for these applications to avoid having manual permissions in the PFCG roles. You must ensure that custom applications are not always visible in the SU24 transaction. This is the case for TADIR services and external services. To learn how to make these services available for suggestion maintenance, see Tip 38, "Use the SU22 and SU24 transactions correctly.".
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
In transaction RZ11 you can easily and quickly check if the parameter is already set.
In the customising (transaction SPRO), you create them via the following path and then select the corresponding section.