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

Home >

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

Product:

Centrify DirectControl ,

Published:

29 June,17 at 10:16 AM

Rating:

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 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> 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.