.Net的目录服务引发了一个奇怪的例外

Question

I have a small C# solution used to check users credentials. It works fine for two of my teammates, but on my PC I get an exception.

The relevant code:

PrincipalContext context = new PrincipalContext(ContextType.Domain);
if (context.ValidateCredentials(System.Environment.UserDomainName + "\\" + usr, pwd))
     return true;
else
     return false;

And the exception is:

DirectoryOperationException, "The server cannot handle directory requests.".

I tried creating context with the explicit server name and the 636 port number, but this didn't help as well.

Any ideas?

Answer 1

I had this problem too using IIS Express and VS 2010. What fixed it for me was a comment on another thread.

Validate a username and password against Active Directory?

but i'll save you the click and search... :) Just add ContextOpations.Negotiate to you Validate Credentials call like below.

bool valid = context.ValidateCredentials(user, pass, ***ContextOptions.Negotiate***);

Answer 2

I had this issue: things were working on my dev machine but didn't work on the server. Turned out that IIS on the server was set up to run as LocalMachine. I changed it to NetworkService (the default) and things started working.

So basically check the user of the app pool if this is running on IIS.

Answer 3

I had to just create a new app pool and assign it .NET 2.0, then assign the new app pool to our web app, and it started working. We had .NET 3.5 SP2, so the hotfix wasn't ideal for us. Since the WWW service is usually Local System, I questioned that too. But since it was .NET and security related, I gave a shot at the app pool first and it worked.

Answer 4

Perhaps you need the hotfix?

• FIX: DirectoryOperationException exception

And you are an Admin or the id that your service is running under is an Admin on your PC right?

I take it you already looked into this:

• System.DirectoryServices.Protocols

"You may receive a less than helpful DirectoryOperationException(“The server cannot handle directory requests.”) what isn't quite so amusing about this is that it didn't even try to communicate with the server. The solution was to add the port number to the server. So instead of passing “Server” to open the LdapConnection, I passed “server:636”. By the way, LDAPS is port 636 – rather than the 389 port used by LDAP."

---

Good point, I wouldn't expect that Win7/.NET 3.5 would need that patch. How about the info provided in this question:

• Setting user's password via System.DirectoryServices.Protocols in AD 2008 R2