Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

KB-4034: ldapproxy ERROR: Failed to retrieve _objectCategory from object: No such attribute

Centrify DirectControl ,  

29 June,17 at 10:16 AM

Applies to: All versions of Centrify DirectControl on all platforms
 
Question:
 
Below INFO messages are shown whenever NetApp issues a query to get the user mapping. Mapping is set up properly and everything works fine (e.g. "getXXbyYY" and "wcc" return correctly), but below messages are flooding in /var/log/messages file. 
 
Jul 4 22:00:05 hyd-ldapproxy-p1 slapd[2437]: INFO ldapproxy ldapproxy ERROR: Failed to retrieve _objectCategory from object: No such attribute 
Jul 4 22:00:05 hyd-ldapproxy-p1 slapd[2437]: INFO ldapproxy ldapproxy ERROR: Failed to retrieve _objectCategory from object: No such attribute 
Jul 4 22:00:05 hyd-ldapproxy-p1 slapd[2437]: INFO ldapproxy ldapproxy ERROR: Failed to retrieve _objectCategory from object: No such attribute 
Jul 4 22:00:05 hyd-ldapproxy-p1 slapd[2437]: INFO ldapproxy ldapproxy ERROR: Failed to retrieve _objectCategory from object: No such attribute 
Jul 4 22:00:05 hyd-ldapproxy-p1 slapd[2437]: INFO ldapproxy ldapproxy ERROR: Failed to retrieve _objectCategory from object: No such attribute 
Jul 4 22:00:05 hyd-ldapproxy-p1 slapd[2437]: INFO ldapproxy ldapproxy ERROR: Failed to retrieve _objectCategory from object: No such attribute 
Jul 4 22:00:05 hyd-ldapproxy-p1 slapd[2437]: INFO ldapproxy ldapproxy ERROR: Failed to retrieve _objectCategory from object: No such attribute 
Jul 4 22:00:05 hyd-ldapproxy-p1 rsyslogd-2177: imuxsock begins to drop messages from pid 2437 due to rate-limiting 
Jul 4 22:00:37 hyd-ldapproxy-p1 rsyslogd-2177: imuxsock lost 793 messages from pid 2437 due to rate-limiting 
Jul 4 22:00:37 hyd-ldapproxy-p1 slapd[2437]: INFO ldapproxy ldapproxy ERROR: Failed to retrieve _objectCategory from object: No such attribute 
=== 
 
Below are the LDAP Options. 
 
hydnas1> 
hydnas1> 
hydnas1> options ldap 
ldap.ADdomain siliconimage.com 
ldap.base DC=siliconimage,DC=com 
ldap.base.group 
ldap.base.netgroup 
ldap.base.passwd 
ldap.enable on 
ldap.minimum_bind_level anonymous 
ldap.name sballa1 
ldap.nssmap.attribute.gecos gecos 
ldap.nssmap.attribute.gidNumber gidNumber 
ldap.nssmap.attribute.groupname cn 
ldap.nssmap.attribute.homeDirectory unixHomeDirectory 
ldap.nssmap.attribute.loginShell loginShell 
ldap.nssmap.attribute.memberNisNetgroup memberNisNetgroup 
ldap.nssmap.attribute.memberUid memberUid 
ldap.nssmap.attribute.netgroupname cn 
ldap.nssmap.attribute.nisNetgroupTriple nisNetgroupTriple 
ldap.nssmap.attribute.uid uid 
ldap.nssmap.attribute.uidNumber uidNumber 
ldap.nssmap.attribute.userPassword userPassword 
ldap.nssmap.objectClass.nisNetgroup nisNetgroup 
ldap.nssmap.objectClass.posixAccount user 
ldap.nssmap.objectClass.posixGroup posixGroup 
ldap.passwd ****** 
ldap.port 389 
ldap.rfc2307bis.enable off 
ldap.servers hyd-ldapproxy-p1 
ldap.servers.preferred 
ldap.ssl.enable off 
ldap.timeout 20 
ldap.usermap.attribute.unixaccount unixaccount 
ldap.usermap.attribute.windowsaccount windowsaccount 
ldap.usermap.base 
ldap.usermap.enable off
 
Tried another KB: KB-2722: Nothing returned when querying Users and Groups from Netapp through Centrify Ldapproxy but it didn't help. Restarting CentrifyDC and LDAP proxy in LDAP proxy server didn't help neither.
 
Is there any way to get rid of this kind of INFO message in /var/log/messages? Is this message harmful?
 
Answer:
 
This INFO message is confirmed to be harmless - that is, it does not hamper functionality.
 
The root cause of this message is using a bad (unsupported) search filter when doing a query. For example:
 
[root@RedHat libexec]# /usr/share/centrifydc/bin/ldapsearch -x -D fred.thomas@henry.cheung -W -h redhat.henry.cheung -b "DC=henry,DC=cheung" '(&(objectClass=user)(uid=fredthomas))' uidnumber shell
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <DC=henry,DC=cheung> with scope sub
# filter: (&(objectClass=user)(uid=fredthomas))
# requesting: uidnumber shell 
# with pagedResults control: size=100
#
 
# Fred Thomas, Users, henry.cheung
dn: cn=Fred Thomas,cn=Users,dc=henry,dc=cheung
uidNumber: 1234567
 
# search result
search: 2
result: 0 Success
 
# numResponses: 2
# numEntries: 1
 
The INFO message will be logged in /var/log/messsages after the above ldapsearch command. It is due to the unsupported search filter: (objectClass=user).
 
Technically speaking, in the code, the category "user" is being looked up in a Translation Map. Since this cannot be found in the translation map, cdcCategory will be empty and "_objectCategory" will not be added to object's attribute list. This is the reason why the INFO message says: "Failed to retrieve _objectCategory from object: No such attribute"
 
To get rid of the INFO message, the search filter has to be modified from the unsupported one: (objectClass=user) to a supported one: (objectClass=posixAccount).
 
Alternatively, as a workaround, the log level of ldapproxy can be raised to WARN in order to get rid of those INFO messages in /var/log/messages:
 
1. Add the following line into /etc/centrifydc/centrifydc.conf:
 
log.ldapproxy: WARN
 
2. Run "adreload" to make the configuration change effective instantly.
 
3. Restarting slapd
 
For example:
 
[root@RedHat libexec]# vi /etc/centrifydc/centrifydc.conf
 
[root@RedHat libexec]# cat /etc/centrifydc/centrifydc.conf | grep log.ldapproxy
log.ldapproxy: WARN
 
[root@RedHat libexec]# adreload
 
[root@RedHat libexec]# ps -ef | grep -i slapd
root     30583     1  0 04:21 ?        00:00:00 /usr/share/centrifydc/libexec/slapd -f /etc/centrifydc/openldap/slapd.conf -h ldap://redhat.henry.cheung
root     30658 25437  0 04:23 pts/4    00:00:00 grep -i slapd
 
[root@RedHat libexec]# kill 30583
 
[root@RedHat libexec]# /usr/share/centrifydc/libexec/slapd -f /etc/centrifydc/openldap/slapd.conf -h ldap://redhat.henry.cheung > /tmp/slapd.out 2>&1 
 
[root@RedHat libexec]# ps -ef | grep -i slapd
root     30663     1  0 04:24 ?        00:00:00 /usr/share/centrifydc/libexec/slapd -f /etc/centrifydc/openldap/slapd.conf -h ldap://redhat.henry.cheung
root     30666 25437  0 04:24 pts/4    00:00:00 grep -i slapd
 
Run the same ldapsearch command as above (with bad search filter: objectClass=user) to verify. That INFO messages in question will not show up again in /var/log/messages after the ldapsearch command.

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.