Periodic Active Directory Bind Failure

Discussion:

(too old to reply)

Brett

2006-08-03 14:41:30 UTC

Hello all,

A deployed web application seems to have periodic bind failures when
connecting to our client's Active Directory server. Most of the time
the Active Directory app works fine then suddenly a bind failure will
occur and will repeatedly occur (for the given user) for a length of
time then start working fine again.

The web application is using NTLM authentication (but is binding
anonymously as it's only reading) The client has approximately 150
users on their network and we've been assured that the active directory
server isn't under any stress.

The code to connect and pull back the data is very straightforward (and
typically works fine in our development environment) but for reference
here it is:

-----------------------

DirectoryEntry entry = new
DirectoryEntry(ConfigurationSettings.AppSettings["ADConnectionString"]);

DirectorySearcher Dsearch = new DirectorySearcher(entry);
Dsearch.Filter = "(&(objectClass=user)(l=*)"+strFilter+")";
entry.Close();

dSearch.PropertiesToLoad.Add("cn");
dSearch.PropertiesToLoad.Add("givenName");
dSearch.PropertiesToLoad.Add("sn");

foreach (SearchResult sResultSet in dSearch.FindAll())
// then goes on to display the details.

-----------------------

Any ideas?

Many thanks in advance,

Brett

Joe Kaplan (MVP - ADSI)

2006-08-03 15:45:53 UTC

Permalink

So, what's the security context the code is running under
(System.Security.Principal.WindowsIdentity.GetCurrent().Name)? If you are
impersonating, then it would be the user authenticated in IIS. If you
aren't, then it would be the process account, although you could also have
ASP.NET configured to impersonate a specific account (so many options :)).

Also, what type of exception is thrown? Do you get "server not operational"
or some other weird thing like an operations error or a "local error"?

One thing we recommend in our book is to use the "using" block in C# on all
of your DirectoryEntry, DirectorySearcher and SearchResultCollection objects
in order to ensure that you are aggressively releasing your underlying COM
objects. Depending on the version of .NET you are running under, there may
be some bugs in SDS related to their cleanup code that could be causing
problems.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Post by Brett
Hello all,
A deployed web application seems to have periodic bind failures when
connecting to our client's Active Directory server. Most of the time
the Active Directory app works fine then suddenly a bind failure will
occur and will repeatedly occur (for the given user) for a length of
time then start working fine again.
The web application is using NTLM authentication (but is binding
anonymously as it's only reading) The client has approximately 150
users on their network and we've been assured that the active directory
server isn't under any stress.
The code to connect and pull back the data is very straightforward (and
typically works fine in our development environment) but for reference
-----------------------
DirectoryEntry entry = new
DirectoryEntry(ConfigurationSettings.AppSettings["ADConnectionString"]);
DirectorySearcher Dsearch = new DirectorySearcher(entry);
Dsearch.Filter = "(&(objectClass=user)(l=*)"+strFilter+")";
entry.Close();
dSearch.PropertiesToLoad.Add("cn");
dSearch.PropertiesToLoad.Add("givenName");
dSearch.PropertiesToLoad.Add("sn");
foreach (SearchResult sResultSet in dSearch.FindAll())
// then goes on to display the details.
-----------------------
Any ideas?
Many thanks in advance,
Brett

Brett

2006-08-04 10:28:37 UTC

Permalink

Hi Joe,

Thanks for your response. We are using Impersonation with IIS using
Integrated Windows Authentication. Connection to the AD is done
anonymously.

The error message received is:

Unknown error (0x80005000)

Void Bind(Boolean)

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at
System.DirectoryServices.DirectoryEntry.Bind() at
System.DirectoryServices.DirectoryEntry.get_AdsObject() at
System.DirectoryServices.DirectorySearcher.FindAll(Boolean
findMoreThanOne) at
System.DirectoryServices.DirectorySearcher.FindAll() at
StaffDirectory.ajaxdirectory.fnDisplayDirectoryTableFiltered(String
strFilter)

We're using Visual Studio 2003.

I can't understand why the problem's only occuring occasionally. I have
read that this can happen if the Active Directory's handling a lot of
requests simultaneously however the IT department within my client's
premises ensure us that this isn't happening and they can connect fine
with third party apps.

Many thanks,

Brett

Joe Kaplan (MVP - ADSI)

2006-08-04 13:34:58 UTC

Permalink

Ah, the dreaded "unknown error". Err.exe actually decodes that into "an
invalid directory pathname was passed", so it might be good to log the
ADsPath that was used when this happened to see if something is weird there.
I have no idea why you get "unknown error" from .NET.

I'm a little confused by why you are using impersonation here. It looks
like you are trying to set up a standard delegation scenario, but delegation
may not be configured, resulting in an anonymous bind to the server.
Anonymous binds are generally a bad idea as there are many attributes you
can't read as anonymous. The other thing is that Windows Server 2003 AD
doesn't allow anonymous binds by default, so if you upgrade (and don't turn
that setting off), your app will start generating operations errors.

It would seem like a better design to NOT impersonate and use a fixed
service account, such as the process account perhaps. This also gives you a
cleaner design to properly take advantage of ADSI connection caching, which
can improve performance.

That doesn't really solve why you have an intermittent failure though.
Besides the path name, it would be a good idea to try to get a network
capture to see if anything looks different on the network when this happens.
It would also be good to have logon event auditing enabled on both machines
so you can get details of how the user authenticated (NTLM vs. Kerberos) on
the web app side and the DC side.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Post by Brett
Hi Joe,
Thanks for your response. We are using Impersonation with IIS using
Integrated Windows Authentication. Connection to the AD is done
anonymously.
Unknown error (0x80005000)
Void Bind(Boolean)
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at
System.DirectoryServices.DirectoryEntry.Bind() at
System.DirectoryServices.DirectoryEntry.get_AdsObject() at
System.DirectoryServices.DirectorySearcher.FindAll(Boolean
findMoreThanOne) at
System.DirectoryServices.DirectorySearcher.FindAll() at
StaffDirectory.ajaxdirectory.fnDisplayDirectoryTableFiltered(String
strFilter)
We're using Visual Studio 2003.
I can't understand why the problem's only occuring occasionally. I have
read that this can happen if the Active Directory's handling a lot of
requests simultaneously however the IT department within my client's
premises ensure us that this isn't happening and they can connect fine
with third party apps.
Many thanks,
Brett

Brett

2006-08-04 14:12:15 UTC

Permalink

Hi Joe,

Thanks again for your response.

The application allows staff to manage holidays, display contact
details and allow completion of company forms etc. therefore
Impersonate is on so that the application works seamlessly with their
login (i.e. they don't have to re-login each time they want to view
their holidays / colleagues' contact details etc.)

I get the feeling the connection isn't closing properly then when it
tries to reconnect fails but the first connection remains open until
MaxConnIdleTime times out, which at default is 900 seconds. This goes
some way as to explain why, after a period of time, the application
suddenly starts working fine again for the user.

Some logging is being done now (I believe) so I will let you know the
result.

Many thanks,

Brett

Post by Joe Kaplan (MVP - ADSI)
Ah, the dreaded "unknown error". Err.exe actually decodes that into "an
invalid directory pathname was passed", so it might be good to log the
ADsPath that was used when this happened to see if something is weird there.
I have no idea why you get "unknown error" from .NET.
I'm a little confused by why you are using impersonation here. It looks
like you are trying to set up a standard delegation scenario, but delegation
may not be configured, resulting in an anonymous bind to the server.
Anonymous binds are generally a bad idea as there are many attributes you
can't read as anonymous. The other thing is that Windows Server 2003 AD
doesn't allow anonymous binds by default, so if you upgrade (and don't turn
that setting off), your app will start generating operations errors.
It would seem like a better design to NOT impersonate and use a fixed
service account, such as the process account perhaps. This also gives you a
cleaner design to properly take advantage of ADSI connection caching, which
can improve performance.
That doesn't really solve why you have an intermittent failure though.
Besides the path name, it would be a good idea to try to get a network
capture to see if anything looks different on the network when this happens.
It would also be good to have logon event auditing enabled on both machines
so you can get details of how the user authenticated (NTLM vs. Kerberos) on
the web app side and the DC side.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Joe Kaplan (MVP - ADSI)

2006-08-04 14:53:53 UTC

Permalink

You don't need impersonation to allow integrated windows auth SSO.
Impersonation just makes the thread executing the request run in the
security context of the user instead of the server process. It is most
useful when you need to access local resources such as the file system on
behalf of the user or you need to access remote resources in a delegation
scenario.

The actual IWA stuff works fine without it though and Context.User will
still point to the authenticated user. Essentially, impersonation makes
Context.User.Identity the same as WindowsIdentity.GetCurrent().

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Post by Brett
Hi Joe,
Thanks again for your response.
The application allows staff to manage holidays, display contact
details and allow completion of company forms etc. therefore
Impersonate is on so that the application works seamlessly with their
login (i.e. they don't have to re-login each time they want to view
their holidays / colleagues' contact details etc.)
I get the feeling the connection isn't closing properly then when it
tries to reconnect fails but the first connection remains open until
MaxConnIdleTime times out, which at default is 900 seconds. This goes
some way as to explain why, after a period of time, the application
suddenly starts working fine again for the user.
Some logging is being done now (I believe) so I will let you know the
result.
Many thanks,
Brett

CEN05

2006-10-20 19:48:01 UTC

Permalink

Please advice on how the problem was solved. We are having similar issues.
The application bind to AD with a given username and password that was
supplied by the login page. We made sure all com object are disposed.

directoryEntry = new DirectoryEntry (this._LDAPPath, this._domain + @"\"
+username, password);
// Bind to the native AdsObject to force authentication.
string nativeGUID = directoryEntry.NativeGuid.ToString();

Iin most case the above code works but somtimes it throw the following
errors:

Here is a summay of errors:

System.Runtime.InteropServices.COMException (0x800705B4): This operation
returned because the timeout period expired at
System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at
System.DirectoryServices.DirectoryEntry.Bind() at
System.DirectoryServices.DirectoryEntry.RefreshCache() at
System.DirectoryServices.DirectoryEntry.FillCache(String propertyName) at
System.DirectoryServices.DirectoryEntry.get_NativeGuid() at
Centura.MVW.BLL.ADHelper.AuthenticateUser(String username, String password,
DirectoryEntry& directoryEntry)

System.Runtime.InteropServices.COMException (0x8007203B): A local error has
occurred at System.DirectoryServices.DirectoryEntry.Bind(Boolean
throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at
System.DirectoryServices.DirectoryEntry.RefreshCache() at
System.DirectoryServices.DirectoryEntry.FillCache(String propertyName) at
System.DirectoryServices.DirectoryEntry.get_NativeGuid() at
Centura.MVW.BLL.ADHelper.AuthenticateUser(String username, String password,
DirectoryEntry& directoryEntry)

System.Runtime.InteropServices.COMException (0x80005000): Unknown error
(0x80005000) at System.DirectoryServices.DirectoryEntry.Bind(Boolean
throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at
System.DirectoryServices.DirectoryEntry.RefreshCache() at
System.DirectoryServices.DirectoryEntry.FillCache(String propertyName) at
System.DirectoryServices.DirectoryEntry.get_NativeGuid() at
Centura.MVW.BLL.ADHelper.AuthenticateUser(String username, String password,
DirectoryEntry& directoryEntry)

Any ideas would be appreciated.

Thank you
--
dev 2005

Post by Joe Kaplan (MVP - ADSI)
You don't need impersonation to allow integrated windows auth SSO.
Impersonation just makes the thread executing the request run in the
security context of the user instead of the server process. It is most
useful when you need to access local resources such as the file system on
behalf of the user or you need to access remote resources in a delegation
scenario.
The actual IWA stuff works fine without it though and Context.User will
still point to the authenticated user. Essentially, impersonation makes
Context.User.Identity the same as WindowsIdentity.GetCurrent().
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--