eDirectory root server hit by useless LDAP searches from ZCM-managed SLES servers

  • 7013258
  • 11-Sep-2013
  • 11-Sep-2013


NetIQ eDirectory
Novell Open Enterprise Server 2 (OES 2) Linux Support Pack 3


While diagnosing utilization and performance issues on a OES2 SP3 server holding the [Root] of a large tree, numerous searches (over 5,000 in a 10 minute trace) for Posix objects were seen in LDAP traces. These took the form

1689246016 LDAP: [2013/07/04 13:42:35.622] ( Search request:
base: "o=XXX"
scope:2  dereference:0  sizelimit:1  timelimit:0  attrsonly:0
filter: "(&(objectClass=posixAccount)(uid=root))"
no attributes

The searches were looking for a specific object uid=root (which did not exist) with a scope that was effectively the entire tree. The IP addresses they came from were the customer's branch SLES servers managed by ZCM. Suspicion fell on ZCM, but there was no known reason why it should trigger such searches.


These are the changes made to silence the excessive requests made. The default SLES configuration was to contact the LDAP server for searches prior to local server.  Editing nsswitch.conf changed the order of the search. The changes made to the SLES servers were:

*   Execute visudo  (Rem out references to any group that refers to a Group in the Edirectory Tree.  Actually rem out any unnecessary Group or User references.)

*   vi /etc/nsswitch.conf  (Place the parameter "files" into the lines below)

passwd: files compat
group:  files compat

passwd_compat:  files ldap
group_compat:   files ldap


The customer's standard SLES server build referenced the eDirectory server in its /etc/ldap.conf file.  This was probably the result of a question asking to provide an LDAP server during the server build.

The excessive LDAP requests commenced after Nagios was installed on the branch SLES servers.  Nagios runs various queries or scripts regularly.  Each query requires elevated permissions, so the "Sudoers" file is interrogated.  Each time this occurred the LDAP server referenced in /etc/ldap.conf was contacted, and a search of the eDirectory Tree was conducted for the "root" user, and a Group that was configured in the Sudoers file.