title: IIS application using application pool identity loses primary token?
body: <p>(This is a question about a vague problem.  I try to present all relevant data, in the hope that someone has helpful information; apologies for the long description.)</p>
  
  <p><strong>Our web app</strong></p>
  
  <p>We have a .NET 4 web application running in IIS 7.5 accessing Active Directory and a SQL Server database.</p>
  
  <p>This web application is running under a virtual 'app pool identity', by setting the Identity of the application's application pool to <a href="http://msdn.microsoft.com/en-us/library/bb386459.aspx" rel="nofollow noreferrer">ApplicationPoolIdentity</a>.  A concise description of virtual identities can be found in <a href="https://stackoverflow.com/a/3680803">a StackOverflow answer</a>, and the blog post to which it refers: an app pool identity is just an additional group which is added to the web application's worker processes which is running as 'network service'.  However, <a href="http://forums.iis.net/p/1171701/1957045.aspx#1957045" rel="nofollow noreferrer">one source</a> vaguely suggests that "Network Service and ApplicationPoolIdentity do have differences that IIS.net site documents do not publish."  So a virtual identity might be more than just an additional group.</p>
  
  <p>We chose to use ApplicationPoolIdentity, as opposed to NetworkService, because it became the default in IIS 7.5 (see, e.g., <a href="http://msdn.microsoft.com/en-us/library/bb386459.aspx#attributesAndElementsToggle" rel="nofollow noreferrer">here</a>), and per Microsoft's recommendation: "This identity allows administrators to specify permissions that pertain only to the identity under which the application pool is running, thereby increasing server security." (from <a href="http://msdn.microsoft.com/en-us/library/bb386459.aspx#attributesAndElementsToggle" rel="nofollow noreferrer">processModel Element for add for applicationPools [IIS 7 Settings Schema]</a>) "Application Pool Identities are a powerful new isolation feature" which "make running IIS applications even more secure and reliable. " (from <a href="http://learn.iis.net/page.aspx/624/application-pool-identities/" rel="nofollow noreferrer">IIS.net article "Application Pool Identities"</a>)</p>
  
  <p>The application uses Integrated Windows Authentication, but with <a href="http://msdn.microsoft.com/en-us/library/72wdk8cc.aspx" rel="nofollow noreferrer"><code>&lt;identity impersonate="false"/&gt;</code></a>, so that not the end user's identity but the virtual app pool identity is used to run our code.</p>
  
  <p>This application queries Active Directory using the <a href="http://msdn.microsoft.com/en-us/library/system.directoryservices.aspx" rel="nofollow noreferrer">System.DirectoryServices</a> classes, i.e., the ADSI API.  In most places this is done without specifying an additional username/password or other credentials.</p>
  
  <p>This application also connects to a SQL Server database using <code>Integrated Security=true</code> in the connection string.  If the database is local, then we see that <code>IIS APPPOOL\OurAppPoolName</code> is used to connect to the database; if the database is remote, then the machine account <code>OURDOMAIN\ourwebserver$</code> is used.</p>
  
  <p><strong>Our problems</strong></p>
  
  <p>We regularly have issues where a working installation starts to fail in one of the following ways.</p>
  
  <ul>
  <li><p>When the database is on a remote system, then the database connection starts to fail: "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors."  The previous error is "Error: 18456, Severity: 14, State: 11."  So it seems that now <code>OURDOMAIN\ourwebserver$</code> is not used anymore, but instead anonymous access is attempted.  (We have anecdotal evidence that this problem occurred when UAC was switched off, and that it went away after switching on UAC.  But note that changing UAC requires a reboot...)  A similar problem is reported in <a href="http://forums.iis.net/t/1181039.aspx" rel="nofollow noreferrer">IIS.net thread "use ApplicationPoolIdentity to connect to SQL"</a>, specifically in <a href="http://forums.iis.net/p/1181039/2010748.aspx#2010748" rel="nofollow noreferrer">one reply</a>.</p></li>
  <li><p>Active Directory operations through ADSI (System.DirectoryServices) start to fail with error 0x8000500C ("Unknown Error"), 0x80072020 ("An operations error occurred."), or 0x200B ("The specified directory service attribute or value does not exist").</p></li>
  <li><p>Signing in to the application from Internet Explorer starts to fail, with HTTP 401 errors.  But if in IIS we then put NTLM before Negotiate then it works again.  (Note that access to AD is needed for Kerberos but not for NTLM.)  A similar problem is reported in <a href="http://forums.iis.net/t/1171701.aspx" rel="nofollow noreferrer">IIS.net thread "Window Authentication Failing with AppPool Identity"</a>.</p></li>
  </ul>
  
  <p><strong>Our hypothesis and workaround</strong></p>
  
  <p>At least the AD and sign-in problems always seem to go away when switching the application pool from ApplicationPoolIdentity to NetworkService.  (We found <a href="http://forums.iis.net/p/1181039/2010748.aspx#2010748" rel="nofollow noreferrer">one report</a> confirming this.)</p>
  
  <p>Page <a href="http://msdn.microsoft.com/en-us/library/ms180891.aspx" rel="nofollow noreferrer">"Troubleshooting Authentication Problems on ASP Pages"</a> has some suggestions related to primary vs. secondary tokens, and what I find encouraging is that it links the first two of our errors: it mentions <code>NT AUTHORITY\ANONYMOUS LOGON</code> access, and AD errors 0x8000500C and "The specified directory service attribute or value does not exist".</p>
  
  <p>(The same page also mentions ADSI schema cache problems, but everything we can find on that topic is old.  For now we consider this to be unrelated.)</p>
  
  <p>Based on the above, our current working <em>hypothesis</em> is that, only when running under a virtual app pool identity, <em>our web application (IIS? worker process?) suddenly loses its primary token</em>, so that IIS only has a secondary token, so that all access to Active Directory and SQL Server is done anonymously, leading to all of the above errors.</p>
  
  <p>For now we intend to switch from ApplicationPoolIdentity to NetworkService.  Hopefully this makes all of the above problems go away.  But we are not sure; and we would like to switch back if possible.</p>
  
  <p><strong>Our question</strong></p>
  
  <p>Is the above hypothesis correct, and if so, is this a bug in IIS/Windows/.NET?  Under which circumstances does this primary token loss occur?</p>