LDAP queries return attributes unless the attribute is requested

  • 3900179
  • 07-Sep-2006
  • 26-Apr-2012

Environment

Novell eDirectory

Situation

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.

Resolution

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.

Additional Information

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.

Feedback service temporarily unavailable. For content questions or problems, please contact Support.