LDAP queries return attributes unless the attribute is requested

When performing LDAP searches for users, all attributes are visible.

When performing LDAP searches for specific attributes of those that appeared in a request for all attributes, some of those are no longer available.

When attributes are requested and do not show up versus a request for all attributes, and having the attribute become visible, it is typically due to a conflict between an actual attribute and a mapped attribute. This is seen where :

• The eDirectory schema has been extended to include an attribute (for example, "dialupAccess")
• The eDirectory LDAP server's "LDAP Group - SERVERNAME" object has an attribute mapping for the same LDAP attribute (for example, NDS Attribute of "RADIUS:Enable Dial Access" is mapped to"dialupAccess")

The process of why this occurs is described in the additional notes section of this document. The solution is to remove the offending attribute mapping :

1. Open the "LDAP Group" object for the LDAP server.
2. Click on the attribute mapping tab.
3. Click the "LDAP Attributes" header. This will sort the list by LDAP attribute.
4. Locate the attribute in question in the list (for the examples provided, this is "dialupAccess").
5. Remove the attribute from the mapping by clicking delete.
6. Apply the changes.
7. Unload NLDAP on the LDAP server.
8. Reload NLDAP.

The services that depend on the LDAP information may need to be refreshed to complete the process, especially if there is any chance of caching.

Before delving into the process, it needs to be discussed that there are multiple LDAP queries. For the scope of this document, there are two. First, performing an LDAP search and requesting all attributes. Second, performing an LDAP search and requesting specific attributes.

Using a Linux workstation, and performing an LDAP search, if therequest is for all attributes:

ldapsearch -h 127.0.0.1 -D cn=admin,o=novell  -W -b o=novell -s sub -x -Z '(cn=joe)'

This resulted in the LDIF output :

# extended LDIF

#

# LDAPv3

# base  with scope subtree

# filter: (cn=joe)

# requesting: ALL

#

# joe, novell

dn: cn=joe,o=novell

dialupAccess: TRUE

uid: joe

givenName: joe

sn: lewis

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: Person

objectClass: Top

objectClass: radiusprofile

cn: joe

# search result

search: 3

result: 0 Success

# numResponses: 2

# numEntries: 1

If then searching and requesting only a single attribute :

ldapsearch -h jlewis1 -D cn=admin,o=novell  -W -b o=novell -s sub -x -Z '(cn=joe)' dialupAccess

This should return the LDIF :

# extended LDIF

#

# LDAPv3

# base  with scope subtree

# filter: (&(cn=joe)(objectClass=user))

# requesting: dialupaccess

#

# joe, novell

dn: cn=joe,o=novell

dialupaccess: TRUE

# search result

search: 3

result: 0 Success

# numResponses: 2

# numEntries: 1

Every LDAP request will see the use of anything in the Attribute Mappings on responses. However, when an LDAP request is made, the Attribute Mapping will ALSO be used to obtain the NDS attribute.

This actually resulted in :

# extended LDIF

#

# LDAPv3

# base  with scope subtree

# filter: (cn=joe)

# requesting: dialupAccess

#

# joe, novell

dn: cn=joe,o=novell

# search result

search: 3

result: 0 Success

# numResponses: 2

# numEntries: 1

And this did not contain the requested attribute. Removing the class mapping allowed the real schema attribute to be returned.