Security Interesting

User Creation Date...

Table USR02 - GLTGV (field) is the date from when user is permitted to use the system.So let suppose if you created the User ID on 01/01/2011 and wants to allow him/her from03/01/2011 then user creation date would be 01/01/2011 but USR02-GLTGV holds the value03/01/2011 .Actually user creation date isUSR02 - ERDAT.

Locked value in USR02…

0: Not Locked

16: Mystery values

32: Locked by CUA

64: Locked by System administrator

128: Locked due to incorrect logons

192: user is locked by admin and user tries to logon with incorrect passwords and gets locked

What is the difference between USOBX_C and USOBT_C?

The table USOBX_C defines which authorization checks are to be performed within transaction and which not (despite authority- check command programmed). This table also determines which authorization checks are maintained in the Profile Generator.

The table USOBT_C defines for each transaction and for each authorization object which default values an authorization created from the authorization object should have in the Profile Generator.

Su22 vs. Su24

SU22 displays and updates the values in tables USOBT and USOBX, while SU24 does the same in tables USOBT_C and USOBX_C. The _C stands for Customer.

  The profile generator gets its data from the _C tables. In the USOBT and USOBX tables, the values are the SAP standard values as shown in SU24. With SU25 one can (initially) transfer the USOBT values to the USOBT_C table.

Restrict to particular tables in SE16

Suppose we have to create a Role that can only have Data Browser t code (SE16) with table USR02 andAGR_USERS Display ACCESS.

In SE16, only one authorization object (S_TABU_DIS) is check maintained in SU24.

Before that we have to check, what are the authorization group for those tables (USR02 and AGR_USERS)

So go to Data Browser (SE16) and Type Table TDDAT. It stores Table auth group.

Put table name USR02.So, we get SC is the auth group for the table USR02.And SS is the auth group for table AGR_USERS.

Now add transaction code SE16 to the newly created Role Z_TCS.Now go to authorization tab and fill the profile name and click CHANGE AUTHORIZATIONDATA.

Search S_TABU_DIS, change DICBERCLS (AUTH GROUP).Go to change (pencil Icon) to DICBERCLS field. And add those two AUTH GROUP (SC and SS).

User Buffer Problem

Suppose, Two user X and Y both have Role A(SU01D, SE16). User X is able to run the SU01D  but YIs not being able to Run the SU01D.

May be user comparison is not done properly for the user Y.

You can refresh the User Buffer (Logoff and Login )

User buffer can store maximum of 312Profile, it may be possible user (Y) has more than 312 Profiles. (Why 312 Profiles: Because user buffer is String buffer which can hold maximum 3750 characters. And a profile contains 12 character, so a user can hold maximum 3750/12 ~ 312 profile.)

Solutions: Please assign a reference User to user Y. And assigned Role A to the reference user, So Y can access Role A.

An user is assigned a certain ROLE. How to find ,how many tables a user can access in sap.

1. So at first we have to check which role contains those Authorization Objects. Go to SUIM and ROLE -> Roles by complex selection Criteria Select User as BIJOY and Authorization Object as S_TABU_DIS. You can select both Auth Objects.

2. As I got roles A and B which contains authorization objects as S_TABU_DIS.3. Now we have to find how many authorization groups are present in these roles.4. Go to SE 16(Data Browser) -> AGR_1251(table)5. Paste the Roles A and B. Also the authorization objects S_TABU_DIS.6. Here we got “SC”,”SS” authorization groups.7. Now we have to find how many tables are associated with this authorization groups.8. Go to SE16(Data Browser)->TDDAT(table)9. In cclass (field) enter “SC”,”SS” authorization groups, you will find out how many tables a user

can access.

AGR_1251: For a particular Role, the associated authorization object, authorization, authorization fields and its values.

How to assign Reference User to a Dialog User

Reference user is when a user gets his authorizations from another user ID. This can be practical for internet users. You need to be careful about this type of access, as it will not show up in your ordinary SUIM0 reports! Or AGR_USERS. Reference user is used only to assign additional authorizations. you cannot login by using reference user User type for general, non-person related users that allows the assignment of additional identical authorizations, such as for Internet users created with transactions SU01. You cannot log on to the system with a reference use.

To assign a reference user to a dialog user, specify it when maintaining the dialog user on the Roles tab page. In general, the application controls the assignment of reference users. This assignment is valid for all systems in a Central User Administration (CUA) landscape. If the assigned reference user does not exist in a CUA child system, the assignment is ignored.

There are two roles Z_Joy and Z_New

Z_NEW contains TCODE¶s of SM36 and SM59.

Z_JOY contains TCODE¶s of SE16, SU01D and SUIM

And we created a REFERENCE type user ZZOT0001.

Which has Z_JOY Role (SE16, SU01D and SUIM).

Now we create a new Dialog user ZZOT0002 and assign role Z_NEW to it.

And assign the REFERENCE user ZZOT0001 to Reference user field in the Roles tab.

Now login through ZZOT0002 user it only shows Z_NEW roles. (SM36 and SM 59).But when you execute SE16 it will execute with no authorization errors.  You should be very cautious when creating reference users.  If you do not implement the reference user concept, you can deactivate this field in accordance with SAP Note 330067.

We also recommend that you set the value for the Customizing switch REF_USER_CHECK in tablePRGN_CUST to ‘E’. This means that only users of type REFERENCE can then be assigned. Changing the Customizing switch affects only new assignments of reference users. Existing assignments are retained.

We further recommend that you place all reference users in one particularly secure user group to protect them from changes to assigned authorizations and deletion.

How to disable fields in a Transaction?

SHD0 – Maintain Transaction Variants.Transaction variants allow us to selectively mask certain fields in SAP transactions/screens. Though strictly not a security tool, transaction variants can have applications in security by helping to prevent users from updating fields which are not protected through authorization objects

Transaction Variants are created through the SHD0 t-code. The initial screen SHD0 is given below. To create a transaction variant we mention the name of the parent transaction, give a name of the variant and click the create button.

In our example below, we create a transaction variant ZSU01 for the very common SU01 t code. The transaction variant allows an administrator only to reset passwords and hides all other functions of SU01. Each transaction variant contains of one or more screen variants depending on the number of screens being called in the entire transaction flow. We don’t have to manually keep track of the screen variants when we are working with transaction variants. As we move from one screen to the next, SHD0 automatically creates and appends a new screen variant to the sequence.

On clicking the create button for ZSU01, we are taken to the standard SU01 screen. We enter a user name and click the change password button. A pop-up window appears with a list of the screen fields. This window contains the attributes of our first screen variant. It’s here where we enter a name of the screen variant and can selectively mark screen fields to invisible/output only/required, etc.

The screen variant window has a button for “Menu Functions” where we can selectively hide/de-activate menu items or toolbar buttons. Since our intention is to disable everything except password change options, we end up with below screen.

On clicking, the save and exit button we are taken to the overview screen for the transaction variant. As shown below, this screen gives the definition of the individual screen variants which form part of the transaction variant. On saving our entries, we are taken to the SHD0 initial screen which shows the transaction variant and the screen variants defined under it.

SHD0 provides a test button here we can check if the newly created transaction variants works as per our requirement. Once tested we create a new Z transaction (ZSU01) for the transaction variant by following the menu path Goto>Create Variant Transaction.

Once set up, this new transaction can be assigned to a user’s role just like a normal transaction. Executing, ZSU01 display a modified form of SU01 screen with all functions other than change password button is disabled.

Organizational LevelsBy Aninda, on November 6th, 2010

“Organizational Levels” (Org Levels) as opposed to authorization fields is another of the core concepts that we come across while creating roles in PFCG. We can access the organizational level values defined for a role by clicking the “org level” button in the main toolbar within PFCG.

In the role below, we see Org Levels like Company Code, Purchasing Org, Purchasing Group, Sales Org, Division, Plant, etc.

PFCG - Org Levels

In the expanded view of the authorization data in PFCG, the org levels defined earlier appear side-by-side with the authorization fields. In fact, all org levels are also authorization fields but not all auth fields are org levels. For example, the org level Plant appears as an authorization field in two objects, M_LFPL_ORG and M_MATE_WRK.  On the other hand the field Activity is not an org level. Once we maintain a particular value for an org level in a role, all authorization objects using the same org level as a field will automatically take the same value. It’s technically feasible to break an org level, so that for a particular object, its value is different from its defined org level value but this defeat a purpose of defining something as an org level.

Another difference between org levels and normal auth fields come to light while deriving a role from another master role. A normal auth field will be inherited by the child role with the same value as maintained in the parent but an org level can be maintained in the individual child roles.

PFCG - Org Levels vs Auth Fields

Organizational Levels in most cases are intrinsically linked to the enterprise structure of an organization and largely determined during the customizing steps for the SAP systems. The below screen-shot from the SPRO transaction shows the options for configuring different org levels like company code, controlling area, purchase org, sales org etc. So its not really the security administrator who defines the org levels. He can only use the existing org levels defined during functional configuration.

SPRO - Enterprise Structure

Its possible to change an authorization field to an org level for the purpose of security by executing the program PFCG_ORGFIELD_CREATE. However, since this program impacts all roles which contain the org field it should only be run after a thorough analysis of all impacted roles. Also certain auth fields like Activity can never be changed to an org level.