Enabling all auth values for selection – Security Tip
Consider a situation where in you have been asked to add a particular authorization to a role or associate an authorization to a tcode (SU24 change) and you are struggling to locate the intended auth.
This is not a regular case but somewhere you may encounter this and until you know the trick behind this you will really feel helpless.
illustrative Case
You have been requested to add Activity 01 in object S_TABU_DIS for a certain tcode and when you go to change mode to your surprise you won`t find Activity 01 but only activity 02, 03, BD. See a SU24 change step as an example where 01 is not available to choose for
Confused????? How do we add 01 if it`s not available to choose……?
Simple trick ….. Just press F7 (function key F7) and then all the available activities in the system (Referring SAP standard table TACT) will be available to choose as below
Now you can make your selection.
Some important considerations
- This is applicable to Authorization field ACTVT only, same may not be relevant for other auth fields
- This is applicable for all SU24 changes
- This is applicable to all Role changes (PFCG auth tab, update authorization)
- This is applicable to all authorization objects not only S_TABU_DIS
Hi Amit,
What version are you running? I remember this working in 4.7 but I haven't seen it work since.
I'd also question why you would want to do this? Table TACTZ contains all selectable activities for each auth object, and those selectable activities were included by SAP because they were relevant to the data that the object relates to.
If a developer asks you to provide an activity that is not available for an object, then I would suggest that they have written a duff piece of code or have chosen the wrong object for the authority check.
Hi Will,
Case presented has been observed in 4.6c, There might be cases when other than SAP standard values are needed. It all depends upon the customization done on the application as per your need.
I agree with Will on this - 01 is not one of the activities available for this object (that's why it's not on the list), so it just shouldn't be used. You might want to read the documentation for the object in SU21.
As an ABAPer, I can only say that if you receive a request to add an activity that is not on the list, feel free to send the request back to the developer and ask them to change the program and only use valid activities. Developers should do some research too before using an object.
It's awfully nice of you to be so accomodating, but I feel a Security expert should rather decline such request.
HI Jelena,
As stated the scenario is not restricted to this object only. Case given is just an example to understand the logic.
I have faced situations where in i had to look for the values using F7 even after consulting ABAPers.
A senior/experienced security professional might decide the relevancy of the value within an obejct but a beginnier or relatively less experienced security professional might and not and he may be helpless unless he knows the trick.
Amit, that's the thing - this should not be applicable to any object. When an object is created, its author also chooses the appropriate activities and documents them. And these are the only activities that should be used. If a different authorization setup is needed - then a different object should be used or a new one created.
As I said, the more appropriate course of action (regardless of experience level) would to request using only the available/documented activities.
In this particular case I can only guess that developer was confused and assumed (without reading documentation) that activity 01 is to create new records. But this is simply not true - 02 grants access to create/change record as this functionality is not separated.
By any means I don't want to discourage you from blogging, but I felt that in this case an inappropriate guidance is being given. I'm wondering what Julius von dem Bussche would have to say about it...
OK, Amit, so here's a question for you.
If a user sent you an SU53 screenshot which showed that their last failed authority check was for object S_ADMI_FCD with field value PADM, what would you do?
Some developers added unsupported activities into SE93 (table TSTCA) without input validation and then the only way to add this to a role or SU24 was the F7 trick - even although it made no sense it was still a tadd better than a * value which is the only other alternative.
But SAP cleaned up the nonesense in TSTCA a while back ( see SAP Note 1501837 ) and also disabled the F7 feature, which only encourages such syntactically incorrect checks.
So ideally this trick is not needed and anyway no longer possible -> that is a much better solution than keeping / propogating "tricks"... 😉
Cheers,
Julius
Julius, thank you for jumping in to referee this. 🙂
Sorry, Amit... Please do not let this to discourage you from sharing.
Thanks Okay. Its fun to learn from experts like you...