System assignment lost after uploading roles

[Former Member]

I'm trying to move my CUA master. For various reasons (incompatible source and target release levels and plug-ins in particular) I don't want to perform a client copy.

I built a new CUA master client and followed all the guidelines in the documentation. I've linked up the new children and successfully added a new user in all child systems. All was looking very successful until my security analyst discovered that the single roles in our composite roles all belonged to the "user system" (i.e., the CUA master) instead of the child system where they should belong.

I copied the roles from the old CUA master to the new master by downloading and then uploading under PFCG in the respective systems. All the roles are there, they appear to contain the appropriate authorisations and the composites contain the correct singles. The only problem is that the singles are NOT assigned to the correct child system.

We tried reading the roles back in from their correct target system but this did not update the assignment. Curiously, the mapping of role to system in table USRSYSACT is ambiguous - some roles map to the CUA master and some to the child systems. I've not yet established whether there is a pattern to this mapping.

Any advice?

How, when my composite role has many single roles FROM MANY CHILD systems, can I reassign the system for each single within a composite?

[Former Member]

Dera Nicholas,

After building up new CUA system and defining all the ALe's , logical system defining thro' BDLS and other things have you done perform the activity "TEXT COMPARISION FROM CHILD SYSTEMS to target systemn" in the new CUA system after uploading all the roles and generating them.

Regards

Kantikiran

[Former Member]

I'm not sure 'downloading' does save the target-system in the role (but then: i never tried this way). When assigning roles from systems 'outside' the cua-master i do it using RFC. Anyway: check that the field 'taget-system' AGR_HIER-TARGET_SYS is filled in the composite role and also me RFCDES-RFCDEST in each single role with the data of the system / client where it belongs.

after saving do as Kantikiran suggested. You might want to use report SUSR_ZBV_GET_RECEIVER_PROFILES instead of the function you can call from tx. PFCG herewith avoiding to repeat the function for every new role created.

[Former Member]

Thanks for the suggestions. Sadly, no luck with either.

I've looked at AGR_HIER table and the "target_sys" field is empty. It's populated in the source CUA master system (which makes sense).

Text comparison, either from SU01 or via the program mentioned, completes successfully with green lights for all child systems but does not update the target system. I tried it with, and without, selecting the "delete invalid assignments" check box - same result either way. Even tried running PFUD for one child-system role but, while that recognised there was no auth data, it didn't update agr_hier-target_sys.

I don't understand the comment "...and also <i><b>me</b></i> RFCDES-RFCDEST in each single role with the data...". The desired target (child) system is correctly defined in the RFCDES table. <u>Remember</u>, I have been able to create users in these systems from the CUA master and I can assigne roles to the users. The problem is that the roles which SHOULD have a child system as their location do not - they think they belong to the CUA master system.

I did try reloading one role via RFC. To try to understand what's happening I tried two experiments. First, I reloaded the role from it's correct child system and then I reloaded it from the old CUA master.

When I reloaded the role from the child system, I was warned that it already existed and would be overwritten but the import log finally showed a red traffic light meaning the role was not imported.

When I reloaded it from the old CUA master it worked but, unfortunately, it set the destination system to the old CUA master, not the child system.

Message was edited by:

Murray Nicholas

[Former Member]

the cua-master should not contain active roles = roles which have authorization objects and generated profiles. the cua master should have 'empty' roles which act as a kind of pointer. they show (using the RFCDES-RFCDEST ... fields) where the 'original'-role is located, so you can directly or indirectly (using HR-ORG) assign the roles to a user which would then execute the role in the child-system it has in its RFC-fields.

some systems, like e.g. BI do not have the same authorization objects as an R/3 core has. to be able to setup a CUA including your BI systems, you could never generate profiles for the BI-roles, because their objects would be unknown to your R/3 (or SolMan) core. This is why you implement such roles using RFC-import from another system (client) (which you have defined in tx. SM59) and using them as 'pointers' only.

You wrote:

"When I reloaded the role from the child system, I was warned that it already existed and would be overwritten but the import log finally showed a red traffic light meaning the role was not imported."

Exactly, because the role is alredy there, but with all objects and no target-system. make a test. delete one of those roles and RFC-load it again from the child. investigate it after it has been loaded. you should find it 'empty'.

as for composite roles:

they are an assembly of roles in the CUA system where the single roles point to 'their' target = child system. so also the composite role needs to 'know' which system is its target = child.

try again. also search sapnet for documents on that topic. i remember having read one that explains the concept a bit more precisely than i would be able to.

[Former Member]

Thanks for continuing to work with me here.

I believe I understand the basics of composite and single roles and the relevant system assignment for each. The problem is that I can't find a viable means of remapping the child systems' roles to their correct systems. There are some test results below which may start to give a clue.

Perhaps if I can safely delete all the single roles (which should live in and be assigned to the child systems) without corrupting the composite roles in the CUA master, then I can do a full RFC read from each child in turn?

The following test has been conducted on all child systems:

1 - create single role with authorisations and generate profile in child system

2 - read role to CUA via RFC

3 - distribute manually via button on PFCG menu tab from CUA

APO/SCM, CRM, BI, WMS children

- read via RFC assigned the destination but did not distribute

- manual distribution works

HR child

- read via RFC does not assign a destination

- manually assigned and distributed the destination without error

ECC6 child

- read via RFC assigns a destination but distribution is not complete

- manual distribution fails with the "Error creating RFC link in system xxxxxxx" pop-up in CUA and a short dump for a missing PRGN_SAVE_ROLE_MENU

- NOTE NOTE NOTE: PFCG in the ECC6 child system shows that the role has been updated (the created column is blank but the changed column is filled with the CUA administration userid and the time stamp is consistent.)

A text comparison still does not fix the imported role assignment. The CUA administration userid in the child system needed access to SMTR_AGRS and PRGN function groups in the S_RFC auth object.

[Former Member]

o.k. since your APO/SCM ... children seem to work ok, let's skip them.

the shortdump in your ECC 6.0 is a known problem. refer to note 996682 for details.

Your RFC-users should be configured (in master CUA and all children) according to note 492589. this is a bit of work and might take a while.

I'm unsure about the HR-child. why does it not assign a destination? Do you get any error-messages? check ST22 for dumps, SM21 for entries in syslog. Check your RFC-destinations and their users (settings) in both CUA master and child.

Message was edited by:

Mylene Euridice Dorias

i deleted the last sentence, because it was nonsense. sorry.

Message was edited by:

Mylene Euridice Dorias

[Former Member]

Hmmmm!

It gets curiouser and curiouser but better too.

My security analyst colleague got frustrated with my questions and test and tried a marginally different approach...

We have used transaction SM30_SSM_RFC to supply variable names for the child systems in our composite roles. This transaction maps the variable name to an RFC destination in table SSM_RFC.

For example, if I have a role structure like the following:

Composite role Z_COMP

contains Z_ECC6_ROLE1 assigned to ECC6 child (via variable "MYECC")

and Z_APO_ROLE1 assigned to the APO/SCM child (via variable "MYAPO")

And table SSM_RFC maps the VARIABLE MYECC to an RFC destination (e.g., ECCCLNT100) pointing to the ECC6 system, and VARIABLE MYAPO does likewise for the APO/SCM (e.g., APOCLNT001) system.

Then, if I read the Z_ECC6_ROLE1 via RFC and specify either ECCCLNT100 or MYECC in the RFC field, the system assignment does not happen. If, however, I choose the pull down menu to select the RFC destination and then choose the VARIABLE radio button and choose MYECC from the listed options, the system assignment does work!

So far I have tested this successfully for my APO/SCM, BI, CRM, HR. Next test is the ECC6 system but I think, despite the other error messages, it may well work since there was one role I successfully imported and assigned but I can't remember exactly how I did that in all the other testing and trying...

[Former Member]

ECC6 system test failed!! No short dumps, nothing SM21.

Note 996682 has already been applied to the CUA master which is where I think it should be. I don't think it belongs in the child from what I've read.

It's home time now... I'll check further in the morning.

[Former Member]

Hi all. Happy New Year.

I've gone around in circles a few times with this problem and had quite a bit of back-and-forth discussion with SAP support. The final outcome according to support is that the download/upload of roles is not designed to transfer the assigned child system so I should be reading them back via the RFC method.

It turns out that reading roles from a child system via RFC is a bit fussy about what you read and in what sequence you do so. By being a little bit careful (fortunately our roles have structured names) it turns out the single roles and composite roles are easy enough to read in provided they are NOT derived roles and provided the selected list of roles being read in one attempt does not include derived roles.

For derived roles, the parent role should be read in only resulting in all the derived children being assigned to the correct system too. Curiously, it seems that if any derived child is included in the list of roles being read in then NO roles are assigned a destination system.

Anyway, it seems that I now have a valid, tested mechanism and it I'll be migrating production tomorrow. Keep your fingers crossed for me!