How to remove SPRO from SAP_ALL profile

[Former Member]

Hi Friends,

Since my client needs access to SAP but we dont want to give them SPRO Tcode authorization.

So i would like to have your advice on that so as wht to be done and how can we create a profile without SPRO Tcode.

Regards

Ayush

[Former Member]

Hi,

you can give tcode range in PFCG in auth object S_TCODE

Or you can give alphabet range

a* to so*

spa* to spq*

spra* to sprn*

sprp* to z*

hope this helps

[Former Member]

Hi trupti,

Or you can give alphabet range

a to so**

spa to spq**

spra to sprn**

sprp to z**

Have you ever tried doing it the way you have suggested, bcoz i dont think that would help.

Kindly suggest if you think it would be helpful

Regards

Ayush

[jurjen_heeck]

> Or you can give alphabet range

Entering ranges in S_TCODE will not bring along all other required objects for the transactions/programs..... so you'll probabely still end up with lots of authorization failures to fix.

But, as soon as anyone finds a "quick fix" for the original problem we'd all like to know. I for one think there is no other option than designing one or more roles around the transactions the user needs.

As I read in the thread they weren't able to tell in advance which transactions they need but instantly managed to start one that wasn't in the role. Now, when and why is that the security guy's fault?

[Former Member]

Hi Ayush,

What i have mentioned is correct and working you can try it

hope this helps

[jurjen_heeck]

>

> Hi Ayush,
> 
> What i have mentioned  is correct and working you can try it
> hope this helps

Once you start to explore TCODE ranges, also be aware of all customizing transactions starting with O.

Try OOUS for instance.

[Former Member]

Trupti,

What you have mentioned here might appear to work, but that is only an appearance.

It is like those optical illusion tricks which magicians do...

Cheers,

Julius

[Former Member]

I guess what Trupti has in mind is copying SAP_ALL and editing the S_TCODE object with the proposed ranges.

Which, of course, would be a bit like coating a nuclear bomb in chocolate and handing it over as a birthday present...

[jurjen_heeck]

>

> I guess what Trupti has in mind is copying SAP_ALL and editing the S_TCODE object with the proposed ranges.
> 
> Which, of course, would be a bit like coating a nuclear bomb in chocolate and handing it over as a birthday present...
> 
> 

Cute comparison.

The one I had in mind was: Technically answering the question "how do I lock the front door?" without making the original poster aware of back doors, windows, skylights and other ways to enter the building.

[Former Member]

>

> Which, of course, would be a bit like coating a nuclear bomb in chocolate and handing it over as a birthday present...
> 
> 

I which case you nibble the edges and get out of there before it explodes.........reminds me of a few implementations I have seen it the past

[Former Member]

I had an image of someone with a top-hat on and a stained sword in his hand, doing some [parallax error|http://en.wikipedia.org/wiki/Parallax#Parallax_error] recalculations... and behind him someone is removing what was left of a cute white rabbit.

[Former Member]

Finally the discussion didnt prove to be of any help, Can anyone suggest me in a simple term that how should i design the role without SPRO.

Or

Are you guys trying to say that i should specifically giveTcosed which client users require and create the role with those Tcodes and should not copy SAP_ALL profile

Regards

Ayush

[Former Member]

The second option is what we are saying, unless there are any objections?

Cheers,

Julius

[Former Member]

Thanks for your prompt reply julius,

Isnt there any way to restrict the user from SPRO. lets say he just cant access all the Tcosed which are bundeled into SPRO or he cant get the view access to SPRO..

I think its not that difficult, although i dont know this. but i have heard people saying that they have made SAP_ALL profile without SPRO...

Regards

ayush

[Former Member]

> I think its not that difficult, although i dont know this. but i have heard people saying that they have made SAP_ALL profile without SPRO... 

It is easy to copy SAP_ALL and create a role without SPRO

This will not stop people from accessing the functions behind SPRO for the reasons posted before.

Lots of people claim they create a SAP_ALL without SPRO, I will bet £1000 (I know it's worth many euro's at the moment) that 90%+ of those roles which people think have SPRO removed will not stop people accessing config.

Ask yourself this question....

If you build a house do you:

1. Buy a giant piece of rock and cut holes in it

2. Build it from components - bricks, windows, doors etc

[jurjen_heeck]

>

> If you build a house do you:
> 
> 1. Buy a giant piece of rock and cut holes in it
> 
> 2. Build it from components - bricks, windows, doors etc

If only SAP_ALL were a piece of rock... unfortunately it's a heap of building materials slightly resembling a house. Now the real trick is to take out enough from the inside to make it liveable without having the rest crashing down on you.

Building roles by taking objects and/or values from SAP_ALL-copies reminds me of playing [mikado|http://en.wikipedia.org/wiki/Mikado_%28game%29] .......

You either leave too many sticks in or you loose alltogether.

[Former Member]

Hi Ayush,

> I think its not that difficult, although i dont know this.

This is perhaps close to what the people who tell you they have made SAP_ALL profile without SPRO... are thinking but not knowing, or perhaps not...

If you only restrict S_TCODE and leave the authorizations as those of SAP_ALL for all other objects, the user with that role will bypass all your security in many ways. For one example, they could simply give themselves SAP_ALL as profile again, or even do it in virtually invisible ways which you have hardly any chance of finding.

I make another bet with you: If you restrict the access by building a role from specific transactions only and restrict all the objects to what they only really need, then they will next ask for a Display-only SPRO role... and if you copy SAP_ALL without SPRO and monitor your security audit log, you will sooner or later find successfull transaction starts which are SPRO related. Most likely it will be some combination of both = both "SAP_ALL without SPRO" role and "SPRO diplay only" role assigned to the same user....

Hope that helps you,

Julius

[Former Member]

This question pops up every 3 months or so; both here on SDN and in real life.

In short, no-one should be assigned SAP_ALL, so the question "how to give SAP_ALL without SPRO" is not really relevant. What is needed is a decent role allowing for displaying the IMG without actually messing anything up, right?

Unfortunately, SPRO in itself is just a menu... by clicking the menu options in the SPRO tree, you activate hundreds of other transactions, each with it's own authorization objects. Because of this, it wouldn't really make sense to just remove "SPRO" from any role; you'd also have to take out everything behind the scenes (or under the hood).

Not sure if this resolves your problem, but as stated above, the request is somewhat misguided in the first place, which is a fair enough reply to your managers...

[jurjen_heeck]

> Since my client needs access to SAP but we dont want to give them SPRO Tcode authorization.

> So i would like to have your advice on that so as wht to be done and how can we create a profile without SPRO Tcode.

Your topic subject is a bit misleading. The only proper answer to the question in your message should be (in my opinion) to ask the client what he does need and build a role based on this information.

As already pointed out, the SPRO tcode only leads to a menu. Taking only that away is like telling someone to hand over the front door key but letting him keep all other keys to the building... I think no-one needs all keys in the first place.

Jurjen

[Former Member]

Thanks friends,

I am still lurking with a doubt as what should be done to remove the SPRO access from a Role.

1. My client wants me to design Role that has got all the MM related Tcodes or rather i should say everything related to MM domain should be there.

I tried making a role with handful of Tcodes but later he tried executing tcodes which were actually not there in the role. so later he was getting access denied.

2. Now my colleagues who are SAP Consultants want me to design a copy of SAP_ALL delimiting the access to SPRO.

Since its quite critical i wanted to help me out..

Regards

Ayush

[Former Member]

I would suggest the best way of designing a role that has access to all standard delivered SAP tcodes but not customizing tcodes would be to download the list of tcodes from TSTC tables. In the selection screen you can exclude from selection the tcodes like O* and SPRO. And also maybe tcodes for function modules you are not interested in.

Download the list to an excel file and and the add them manually to the new role.

[Bernhard_SAP]

... what a suggestion....

do you really mean what your are suggesting?

Have you tried that once before?

I think you want to add abt. 15-20.000 tcodes manually.....

Good luck!

I think after some hours of work you will stop again....

b.rgds, Bernhard

[Former Member]

>

> I think after some hours of work you will stop again....

I believe that is the first step in the above mentioned Mikado game. Also known as "short dump"...

Cheers,

Julius