HTTP-Based Cross-Platform Authentication by Using the Negotiate Protocol

Sanj Surati & Michael Muckin
Microsoft Consulting Services

December 2002

Applies to:
   Windows® 2000
   Non-Windows web servers
   Kerberos-capable clients

Summary: Learn how you can implement Kerberos-based authentication by using HTTP in a cross-platform environment. This article is the first in a series.

The series consists of three parts:

• "Network Infrastructure"—Describes the infrastructure required to enable the solution.
• "SPNEGO Tokens and the Negotiate Protocol"—Describes the negotiate protocol and binary layouts of information sent over the wire.
• "SPNEGO Token Handler API"—Describes and provides the C source code for an API that will parse and create SPNEGO tokens.

Contents

Introduction
Network Topology
Kerberos Infrastructure Configuration
Summary
Appendix A - References

Introduction

With the availability of Kerberos-based authentication in Windows® 2000, there has always been the possibility of interoperable cross-platform authentication with web browsers. Just as integrated authentication in IIS does not require HTTP-based Windows clients to manually re-authenticate themselves by forcing users to reenter their passwords, so can the same functionality be available when communicating with non-Windows web servers from Kerberos-capable clients. The ability to have cross-platform authentication on a network significantly reduces complexity both for administrators and users. With cross-platform authentication, administrators need only worry about Active Directory. Also, users no longer need to remember multiple accounts and passwords, or reenter their credentials when they want to access non-Windows web-based resources.

On a Windows 2000 server with integrated authentication turned on, IIS authenticates with Windows 2000 Internet Explorer clients using what is called the Negotiate authentication package (that implements the SPNEGO protocol). This article will provide a high-level overview of the protocol and show the configuration settings necessary to enable Kerberos as the negotiated authentication mechanism.

Assumptions

Intranet web-based applications

This solution assumes the following to be true:

• The use of this cross-platform authentication solution is intended for intranet apps only.
• Microsoft's Active Directory/Kerberos implementation is the single user and authentication store.
• MIT V5 Kerberos is implemented on the UNIX hosts.
• This solution was verified on Solaris 2.8.

This article does NOT cover:

• Custom Kerberos error handling
• Ticket/Session expiration handling

This article assumes that the reader is familiar with Kerberos, the HTTP protocol and C. For an overview of Kerberos authentication in Windows 2000, as well as definitions of important Kerberos-related terminology such as Key Distribution Center (KDC), Ticket Granting Service (TGS), keytab files and more, see Windows 2000 Kerberos Authentication. Additional resources are outlined in Appendix A.

Although this article describes a general cross-platform solution, for ease of reference we will assume non-Windows 2000 web servers to be running a flavor of UNIX with MIT Kerberos V5, which is the environment used to develop this solution. Additionally, although we reference Windows 2000 in this article, the same information is applicable to later versions of Windows (for example, Windows 7 and Windows Server 2008 R2).

Network Topology

Interoperability

There have been many documented and successful implementations of Windows UNIX Kerberos interoperability using the MIT V5 Kerberos standard. The table below describes the typical scenarios encountered with Kerberos interoperability.

Table 1. Kerberos Interoperability Scenarios

This particular solution is slightly different, however, in that it does not neatly fall into any of the above scenarios; most of these scenarios assume another non-Windows Kerberos realm. In this case, there is no existing Kerberos realm—and one of the main objectives is to get the UNIX servers to be recognized as members of the Windows 2000 Kerberos realm (domain). How this is accomplished is discussed in the "Kerberos Infrastructure Configuration" portion of this article.

System Requirements

To enable a properly functioning environment for HTTP-based cross-platform authentication, the following components are required:

• Server systems:

  • Windows 2000 or later Active Directory
  • Service accounts for mapping Kerberos services
  • Service Principal Names (SPN) configured correctly
  • Key tab files created and exported

• UNIX web servers:

  • MIT Kerberos V5 Generic Security Service API (GSS-API)
  • Web server software configured to use Active Directory Kerberos realm
  • Keytab import and configuration; successful authentication to Kerberos realm
  • Custom SPNEGO code and custom code in web server to perform HTTP header exchanges

• Client systems:

  • Windows 2000 Professional with Service Pack 2 or later Windows client operating system
  • Internet Explorer 6.0 with Service Pack 1 or later (on Windows 2000)
  • Proper configuration of the browser

  Note   If you are running Internet Explorer 6.0, please refer to the "Client Side—Internet Explorer" section of this document for specific details about how to configure this version of Internet Explorer.

HTTP-Based Cross-Platform Authentication Overview

The cross-platform authentication design emulates the "Negotiate" behavior of native Windows-to-Windows authentication services on UNIX web servers. For informational purposes, the native Windows Negotiate (also known as Simple and Protected Negotiate (SPNEGO)) sequence is described in the figure below. The Security Support Provider Interface (SSPI) is conceptually equivalent to where GSS-API calls are handled.

Negotiate behavior in Windows 2000

Figure 1. Windows Negotiate Protocol
This figure was taken from Designing Secure Web-based Applications with Windows 2000 by Michael Howard and published by Microsoft Press.

HTTP-based cross-platform authentication design

The design begins with a user who is logged on to the Windows 2000 domain. This is essential—the user must have acquired Kerberos credentials from the domain; local logons will not work.

The logged-on user then attempts to access a web application running on a UNIX web server. The web server asks for authentication with Kerberos (by using SPNEGO). The client obtains a ticket for the requested service from the KDC and presents these credentials back to the web server. The web server extracts—by using the GSS API—the user's credentials and authenticates the request.