Microsoft Windows Single Sign-On options

Available options to use Single Sign-On from or among Microsoft Win32 platforms, known Problems on specific Platforms.

You want to re-use the Microsoft Windows NT/2000/XP/2003 based authentication for single Sign-On to SAP R/3 systems.

SAP R/3 offers a software interface to use authentication by third party security software for Single Sign-On into SAP R/3 Systems. This interface is based on the GSS-API v2 standard, that was developed in the IETF (Internet Engineering Task Force) and published as RFCs 2743+2744. SAP offers interoperability certification for third party software through the CSP program.

Microsoft has implemented authentication and single sign-on on their Win32 plattforms Windows NT,9x,2000,ME in a proprietary variant of GSS-API named Microsoft "SSPI" (Security Service Provider Interface).

The proprietary NT Lan Manager Security Service Provider (NTLM-SSP) shipped with all Win32 Platforms (Win9x/ME/NT4/W2K/XP/W2K3) offers client-only authentication based on a challenge-response protocol.

Windows 2000 and above additionally contains a "Kerberos 5" SSP, offering integrity protection and encryption of the entire network communication in addition to secure authentication. The Microsoft Kerberos SSP should be on-the-wire compatible with the standardized Kerberos 5 protocol, 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, NOT for local computer accounts.

Microsoft Kerberos FAQ (Knowledgebase Article 266080) http://support.microsoft.com/kb/q266080/

Windows XP Home appears to lack true Kerberos 5 support according to this Information on Microsoft's Web-Site: http://www.microsoft.com/windowsxp/home/using/productdoc/en/sag_ipsec_ov9.asp

Windows XP service pack 2: Please download and install gsskrb5.dll v1.0.8 or newer--attached to this note. You may additionally need to request the Microsoft Hotfix 885887: http://support.microsoft.com/kb/q885887
since there are some new bugs in Microsoft's kerberos.dll of XPsp2, and it seems that not all aspects of these bugs can be sufficiently addressed with the workarounds in gsskrb5.dll v1.0.8.

Microsoft Windows 2003:contains several proprietary changes and extension to the Kerberos 5 protocol (some clearly violate existing protocol specs) and some new bugs, and that may cause severe interoperability problems. Service Pack 1 for Windows 2003 should fix most of those problems, but PLEASE do not let this information impair your regular careful planning and testing before applying a Service Pack to productive domain controllers.
SEE BELOW for additional information concerning Windows 2003.

SAP provides a seperate wrapper DLL for each of these two independent Microsoft Security Service Providers (called "mechanisms" in GSS-API terminology). Note however, that only one mechanism can be installed and used with the SNC interface in SAP R/3.

GSSNTLM.DLL (previously also shipped as "GSSAPI32.DLL)
to use the NTLM SSP for Single Sign-On in pure Microsoft Win32 environments (users AND application servers on Microsoft platforms). We provide *ONE* single GSSNTLM.DLL that is supposed to work across all of the platforms Win95, Win98, WinME, NT4, W2K, XP and W2K3.
GSSNTLM.DLL will provide only the most basic security: a non-disclosing, uni-directional authentication. However, it will NOT provide integrity NOR confidentiality protection for the actual communication.
GSSKRB5.DLL
to use the Kerberos 5 SSP of Windows 2000 for Single Sign-On. It can be used in pure Windows 2000 environments as well as in combination with Kerberos 5 implementations from other vendors on Unix and those Microsoft Win32 platforms, for which Microsoft doesn't provide Kerberos themselves, like Windows NT4/9x and XP-Home. Microsoft provides some information on interoperability of W2K Kerberos with non-Microsoft KDCs/Realms on their Web-Server -- go to http://www.microsoft.com/ and search for "ksetup.exe". There is also some technical information in the README that is included with the Source code for our gsskrb5.dll (see below).
GSSKRB5.DLL will provide a secure mutual authentication along with integrity and confidentiality protection for the entire communication.


The two wrapper DLLs are available for download as attachments to this note:

win32sso.zip (for Microsoft Win32 platforms)
win64sso.zip (for Microsoft Win64 platforms)

The source code for (both!) DLLs is also available for download:

ftp://ftp.sap.com/pub/ietf-work/gssapi/gsskrb5/


Information on BC-SNC certified software partners is available from our Web-Server:

http://www11.sap.com/partners/directories/SearchSolution.epx

choose "Secure network communication" in the Certification Category andpress the search button.

and Information about the BC-SNC certification itself is available from SAP Developer Network (SDN) on this page:

https://www.sdn.sap.com/irj/sdn/sdnservices/icc?rid=/webcontent/uuid/e112cb72-0501-0010-63a3-f45326c176ae

The freely available (but maybe US-crypto-export restricted) Kerberos 5 implementation from MIT is interoperable with GSSKRB5.DLL, however building, installing and using it requires a significant amount of expertise. Support by SAP in case of problems is limited! (see note 150380). There are a few customers using it, and the MIT itself is one of them. We recommend that you take a look at the BC-SNC certified products. The products from the two vendors CyberSafe and Platinum (now Computer Associates) are implementations of the Kerberos 5 protocol and should be interoperable with GSSKRB5.DLL.

All of the major Unix vendors seem to be shipping a version of Kerberos 5 these days. These implementations should be wire-interoperable with each other and with Microsoft W2K (not necessarily W2K3!), however they may not be interoperable with SAP's shared library interface to GSS-API v2 mechanisms.

SAP offers a BC-SNC interface certification for complete third-party Single Sign-On solutions (i.e. a solution MUST include the Win32 SAPgui front-end platform at least one back-end platform). The SAP test tool "GSSTEST" is used to test interoperability and functions of a third party gss-api library, and it is freely available for download from our Web-Server (as source code), follow the first link about BC-SNC certification above. This tool can be used to check interoperability between SAP-SNC and a third-party library on any particular platform. Keep in mind, however, that SAP does *NOT* certify interoperability among implementations of a standardized protocols (like Kerberos) from different vendors, only complete single-source solutions.

In case you want to use an OS-Vendor supplied Kerberos5 implementation and in particular in a heterogeneous environment with Microsoft W2K or XP Workstations then please ask your OS-vendor for support, documentation on installation and an interoperability statement with SAP BC-SNC certifiable interface and Microsoft's Kerberos.


Windows 2003 continued:


1. Windows 2003 64-bit (Fixed with SP1, and Hotfix 889529 for IA64):
There is a single-bit memory corruption in the Kerberos SSP function ExportSecurityContext() which is called on the SAPAppServer when gi64krb5.dll (ia64) or gx64krb5.dll (amd64) is used for Single Sign-On, which can corrupt the cryptographic session key resulting in a "Message out of Sequence" error on the SAP AppServer.

2. Windows 2003 Active Directory (Fixed with SP1, Hotfix 829074):
When installing or upgrading an existing Active Directory to Windows 2003, then your users suddenly have to be careful when typing their username on the computer logon screen, because the Windows 2003 KDC will issue tickets for arbitrarily cased names instead of the canonical case-sensitive Kerberos Principal names, creating myriads of distinct user principals at the Kerberos protocol level.

i.e. a user with an NT-account sampleuser may authenticate as one of 1024 entirely distinct Kerberos principals, but usually only one of those will appear on the access control list of a Kerberos-based server. In oder to "switch" to the correct name, a user will have to terminate all apps, logoff and re-logon with the correctly spelled username!


3. Before you switch the domain functional level of your Windows 2003 Active Directory from "Windows 2000" to "Windows 2003",
a) you should use the gsskrb5.dll attached to this note on all of the frontends/clients. On Windows XP Professional and Windows 2003 machines you will get a credential error with older versions of gsskrb5.dll.
b) you will need to define Kerberos Service Principal Names in the Active Directory for all service accounts of your AppServers (traditionally called something like SAPServiceC12) using the SETSPN.EXE from the OS installation CD archive supporttoolssupport.cab and call it for every SAP service account in the following fashion:
SETSPN -A SAPServiceC11/dontcare NT4DOMAINSAPServiceC11
This is necessary to re-enable the correct rfc-1964 kerberos protocolexchange for authentication. The name isn't actually used by gsskrb5.dll, this is just to trigger an undocumented side effect (there is no API parameter to steer this behaviour so that a workaround within gsskrb5.dll is impossible).



Microsoft W2K Kerberos in general:

Other known problems: There is a memory leak (heap and non-paged) in QueryCredentialsAttributesA(NAMES) of Win2Ksp4 and WinXPsp2 (not W2K3) which can lead to operational problems on SAP AppServers. gsskrb5.dll v1.0.8 contains a workaround for this bug using the UNICODE-variant of the API call, which does not leak memory. Normally the leak of non-paged pool will hit a process resource limit and cause further SSPI calls to fail with "out of memory" errors, preventing NTLM or Kerberos Single Sign-On from succeeding. The server process itself will usually continue running (having leaked only 130 MBytes of heap), so a manual intervention and restart is necessary.


As described at the beginning gsskrb5.dll attempts to provide an rfc-1964 compliant Kerberos 5 gssapi mechanism which is fully interoperable with Unix-based implementations of rfc-1964 Kerberos. In Kerberos, the name of the user and the name of the Kerberos realm are CASE-SENSITIVE. On Microsoft Windows however, the names of accounts and the name of domains are case-insensitive. Additionally, all of the Microsoft User Interfaces display the lowercased domain name instead of the all-uppercased Kerberos realm name.

Unfortunately the SSPI call TranslateName() to map/convert from Microsoft's case-insensitive representation into the correct, canonical and CASE-SENSITIVE Kerberos Principal Name syntax is either incomplete or broken, failing the translation into the *default* Kerberos principal names, which is why gsskrb5.dll can not perform the canonicalization programmatically. When the Active Directory runs on Windows 2003, then TranslateName() appears to perform the mapping, which differs from the "ERROR_NONE_MAPPED" that Windows 2000 Active Directory returns.

So please remember: whenever you enter the Kerberos Principal Name for a user into the SNC-ACL of SAP software, it must be provided in verbatim correct syntax. If the user account is managed by a Microsoft W2K+ domain, then the realm name is the all-upper-cased form of the DNS-Domainnname of the Windows Domain.