Best ways to migrate from XYZ-SNC to SAP SSO 3.0 SNC library

[Colt]

Hi Experts,

would love to have a discussion with you about the best way to move from XYZ-SNC library (such as MIT kerberos) to SAP SSO 3.0. Lets assume a customer has a large environment and already SNC in use based on a 3rd Party Kerberos library. Now he wants to move to SSO 3.0 to make use of all the nice features, such as parallel operation of SNC with X.509 and Kerberos and many other benefits of using a officially supported and certified SNC library.

Background:

• As of today SAP AS ABAP are operated with any SNC Kerberos Library (or could be X.509 also)
• A migration to SAP Single Sign-On 3.0 solution is now being considered

Challenges:

• The parallel operation of multiple SNC libraries on a SAP AS ABAP is not possible
• The parallel operation of multiple SNC libraries on the client side is not possible (maybe possible)
• Although SNC libraries are based on the standard interface GSS-API V2, the token formats may be incompatible, this will impact the user mapping format (different canonical name format for the SNC-Name).
• With an exchange of the SNC Library all SNC-Names in the user master data SU01 (Table USRACL) must be re-calculated and generated (Update of the User Mapping)
• Different format/syntax for the snc/identity/as impacting the client rollout (saplogon.ini)
• Often all SAP users don’t have any active passwords or they simply don’t know their passwords anymore because of using SSO 🙂
• Looks like it is required to switch back to Username + Password based authentication during a migration phase on a per Server basis
• In short, a migration seems to be impossible without either big-bang or switching back to password auth (losing SNC security)
• RFC connections between systems may be in use and must be considered for the migration
  

What could help?

The parallel operation of two SNC libraries on the client side (smells like a feature request)

I would love to have a “standard” way (at least on the SAP Logon/GUI) where a user (or the admins) are able to “control” which SNC library is used for which connection. Using SAPGUI.EXE allows to specify a parameter for SNC_LIB, that may help, haven't tried it yet. But just a small improvement on the SAP GUI client, an additional saplogon.ini parameter or whatever which overrules the SNC_LIB variable would help. A place where you would be able to define the full path and SNC lib used for a specific connection.

This could allow the use of two SNC solutions on one Windows client in parallel. That would provide customers with the possibility, to rollout the SAP Secure Login Client (SLC) in addition to an existing SNC client installation and migrate the ABAP backends one after another. Connections to migrated servers would use the new SAP CommonCryptoLib via SLC while the old SNC based connections would still work. This approach could be controlled by the IT organization using a phased approach for the migration. Do you have additional thoughts and ideas?

Lets discuss.

Regards,

Carsten

[Christian_Cohrs · Accepted solution]

Hi Carsten,

what do think of the migration support that we added some time ago, as described at http://scn.sap.com/community/sso/blog/2015/04/15/snc-product-migration-now-is-the-time ?

Does this make things easier?

Best regards,

Christian

[Colt · Accepted solution]

Hi Christian,

well, indeed it helps. I must have missed that one.

Questions:

• Will the SLC detect the existence of SNC library and automatically set SNC_LIB_2 or is it required to manually take care to set the new SNC_LIB_2 during SLC installation while keeping the existing SNC_LIB untouched?
• As far as I understood, the SAP SSO SNC library located by SNC_LIB_2 variable, will be called by specifying the SNC-Name of the Server using the syntax p/sapsso:CN=xxx, right?
• Given the fact all servers are migrated to SAP SSO (CommonCryptoLib), is is required to switch back the snc/identity/as from p/sapsso:CN=xxx to default p:CN=xxx to make use of the SNC_LIB instead of the SNC_LIB_2? This may be important when enrolling new clients where only SNC_LIB is available. Or could one theoretically keep the alternative prefix name?

Thanks again!

Carsten

[former_member200373 · Accepted solution]

Hi Carsten,

Secure Login Client will always overwrite an existing SNC_LIB / SNC_LIB_64 value (as well as SSF_LIBRARY_PATH / ..._64).

And you should not run with SNC_LIB_2 only, even it works, when there is just one product installed.

I´d propose the following procedure (which is different than the blog mentioned above).

The goal is to keep the default syntax and variables for the future standard SNC provider, SAP SSO with CCL, and use the extras for the old product that shall disappear from the landscape sooner or later.

1. Change the respective SNC names related to the old product by adding its specific p/vendor identifier (on ABAP side: only required if message server is used; on SAP Logon Pad side: required)

2. On client side, clone the current SNC_LIB into a new SNC_LIB_2.

3. Check that all SNC connections still work as expected.

4. Install SLC, which is setting its own SNC_LIB value.

5. Check that all server connections still work as expected.

6. Now add new CCL based or change to CCL based SNC servers.

7. Check each new/changed SNC server if it works with SLC as expected.

8. Once no old SNC server is live anymore, remove the SNC_LIB_2 configuration, as well as the old SNC product.

9. Make sure that removing the old SNC product does not also remove SNC_LIB. Repair if needed.

-- Stephan