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