Integrated Windows Authentication

Integrated Windows authentication is the most secure method of authentication, but it is available only with Internet Explorer. This authentication type had been known previously as NTLM authentication and Windows NT Challenge/Response authentication. In Integrated Windows authentication, the user's browser proves itself to the server using a cryptographic exchange during the authentication process.

Integrated Windows authentication supports both the Kerberos v5 and the NTLM (NT LAN Manager) protocols for authentication through the Negotiate package. If you are using Active Directory, and the browser supports it (IE 5 or above with Windows 2000), Kerberos is used; otherwise, NTLM is used. Both Kerberos and NTLM have limitations on their use. Interestingly enough, each one's strength is the other's weakness. Kerberos generally works with proxy servers, but it tends to have a hard time with firewalls. NTLM generally works through firewalls, but it tends to have a hard time with proxy servers.

About Microsoft Negotiate

Microsoft Negotiate is a package that serves as an interface between different security support providers. It can choose among several different authentication packages. IIS uses the Negotiate package for authentication, which currently chooses between Kerberos and NTLM. Support for future authentication packages can be added, though, which is Negotiate's strength. By default, Negotiate chooses Kerberos, because it's the more secure protocol. If, for some reason, Kerberos is not available, Negotiate falls back to NTLM.

About NTLM Authentication

NTLM is an enhancement of the old LM (LAN Manager) authentication protocol. NTLM works by using a challenge/response between the server and the client without sending the user's clear text password across the network. The client has to prove it knows the user's password by sending an encrypted hash.

Here's how NTLM works:

1. The user types in a username, password, and a domain name when logging in to the client machine.

2. The client creates a hash of this password and discards the original.

3. The client sends the server the plaintext username.

4. The server sends a 16-bit nonce to the client.

5. The client encrypts this nonce along with the hash of the user's password and sends it to the server.

6. The server then sends the username, the nonce, and the client's response to a domain controller.

7. The domain controller encrypts the nonce along with its own hash of the user's password, and it compares the value to the one sent by the server.

8. If the values match, the domain controller notifies the server that authentication is successful.

9. If the values do not match or no username matches, the domain controller notifies the server, which then sends that message to the client. The client's browser then prompts the user for login information.

About Kerberos Authentication

The original Kerberos was the three-headed dog in Greek mythology that kept people from entering the underworld. The modern day Kerberos protocol provides for secure authentication to resources. Kerberos relies on secret key authentication, in which client and server share a single key that is used for encryption and decryption. The client proves it knows the key by encrypting a message, and the server proves it knows the key by decrypting that message. It then takes part of that message, encrypts it, and sends it back to the client. If the message is intact, everybody knows who everybody else is.

Kerberos relies on a central server, called a Key Distribution Center (KDC), to provide all the keys. The KDC issues Ticket-Granting Tickets (TGTs) to clients requesting access to a server resource.

Here's how the client gets the initial TGT from the KDC:

1. The user logs in to the client with a username and password.

2. The client encrypts the password and saves it.

3. The client sends the KDC a message requesting credentials for the TGT service, along with the user's encrypted password.

4. The KDC compares the encrypted password with its master copy to make sure they match. It also checks the timestamp the client added to the request to make sure it is within five minutes of its own time.

5. If everything matches, the KDC creates the requested credentials for the TGT service by creating a logon session key and encrypting it with the user's key.

6. The KDC also creates another credential by encrypting the logon session key and a TGT for the user with its own master key.

7. The KDC then sends both credentials to the client.

8. The client decrypts the logon session key from the first credential using its encrypted password, and it stores that logon session key in its ticket cache.

9. The client also stores the TGT in its ticket cache.

Now that the client has a TGT, it can use that TGT to get tickets to access resources. Here's how that works:

1. The client asks the KDC for a ticket to access resources on a server. The client presents its TGT to the KDC along with the desired resource name and an authentication message, which is encrypted with the logon session key.

2. The KDC decrypts the TGT using the master key, extracts the logon session key, and uses that logon session key to decrypt the authentication message. If it matches, the client is verified.

3. The KDC creates a service session key for the client to present to the server when requesting resources, and it encrypts the service session key with the client's logon session key.

4. The KDC also encrypts that service session key with the server's master key into a ticket.

5. The KDC then sends both credentials to the client, which decrypts the session key using its logon session key and stores the service session key and the ticket in its cache.

Now the client has a ticket it can present to the server to gain access to resources.

1. The client sends the server the session ticket and an authentication message, which is encrypted with the service session key.

2. The server decrypts the session ticket and compares the timestamp the client put on the request to make sure it is within 5 minutes of its own time. It then gets the session key from this ticket.

3. The server then encrypts the timestamp in the session ticket with the session key and sends it to the client.

4. The client decrypts the message and compares the timestamp with the original. If it matches, everybody knows who everyone else is.

This is a very involved process, but it makes sure that the identity of everyone communicating is known and verified. Obviously, the KDC plays an important part in this, and it's important to make sure your KDC is secure.