This is caused by the fact that when a user is authenticated against a sharepoint server using NTLM or Kerberos, a "secondary token" is sent to the server that it uses to authenticate the user. This token cannot be used to authenticate the current user against another server (e.g. a domain controller).
This can be circumvented by reverting the impersonation to the application pool account used by IIS (if this account has access to Active Directory) with the following code (this is equal to running with impersonation set to false in web.config):
C#:
using System.Web.Hosting;
...
...
...
...
// Code here runs as the logged on user
using (HostingEnvironment.Impersonate()) {// This code runs as the application pool user
DirectorySearcher searcher ...}
// Code here runs as logged on user again
using (HostingEnvironment.Impersonate()) {// This code runs as the application pool user
DirectorySearcher searcher ...}
// Code here runs as logged on user again
VB:
// Code here runs as the logged on user
Using (System.Web.Hosting.HostingEnvironment.Impersonate())
Using (System.Web.Hosting.HostingEnvironment.Impersonate())
// This code runs as the application pool user
DirectorySearcher searcher ...
End Using
// Code here runs as logged on user again