Central User Administration: Step by Step

The steps listed in the following "roadmap" are required to set up Central User Administration.

Note: Where the term " technical users " is used here, it refers to technical users in terms of user classification for system measurement. In this case, the class of "technical users" represents users for whom no license fees are charged.

The technical users that are used for CUA are of the type "System" (created as such in transaction SU01), although the documentation and the note database sometimes refer to users of the type "Communication". However, this recommendation is out of date, since users of the type "Communication", unlike users of the type "System", are subject to the password change rules.

Setup for the DEV system

DEV: Your central system is client 100 in the DEV system, identified as DEVCLNT100.

QAS: The linked child system is client 200 in the QAS system, identified as QASCLNT200.

Setup for the QAS system

QAS: Your central system is client 100 in the QAS system, identified as QASCLNT100.

DEV: The linked child system is client 200 in the DEV system, identified as DEVCLNT200.

Caution: In a real system landscape, you will only set up one central system.

Note: In the following, only the terms central system and child system are used. Use the figure above to help you if you are no are longer sure which steps you should perform in which client of which system.

Specifying and Assigning the Logical Systems

You can specify logical systems as follows:

1. Log onto your central system with an administration user.

2. In the Implementation Guide (transaction SALE ) choose Sending and Receiving Systems -> Logical Systems -> Define Logical System or start transaction BD54 . Alternatively, you can maintain the table view V_TBDLS using transaction SM30.

3. Choose Edit -> New Entries.

4. In the Log.System column, create a new logical name in uppercase letters.

So that you can later identify systems by name more easily, use the following naming convention for the logical system names:

CLNT###, where you replace with the relevant system ID and ### with the relevant client number.

For example DEVCLNT100

Enter a name of the logical system, such as Central System (CUA) or Child System (CUA).

5. Save your entries, which will then be included in a transport request.

6. Create the logical system name of the central system and of the relevant child system in all child systems.

You have the following options for step 6:

• Send the transport request generated in step 5 (which contains the names of all logical systems) to all other systems in the CUA.

• Perform steps 1 to 4 in all child systems of the CUA. Create the logical system name of the central system and of the relevant child system in each case.

You also use transaction SALE to assign the logical systems.

Choose Sending and Receiving Systems -> Logical Systems -> Assign Client to Logical System

or start transaction SCC4 directly. Alternatively, edit table T000 with transaction SM30.

After you have switched to change mode, you can assign an appropriate entry to the Logical System field in the detail view of the client attributes. You can use the F4 help to do this. Select the appropriate entry, such as DEVCLNT100, if you want to assign this logical system to client 100 in the DEV system. Make this assignment of logical systems for all clients involved in the CUA (in all of the involved systems).

Creating the Technical Users and the RFC Connections

RFC connections are used to exchange data by ALE in the context of CUA. These RFC connections are used to distribute user data from the central system to the child systems, to send changes to this data in the child systems, and to send status reports back to the central system. In the context of CUA, the central system is treated like another child system in some respects. That is, in the simplest case of a CUA (two logical systems linked to each other - one central system, one child system - within the same SAP system), two RFC connections are required. If the central system and the child system are in different SAP systems, three RFC connections are required:

A separate, additional RFC connection is required to connect the central system "to itself." Special users are used for these RFC connections. These technical users are of the type System and their authorizations are clearly delimited using predefined roles.

Caution: Ensure that you take into account SAP Note 492589: Minimum authorizations for communication users.

RFC Connections from the Central System to the Child Systems

RFC connections are required from the central system to all child systems and to the central system itself (loopback).

These RFC connections use users in the child systems for which this naming convention should be sufficient: CUA__###, where is replaced with the system ID of the child system and ### with the number of the client being addressed in the child system.

This user also requires authorizations that are contained in the following roles:

SAP_BC_USR_CUA_SETUP_CLIENT and

SAP_BC_USR_CUA_CLIENT.

However, you should not assign the delivered SAP roles to the technical users, but rather copies of these roles for which you have created authorization profiles with role maintenance (transaction PFCG). For simplicity, simply name the copies of the SAP roles by adding "Z_" to the start of the name, that is,

Z_SAP_BC_USR_CUA_SETUP_CLIENT andZ_SAP_BC_USR_CUA_CLIENT.

RFC Connections from the Child Systems to the Central System

RFC connections are also required from the child systems to the central system. Every child system must be able to create an RFC connection to the central system.

The connection from the child system to the central system uses a technical user of the type System that must be known in the central system. This user should have the following ID:

CUA_.

In this case, stands for the system ID of the child system that communicates with the central system using this user.

This user requires the authorizations of the following roles:

Z_SAP_BC_USR_CUA_SETUP_CENTRAL,

Z_SAP_BC_USR_CUA_CENTRAL, and

Z_SAP_BC_USR_CUA_CENTRAL_BDIST.

Create the roles by copying the template roles (the template names have the same names as the specified roles, but without Z_ at the start of the name) and generating the profiles for them using transaction PFCG.

The first role listed, Z_SAP_BC_USR_CUA_SETUP_CENTRAL, is only required while you are setting up CUA.

Caution: The role Z_SAP_BC_USR_CUA_CENTRAL_BDIST is only required by the user in the RFC connection if the attributes in transaction SCUM are set to Redistribution.

See the section "Setting the Parameters for Field Distribution".

Caution: In addition to the RFC connections from the child systems to the central system, you also require an RFC connection from the central system to the central system. This connection also uses the user with the ID

CUA_, where is the ID of the central system. The required authorizations are contained in the roles

Z_SAP_BC_USR_CUA_SETUP_CENTRAL,

Z_SAP_BC_USR_CUA_CENTRAL, and

Z_SAP_BC_USR_CUA_CENTRAL_BDIST,

After you have created the users listed above with the appropriate role assignments in all of the clients involved , you only need to define the RFC connections in transaction SM59. Follow the instructions below to do this:

1. In transaction SALE in the central system, choose Sending and Receiving Systems -> Systems in Network -> Define Target Systems for RFC Calls (transaction SM59 ).

2. Choose Create.

3. Enter the following data:

• In the RFC Destination field, enter the name of the connection, such as QASCLNT200 or DEVCLNT200.

This entry must be in uppercase letters.

• In the Connection Type field, enter 3

• In the Description group box, enter a short text, such as Connection to child system.

• In the Logon group box, specify the technical user for the relevant connection, such as

CUA_QAS_200 or

CUA_DEV_200.

Caution: Specify the RFC connection in the same way that you specified the logical system that you want to address with the RFC connection. The RFC connection must be specified in uppercase letters.

4. After choosing Return, make the following settings on the Technical Settings tab page:

• If you want to restrict the function of the CUA to a particular server group, you can specify the logon group after selecting the Load Distribution: Yes radio button and choosing Return. Only the delivery logon group SPACE exists in the training systems.

• If you do not want to use load distribution, specify the name of the host on which the central instance of your target system is running for Target Host, and specify the instance number of the central instance.

5. On the Logon/Security tab page, specify the client of the desired logical system and the technical user

CUA__###, such as

CUA_QAS_200 or

CUA_DEV_200 and the relevant password

(in course ADM102, this password is cua).

6. Save this connection.

7. Test the connection by choosing Test -> Connection and Test -> Authorization.

To setup the required RFC connection from the child system to the central system, log onto the child system and perform steps 1 to 7 again. Use the user CUA_ here, where is the SID of your child system. You should also set up the RFC connection from the central system to itself, described above, in the same way.

Note: You can also use trusted RFC connections for the CUA communication. This increases the security of your CUA communication further. For information about configuring the CUA using trusted RFC connections, see the system documentation.

Configuring and Activating the CUA

Once you have successfully activated the CUA, you will no longer be able to create users in the linked child systems using transaction SU01. Before you activate CUA, call transaction SU01 in a child system:

It is still possible to create new users.

The activation of CUA has been significantly simplified, and a number of necessary configuration steps are performed automatically by the system. Follow the procedure below.

1. Log onto the central system.

2. In the Implementation Guide (transaction SALE), choose Modeling and Implementing Business Processes -> Predefined ALE Business Processes -> Cross-Application Business Processes -> Central User Administration -> Select Model View for Central Administration (transaction SCUA).

3. Enter the name of your distribution model, such as CUA.

4. Choose Create.

5. Enter the names of all child systems to be connected (such as QASCLNT200).

6. Save your entries.

7. The result screen Display Logs appears. If you expand the nodes for the individual systems, you normally see the following messages for each system:

ALE distribution model was saved,

Central User Administration activated, and

Text comparison was started.

If problem messages are displayed here, follow the procedure in SAP Note 333441: CUA: Tips for problem analysis.

Check whether it is still possible to create new users with transaction SU01 in the child system.

Caution: The CUA is only fully operational after you have performed the following additional steps.

Setting the Parameters for Field Distribution

For each field of transaction SU01, you can use transaction SCUM to determine the system in which the administration of the field content can be performed.

Setting the Field Distribution Parameters

Global

You can only maintain data in the central system. The data is then automatically distributed to the child systems. The corresponding fields cannot be changed there; they can only be displayed.

Local

You can only maintain data in the child system. Changes are not distributed to other systems.

Proposal

You have maintained a default value in the central system that is automatically distributed to the child systems when you create a user. After distribution, the data is only maintained locally, and is no longer distributed, if you change it in the central or child system.

Redistribution

You can maintain the data both centrally and locally. Every time that the data is changed, the change is distributed back to the central system, and is then forwarded from there to the other child systems.

Everywhere

This option is only available on the Lock tab page. You can maintain the lock data both centrally and locally. However, only the changes made to the data in the central system are distributed to the other systems. Local changes in child systems are not distributed.

Caution: If you subsequently change the distribution from "Local" or "Proposal" to "Global" or "Redistribution", inconsistent data can be created. The only exception is that you can reset the indicators on the Lock tab page at any time without danger.

Ensure that you take into account SAP Note 611972: SCUM: Change to field distribution parameters.

Print parameters (under Defaults) ---------------------------- Proposal

Parameters ------------------------------------------------- Proposal

User group (under Logon Data) --------------------------------- Proposal

Fields for data that the users maintain themselves ------------------------- Redistribution or local

Caution: For information about lock management for your users (such as due to too many failed logon attempts), see the BC-SEC-USR area of the SAP Library.

Synchronizing the Company Addresses

As company address data has already been maintained in all systems of the future CUA, you must first ensure that at least the central system contains all valid company addresses. Then distribute this complete company address set to all child systems, so that a consistent status exists for the company addresses in the entire CUA.

You can use transaction SUCOMP to administrate company address data. You can use transaction SCUG in the central system to perform the synchronization activities between the central system and the child systems by selecting your child system on the initial screen of transaction SCUG and then choosing Synchronize Company Addresses in the Central System. For more information about this, see the documentation.

Note: Alternatively, you can compare company addresses using transaction SCUC. You cannot transfer user data in this transaction.

Synchronizing User Groups

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

Caution: For information about structuring this work as simply as possible, see SAP Note 395841: CUA: Assign target system-specific parameters and user groups.

After importing this SAP Note, the missing user groups from the CUA are created where required.

Transferring Users to Central Administration

After you have synchronized the company addresses, you can transfer the users from the newly connected child systems to central administration. You can do so using transaction SCUG in the central system. To do this, on the initial screen of transaction SCUG, select your child system and choose Copy Users to the Central System.

Different cases are handled differently for the user transfer.

New Users

These users are not yet contained in Central User Administration. By choosing Transfer users, you can transfer the selected users to the central system. All user parameters (address, logon data, and so on) and profiles and roles are transferred. The user is maintained centrally in the future.

Identical Users

In this case, there are users with identical user IDs (the user ID or ID is the string that you enter in the User field on the SAP Logon screen) and matching first and last names. You can transfer the roles and profile data of this user to the central system. The user is then distributed as it exists in the central system. Local data is overwritten. In this case, it is assumed that, for example, the ID "MooreJ" that exists in multiple logical systems, with the last name "Moore" and the first name "Jane", always belongs to one and the same person. In large companies, this assumption is not always correct. For this reason, we recommend that you use unique character strings, such as the personnel number as the user ID.

Different Users

These user IDs exist both in the central and in the child system, but the user has a different first and/or last name. If, in an individual case, these IDs actually refer to the same user, you can transfer the roles and profile data for the user to the central system. The user is then distributed as it exists in the central system. If the IDs do not refer to the same user, use the CUA to create a new user ID in the child system for one of the users and delete the old ID in the child system.

Alternatively, you can assign a new ID to the user in the child system (if different employees have an identical ID in different clients). For this purpose, you can call transaction SU01 in the child system and choose Users -> Rename. If the user transfer is restarted, the user is listed as a New User rather than as a Different User.

Already Central User

These users already exist in Central User Administration and are only administered centrally.

Caution: A new function is available for transferring users (SP38 (BASIS) for SAP Web AS 6.20 and SP02 (BASIS) for SAP Web AS 6.40), which you can call up by means of three new pushbuttons in transaction SCUG, if the Already Central User tab is selected. On these tab pages, you can transfer role assignments, profile assignments, and the license classification of users from child systems, particularly in cases in which (despite CUA being in use) the corresponding administration was carried out until now in the child systems (in line with the settings in transaction SCUM).

Central User Administration is now completely set up for use.

See SAP Note 704412: CUA support for license data maintenance.