Thumb rule for assigning auth values after t-code addition to a role

[Former Member]

Hello everyone,

Could you please share your expertise on this. When a transaction is added to (the menu of )a role in PFCG, it automatically pulls in its corresponding authorization objects. So my question is what values should be given to these newly pulled in auth objects. Is there any guideline to be followed? Any disucssion would be greatly appreciated. Thanks a lot!

[Former Member]

Hello Sridhar,

This is totally governed by user and business requirements plus some standard practices.. NO thumb rule exists as such. In lot of cases for fields like activty these values get auto populated as per the values maintained in Su24. You can consult with yor functional consultants for filling in values for functional authorizations. They are the best people for this.For Basis and ABAP workbench transactions you need to take a call. For example for auth object S_DEVELOP you may give 01 and 02 in development systems but in production you should give only 03.

Regards.

Ruchit.

[manohar_kappala2]

Hi Sridhar,

Its not a one fits all approach.

But a general approach could be u add values based on the what the role is supposed to do.

for example for the activity field u would give 03, 08 for a display role;

01 for create role and 02 for change roles.

But like i said if you consider the HR the activity field is called authorization level there and the values are different for them like M,R,W.

best way is to give values which u are sure of and then trace for the extra values u require to add.

In addition to all these u need to add org fields as per the roles requirement.

Hope this answer ur query to a certain extent

Manohar

[Former Member]

On thing you should do is look at values in other roles in the same area, this is largely dependant on the way SAP is implemented in your company.

As an example if document type comes up look at other roels and never give STAR (*) when ohter roles are limited, then always consult the process experts.

In a good team they should have provided you up front with the fields and values the TRX shuld be restricted on. It should be a standard paragraph in the change documents based upon which you are requested to add teh TRX to a role! The security implications are owned by te process consultants, security consultants should ONLY be bothered by the technical way of translation of the request.

[koehntopp]

There really is no general rule.

There are two things you need to prepare to work on authorizations:

1. A list of critical authorization objects, such as S_DEVELOP, S_RFC and the like. In every role that you touch, these need to be managed properly. If you find that the default values in PFCG are not according to your policy, change them in SU24

2. A list of authorization values that you have determined are necessary for control purposes, i.e. cost centers and other org values. These need to be set according to the desird usage of the role.

Oh, there is ONE general rule: DO maintain SU24, i.e. manage what gets into PFCG in the first place. Make sure it's what your security design requires.

Hope that helps,

Frank.

[Former Member]

Thanks a lot,everybody! It was very helpful.