(2012-11-10) Testing/Understanding The Authentication Protocol Your Web Site Is Using

Last Wednesday I was at a customer for a workshop/presentation/demo and talking about ADFS, federation, federated identities, authentication, SSO, claims,  Kerberos and NTLM. The day ended how to execute the next steps in troubleshooting both Kerberos and NTLM authentication because of the authentication issues this customer was experiencing.

-

In the past I already blogged about troubleshooting Kerberos/NTLM Authentication. Also see: (2012-01-26) Troubleshooting Authentication Problems – Kerberos Or NTLM

-

After arriving home and having some dinner I searched on the internet for “testing Kerberos authentication” and that’s when I found Michel Barneveld’s blog that contained a blog post about the Kerberos Authentication Tester.

-

This allows you to test the authentication protocol being used by a specific website. The main features are:

• It shows what authentication method is used in a web request: None, Basic, NTLM or Kerberos
• It shows the SPN used in case of Kerberos
• It shows the HTTP status
• It shows the HTTP Headers of the request
• It shows the version of NTLM used (v1 or v2)
• It has a detailed view with a complete breakdown of the Authorization header. (Yep, went through all the RFCs to dissect the Kerberos and NTLM packages)
• It shows your current Kerberos tickets and allows you to remove them (like klist.exe)

-

I tried this tool against my test/demo environment and below you will find some screen dumps.

-

On The Settings TAB you can specific the credentials that should be used when targeting the specified website.

Figure 1: Settings TAB – Credentials And Proxy

-

On the Test TAB, after specifying a URL and clicking on [Test], it will output the HTTP Headers. In this case I was targeting a Kerberos Based Web Site.

Figure 2a: Test TAB – Output HTTP Headers For Kerberos Authentication

-

Figure 2b: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

Figure 2c: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

Figure 2d: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

Figure 2e: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

Figure 2f: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

Figure 2g: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

In case of Kerberos Authentication, you can see the total list of Kerberos Tickets, including the one for the Kerberos Based Web Site.

Figure 3: Tickets TAB – List Of Kerberos Tickets

-

On the Test TAB, after specifying a URL and clicking on [Test], it will output the HTTP Headers. In this case I was targeting an NTLM Based Web Site.

Figure 4a: Test TAB – Output HTTP Headers For NTLM Authentication (Continued)

-

Figure 4b: Test TAB – Output HTTP Headers For NTLM Authentication (Continued)

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2012-01-26) Troubleshooting Authentication Problems – Kerberos Or NTLM

Over the years I have written a few blog posts about or related to Kerberos or NTLM authentication. These blog posts are summarized here for your convenience:

• (2006-12-28) NTLM And Kerberos Authentication Explained The Easy Way
• (2010-10-12) User Principal Names In AD (Part 1)
• (2010-10-12) User Principal Names In AD (Part 2)
• (2010-10-12) User Principal Names In AD (Part 3)
• (2011-02-13) Accessing A Resource With The Kerberos Authentication Protocol
• (2011-02-13 ) Accessing A Resource With The NTLM Authentication Protocol
• (2011-02-13) When Will The Password Expire For An AD User Account And What Happens Then?

-

However, in addition to what I have written, the guys at AskDS have written a bunch of excellent Kerberos related blog posts. These blog posts are summarized here for your convenience:

• Kerberos for the Busy Admin
• Troubleshooting Kerberos Authentication problems – Name resolution issues
• Kerberos Authentication problems – Service Principal Name (SPN) issues – Part 1
• Kerberos Authentication problems – Service Principal Name (SPN) issues – Part 2
• Kerberos Authentication problems – Service Principal Name (SPN) issues – Part 3
• Understanding Kerberos Double Hop
• Fun with the Kerberos Delegation Web Site

-

A guy from WebTopics also has written a very good blog post about Kerberos in IIS. This blog post is also here for your convenience:

• Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0/7.5

-

And the guys from IIS support in France have also written a great article about troubleshooting Kerberos

• Things to check when Kerberos authentication fails using IIS/IE

-

Read all these blog posts, and you are up to speed in no time when the need arises to troubleshoot authentication problems. Have fun!

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-02-13) When Will The Password Expire For An AD User Account And What Happens Then?

A few weeks ago I was discussing an issue with a colleague he experienced at his customer. The issue was about password expiration and I thought it was also worth to post the technical parts of the discussion. As you may know, Windows itself, will warn you during logon (Windows XP) or right after logon in the notification area (Windows Vista and Windows 7).

If you log on interactively while your password is already expired, the system will force you to change the password before allowing you to continue to logon.

However, what would happen and what is the impact if:

1. you logon interactively while your password is still valid (i.e. not expired), AND
   
2. you are warned by Windows your password will expire within one day (optional if configured!), AND
   
3. you ignore that and do not change the password (depends on [2]), AND
   
4. your password expires a few hours after logging on (e.g. 3 hours) and before logging off again.
   

The universal IT answer to that is: "it depends!". Seriously, it really depends on the authentication protocol being used when accessing a resource, while your password has expired previously.

One of the users at my colleague’s customer experienced the following, after the previous 4 steps:

• Drive mappings still worked;
  
• Outlook still worked;
  
• Access to the internet did not work, and the user was prompted to provide credentials again.
  

After some research, the first two (Microsoft systems) used Kerberos as the authentication protocol and the last one (non-Microsoft system) used NTLM as the authentication protocol. Detailed information about the Kerberos authentication protocol can be found here and here and here. Detailed information about the NTLM authentication protocol can be found here and here.

A very very very high-level overview of both authentication mechanisms can also be read here in this post I wrote once.

To make it more easy to understand, I will provide some high-level information (but with more depth than the previous post) when using either authentication protocol to access a resource. Windows will always try to use Kerberos first and if that is not possible it will fallback to NTLM.

The version of accessing a resource with the Kerberos authentication protocol, can be found here.

In short, when resources are accessed through the Kerberos authentication protocol…. If your password expires after you have logged on, you will be able to access resources through the Kerberos authentication protocol for as long as the TGT renewal period has not ended. As soon as the TGT renewal period has ended, you will be prompted to provide credentials, and depending on the resource (e.g. Exchange) you may get the possibility to change your password on the fly.

The version of accessing a resource with the NTLM authentication protocol, can be found here.

In short, when resources are accessed through the NTLM authentication protocol…. If your password expires after you have logged on, you will be NOT able to access resources through the NTLM authentication protocol. As soon as the password expires, you will be prompted to provide credentials, and depending on the resource (e.g. Exchange) you may get the possibility to change your password on the fly.

So, the moral of the story is: "change the password as soon as you are warned it is going to expire"!

Another solution would be to scan for expiring passwords and notify the user through e-mail to change his/her password and if needed in addition force the user to change the password at next logon earlier than the password expires. This can be accomplished quite easily with the correct tools, and if you are using FIM 2010, it is also quite easy to accomplish. Watch out for an upcoming blog post from me on how to do that using FIM 2010!

If you want to do this by using a custom made script (e.g. VBScript, PowerShell), then the complexity of logic in the script depends on whether or not you are using Password Settings Objects (PSO). For more information about PSOs, click here and here.

Below, I will explain the logic of what the script should do according to my opinion. A free unsupported tool that can do just the mailing part can be found here.

Before continuing, lets define the password lifecycle timeline as shown in the picture below.

['A'] When NOT using PSOs, just the password settings in the default domain GPO
(Also see a similar article about this on MSDN: How Long Until My Password Expires?)

• Retrieve a list of user accounts that match the following criteria:
  
  • User accounts, AND –> (objectCategory=person)(objectClass=user)
    
  • Enabled, AND –> (!(userAccountControl:1.2.840.113556.1.4.803:=2))
    
  • Password will expire, AND –> (!(userAccountControl:1.2.840.113556.1.4.803:=65536))
    
  • Mailbox/mail-enabled –> (mail=*)
    
• Read the maximum password age "maxPwdAge" from the domain NC. If set to 0 (zero) then stop processing as then passwords will not expire for any AD user account;
  
• Define a warn period in days which is the number of days before the password expiration date;
  
• For each AD user account in the list:
  
  • Retrieve the "pwdLastSet" attribute;
    
  • Calculate the password expiration date by adding the maximum password age to the password last set date;
    
  • Calculate the warn period starting date by extracting the warn period from the password expiration date;
    
  • Based upon the calculated information, perform the following action(s):
    
    • [1]
      
      • Send an e-mail if TODAY (or NOW) falls after the warn period starting date AND before the password expiration date
        
    • OR
      
    • [2]
      
      • Send an e-mail if TODAY (or NOW) falls after the warn period starting date AND before one day before the password expiration date
        AND
        
      • Configure the AD user account with ‘change password at next logon’ if TODAY (or NOW) falls within one day before the password expiration date
        
    • OR
      
    • [3]
      
      • Configure the AD user account with ‘change password at next logon’ if TODAY (or NOW) falls within one day before the password expiration date
        

['B'] When using PSOs incl. the password settings in the default domain GPO

• Retrieve a list of user accounts that match the following criteria:
  
  • User accounts, AND –> (objectCategory=person)(objectClass=user)
    
  • Enabled, AND –> (!(userAccountControl:1.2.840.113556.1.4.803:=2))
    
  • Password will expire, AND –> (!(userAccountControl:1.2.840.113556.1.4.803:=65536))
    
  • Mailbox/mail-enabled –> (mail=*)
    
• Define a warn period in days which is the number of days before the password expiration date;
  
• For each AD user account in the list:
  
  • Retrieve the value of the "pwdLastSet" attribute;
    
  • Retrieve the value of the "msDS-ResultantPSO" attribute (constructed attribute);
    
  • Logic around retrieved from "msDS-ResultantPSO" attribute:
    
    • If no value (<NOT SET>) exists in the attribute, read the maximum password age "maxPwdAge" from the domain NC. If set to 0 (zero) then stop processing as then passwords will not expire for this AD user account;
      
    • If a value (distinguished Name of PSO) exists in the attribute, read the maximum password age "msDS-MaximumPasswordAge" from the PSO object. If set to 0 (zero) then stop processing as then passwords will not expire for this AD user account;
      
  • Calculate the password expiration date by adding the maximum password age to the password last set date;
    
  • Calculate the warn period starting date by extracting the warn period from the password expiration date;
    
  • Based upon the calculated information, perform the following action(s):
    
    • [1]
      
      • Send an e-mail if TODAY (or NOW) falls after the warn period starting date AND before the password expiration date
        
    • OR
      
    • [2]
      
      • Send an e-mail if TODAY (or NOW) falls after the warn period starting date AND before one day before the password expiration date
        AND
        
      • Configure the AD user account with ‘change password at next logon’ if TODAY (or NOW) falls within one day before the password expiration date
        
    • OR
      
    • [3]
      
      • Configure the AD user account with ‘change password at next logon’ if TODAY (or NOW) falls within one day before the password expiration date
        

As you can see, script ['B'] is a lot more complex because of the usage of PSOs. It becomes more complex because you cannot query for a list of AD user accounts and retrieve the resultant PSO, but rather you need to query for a list of users and then for each user individually query for the resultant PSO. Either way, as soon as you know which resultant PSO is being used by that AD user account, you need to query the resultant PSO for the maximum password age. Because multiple accounts may use the same resultant PSO, that same PSO will be queried multiple times for the same information. You could enhance this by querying all PSOs and retrieve the maximum password age and "cache" it somewhere and the use the cache to retrieve the maximum password age to calculate the password expiration date.

Whatever script you use (['A'] or ['B']), you can schedule as task that executes the script at midnight. The configuration of the AD user account with ‘change password at next logon’ should only occur for those AD user accounts for which the password will expire in the next 23 hours. This way, as soon as the user logs on, he/she will be forced immediately to change it in the morning. This could lower the impact when a user is able to access resources through the Kerberos authN protocol, but not through the NTLM authN protocol, when the password expires after the user logs on and ignores the warning message which states the user should change the password because it will expire soon.

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-02-13) Accessing A Resource With The NTLM Authentication Protocol

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.

1. 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;
   
2. The user at the client wants to access a resource and the client sends the user name to the server (the resource) in plaintext;
   
3. The server generates a 16-byte random number, called a challenge or nonce, and sends it back to the client;
   
4. The client encrypts this challenge with the cryptographic hash of the user’s password and returns the result as the response to the server;
   
5. 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):
   
   1. The user name;
      
   2. The challenge that was sent by the server to the client;
      
   3. The response that was sent back by the client to the server;
      
6. 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;
   
7. 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:

Introducing the Restriction of NTLM Authentication

NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7

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!

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————