SAP ALL display issue

[Former Member]

hi guys,

i created a role "ZSAP_ALL_DISPLAY" in quality system by assigning all fields "ACTVT =03". but in SPRO transaction, some nodes like fv12 are able to change and save. please help on this issue

thanks

ramesh

[Former Member]

Hi Ramesh,

For some t-codes display authorization is sufficient it should be either create,change or delete.

Ex: For MM01 T-code if you can assign the activity 03 (display) for all authorization objects even you can't execute the MM01 T-code because of you shold maintain the activity 01 for the auth.object M_MATE_STA

Regards,

Reddy V

[jurjen_heeck]

> i created a role "ZSAP_ALL_DISPLAY" in quality system by assigning all fields "ACTVT =03". but in SPRO transaction, some nodes like fv12 are able to change and save. please help on this issue

That's why this frequently asked question about a display all role hasn't been answered completely yet. Quite a lot of programs do not have any activity check in them. You will have to find out which ones and take them out of S_TCODE.

[koehntopp]

<sigh>

<HUGE SIGH>

I really will have to make that a sticky in this forum....

Once again: creating SAP_ALL_DISPLAY is about the worst idea you might get. If you run any authorization risk analysis tool over such a beast you will quickly find out why.

Short answer: Don't do it. Create Display roles for your different business areas, and use properly controlled superuser roles for the rest. There is no such thing as SAP_ALL_DISPLAY.

Frank.

[jurjen_heeck]

> I really will have to make that a sticky in this forum....

Oh yeah. Definately. Like spro display and all other 'quick fix' questions.....

[Former Member]

>

> > I really will have to make that a sticky in this forum.... 
> 
> Oh yeah. Definately. Like spro display and all other 'quick fix' questions.....

I am already working on it for the FAQ thread - using the search

[Former Member]

I think the quick answer to this may be to check the auth object S_TABU_DIS - all of the nodes from SPRO should be checking this auth object since these are config tables.

[jurjen_heeck]

> I think the quick answer to this may be to check the auth object S_TABU_DIS - all of the nodes from SPRO should be checking this auth object since these are config tables.

I consider that to bad advice.

All my role-building roles (yes, I know that sounds funny) work fine with only ACTVT 03 in S_TABU_DIS, and so do the user-admin roles.

[Former Member]

Sorry I was responding to Ramesh's original question - if he was looking for the nodes in SPRO - which are primarily config tables then these config tables should be checking against S_TABU_DIS. If he wants to make sure its display only then the activity there should be 03.

Not disagreeing with anything said - just saying that he may have change activity in this auth object somewhere and pointed him to that auth object.

The thread seemed to have gone off in general discussion on SAP ALL display all. And I agree - copying SAP_ALL - with S_TCODE wildcarded does not guarantee a display all role if you just change activity to 03 - that's why I would never do it this way.

[Former Member]

This message was moderated.

[Former Member]

At a recent client's site somebody had decided a finance display all role would be a good idea. It wasn't - we dreaded having to add a transaction due to the amount of work involved in inactivating change object values brought in by SU24.

Even if you do manage to transport a role that you think is fully held back (by whatever means) your users will probably have auths which combine to give change access. You also have the problem of a display monster role being modified and transported with change access accidentally.

Throw the request back to the requestor, stand your ground

Good luck

David

PS Frank's posting around SoD /GRC really is worth thinking about

Edited by: David Berry on Sep 29, 2010 9:22 PM

Edited by: David Berry on Sep 30, 2010 6:34 AM