cancel
Showing results for 
Search instead for 
Did you mean: 

Failback scenario when CUA identity managemnt is unavailable

JPinto
Newcomer
0 Kudos

Hi experts,

not sure if you answer questions on all SAP applications for identity management or only for the SAP IDM solution.

Regardless, my question is more on strategy and applies to both but much more relevant for CUA implementation because of 1 special technical detail.

We have configured a central identity management solution using CUA, and to force it to be the only point of access we've defined that no user management can be done directly on the backend.

Problem is the CUA is located on a non-critical system (Solman) and we need to setup a failback scenario in case the solman is unavailable (maintenance, incident, etc.).

Can you advise on the strategy to follow? We've thinked of some different solutions but would like to adopt the most commonly used/advised:

1 - using CUA customization not allowing any change to be done on satellite system:

1.1 - CUA doesn't seem smart enough to detect the central system is unavailable and allow local changes. Is there any 'switch' to allow it and queue the changes so they are replicated after CUA is back online?

1.2. - on satellite system remove the CUA implementation, perform the change and recover the CUA setup when it's again available.

        we don't know possible impacts or user master data out-of-synch problems that can occur or even 'garbage' data that stays in the system and can corrupt CUA itself.

2 - using CUA customization allowing changes both on central and local:

2.1 - disable access to user management changes using authorizations; in emergency using a firefigther account to perform user changes

2.2 - disable access to user management transactions using authorizations or sm01; in emergency using a firefighter account to allow access on himself.

2.3 - the same as the above but instead of a firefighter account have an authorized 'super' user admin person allowed to grant this access in emergency.

3 - any other strategy?

Thanks,

João Pinto

Accepted Solutions (1)

Accepted Solutions (1)

jaisuryan
Active Contributor
0 Kudos

Hi Joao,

Just sharing my SAP security project experience, may not be best practice.

We had CUA set up and we were not allowed to change users (thru authorizations) in satellite systems.

We had both FFIDs (Service) and SuperUsers (Dialog) set up in each satellite systems. 

If CUA is down, we use FFID to maintain users in satellite system and keep record of changes we are doing. Then when the CUA is back, we do the assignments in CUA so that we keep things in sync.

If both CUA and GRC is down, we use SuperUser to do the same thing as above. The password of superuser was maintained by Client's SAP Security or Technical BPO.

Hopefully you get the answer you require from others in the community.

Kind regards,

Jai

Answers (0)