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.
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")
- Open the "LDAP Group" object for the LDAP server.
- Click on the attribute mapping tab.
- Click the "LDAP Attributes" header. This will sort the list by LDAP attribute.
- Locate the attribute in question in the list (for the examples provided, this is "dialupAccess").
- Remove the attribute from the mapping by clicking delete.
- Apply the changes.
- Unload NLDAP on the LDAP server.
- Reload NLDAP.
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:
This actually resulted in :
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 LDIFIf then searching and requesting only a single attribute :
#
# LDAPv3
# basewith 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
ldapsearch -h jlewis1 -D cn=admin,o=novell -W -b o=novell -s sub -x -Z '(cn=joe)' dialupAccessThis should return the LDIF :
# extended LDIFEvery 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.
#
# LDAPv3
# basewith 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
This actually resulted in :
# extended LDIFAnd this did not contain the requested attribute. Removing the class mapping allowed the real schema attribute to be returned.
#
# LDAPv3
# basewith 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