Central User Administration has been around for quite a while. Although identity management solutions are slowly replacing it, I still find that it can play a significant role. Quite often, when I talk to customers, they have not had a good experience with central user administration or don’t fully understand how it works.
This guide helps SAP Security Administrators and their management successfully implement central user administration and gain the benefits of doing so.
I will cover the high-level steps required, and essential things to think about to set up central user administration successfully.
What is Central User Administration (CUA), and Why Does it Matter?
If you’ve worked in SAP Application Security, you’ll understand that logging into multiple SAP ABAP systems and clients to make security changes is cumbersome and inefficient.
SAP central user administration (CUA) allows an SAP Security Administrator to maintain users centrally in a master system, thereby improving data quality and reducing effort and duration required in administering users in the landscape. Changes made in the central master system are automatically distributed to child systems using SAP standard application link enabling (ALE) technology.
How to Configure Central User Administration
Many other articles have been written, some in more detail, on this topic, but I hope that my take on it will help you to plan and successfully implement central user administration.
Plan your landscape. What systems and clients will you connect and which of these is going to be the master client?
There is no right or wrong here, but you should carefully consider what setup will best fit for your company.
Hint: I’ve seen a few scenarios where CUA has been implemented from Solution Manager or ERP. My preference is to use ERP for a few reasons: 1: Typically, ERP has the greatest number of users in your SAP landscape than other system types. In most cases I’ve encountered, any user-created in a BW, SRM or CRM (or other) system typically already has a user account in ERP. There are exceptions, of course, but for the most part, this holds true. 2: Position-Based security, if you use Organisational Management in ERP, this is a possible scenario and makes sense for several reasons. CUA works perfectly in this situation and compliments the position-based security model.
Hint: You can have one master system that controls systems and clients from different landscape tiers (Development and Quality Assurance). While this works, I tend to favour having a master system per landscape tier as I find the consistency for testing provisioning scenarios with this approach to be better.
Plan and implement your security. You’ll need system users in the master and child systems with the appropriate access* to set up the CUA and then later to operate it. This step also includes making sure you have the necessary RFC** destinations for each system and client.
*Use the standard roles in the table below as a reference for creating your company roles. Note: this is not a comprehensive list of available roles but is a great starting point; if you need more information, you can look here.: https://help.sap.com/viewer/c6e6d078ab99452db94ed7b3b7bbcccf/7.4.19/en-US/23cbce3b1bc7fa20e10000000a114084.html
|SAP_BC_USR_CUA_CENTRAL||Authorizations for RFC Service User in CUA Central System|
|SAP_BC_USR_CUA_CENTRAL_BDIST||Authorizations for RFC Service Users in CUA Central System (Back)|
|SAP_BC_USR_CUA_SETUP_CENTRAL||Authorizations for RFC Users in CUA Central System (for CUA Configuration)|
|SAP_BC_USR_CUA_CLIENT||Authorizations for RFC Users in CUA Child System|
|SAP_BC_USR_CUA_SETUP_CLIENT||Authorizations for RFC Users in CUA Child System (for CUA Configuration)|
**For this blog, I’ve assumed you are connecting an existing client, and therefore the logical system is defined. If this is a new client, you can find the setup information here: https://help.sap.com/viewer/c6e6d078ab99452db94ed7b3b7bbcccf/7.4.19/en-US/b4b0b13bb3acef3ce10000000a11402f.html
It’s time to define your CUA model in transaction SCUA and remember to perform this step in the master (central) system. Add each recipient (child) system and then click save to distribute and activate the ALE model. After activation, check the log to make sure there are no errors.
You can find additional information here: https://help.sap.com/viewer/c6e6d078ab99452db94ed7b3b7bbcccf/7.4.19/en-US/48b1b13bb3acd607e10000000a11402f.html
Important: After this step, you’ll no longer be able to create users directly in the connected child systems.
You’re almost there! It’s time now to define your field distribution parameters using transaction SCUM. The parameters control which information in the user master record is controlled centrally by the master system and which (if any) can be maintained locally. Consider the available options carefully as each one affects the behaviour and operation of the CUA.
Hint: Having the fields maintained and controlled centrally is great for consistency but importantly achieves the main objective of CUA, which is to reduce the effort required to make changes in multiple systems and clients. There are use cases where you may need to change specific fields locally but keep in mind that this then increases your maintenance effort and you, therefore, lose some of the benefits of implementing CUA.
You can find additional information here: https://help.sap.com/viewer/c6e6d078ab99452db94ed7b3b7bbcccf/7.4.19/en-US/6ab1b13bb3acd607e10000000a11402f.html
Lastly, it’s time to synchronise the addresses and users from each connected system and client into the master, using transaction SCUG. Once this step is complete, you will have a central view of which systems your users have accounts in and their assigned access.
You can find additional information here: https://help.sap.com/viewer/c6e6d078ab99452db94ed7b3b7bbcccf/7.4.19/en-US/8591cd3b11571962e10000000a11402f.html
Congratulations! Once this step is complete, your CUA is ready for operational use.
Tips for Central User Administration
Once you switch over from setup to operation, ensure that you regularly review the distribution logs in transaction SCUL and resolve any errors.
You can find additional information here: https://help.sap.com/viewer/c6e6d078ab99452db94ed7b3b7bbcccf/7.4.19/en-US/cd16b0d7100711d295750000e82de14a.html
Common issues I’ve seen in the logs include:
- Address data inconsistencies, e.g. extension without a phone number or form of address (Mr.) not existing
- User groups not existing
- Printers not existing
- Parameters not existing
Hint: If you identify and correct these issues before you setup CUA, you won’t have to do it during setup.
We don’t plan to fail, but we might fail to plan. Don’t rush into implementation. Plan first and you’ll be set up for success.
Chris is a senior SAP security and GRC consultant, with 11 years experience in security, authorisations, governance risk and compliance (GRC). Chris’s particular technical specialty is SAP HR and ERP security. He has a strong technical background in SAP basis, project release and cutover management. Chris has worked in many varied industries, including Mining, Retail, FMCG, Government and Utilities. Chris has worked/lead all types of implementation scenarios and brings a wealth of experience and skill to the table. His strong skills and experience, means he is able to leverage from this knowledge in implementing best practise security and authorisations solutions.
Comments are closed.