How do we set the Authorizations in Role Creation?

[former_member695529]

Hello,

I am new to Security and in need of help!

I have this scenario and need your expertise idea and guidance.

1) Initial requirement: (Solved)

• Please create an user administration role.
  Users having this role should not be able to add roles to an user.

So far, I have created a single role "ZES_VAL_USER_ADMIN" using the TCD PFCG.

To this role, I have assigned the transaction SU01 - MAINTAIN USERS. By assigning this role, Users could access SU01 but were not able to add Roles to an user.

2) New Requirement:

Now, I need to modify the authorizations of this role "ZES_VAL_USER_ADMIN" and generate the profile, so that the users now should be able to Assign Roles to users.

I tried giving the S_USER_GRP Activities with the "create and assign" options, but still, the users with this role are not able to assign roles in SU01.

Please see the attached snapshots.

Error Message:

Please help!

Thanks in advance,

Debugger

[Colleen]

Hi

What value did you enter for CLASS? That relates to user group on su01 login data tab

Being new to security you may want to read up on authorisation concepts and learn about transactions SU53 and ST01

In pfcg traffic lights are there to help - green is good as it means you completely maintain the authorisation

Regards

Colleen

[former_member695529]

Hi Colleen,

Thanks for your reply.

Yes, I will look into more about transactions SU53 and ST01.

I understand the concept of traffic lights as they help in maintaining role consistency.

I have created and updated roles before, and they work as per the requirements.

In this case, I had given " * " for CLASS.

I referred to Table TSTCA but frankly, couldn't make much sense of it.

Thanks,

Debugger

[karthikeyan_natarajan4]

Hi Mitchel,

When you see the error screen " you are not authorized to assign role" straight away run the tcode SU53(you should assign SU53 to that user), see the output screen which tells about the missing authorization. Main purpose of SU53 is to find the last missing authorization for a user.

If still SU53 can't provide you the solution, you start activating the authorization trace in ST01 for that particular user and see the result log. Deactivate the trace as soon as you find the cause of missing authorization. Keeping trace activated leads to disk size full.

Please go through this page to understand how to activate authorization check using ST01

http://wiki.scn.sap.com/wiki/display/PLM/Authorization+Trace+in+transaction+ST01

regards

kartik

[Colleen]

Hi Mitchel

Take care with SU53 and ST01. Depending on your SP there is also STAUTHTRACE. You will want to read up on these transactions and search SCN as there were improvements to SU53. Please take care on interpreting a last failed authorisation check as there can be misleading items. For example, if an end user fails on S_DEVELOP it is unlikely that is the root cause. To figure out what counts it's a mixture of training, research, trial/error and just plain common sense.

For the TSTCA comment this relates back to SE93 definition. When a user executes a transaction there are two checks that take place to get to the initial screen (unless the program has additional). The first is the S_TCODE for the transaction. The second is the SE93 additional check which is the values stored in TSTCT. This creates flexibility if a transaction is a "cockpit-style" where one transaction code can cover create, change, display, delete, etc (e.g FS00 transaction).

In the example of SU01, the user would require the S_TCODE to SU01 as well as the TSTCA entry of S_USER_GRP with any value (not specific activities were mentioned) and then any other authorisations depending on what you level of access you want to grant.

I recommend, if security is going to become an additional responsibility, that you attend the ADM940 training course. Adding authorisations to PFCG is a easy to do (press a bunch of buttons) but the how you maintain PFCG has impacts to managing your role build long terms, including support pack and upgrades. For example, understanding the connection between SU24 and PFCG for standard, maintained and changed authorisations.

Good luck with your venture into security.

Regards

Colleen

[Former Member]

Hi Mitchel,

As mentioned above, S_USER_AGR with the relevant authorization field content will let you have the required authorizations to assign roles to the user*

Note: To access (user*: change/maintain) the user master record, you need to have the access to that user group first, which you can have from S_USER_GRP.

These will definitely meet your needs. So, kindly check and do let us know for any more clarifications.

BR,

Ameet Kumar

[former_member695529]

Hi Karthikeyan,

Thanks for your help.

Your suggestion did help but I have a little problem here.

Every time the system restricts an action(due to missing authorization/activities), say the action is "assigning roles in SU01", what I observed is, at a time, SU53 gives only one of the OBJTYP where the ACTVT has gone wrong. Once I assign the required ACTVT code for "assigning roles in SU01", and then try to assign roles in SU01, system still gives an error and when I check SU53, it gives the new missing ACTVT code.. Surely if I keep assigning all of the ACTVT codes that SU53 suggests, the problem will be solved. But this is very time taking and was wondering if I could get all the missing ACTVT codes at one shot..

Please advise..

Thanks in advance,

Debugger

[karthikeyan_natarajan4]

Hi Debugger,

I believe that's not possible, because authorization checks will be carried on each step, not for whole activity and system doesn't guess our transaction too. Keep on doing so that you will be clear at the end. But do remember you can ask your functional head regarding the task processed for that ID. So that you can assign it at once. For eg. Functional head say user AAA has to create, delete, change in that case you can assign activity 01 02 and 03 at once.

regards

kartik

[former_member695529]

Oh I see.. This problem pitches in when there isn't a solid requirement, guess that's the only option then..

Thanks again

Regards,

Debugger

[Former Member]

Hi

Kindly follow the procedures mentioned above.

To change the user of a particular group, you need to have field contents ACTVT: 02, 22 maintained in your user buffer for the authorization object: S_USER_GRP.

But to change the role assignment of an user, you need to have the authorization object: S_USER_AGR with the required field contents

Once you run SU53/ST01, I am sure that you would get to see all the missing and required authorizations to solve the issue.

BR,

Ameet Kumar

[Former Member]

Run SU53 and find the missing authorisation.

[Former Member]

Isn't SU53 and ST01 are the two life savers for many Security Consultants who doesn't understand from where to start?

Unfortunately many consultant are just surviving because these t-codes come to Aid.

Mitchel,

To answer your question, there is one more help that SAP provides when you add a t-code through role menu. It's reads from tables USOBX_C and USOBT_C and populates possible SAP recommended auth objects which will be needed for a transaction (not necessarily always, but most of the time).

Which ones for SU01?? The answer is in the second screenshot you have provided.

S_USER_GRP will only allow you to control access on User Creation and modification of all the tabs except "Role" and "Profile"

For your role to enable access to role assignment, you need S_USER_AGR as well as S_USER_PRO (on and above S_USER_GRP.

The full requirement is not mentioned by you, however from what I understand:

S_USER_AGR

ACTVT = 02,03,08,22 should suffice

ACT_GROUP = * or Z*/Y* or specific role names (as per requirement)

S_USER_PRO (If you don't use this, generated profiles for roles will not be added to the user)

ACTVT = 02,03,08,22

ACT_GROUP = T* or * (please note * will enable the role to provide access to assign SAP Standard Profiles like SAP_ALL, SAP_NEW etc. So please check the requirement first).

[former_member185447]

Hello Mitchel

Try these two Authorization objects

S_USER_AGR which deals with Roles and

S_USER_PRO which deals with Profiles

Make sure you have activities 02,03 and 22

Regards

Deepak M

[madhusap]

To assign roles through SU01, SU10 or PFCG

S_USER_AGR with 02, 22 or 78

S_USER_GRP with 02,22

S_USER_PRO with 22

To create/maintain roles through PFCG

S_USER_AGR with 02, 22 ,64

S_USER_TCD with PFCG

S_USER_VAL with * [For changing activity field values]

So based on these values you can decide which one to keep and which one to remove in the security role you are creating.

Regards,

Madhu.

[former_member695529]

Thanks, this will surely come in handy

Regards,

Debugger

[Former Member]

Hi Debugger

Welcome to Security Team

Su53 tcode is like a magic wand for Sap Security.

As most of the people above gave you solution in finding missing authorization.

I am gonna give 2 small tips for you as a security consultant

1.End users should always have access to Su53, so that they can send missing auth screenshot to us (Security team). So a general role for SU53. if not we have ST01 (trace) to find out where exactly is the error.

2. Trace will not work for custom objects

Below are the values for return codes for TRACE

*The return code shows whether or not the authorization code was

successful. *

- *ST01 Return Code *

*0 *

Authorization check passed

*1 *

No Authorization

*2 *

Too many parameters for authorization check

*3 *

Object not contained in user buffer

*4 *

No profile contained in user buffer

*6 *

Authorization check incorrect

*7,8,9 *

Invalid user buffer

[Colleen]

2. Trace will not work for custom objects

why is that?

[Former Member]

Hi Colleen

This will help you

http://scn.sap.com/thread/1079987

[Colleen]

Hi Pavan

I looked at the article you referred me to...

Example: User Guest wrote:

So I think you need to make sure that the Custom Authorization Objects are properly checked in the Custom ABAP programs with the Authority Check Statement

Another example from

On the back-end ABAP system, developers can do a lot of creative and even strange stuff. They can even code successfull authority-checks to prevent access if they want to (as exceptions).
From what you have discribed, there are some undocumented or badly communicated techniques in your concept. But I might be wrong... 

I am still unsure how you have drawn the conclusion that custom objects will not appear in ST01. This article in the end referred to BW component security with RRSM.

A key message however, would be Custom authorisation objects will appear in ST01 if the developer had programmed correctly. If the developer doesn't use the authority-check syntax, the trace will not show the entry.

Regards

Colleen

[Former Member]

I completely agree with Colleen. Also would like to say, searching Internet for solutions doesn't always help. Carrying some basic concepts is always required.