Fundamentals

User information is stored in a client-specific manner in SAP systems. That is, every client in a system has its own, independent group of permitted users. If you have a complex system landscape in your company, you might have more than one of the three standard system types (DEV, QAS, and PRD).

Classically, users are maintained in the respective client. If, for example, a developer retires from your company, you must ensure that the relevant system user is removed from all affected clients; ideally, you must ensure that the relevant user is locked. If you do not know exactly which areas your colleague worked in as a developer, you need to log onto every single client that he may have used, and manually search for and remove the user. In complex landscapes, this task can easily become confusing. There may, therefore, be potential security gaps in your user administration. This can result in large costs for consistent user maintenance.

Note: Users that are no longer to be used for logging onto the SAP system should be locked and not deleted.

As you can see from the figure, the number of "interesting" clients (that is, clients other than 000, 001, and 066) to be administrated is 17, even in this simple example. The clients shown are used for different purposes, for example, client 200 is not required in the production system in the R/3 Enterprise system.

Concept of Central User Administration

The aim of Central User Administration is to reduce the cost for user administration and to make user administration more secure by centralizing the work. The concept of Central User Administration (CUA) envisages only a single client for maintaining user data; that is, you determine the following list of points at a central location in your system landscape.

What You Define with Central User Administration

• Which user master records exist in which clients?

• Which roles and profiles are assigned to these master records?

• What are the initial passwords?

• Is the user locked or not?

The above user data is managed in only one place. This means that you can have an overview of the situation for managing your user data. Before you decide to implement CUA, the following prerequisites should exist in your system landscape; otherwise the work reduction due to the implementation of CUA will not be optimal.

Prerequisites for Efficient CUA Implementation

• There are a large number of identical users in multiple clients

• There is a complex system landscape with large number of clients to be managed

• You want to reduce the costs of complex, distributed user administration by implementing Central User Administration

The prerequisites above are not entirely self-explanatory. If, for example, you have a "standard three-system landscape" in which the users each primarily work in one client, and the user groups in the different clients are almost disjunctive, the cost saving due to the implementation of CUA is not particularly large. The situation is similar if you use identical users in multiple clients, but your system landscape only contains a few clients, or the number of administered users is not especially high in total.

Using CUA, which resides in a dedicated system, you can now distribute the following information from the central system to the child systems by Application Link Enabling (ALE):

Which users exist in which system, in which client, and with which roles and profile assignments. You can also distribute the initial password.

The following list contains important notes for implementing CUA.

Notes on Implementing CUA

1. Use a system with a release status of at least SAP Basis 4.6C. Your system should be as up to date as possible, with the latest Support Packages and kernel patches.

2. CUA can be used cross-release, although a linked system must have at least SAP Basis 4.5B (and should also have as current a Support Package status as possible).

3. CUA can also be used for user administration in BW, CRM, and SRM systems, for example. However, you should search for SAP Notes about this topic in the SAP Notes database before implementing CUA, and take these into account.

In an ALE integrated system, SAP and non-SAP systems may be in contact. The systems linked to each other are called logical systems. The logical systems in the context of CUA are, in this case, the clients involved. That is, a single SAP system can house multiple logical systems in terms of ALE (and CUA). Data exchange in an ALE integrated system is performed by exchanging intermediate documents (IDocs) by Remote Function Call (RFC).

Caution: Ensure also that if CUA is in use and role definitions are transported (by means of transport requests from one system to another system), the user assignments to the roles are not transported.

If CUA is in use and role definitions, including user assignments, are transported at the same time, discrepancies might arise in the user assignment to roles.

You can avoid these problems as described in SAP Note 571276: PFCG: Transporting roles using transaction SM30 by setting the USER_REL_IMPORT entry in table PRGN_CUST to NO in all the child systems in CUA.