Central Central UserUser Administration Administration

04/09/23

2

• In complex system landscapes with several clients in different systems

• Users work in more than one system

• Administration on users forces administrator log on to relevant systems..

Enormous administration effort

Manual effort to synchronize user data in all the relevant

systems

• Lack of control can result in security weakness

Situation Of Administrator In User AdministrationSituation Of Administrator In User Administration

04/09/23

3

•Administration of whole system landscape from a single system

•Over view of all user data in the whole system landscape

•Consistent user data in the whole system landscape

•Additional Local maintenance still possible

The Solution –Central User AdministrationThe Solution –Central User Administration

04/09/23

4

•Once you configure CUA users can only be created or deleted in the central system.

•User attributes can be maintained only locally, only centrally, or both centrally and locally

•Therefore, the required roles and authorizations must exist in active form in all child

systems.

•As a result each user only has to be administered once centrally which gives the

administration a much clearer overview of all users and authorizations.

Benefits – Central User AdministrationBenefits – Central User Administration

04/09/23

5

•Users are created and maintained via user maintenance transaction SU01 in

the central system.

•Distribution of initial passwords or passwords reset possible

•Central user lock possible

•Maintenance of local fields via su01 is possible by local administrators in the

child systems

•Input only possible for those fields where maintenance is allowed.

Use Of Central User AdministrationUse Of Central User Administration

04/09/23

6

Central system of CUA

Child Client2Child Client1 Child Client3

• users can be administrated in

central system

•Automatic distribution to child

systems

•Local administration still possible

•No inconsistencies

CUA is recommended >= 4.6 c

ALEALE ALE

Central User Administration using ALECentral User Administration using ALE

04/09/23

7

Configuring the ALE Scenario

•Naming and assigning logical systems to clients

•Creating the communicating users (which are used in the RFC interfaces) for all

clients

•Creating RFC destinations

•Create the model view and distribute the model view

•Activating CUA

•Synchronizing the users

Setup Of System InfrastructureSetup Of System Infrastructure

04/09/23

8

We need to set attributes for each user field and distribute them and options are..

•Global : changed only in the central client changes are automatically created

•Proposal : Default value, maintained on the central client, only gets distributed when user

is created.

•Local : Data can be maintained on the child system

•Everywhere: Data is maintained both central and child system. Changes made in the

central client are distributed to other systems

•After configuring CUA attributes could be set in SCUM Transaction Code

Field selection and their optionsField selection and their options

04/09/23

9

Each Acton in the child system sends a log back to the central system. Log contains all

•Errors

•Warnings

•Success Messages

These logs can be viewed in SCUL transaction code in the central system

LogsLogs

04/09/23

10

Integration of CUA child systems has to be done one by one using the migration

tool. (SCUG transaction code)

•Analyze which users have to be transferred

•Migrates user master data

•Migrates assignment of profiles and roles

•Detects conflicts with inconsistent user names

Prerequisite for migration : same user id and user name in

all systems

Integration Of Existing UsersIntegration Of Existing Users

04/09/23

11

•Define the first child system, choose the one where user data is most complete

•Use migration tool (SCUG) to migrate the data to the central system.

restriction on selected users is possible

•Define next child system

•Use migration tool to compare user data

New users : User does not exist in the central system

Identical users : User already exist in the central system, user id is identical

Different users : User already exist in the central system, user id is not identical

Already central users:User has already been transferred to the central system

Migrate UsersMigrate Users

04/09/23

12

Use migration tool (SCUG)to transfer the selected users to the central system

•If user does not exist in the central system transfer all the data.

•If user already exists in the central system transfer assignments(system, user

roles, profiles).

Migrate UsersMigrate Users

04/09/23

13

Central admin system

CUA central system

CUA child

systems

DEV

QAS

PRD

CUA in separate system

•No performance impact on production system

•Independence from planned down time for production system

•Access to user management can easily be controlled

Disadvantage:

•Additional hardware and

administration cost

Advantages:

System Landscape for central user AdministrationSystem Landscape for central user Administration

04/09/23

14

PRD - CUA central system

QAS

DEV

CUA in production systemAdvantages:

•No additional hardware and

administrational cost

Disadvantages:

•Performance impact on PRD system

•No user administration during the down

time of production system

•Maintenance of cua causes PRD down

time

•Access to user management can be

controlled only is separate clienton PRD

server is set up

CUA in Production systemCUA in Production system

04/09/23

15

CUA client system

QTY

PRD

DEV

DEV QTY

PRD

CUA client systemCUA central system

One Global CUA for different LandscapesOne Global CUA for different Landscapes

04/09/23

16

Advantages:

•Require little recourses

•Consistent user master data in the whole system landscape

•One single point of administration and control

Disadvantages:

•Maintenance of cua has immediately impact on production system – no test of cua

functionality possible

•Unavailability of central system will have impact on whole landscape

•Planned down time for CUA central system is b e confirmed by all system owners

04/09/23

17

Removal Of CUARemoval Of CUA

•Log on central system and run RSDELCUA to delete one of the child system

•Delete message types cclone and user clone for the selected child system

•Delete the complete partner model

•Execute BD64 and in change mode delete the methods for deleted child and save

it

•Log in to every child system to be deleted.

•Run RSDELCUA report

•Once this is done complete partner profile can be deleted.

•Need not to delete RFC connections

04/09/23

18

Screen ShotsScreen Shots

Define and assign logical systems to the specified clients using the transaction SALE.

04/09/23

19

04/09/23

20

Assigning logical system to the clients

04/09/23

21

Creating RFC destinationsCreating RFC destinations

Execute SM59 create R/3 connection

04/09/23

22

Give logical system name of the child client in the description field and

hostname, logon language, login client, RFC user id and password.

04/09/23

23

Execute scua and give name of the model view and save it.

Creating Model ViewCreating Model View

04/09/23

24

Give the logical system name of the child client that are to be included in the model view

and save it.

04/09/23

25

04/09/23

26

In the screen of SUO1 (central system) transaction a new tab SYSTEM

will be added after configuring CUA where you can include the child systems whenever necessary

SU01 screen of central clientSU01 screen of central client

Systems Tab

04/09/23

27

SCULSCUL

Each Acton in the child system sends a log back to the central system .

04/09/23

28

SCUMSCUM

After configuring CUA attributes could be set in SCUM Transaction Code.

04/09/23

29

Thank you