Analyzing the quality of the authorization concept - Part 1
Authorization object documentation
Now maintain the permissions and organisation levels. If possible, use organisational level values in the note, which you can find well in other numbers later on, i.e. about 9999 or 1234. After generating and saving the role, you will be returned to eCATT. There you will be asked if you want to accept the data and confirm with Yes. You have now successfully recorded the blueprint. Now the slightly trickier part follows: The identification of the values to be changed at mass execution. In the editor of your test configuration, the record you created is located at the bottom of the text box. We can now execute the test script en masse with any input. We need a test configuration for this. In the example Z_ROLLOUT_STAMMDATEN, enter a corresponding name and click the Create Object button. On the Attribute tab, specify a general description and component. On the Configuration tab, select the test script you created earlier in the corresponding field. Then click the Variants tab. The variants are the input in our script. Since we do not know the format in which eCATT needs the input values, it is helpful to download it first. To do this, select External Variants/Path and click Download Variants. A text file is now created under the appropriate path, containing the desired format with the input parameters. Open the data with Microsoft Excel and set your target value list. To do so, delete the line *ECATTDEFAULT. In the VARIANT column, you can simply use a sequential numbering. Save the file in text format, not in any Excel format.
Manual authorization profile - To minimize the editing effort when using manual authorization profiles, you usually do not enter individual authorizations in the user master record, but authorizations combined into authorization profiles. Changes to access rights take effect for all users whose user master record contains the profile the next time they log on to the system. Users who have already logged on are therefore not initially affected by changes.
Set Configuration Validation
SAP Note 1720401 extends the SU10 transaction (mass maintenance of users) with the previously missing option to select users by login date and password changes. The notice adds these features to the RSUSR200 report. This report can also be executed directly using the transaction SU10 and the corresponding permission. After the hint has been inserted, the transaction SU10 will be expanded to include the login data button.
You can use the BAdI SMIME_EMAIL of the SMIME extension spot and implement the CERTIFICATE_RETRIEVAL and CERTIFICATE_SELECTION methods according to your requirements. This BAdI is called whenever an encrypted e-mail is sent. An extension allows you to search for a valid certificate at run time (for example, the one with the longest validity) to the recipient's email address in a source you defined. In the default implementation, the BAdI searches for the certificate in the Trust Manager's address book. For details on the availability of BAdIs, see SAP Note 1835509.
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.
This improves basic management of your existing security concept and protects you against external and internal intrusions.
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
Safeguard measures: In all systems (except for client 000 due to upgrade features), set DDIC to the System user type.