Skip to Content

Why are the people who define allowed transactions in production apparently not very smart?

Why are the people who define allowed transactions in production apparently not very smart?

So often I find that in production, I can use SE80, but SE38 - ooo no. You musn't use that...

Even though I can run from SE80...

Show 7
* Please Login or Register to Comment on or Follow discussions.
avatar image
Apr 13 at 03:58 PM

I've seen several places that ban SA38 and SE12, but SE38 and SE11 are fine.

2 Share

Same here! :)

0 Share

Restricting authorizations only on transaction id is always a dumb and bad idea.

The same goes for strict authorization on a development system.

1 Share

the auditor who had his first assignment asked the user admin veteran to do this - and since auditors are always right you must not argue with them as this might turn into a red flag in the audit report

And since this pi**ed off the professionals they are no longer telling what security gaps are in a system.

3 Share

Well, even if you restrict TCodes use SE93 and double click on program and perform test on it :)

For example : SE93 --> SU01 --> SAPMSUU0 --> F8

1 Share

Shshsh, don't tell anyone! You'll blow our cover! :)

1 Share

SE37 but no SE38 access. Uhm, I can just click a button and change the object type to a report. This is merely a nuisance to me and not a deterrent to anyone with evil intentions.

SA38 access but no SE38. So, you mean I can execute the program but not look what is inside it before I do that?

Also for business users - allow SE17 (without bothering adding any table-level objects) but not SE16. Again, this just makes people less productive, not less potentially dangerous.

I agree with Juergen, this likely comes from the auditors who have no clue. Just like some stupid ABAP stuff comes from the developers who have not learned anything in 20 years but have enough power to make what they do "our standard".

1 Share
10 |10000 characters needed characters left characters exceeded