This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

Tag: security

HowTo: Hide SAP tables including USR02

Within an SAP system, the user account passwords are hashed and stored in the SAP schema table USR02.
If the SAP system users have access to transaction SE16, then it’s possible for them to view the USR02 table by default.

This would present the user with the opportunity of seeing the password hash values.

It would be possible to spot a commonly used password hash and provided the user knows the actual password text that generated the hash, could use it to log in as a different SAP user, maybe with higher privileges.

More importantly, if the user manages to modify the table through transaction SM30, they could set their own hashes.

It is better to create a new authorisation group for the USR02 table, then exclude this specific auth group from the user roles via auth object S_TABU_DIS and setting the “Authorization Group” field.

An example would be to create a new authorisation group “ZZND” (zz no display) in transaction SE54.
Then, still in SE54, assign all the tables you do not wish anyone to see, to the new auth group.

Use transaction PFCG to edit your roles and change authorisation S_TABU_DIS, so that the field “Authorization Group” is set to a range “$*” to “ZY*” (it excludes ZZ*):


The next time the users try to access the table, they will receive a no authorization prompt in SE16.

UPDATE 30/05/2014: The post above was based on R/3 4.7.  Later releases may have an SC auth group already defined with the USR* tables, plus others, already defined.  You may still wish to create your own ZZND auth group to ensure continuity across upgrades and for your own standardisation practices if you must customise the list of tables in the auth group.  Thanks Matt.

Controlling FUGR Access

If you have a super user role in your production system, it’s quite possible that use of the SUPRN_INS_OR_DEL_PROFILE or BAPI_USER_PROFILES_ASSIGN function modules could be used from SE37 to give SAP_ALL and then proceed to get around other restrictions.
Since SUIM relies upon S_DEVELOP and activity 16, you can’t just remove it unless you leave the admins to find their own way to the underlying transactions.
Instead, you could lock down the S_DEVELOP authorisation object by removing access to the specific function group (FUGR).
When editing the authorisations of a role, set one of the S_DEVELOP authorisation objects to exclude FUGR (and DEBUG):
Activity = 03 & 16 (Display & Execute)
Package = *
Object Type =
4              to DE
DEVC     to FU
FUGS     to Z
Z              to $TM
Then add another S_DEVELOP authorisation object “MANUALLY”.
Set this to exclude the SUPR, SUPRN and SU_USER function groups:
Activity = 03 & 16 (Display & Execute)
Package = *
Object Name =
0              to SUNI
SURI      to SURI-SU_UPGTOOLS
SU_USER_GRP_SURFACE to Z*
Z*           to $*
Object Type = FUGR

SAP_ALL modified role

Have you got a SAP Development system where the developers insist they have SAP_ALL, but you know this is just wrong.

Well, here’s a neat solution that removes certain authorisations like user admin in SU01 and adjusting auditing (SM19), RFC admin (SM59) etc.

Using transaction PFCG, create a new single role.
Add a description and save the role.
On the Authorisations tab generate a new profile and then edit the authorisations “Change Authorization Data“.
Do not select any Templates.
From the “Authorizations” screen, select “Edit -> Insert Authorization(s) -> from profile…“.
On the popup, enter profile “SAP_ALL”.

Now adjust the profile as required.
I usually adjust the following authorisation objects:

S_ADMI_FCD – BTCH, FONT, SM21, SP01
S_OSS1_CTL – 16
S_USER_AGR – 03, 08
S_USER_AUT – 03, 08
S_USER_GRP – 03, 08
S_USER_OBJ – [NO AUTH]
S_USER_PRO – 03, 08
S_USER_SAS – [NO AUTH]
S_USER_SYS – 03
s_XMB_ACT – [DEPENDS ON USAGE OF XI/PI]
S_TRANSPRT – [CREATE TASKS, SEPARATE ROLE FOR CREATE TRANSPORTS]
S_IDOCPART – 03
S_IDOCPORT – 03
S_SCD0 – 08, 12

You can then save and assign the role to the developers.

Values for SAP Auth Objects F_REGU_BUK and F_REGU_KOA

Whilst configuring some new read-only SAP roles for FICO access, you may be struggling to find the descriptions for the actions for authorisation objects F_REGU_BUK and F_REGU_KOA and the values for FBTCH (Action for Automatic Procedure).
The descriptions do not appear in the usual auth object display screens.

Within the SAP GUI, if you go into transaction F110, then from the menu select “Environment -> Authorizations”, a popup will be displayed with the following legend:

KeyAction
02Edit parameters
03Display parameters
11Execute proposal
12Edit proposal
13Display proposal
14Delete proposal
15Create payment medium proposal
21Execute payment run
23Display payment run
24Delete payment run payment dat
25Create payment media of paymen
26Delete payment orders of payme
31Print payment medium manually

For a read-only role, I would recommend only actions 03,13,23 and possibly 31 (in case the electronic BACS payment method breaks).

You may also be interested in:

Oracle 11gR2, KEWBMBTA: Maintain BSLN Thresholds failed

If you tighten up the security in an Oracle 11gR2 database, you may be tempted to remove access to the DBMS_OBFUSCATION_TOOLKIT package from PUBLIC (“revoke execute on DBMS_OBFUSCATION_TOOLKIT from PUBLIC;“).

This causes an issue, seen in 11gR2 11.2.0.3.
The error was visible in the user traces:

“*** 2012-09-11 20:00:43.692
KEWBMBTA: Maintain BSLN Thresholds failed, check for details.”

This was tracked to an invalid package body DBSNMP.BSLN.

SQL> alter package DBSNMP.BSLN compile body;

Warning: Package Body altered with compilation errors.

SQL> show errors
Errors for PACKAGE BODY DBSNMP.BSLN:

LINE/COL ERROR
-------- -----------------------------------------------------------------
88/5 PL/SQL: Statement ignored
88/19 PLS-00201: identifier 'DBMS_OBFUSCATION_TOOLKIT' must be declared
200/7 PL/SQL: Statement ignored
200/21 PLS-00201: identifier 'DBMS_OBFUSCATION_TOOLKIT' must be declared
241/7 PL/SQL: Statement ignored
242/8 PLS-00201: identifier 'DBMS_OBFUSCATION_TOOLKIT' must be declared
1332/7 PL/SQL: Statement ignored
1332/21 PLS-00201: identifier 'DBMS_OBFUSCATION_TOOLKIT' must be declared

Re-granting access to the DBMS_OBFUSCATION_TOOLKIT package to the PUBLIC user, fixes the issue again:

SQL> connect / as sysdba

Connected.

SQL> grant execute on DBMS_OBFUSCATION_TOOLKIT to PUBLIC;
Grant succeeded.

SQL> alter package DBSNMP.BSLN compile body;

Package body altered.