Skip to Content

SCUA, the new and easy magical way to implement CUA

What is the easy and simple way of activating Central User Administration (CUA)via SCUA?

Customers that have implemented the Central User Administration in lower releases have had to read and skim through cookbooks and adhere to the different set-up procedures of the ALE landscape used to propagate the user data and input methods like UserClone in transaction WE20 (managing partner profiles), bearing in mind upper and lower cases for the different methods.

There is good news for you. The setup of CUA is now extremely simple and easy. All you have to do to activate the CUA, regardless of whether you want to set up a complete new CUA just add a new client to the CUA, is activate the CUA via transaction SCUA. So, no more fumbling in ALE configurations and partner profile management is needed!

The process, in short, is as follows:

1. Log on to the new child system and create a communication user for the CUA. Assign this user a customer copy of the following two roles: SAP_BC_USR_CUA_CLIENT, SAP_BC_USR_CUA_SETUP_CLIENT. The latter can be removed from the communication user after CUA activation.

2. Create the RFC connection(s) between central system and client.

3. Create a new logical system for the CUA client

4. Assign the logical system to a client

5. Go into transaction SCUA, enter the logical system and save. This will generate the ALE distribution model including partner profiles.

6. If you configure a CUA newly from scratch you have to customize the field distribution in transaction SCUM.

7. Migrate new users into your CUA central using transaction SCUG.

Let’s look at the details and do it. The CUA landscape we start with is as follows: We have a central system in client 100 on a Web Application Server stand-alone called TT1. We have two child systems in client 200 and 300. Now, we want to add client 400. So, how do we start? Create the communication user on client 400.


So, we log on to client 400 and create the communication user via transaction SU01.


This user has also been assigned the roles Z_SAP_BC_USR_CUA_CLIENT and Z_SAP_BC_USR_CUA_SETUP_CLIENT, which are custom copies of the pre-delivered SAP roles.

Now we have to create the RFC connection. To do this, we log onto the central system client 100 in system TT1 and go into transaction SM59.


We maintain the technical settings for the RFC connection.


And we maintain the communication user in this RFC connection.

What is the next step? To create a logical system for the new client 400. This is done in transaction SALE on the central system. Navigate to the menu path for logical systems and click on Define Logical System.


On the next screen enter a new value for TT1CLNT400 and save.


Then, go back with the green arrow and double-click on Assign Logical System to Client. On the next screen double-click on client 400.


Assign the logical system TT1CLNT400 to client 400.

Please note that the setup of the CUA landscape in our example spares us the burden of creating an RFC connection from the new daughter system client 400 back to the CUA central client 100, because we are in ONE system only, namely the TT1.

What is left to do? Well, all you have to do now is go into transaction SCUA, add the new child system TT1CLNT400 there, and click on save. Let us do it.


After you have saved your entries, you will see the following logs.


So, activities you formerly had to do yourself like creation and generation of the ALE partner model and input of methods in the ALE model are now done AUTOMATICALLY for you.

If you have not configured it yet, you can now maintain the field distribution in transaction SCUM. This transaction allows you to configure on a field level where you want to allow fields of the user master record to be maintained. Optionally you can just take the SAP defaults. So there is nothing to configure in transaction SCUM. The defaults will be distributed when you activate the CUA with transaction SCUA.

Then, you can migrate the users from child system 400 into the central system 100 using transaction SCUG.

For more information on CUA and how to implement it please take a look here: SAP Security Homepage” -> Security in Detail -> Identity Management -> Centralized Administration -> Cookbook: Central User Administration (Web AS ABAP 6.20 or higher release)

Hopefully, this weblog has shown how easy it has become to implement CUA. The crucial transaction SCUA has been powerfully enhanced, so that you are spared the burden of a lot of manual configuration. I hope you enjoy implementing CUA.

You must be Logged on to comment or reply to a post.
  • Hi
    We have configured CUA for managing user admin across 10 clients with different SAP components. But now facing peculiar problem.
    Is there any way through which we can add multiple users to specific role when CUA is configured??
    Actually in CUA, there is one controller client where the userids are created and there is a virtual link to roles (which are created in different child clients). Now when I go to PFCG of Controller client & try to execute some role, system says the role is not present in controller client. So how can I add multiple users to the said role. However if I go to PFCG of particular child client, then the USER tab of PFCG screen is disabled.
    In this sceneriao, I have to go to Su01 in controller client & select user one by one and add the specific role, though I actually want one role to be assigned to multiple users.
    In transaction SCUM, we have defined ROLE ASSIGNMENT as GLOBAL. Is this something related to that setting? Please comment & suggest on this.
    • Hi ,

      You can actually add multiple users to a role using transaction SU01.  From SU01, use the menu Environment->Mass Changes.

      Here you can manually add the users, select them by address or authorisation data.  Once you have your user list, you can then add or remove roles and/or profiles.

      That should do the job.



    • Hi Shailendra,

      when using CUA the idea is to create and maintain all users including role assignment centrally. That is why the tab strip user assignment in the profile generator (transaction pfcg) is not available, because you should not do the role assignment locally in transaction pfcg any more, but centrally.

      You can use SU01 to assign a role to a user per logical system. Make sure that you perform the text comparison in the role tab strip in SU01 first to read all new role names into the central system.

      You can use SU10 to do mass changes to multiple users including role assignments per logical systems.

      Hope this helps.

      Kind regards,
      Gerlinde Zibulski

  • Hi,
    Is there a way in which we can get the user creation   using function module in CUA master, which replicates to child CUA.
    BAPI_USER_CREATE1 doesn't seem to support this functionality. No input param to take the child systems. Also would like to assign different roles in child systems while creating the user.

    However BAPI_USER_LOCK and unlock works perfectly, without any special coding.

    Any suggestions:)-

    Best regads,

      • Hi Gerlinde,
        Your suggestions works. Role assignment was the problem. If no role is assigned, the user is kept in dormant state.

        As an information to other interested parties: BAPI_USER_CREATE1 is not adhered to transaction concept. User is created even before the commit is called.
        Heard that this is being fixed in the new version of UM API.

        Best regards,

        • Hi Pavan,

          am glad to hear that the information helped.

          Both of your statements are correct. The BAPIs directly update the database and perform in most cases a COMMIT WORK.
          However, the new API will adhere to the transactional concept.

          Kind regards,

  • Let me try to take this very slowly; it's complex.

    I have a development environment, a test environment and a production environment (plus prototype and a project dev and test).  Each environment includes ECC6, SCM, BI, CRM and HR managed by CUA.  Each environment, presently, has its own CUA system.

    Our security model works on the basis of "Job Definition".  In this context, a Job Definition is an SAP Composite role, stored in the CUA system, which includes roles from one or more child systems.

    When a new role is developed in a child system, it is read into the corresponding CUA system to be included in the appropriate Job Definition then the Job Definition (composite role) is transported from DEV to TST to PRD CUA system and the child roles are transported from DEV to TST to PRD in their respective application systems.

    Security roles are assigned to users by means of the Job Definition which contains one or more system/role pairs.

    This all works because the ECC6 systems are all  logical system ECC6, the HR systems are all logical system HR etc.  This means that the Job Definition, in logical system CUA, assigns (for example):
    RoleX in ECC6
    RoleY in ECC6
    RoleZ in HR

    and the role/system relationship does not change when the Job Definition is transported.

    The problem is that a logical system maps to only one client.  Thus, if I have a second client in the test system, I cannot manage both clients from my test CUA system.  Furthermore, I am trying to consolidate my CUA systems so I have only two - production and non-production.

    I have looked at transaction SM30_SSM_RFC and this has allowed me to map things like logical system ECC6 to RFC destination DEVCLNT100 to read in a Job Definition or role but then I can't assign that Job Definitions to TSTCLNT100 and have the internal roles correctly assigned (they'll belong to ECC6 and the SM30_SSM_RFC mapping will point them to TSTCLNT100).

    Have I missed something or am I trying to build an impossible configuration?

    • And the final challenge...

      I want this model to be extensible so that as projects come and go I can build systems or clients and add them into the non-production CUA system without having to redesign everything.

      • Hi Murray,

        adding and deleting child systems to a CUA should be fairly easy. Is done via transaction SCUA and automatically generates the ALE landscape.

        However, your problem seems to be rooted in the role assignment and the fact that a logical system only maps to exactly one client.

        Kind regards,
        Gerlinde Zibulski

        • Hello Gerlinde

          Thanks for looking at this.  Let's try to simplify the problem a bit then build up until the model breaks.

          Initially, let's just assume I have an ECC6 landscape with DEV, TST and PRD each with client 100 only (ignoring standard clients 000, 001, 066).

          According to the de facto SAP standard, this would produce logical system names DEVCLNT100, TSTCLNT100 and PRDCLNT100 respectively. 

          Assuming I need to develop my roles in DEVCLNT100 and transport them to TSTCLNT100 and PRDCLNT100 what do I need to set up for a CUA client or system. 

          Your example seemed to infer that I could set up the CUA client in the DEV system (e.g., DEVCLNT999) but can this then administer TSTCLNT100 and PRDCLNT100. I think so as I would assume that I can transport the roles as described above then simply assign the role and system combination in each case.  This would also work when I created DEVCLNT200 and DEVCLNT300 etc.

          Am I right so far?  If so, I'll extend the scenario and try to break the model....


          • Hi Murray,

            your assumptions are correct. What you describe above is absolutely doable. However, I would probably use the following logical system names prefixing with the ECC for the landscape: ECCCLNT100, ECCCLNT200 and so on. If you use DEV, TST and PRD as the prefix you can only use this for one landscape once. And it is more use to identify the system landscape in the logical system name. That would give you the option to add children of other landscapes (APO, SRM etc) to your CUA later on and you'd be adhering to the SAP naming recommendation for logical system names.

            Kind regards,
            Gerlinde Zibulski

          • Hello again Gerlinde and thanks.

            Absolutely agree with your comments about naming conventions.  My system IDs here were purely illustrative - the real ones are more rational.  For purposes of this discussion I will stick with DEV, TST and PRD just to keep the implied transport path clear.

            Now I'm going to try to extend and (hopefully not) break the model. 

            Let's add the APO landscape now and start to look at the Job Definition first mentioned in my earlier post. 

            The current configuration has three systems and I have three clients (100, 200, 300)in DEV plus the CUA client (999) there too. I'll add DVA, TSA, and PRA systems each using only client 001 (logical systems DVACLNT001, TSACLNT001 and PRACLNT001).

            Now I can easily add these systems to the CUA model and create a user with roles in each.

            Let's create role Z_ECC6_R1 in DEVCLNT100 then transport that to DEVCLNT200, DEVCLNT300 and, after due testing of course, to TSTCLNT100 and PRDCLNT100.  I can now assign any combination of system name and role to a user unambiguously even granting the same role in DEV, TST and PRD.  Similarly I can create Z_APO_R1 in DVACLNT001 and transport and assign that.

            Let's say my user profile now looks like this:

            I can work with that and have access in each system as required.  No problem so far?

            The problems start to arise when I create composite roles in the CUA client (DEVCLNT999) and combine system names and roles here.  Let's say I want to create a Job Definition for an APO user - Z_APO_USER - and include the above profiles in it.

            This role now looks like

            If I wish to grant this same access in the production environment I'd expect the profile to role to look like this

            For SOX compliance and segregation of duties reasons, I want a separate CUA client (PRDCLNT999) for my production systems but, ideally, only one client to manage ALL the non-prod systems.

            Now, if I create the composite role in DEVCLNT999 and transport it to PRDCLNT999, the system names in the transported roles will be non-production systems and, therefore, the access won't be granted where it is required.

            I've looked at transaction SM30_SSM_RFC and I think I can see a way through if I create mappings in DEVCLNT999:
            ECC6 -> TSTCLNT100
            APO  -> TSACLNT001

            and PRDCLNT999:
            ECC6 -> PRDCLNT100
            APO  -> PRACLNT001

            If I do this, I can then create the Job Definitions above as

            and transport that but I would then need to manually assign the additional roles and systems for the development clients.

            Am I making sense?

          • Hi Murray,

            you are using the same role with the same name in different clients and transport them through your landscape. No problem so far.

            The problem with composite roles that combine single roles pointing to a specific RFC/logical system in a CUA landscape is that the single roles have to have different names in the different backends then. So after you transported them into a client you'd have to create a local copy, e.g. Z_ECC6_R1_DEVCLNT100, Z_ECC6_R1_TSTCLNT100 etc.

            Transaction SM30_SSM_RFC maintains a table of names for RFC destinations which only makes sense when you have two or more CUA landscapes, e.g. one CUA for your production systems and one for the rest.

            Hope this helps and kind regards,

    • Hi Murray,

      I might not have understood your problem correctly, but unfortunately there is no other way. A logical system only maps to one and exactly one client.

      Gerlinde Zibulski

  • Hi Gerlinde,

    i have a situation here. I have my CUA shut down but still have two child systems online. I need to administer the accounts on child systems, so can i remove the Child systems from CUA without having the CUA system turned on.

  • Hello,

    Quick question for you, we just implement CUA and we are facing a small problem.  Here we have multiple test systems, each of them used by a subset of users and refreshed on a regular basis.

    The problem is when unlocking users, we certainly do not want to unlock them globally so the best approach is we go in CUA to assign roles and then we need to go into the child system to unlock the users. 

    Since we have 2 different groups of users that do unlock we want to keep it at the child level.

    Any solution for us

    Thank you

    • Hi Josee Dion,

      I am not quite sure that I understand your problem correctly.

      From the CUA Central you can globally lock/unlock users. If you want to unlock users in a specific child system, an admin has to log on to that system and lock the users there.

      So you are right. After a system refresh, you'd have to assign the system specific roles again for the refreshed child system and unlock the users in that child system.

      Was that your question?

      Kind regards,
      Gerlinde Zibulski

  • We are implementing ECC 6, BI, EP, ER, and PI in a 5 system landscape, sand, dev, qa/training, prd.  We have about 8000 employees and 1200 SAP users and we use ESS.

    We are also looking at using postion level security from HRM.  Is it best practice to use one CUA for non-prd system and one CUA for prd systems or should we use a single CUA for all systems?

    The next question would be in which system should we locate CUA, Solman, ECC or on its own system?

    Thanks for any advice you may have.

    • Hi Rick,

      you will gain the most bang for the buck if you implement one CUA for all of your systems. That is you will be able to reduce administration efforts to the minimum.

      However, there are customers that have more than one CUA. Reasons for this are mostly organizational, where the Asian IT is only working on systems in Asia or where the business wants all HR systems de-coupled from all the other SAP systems.

      As to where the CUA central should reside half of our customers use their productive HR system/R/3 system, since most of their users/employees are already in there and do not need to be migrated. The other half uses a Web AS/NetWeaver App Server stand-alone so they can easily import patches or upgrade this system to the next release without interfering with product systems. The latter is the SAP recommendation also for the just mentioned reasons.

      But to be honest you can install it anywhere you like actually.

      As regards to position-based security in HR, you have to know that either you use this in your HR system and then do the user administration locally in this HR system landscape without integrating it into your CUA.

      Or you have to set up your user and role administration in a specific way for your employees to integrate it with HR. If you want to go for this option, you'd have to synchronize the org structure into your CUA Central unless the HR system is the CUA central. Secondly you can only assign composite roles to objects in the org structure, when you want to use position-based security integrated with CUA. These composites must combine single roles, where the RFC destination is defined. This is a rather rare set up for roles, but again it only applies if you want to use position-based security in combination with CUA.

      Hope this helps and kind regards,
      Gerlinde Zibulski

  • Hi

    The documentation implies that the RFC destinations linking the CUA master and CUA child systems MUST be named using the respective logical system name. 
    For example, system CMS client 100 (my sample master client) has logical system name CMSCLNT100 and the child is, for example, PRDCLNT200. 
    To connect these I appear to be required to use RFC destination PRDCLNT200 in the master system and a destination named CMSCLNT100 in the child.
    These RFC destinations will be created with security credentials allowing a fairly well controlled level of access.  However, because the RFC name MUST match the logical system name, there will be other connections (perhaps from another client in the master or child systems) which need to communicate over the same RFC destination with different authorisation requirements.
    My specific situation is that I'm using my Solution Manager system for a number of functions (in different clients): Rev-Trac master, TMS domain controller, Solution Manager system monitoring, CUA master for production systems, CUA master for non-production systems.
    Rev-Trac, TMS and Solution Manager use their own RFC destinations and the two CUA master clients will not need to access each other's children so I think I'll be OK but I want to know if I am OBLIGED to use these names or if I can map LS to RFC explicitly (e.g., access PRDCLNT200 via RFC destination CUA_PRD200).

    • Hi Murray,

      this is only and SAP recommendation and you are not obliged to do so.

      However, it is mandatory that you use the same name for the RFC destination and for the logical system if you used the field RFC destination with roles.

      Hope this helps.

      Kind regards,
      Gerlinde Zibulski

      • Thanks Gerlinde,

        I looked in the configuration and the documentation and could not find how to map the connection between the CUA reference to a Logical System and an RFC destination.  When I build the CUA model in BD64 there is nowhere to do this mapping.  What am I missing?


  • Hi all.  Need some bright ideas to explain an incident which has occurred twice in the past week.

    For no (as yet) explained reason and by no (as yet) identified process, the userid which administers security in our ECC6 child system lost its SAP_ALL profile (it's got more than security access so it gets SAP_ALL instead).  We can see SCUL entries in the CUA master showing the removal but can't see anything in transaction logs showing who did it or what transaction was used (apparently NOT SU01!).

    The iDoc logs in the child system show the user being cloned and another iDoc with BAPI Method "Assign profile" (I think) with three profiles in the data segment but SAP_ALL is the third line on the screen.  When the user stopped administering security due to lack of access, we noticed that it only had the first two profiles assigned.

    We assigned a different user (with enough access) to the RFC destination in the CUA Master and resaved the administration user and everything started working again.

    1) apart from a user using SU01 to save change the admin userid, what other process could cause CUA to update a userid in a child system?
    2) if the admin user needs a change to its authority which removes its ability to do user administration in one profile and adds it back in another, at what point in the process does the removal take effect relative to the addition of the alternative profile?  (e.g., if I took SAP_ALL away and assigned Z_CUA_ADMIN instead, would it work or would the removal of SAP_ALL remove the authority to assign Z_CUA_ADMIN?)

    This is important to us because the userid is used for a number of connections (back to that question about RFCname=LogicalSystemName!) - CRM creates sales orders, WMS co-ordinates stock movements, HR updates finance to pay my salary (!!!) and CUA manages security all via the same RFC with the same userid.  Our HR people want to know why, our distribution people want to know why, our sales people want to know why.