Menu Search Sign up


What is Kerberos?

Kerberos is a single sign-on system for distributed environments, and is commonly used for SSO in enterprise internal network. Kerberos uses symmetric key cryptography. It was designed specifically to eliminate the need to transmit passwords over the network. It is an authentication protocol that can also provide confidentiality and integrity protection of the sensitive data passed back and forth over a network.

The current version, Kerberos version 5, was published by the IETF (Internet Engineering Task Force) as RFC 1510. This is the version on which Microsoft’s implementation in Windows 2000/XP/Server 2003 and above is based.

Kerberos Authentication Process

We will walk through the Kerberos authentication process with the following example:

  • Emily comes in to work and enters her username and password into her workstation at 8 A.M.
  • The Kerberos software on Emily’s computer sends the username to the authentication service (AS) on the key distribution centre (KDC), which in turn sends Emily a ticket granting ticket (TGT) that is encrypted with Emily’s password (secret key).
  • If Emily has entered her correct password, then this TGT is decrypted and Emily gains access to her local workstation desktop.
  • When Emily needs to send a print job to the print server, her system sends the TGT to the ticket granting service (TGS), which also runs on the key distribution centre (KDC). This allows Emily to prove that she has been authenticated and allows her to request access to the print server.
  • The TGS creates and sends a second ticket to Emily, which she will use to authenticate to the print server. This second ticket contains two instances of the same session key, one encrypted with Emily’s secret key and the other encrypted with the print server’s secret key. The second ticket also contains an authenticator, which contains identification information on Emily, her system’s IP address, and a timestamp.
  • Emily’s system receives the second ticket, decrypts and extracts the session key encrypted with her secret key, adds a second authenticator set of identification information to the ticket and encrypts it with the session key, and sends the ticket onto the print server.
  • The print server receives the ticket, decrypts and extracts the session key encrypted with print server’s secret key, and decrypts and extracts the two authenticators in the ticket. If the printer server can decrypt and extract the session key, it knows that the KDC created the ticket, because only the KDC has the print server’s secret key that was used to encrypt the session key. If the authenticator information that the KDC and the user put into the ticket matches, then the print server knows that it has received the ticket from the correct principal (Emily).
  • Once this is completed, it means that Emily has been properly authenticated to the print server and the server prints her document.

Integrated Windows Authentication (SPNEGO HTTP Authentication)

Integrated Windows Authentication is defined by RFC 4559, or “SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows”. It extends the use of Kerberos over the HTTP Access Authentication Framework. This RFC is also known as “SPNEGO HTTP authentication”.

The following example illustrates how the Integrated Windows Authentication works.

  • Step 1 The client requests an access-protected document from server via a GET method request. The URI of the document is "".

C: GET dir/index.html

  • Step 2 The first time the client requests the document, no Authorization header is sent, so the server responds with

S: HTTP/1.1 401 Unauthorized

S: WWW-Authenticate: Negotiate

  • Step 3 The client will obtain the user credentials (more precisely, using the SPNEGO GSSAPI mechanism to generate a GSSAPI message) to be sent to the server with a new request, including the following Authorization header:

C: GET dir/index.html

C: Authorization: Negotiate a87421000492aa874209af8bc028

  • Step 4 The server will decode the message and try to establish a security context (more precisely, decode the gssapi-data in the message and pass this to the SPNEGO GSSAPI mechanism in the gss_accept_security_context function). If the context is not complete, the server will respond with a 401 status code with a WWW-Authenticate header (containing the gssapi-data).

S: HTTP/1.1 401 Unauthorized

S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356

  • Step 5 The client will decode the gssapi-data, pass this into Gss_Init_security_context, and return the new gssapi-data to the server.

C: GET dir/index.html

C: Authorization: Negotiate 89a8742aa8729a8b028

  • Step 6 This cycle can continue until the security context is complete. When the return value from the gss_accept_security_context function indicates that the security context is complete, it may supply final authentication data to be returned to the client. If the server has more gssapi data to send to the client to complete the context, it is to be carried in a WWW-Authenticate header with the final response containing the HTTP body.

S: HTTP/1.1 200 Success

S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca

  • Step 7 The client will decode the gssapi-data and supply it to gss_init_security_context using the context for this server. If the status is successful from the final gss_init_security_context, the response can be used by the application.

It should be noted that the SPNEGO HTTP authentication facility is only used to provide authentication of a user to a server. It provides no facilities for confidentiality and integrity protection of the transmission of data. You will need other means like TLS to provide such protection.