NTLM!!!!!!! want to know how it works!!!!!!!!!

Overview and working of NTLM

Why NTLM:

Microsoft adopted Kerberos as the preferred authentication protocol for Windows 2000 and subsequent Active Directory domains. Kerberos is typically used when a server belongs to a Windows Server domain, or if a trust relationship with a Windows Server Domain is established in some other way (such as Linux to Windows AD authentication). But NTLM can be used in either case(if you have a active directory or not).

NTLM is still used in the following situations:

The client is authenticating to a server using an IP address

The client is authenticating to a server that belongs to a different Active Directory forest that has a legacy NTLM trust instead of a transitive inter-forest trust

The client is authenticating to a server that doesn't belong to a domain

No Active Directory domain exists (commonly referred to as "workgroup" or "peer-to-peer")

Where a firewall would otherwise restrict the ports required by Kerberos (typically TCP 88)

Working of NTLM in general words:

The following steps present an outline of NTLM non-interactive authentication. The first step provides the user's NTLM credentials and occurs only as part of the interactive authentication (logon) process.

1. (Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.

2. The client sends the user name to the server (in plaintext).

3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.

4. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.

5. The server sends the following three items to the domain controller:

◦User name

◦Challenge sent to the client

◦Response received from the client

6. The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.

7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.

NTLM working in terms of status codes:

Windows NT Challenge/Response protocol

Windows NT Challenge/Response (NTCR) protocol differs from Kerberos in that the server presents the HTTP client with a "challenge" and the client responds with its response. This way, the client's password is never sent over the network. Authentication with the NTCR protocol occurs as follows:

1. Typically, the client issues an initial anonymous request. When the anonymous request is rejected, IIS returns a 401.2 error and the WWW-Authenticate headers.

2. If the client fails or does not support Kerberos, the Negotiate and NTLM header values initiate an NTCR authentication exchange. The client closes the TCP connection, opens a new one, and sends a request that includes an Authorization: NTLM header. This header also includes encoded text that represents the users UserName, ComputerName, and Domain. This text is used by the Windows Security Support Provider Interface (SSPI) to generate the challenge. If the user account is not a local Windows account on the IIS server, the data is passed on to an appropriate domain controller, which then generates the challenge.

3. The challenge is sent to the client and IIS returns another 401.1 error.

4. The client uses its password and the challenge to create a mathematical hash. The client sends the hash back to the server in another Authorization: NTLM header.

5. The server accepts the response, and the local security provider or the appropriate domain controller recreates the same hash and compares the two. If they match, the user is successfully authenticated.

NTLM Working from Fiddler Perspective:

The following is a scenario-based example in which IIS is configured to support only the NTLM protocol. In IIS 6.0 and in earlier versions, this is done by having the NTAuthenticationProviders metabase key set to "NTLM". In IIS 7.0 and in later versions, only the NTLM protocol must be listed as a provider in the <windowsAuthentication> section.
Again, Internet Explorer does not include any authentication information in the first request on a new connection:

If the IIS server is not configured to support Anonymous authentication, the server returns a 401.2 status that tells the client that the client is unauthorized. Together with the error status, the server also sends a list of authentication protocols that the server supports. The response headers that IIS returns in this NTLM-only scenario resemble the following:

IIS then writes an entry that resembles the following to the IIS log:

When the client receives the server's notification that the server supports the NTLM protocol, the client re-sends the request. The client includes authentication information in an Authorization header:

As part of the NTLM handshake, the server acknowledges that the client has sent authentication information. However, the server needs the client to send more information. Therefore, the server returns another 401 response that resembles the following:

IIS then writes an entry in the IIS log that resembles the following:

The 401.1 status that IIS sends tells the client that the client must provide the remainder of the valid authentication information. The client receives this challenge. The client then sends one more request that resembles the following:

When the IIS server receives this request, the IIS server communicates with a domain controller to complete the authentication request. When the client's authentication request is confirmed, IIS sends a response that resembles the following:

After IIS sends this response, IIS writes the following associated entry to the IIS log:

References:

http://en.wikipedia.org/wiki/NTLM

http://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/bb643328.aspx

http://msdn.microsoft.com/en-us/library/bb643328.aspx

Author: Chiranth Ramaswamy