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

score 133 · Answer 1 · edited Feb 12 '18 at 05:54

133

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

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

edited Feb 12 '18 at 05:54

Graham

7,431
18
59
84

answered Apr 11 '12 at 06:55

Flavio

1,645
2
11
9

16

This fixed it for me as well. LDAP must be in caps. – Adam Rodger Sep 11 '12 at 14:59
1

great answer for me. especially if working with powershell, you are not used to case sensitive spelling – Falco Alexander May 16 '16 at 09:05
19

WAAAAAAAAT??! I After spending 2 hours on this LDAP solved my problem! – Stefan Vasiljevic Aug 19 '16 at 13:15
1

Weren't all MS/Windows related resources supposed to be case insensitive? Thanks. – Alexei - check Codidact Aug 16 '18 at 07:55
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. – Simon Thum May 17 '22 at 21:17

marc_s · Accepted Answer · 2009-11-12T16:40:32.923

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

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? — GodEater, Nov 12 '09 at 16:23
OK - can you step through the code (or write out trace messages) to find out where exactly that exception happens?? — marc_s, Nov 12 '09 at 16:34
The 0x80005000 is a pretty "boilerplate" error and can mean just about anything...... — marc_s, Nov 12 '09 at 16:35

score 25 · Answer 3 · answered Jul 01 '14 at 01:02

25

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:

enter image description here

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

answered Jul 01 '14 at 01:02

David d C e Freitas

7,481
4
58
67

2

For my specific problem (hitting the OP error but I was going for IIS, not LDAP), this solved it. Thank you – Malachi Sep 27 '17 at 21:40

score 20 · Answer 4 · answered Dec 20 '17 at 18:31

20

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

answered Dec 20 '17 at 18:31

Ernest

2,039
24
19

This fixed it for me! Thank you. – myroslav Aug 27 '18 at 16:51
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 :). – Ernest Aug 28 '18 at 18:08
5

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. – AirmanAJK Aug 02 '19 at 17:35
argh!!! this was my problem! this answer should be higher up, fixed the issue for me. – matao Nov 19 '19 at 01:05
Thanks, worked for me. I restarted iis after recycle. – Tulshi Das May 12 '22 at 06:35

score 15 · Answer 5 · edited Dec 21 '17 at 22:01

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);

score 9 · Answer 6 · answered Nov 23 '11 at 19:55

9

I had this error as well and for me it was an OU with a forward slash in the name: "File/Folder Access Groups".

This forum thread pointed me in the right direction. In the end, calling .Replace("/","\\/") on each path value before use solved the problem for me.

answered Nov 23 '11 at 19:55

Nick Sarabyn

1,632
2
21
29

1

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. – Panda Aug 18 '16 at 08:31
OMG Thank you @Nick – JMIII Sep 27 '21 at 16:58

score 3 · Answer 7 · answered Jul 14 '15 at 09:02

Just had that problem in a production system in the company where I live... A webpage that made a LDAP bind stopped working after an IP changed.

The solution... ... I installed Basic Authentication to perform the troubleshooting indicated here: https://support.microsoft.com/en-us/kb/329986

And after that, things just started to work. Even after I re-disabled Basic Authentication in the page I was testing, all other pages started working again with Windows Authentication.

Regards, Acácio

score 3 · Answer 8 · answered Mar 12 '11 at 17:29

3

Just FYI, I had the same error and was using the correct credentials but my LDAP url was wrong :(

I got the exact same error message and code

answered Mar 12 '11 at 17:29

sebagomez

9,501
7
51
89

score 2 · Answer 9 · answered Nov 19 '20 at 14:37

I encounter this error when I'm querying an entry of another domain of the forrest and this entry have some custom attribut of the other domain.

To solve this error, I only need to specify the server in the url LDAP :

Path with error = LDAP://CN=MyObj,DC=DOMAIN,DC=COM

Path without error : LDAP://domain.com:389/CN=MyObj,DC=Domain,DC=COM

score 1 · Answer 10 · answered Jun 23 '17 at 10:57

1

This Error can occur if the physical machine has run out of memory. In my case i was hosting a site on IIS trying to access the AD, but the server had run out of memory.

answered Jun 23 '17 at 10:57

lsp

744
6
19

score 1 · Answer 11 · answered Nov 18 '20 at 00:30

I had to change my code from this:

 DirectoryEntry entry = new DirectoryEntry(path, ldapUser, ldapPassword);
 DirectorySearcher searcher = new DirectorySearcher();
 searcher.SearchRoot = entry;
 searcher.SearchScope = SearchScope.Subtree;

To this:

DirectoryEntry entry = new DirectoryEntry(path, ldapUser, ldapPassword);
DirectorySearcher searcher = new DirectorySearcher();
searcher.SearchScope = SearchScope.OneLevel;
SearchResult searchResult = searcher.FindOne();

score 1 · Answer 12 · answered Dec 15 '22 at 13:46

In my case, the problem was that I was trying to reference a DirectoryEntry's property value, even though that DirectoryEntry did not have that property at all.

If you for example, have:

var myGroup = new DirectoryEntry("LDAP://CN=mygroup,OU=mydomain....", myUsername, myPassword);

var groupManager = myGroup.Properties["managedBy"].Value.ToString();

If myGroup has no managedBy attribute set in the AD, this will result in Unknown error (0x80005000)

score 0 · Answer 13 · answered Mar 02 '16 at 06:28

The same error occurs if in DirectoryEntry.Patch is nothing after the symbols "LDAP//:". It is necessary to check the directoryEntry.Path before directorySearcher.FindOne(). Unless explicitly specified domain, and do not need to "LDAP://".

private void GetUser(string userName, string domainName)
{
     DirectoryEntry dirEntry = new DirectoryEntry();

     if (domainName.Length > 0)
     {
          dirEntry.Path = "LDAP://" + domainName;
     }

     DirectorySearcher dirSearcher = new DirectorySearcher(dirEntry);
     dirSearcher.SearchScope = SearchScope.Subtree;
     dirSearcher.Filter = string.Format("(&(objectClass=user)(|(cn={0})(sn={0}*)(givenName={0})(sAMAccountName={0}*)))", userName);
     var searchResults = dirSearcher.FindAll();
     //var searchResults = dirSearcher.FindOne();

     if (searchResults.Count == 0)
     {
          MessageBox.Show("User not found");
     }
     else
     {
          foreach (SearchResult sr in searchResults)
          {
              var de = sr.GetDirectoryEntry();
              string user = de.Properties["SAMAccountName"][0].ToString();
              MessageBox.Show(user); 
          }        
     }
}

score 0 · Answer 14 · answered Jun 09 '17 at 17:13

0

Spent a day on my similar issue, but all these answers didn't help.

Turned out in my case, I didn't enable Windows Authentication in IIS setting...

answered Jun 09 '17 at 17:13

YSJ

382
2
14

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 */ } – Rolf Apr 24 '18 at 06:43

Error 0x80005000 and DirectoryServices

14 Answers14

Linked