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.
KB-20210: Common Questions Regarding Centrify DirectControl and CoreOS