LDAP Active Directory Bind Stops Working

[Guest]

I appear to be having a problem similar to Neil as posted at
http://msdn.microsoft.com/newsgroup...-DC48AB0DA5C9&dglist=&ptlist=&exp=&sloc=en-us

I thought my problem was solved when I changed the bind statement to use a
specific username/password like:
DirectoryEntry entry = new DirectoryEntry(_path,"test\\testAuth","test");

And it did work without any reported problems for over 3 weeks. Then I
received the "Failed to Bind" error message and each of the 4 asp.net apps
using active directory binding code (all use separate but exact copies of the
LDAP code) failed with this error. A restart of the box fixed the problem
(restarting IIS did not). Does anyone have any ideas? I have been unable to
find detailed info about caching/reconnecting to AD/mulitple apps connecting
to AD (are connections cached with security contexts), etc? And help would
be greatly appreciated!

 

[Guest]

I meant 'Any help would be appreciated', not 'And..'. Sorry.

Also, if it helps, I'm on W2k Server with IIS 5 running .net 1.1. I have
not been able to recreate the problem either.

 

[Jared]

Marshall,
I'm probably not much help, considering I was trying to help Neil in the
link you provided. Have you looked through your event logs? Are there any
event that denote failed or slow connections? Did any Administrators change
any of the authentication schemes/updated group policy? Can you log in with
the specified account, fire up dsa.msc, do you have permissions to view the
objects you are trying to bind to? Can up download/run gpresults? Do any of
the settings look like they could conflict with access (secure channel,
etc.). Can you answer the same questions that I gave in Neil's post?
The more info you post the better your chances of an answer.
Jared

 

[Guest]

Thanks Jared- to answer some of your questions:
-event logs show identical log entries (in the security log) for successful
as well as failed page requests
-no AD changes were made
-the account specified in the bind statement does have access to the objects
(code ran on a different box successfully, and was working on the production
box until something happened)

I am currently working with someone at MS to see if they can give any more
insight. What we are looking at now is how/whether the impersonation context
affects the bind to AD (is a process/thread security context stored with the
AD bind operation; is anything cached that could cause an access denied by
less privelaged impersonation accounts). I'll be sure and update if
something comes up.