Setting up a CUA

Note this is only sharing of what I learnt, never to be used as official documentation :).

Overview of CUA

The purpose of CUA is to help make user administration easier and reduce security gaps such as forgetting to lock/ expire a user in one of the systems in your landscape. It also helps in the creation of users by enabling you to create one user in the CUA client, and distributing it to all the daughter systems(of your choice) from just one system.

List of things you can define with CUA:

• Which user masters are in which client
• Which roles and profiles are assigned to these users
• Initial passwords
• Locked users

Pre-requisites

• A large number of identical users in multiple clients
• Complex system landscape with large amount of clients to be managed
• You want the reduction of costs of complex distributed user administration by implementing CUA

Important notes

• Can only be implemented on systems that are 4.6c and above, with latest support packages and kernel patches.
• CUA can be used cross-released, but child systems must be 4.5B and above (with most current Support Package)
• Can be used for BW, CRM and SRM too, but always check the sap notes on how to implement it on those systems.

CUA can also be hooked up to external systems like LDAP using the data exchange method IDoc and RFC as the communication protocol.

Caution:

Make sure roles and profiles are transported separately because setting this up, will no help you to transport roles and profiles to other child systems. To enable the role problems based on CUA follow the note: 571276 (PFCG:Transporting roles using transaction SM30 by setting the USER_REL_IMPORT entry table PRGN_CUST to NO in all the child systems in CUA)

Setting Up the CUA

Note: when creating users, create them as “system” as “communication” users require password change. Also bear in mind that the CUA lies within a certain client, and is not client independent, so all children system may include the ones in the same system, on different clients.

Defining the Logical System

1. Go to Transaction SALE and navigate from Basic Settings  Logical Systems  Define Logical systems, or use BD54.
2. Create a new logical system in UPPER CASE, use the naming conventions: <SID>CLNT### (e.g. QASCLNT100 for a system id of QAS with a client 100)
3. Save, and include it to a transport request.
4. Create all Logical systems for the central system and child systems to be included.
5. Transport the, Transport requests over to the child systems.

Note: you can also edit table T000 with transaction SM30 to define a logical system.

Creating “System” users for Central system RFCs

1. Create a “system” user through SU01 using the following naming convention: CUA_<SID>_###
2. In PFCG assign the following rolls: SAP_BC_USR_SETUP_CUA_CLIENT & SAP_BC_USR_CUA_CLIENT. (please take note that system users cannot have these roles directly assigned to them, so it is necessary to make copies of these roles and rename them with names such as: Z_SAP_BC_USR_SETUP_CUA_CLIENT & Z_SAP_BC_USR_CUA_CLIENT)
3. The role Z_SAP_BC_USR_SETUP_CLIENT is only required for the setting up of CUA and can be removed from child systems later on.

Tip: To increase security you might want to consider the following roles (which is created the same way as the roels you created above): Z_SAP_BC_USR_CUA_CLIENT_RFC & Z_SAP_BC_USR_CUA_CLIENT_BATCH.

Z_SAP_BC_USR_CUA_CLIENT_RFC: Authorization to receive IDocs (assign to the system user described above)

Z_SAP_BC_USR_CUA_CLIENT_BATCH: Update authorization for inbound IDocs (assign to any background processing user you might be using)

Take note: for information on system users, read note 492589: Minimum Authorizations for communication users.

Creating “System” users for Child system RFCs

1. Create a user with the name: CUA_<SID>
2. Assign the following copied authorizations:
   1. Z_SAP_BC_USR_SETUP_CENTRAL
   2. Z_SAP_BC_USR_CUA_CENTRAL
   3. Z_SAP_BC_USR_CUA_CENTRAL_BDIST

Note: the role Z_SAP_BC_USR_SETUP_CENTRAL is only required for setup of CUA.

Caution: Z_SAP_BC_USR_CUA_CENTRAL_BDIST is only needed by a user in the RFC connection if SCUM attributes are set to Redistribution.

You will also need a user for the central system to connect to itself with the following authorizations:

1. Z_SAP_BC_USR_SETUP_CENTRAL
2. Z_SAP_BC_USR_CUA_CENTRAL
3. Z_SAP_BC_USR_CUA_CENTRAL_BDIST

Creating RFC Connection

Use SM59 to create an RFC with the above names. And assign the users created earlier accordingly.

Note: that the RFC connections MUST be in Capitals! And the same name as the logical system .

Configure and activate CUA

1. Log on Central system
2. Go to T-Code SCUA, or SALE modeling and implementing business processes  Configure predefined ALE business process  Cross-Application Business process  Central User Administration  Select model view for central Administration.
3. Enter the name of your distribution model e.g CUA.
4. Choose create
5. Enter logical names of all child systems <sid>CLNT###
6. Save.
7. Results will show you a list of logs, all should be green. In the case there is a problem please view note: 333441:CUA: Tips for problem analysis

Set partners for distribution

1. Go to SCUM.
2. Adjust the settings according to your liking:
   1. Global
      1. The user data can only be maintained by the central system, which then distributes it to the child systems. The child systems however may display the information.
   2. Local
      1. You can maintain the data in the child system. But are not distributed to other systems.
   3. Proposal
      1. You maintain the default details initially from the central system, which is then distributed to the child systems, after which it is all maintained locally and not redistributed.
   4. Redistribution
      1. You can change data both centrally and locally, if it is changed locally it will be distributed back to Central system, then to the other child systems.
   5. Everywhere
      1. This option is only for Lock tab and initial passwords. When you maintain the locks and initial passwords centrally, it will be distributed to other systems, but when you change it locally, it is not distributed.

Caution: If you change from Local/proposal  Global/Redistribution it might cause inconsistency, only exception is the lock tab data being changed without an issue.

Check Note: 611972

Sync Company Addresses

1. Go to T-code SCUG
2. Click on child system
3. Click Synchronize Company addresses in central system.
4. OR you can use SUCOMP to administrate company address data.
5. OR Comapare with child systems using SCUC. (only compare no synchronization tho).

Sync user Groups

To be able to transfer users from a child system to the central system or to distributing them from the central to the child systems, the user group to which theuser is assigned must exist in all systems in which the user exists.

Look at SAP note: 395841: CUA: Assign target system-specific parameters and user groups

Transfer users to central administration

1. Go to Transaction SCUG in the central system
2. Choose the child system
3. Choose copy ysers to the central system

Note: Make sure your users are unique across the landscape before synchronizing.

Checking Distribution Status

1. Go to T-code SCUL
2. View the logs to see

Hint: if the status is unconfirmed, it means that there was not enough dialog work processes available in the child system at that time. If that’s the case you can use BD87 to do post processing of IDocs in the child system. Or you can use Inbound processing of IDocs using background processes, described in note: 399271: CUA: Tips for optimizing ALE Distribution performance.