Skip to end of metadata
Go to start of metadata

Purpose

 

Vers.1.31.03.2016

This is a summary of the most common problems related to CUA (Central User Administration), which have been reported by different customers during the last years.

 

Overview

 

Precondition:

The CUA has been set up as documented, available documentation for instance at:

https://www.sap.com/corporate/en/company/security.html, or
https://service.sap.com/~sapidb/011000358700001037122002E/October_670_change.pdf , or http://scn.sap.com/docs/DOC-17019 ,
etc.

 

Any ‘alternate’ approach / setup (for instance the usage of different logical system names) can/will lead to unexpected behavior and effects and is therefore not supported by SAP.

 

Sections

 1. Issues in the central system:

1.1.     Role/profile cannot be assigned, message for instance ‘Role xyz does not exist’
1.2.     SCUL: entries stay unconfirmed
1.3.     SCUL: strange error messages
1.4.     Role assignment exists in PFCG but not in SU01

 

 2. Issues in child system(s): 

2.1.     No IDoc arrives
2.2.     IDoc is not processed
2.3.     IDoc is processed but status is not 53
2.4.     IDoc is processed correctly, user is updated, but SCUL stays ‘unconfirmed’ in central system
2.5.     SU01: edit/create/delete buttons available
2.6.     Password gets deactivated instead of initialized

 

 

 

 

1.     Issues in the central system:

 

1.1.    Role/profile cannot be assigned, message for instance ‘Role xyz does not exist’

 

The central system must know, which roles/profiles exist in the child systems. Therefore it is necessary to send this information to the central system. This is done using the ‘text comparison’ (refer also to SAP note 1642106 – CUA | PFCG: Automatic text comparison of roles for central system ). If started from the central system (i.e. SU01), the collection of data is triggered by RFC (using the RFC connections pointing to the child systems) in the selected child systems. The information is sent from the child system through the RFC-connection pointing to the central system. The information contains the logical system name of the child system and the corresponding role name/profile name/license data information.

So the text comparison needs to work properly.
Preconditions to work properly
:

    • Proper configured RFC-connection from central system to child system, including correct technical setup, correct connection name (i.e. logical system name of the child system) and assigned RFC-user with sufficient authorizations (see SAP notes 492589 and 2000585)
    • Proper configured RFC-connection from child system to central system, including correct technical setup,  correct connection name (i.e. logical system name of the central system) and assigned RFC-user with sufficient authorizations (see SAP notes 492589 and 2000585)
    • Correctly set logical system names (SCC4)

 

In case the text comparison succeeded, you will find the known:

    • roles                              in table USRSYSACT,
    • profiles                          in table USRSYSPRF and
    • License data                  in tables USRSYSU*.

To check it child system wise enter the logical system name of the child system into the selection field ‘Subsystem’ (SE16).

 

It is absolutely necessary to follow the ‘golden rule’ for the CUA Setup:

‘System name in the CUA landscape’ (maintained in SCUA)
= ‘logical system name’ (maintained locally in SCC4 in each system)
= 'name of the RFC-connection' pointing to that system (maintained in SM59)

 

This mapping of the logical system name to the RFC-Destination is hard coded in some places of the CUA functionality. The CUA central system must also know about the logical system names of all connected child systems via the view V_TBDLS.

An easy way to perform a quick check of the technical setup is to use the report RSUSR_CUA_LANDSCAPE_CHECK (SAP note 2108938 - CUA: Analysis of existing CUA landscape).

The report provides a quick overview about the current setup.  It provides a detailed documentation (red question mark button), navigation to more detailed information, etc.

 

Example: In the result list of report RSUSR_CUA_LANDSCAPE_CHECK: double-click on the red traffic light next to system QNXCLNT500 provides details of the cause of the problem:

 

                       

 

 

 

A double-click on a child system name provides the information from point of view of the child system. Example:  double-click on ‘UI3CLNT323’  on the above screen results in:

 

 

 

 

 

 

1.2.    SCUL: entries stay unconfirmed

Problem: perform a change of a user in the central system. This change is relevant also for assigned child systems. In SCUL the corresponding entries for the child systems never get the green (successful) or a yellow/red status (warning/error). They just stay grey (‘unconfirmed’).

There exist several possible causes. In most cases, the problem is located in the child systems (check sections 2.1. – 2.4. below).

Furthermore to be checked in the Central system:

-           RFC-connection to the child system is not working

        • Technical setup
        • RFC-user with sufficient authorizations (see SAP notes 492589 and 2000585)
        • Connection not registered (SMQS) (errors are displayed in SM58)
        • SAP Note 802062 - Logging in SM58

-           Inconsistent CUA Landscape (setup, for instance wrong system name[s] etc., please refer also to 1.1.)

-           Number range problem (EDIDOC)

 

 

1.3.    SCUL: strange error messages

 

Cause: Missing SCUM-entries in the child system
For so far unknown reasons it may happen, that not all SCUM settings are available. In such a case you will notice empty or missing tabs in SCUM (in the child system).

The missing entries can be restored by importing the table content of the USRFLD*-tables from a system with similar basis release. Afterwards the SCUM settings have to be saved once in the central system so they get synchronized in the child system.

An indication is, that some fields are open for modification in SU01 in the child system, although the SCUM settings in the central system are set to ‘global’. Messages, which indicate such a problem:

-           You have not logged onto the central system

-           You must specify a surname when you create a user

-           No company is assigned

 

 

 

 

 

1.4.    Role assignment exists in PFCG but not in SU01

Background: in opposite to a standalone system, the local role assignments based on table AGR_USERS are not displayed in SU01 called in a CUA central system. AGR_USERS does not have a target system field, which is required for target system specific assignments. Therefore in CUA case a different table is used: USLA04.
(For child system specific Profile assignments table USL04 is used, see also: SAP Note 161347 - CUA: Tables in central user maintenance.)


If not a proper setup of the CUA was used and inconsistencies exist, role assignments may exist in the local AGR_USERS table in the central system, which are different with the assignments in table USLA04. The consequence is, in SU01 those (AGR_USERS-) assignments are not visible. In PFCG, which is a “local” and not CUA related transaction, they are visible and the user has the authorizations from that roles. Such inconsistencies may occur for instance after client copy actions, etc.

Solution in such cases (depending on which actions have led to the current situation):

-           take over users again with SCUG (for the Central system itself)

-           restore USLA04 and USL04 from before the client copy action/system refresh/etc.

-           re-setup the CUA

 

 

 

 

2.    Issues in the child system(s):

 

2.1.    No IDoc arrives

Possible causes:

-           Insufficient configured RFC connection from central system to child system.


To be checked in this case:

            • technical setup
            • connection name (i.e. logical system name of the child system)
            • assigned RFC-user (existing in child system) with sufficient authorizations

-           Number range problem of number range object EDIDOC (visible also in SM58 in the central system then)

-           Wrong partner profile settings (WE20)

-           Problem in the central system (see checks mentioned in point I.2. above)

 

An easy way to perform a quick check of the technical setup is to use the report RSUSR_CUA_LANDSCAPE_CHECK (SAP note 2108938 - CUA: Analysis of existing CUA landscape).

 

 

2.2.    IDoc is not processed

Possible causes:

-           The own logical system name is not set correctly

-           Not enough resources for IDoc processing (leads to IDoc status 64)

-           Insufficient authorizations of the user-ID, which shall process the inbound IDoc (must not be the RFC user…)

 

An easy way to perform a quick check of the technical setup is to use the report RSUSR_CUA_LANDSCAPE_CHECK (SAP note 2108938 - CUA: Analysis of existing CUA landscape).

 

 

2.3.     IDoc is processed but status is not 53 (application document posted)

 

  • Status 51 (application document not posted)
         -->  Due to an error the IDoc processing was cancelled.
               Also, if it is possible to reprocess these IDoc locally in the child system, NEVER (!) ever do it!
               Rather redistribute the entire user in SCUL. Otherwise, you possibly update the user with outdated data.
               Please refer also to SAP note 943609 - CUA: Reposting unsuccessfully updated IDoc

 

  • Status 68 (error, no further processing)
    -->  This status was created as of SAP note 1833088 - CUA: Updating incorrect IDoc to avoid the before mentioned local reprocessing of IDoc, as IDoc with status 68 cannot be reprocessed.

 

 

 

2.4.    IDoc is processed correctly, user is updated, but SCUL stays grey meaning ‘unconfirmed’ in central system

Possible causes:

-           incorrect logical system name of the child system

-           Wrong configured RFC-connection from child system to central system.
            To be checked in such case:

        • technical setup
        • correct connection name (i.e. logical system name of the central system)
        • assigned RFC-user (existing in central system) with sufficient authorizations (see SAP notes 492589 and 2000585)

 

An easy way to perform a quick check of the technical setup is to use the report RSUSR_CUA_LANDSCAPE_CHECK (SAP note 2108938 - CUA: Analysis of existing CUA landscape)

 

 

 

2.5.    SU01: edit/create/delete buttons available
  • The ‘create’ and ‘delete’ buttons are available in SU01 of the child system as long that system is classified as ‘new’ system (see SCUG in the central system). After taking over all users using SCUG, the ‘create’ and ‘delete’ buttons will be gone.
  • Missing SCUM-entries
    For so far unknown reasons it may happen, that not all SCUM settings are available. In such a case you will notice empty or missing tabs in SCUM. The missing entries can be restored by importing the table content of the USRFLD*-tables from a system with the same basis release (see point I.3 above)

 

 

2.6.    Password gets deactivated instead of initialized

Especially in case the value for system parameter login/password_downwards_compatibility is set to ‘0’ in one of the CUA-integrated systems, the behavior of password related actions may be unexpected.

The behavior is described in SAP note 1300104 - CUA|new password hash procedures: Background information.
In case not all systems of the CUA landscape have the same basis release, the parameter values of login/password_downwards_compatibility have to be checked very carefully to avoid unwanted deactivations, etc.

Recommendation:
As mentioned also in the documentation (for instance here), SAP recommends to run the central system of the CUA on a system with the same Basis release (or higher) as the connected child system(s). Otherwise the central system is not able to provide the most actual password hash values.
 
Consequence for not following the recommendation:
The child system with higher Basis must accept also ‘older’ hash values, which do not have the maximum security.

 

 

 

 

 

 

 

Related Documents

 

 

https://service.sap.com/~sapidb/011000358700001037122002E/October_670_change.pdf

Related SAP Notes/KBAs

 

 

161347 - CUA: Tables in central user maintenance

320449 - Deactivating the CUA temporarily

333441 - CUA: Tips for problem analysis

395841 - CUA: Assign target system-specific param. and user groups

399271 - CUA: Tips for optimizing ALE distribution performance

399917 - CUA: Moving of a CUA via Client or System Copy

 

492589 - CUA: Minimum authorizations for communication users

2000585 - CUA: Minimum authorizations for communication users (Version 2)

 

943609 - CUA: Reposting unsuccessfully updated IDoc

1300104 - CUA|new password hash procedures: Background information

1642106 – CUA | PFCG: Automatic text comparison of roles for central system

1833088 - CUA: Updating incorrect IDocs

2108938 - CUA: Analysis of existing CUA landscape


__________________________________________________________________________________________________________

Use this structure to help you compose your contributions for WIKI and at the same time will ensure spelling and grammar.