In this article, we will discuss how the AuthPersistNonNTLM authentication attribute affects Kerberos authentication to become a session or request based authentication protocol. Thus, we will be addressing below questions:
What is the purpose AuthPersistNonNTLM attribute?
AuthPersistNonNTLM attribute has a significant role on controlling Kerberos authentication behaviour. When this attribute is set to False, it converts the authentication from Session based to Request based which means that your client needs to send the authentication ticket with every single request to your IIS server even after it gets authenticated and authorized for the first request. On the other hand, Session based Kerberos authentication, gives the privilege to your client to send the authentication ticket only with the first request after getting authenticated and provided by the ticket.
Having a look on below Request-Based Kerberos Authentication graph, you can see that in step 5, where the client makes the second HTTP request (request2.aspx), it will still needs to send the Kerberos ticket to the server in order to get the desired content, and this would apply on request3, request4 .. and so on.
On the other hand, as you may notice within below Session-Based Kerberos Authentication, Request2.aspx, does not contain the Kerberos ticket anymore and no further authentication is required as long as the client is using the same TCP connection on which the HTTP requests are sent and the responses are received (the reuse of a TCP connection for multiple http requests is also called http keep alive).
Why is this distinction important?
Request-based authentication may cause a heavy load on traffic between your client and IIS server (where your application lives). This is because the Kerberos tickets tend to be rather large, several kile-bytes in size, whereas a simple GET request is only several hundred bytes in size – thus we increase the size of all outgoing requests by a large factor in request based Kerberos Authentication. On the server side, we have to perform the decryption of the ticket and the authentication phase again and again for each request, which can again cause a small performance hit.
How to change AuthPersistNonNTLM setting to True, to make Windows Authentication Session-Based?
Initially, we need to Enable Windows Authentication module on Server or Site level, whatever you decide. This can be done by following below steps:
Note: Applying below steps on server level, means that you have decided to involve ALL application hosted on this IIS server.
Now that we have Windows authentication enabled, there are 2 ways to manage AuthPersistNonNTLM attribute:
First one and the recommended one, is to use Configuration Editor on Application or Server level:
Note: You will notice that, AuthPersistNonNTLM is set to false by default on Windows 2008 SP2 and Windows 2008 R2 servers. In other words,
Kerberos authentication is a request based by default. Starting from Windows 2012 R2 servers onwards, the default value is true.
The second way to manage AuthPersistNonNTLM attribute, is to go directly to your web or ApplicationHost config files as shown below:
<system.webServer> <security> <authentication> <windowsAuthentication enabled="true" authPersistSingleRequest="false" authPersistNonNTLM="true"> <providers> <clear /> <add value="NTLM" /> <add value="Negotiate" /> </providers> </windowsAuthentication> <basicAuthentication enabled="true" /> <anonymousAuthentication enabled="false" /> </authentication> </security> </system.webServer>
Now that we have addressed first two questions, we aimed to answer within this article, It is time to have a real-life example on how to test if the Kerberos authentication is session or request based?
For similar cases scenarios, when we need to check or troubleshoot the http network traffic between client and server, we use an excellent tool called NetMon short for Network Monitor, you can install it from http://linqto.me/Netmon , and to have more insight on how to use it, you may follow instructions within this article.
Kerberos Authentication sample
Looking at below screenshot taken from a Netmon trace for a regular Kerberos authentication traffic, which started with Client requesting /whoami.aspx page, and server responded with 401, Unauthorized (this is normal, since the browser starts by making an anonymous request to the server at first):
In the response, the server also provides the supported authentication methods via the WWWAuthenticate header, which in this case indicate that both Negotiate and NTLM are supported. In light of this, the client attempts another request providing the Authorization token (the Kerberos ticket):
Note that on the case of Kerberos, the tickets will always start with a YII prefix.
The server processes the request, decrypts the ticket and validates it. If the authentication is successful, it responds with a 200 status code, like the below. It also includes a validation token so that the client can also validate the identity of the server.
As of this point, we were only pointing to a regular Client-Server negotiation process which typically applies for both Request and Session based Kerberos authentication.
How should traffic show for Request-based Kerberos authentication?
As you may notice, event 2nd and 3rd requests were still in a need to provide Kerberos tickets and the Authentication from server side was still needed for every request although we are using the same TCP connection between the client and the server.
How about Kerberos Session-based traffic?
In this screenshot of a Network trace captured for same exact above requests but this time for Session-based Kerberos authentication setup, where you can easily notice that Kerberos ticket was not being sent anymore:
Notice that the response from the server, on the first request that contains the authentication ticket also contains an Http-Header called Persistent-Auth and which has its value set to true. This header indicates to the client that the server is willing and able to use session-based Kerberos authentication on this TCP connection and there is no need to resend the Kerberos ticket with subsequent requests:
written by: Muna AlHasan
reviewed by: Paul Cociuba
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.