Central User Management - Restore of Users and auth.

[former_member259023]

Hi Guys!

I have a big question to everyone that can help me or in the past do something like this.

I have my CUA and the systems are connected to the same, and what i want is, everytime that i resfreh, for exemple the Test system from the PRD system, i want to restore my users and auth that are in original in my test system before the refresh, i dont want the users and auth from PRD.

Thanks!

I hope that you can help me.

Best Regards;

Ricardo Nolasco

[Colleen]

Hi Ricardo

Prior to Basis refreshing test can they take a client export of the users and then reapply them after the refresh?

Regards

Colleen

[former_member259023]

Hello Colleen:

Thanks for you reply.

  Well yes, i think it´s possivel, but the objective its to avoid something like that, and try to figure out if the CUA can store the user and import to the system before the resfresh.

   Any ideia?

Thanks!

Best Regards;

Ricardo Nolasco

[Former Member]

I take the approach proposed by Colleen: client copy using SAP_USER taken prior to refresh and then applied back in.  Everything is preserved (users, roles, allocations, passwords).

You could disconnect the target system prior to the refresh and then reconnect post-refresh & using a script to initiate a minor change in the UMR, target system would be refreshed.  Unfortunately idocs would also be sent out for other systems.  The client copy option is relatively low impact & becomes part of the Basis Team workflow & not yours. 

[Colleen]

Hi Ricardo

The CUA stores the SU01 information of the users that is replicated to the child system. It will not, however, store the non-global/redistribute fields as per SCUM settings, passwords, etc.

Alex already beat me to the reply but I'll add my reasoning for the copying - in particular when the refresh is different environment.

I worked on a large user base system (100k+ users) and they did refreshes quite often. One one refresh this place decided to copy Production Enviroment to QA. The issue from a security perspective is that not all Production users has QA accounts. In this particuarly situation, Production was the 100k+ whilst the QA was only about 15k (numbers made up but you get my point for the size I was dealing with).

As a result, there were 85k users in QA that were not required. In addition, the roles assigned to the users were different between the systems (production access were different roles and much more restrictive).

To "sync the CUA" the following was done

1. All NEW users were imported to the CUA via transaction SCUG. This repesented 85k users. However, this meant 85k x 3 IDOCS (USER, ROLE, PROFILE) on a dialogue work process --> very time consuming
2. All the NEW users then had to be deleted out of the system - that's another 85k x 3 IDOCS going back the other direction. Deletion executed via SU10 which also took time
3. All EXISTING USERS - were then redistributed to the child system (use SCUL or mass resend program RSCCUSND) which is 15k x 3 IDOCS for the specifc system. This would then overwrite the role assignments based on the entries in the CUA USLA04/USL04 tables and resend any users that were maintained whilst the CUA was disconnected during the refresh.

We never did all of these activities. In the end I had the CUA disconnected and I deleted the rest of 85k users out of the child system to avoid steps 1 and 2. It involved a heap of table extracts to manually identify users to keep vs deleted as well as more extracts to reconcile that pre and post refresh matched. Not fun!

In addition to all of this, users then had to use their Production password instead of their QA one. Change documents for the system were then Production instead of QA. Finally, a heap of change documents written to remove the Prod roles and reassign the QA

The example I gave was due to an operational procedure devised for client refreshes within a system instead of cross-environment. Unfortunately, this refresh was a bit different and no-one stopped to question the approach was appropriate until it was too late. By then, the additional users were in Prod and had to be cleaned up.

The option I recommended - Basis disconnects the CUA, takes the client export of the users, does the refresh, re-apply the users, reconnect the CUA and then distribute Idocs in SCUL to clear any errors (some would depend on SCUM settings).

Regards

Colleen

[former_member259023]

Hello Colleen and Alex:

  Thanks a lot for your explanation and tips, i think that your view is the correct aproach to the problem

  I will test the proceed.

  Thanks a lot!

Best Regards;

Ricardo Nolasco