Role Management - Copy or standard roles

[krishg]

I had a query regarding the Role Management in SAP. I know it is common practice to copy standard roles and use 'Z' roles in SAP and this makes lot of sense for end-user roles. My question is with regards to roles for Communication users where the role is used 'AS-IS' lot of times. What is the recommended best practice for such roles. Do we copy even such roles to 'Z' roles (for sake of uniformity, even if roles are not modified)

What would be the pro's and con's of using Standard roles (instead of copying to Z roles when there are no changes)?

Also, What about other products from SAP (SLT, GRC, EHS, SolMan, Portal)?

[Colleen]

Hi Krish

Not really best practise. Thsose roles are for guidelines only

If using SAP roles, you have to do something with them as they come ungenerated. By themselves, the role can't be used. A lot of these roles have unmaintained authorisations or don't match SU24 so not sure how you can have a scenario where they don't require changing

[Bernhard_SAP]

furthermore in addition to Colleens points: SAP roles may be changed by support package/upgrade.

b.rgds,Bernhard

[krishg]

Thanks. There are roles that have been requested to be assigned to RFC users as part of standard set up guide. This roles have no organization levels (example - SAP_IUUC_REPL_REMOTE for SLT replication). Does it really make sense to copy such roles and assign 'Z' roles to the RFC user id for sake of uniformity?

I have seen lot of clients use * for organization levels while assigning copied roles to RFC user . In effect, the roles are used as-is, but they are copied. Is that the desired outcome?

I understand that roles can change during support pack /upgrade. Either way, we have to run SU25 to identify changes .  Is there a way to identify such changes when we are applying notes using SNOTE (and there is a role change) or SP upgrade on a minor component like DIMS.

[Colleen]

Hi Krish

SAP* roles are owned by SAP. As a general rule, if SAP owns it you use it as a reference as they may make changes are next release. SU25 is separate to this

I generally use SAP roles as a reference to see what access is in them. Many roles are so old an appear to have been build from old profile concept in 3.1x systems. As a result, they have a lot of additional access they shouldn't have (e.g. S_RFC asterisk).

My main exception is SAP_J2EE* roles.

But there does seem to be inconsistency in SAP advise. For example, HANA guide provides steps to generate profile http://help.sap.com/hana/SAP_HANA_Installation_Guide_Trigger_Based_Replication_SLT_en.pdf instead of advise to copy

Yet, SAP help information has a general rule/caution (which I follow)

source: help.sap.com/saphelp_nw75

"Do not change the delivered standard roles (SAP_*), but rather only the copies of these roles  (Z_*). Otherwise, the standard roles that you have modified will be overwritten by newly delivered standard roles during a later upgrade or release change."

Changing Standard Roles -  User and Role Administration of Application Server ABAP - SAP Library

If the role is exactly as required and you don't need to maintain the authorisations AS WELL AS always wanting whatever access SAP provides then using the role may not be a problem. You'll just have to heed the warning and manage the risk.

Regards

Colleen

[krishg]

Thanks Colleen! We are trying to determine if we should consider an exception policy for such scenarios.

Before defining the policy, I would like to understand the advantage of using "AS-IS" copied roles over assigning standard roles (for communication users) apart from having a uniform policy.

Potentially one difference is that during upgrades, we will not have authorization failures with copied roles, while there is potential that standard roles will  not be generated and we will get error. Would you consider that an advantage?

[Former Member]

I have been optimizing communication users for many years and SAP does as well (See SAP Note 1682316). I can confirm that there are only 3 places in this area where you should keep the SAP standard roles:

1) User SAPJSF because the roles have UME group mappings on the JAVA stack. Use the "read only role" - it is OK. To be safe create a 2nd role for the user anyway and assign it exactly that which it actually uses, just incase SAP change the standard roles and send you one in an upgrade without a profile generated - which is what they will do if they ever change the role.

2) The users generated by transaction SOLMAN_SETUP. These have release dependent expected roles which they don't really need, but the SOLMAN monitor will turn red if they don't have at least those. Easiest is to assign them, delete the profiles because the quality of the roles is not ideal, and then create your own roles with generated profiles for that which they actually do use on your system. Or change the SOLMAN_SETUP to expect your roles... but just making it happy and the basis guys stop complaining works easier.. 🙂

3) In double-stack PI systems up until release 7.3 a similar situation as with SAPJSF arises for the channel users in the JAVA stack. Often the roles do not have profiles or are mostly OK from authorizations perspective, but also not the real authorizations you want. So here also copy the roles but be careful when taking all the standard ones away. Rather just delete the profiles.

All other SAP roles you should avoid as far as possible. Even making a copy of the most of them is a mistake IMO -> build roles for your current scenario and maintain it yourself.

Cheers,

Julius