Skip to Content
author's profile photo Former Member
0
Former Member

User Authorizations and security

Posted on Nov 13, 2006 at 06:44 AM 68 Views

Hi,

I need to know that , is it required to give <b>SAP_ALL</b> to <b>functional consultants and ABAP developers user id</b> created , or there are some different set of roles to be created. where do I find these security best practices , so that I can implement them.

Regards

Puneet

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

6 Answers

  • Best Answer
    author's profile photo Morten Hjorth Nielsen
    Morten Hjorth Nielsen
    Posted on Nov 13, 2006 at 11:00 AM
    1

    Hi

    No it's not needed, there a lot of security functionality they haven't got any need for. Though I recognize that they need extensive access.

    What I normally do is to create a developer role based on SAP_ALL. In this role I then revoke some of the more critical objects e.g. the user management/security object, access to create RFC destinations, change system settings (S_TABU_DIS, no access to group SS and SA), go through S_ADMI_FCD, etc..

    What needs to be removed from the role depends on the system, the version, your policy. My guess is that there are as many opinions on this, as there is security consultants.

    But keep in mind, as security is implemented in the abap code - your developers will never the less have almost full access to your entire system. Security here is more a question on "Communication" than actual security. e.g. <i>"If you haven't got access - don't do it ! "</i>

    Regards

    Morten Nielsen

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Nov 14, 2006 at 05:15 PM
    1

    No, it is definitely not needed. Although you may

    end up creating a set of roles for them that has very broad access,

    it is still not SAP_ALL. Also,requirements for access in DEV and PRD

    would be different. Typcially, the PRD may only be display only.

    Warning though - there will be quite a bit of work to create and

    maintain these roles. Copying SAP_ALL and turning off authorizations might

    be one way to go, but SAP_ALL has access to * on S_TCODE which means

    any tcode can be executed - unless the associated auth objects are turned off. But there

    are several tcodes that do not have associated objects. I normally build

    a role by specifically identifying the tcodes they need - rather than

    a wildcard or a range of tcodes like A* to D*, etc.

    It might come down to what your auditors / management will want.

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Sri Raghu Kishore Pusapati
    Sri Raghu Kishore Pusapati
    Posted on Nov 14, 2006 at 05:04 PM
    0

    Hi Puneet,

    for ABAP developers we used to have the SAP standard DEVELOPER role earlier..so we framed our roles based on this one and also after a lot of effort we have differentiated the Tcodes into Module customizing etc .like MM customizing, PP cust and so on... a bit of functional effort has been spent into thso role differentiation......

    http://www.sapsecurityonline.com/r3_security/r3_security.htm has abit of security concepts and would be a bit of help on a read 😉

    Hope this info is helpful,

    Br,

    Sri

    Award Points for helpful answers

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Nov 15, 2006 at 08:14 AM
    0

    The authorizations which you specified here depends on the system and also the Position..

    For your query, for ABAP developer you can go for

    SAP_BC_DWB_ABAPDEVELOPER ---ABAP developers.

    SAP_BC_DWB_PROJECT_MANAGER------Development project leader.

    SAP_BC_DWB_WBDISPLAY -

    ABAP developer display authorization.

    For functional consultants its solely dependent on the position he holds....

    Hope it helped you...

    Subbu

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Nov 15, 2006 at 08:20 PM
    0

    Hi Puneet,

    This can be done in another way too. If the Developers need powerful Transaction codes, but not in everyday usage, you can think of creating seperate user id ( for example POWER_MM, POWER_FI etc),

    This common ID could be used by that group members, id only on approval from his manager for a specific purpose.

    This way, you have much control over the POWER ID usage. Also auditing is easier.

    Thanks,

    Raj Sam

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Nov 16, 2006 at 12:10 PM
    0

    hi friends

    one of my staff has created a company code. He wants the company code to be accessed only by four users is ther any way that i can restrict others from accessing that company code if yes please tell me the steps to do that

    thanks & regards

    sathi

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member
      Jan 10, 2007 at 09:52 PM

      Sathi,

      Yes, you can in fact do this...it is a fairly involved process but once done it works very well.

      Remove ALL authorization objects pertaining to BUKRS (in this particular example you only want to limit users to a company code) from your role. We'll call this first role ZT_role. You will have your transaction codes in here.

      You will have a number of other authorization objects that you could do this same thing with. We are currently not only doing this with company code, but cost center/profit center, plant and several more. The process is the same. If you don't want to allow certain users access to a company code, plant...etc. pull the auth obj out of the transaction role.

      Next, create a brand new role WITHOUT T-CODES in it and name it something like ZD_Locking_role (whatever you want to call it...but in a sense you are locking users down with this role).

      In this 2nd role you will need to manually enter each Authorization Object that uses BUKRS from your 1st role and then add in the company code(s) you want to allow people to see (again...manually add those auth objects needed as mentioned above for cost center/plant etc.).

      Now, you shoudl be able to assign the 1st AND 2nd role to a person. Now, they will will only be able to see the company codes you placed in the locking role.

      If you only assign the 1st role, they will not be able to view/change by company codes. By adding the second role, the SAP system checks the auth object against their entire profile in their master record and should allow them work fine.

      Good luck!

      For those that care...

      We not only do the above, we took it many steps further. We created derived roles broke those down to display only and create/change roles. In other words, the locking role would read something like Z_DISPLAY_XXX or Z_CRT_CHG_XXX (where XXX is the company).

      User roles assigned to associate Joe Smith - As an AR Manager this person needs access to ALL AR function for creation/display and change but only allowed to display all AP documents and not change all within company code XXX:

      Transaction roles:

      ZT_AP_DISPLAY role (AP needs to run XK03 or XK04...any and all t-codes are locked down to display only! [03 or 08...etc.])

      ZT_AR_MANAGER role (AR Manager needs to display (only) AP stuff but not be able to change. They also need to be able to perform all other functions (create/change) as an AR Manager)

      Locking Roles:

      ZD_DIS_BUK_XXX (XXX is company code) [display only]

      ZD_CRT_CHG_BUK_XXX (XXX is company code) [create change]

      With a thoroughly thought out system you can have a very sight system while being able to allow user the versatility to see only certain information.

      Good luck!

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.