Error [80] in LDAP search for user object unser the domain

  • 7009740
  • 14-Nov-2011
  • 27-Apr-2012


Novell Open Enterprise Server 2 (OES 2) Linux
Novell eDirectory
Novell ZENworks 7 Desktop Management Support Pack 1 - ZDM7 SP1 Application Launcher (NAL)


The message, "Error [80] in LDAP search for user object unser the domain with base=o=myOrg filter=(&(objectclass=posixAccount)(uid=*))", was observed in /var/log/messages:
  • when workstations (running ZENworks Desktop Mgmt 7) were not seeing all of their application icons, and
  • intermittently during a periodic check


Error 80 is defined as "other error" (see java error code wiki).  To determine the root cause in eDirectory:
  1. Identify the preferred LDAP server that this OES server used for LUM.
    This is the "preferred-server=" line in /etc/nam.conf
  2. On the preferred LDAP server run the following
    1. ldapconfig set "LDAP Screen Level=all" you will be prompted for a tree admin ID & password
    2. run ndstrace
    3. insure only the following flags are enabled "+TAGS +TIME +LDAP"
    4. enable logging to file with "dstrace file on"
    5. insure the log file can grow to at least 10MB ("dstrace fmax 10000000")
  3. Reproduce the event the triggered the message
    This is typically the cache refresh cycle (persistent-cache-refresh-period in nam.conf).  If that is the default 8 hours, you can reproduce the matter by running the following LDAP search:

    ldapsearch -x -h {ip_addr_of_primary_ldap} -b o={orgOfTree} -s sub "(&(objectclass=posixAccount)(uid=*))"> filename.out

      {ip_addr_of_primary_ldap} = preferred ldap server in nam.conf
      {orgOfTree} = the organization object in your tree
  4. Stop the ndstrace to file ("dstrace file off") and exit ndstrace.
  5. Review either the ndstrace.log file or the filename.out file (from ldapsearch) to see the last object returned.

An example output of the end of the ndstrace log is below.  Note that the last good object returned was in the ou=123,ou=12,ou=1,o=myOrg container:

# UU123456, OU123, OU12, OU1, MYORG
dn: cn=U123456,ou=OU123,ou=OU12,ou=ou1,o=myOrg
description: SIEBEL  Wed Dec 17 14:00:52 CST 2008
description: QUICKPICK_REMOVE Q0005915 Thu Jul 23 07:02:03 CDT 2009
cn: U123456
ACL: 6#entry#cn=U123456,ou=OU123,ou=OU12,ou=OU1,o=MYORG#loginScript
ACL: 6#entry#cn=U123456,ou=OU123,ou=OU12,ou=OU1,o=MYORG#printJobConfiguration
# search result
search: 2
result: 80 Internal (implementation specific) error
text: NDS error: inconsistent database (-618)

In this example, the root cause is an inconsistent database.  The quickest resolution is to:

  1. run a repair on all replicas of this partition
    use dsrepair for NetWare, dsrepair.dlm for Windows (via console app) and ndsrepair on Linux
  2. repeat the verification steps 1-5 (above), to insure there are no other objects that have a problem.

Additional Information

In the example/case above, the inconsistent database (-618) message means that:
  •  an object has an attribute whose value points to the ID of another object (i.e. a group membership, ACL or such), AND
  • the inconsistency is that the other object no longer exists, so the value referred to is invalid.
In all known cases of the above example, the inconsistent database was due to a large number of changes made via LDAP scripts vs. iManager.  Further, the LDAP script utilized was processing one type of change first and then updating the complimentary object much later.  The delay in update of related objects caused the linkages to become inconsistent and repairing the database is the only way to resolve.

It is therefore recommended to make complete changes on one object before moving onto the next.  This can be accomplished by:
  • using iManager (or proper Novell provided tool)
  • use separate LDAP scripts for each unit of work
    Changes typically center around individual users so insure that all group memberships, ACLs, etc. are modified on one user (and complimentary objects) before updating the next.