Basic administration
User Interface Client Permissions
If you use change request management in SAP Solution Manager, you can use the system recommendations in an integrated way. To do this, create an amendment in the system recommendations for the SAP hints to be implemented. To access the system recommendations, you must have permission for the SM_FUNCS object (ACTVT = 03; SM_APPL = SYSTEM_ REC; SM_FUNC = , such as SECURITY).
You must enable a role that you have created as a Design-Time object in the Design Time Repository before it can be associated with a user. To do this, use Project Explorer to select the role you want to enable and select Team > Activate from the shortcut menu. This will create a runtime object of this selected SAP HANA role. This object is also understood as a catalogue object and is incorporated in the Roles branch in the corresponding SAP HANA system.
Authorization Analysis
For a long time, SAP authorization consultants and ABAP developers have disagreed on how to implement authorization object characteristics in the coding. There are two positions: On the one hand, consultants advise never to test for the signal word DUMMY, the constant space or the literal ' '. These tests only superficially check for the existence of an authorization object and do not react to settings in the field specification in the profile of the roles. Moreover, the literal ' ' is then authorized because it is displayed in the transaction STAUTHTRACE. On the other hand, there are situations where development uses these superficial tests to save the user time and the machine resources. If the program determines early on that the user does not have the necessary objects in the user buffer, it may abort before the first SELECT and issue an appropriate error message. Both positions contain a kernel of truth. Let's look at the effects of different programming on a simplified example. The role(s) have only the authorization object S_DEVELOP with the field value DEVCLASS "Z*".
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").
Secure your go-live additionally with "Shortcut for SAP systems". You can assign necessary SAP authorizations quickly and easily directly in the system.
The website www.sap-corner.de offers a lot of useful information about SAP authorizations.
The procedure for this is described in detail in our Tip 39, "Maintain suggestion values by using trace evaluations".
In any case, check the Reset Index box in the SUIM_CTRL_CHG_IDX report!