Skip to Content
Author's profile photo Christian Cohrs

SNC Product Migration: Now is the time

Where we come from


Since we first released it in 2011, SAP Single Sign-On has become a very popular product (thanks to all of you for that). Many customers decided to increase the security of their SAP landscape and the efficiency and satisfaction of their end users by implementing it. Even customers who were already using a product for SAP GUI Secure Network Communication (SNC) decided to switch to the SNC support that comes with SAP Single Sign-On.


Back then however, switching an SNC product was a tricky thing. SNC requires matching libraries on the frontend and the backend, and different SNC products are not interoperable. This left customers with the big bang approach. All frontend and backend systems had to be updated at the same time to avoid broken connections.


What is new


In the current version of SAP GUI and many RFC clients we have now added a capability that will significantly simplify the SNC product migration. SAP GUI was enabled to support 2 SNC products within the same SAP GUI installation. This can be configured by customers using newly introduced environment variables and specifying the required SNC product for each SAP GUI connection.


How to migrate to SAP Single Sign-On SNC


  1. In the beginning, an old SNC product is still installed and the environment variables SNC_LIB, SNC_LIB_32 or SNC_LIB_64 point to this.
  2. You ensure up-to-date versions of SAP GUI and relevant RFC clients are rolled out to your frontend systems. See OSS note 2025528 for the list of recommended versions.
  3. You install the Secure Login Client component of SAP Single Sign-On on the clients and set the newly introduced environment variables SNC_LIB_2, SNC_LIB_32_2 or SNC_LIB_64_2 to the location of the Secure Login Library that comes with the Secure Login Client.
  4. You replace the old SNC product on a backend with SAP CommonCryptoLib and update the SNC name for the system on the clients to specify p/sapsso as the product name (e.g. p/sapsso:CN=ALX,O=SAP-AG,C=DE). If the connection is managed through a message server then this change can be done centrally without modifying the individual clients. Use transaction SNC4 to update the canonical name of the system.
  5. Once all backend systems have been updated to use SAP Single Sign-On you may uninstall the old SNC product from the clients and update SNC_LIB, SNC_LIB_32 or SNC_LIB_64 to point to the Secure Login Library. Now the environment variables SNC_LIB_2, SNC_LIB_32_2 or SNC_LIB_64_2 can be removed as they were only needed for the migration.


With this approach you are able to upgrade your landscape to SAP Single Sign-On step by step. So now is the time to get started 😎

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Tim Alsop
      Tim Alsop

      I assume it is also possible to use a similar approach to migrate from SAP Single Sign-On to another product that has an SNC library (e.g. opposite to what you describe) ?

      Author's profile photo Christian Cohrs
      Christian Cohrs
      Blog Post Author

      We have only tested the scenarios that customers asked about, and (I'm happy to say) the one you describe never came up.

      Technically it might or might not be possible for the pure SNC scenario. But then SAP Single Sign-On has much more to offer than just SNC.

      Cheers, Christian

      Author's profile photo Owen Shaw
      Owen Shaw

      Hi Christian,

      If we have a Business Suite license do we still have to Purchase the SAP Single SignOn suite of products separately?



      Author's profile photo Christian Cohrs
      Christian Cohrs
      Blog Post Author

      Hi Owen,

      yes, SAP Single Sign-On requires a dedicated license. Please check with your account executive for the details and a test license.

      Best regards,


      Author's profile photo Wolfgang Janzen
      Wolfgang Janzen

      In step 4 (replacing the SNC library on the server) not only the (product-specific) SNC name of the server will change but also the SNC names assigned to the users. Even if the (printable) SNC name has not changed, the so-called canonical name (i.e. the internal representation) will have changed and thus it's important to run ABAP t-code SNC4 afterwards to re-calculate and update the canonical name, after having changed the SNC product.

      Author's profile photo Christian Cohrs
      Christian Cohrs
      Blog Post Author

      Good point, thanks Wolfgang.

      Best regards,


      Author's profile photo Steffen Wetzler
      Steffen Wetzler

      Hi Christian Cohrs , Thanks for your guide.


      I tried to use SNC_LIB and SNC_LIB_2 with newest SAP GUI 740 SP17. SAP Logon pad does not use SNC_LIB_2. It only uses SNC_LIB. I have a test system configured with SSO 3.0. The other systems are configured with gsskrb5.dll/SAPSSO.MSI/etc.

      I only can login to any system, when SNC_LIB is configured.

      Is there anything missing?




      Author's profile photo Carlos Fortuno
      Carlos Fortuno


      same issue for me. I tested the SNC_LIB and SNC_LIB_2 when logging in through ASCS using the Public logon group,  SAPGUI defaults the SNC name with the parameter snc/identity/as.

      SNC name cannot be modified, thus we cannot put the p/sapsso: prefix even if you update the SAPUILandscape.xml file

      Any suggestions on this issue?

      Author's profile photo Vanderlei Vitorio Gomes
      Vanderlei Vitorio Gomes



      how do we handle the different user mapping format (canonical names) when CUA is in place and SCUM is configured to Global for SNC Names?


      Best regards,

      Vanderlei Gomes.