How-to-Guide - How to upgrade the implementation of SNC/Kerberos/SPNego
Introduction
The implementation of Single-Sign On (SSO) in a company can be done following different approaches. While some likes the usage of x.509 certificates or SAML, other prefers the Kerberos, SPNego and Secure Network Connection alternative to only mention some of them. Whether one alternative suits better than another one is left to one another’s appreciation.
This document is focused on the setup of Kerberos and SPNego or more specifically on the update of its implementation since setting it up on a green field is already largely covered.
Here are the given from the use case based on which we built this knowledge.
A company running many SAP Systems, most of the time in a 6-tiers environments (X, D, E, Q, R, P), is using Secure Network Connection (SNC) to authenticate its users without providing any credentials to SAP Logon. The profiles in SAP Logon are pushed to the end-users by the system administrators and they don’t have the capability to modify easily (through the GUI) the preconfigured entries. Each pre-configured entry of the SAPLogon.ini file makes use of SNC and relies on a messaging server to establish the connection to the SAP System. The users can thus access each system without providing any user and password. Thanks to the usage of SNC, the end-users never had to know the password they would have had to use to access those systems if they had to be accessed differently. Most of them don’t even have a password defined in the SAP Systems. The company has a Central User Administration (CUA) infrastructure to handles the users in all the SAP Systems, their configuration can thus not be updated directly using the SU01 transaction, without using the CUA. The same restriction applies to transactions such as SNC1 or SNC4 and I suspect that many others suffer from that given.
The configuration in place which offers that silent sign on capability through SAP Logon doesn’t allow the same convenient approach for Web Browser based access. At the time of writing this document, to benefit from SSO through the SAP Logon as through the Web Browser, it is required to use SAP SSO 3.0. To remain at a as high-level as possible, we will consider that SAP SSO 3.0 corresponds to the “new” implementation of SNC/Kerberos. This new implementation got introduced end of 2013 and requires, unlike its predecessor, a dedicated license (for SAP SSO 3.0) to be used. And beside the licensing aspect of things, using SAP SSO 3.0 has a major impact on the overall SAP ecosystem since it doesn’t work in standard side by side with the “old” implementation.
Since Security is considered by most people as a complex and sensitive topic in general, we built this document with as many details as possible and often to an extended that goes beyond exaggeration (when it comes to screenshots for instance). This is done in purpose to reduce to the bare minimum the number of unexpected events that could happened along the road.
| NOTE: Pay attention that all the screenshots do not come from the same system nor the same implementation, you might be confused seeing elements coming from different environments (X, D, E, Q, R, P). They are just there to illustrate the steps but does not relate unfortunately to a single implementation process. |
Some theory
Before diving into the configuration, it might be interesting to have a closer look at the concepts and the mechanisms that lies behind those terms, Kerberos and SPNego. Then, to conclude this section a few words around the differences between the capabilities offered by the "old" and the "new" implementation of Kerberos/SPNEGO.
Concepts
“Kerberos is an authentication protocol that can be used for single sign-on (SSO).”
SPNEGO (Simple Protocol GSSAPI Negotiation Mechanism) is a mechanism used in a client-server context to negotiate the choice of security technology. It is used when the parties have no clue about the authentication protocols their correspondent supports. The negotiable security mechanism includes Kerberos.
How does Kerberos work?
The following illustration from Dan Lebrero’s blog helps to understand the principle.
 | Legend:
|
The following description from wikipeadia can also help to make the link with other concepts that we will see later:
"The client authenticates itself to the Authentication Server (AS) which forwards the username to a key distribution center (KDC). The KDC issues a ticket-granting ticket (TGT), which is time stamped and encrypts it using the ticket-granting service's (TGS) secret key and returns the encrypted result to the user's workstation. This is done infrequently, typically at user logon; the TGT expires at some point although it may be transparently renewed by the user's session manager while they are logged in.
When the client needs to communicate with another node ("principal" in Kerberos parlance) to some service on that node the client sends the TGT to the TGS, which usually shares the same host as the KDC. Service must be registered at TGT with a Service Principal Name (SPN). The client uses the SPN to request access to this service. After verifying that the TGT is valid and that the user is permitted to access the requested service, the TGS issues ticket and session keys to the client. The client then sends the ticket to the service server (SS) along with its service request."
The old and the new implementation
In the introduction we simplified a bit the situation in saying that SSO 3.0 was required for Web base SSO and what we refer to be the “new implementation”. This is not exactly true. At the time of writing this document, the current ABAP Kernels come with CommonCryptoLib (SAPCRYPTOLIB) Version 8.5. This is specifically that DLL that is required for the new implementation. The SAP SSO 3.0 is only a license that is required to legally benefit from the features that are offered using that library. As illustrated in the SSO diagram in the concept section of this document, using that library will also require the use of the Secure Login Client (SLC), on the client side, which comes with SAP SSO 3.0.
In the past a part the job achieved by this library was done by three distinct libraries. The table below illustrates the differences. Going from multiple libraries to a single one also contributes naturally to the simplification of the configuration.
More information on history of the CommonCryptoLib can be found here.
Strategy for a smooth migration
We will see that it is not possible to run the standard transactions that are required to configure the system (SNCWIZARD and SPNEGO) if SNC/Kerberos is already configured using the old implementation. It is thus important to follow some preliminary steps to achieve this configuration.
Beyond the question of how to achieve this for a single server, what if your company has multiple servers and that the user administration is done through a CUA? How can this be streamline on a company level without locking out the users from the systems until all the systems (clients and servers) got reconfigured?
The following process flow recommends to first patch all the clients, deploying the SLC component and adjusting their environment variable in such a way that the authentication can happen with both SNC name that may be required in the overall SAP ecosystem. Then only, take the SAP Systems one by one at a time and adjust its configuration to comply with the new implementation.
In the remaining sections of this blog, we will see how to achieve these steps in detail.
Client Side Configuration
Download the Secure Login Client from support.sap.com/swdc.
Install the Secure Login Client
Before installing the SLC, make a backup of your environment SNC_LIB variable. Its value should point to something like: C:\[...]\SAP\gsskrb5.dll. You will need to retrieve this value after the installation of the SLC.
Once the installation of the SLC done, the environment variables should have been updated similarly to what is displayed here:
- SNC_LIB=C:\Program Files (x86)\SAP\FrontEnd\SecureLogin\lib\sapcrypto.dll
- SNC_LIB_64=C:\Program Files\SAP\FrontEnd\SecureLogin\lib\sapcrypto.dll
- SSF_LIBRARY_PATH=C:\Program Files (x86)\SAP\FrontEnd\SecureLogin\lib\sapcrypto.dll
- SSF_LIBRARY_PATH_64=C:\Program Files\SAP\FrontEnd\SecureLogin\lib\sapcrypto.dll
Adjust the environment variables
The complexity of the task described in this document is to go from the legacy Kerberos implementation to the new one or more accurately from using one DLL to another one.
NOTE: This change implies a change on the SNC Name of the users. While we used p:<UPN> as for the user’s SNC name it is now required to use p:CN=<UPN> instead. This requirement comes from the fact that a different client is required on the host to handle the Kerberos token. The new SLC component only gives the latest format, p:CN=<UPN>.
The trick is thus to find a way to use the old and the new system simultaneously which boils down to finding a way to use the two different DLLs at the same time.
- SNC_LIB=<Path to the old DLL>
- SNC_LIB_2=<Path to the new DLL>
And comment out the *64 one since only one is used in the end: the 64 one if you are running a 64 bit and the other one if you are running on a 32 bit. Up to you to configure it correctly.
Server-Side Configuration
Checking the prerequisites
The only prerequisite to this configuration is the presence of the SAP CommonCryptoLib (SAPCRYPTOLIB) in version 8.5 or above on the server. Its installation is done through the setup of SAP SSO 3.0. This prerequisite is met automatically if you are running AS ABAP Kernel 7.20 PL88 or above. If your system or Kernel uses CommonCryptoLib 8.4, or with the deprecated SAPCRYPTOLIB version 5.5, it is recommended to update to the latest CommonCryptoLib version 8.5.
We will thus see now out to check those two versions.
The Kernel’s version
In SAP Logon
Go to System menu ► Status
Click on the button on the right of the Navigate button at the bottom right of the screen
The info can be seen in the upper left side.
The SAPCryptolib’s version
In SAP Logon, go to STRUST ► Environment Menu
Select Display SSF Version
If the CommonCryptoLib doesn’t reach the expected version level, either upgrade the server to the latest version or install the SAP SSO 3.0 component. This part is left out of the scope of this document since we didn’t face that scenario in context of the assignment during which we built that expertise.
Configure the SPNs for the Kerberos Principal Name
“A service principal name (SPN) is the unique identifier for a service that Kerberos will authenticate against.” The minimum required SPNs are:
- SAP/<SID>: “The SPN must match the SNC name chosen for SNC. If they don’t match, the secure login client won’t be able to match the SPN with the server’s SNC name and SSO will fail, but encryption will be successful.”
- HTTP/<FQDN of appserver>: “Here appserver should be the fully qualified canonical domain name of the appserver server host or any alias of the appserver.”
This part of the configuration is not covered in this document. Ask your AD Administrator to get this properly configured. The time required to perform this task is negligible.
Checking the SPNs of a technical account
The technical account to check here is the one that will be used later to connect the SAP System with the ADFS acting as a Key Distribution Center (KDC).
setspn -l <domain>\<technical account name> >> SPN.txt
Registered ServicePrincipalNames for CN=SAPServiceR75,OU=SAPService, |
The lines with the msapproxy are required since the services (SAP Fiori content in this case) that need to be accessed are reached through a Microsoft Application Proxy service.
To make it short, any services that you are willing to reached and that should be authenticated using Kerberos should be in that list... The example above is just an example, don't take it as a generic template to stick to!
Login into the SAP System
Cleaning the SNC and SPNEGO configuration
Running the SNCWIZARD transaction will be troublesome if the old implementation of SNC is in place. A message saying "SNC product not supported" appears.
SPNEGO transaction should not be accessible neither if the old implementation is still in place. Trying to access it should give an error message such as "Kereberos library was not loaded" and "snc/*_lib not equal spnego/*_lib".
Both of those issues are covered with more details in the troubleshooting section of this blog.
At this stage, the way to proceed is to remove all the configuration related to the SNC and SPNEGO implementation.
Clean the RZ10 transaction
Go to RZ10 transaction
In this case, the parameters that we are looking for are stored in the DEFAULT profile, but it might be otherwise for other parameters or other installations. To have more information about where a given parameter takes its value from you can use RZ11. RZ11 can provide you some information about the parameters, can be also used to change the value of those parameter but those changed are discarded as soon as the server restarts!
Select Extended Maintenance
Press the Change button
Scroll down until you found the icm/* and spnego/* parameters
NOTE: The screenshot above doesn't represent the state in which you should find the system before being reconfigured. Initially the following attributes should look like:
- snc/gssapi_lib c:\windows\system32\gx64krb5.dll
- snc/identity/as p:SAPServiceR75@*******.net
One of the changes introduced with this reconfiguration of the system is to use the SAP CommonCryptoLib rather that the old one in place. At the same time, using this new library requires to prefix the server identity differently with "p:CN=" rather than just "p:". The screenshot is thus a bit confusing.
Select the first one and press Shift + F2 to delete the parameter or use the menu of the top window
Press Yes
Repeat these last steps for each icm/* and spnego/* parameters
Press the Copy button
Press the green back button
Press the Save button
Press Yes
Inspect and press the green back button
Press the Yes button
Press the green validation button
Keep that note in mind and press the green validation button
Press the green back button
Cleaning the PSE
"A personal security environment (PSE) is a secure location where the public-key information of a user or component is stored." (link)
The implementation of SNC relies on a specific PSE, SNC SAPCryptolib. This PSE is created automatically during the execution of the SNCWIZARD transaction. If for some reasons, the associated certificate does not meet your expectation, you can delete the PSE and recreate it later when you will configure SNC again.
Enter STRUST in the transaction input field
Press the green button on the left of the transaction input field
Expand the folder SNC SAPCryptolib
NOTE: As far as I am concerned I find it a bit confusing to use something that looks like an email address for the common name of the certificate used to identify the server. This is the reason why I took the decision to remove the certificate.
Press the Display Change button
Right click on the folder SNC SAPCryptolib
Select Delete
Press Yes
Press the green back button
Ask for a restart of the server
Configure SNC
SNCWIZARD
Enter SNCWIZARD in the transaction input field
Press the green button on the left of the transaction input field.
NOTE: If you forgot to remove the SAPCryptolib PSE from STRUST you will see the following list of steps. The SNC Identify Step is missing!
Press the Continue button
Press Continue
Press Skip
Press Complete
RZ10
Enter RZ10 in the transaction input field
Press the green button on the left of the transaction input field
As seen previously select the appropriate profile in its latest version (double check on which version you are working)
Select Extended maintenance
Press on Display
Scroll down to the icm/* and spnego/* parameters
Press the Display Change button
Modify the value of the snc/identity/as parameter to match the following pattern:
p:CN=… --> p/sapsso:CN=…
Press the Copy button
Press the green back button
Press the save button
Press Yes
Inspect and press the green back button
Press Yes
Press the green validation button
Press the green validation button
Press the green back button
Ask for a restart of the server
Configure Kerberos
SNCWIZARD & SPNEGO
Enter SNCWIZARD in the transaction input box
Press the green button on the left of the transaction input field
Press the Continue button
Press the Continue button, the SPNEGO transaction is started
Press on the Change / Display button
Acknowledge the information pop up using the green validation button
In the toolbar above Kerberos User Principals, click on the new button
Provide the name of the user that should be used to interact with the KDC. That account needs to have a couple of SPNs defined. Each SPN defined correspond to an endpoint that will have the capability to be authenticated using Kerberos.
Press the check button next to the second input field dedicated to the password to verify whether the password that you have provided is correct or not.
Press the green validation button
Press the green validation button
Ideally, we should be able to see something in the two tabs at the bottom of the screen, Service Principal Name and User Mapping, but it doesn’t seem to be stable… (From what I have experienced at that customer.)
Press the Save button
Press the green back button
Press the Continue button
Press the Complete button
Ask for a new restart of the SAP System
The configuration of the server is now done exception made from the Users’ SNC name that still need to be adjusted.
Adjusting the SNC name of the users
To benefit from this new Kerberos implementation some adjustments on the client need also to be done. This mainly the installation of the Secure Login Client that I am referring to. Unfortunately, while using that client the SNC name of the users will be changed from p:<UPN> to p:CN=<UPN>. It is thus necessary to modify the Users’ SNC name in the system.
At the customer side where we build this knowledge, they had implemented a small ABAP extension which was capturing the iDocs coming from the CUA. The iDocs were compared to the entries of a custom table and if the iDocs were related to a user mentioned in the table the SNC name of the user was modified to comply with the new formatting standard, p:CN=<UPN> rather than p:<UPN>.
Unfortunately this piece of the puzzle was not shared but it should be achievable through the CUA.
Service Level Configuration
Ensure that the service is properly configured to work with SPNEGO. Here is a potential solution. The key is to avoid having an option like HTTP Fields in the first place because it will not move automatically to the next method...
- SPNEGO Authentication
- Logon Through HTTP Fields
- Logon Through SSL Certificate
- SAML Logon
- SAP Logon/Assertion Ticket
- SAP Assertion Ticket
- Basic Authentication
- SAP RFC Logon
- Logon Through Service Data
Troubleshooting
Find here a couple of difficulties we ran into.
Realizing that a legacy configuration was in place
SNC Product not supported
At the very beginning, one should be tempted to go straight at SNCWIZARD to configure the system. Unfortunately for us we ran into this error immediately.
Check SAP KBA “2500444 - Transaction SNCWIZARD - SNC product not supported”
Check RZ11 for snc/gssapi_lib
It is pointing to a Kerberos dll rather than a cryptolib file.
This is already one "issue" identified.
Mismatch between snc lib and spnego lib!
After failing with the SNCWIZARD transaction, one might be interested to check SPNEGO.
Kerberos library was not loaded! as an error message at the bottom and a mismatched library as a warning above.
Check RZ11 for spnego/*_lib
Indeed, if we compare the value of this parameter with the one from the previous we do have a mismatch. Changing manually the values to get them in synch does not really help if you wonder...
Solution
The solution we found to solve those two issues at the same time was to remove completely the SNC/Kerberos configuration that was initially in place. This means:
- Remove from RZ10 any parameter that matches snc/* and spnego/*
- [optionally] delete the PSE related to the SNC implementation
- Restart the server
Front End control SNCAX.DLL not installed
Once the RZ10 cleaned out from the old configuration you can proceed again with SNCWIZARD and SPNEGO but there is still one requirement: having the Secure Login Client (SLC) component installed on the machine from which you are doing the configuration!
Peer certificate verification failed
The server has been configured, SNCWIZARD and SPNEGO transaction were successfully used but while trying to access a resource from sap logon using SNC and a messaging server you get the following error.
2497505 - SNC Error Code A2200210 Peer certificate verification failed - Kerberos configuration
Reason: The SNC identity name was not chosen properly. Removing the configuration and using CN=E75 was better in that particular case.
Pay attention that the name used as a common name in the SNC SAPCryptolib PSE should be the one used in RZ10 for the parameter snc/identity/as (p/sapsso: prefix excluded).
The verification of the Kerberos ticket failed
Reason for this: R75 is a system that gets refreshed from the Q75 System. After the refresh some clean up usually takes place to be sure that Q75 is not mentioned anywhere anymore but R75 instead. This cleanup phase was not properly done and during the reconfiguration of the system, the SNC SAPCryptolib PSE was still mentioning Q75 just as the System PSE… Deleting both PSE and repeating the configuration using the right information fixed the problem…
No user exists with SNC name “p:CN=…”
This is because the user in SU01 is still configured with an SNC name p:<SPN> instead of p:CN=<SPN> and it cannot be changed directly since it is configured automatically through the CUA (in our context). Make sure that the user can updated in some way to comply with the new formatting standard.
SoapFaultCode:5 File does not exist
For some reason the PSE file on the file system does not exist…
The solution is simple: recreate the file! To do so,
- load the certificate (here related to the SSL Server Standard PSE)
- Double click on the SSL Server Standard folder in the tree view. The right side will update itself automatically.
- Ensure that your are in edit mode
- Go to the PSE menu
- Select Save as
- Select the SSL Server option
- Save
The modification will be saved for both entries of the tree view.
Alternatively, you can do a right click on the folder and select Distribute while in step 3.
Reference
Definitions
- https://danlebrero.com/2017/03/26/Kerberos-explained-in-pictures/
- https://en.wikipedia.org/wiki/SPNEGO
General
- https://blogs.sap.com/2017/07/27/sap-single-sign-on-authenticate-with-kerberosspnego/
- https://blogs.sap.com/2014/07/16/sap-s-new-cryptographic-library-commoncryptolib/
- https://wiki.scn.sap.com/wiki/display/ASJAVA/SPNego+Kerberos+Authentication
- https://www.slideshare.net/SAPTechnology/sap-singlesignon2-0overview
- https://launchpad.support.sap.com/#/notes/1848999
Troubleshooting
- SAP Managed Tags:
5 Comments
