SAP_ALL minus SPRO

[former_member759680]

Hello,

I need to give 20 users access to SAP_ALL, but restrict access to Transaction SPRO.

Please provide an efficient method to do this.

Thanks.

[Former Member]

lock spro in sm01

[former_member759680]

Thanks jet,

But its just for 20 Users!!

[Former Member]

I think you will have to create a custom role ( I may be wrong). You can use table tstct for the list of transactions you want.

[Former Member]

see there is no straight forward way of blocking access in sap. it depends on how to do a work around.

when u give sap_all u cannot block any thing, u can lock certain t-codes.

u can go for creation of a new role. for them

or else u can block the changes by making the client non-modifiable. but again this will effect all the users.

if u can tell ur exact requirement then we can come out with a work around.

i still couldn't get why, u want to give sap_all when u want to block spro.!!!!!!!!!!!!!!!!!!

[Former Member]

this might solve ur problem,

create an empty Z role , go to authorizations and edit/insert authorizations/ from profile . i.e. sap_all and then give authorization to organizational levels and edit the role but removing or blocking autho to spro and other objects depending on requirement.

this should work

Edited by: jet l.....i on Feb 7, 2008 5:12 PM

[Former Member]

Hi Gautam,

try the below procedure:

Create a role in PFCG and save it.

Go to authorizations tab and select 'expert mode'.

Select SAP_ALL template and click 'adopt reference'.

Save, generate, then find S_TCODE object and change values to 0-SPRN, SPRP-Z

Save, generate again.

Regards

Ravi

P.S: Reward points if useful

[Former Member]

>

> Hi Gautam,

>

> try the below procedure:

>

> Create a role in PFCG and save it.

> Go to authorizations tab and select 'expert mode'.

> Select SAP_ALL template and click 'adopt reference'.

> Save, generate, then find S_TCODE object and change values to 0-SPRN, SPRP-Z

> Save, generate again.

>

>

> Regards

> Ravi

>

> P.S: Reward points if useful

That will only provide superficial restriction over running SPRO

By modifying SAP_ALL, there is nothing stopping me doing something like adding SAPLS_IMG_TOOL_5 to a custom tx (no dev key needed)......

[Former Member]

>

> P.S: Reward points if useful

I have serious doubts that you will get points for that, but chances are good that you will get a special mention in the next audit report...

[Former Member]

What is wrong with SPRO, if the user has the correct authorizations for it?

Considering that these users already have SAP_ALL and based on the posts so far, will with almost certainty continue to do so, the end result of your efforts are that these 20 "super users" will learn the wrong way to analyze and display the system setup, and also learn the wrong way to bypass cosmetic security anyway (assuming they don't know 100+ ways to hose your security anyway).

Or they might accidentally find some transactions which often start with O* and not have a clue where they fit into the bigger picture... and then start them to see what happens...

Cheers,

Julius

[Former Member]

>

> Or they might accidentally find some transactions which often start with O* and not have a clue where they fit into the bigger picture... and then start them to see what happens...

Don't tell me you have never tried that one........

[Former Member]

If you look in table T085G, then chances are good to find many customizing changes created by auditors.

Again, no fault of SPRO. When you restrict the access as described above, then users find the reports and run them, sometimes the wrong ones, or without the "Test" flag...

An intuitive menu or report tree is the way to go (in my opinion), but that is not easy to convince auditors of (including myself) when all their audit programs state "start transaction SE38 and run report RF.... etc". Of course, you can block them from executing reports directly from SE38 etc.

Cheers,

Julius