User Authorizations and security

[Former Member]

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

[morten_nielsen]

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

[Former Member]

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

[Former Member]

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.

[Former Member]

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

[Former Member]

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

[morten_nielsen]

Hi

Sorry - but I would strongly advice against using generic poweruser.

By doing so you would loose your audit trail, and probably violate your license agreement with SAP.

<b>Always use named users !</b>

Regards

Morten Nielsen

[Former Member]

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

[Former Member]

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!