SAP Authorizations Note the effect of user types on password rules - SAP Corner

Direkt zum Seiteninhalt
Note the effect of user types on password rules
Sustainably protect your data treasures with the right authorization management
Another important authorization object for background processing is the object S_BTCH_NAM, which allows a user to run the steps of a job under another user (see SM36 -> Edit step). Here, a name other than the user's own can be entered in the user field of a step. The prerequisite is that the job scheduler has an authorization for the object S_BTCH_NAM, which contains the name of the step user, and that the step user exists in the same client as the job scheduler itself. From 4.6C: The step user must be of type Dialog, Service, System or Communication.

Authorizations are used to map the organizational structure, business processes and separation of functions. Therefore, they control the access options of users in the SAP system. The security of business data depends directly on the authorizations assigned. For this reason, the assignment of authorizations must be well planned and executed in order to achieve the desired security.
AUTHORIZATIONS FOR BATCH PROCESSING IN THE SAP NETWEAVER AND S/4HANA ENVIRONMENT
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").

The basic idea of the approach described below is to evaluate the previous usage behaviour (reverse engineering) for the definition of the required permissions. In the first step, you configure the retention time of usage data, because each SAP system logs the calls to bootable applications. This way, not only the user, at what time, what transaction, but also the user, which function block was called. These data are then condensed into daily, weekly and monthly aggregates and stored for a specified period. This statistical usage data is originally intended for performance analysis; You can also use them to determine the permissions you need. We described the configuration of the retention time of the statistical usage data in Tip 26, "Use usage data for role definition". Please also refer to our explanations on the involvement of your organisation's co-determination body in the storage and use of the statistical usage data. In addition to the settings described in Tip 26, you should also adjust the retention time for the RFC Client Profile (WO), RFC Client Destination Profile (WP), RFC Server Profile (WQ), and RFC Server Destination Profile (WR) task types using the SWNCCOLLPARREO Care View.

The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".

If a user is assigned SAP_ALL, he has all permissions in an ABAP system.

At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.


If roles cannot be locked, the job release fails.
SAP Corner
Zurück zum Seiteninhalt