(2011-02-13) Accessing A Resource With The NTLM Authentication Protocol
Posted by Jorge on 2011-02-13
During the interactive logon the domain name, the user name and the password are collected as the credentials to be used for subsequent network logons. The password will not be used in its text format, but rather in its hashed format. Sending passwords of the wire is a bad thing, and that’s why the NTLM authentication protocol uses a challenge/response mechanism to authenticate a user when accessing a resource. During authentication three parties are involved, being the client, the server (the resource) and the DC. The client is from where access is requested, the server is the resource for which access is requested and the DC is the intermediate party that’s performs the authentication. So, with NTLM, the path is: "Client" –> "Resource/Server" –> "DC" –> "Resource/Server" –> "Client"
The following steps present an outline of NTLM non-interactive authentication (network logon). The first step provides the user’s NTLM credentials and occurs only as part of the interactive authentication (logon) process.
- A user logs on interactively to a client and provides a domain name, a user name, and a password. The client then computes a cryptographic hash of the password and discards the actual password;
- The user at the client wants to access a resource and the client sends the user name to the server (the resource) in plaintext;
- The server generates a 16-byte random number, called a challenge or nonce, and sends it back to the client;
- The client encrypts this challenge with the cryptographic hash of the user’s password and returns the result as the response to the server;
In turn, the server wants to validate the credentials of the client and therefore sends the following three items to the DC in the AD domain from which the user on the client belongs to (following the path of secure channels between the server and all the DCs in between if applicable and the DC from the AD domain of the user):
- The user name;
- The challenge that was sent by the server to the client;
- The response that was sent back by the client to the server;
- The user name;
- The DC uses the user name to retrieve the cryptographic hash of the user’s password from the Security Account Manager database and then uses the cryptographic hash to encrypt the challenge that was sent by the server to the client;
- The DC compares the encrypted challenge it computed itself (in step 6) to the response computed by the client (in step 4). If both are identical, authentication is successful and reported back to the server, which in turn allows access to the resource in question based upon the SIDs in the access token.
Now look at step 4, step 6 and step 7. If the password has expired after the user logged on interactively, but before the user accessed the resource, the DC will not be able to compute the encrypted challenge because the password of the user has expired. The server will then present you with a window to provide valid credentials. However, any session that was already established before the password expired is maintained and still accessible until the session is ended. How the session is maintained may also influence whether or not access is still possible.
Because a user does not know which authentication will be used, or better yet, the user does not even care, it might be an annoying user experience if the user is able to access certain resources (using Kerberos authN) after the password has expired, but not others (using NTLM authN). One solution to this is to only allow Kerberos only authN and restrict any NTLM authN. You might think: "this is not possible!". Well, as of W7/W2K8R2 you can block/restrict the use of NTLM based authN. What’s the impact of this? That would be enormous! For more information about restricting NTLM authN see the following links:
The version of accessing a resource with the Kerberos authentication protocol, can be found here.
So, the moral of the story is: "change the password as soon as you are warned it is going to expire"!
UPDATE (2011-02-16): W2K3SP1 changes the behavior around using an old password to access network resources through NTLM after the password is changed. I had forgotten about this one. Tomek [MVP-Security] remembered me about this change in behavior in W2K3SP1. I have not tested it, but I do assume this behavior also exists in Windows 6 and higher. The article that mentions this is: Windows Server 2003 Service Pack 1 modifies NTLM network authentication behavior. THANKS TOMEK!
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########