How to handle unwanted SU24 proposals which are automatically "corrected"?

[Former Member]

Dear gurus,

I would be interested in knowing whether someone knows a trick or better way to deal with the issue:

Background

I remove the proposal = Yes indicator in SU24 for selected objects from all, or almost all, transactions (e.g. S_DEVELOP, S_USER_GRP, etc). This is because I always want to know and intentionally grant access for these objects, and also because SAP delivers them sometimes without important fields maintained, so the continue to "nag" and invite you to pop a * into them. For larger roles, they clog up the authorizations tab with inactive authorizations as well if left.

Solution

So, in SU24 on the "Authorization Object" tab I do a mass maintainance and set all the indicators to "No".

Here is the problem

If I ever go to that transaction again on the SU24 "Application" tab and maintain the proposal values for any other object AND the unwanted object is maintained as an "additional check at transaction start" (visible in SE93, backend table TSTCA) then the system "automatically corrects" the SU24 proposal values again and sets the indicator to YES. It also does not tell you which object it corrected and if it is has parameterized transactions which have no proposals of their own, then it distributes the proposals to all of them as well.

I don't want that...

My ideas

1) Maintain some harmless activity and dummy values in SU24 and live with the object in the roles. I could set them all to the same values so that they appear only once.

2) I can change the SE93 object to a different one or remove it, but there are many transactions and this might open some backdoors to call transactions allowed in SE97 which still "need" that additional check.

3) I can remember to check the list of objects periodically, and then check roles which might have been opened in expert mode since (this option has the "survival rate" of a dodo..

4) I can ask SAP to change the behaviour, as these proposals should come from the auth/authorization_trace (backend table USOB_AUTHVALTRC) and not TSTCA in my opinion.

5) ... any other trick or solution?

Thanks for opinions and any help.

Cheers,

Julius

[Former Member]

First: Julius is definitely on a NW 7.* system - this phenomenon cannot be reproduced on NW 640 (not to mention that SU24 looks quite different).

>

> 1) Maintain some harmless activity and dummy values in SU24 and live with the object in the roles. I could set them all to the same values so that they appear only once.

Desist! How would the next person, succeeding you, explain? What would this person do, if she/he knew not of your 'solution' to that dilemma. I can tell you what I would do: clean up!! It is not transparent, one has to know what you thought to explain the settings, which is - in my book- not a solution I would give.

>

> 2) I can change the SE93 object to a different one or remove it, but there are many transactions and this might open some backdoors to call transactions allowed in SE97 which still "need" that additional check.

Again: desist! You gave the reason yourself - dependencies that are not obvious on first sight.

>

> 3) I can remember to check the list of objects periodically, and then check roles which might have been opened in expert mode since (this option has the "survival rate" of a dodo.. 

You can try ... however, I promise you that this check will be forgotton as soon as you close the door. Two weeks after you left nobody remembers even why that check should be done ...

>

> 4) I can ask SAP to change the behaviour, as these proposals should come from the auth/authorization_trace (backend table USOB_AUTHVALTRC) and not TSTCA in my opinion.

This.

One question though. I have been looking at this for some 20 minutes now. Why would you prefer the proposals to come from USOB_AUTHVALTRC??? And then ... in our NW 640 systems that table is empty, soooooo ....

>

> 5) ... any other trick or solution?

Nope. Sorry. I am not helping and I know :-(( ...

[Former Member]

Hi Mylene,

Thanks for your inputs!

> Julius is definitely on a NW 7.* system

Yes, sorry I forgot to mention that.

> > Julius Bussche wrote:

> > 1) Maintain some harmless activity and dummy values in SU24 ...

> Desist! How would the next person, succeeding you, explain? What would this person do, if she/he knew not of your 'solution' to that dilemma. I can tell you what I would do: clean up!! It is not transparent, one has to know what you thought to explain the settings, which is - in my book- not a solution I would give.

I agree. Additionally for optional objects or optional fields (such as S_USER_GRP field CLASS...) this "DUMMY" will bring in unwanted access unless all master records are protected by a group. That might not always be the case.

> > Julius Bussche wrote:

> > 2) I can change the SE93 object to a different one ....

> Again: desist! You gave the reason yourself - dependencies that are not obvious on first sight.

Agreed.

> > Julius Bussche wrote:

> > 3) I can remember to check the list of objects periodically, and then check roles which might have been opened in expert mode since (this option has the "survival rate" of a dodo..

> You can try ... however, I promise you that this check will be forgotton as soon as you close the door. Two weeks after you left nobody remembers even why that check should be done ...

No objections your honour

> > Julius Bussche wrote:

> > 4) I can ask SAP to change the behaviour, as these proposals should come from the auth/authorization_trace (backend table USOB_AUTHVALTRC) and not TSTCA in my opinion.

> One question though. I have been looking at this for some 20 minutes now. Why would you prefer the proposals to come from USOB_AUTHVALTRC??? And then ... in our NW 640 systems that table is empty, soooooo ....

See [SAP Note 543164|https://service.sap.com/sap/support/notes/543164] . That is where SAP gets it's SU22 data from, and customers can generate "original" data of their own.

> > Bussche wrote:

> > 5) ... any other trick or solution?

> Nope. Sorry. I am not helping and I know :-(( ...

Darn! Next please...

Thanks for the thoughts and vote in favour of option 4.

Cheers,

Julius

[Former Member]

> One question though. I have been looking at this for some 20 minutes now. Why would you prefer the proposals to come from USOB_AUTHVALTRC??? And then ... in our NW 640 systems that table is empty, soooooo ....

Not necessarily, and in some cases not at all.

At least we don't have the "vanilla" checks proposed any more for PFCG from their traces or assumptions at transaction start...

SAP has to maintain SU22, but the SE93 checks are still there, which is fine.

>... in the worste case actually an empty field (in SE93)..

>

> Empty fields or hurried values in SE93 are *'s in empty or hurried minds..

I think this will be the greatest security gain in my opinion, but no reason for SAP not to deliver usable (empty?) SU22 data for "activity type" fields.

Rather don't deliver anything than empty activity or action type fields.... and maintain '03' etc for parameter transactions with the correct default groups, etc.

Cheers,

Julius

Edited by: Julius Bussche on Jan 11, 2010 11:52 PM

[Former Member]

Note: This is only available via SNOTE if you are on SP18 or higher (for 7.00 ABAP systems). Many programs are "hit" by the change which have pre-requisite corrections in earlier SPs.

Cheers and thanks again to Keerti (and SAP :-)!

Julius

[Former Member]

I tend to do what you are already doing so option 4 seems like the best bet to me.

I've used a variant of option 1 before - clearing all default values, but if someone doesn't read the tech build standards then they could easily put * in a blank field.

[Former Member]

> I tend to do what you are already doing so option 4 seems like the best bet to me.

Okay. SAP Note 11 here we come..

> I've used a variant of option 1 before - clearing all default values, but if someone doesn't read the tech build standards then they could easily put * in a blank field.

If you consistently put some harmless value into SU24 for the field (which is what I meant by DUMMY field value) then you will get that auth instance consistently in the roles, but it will fullfill any authority-check for a DUMMY construct as well.

Okay, one might ask: if it is there in SE93... then what is the user doing with the transaction in the menu? But adding more authorizations to the role data than needed and finding all of them to invent a DUMMY value for is not what I want to be doing in the next weeks.

I would like to have the object and values in SE93 ignored by the automatic correction if I have removed the proposal flag, both for "core transactions" (e.g. SM30) and their parameter transactions (e.g. all the views in SPRO for which I am correcting the S_TABU_DIS groups - because we use them).

Also, there are some transactions which check non-existing domain range values in SE93. These force me to grant a * in SU24 or manually in the role. I don't want that either. My only option is to disable the proposal for the object, but if they keep on auto-correcting back into SU24... then it does not work.

Cheers and thanks for the insights,

Julius

[Former Member]

> Julius Bussche wrote:

> I remove the proposal = Yes indicator in SU24 for selected objects from all, or almost all, transactions (e.g. S_DEVELOP, > S_USER_GRP, etc). This is because I always want to know and intentionally grant access for these objects

Julius,

Out of curiosity i want to know if you mean, you prefer to add auth objects manually in the role? instead of value proposal through SU24?

Regards,

Amol

[Former Member]

> Out of curiosity i want to know if you mean, you prefer to add auth objects manually in the role? instead of value proposal through SU24?

Hi Amol,

I understand your concern, but in this case it is only for a selection of objects which I would like to control either intentionally (yes, manually) or pulled in only from very specific transactions and not all of those which SAP delivers.

If you stick around for long enough after an implementation, then you will see the trouble which these empty proposal fields and excessive activity type fields cause with these objects, over time.

This works okay if you just do it "once off" and then build roles, but I currently have some time to check the transactions in detail and am maintaining very specific values in SU24. If you change any other value or set the proposal indicator for any other object to YES or NO... then these (sometimes ancient values) jump back into the SU24 data automatically.

As the SE93 additional authority-check (see the code of function module AUTH_CHECK_TCODE - and no, it is not AUTHORITY_CHECK_TCODE in this case) is usefull for "plausibility checks" at transaction start and for old transactions even their own S_TCODE value.... it is useless to have optional objects pulled in, or non-existing values, and in the worste case actually an empty field.

Empty fields or hurried values in SE93 are *'s in empty or hurried minds..

Cheers,

Julius

[Former Member]

Looks like SAP heard You ....

SAPnote:-1404093

[Former Member]

Perfect... so 4 it was...

(also see the related notes!).

We just patched our "new year" kernels... See

So the application SP's are next... Darn, darn, darn... those ç%&?"@! user exits!!

Thanks Keerti!

Julius

Edited by: Julius Bussche on Jan 11, 2010 11:37 PM