SAP Authorizations Communication User

Direkt zum Seiteninhalt
Communication User
SAP Data Analytics
For even more extensive operations on jobs, there must be an authorization for object S_BTCH_ADM, in which the field BTCADMIN (identifier for the batch administrator) has the value 'Y'. This allows cross-client operations on any job. S_BTCH_ADM with value 'Y' thus also contains the objects S_BTCH_JOB action * and S_BTCH_NAM and S_BTCH_NA1 with user/program = *. Therefore, this is a very critical authorization because it allows an identity change. With the changes mentioned in note 1702113, the S_BTCH_ADM object can be used to restrict the authorization assignment more precisely.

Typically, users access a table's data through applications rather than directly. If so, you should take precautions and restrict access to sensitive data. End users typically do not access table-level data directly, but the data is displayed in business applications and their display is restricted in context by means of entitlement checks. However, there are cases where generic access to tables via the SE16, SE16N, SM30, SM31 or SM34 transaction is required for administrators, key users, verifiers, etc. For example, a verifier should have read access to all customising tables. However, you do not want to display security-related tables. Key users should be able to access certain reports regularly, but only read information relevant to their work. There are several ways to restrict access to tables by using table tools. This means that users can only access tables or table contents that they want to see. However, we would like to point out that the granting of permissions for these tools in the production environment is considered to be critical to security, since it is very easy to allow access to large amounts of sensitive data in the case of erroneous or excessive permissions. Therefore, only apply these permissions in a restricted way.
Maintain derived roles
Service users are used for multi-person anonymous access, such as Web services. This type of user is also dialogical, i.e. it can log on to the SAP system via SAP GUI. With a service user, multiple logins are always possible, and password modification rules do not work. This behaviour has changed with the introduction of security policy. Because previously all password rules for the service user were invalid, and now the rules for the contents of the passwords also apply to the service user (see Tip 5, "Defining User Security Policy" for details on security policy). The password of a service user always has the status Productive and can only be changed by the user administrator.

However, a full SAP security audit does not end here. In addition, the auditor examines whether the four important concepts of SAP Security, namely the data ownership concept, the proprietary development concept, the authorization concept and the emergency user concept, meet the requirements. Each of them should represent a fully formulated document that, on the one hand, contains all the target specifications for the respective topic and, on the other hand, is consistent with the actual state found during the audit.

Assigning a role for a limited period of time is done in seconds with "Shortcut for SAP systems" and allows you to quickly continue your go-live.

SAP Basis is the foundation of any SAP system. You can find a lot of useful information about it on this page: www.sap-corner.de.


Do you not want to use SAP's standard password creation rules, but rather make your own password requirements for your users? Do you need to implement internal or external security requirements, such as audit requirements? You do not want to allow certain words as passwords, exclude certain special characters or change the formats of passwords generated by the SAP system? In the following we give you an overview of the possible characters, the existing profile parameters and the customising settings for passwords.

To store all the information on the subject of SAP - and others - in a knowledge database, Scribble Papers is suitable.


There are approximately 40,000 RFC-enabled function blocks in an ERP system; Usually no more than a few hundred of them are used.
Zurück zum Seiteninhalt