title: What is the scope of the tcp session when AuthPersistNonNTLM is used?
body: <p><strong>The Question:</strong></p>
  
  <p>How is the scope of the TCP session controlled when authPersistNonNTLM is enabled?</p>
  
  <p><strong>The Background:</strong></p>
  
  <p>I am doing performance profiling on a ASP.NET application hosted in IIS 7 that uses Kerberos for it's authentication, we were seeing that the response times when Windows Authentication was used increased significantly (some times as much as 1000%) as compared to just Anonymous authentication.</p>
  
  <p>After some searching I cam across <a href="http://blogs.msdn.com/b/benjaminperkins/archive/2011/10/31/kerberos-authpersistnonntlm-authentication-request-based-vs-session-based-authentication.aspx" rel="nofollow">this article</a> that suggested using the authPersistNonNTLM setting to reduce the number of round trips to the server.</p>
  
  <p>I've now run my tests again with this turned on and did indeed see substantial improvement.</p>
  
  <p>However I'm still unclear on the technical details of how this works and we have the following scenario that raises some questions about potential security holes.</p>
  
  <p><strong>The Scenario:</strong></p>
  
  <p>One of our applications is a WPF thick client and it connects to several ASP.NET services that we would be looking to apply this setting to. The machines on which the client is installed are shared between users (with separate logins ofcourse) that can have various different permissions sets within the ASP.NET services. So the concern would be that a User with higher privileges logs out for the day, a new user with lesser privileges logins in and retains the permissions of the previous user.</p>
  
  <p>I've done some initial smoke testing and it seams like this scenario is handled properly, but I would like to understand the technical details of what is happening to be sure.</p>