Why does authenticating against LDAP with DirectoryEntry intermittently throw COMException (0x8007203A): "The server is not operational"?

If anybody has a similar story, please post details below!

I'm building an ASP.NET website which needs to support authentication against LDAP.

On windows, LDAP auth can be performed via Active Directory (I'm no expert, but AD seems to simply be a particular flavor of ldap). I don't control the AD and/or LDAP servers.

I've tried various methods of authentication, but I've settled on using a single DirectoryEntry per authentication attempt:

using (DirectoryEntry de = new DirectoryEntry(ldapPath, ldapUsername, password, AuthenticationTypes.ServerBind)) {
    try {
        // Bind to the native AdsObject to force authentication.
        object obj = de.NativeObject;//not IDisposable
    } catch(...

Retrieving the NativeObject causes a COMException if anything whatsoever goes wrong, for instance if the authentication failed, the exception is something like "Logon failure: unknown user name or bad password", and if the ldap server is unreachable or times out, something like "The server is not operational."

This works, basically, but after variable number of days, always starting first thing in the morning, we get "The server is not operational." until IIS is restarted. This is obviously not a great long-term solution, but as far as I can tell the fault lies with the Com Object underlying DirectoryEntry - not something easy to fix.

This problem isn't new or unknown. Some people have gone through microsoft's support with mixed results; basically the answers seem to come down to "take your ldap path and create a few equivalent alternatives and maybe one of those will work". Each time you try, or course, you won't know for a few days whether it actually worked, and until a real solution is found, we're back to "reboot the windows servers every night".

As a start, I've tried ldap paths in the format

* "LDAP://server.uri:636"
* "LDAP://insecure.server.uri:389"
* "LDAP://server.uri:636/cn=username,ou=staff,o=myOrganisation,c=org"

Always with a username with the following pattern:

* "cn=username,ou=staff,o=myOrganisation,c=org"

All of these methods work initially, but fail after a variable number of days (and start working after an IIS reset). The server is running IIS6 on win 2k3.

If anyone else has these problems, please post below, and perhaps eventually we'll find a pattern to work with or have sufficient number of examples to convince microsoft to fix this.

Although I can't precisely pinpoint the cause of this trouble, it seems to have to have stopped after migrating to a non-clustered server.

There are other odd facts about this bug:

• Restarting the asp.net host process isn't sufficient to fix the trouble. This is odd; you'd expect the OS to forcibly release resources on process death
• Restarting the IIS service doesn't release the resources (the UDP ports). netstat reveals the ports seem free, but all ports opened are actually opened by process #4 - the System process.
• Killing IIS (for instance via the IIS manager) does release the UDP ports, and then authentication works again.

All in all, this looks very much like a driver or kernel issue in win2k3 with clustering enabled, and not a .NET related problem.

So, if anyone else stumbles over a similar problem, check to see if clustering is enabled - it may save you weeks of headaches.