Authentication in IIS

Introduction

So this blog is mostly meant to clarify the thought process of which authentication would take precedence when we have multiple authentication mechanisms like Anonymous, Basic, Windows and so on in place. Few days back i was working with one of the customers in which he had Digest Authentication as well as Windows Authentication enabled and for some reason, the Windows Authentication would take precedence in IIS 6 and Digest Authentication in IIS 7.5. Why was this happening? Lets have a look.

In an ideal scenario, under any given circumstances, when a client makes the first request to the server, the request will be anonymous. If the server is configured for anonymous authentication, the server would process the request and send the required data back to the client. However, if the server is configured for any other authentication modes like Basic or Digest, the server will respond to the client with the set of authentication mechanisms it is configured under. Now, when the client receives this data from the server, it will pick up the most secure authentication mechanism from the list provided by the server in its response header and send it back to the server. You can assume this to be a simple handshake between the client and server in which both agree to work on a single authentication mechanism.

The authentication precedence is in the following order.

• Client Certificate Authentication
• Anonymous authentication
• Windows authentication
• Digest Authentication
• Basic Authentication

Now, in order to find out the best way which authentication mode would take precedence would be to revisit the IIS 6 Directory security Tab. The order in which authentication modes are presented from top to bottom indicates the precedence. For example,Anonymous authentication would take precedence over Windows, Digest, Basic and other authentication mechanisms. Lets say if you have Windows authentication and Basic Authentication enabled, then the client would always choose Windows authentication to connect with the server.

However, if the client certificate authentication is configured, then it will take precedence above all other authentication mechanisms since the SSL handshake takes place even before HTTP request would come in to picture. But for some reason, if we have client certificate authentication fails and anonymous is also configured, then the request would fall back to anonymous.

Image may be NSFW.
Clik here to view.

People usually have a misconception that if two authentication modes are configured and that if one fails, it would fall back to the other. For example, in my previous example I stated that if windows authentication and Basic Authentication are enabled, windows would take precedence. Now, for some reason if Windows authentication would fail, we believe that the client would make use of Basic Authentication to complete the request. Unfortunately, this is not what would happen. If we have configured two or more authentication mechanisms and if one fails, then there is no way of moving to the other.

A fall back would occur only in two scenarios.

• Scenario 1 : Under windows authentication when Kerberos would fail, NTLM would come into picture and rescue it.
• Scenario 2 : If client certificate authentication is enabled along with any other authentication mechanisms and if it fails, then the next authentication mode would be chosen based on the precedence that is normally followed which would be Anonymous, Windows, Digest, Basic.

The same concept works fine for IIS 7.5 as well however with a small twist to it. Recently, I was working with a customer in which he had Digest Authentication as well as Windows Authentication enabled and for some reason, Digest Authentication was taking more precedence than Windows. If we track back, we observed that windows authentication is supposed to take precedence over Digest but this was not what was happening in his case here. However, with the same configuration in place on an IIS 6 machine, Windows authentication was taking precedence over Digest which was what we expected to happen.

Let us now try and understand why Digest authentication was taking precedence over Windows when it should have been the other way round. The best way to deal with this is to capture Fiddler traces during the time of issue.

From the fiddler traces, what we are interested in looking at is the Authentication header. Once the client sends its first request to the server, the server in its response would send over the different authentication mechanisms it is configured under. Please note that when you have two or more authentications enabled, the order of precedence that would be presented in the "headers" section in Fiddler would be in reverse order.

Image may be NSFW.
Clik here to view.

Now, let us consider a similar trace when the request was made to an IIS 7.5 machine. If you observe in the headers section for the response under the www-authenticate header(reading upwards), for some reason the server is presenting Digest authentication with higher precedence than Windows authentication.

If you observe a similar trace for an IIS 6 machine, you will see in the headers section for the response under the www-authenticate header(reading upwards), that Windows authentication would be placed below Digest authentication and hence making sure that Windows authentication takes more precedence.

The reason being, when you open up the "Application host.config" file and view the "modules" tag for an IIS 7.5 machine, Digest authentication attribute is placed below Windows authentication. In the modules section, the precedence flow is from bottom to top and hence you observe that the server is projecting Digest authentication over Windows authentication.

   <add name="WindowsAuthenticationModule" lockItem="true" /> 
 <add name="DigestAuthenticationModule" lockItem="true" />    

To rectify this, all we have to do is to interchange the two attributes in the modules tag such that Windows authentication attribute is below Digest Authentication and that would resolve the problem.

<add name="DigestAuthenticationModule" lockItem="true" /> 
      <add name="WindowsAuthenticationModule" lockItem="true" /> 

However, after all this if you still have confusion over authentication precedence in IIS, Please follow the IIS 6 Directory security tab and that will give you the answer.

PS: All statements made here are with respect to IE browser. 

Hope this helps :)  

Image may be NSFW.
Clik here to view.