Question

In C# I am binding to a secure LDAP site with the following code

authServer =
    new DirectoryEntry("LDAP://whatever.com:636",
          authServerUsernameFromConfig,
          authServerPasswordFromConfig,
          AuthenticationTypes.Anonymous );

then searching for a user which is found OK.

then the following collection is examined looking for property name of “groupMembership”

DirectorySearcher directorySearch = new DirectorySearcher(authServer, filterKey);
...
SearchResult result = directorySearch.FindOne();
...
authUser = new DirectoryEntry(result.Path, userDN, password, AuthenticationTypes.None);
...
(read) authUser.Properties.PropertyNames

However none are found when using 636 secure port. Other properties are found. When binding to non secure PORT all properties are found both those with 636 bind and also those named groupMembership.

Can anyone explain why this might be or how to retrieve them.

In seems that with the LDP.exe utility can see these groupMembership properties with a secure port 636 bind.

Answer 1

• The directory information tree does not have properties. The directory information base has attributes grouped into entries. Attributes might be multi-valued, properties are always single-valued.
• LDAP clients do not “bind” to a connection. LDAP clients establish a connection to a secure port (using SSL) or to a non-secure port (which can then be “promoted” to a secure connection if desired by the client and permitted by the server). Once a connection has been established, that connection has no authorization state. The LDAP client may then use the BIND operation to request that the server verify credentials and change the authorization state of the connection. The authorization state of the connection is used by the server to determine whether the client using that connection has access rights to entries and attributes comprising those entries.
• Modern, professional-quality LDAP servers have the capability of denying access to certain sensitive attributes if the connection is not a secure connection. If the server the LDAP client is accessing does not have this capability, then there is no difference in accessing data over a secure vs. a non-secure connection. These legacy servers do not distinguish between secure and non-secure connection for determination of access rights and privileges – the authorization state of the connection is used to determine access rights)

Use a known good tool like ldapsearch to verify that an LDAP client can access data as required. If the known good LDAP client can access the data and a hand-coded LDAP client cannot, then check the following parameters of the search request:

• The base object, or base DN. This is the place at which the search begins. No entries superior to the base object are returned
• The scope of the search. BASE only returns the entry and request attributes, ONE returns the entries immediately subordinate to the base object, SUB returns the base object and all entries sub-ordinate to the base object, on any level.
• The filter. The filter is used to narrow the search and is composed of attributeType-attributeValue assertions and can be of a number of different forms
• The requested attributes the server is to return from the entries that match the other search parameters. Some APIs, not all, return all user attributes if none are requested.

see also

• LDAP: Programming Practices
• LDAP: Using ldapsearch