Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

CUA followed by SSO of child instance results in SNC TAB not recognized

Former Member
0 Kudos

Hello All,

Has anyone run across the following scenario and found a solution that is better than the the workaround we are having to use?

Background.

We have implemented CUA on our Solution Manager Instance and we already have several child instances defined and operational. We are on SolMan 4.0 with ECC 6.0 and BI 7.0. We are in a build phase, so we have been deploying CUA to 'new' child instances as we create and operationalize them.

Subsequently, we have begun to deploy SSO to these child instances successfully, with SolMan CUA controlling the SNC tab information at the parent level. This worked fine for the first child instance deployed.

Problem.

As more child instances are built, we have been bringing them under the control of CUA. This works fine. However, when we next attempt to deploy SSO onto the child instance, the information in the SNC tab that already existed from CUA'ing the child, has the correct format and content but it is not being respected by SSO.

Workaround.

We are having to go in to each UID in SU01 and remove the 'correct' SNC information. Then save the UID until it propagates down to the child instance. Then we have to go back in to the UID, put back the SNC information and save it a second time so that it again propagates down to the child instance. Once we do this, the UID works under SSO and CUA.

We wanted to deploy CUA first followed by SSO to new child instances, since the SNC tab information already existed in the parent instance from previously successful SSO deployments.

Has anyone experienced this phenomenon and found a better workaround? Thanks very much.

Regards,

Ken Fujimoto.

9 REPLIES 9

Bernhard_SAP
Employee
Employee
0 Kudos

Hi,

I suppose you get in the child system with the problem 'canonical name not determined' on the snc-tab in SU01? unfortunately the determination

is done only, after an etnry is changed. As long this status is not 'Determined', SSO will not work.

I only can suggest a little workaround:

First please make sure, that you have the latest kernel applied.

then you need to perform a change on the canonical name of each user.

As you have this entry already in your CUa - mastersystem I suggest to perform this change as follows:

1. set in SCUM SNC to 'local' to be able to perform local changes in the client system.

2. In the clientsystem: with SU10 pick every user and change their snc entry to any value (it does not matter if this is a wrong/useless entry, the aim is, to make a change to get the canonical names re-determined)

After you have done this.

3. Set SNC in SCUM back to 'global'

4. Start SU10 in CUa master, and select all users for that child system

-->SU10->press F4 at the user-field->the F4-popup offers a tab users by systemassignement)

I suggest to select not too many users at a time, as the following distribution will cause some systemload.....

5. now make any change to that users which do not affect them really, for instance make an entry for an additional parameter which does not affect the users (you can roll it back afterwards by undoing this change again with SU10). this change will redistribute the SNC-settings too to that child system.

6. check SCUL, if all users have green status.

7. Proceed with the next set of users until you have changed all of them.

After the distribution the SNC-status should be 'determined' in your

childsystem.

8. Undo the changes made again with SU10 (if necessary).

I know, that is not very elegant, but thats the only workaround I am aware of.

Maybe you test these steps before with a small set of 'test-useers'.....

good luck, Bernhard

0 Kudos

Hello Bernhard,

Thanks very mcuh for the quick response. Yes you are correct that we see the message 'canonical name not determined' in the SU01 SNC tab in the child instance.

I like the potential that you solution has, however, we will need to wait for the next child instance to be built, then CUA'ed and finally SSO'ed before we will have the chance to try it. This may be several weeks away, however, once we are in such a position, we will use your strategy.

Thanks again.

Regards,

Ken.

0 Kudos

Hello Bernhard,

We are now in a position to test your solution and have run into a problem. I have set SCUM in the CUA parent system to allow local changes to SNC in the child system. However, when I go into SU10 in the child system, I do not see the SNC tab for 'mass changes'. I can only see the SNC tab on the individual SU01 screen for each user ID.

Am I doing something wrong or do you have any other suggestions? Thanks very much.

Regards,

Ken.

0 Kudos

Hello Ken,

oh, my fault.....

In SU10 there is no 'SNC'-tab.....(no matter with or without CUA)....

Instead you could use SE37->bapi_user_change to update the SNC-value in table USRACL.

Sorry!

b.rgds, Bernhard

0 Kudos

Hello Ken,

oh, my fault.....

In SU10 there is no 'SNC'-tab.....(no matter with or without CUA)....

Instead you could use SE37->bapi_user_change to update the SNC-value in table USRACL.

Sorry!

b.rgds, Bernhard

0 Kudos

try transaction SNC4

0 Kudos

SNC4 it is. Thanks! Must remember to hit save and this cleans up the canonical names. I didn't like the idea of having to open each system and modify each user.

0 Kudos

And now:

SAP proudly presents:

[SAP Note 1563288|https://service.sap.com/sap/support/notes/1563288]

b.rgds, Bernhard

Bernhard_SAP
Employee
Employee
0 Kudos

set to 'answered'