3-Step SNC Migration Roadmap to SAP SSO 3.0

You are faced with the challenge of migrating your current SSO solution to SAP Single Sign-On 3.0 but question yourself how to migrate without a big bang approach? I am glad you asked!

I was busy for a while but thought it would be a good time for a blog again. So here we are and talking about the advantages of SAP SSO 3.0 compared to the free SNC library. How to operate two SNC libraries in parallel and how to perform a successful per-system migration.

Many SAP customers are still using an SSO solution for SAP GUI which is based on a very old Secure Network Communication (SNC) library. Often, the free RFC-1964 Kerberos 5 or SAP’s GSS-API v2 NTLM wrapper for Microsoft’s “SSPI” (Security Service Provider Interface) namely – gsskrb5.dll| gx64krb5.dll- is used on the front- and backend.

Due to various factors, since a while you consider using the SAP Single Sign-On 3.0 software suite in your SAP landscape. You know, it is not just an SNC library but much more and comes with a full-featured Secure Login Client supporting Kerberos, X.509 certificates, Smartcards, and MFA. You know your old solution is not officially supported by SAP and you will have issues using them on later SAP releases or future use cases. 

You are craving for features such as SPNEGO for the AS ABAP, support for onetime passcodes, the use of strong encryption algorithms or policy-based authentication. You know that Security is not a static condition but an ongoing process – perfect, now it’s time to bring some fresh wind into your SAP SSO landscape. 

Once the decision is made to increase compatibility, security, and efficiency of your SAP landscape, it makes perfect sense to migrate to SAP SSO 3.0. Since some years now, the SAP CommonCryptoLib is the kernel-default library for TLS, SSF as well as SNC and SPNEGO. By using it, you don’t have to deal with many different libraries and can be sure to have to best possible SAP and platform support.

As you already use SSO, the majority of your SAP users are already used to it. Now you need to make the transition to the new Single Sign-On solution as smoothly as possible, without taking away the usual SSO comfort from the users, switching them back to password authentication or worse disable SNC. Also, you can’t just change all the systems at the same time.

Background information – why you can’t just replace the SNC library?

Although most SNC libraries are based on the generic GSS-API V2 interface (Generic Security Services Application Programming Interface Version 2) they are incompatible among themselves, because they use different wire protocols and different token formats which affects the GSS-API token itself and the SNC User Mapping Format (Canonical Name). 

When the SNC library is replaced with the CommonCryptoLib, at the same time all SNC names in the user master SU01 (table USRACL) must be calculated and regenerated by the new SNC library. Otherwise, users can no longer log in to SAP. There can only be one concurrent SNC mechanism used with the BC-SNC interface on an SAP application server. Moreover, SNC-protected communication requires that both communication peers, client and server, have the same SNC library installed. For those reasons, switching the SNC library can be a complex task. 

Ok, now you know the facts but still fear the high efforts a migration could mean? 

Don’t panic, there is a solution!

Now let us answer the question about how to migrate to SAP SSO (CommonCryptoLib) without a big bang approach or the need to update all frontend and backend systems at the same time. The trick is, you can operate two SNC libraries in parallel for your SAP GUI installation. Having this opportunity, the backend and frontend software updates can be decoupled, and migration can be performed on a per-system basis. 

Since SAP GUI 730 (Patch 10) SAP added support for two concurrent SNC products within the same SAP GUI installation. This can be configured by customers using simple environment variables specifying the required SNC product for each SAP GUI connection. The selection/distinction between multiple SNC libraries requires the use of a modified syntax for the SNC-Name of the target/peer. More information can be found in SAP Note 2025528 – (Limited Support for) more than one concurrent SNC_LIB.

Performing the migration requires proper planning, for that reason we have developed our proven 3-Step SNC migration roadmap supporting your project. Based on these procedures, we have successfully performed several migration projects.

Setting the prefix p/krb5 controls the RFC-1964 Kerberos 5 SNC adapter, so the old SNC library is used for such entries. For more information see SAP note mentioned above. 

Proceed with Step 2 if all changes have been done

It makes sense to have the SAP Logon configuration file such as saplogon.ini or SAPUILandscape.xml on a central file share or http location. If not, please ensure you can distribute the required changes in Steps 1 and 2 to multiple clients using GPOs or other software deployment tools.

Step 3 operations can only be carried out after completing the previous steps. An SNC secured login to the system is no longer possible until all Step 3 tasks are completed. Therefore, a corresponding time window should be planned for these activities. As soon as a system has been configured accordingly, an SNC connection to this system is only possible via the Secure Login Client 3.0. The SNC logon to such an “migrated system” is then triggered by the changed syntax of the SNC name p:CN=<SID>. At the same time, all existing SAP logon entries will continue to work with the old Kerberos SNC library.

Conclusion

This approach allows for migrating specific SAP systems gradually. As a result, the effort and complexity, as well as the required downtime, can be well controlled. During the overall migration, the SAP GUI client can use the old and new SNC library (migrated system) in parallel.

Once done with the migration, don’t forget to cleanup old SNC library, variables and  AD service accounts. We recommend, to enforce SNC for normal SAP GUI users, disable passwords and cleanup hashes, for more details see our other blogs.

This blog is intended to provide a brief insight into how it works, our experienced consultants are happy to assist you in the detailed migration process. Hope you enjoyed reading. Please stay tuned – we will soon continue our “Insider Tips” blog series with volume #4.