SAP_ALL without access to SPRO transaction and thereby the IMGs

[Former Member]

Dear All,

My team has come up with a requirement that few of customer core team members be given SAP_ALL authorization but SPRO access should not be.

Personally I have the impression that authorization can only be given, not taken away. Is there any way by which I can create a role and adopt SAP_ALL + restrict SPRO??

regards, Sean.

[jurjen_heeck]

Please use the [search|https://www.sdn.sap.com/irj/scn/directforumsearch?q=sap_all%20spro&objid=f208&daterange=last90days&searchid=18996369&forumid=208&rankby=10001&start=0] and/or look in the sticky thread:

[Former Member]

Hi,

This has been discussed umpteen times and there has never been a conclusion to the above requirement. Still,the thread below might give some interesting tips to approach to a close solution.

[Former Member]

Dear All,

Thanks for your suggestions. I searched and read through forums but couldn't find anything. Moreover, my functional team insists they've had such role assigned before but cannot give me the basis guy's contact number who did it

Any more ideas please.

regards, Sean.

[jurjen_heeck]

> Moreover, my functional team insists they've had such role assigned before

How about searching your systems' change documents?

[Former Member]

Thanks Jurjen.

I meant my team had similar requirement fulfilled in another project. I've been in this one since day one

By the way, how can I search for system's change documents?

regards, Sean.

[jurjen_heeck]

Hi Sean,

Not to insult you, but if basic security searches like change documents are new to you (explore transaction SUIM) there's no way you can judge whether any role, standard or purpose-built, fullfills your requirements without leaving backdoors open.

If your team comes up with requirements like they have you should demand training, at the very least SAP course ADM940. For now I honestly suggest you either bring in a security consultant or just give them SAP_ALL and make sure system backups are regularly made by the basis team.

This is of course as long as we're not talking about a production system. If it is production I strongly advise an immediate system shutdown

Cheers!

Jurjen

[Former Member]

> I meant my team had similar requirement fulfilled in another project. I've been in this one since day one

Was the person's name Caspar?

I used this trick once, although most folks follow either the "build from the bottom" approach with roles based on what the user does need (because often it ends up in production as well....) or the "trust people with SAP_ALL" approach which the first approach sometimes ends up in if you don't do it carefully.

If you search the forum for the term "symbolic table" then you will find an additional trick you can use. You can also go through the code of the table maintenance generator function with an ABAPer to find it.

It looks something like:

SELECT CLASS from TDDAT into wa_tddat WHERE tabname = '&SM31&'.
* Give the customer a chance to exclude super-users... 

But remember that it is "all-or-nothing", and is not 100% bullet-proof against a developer. Probably it is more usefull to isolate the users who can access SPRO, but that is debatable as well whether one should prevent people from displaying the customzing of the system.

The better option is to grant users the correct access and train them to use the correct choice of transaction, so that they do not ask for all sorts of odd transaction codes and objects.

Cheers,

Julius

[Former Member]

@Jurjen,

Thanks again for your time. Actually I haven't worked on security much, this is my first E2E implementation. Although I did found the solution, we already are building up a role authorization matrix for production, so that we do not need a shutdown

@Julius,

Thanks for your answer. My issue is resolved using a trick I finally found using * in auth object.

I'd love to explore your suggestion whenever I find time. And I haven't found the Casper guy yet

Thanks to all for your time.

regards, Sean.

PS: We had this requirement for customer core team in sandbox system.

[Former Member]

> My issue is resolved using a trick I finally found using * in auth object.

So you have them a display all role by setting all S_TABU_DIS to actvt '03' only and in tcode SPRO_ADMIN you created a dummy project for the whole IMG? But they will still display your customizing based on tables if they can find them - which is why the IMG is a more guided way of finding the correct settings, and not assuming that some table found in SE16 is the correct one because it looks similar...

> I'd love to explore your suggestion whenever I find time. And I haven't found the Casper guy yet

> ...

> PS: We had this requirement for customer core team in sandbox system.

Probably wouldn't work in a Sanbox though. It is like the client settings in SCC4 of that client which would be expected to be open in a sandbox, or easily opened without thinking too much about it. It is just a trick, which makes the system behave as if the client is closed and sets change authority to display only if the user goes via the IMG or parameter transactions of SM30 / SM31 which attempt to enter the customzing in change mode.

Looking at it again this morning, it is quite old and probably not really supported anymore.

Cheers,

Julius