Skip to Content
avatar image
Former Member

Access to all Except Basis and Security

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?


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    avatar image
    Former Member
    Mar 05, 2008 at 11:12 PM

    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 [frustrated-need-advice-on-sap-security-implementat]

    Hope this helps


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


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

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member 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.


      > 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,


  • avatar image
    Former Member
    Mar 05, 2008 at 08:20 PM

    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.



    Add comment
    10|10000 characters needed characters exceeded