Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SAP R/3 : How to make a particular master role non-editable ?

Former Member
0 Kudos

Hi.

My knowledge on Security of SAP is limited.

And while am reviewing a revamp of the existing roles of a new project on finance module.

I find that there are a few instances wherein,

there are master roles

- under which there are hundreds of derived roles.

And i find that each derived role is maintained subsequently. And independently. Thereafter.

May be the Master role was created some 6 years back. And new derived roles have been added over a period of time.

But maintained independently. 

My understanding is that,

In a SAP Master Role you maintain all authorisation.

And in derived roles which are created under master roles, you generally maintain USERS.

So any change you do on the authorisation is done on the master role.  Which gets reflected to all derived roles.

But there would be requirements wherein restrictions would be required to be given on derived roles.

So that there is proper segregation of duties on authorisation.

While i tried to review and understand the entire logic on the existing system,

the entire authorisation concept is built upon OU, org unit,

and all authorisations are maintained indirectly, based on postion of an employee, which is unique, (hire to retire)

Now they have branced over different countries.

And want to have a re-look on security of the existing system.

While reviewing all the roles on the existing set up which is on ECC 6.0 with oracle 10g,

So first thing i saw is that One single Fund management Master role.

Has some 153 derived roles.

And all derived roles are maintained independently.

Looking at this, I felt a bit uncomfortable.

Here i see a scenario where somebody mistakenly,

if they click on the master role and say percolate to derived role.

The entire existing will get shaken up. Which i dont want to happen even by mistake.

So am wondering if i could make any particular Master role to be non-editable.

or can i make that button of Percolate to derived roles - hidden from master role.

I do not know how internally things work within SAP.

I do not want any user - to touch any particular Master roles, which i decide to be non-editable.

Including BASIS users, it should give not authorised and ask for special login.

Is it really possible to do that ?

At a later date, if there is a requirement to add any derived role, under that master, let the system ask for permission.

Various reads on authorisation objects on SAP,

does not really HELP me understand as to

whether we could do  this for ANY SINGLE Master role and make it non-editable or make the button to percolate to all derived roles to be greyed out,

BECAUSE it has many derived roles under it.  Which should not be disturbed.

My question might sound ridiculous, but if anyone could guide me as to how to address this scenario.

S_USER_AUT - how to use this for the above ?

Thanks

indu

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Indu,

In SAP Security, both Master and derived roles need to be editable for different purposes (master role for adding authorizations/tcodes & derived primarily for organizational values). If any of these roles is made unmodifiable, it might lead to greater issues in future assuming that your system will need to undergo some change or the other over a period of time.

Stricter change management and QA methodologies are the only safe & long term solutions. In case you have a hugh security team &  can afford to limit maintainence access of the entire set of parent-derived roles to only a group of experienced resources, you might as well try utilizing S_USER_AGR object for implementing the segregation. Just my 2 cents!

Thanks

Sandipan

6 REPLIES 6

Former Member
0 Kudos

Hi,

It is possible to make the Master roles not to be edited by eveyone. You can define restrictions on PFCG based on role names. Using authorization object S_USER_AGR you can restrict or grant access to roles in PFCG based on role names. You can put other restrictions also like they can only view the roles etc...You can also use wild cards like ZGLOBAL* or ranges A* to D*

Master - Derive role concept:

All the authorizations (T-Codes, Autho objects) are maintained in master role and pushed to derived roles. Only Org-levels are maintained in the derived roles. The advantage is that we maintain only one role for all the org-units. A derived role assined to a user will have access to data with in the Org Unit. You can not make authorization changes except modification to Org levels in the derived roles.

Your scenario looks typical to me. Any trained security adminster should be able to maintain these role carefully. A proper change management in your landscape would secure the changes more.

Regards,

Ajesh.

0 Kudos

Thanks Ajesh. I do agree that every customer has a particular need and things are maintained acc to one's requirement.

But i see independent auth maintained in derived roles.

And not everywhere company code is maintained. REstrictions are on different auth objects and it still works absolutely fine. I do not know whether that is normal to be that way. That is why i felt, that if there is a mistaken click on Master, the entire derived role will get shaken up completely. Because they are living as independent entities with added restrictions in each. Whereas the master has *  in those fields. And new derived roles are created based on the existing derived roles as per the change management followed. And it works absolutely fine. .

But - Yes, the request and idea of the customer now is to re-define / revisit security and change management - per se. So as to be able to secure the changes more appropriately, so that accidententally nothing happens. And i dont see any restrictions on any Master Role to be non editable. Thats what scared me while i was reviewing the system.

Ok thanks, let me test this and see whether applying the restrictions on Master to be read only , still allows derived roles to be created under that, and then whether that allows the derived role to be maintained independently.

And thereby making the Master role more secure than at present. I shall test this.

thanks again.

regards

indu

0 Kudos

Hi Indumathy,

The current security design of the customer looks good to me from what you said. Not only company codes, but also plants, authorization groups, plan versions... will be maintained in the derived roles.

Things you may want to stress while reviewing:

1. Strict change management procedures with right approvers, testing....

2. You may have different change procedures for Master and derived roles.

3. Master role assignment to end users ( generally not assigned to end users)

4. Good Security Resources ( If you dont have this all the above may go in vain )

All the best !!

Regards,

Ajesh.

Former Member
0 Kudos

Hi Indu,

In SAP Security, both Master and derived roles need to be editable for different purposes (master role for adding authorizations/tcodes & derived primarily for organizational values). If any of these roles is made unmodifiable, it might lead to greater issues in future assuming that your system will need to undergo some change or the other over a period of time.

Stricter change management and QA methodologies are the only safe & long term solutions. In case you have a hugh security team &  can afford to limit maintainence access of the entire set of parent-derived roles to only a group of experienced resources, you might as well try utilizing S_USER_AGR object for implementing the segregation. Just my 2 cents!

Thanks

Sandipan

0 Kudos

Hi Sandipan.

Good morning and thank you very much.

This was exactly my doubt. And wanted clarity.

Because i was wondering why would a system like SAP allow a role to be edited if it is not supposed to be so. And secondly even if i were to make something non-editable, how would the system allow something below that to be editable, if the new entity is below that structure which is set to be non-editable.

These two questions were a puzzle to me.

Agree stricter change management & QA methodologies implemented.

Thanks.

@Ajesh : thanks to you too. 

Kind regards

indu

0 Kudos

Hi.

the whole doubt came because. when you have objects to be maintained at org unit level for any derived role whether it is co code, or plant or whatever, then maintaining any authorisation is not a problem.

however, when you are doing a manual entry - say release code

WHICH is not maintained at the org unit level

BUT independently in derived roles manually changed and maintained.

Then if by chance anybody changes the master and derived, the whole thing would go.

I checked it. And it does get disturbed. But when it is maintained at org unit level. It takes it from there. And it remains.

And am not seeing any option to add any object at that org unit level to do this restriction.

Thanks

indu