Access to all Except Basis and Security

[Former Member]

Hi All,

I was told to make a Role for Abaper's and Functional Consultant in DEV and QAS System.

I am supposed to give them access to all except all the Basis and Security Access.

Please help me how should i do this. Is there any Standard Profile for this?

Thanks.

[Former Member]

You could look in transaction SU21 at the objects in the "Basis Administration" class, which also includes the main Security and User Admin objects, and then exclude them.

Some of them with display activity type fields (not only field ACTVT!!) may be required though... some might also be required for specific reasons / requirements.

There are also some objects in the Development class of objects, which are stronger than all the others.

There have been a few posts already on this topic in the past. Search for "SAP_ALL & developers" for more and keep an eye out for 'Auke Visser' who has made some very usefull comments on procedures.

Cheers,

Julius

[Former Member]

One of my favorite topics

This is a quote from one of my posts related to the same issue. This is how I did it

So, I made a role (z:sap_all), copied sap_all profile, disabled Basis Objects (BZ_A, BC_C, BC_Z) and assigned it to them. Then I kept adding Tcodes one by one on request basis.

This effectively means that the Functional Consultants have access to no Basis Objects but all Functional Objects. Please note that this is only okay for Dev and in QA to some extent.

If you dont want to add Tcodes on a request basis, here are some Tcodes you can give them in Dev or QA. They will need access to these anyway.

SM21, SM36, SM37, AL11, ST22, SE16, SM30, SE38, SA38, SM30.

You can also create another role with these Tcodes.That way, you have 2 roles

1. With all Functional Objects and no Basis Objects

2. This will have the Basis Tcodes that they might need.

Also, check this []

Hope this helps

Julius,

If you think there are loopholes in this method, please let us know.

Kunal

Edited by: Kunal Belnekar on Mar 5, 2008 3:13 PM

[Former Member]

I agree with you.

But we have to give display access on authorization object S_TABU_DIS for Functional people. ABAPer s may required the same.

[Former Member]

Hello Kunal,

That sounds like a good plan, and if it works for you then that is okay.

I guess it also depends on your setup and the size of your organization. Some of those folks might also have some support and monitoring responsibilities, perhaps even in PRD,

so some specific values for those "basis objects" might be unavoidable (eg. S_ADMI_FCD, S_IDOCMONI, S_BTCH_ADM, S_SPO...).

For folks with such skills, it certainly makes sense to control at object level and not rely on S_TCODE (eg. they already have SE38, SM37, SM30... anyway).

Very usefull is to have a secure Emergency User Concept in place. This will help you restrict the roles to differentiate between routine tasks required,

and eventualities which might happen. We developed our own solution, but there are also commercial products on the market. Of course, I think ours is much better...

Regarding "loopholes", I would say that the higher your Support Pack-level is relative to your Release level, the less there will be.

A tricky area is the config around and authorizations for the debugger. One of oldest tricks in the book, is to look for dialog users in RFC destinations and then debug calls to them.

You might want to close that "loophole". Ensuring restricted authorizations, and no dialog users in RFC destinations is a good start.

Cheers,

Julius

[Former Member]

Thanks Julius. Unfortunately, I did not see this post until today when I was looking up for a solution to another problem.

I had a few questions and was wondering if I could get some help. I have received very good response so far and I have been able to get almost all the Functional and Developer roles carved out just because of this forum.

We are planning to Go Live and I am being bombarded with people literally demanding for access to Tcodes that can potentially cause harm. Their argument is that they need it to troubleshoot errors post Go Live which I do not disagree to.

I intend to make a firefighter role/user for this purpose so as to allow users to troubleshoot and also not stop them from performing their daily activities. My biggest problem is, I dont want to give the firefighter role too much or too little access.

Can you provide me with some insights with what the Firefighter role should have ? Like some Tcodes or maybe more of Developer Access ? Anything that would help me. Or should it have sap_all access ?

Also

 One of oldest tricks in the book, is to look for dialog users in RFC destinations and then debug calls to them.
You might want to close that "loophole". Ensuring restricted authorizations, and no dialog users in RFC destinations is a good start.

Im not sure what this means.

Thank you.

Kunal

Edited by: Kunal Belnekar on Mar 14, 2008 3:44 PM

[Former Member]

Some comments:

> We are planning to Go Live and I am being bombarded with people literally demanding for access to Tcodes that can potentially cause harm. Their argument is that they need it to troubleshoot errors post Go Live which I do not disagree to.

and

> I intend to make a firefighter role/user for this purpose so as to allow users to troubleshoot and also not stop them from performing their daily activities. My biggest problem is, I dont want to give the firefighter role too much or too little access.

I think only you can answer that question for your specific system and security requirements. A question you might face is access to maintain variants via SA38 / SE38. So, do you give it to the support person's role, or the emergency user role (in which case you will have regular "emergencies" from a wider user base and might want to restrict the emergency access more). To this specific example, you might want to rather consider giving the users transaction VARCH instead, which I recently discovered via one of the SAP User Groups.

>> One of oldest tricks in the book, is to look for dialog users in RFC destinations and then debug calls to them.

Someone with access to SM59 can easily click on the "Remote logon" button. There is another way of doing it in the debugger which is well known. Find the location of a function call to the destination in which the SAPGUI capable user is defined. Place a break point immediately ahead of the call. When your program reaches the break-point, change from the ABAP debugger (/h) to the System debugger (/hs) and then select the Single Step option to step into the function module. The debugger will open an RFC debugging session and you will be logged onto the target destination as the user ID saved in the SM59 connection data.

Some important tips:

- Use only SYSTEM type users, and only SERVICE type users if it must be SAPGUI capable.

- Do not give these user ID's any authorizations for S_TCODE. Their entry point is S_RFC.

- Restrict S_RFC to only those function groups they need (from release 7.10 also protecting function modules).

- Do not give them S_DEVELOP authorizations and be carefull with any other "basis" type authorizations for them.

- Restrict their application authorizations to a minimum which they require.

- Consider deactivating the debugging at system level in production systems.

- Depending your release / SP level, the authority-checks may differ.

Hope that helps you a bit, cheers,

Julius