Skip to Content
Technical Articles

Enabling Single Sign On into SAP using Microsoft proprietary Windows Kerberos authentication(GSS-API)

In today’s world its hard to remember user name and password for every environment we login . It also takes soo much of time and cost in resetting the passwords from an IT team . In order to reduce manual login process Single sign on (SSO) has been introduced . But there has been some limitations and cost involved in using a Single Sign-On products .

Is there a way to single sign on without any 3rd party or SSO products for SAP session from SAPGUI ? Yes , if you have Microsoft Active directory with kerberos support then it is possible .  This method allows you to reduce your TCO.

In this blog we are going to use  Microsoft proprietary single sign on mechanism for SAPGUI .

Microsoft has implemented authentication and single sign-on on their Win32 platforms in a proprietary variant of GSS-API named Microsoft “SSPI” (Security Service Provider Interface), and includes two Security Service Providers for user authentication in Microsoft Windows:

(1) NT Lan Manager Sercurity Service Provider (NTLM SSP) with client-only authentication based on a challenge-response protocol an no protection for application data.
(2) Microsoft Kerberos SSP with mutual authentication, encryption and integrity protection for the entire communication

The DLLs attached to this Note only “wraps” a genuine Microsoft SSP, and translate API calls and API semantics between the IETF GSS-API used by SAP’s BC-SNC interface, and the underlying Microsoft’s SSP.  gssntlm.dll/gx64ntlm.dll wraps the Microsoft NTLM SSP (1), and gsskrb5.dll/gx64krb5.dll wraps the Microsoft Kerberos SSP

The Microsoft Kerberos SSP should be on-the-wire compatible with the standardized Kerberos 5 GSS-API mechanism (rfc1964 and rfc4121), and interoperable with Kerberos 5 implementations from various vendors/providers for other platforms. In pure Microsoft environments, Kerberos authentication is only available for Domain Accounts that are managed by a Microsoft Active Directory, but NOT for local computer accounts.

The Single Sign-on for SAP solution is used with SAP GUI clients running on Windows systems that are joined to an Active Directory domain. The Single Sign-on for SAP installs and configures the gsskrb5.dll module which provides a SAP Secure Network Communications (SNC) compliant Generic Security Services Application Program Interface (GSS-API) to Microsoft Security Support Provider Interface (SSPI) translation layer. You do not need to install any additional client software.

SAP’s Disclaimer on GSSKrb5.DLL *Important :
  • We re-use the Microsoft Windows Kerberos or NTLM authentication for single sign-on to SAP R/3 systems
SAP ABAP systems offers the BC-SNC software interface to perform authentication through an external single sign-on solution. This interface is based on the GSS-API v2 standard, which was developed in the IETF (Internet Engineering Task Force) and published as RFCs 2743+2744.
/*With the product SAP Single Sign-On SAP offers its own comprehensive single sign-on solution based on this interface, covering multiple scenarios, including the re-use of Microsoft Windows authentication. More information about this product can be found at */
Previous versions of the note 352295 contained the download of the GSSKRB5.dlls. Further development for this solution is discontinued and SAP offers support only for the SAP wrapper, but not for the underlying authentication mechanisms, which are genuine Microsoft technology and beyond SAP’s control (see note 150380). The files are still available under note 2115486. Access to note 2115486 can be requested via customer message on component BC-SEC-SNC.
  • SAP Note150380 – Is Kerberos 5 supported for use with SNC? SAP does not provide support for problems that occur within/inside third-party Single Sign-On solutions at SAP’s BC-SNC interface. Only SAP side of the coding is supported.
Please be aware that SAP Single Sign-On and gsskrb5.dll/gx64krb5.dll are NOT interoperable, because they use different wire protocols and different token formats


SSO Work Flow Architecture:



Work Flow of Kerberos authentication


  • A user logons to a Windows client PC. The local security subsystem takes the domain name specified by the user during logon, and uses DNS to locate a domain controller in the domain
  • Upon logon the user is validated against a domain controller (DC) server that also functions as an active directory LDAP server, a Key Distribution Center (KDC), an Authentication Server (AS) and a Ticket Granting Service (TGS). The KDC authenticates the user by contacting the Active Directory and the Authentication Server (AS) issues a Ticket Granting Ticket (TGT) that the client can use to request a service ticket for the SAP system later. The client receives login credentials from the KDC and the login credentials comprise of a Ticket Granting Ticket (TGT) and a session key. The TGT contains a copy of the session key and data identifying the client. The TGT is encrypted with a secret key known only to the KDC, and the session key is encrypted with the client’s secret key, derived from the user’s password.
  • The user starts SAPGUI for Windows and selects the entry for SID. This entry is configured to use SNC which in turn communicates with Kerberos authentication package to request a Kerberos service ticket (ST) for the SAP system.
  • The Kerberos authentication package requests a new service ticket for the SAP system and sends the Ticket Granting Ticket (TGT) together with the service request. The Ticket Granting Service (TGS) encloses a Service Ticket in a response to the client and encrypts the response using the session key. The service ticket itself is encrypted with the key that the KDC shares with the SAP server, and contains the client’s identity, the session key, timestamp and other information. This service ticket is stored in a ticket cache so that later retrievals can be made from the ticket cache.
  • The client extracts the service ticket using the session key, creates an authenticator record with the session key, and sends the service ticket and the authenticator record to the SAP server through SAPGUI. The service ticket is presented whenever requested.
  • The SAP system receives the service ticket and validates it by invoking the Kerberos authentication package on the server through a GSS-API wrapper, SNC Wrapper.
  • The SNC Wrapper functions as a wrapper between SAP SNC protocol, which supports the GSS-API interface, and Windows (ABAP application server)  Kerberos client product to validate the ticket.
  • Windows (ABAP application server)  Kerberos Client Product are invoked to validate the ticket. Windows Kerberos Product are configured to use Active Directory server as the KDC server which means there is trusted relationship between the SAP server and the KDC similar to the one that described between the PC client and the KDC. The SAP server using Windows Kerberos Client product decrypts the service ticket, extracts the session key, and uses this key to verify the authenticator record. The communication between the SAP server and the KDC works even if there is a firewall in between but in this case firewall rules must be adjusted to allow Kerberos communication.
  • If the ticket is validated, the SAP system extracts the User Principal Name (UPN) of the user, and then maps this information to an account maintained by the SAP system. The user is then logged on to the SAP system using the account maintained by SAP. Since the user authenticated to the SAP system using their default Kerberos credentials, a SSO solution is achieved for the user.

This how to guide describes only how to configure the solution for SAP GUI for Windows with a Kerberos integration

Environment Used in this blog :

SAP Netweaver Version : 7.4 / 7.5

SAP Kernel : 749_REL / 753_REL

OS : Suse Linux Enterprise Server 12 SP5

Windows desktop Version : Windows 10

SAP GUI Version :750

IE version : IE11


1.1 Create service user

Create a user which works as a Service Principal. Here the <sid>adm is used.

Set “Password never expires”, “Uncheck Use DES encryption types for this account”

  1.2 Set Service Principal Name

setspn -A <ServiceName>/<hostname_linux_server>.<domain_name> <DOMAIN_SHORT>\<service_user>

Command to set SPN :

       setspn -A SAPService/hostname@domain_name DOMAIN_SHORT\sidadm

–case sensitive use the command as shown above

  1.3 Export Keytab from Microsoft ADS

The key export is done by ktpass

ktpass -princ <ServiceName>/<hostname_linux_server>.<domain_name>@<DOMAIN_NAME>  -mapuser <DOMAIN_SHORT>\<service_user> -crypto <ENCRYPTION_TYPE> -ptype <PRINCIPAL_TYPE> -mapop set -pass <your_password> -out <filename>

Command to export Keytab :

ktpass -princ SAPService/hostname@DOMAIN_NAME-mapuser DOMAINSHORT\sidadm -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -mapop set -pass <*password*> -out <SID>aes.keytab

 –case sensitive use the command as shown above

          The output would look like

C:\Windows\system32>ktpass -princ SAPService/hostname@DOMAIN_NAME-mapuser DOMAINSHORT\sidadm -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -mapop set -pass 123456 -out s4haes.keytab

Targeting domain controller: Domain Controller name

Successfully mapped SAPService/hostname to sidadm.

Password successfully set!

Key created.

Output keytab to SIDaes.keytab:

Keytab version: 0x502

keysize 99 SAPService/hostname@DOMAIN_NAMEptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength 32 (0xacedae5fa52a5a9bec84de453120998279663b972ec138952e6b1371fbd4dda7)

The file <SID>aes.keytab contains the necessary key and can be copied to the linux server



2.1 Configuration Kerberos

The configuration is held in /etc/krb5.conf by default. Adjust the DOMAIN name and KDC as per you environment . You could obtain these details by executing a klist command from any of the test user desktop (which is connected to AD)

    # "dns_canonicalize_hostname" and "rdns" are better set to false for improve
d security.
    # If set to true, the canonicalization mechanism performed by Kerberos clien
t may
    # allow service impersonification, the consequence is similar to conducting
TLS certificate
    # verification without checking host name.
    # If left unspecified, the two parameters will have default value true, whic
h is less secure.
    dns_canonicalize_hostname = false
    rdns = false
#       default_realm = EXAMPLE.COM
        default_realm = DOMAIN.LOCAL
#       EXAMPLE.COM = {
#                kdc =
#               admin_server =
#       }
                kdc = DC.DOMAIN.LOCAL
               admin_server = dc.DOMAIN.local
  .domain.local = DOMAIN.LOCAL
   domain.local = DOMAIN.LOCAL

    kdc = FILE:/var/log/krb5/krb5kdc.log
    admin_server = FILE:/var/log/krb5/kadmind.log

        default_ccache_name = FILE:/tmp/krb5cc_%{uid}



   2.2 Key import to Linux

The key from sidaes.keytab will now be imported to /etc/krb5.keytab. For this the tool ktutil under user root is used.

Verify if the SPN name and the encryption algorithm are same as we set up in setp 1.3 using the below commands


rkt /tmp/sidaes.keytab

l -e


Once the keytab file looks fine write the keytab into etc directory using below commands


wkt /etc/krb5.keytab



Import Keytab

   2.3 Initialize Kerberos: Ticket Granting Ticket (TGT)

 Get your first TGT with: kinit –V –k <ServiceName>/<hostname_linux_server>.<domain_name>@<DOMAIN_NAME>

Command : kinit -V SAPService/linuxhostname@DOMAIN_NAME


Generate Kerberos token

Since we have setted the cache path in the conf file the cache file will be created in the /tmp/

If the parameter is not defined it will use the /run/user/<uid> as default path.

   2.4 Set permissions

 Under the user root change the permissions for the key table of the system. Else <sid>adm can’t get a valid ticket.

chgrp sapsys /etc/krb5.keytab

chmod 640 /etc/krb5.keytab


Permissions for Keytab

   2.5 Automatic renewal of the Kerberos TGT

 Kerberos tickets have a limited lifetime (10 hours by default) and therefore have to be renewed. The easiest way is to setup a cron job. In this example the ticket will be renewed every 6th hour:

crontab –e 01 0,6,12,18 * * * /usr/bin/kinit -R SAPService/hostname@DOMAIN_NAME

Should the renewal of the ticket fail for any reason and therefore the linux server not possess a valid TGT, you will find following error on your SAP instance in the developer trace of the work process:

 N      GSS-API(maj): Miscellaneous failure

 N      GSS-API(min): No credentials cache found

3.Configuration in SAP

3.1 Check GSSAPI library

Check the GSS API library in the linux server under the path /usr/lib64/

   3.2 Configure the below SNC parameters in Default profile

snc/permit_insecure_start = 1

snc/data_protection/use = 3

snc/data_protection/max = 3

snc/data_protection/min = 1

snc/accept_insecure_r3int_rfc = 1

snc/accept_insecure_rfc = 1

snc/accept_insecure_cpic = 1

snc/accept_insecure_gui = 1

snc/gssapi_lib = /usr/lib64/

snc/enable = 1

snc/identity/as = p:SAPService/hostname@DOMAIN_NAME

login/password_change_for_SSO = 0



  3.3 Restart SAP

4.Setup for Windows desktop Client

4.1 Installation and configuration of wrapper DLLs

To install the DLLs manually follow the SAP Note #352295.

Copy the file gsskrb5.dll in the directory %windir%\system32. Add the following system variable: Variable SNC_LIB with the value %windir%\system32\gsskrb5.dll.


   4.2 Configure SAP Logon

Edit the Landscape.xml for the corresponding system to include SNCname and include the parameter to enable the SNC .

<Service type=”SAPGUI” uuid=”xxxxxxxxxxxxxxxx” name=”SID-Dev” systemid=”SID” msid=”xxxxxxxxxxxxxxxxxxxx” mode=”1″ server=”hostname:3200″ sncop=”9″ sapcpg=”1100″ dcpg=”2″ sncname=”p:SAPService/hostname@DOMAIN.COM”/>

Rollout/Replace the Landscape.xml in the SAP Logon GUI

5.Mapping of User in SAP

5.1 Map the user in SAP

 Use the TCODE SNC1 or report (RSUSR300) to set the SNC name and then execute  SNC4 to determine the canonical name.




Proposed SNC name


Log Display


Verify SNC name from SU01



6.1 Launch the SAP session from the SAPLOGONpad GUI in the test user desktop

6.2 Launch SAPGUI using from a HTML page.

     One of our client has a requirement of launching SAPGUI session from a browser . So we have developed a simple HTML page by invoking SAPGUI shortcut using Java Script. The logic is below

Launch the HTML page from IE (Enable Active X controls in browser , instructions below)


HTML page

Click on SAP Login button will take you to SAP session directly without userID/password

    <script src=""></script>
     <button id="go" type="button" >SAP Login</button>
            var usr = 'XXX';
            var pass = 'YYY';
            var sid = 'SID';
            var mand = 100;
	    var sncname='p:SAPService/hostname@DOMAIN.LOCAL';
	    var sncparam=9;
    function openSAPGui(sid,client,sncname,snc_qop){
        var shell =  new ActiveXObject("WScript.Shell");'sapshcut.exe -system="'+sid+'" -client='+client+' -language=EN -sncname="'+sncname+'" -snc_qop='+snc_qop+'');        

Steps to Enable Active -X controls in IE browser (only IE 11)

a) Go to Tools–>Internet Options

b) Select security tab

c) Click on Trusted Sites (or Local Intranet depending on whether your site is trusted or not)

d) Click on Custom Level

e) Ensure that “Initialize and script active x controls is not marked safe for scripting” is enabled – this comes under Activex controls and plug-ins section towards 1/4th of the scroll bar.

Click OK, OK.

Once this is completed, clear the browser cookies and cache. Close all your browser sessions. Reopen the IE to launch your site

Note : On Edge browser you can enable IE mode . Goto–> Settings –>Default browser


IE mode in Edge Browser



By following the above steps you would be able to achieve single sign on to SAP session using the kerberos authentication .

Be the first to leave a comment
You must be Logged on to comment or reply to a post.