Creating Roles for HR,FICO etc.

[Former Member]

Hi Security Experts,

I am new to hard core security and really do not know much except for the basics.

I have a requirement where in i have to create roles for different modules like SD,MM,HR and FICO. I do not have any requirement specifications from the bussiness, but all they want is that these consultants should not be able to acces the SAP basis T-codes. this is kinda basic security what they are looking for.

I have tried many ways but i am not able to achieve it. The ways i did are...

1. Copied all individual sap standard roles which belong to each of the modules like HR etc to another role like Z_HR... individually... there are like 300 for each module... and i am tired. In these newl created role i have checked S_TCODE for any basis t-codes. It is killing time. Then i added these roles into a composite role. Till now i am not even done with one.

2. I have added all the transaction codes related to each module into a role. The problem here is the users are not able to access the backend... this was a complete diaster...

Now i am thinking if i can change the Profile SAP_ALL by coping it to another new name and then taking out all the basis t-codes from it.

Can anyone help me with this issue cos this is going on since the past couple of months and i am not unable to get over with it.

Please try to walk me through this.

Thanks in advance.

[Former Member]

Taking out the tcodes from a copy of SAP_ALL is not enough, by a longggg way.

So that they cannot easily bypass their own security restrictions or access basis type functionality, try start with the following:

- restrict all the S_USER* objects (permit display if that is intended),

- restrict all S_DEVELOP authority (permit display, but preferably without DEBUG object_type),

- restrict object S_ADMI_FCD to a bare minimum they can do with,

- restrict S_LOG_COM and S_RZL_ADM objects,

- restrict S_TABU_DIS activities and groups,

- continue further with other auth objects in the Basis_Development and Basis_Administration classes (see docs in tcode SU21 to find the next layer of objects to restrict further).

Little tip: Before doing this, activate the security audit log (tcode SM19) to record all successfull tcode starts and RFC calls as these users go about their daily tasks. This will help you find the tcodes the users will need a new, less basis type tcode for to replace the basis one, and give you a list of tcodes actually used by them, to start building a role based on the entry point they are using for have grown used to using.

Depending on how much time and effort you are willing to invest, you might be better off just using the standard roles (copy them into your own name space) and check them against the above objects and if found, then check the values they have in the authorization definitions.

If you have not done this before, then my recommendation would be to go for the second option: Copy the standard roles delivered, as a basis to start from.

Cheers,

Julius

[Former Member]

1. What our Learned frined juluis suggested is good. But the problem is you may not understand what you have done or why you have done, Its an excellent method , especially if you are hard pressed for time.

A way to learn along and design the is :

1. In the module there woudl be a functional "expert"

2. Together divide the module into smaller business groups

3. within this business group understand who does what

4. Understnd which tcds are needed for each

5. Go to PFCG create the role.

Now you may question why not just copy the standard role and customize it--> Excellent but only one hurdle the small business group i talked aboutmay differ from the standard. then customizing th estandard role would be mor etime consuming than creating a new one !

Hope I am clear. Else Julius or I shall fly down to your location !! ( I already owe lot of flights to Juluis !!)

Thanks

[Former Member]

> But the problem is you may not understand what you have done or why you have done,

That is probably also true, that using Standard Roles will likely deprive you of a part of the learning curve and the implementation specific business processes which the roles whould "give life to" for the users. But you can learn a lot from the standard roles as well (which objects are important in the coded part of the concept, which objects are optional, etc).

Cheers,

Julius

[Bernhard_SAP]

Hi Bharani,

another point of your suggestion to copy SAP_ALL is, that (with quite actual supportpackage) you won't be able to activate your copy, as it still contains generated authorizations....

I just want to warn you, that hours of work might be useless (for reducing the SP_ALL-values) if you cannot activate the profile at the end...

So if you still want to perform such a reduction-process, I strongly recommend, that you perform that in pfcg ('insert complete authorization form draft) instead of SU03,SU02.

b.rgds, Bernhard

[Former Member]

Hi Julius/George

Thank you for the reply. I have tried what you have told me and inbetween am stuck.

I am trying to go with the 1st choice of wht Julius has told me. Even if it a little time consuming i would go with that, Julius can you tell me a little in something like specific steps on how to change the S-USER.

Wht role has to be copied first in PFCG to derive the new role from. Then we have to change the authorization in this role and further assign it to the users.

A little details steps would help me.

Other inputs would also help along with what julius is saying.

Thank you'

[Former Member]

Obviously in the absence of requirements, your big problem is that the definition of HR, FICO, etc consultant is missing and what basis is, will also depend on how you are organized.

We know even less about that, than you...

So you are starting with the delivered standard roles, copying them and going from there? Is that correct?

> ... can you tell me a little in something like specific steps on how to change the S-USER.

Take a look at the FAQ sticky thread at the top of the forum. There are some threads on "rules" and "changed objects" for using PFCG. In the case of S_USER*, the easiest option is to disable the objects if they are brought into the role and create explicit roles for user and authorization management.

Cheers,

Julius

[Former Member]

Hi there

i have copied all the standard roles pertaining to one function group such as HR_........ into new ones and named them Z_..... Now i have created a composite role and assigned all the z_ roles that i have created and assigned the composite role to a user.

When i login and execute the basis transactions, they pass.

Can anybody tell me how to go abt it.

Thank you in advance

[Former Member]

Opps

forgot to tell you experts that when i copied the standard roles into new ones, i did check the s_user to see if there were any critical transaction like su01,pfcg,scc4,sccl etc...

[Former Member]

This might sound silly, but does your test user have only these roles (or the composite one)? The access might be coming from a different role or from a reference user?

If not, then the authority to start these tcodes (SU01, PFCG, SCC4) and use them (S_USER_GRP, S_USER_AGR, S_TABU_DIS) must be in there somewhere.

Hope that helps,

Julius