Error 0x80005000 and DirectoryServices

Question

I'm trying to run a simple LDAP query using directory services in .Net.

    DirectoryEntry directoryEntry = new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com");
    directoryEntry.AuthenticationType = AuthenticationTypes.Secure;

    DirectorySearcher directorySearcher = new DirectorySearcher(directoryEntry);

    directorySearcher.Filter = string.Format("(&(objectClass=user)(objectCategory=user) (sAMAccountName={0}))", username);

    var result = directorySearcher.FindOne();
    var resultDirectoryEntry = result.GetDirectoryEntry();

    return resultDirectoryEntry.Properties["msRTCSIP-PrimaryUserAddress"].Value.ToString();

And I'm getting the following exception:

System.Runtime.InteropServices.COMException (0x80005000): Unknown error (0x80005000)
  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.FindOne()

As a snippet in a Console app, this works. But when I run it as part of a WCF service (run under the same credentials), it throws the above exception.

Any suggestions?

Thanks

Solution 1

It's a permission problem.

When you run the console app, that app runs with your credentials, e.g. as "you".

The WCF service runs where? In IIS? Most likely, it runs under a separate account, which is not permissioned to query Active Directory.

You can either try to get the WCF impersonation thingie working, so that your own credentials get passed on, or you can specify a username/password on creating your DirectoryEntry:

DirectoryEntry directoryEntry = 
    new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com", 
                       userName, password);

---

OK, so it might not be the credentials after all (that's usually the case in over 80% of the cases I see).

What about changing your code a little bit?

DirectorySearcher directorySearcher = new DirectorySearcher(directoryEntry);
directorySearcher.Filter = string.Format("(&(objectClass=user)(objectCategory=user) (sAMAccountName={0}))", username);

directorySearcher.PropertiesToLoad.Add("msRTCSIP-PrimaryUserAddress");

var result = directorySearcher.FindOne();

if(result != null)
{
   if(result.Properties["msRTCSIP-PrimaryUserAddress"] != null)
   {
      var resultValue = result.Properties["msRTCSIP-PrimaryUserAddress"][0];
   }
}

My idea is: why not tell the DirectorySearcher right off the bat what attribute you're interested in? Then you don't need to do another extra step to get the full DirectoryEntry from the search result (should be faster), and since you told the directory searcher to find that property, it's certainly going to be loaded in the search result - so unless it's null (no value set), then you should be able to retrieve it easily.

Marc

Solution 2

I had the same again and again and nothing seemed to help.

Changing the path from ldap:// to LDAP:// did the trick.

Solution 3

In the context of Ektron, this issue is resolved by installing the "IIS6 Metabase compatibility" feature in Windows:

Check 'Windows features' or 'Role Services' for IIS6 Metabase compatibility, add if missing:

Ref: https://portal.ektron.com/KB/1088/

Solution 4

On IIS hosted sites, try recycling the app pool. It fixed my issue. Thanks

Solution 5

I had the same error - in my case it was extra slash in path argument that made the difference.

BAD:

DirectoryEntry directoryEntry = 
    new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com/", 
                       userName, password);

GOOD:

DirectoryEntry directoryEntry = 
    new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com", 
                       userName, password);

View more solutions

Comments

[GodEater]

I'm logged into the server where this process is running as the service account I have configured the WCF service to run as - so they are using the same credentials surely?

[marc_s]

OK - can you step through the code (or write out trace messages) to find out where exactly that exception happens??

[marc_s]

The 0x80005000 is a pretty "boilerplate" error and can mean just about anything......

[Adam Rodger]

This fixed it for me as well. LDAP must be in caps.

[Falco Alexander]

great answer for me. especially if working with powershell, you are not used to case sensitive spelling

[Panda]

Thank you so much, this was my problem ! After trying during 2 days fiddling about access rights, we found out an OU had been created with a slash in the name.

[Stefan Vasiljevic]

WAAAAAAAAT??! I After spending 2 hours on this LDAP solved my problem!

[Malachi]

For my specific problem (hitting the OP error but I was going for IIS, not LDAP), this solved it. Thank you

[Rolf]

If you need to revert to the application pool user, you can do this by "expersonating" for the AD call: using (WindowsIdentity.Impersonate(IntPtr.Zero)) { /* AD-Access */ }

[Alexei - check Codidact]

Weren't all MS/Windows related resources supposed to be case insensitive? Thanks.

[myroslav]

This fixed it for me! Thank you.

[Ernest]

Cool, I'm glad you made it. The thing is not always we have the chance to make code changes to fix an issue like this one, specially when we don't own or have the code, so trying things like this help a lot :).

[AirmanAJK]

If you're using an actual user account for your application pool identity and not a service account: In advanced settings for the application pool, set "Load User Profile" to True. If set to False, the registry keys needed for the COM operation will not be available if that user logs off the machine.

[matao]

argh!!! this was my problem! this answer should be higher up, fixed the issue for me.

[JMIII]

OMG Thank you @Nick

[Tulshi Das]

Thanks, worked for me. I restarted iis after recycle.

[Simon Thum]

That nailed it! I can't believe it... On top of that, when you use Url.GetComponents() in between, .net will helpfully lowercase your LDAP.