Change authorization object in a derived role

[Former Member]

Hi Gurus,

What's happen if someone has added a new authorization object in a derived role?

He has only changed some derived role, not the parent role, he added manually a new value in the authorization field. The parent role didn't changed.

<u>Note:</u>The field was not an organizationnal field, it was S_DATASET.

What do you think about this ?

Thanks

Hery-zo

[Former Member]

I would not recommend this approach to maintaining derived roles since it sounds like you have some derived roles with S_DATASET and some without. It would be better - more efficient and consistent to have the auth object added to the parent role - which would then add it to the dervied roles when you regenerate. That being said if the auth object was added to all of the dervied roles - it would be fine since consistency is maintained - it is just not as efficient.

[Former Member]

I agree with JC. The whole idea of derived roles is that with the exception of org levels, they are identical to the parent. The next time a change is cascaded to the derived roles from the parent, then the manually added object will be overwritten.

[Former Member]

Agree with JC & Alex. Not a good practice.

[Former Member]

Many thanks guys,

So when he has changed the authorization object, all object in parent roles becomes in red color, so i think there is an impact to other derived role. Does it ?

We need to import the modification in production system, so i think that we need to create another parent role which include the necessary modification ( add manually S_DATASETand its values) and we will create a derived role from it before import them in production system.

Do you think its the best idea to correct it ?

[Former Member]

If the derived role was changed, then the parent role should remain unchanged. It may be that the parent role already had red values on the auth objects - they are red since values have not been maintained for them - this may have been intentional to help you see what values need to be maintained at the derived role level.

To correct I would add the value at the parent level with an auth object value and generate the derived roles.

[Former Member]

The suggested is the best approach, create a different parent role and derive the role from there.

If you change a derived role directly without changing from the parent role. everytime the parent role we be rederived all changes in derived roles directly will be overwritten.

[Former Member]

The problem is that many roles derived from the parent roles and they don't need to be updated.

I explain:

YY_PARENT (the parent role)

YY_DERIVED_01 (derived from YY_PARENT) need the authorization object S_DATASET to be updated

YY_DERIVED_02 (derived from YY_PARENT) need the authorization object S_DATASET to be updated

BUT:

YY_DERIVED_03 (derived also form YY_PARENT) <u>don't</u> need S_DATASET to be updated !!

So I think that if i modify the parent role YY_PARENT to update the object S_DATASET, it will modify also YY_DERIVED_03, that's the big problem !!

[Former Member]

Auke,

I think you're right, I have no choice, I need to create another parent role and derive it to create another role that contains the new values !!

Many thanks Guys for your help!!

[Former Member]

But what you are saying is that YY_DERIVED_03 should not have been part of the derived role design in the first place since the access does not need to be the same as the other derived roles. If this is the one and only role that requires it, then you might just go with single roles. Note that S_DATASET will be linked to a tcode and in fact it means that the users for YY_DERIVED_03 are using that tcode in a different way than the other derived role users.

[Former Member]

The problem was YY_DERIVED_03 is created as a ...derived role because the functionnal team doesn't understand how derived role works. They thought that the difference between the parent role and derived role is only about the menu !!!

They have some difficulty to understand the difference between organisation level and authorization object.

As you suggest, i will create a new single role that will contain the necessary object.

[Former Member]

I think I see Hery-zo's point here...

If YY_DERIVED_01 needs a different value for the file name authorization than the value for YY_DERIVED_02 (but the same program) to separate company codes as an example, and YY_DERIVED_03 should be blank or inactive and not even have the program name; then perhaps the intended use of derived roles has reached its limits here as the authorizations are not wanted consistently.

I would set the parent role to the minimum common access acceptable for all child roles, and then create a new single role for YY_DERIVED_01 / 02 where you can then maintain the S_DATASET access required without disturbing the parent / children.

There might already be such a role assigned to those same user's functions which you can add the values to for those who would then require it.

Alternately, you could make your child roles that function by deleting the parent and then maintain the children on their own going forward, but that would be a departure from your current concept. (also test this in a sandbox first, because I have not deleted such a parent role before so there might be some other tasks required).

Cheers,

Julius

[Former Member]

Do i understand this right??? do functional teams have access to PFCG to create roles???

If so that is your real problem, as that shoudl never been doen that way. You are completely right functional consultants have no clue about how roles should be build. advise:

1 take away the access to PFCG in ALL systems for anybody other than security consultants administrators.

2 ask all functional teams to describe the roles points to be adressed:

A TRX in every role

B all wanted restrictions on every TRX (described functionally)

C orglevels on which restrictions should be build.

D Test process for every TRX in every role (both positive and negative)

E check all roles against table USOBT and look for manually added objects,

if they can not give a good reason for adding these REMOVE them.

3 retest all roles based on point 2D, ask the funcxtional consultants to assist where needed. Adjust roels during testing where needed, but create a good auditable record for every change.

4 Update USOBT_C (use TRX SU24) for all changes you apply during testing

5 check your roles for the corrected TRX after this change and update the other roels involved as well.

6 ONLY allow roles that have followed the above process to go to Production.

The above steps are the only way to create a secure SAP Production system for you!

[Former Member]

Hi,

The strenght of derived roles is that you can have the same process available for different parts of the organization. If you add or change an authorization object in a derived role and later change the template role and use the button to update also the derived roles(or do thise even you did not change a thing), all the changes in the derived roles are replaced by the template role except the organisational values. If you want to change the activities (process) of a role, you better copy this and make a new one. Derived roles can take away a lot of maintenance if you keep the activities etc the same in the template role and the derived roles, only have differences in the organizational fields (values).

Take the advice of Auke in mind about how to organize properly.

have fun

Jan van Roest

[Former Member]

Hi,

Thanks Gurus.

The real problem is nobody knows exactly how authorization concept works in our organization. Your help is very precious for us.I try to apply your recommendations and I'll give you the issue next time.

Thanks a lot

[Former Member]

thanks a lot for your help gurus

They change team to manage authorizations !!