Central User Admin - Problem with roles and composite roles

[Former Member]

We have 2 CUA systems (non-prod and prod) with similar, but slightly different problems. I will concentrate on Production here as I suspect the solution may be relevant to both.

I have recently migrated the production CUA system from windows to AIX 6.1.

After the migration the decision was taken to delete the CUA and recreate it again. The main reason to migrate and not reinstall (as was done in dev) was the HR Org structures.

Initially I was informed everything was fine, but a few days after the move I was told that the roles allocated via a composite role were not displayed in blue and could be deleted individually. If the composite role was deleted the individual roles were not removed.

If each of the individual roles was highlighted and "deleted" using they then turned blue and a 'C' appeared in the INDIRECT column.

If this is saved and the user looked at again the lines stay blue, and if the composite is removed the individual roles disappear. We cannot really carry out this process for all our composite roles. Before the move to AIX this problem did not occur.

Development was created via a fresh install, the HO Org structure created anew and CUA rebuilt. The problem in here is very similar, in that if you "delete" the roles they remain and stay blue. If you save the record you can see that table usla04 has a "C" against the

individual roles. If you now look at the user record again all the roles are black. If this record is saved again the "C" dissapears from

usla04.

In Dev I have created a new role and allocated it to a new, and an existing, composite role. Whichever of these composites I allocate to my test user, the individual role id displayed in blue and performs perfectly (it cannot be deleted and it goes when the composite is

removed). I do not have e the access to try this in Production.

How can I correct my existing roles?

Regards,

Paul Richardson

SAP Basis consultant.

[Bernhard_SAP]

Hi Paul,

please have a look at SAP note 1472949.

To repair the already inconsistent users, I suggest to 'RESCUG' the role assignements from the child systems (and also from the central system itself) on the 'Already central users'-tab.

If the indirect assignements have already been overwritten in the child systems, you propably need to remove that direct assignements beforehand, then reassigne through hr-org and tehn take them over again to your CUA central system.

b.rgds, Bernhard

[Former Member]

Bernhard,

Fantastic result. Dev and Production are now performing the same, although still not fully correct.

One more question. By "RESCUG", I assume you simply mean reprocess all the users who are "already central users" with SCUG. I cannot see how to do this on the "already central" tab.

Regards,

Paul

[Bernhard_SAP]

Hi Paul,

on the 'already central users'-tab you have 3 buttons on the top. Choose the 'Role assignements' button to sync the central system with the local role assignements of the child system.

b.rgds, Bernhard

[Former Member]

Bernhard,

Doing what you suggested didn't have an affect. I have also tried a text comparison and that didn't do what I expected either. I feel there is something fundamentally damaged in this system. An example of what MAY have happened (I have only been at this compant 2 months and this system was rebuilt some time last year) is that the development CUA - which contained composite roles made up of roles for a number of child systems - was created with a fresh install and CUA rebuilt. Once this was done I cannot see how the composite roles that were only in CUA could now exist in the new CUA.

I do have a call open with SAP (0000294826) about this, and as I notice you are an SAP employee are you in a position to get someone to look at the call and then I can leave you in peace. If the OSS call is progressed they would also be able to connect to the system and look at what I have.

Also if I try and connect to CUA from pfcg in a child system I get a message "System not reachable or no data exists".

Regards,

Paul

[Former Member]

Bernhard,

SAP have now responded to the call (about 2 minutes after I posted this)!!!

Regards,

Paul

[Former Member]

Bernhard,

Another problem we now have with CUA.

I have patched our 7.00 development CUA system to:

ABA SAPKA70023 from 22

BASIS SAPKB70023 from 22

BW SAPKW70025 from 23

ST-PI SAPKITLRD4 from 2

ST-A/PI SAPKITAB7G from 7E

PI_BASIS SAPKPYM13 from J7L

If I now reset a password from CUA in our R/3 systems that are 620 (patch level 65) the password is changed, but NOT to what I set it to in CUA.

In out 701 R/3 system everything is OK, as are all out other systems based on 700. Any Ideas?

To get around this we have set passwords to be "everywhere" in SCUM, so we can reset the password directly in R/3 but we cannot do this in production.

Regards,

Paul

[Former Member]

This is because your higher release CUA is sending only "upward compatible" password hashes to the 6.20 system.

6.20 does not support the newer hashes, and CUA does not sent a clear text password....

Because of the lower release system attached to your higher release CUA, you will be forced into setting the system profile parameter login/passwords_downward_compatability (see OSS notes) to generate the PASSCODE hash and the BCODE hash.

Locally in the 6.20 system, users can then logon using the 8 character password converted to UPPER CASE.

Locally in the higher release child systems, you can still instruct them to only use the stronger hashing and ignore the truncated and UPPER CASE password hash sent by CUA.

You can also trick them manually by defining a password wizard rule which requests 6 upper case passwords, 1 digit and one special character, with max length = 8. -- > The password will always be UPPER CASE and 8 characters long. This will however not help much for CUA set passwords, as it sends the hash and not the password...

Cheers,

Julius

[Bernhard_SAP]

Hi,

set login/password_downwards_compatibility=1 in your central system. See note 1300104.

Furthermore please assure, that you have the correction of note 1542260 CUA: Initial passwords cannot be distributed.

b.rgds, Bernhard