1

I am trying to read an attribute from an LDAP (not AD) entry using C# and the .NET library 'System.DirectoryServices'.

My LDAP entry is the following:

dn: uid=foo,ou=People,dc=companyname,dc=local
objectClass: posixAccount
objectClass: top
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
gidNumber: 0
givenName: Foo
sn: Bar
displayName: Foo Bar
uid: foo
homeDirectory: /
cn: foo bar
uidNumber: 9846
userPassword: {SHA}Ys23Ag/5IOWqZCw9QGaVDdHwH00=
mail: foo@dodo.net

The Linux LDAP server I am using is "389", also known as "Fedora Directory Server". My C# code looks like this:

string value = null;
DirectoryEntry ouEntry = null;
string path = "LDAP://192.168.150.192/ou=People, dc=companyname, dc=local";
string adminUserName = "cn=Directory Manager";
string adminPassword = "supersecureadminpassword";
ouEntry = new DirectoryEntry(path, adminUserName, adminPassword, AuthenticationTypes.None);
DirectorySearcher searcher = new DirectorySearcher(ouEntry, "uid=foo");
SearchResult result = searcher.FindOne();
DirectoryEntry userEntry = result.GetDirectoryEntry();
var props = userEntry.Properties.PropertyNames;
if(userEntry.Properties.Contains("givenName"))
    value = userEntry.Properties["givenName"].Value.ToString();

The code works perfectly fine. However, if I replace "givenName" by "displayName" the code fails on the line if(userEntry.Properties.Contains("displayName")) with a System.Runtime.InteropServices.COMException: Unknown error (0x8000500c). And that happens, even though the attribute "displayName" shows up when inspecting the property list props.

I have read this post, because it seems to be a similar problem. However, I don't know how to fix the problem, because all I have is a static IP address and not a fully qualified name for my LDAP server.

Has anybody any idea what the problem in my code is and if it is related to the mentioned post? How would I solve the problem?

Thanks a lot in advance.

Update 1: I've also tried to replace the IP address by the LDAP server's Linux host name (the output of the shell command hostname), but that didn't work either. Also, "displayName" is not a custom attribute, as far as I know. Therefore, my problem probably does not match the problem in the linked post. I am really desperate and don't know what to do. Any help would be greatly appreciated.

Community
  • 1
  • 1
Joerg
  • 790
  • 2
  • 10
  • 23

1 Answers1

0

Few things:

  1. adminUserName is a login name, e.g. "jsmith" not "cn=..."
  2. if your box is in the same domain then usually you don't need to specify user/password
  3. make sure that uid (uid=foo) is the right property

  4. try to use PropertiesToLoad

    DirectorySearcher searcher = new DirectorySearcher(ouEntry, ...);
searcher.PropertiesToLoad.Add("displayName");

Although you said it works for "givenName", you might try to test a third party tool to check if there is no problem with your connection. E.g. you might try LDAP Browser, try to provide same connection data and perform a search for your filter string and see if it returns all required data.

user2316116
  • 6,726
  • 1
  • 21
  • 35
  • Thanks for the answer. Referring to your suggestions: 1.) Are you sure? Shouldn't it be a LDAP distinguished name? How else would you distinguish between user of different OUs? Anyway, even if I replace `"cn=Directory Manager"` by `"Directory Manager"`, I still get the same error at the same line. 2.) Ok, but it should work regardless, right? 3.) It is the right property. I am also using [LDAP Admin](http://www.ldapadmin.org) as an LDAP browser and checked all the attributes. 4.) I had tried that before and it doesn't make a difference. Do you have any other ideas? Thanks for your help. – Joerg Jul 28 '14 at 12:59
  • Sorry, I see you said, it's an LDAP not AD. In this case you're right it might be CN=... however it is strange that it does not change its output when you changed "Directory Manager" without CN= - so it looks like this is the issue. Try to specify "abc" instead of real password - I believe you'll get the same result. Did you try other than AuthenticationType.None? – user2316116 Jul 28 '14 at 13:10