H2: Common causes of LDAP errors
-Port answers from http://www.openldap.org/faq/data/cache/53.html
-
H3: ldap_*: Can't contact LDAP server
+The {[B:Can't contact LDAP server}} error is usually returned when the LDAP
+server cannot be contacted. This may occur for many reasons:
+
+* the LDAP server is not running; this can be checked by running, for example,
+
+> telnet <host> <port>
+
+replacing {{<host>}} and {{<port>}} with the hostname and the port the server
+is supposed to listen on.
+* the client has not been instructed to contact a running server; with OpenLDAP
+command-line tools this is accomplished by providing the -H switch, whose
+argument is a valid LDAP url corresponding to the interface the server is
+supposed to be listening on.
+
H3: ldap_*: No such object
+The {{B:no such object}} error is generally returned when the target DN of the
+operation cannot be located. This section details reasons common to all
+operations. You should also look for answers specific to the operation
+(as indicated in the error message).
+
+The most common reason for this error is non-existence of the named object. First,
+check for typos.
+
+Also note that, by default, a new directory server holds no objects
+(except for a few system entries). So, if you are setting up a new directory
+server and get this message, it may simply be that you have yet to add the
+object you are trying to locate.
+
+The error commonly occurs because a DN was not specified and a default was not
+properly configured.
+
+If you have a suffix specified in slapd.conf eg.
+
+> suffix "dc=example,dc=com"
+
+You should use
+
+> ldapsearch -b 'dc=example,dc=com' '(cn=jane*)'
+
+to tell it where to start the search.
+
+The {{F:-b}} should be specified for all LDAP commands unless you have an
+{{ldap.conf}}(5) default configured.
+
+See {{ldapsearch}}(1), {{ldapmodify}}(1)
+
+Also, {{slapadd}}(8) and its ancillary programs are very strict about the
+syntax of the LDIF file.
+
+Some liberties in the LDIF file may result in an apparently successful creation
+of the database, but accessing some parts of it may be difficult.
+
+One known common error in database creation is putting a blank line before the
+first entry in the LDIF file. {{B:There must be no leading blank lines in the
+LDIF file.}}
+
+It is generally recommended that {{ldapadd}}(1) be used instead of {{slapadd}}(8)
+when adding new entries your directory. {{slapadd}}(8) should be used to bulk
+load entries known to be valid.
+
+Another cause of this message is a referral
+({SECT:Constructing a Distributed Directory Service}}) entry to an unpopulated
+directory.
+
+Either remove the referral, or add a single record with the referral base DN
+to the empty directory.
+
+This error may also occur when slapd is unable to access the contents of its
+database because of file permission problems. For instance, on a Red Hat Linux
+system, slapd runs as user 'ldap'. When slapadd is run as root to create a
+database from scratch, the contents of {{F:/var/lib/ldap}} are created with
+user and group root and with permission 600, making the contents inaccessible
+to the slapd server.
+
H3: ldap_*: Can't chase referral
+This is caused by the line
+
+> referral ldap://root.openldap.org
+
+In {{F:slapd.conf}}, it was provided as an example for how to use referrals
+in the original file. However if your machine is not permanently connected to
+the Internet, it will fail to find the server, and hence produce an error message.
+
+To resolve, just place a # in front of line and restart slapd or point it to
+an available ldap server.
+
+See also: {{ldapadd}}(1), {{ldapmodify}}(1) and {{slapd.conf}}(5)
+
H3: ldap_*: server is unwilling to perform
+slapd will return an unwilling to perform error if the backend holding the
+target entry does not support the given operation.
+
+The password backend is only willing to perform searches. It will return an
+unwilling to perform error for all other operations.
+
+The shell backend is configurable and may support a limited subset of operations.
+Check for other errors indicating a shortage of resources required by the
+directory server. i.e. you may have a full disk etc
+
H3: ldap_*: Insufficient access
+This error occurs when server denies the operation due to insufficient access.
+This is usually caused by binding to a DN with insufficient privileges
+(or binding anonymously) to perform the operation.
+
+You can bind as the rootdn/rootpw specified in {{slapd.conf}}(5) to gain full
+access. Otherwise, you must bind to an entry which has been granted the
+appropriate rights through access controls.
+
+
H3: ldap_*: Invalid DN syntax
+The target (or other) DN of the operation is invalid. This implies that either
+the string representation of the DN is not in the required form, one of the
+types in the attribute value assertions is not defined, or one of the values
+in the attribute value assertions does not conform to the appropriate syntax.
+
H3: ldap_*: Referral hop limit exceeded
+This error generally occurs when the client chases a referral which refers
+itself back to a server it already contacted. The server responds as it did
+before and the client loops. This loop is detected when the hop limit is exceeded.
+
+This is most often caused through misconfiguration of the server's default
+referral. The default referral should not be itself:
+
+That is, on {{F:ldap://myldap/}} the default referral should not be {{F:ldap://myldap/}}
+ (or any hostname/ip which is equivalent to myldap).
+
H3: ldap_*: operations error
+In some versions of {{slapd}}(8), {{operationsError}} was returned instead of other.
+
H3: ldap_*: other error
-H2: Causes specific to specific LDAP operations:
+The other result code indicates an internal error has occurred.
+While the additional information provided with the result code might provide
+some hint as to the problem, often one will need to consult the server's log files.
H3: ldap_add/modify: Invalid syntax
+This error is reported when a value of an attribute does not conform to syntax
+restrictions. Additional information is commonly provided stating which value
+of which attribute was found to be invalid. Double check this value and other
+values (the server will only report the first error it finds).
+
+Common causes include:
+
+* extraneous white space (especially trailing white space)
+* improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
+* empty values (few syntaxes allow empty values)
+
+
+For certain syntax, like OBJECT IDENTIFIER (OID), this error can indicate that
+the OID descriptor (a "short name") provided is unrecognized. For instance,
+this error is returned if the {{objectClass}} value provided is unrecognized.
+
H3: ldap_add/modify: Object class violation
+This error is returned with the entry to be added or the entry as modified
+violates the object class schema rules. Normally additional information is
+returned the error detailing the violation. Some of these are detailed below.
+
+Violations related to the entry's attributes:
+
+> Attribute not allowed
+
+A provided attribute is not allowed by the entry's object class(es).
+
+> Missing required attribute
+
+An attribute required by the entry's object class(es) was not provided.
+
+Violations related to the entry's class(es):
+
+> Entry has no objectClass attribute
+
+The entry did not state which object classes it belonged to.
+
+> Unrecognized objectClass
+
+One (or more) of the listed objectClass values is not recognized.
+
+> No structural object class provided
+
+None of the listed objectClass values is structural.
+
+> Invalid structural object class chain
+
+Two or more structural objectClass values are not in same structural object
+class chain.
+
+> Structural object class modification
+
+Modify operation attempts to change the structural class of the entry.
+
+> Instanstantiation of abstract objectClass.
+
+An abstract class is not subordinate to any listed structural or auxiliary class.
+
+> Invalid structural object class
+
+Other structural object class problem.
+
+> No structuralObjectClass operational attribute
+
+This is commonly returned when a shadow server is provided an entry which does
+not contain the structuralObjectClass operational attribute.
+
+
+Note that the above error messages as well as the above answer assumes basic
+knowledge of LDAP/X.500 schema.
+
H3: ldap_add: No such object
+The "ldap_add: No such object" error is commonly returned if parent of the
+entry being added does not exist. Add the parent entry first...
+
+For example, if you are adding "cn=bob,dc=domain,dc=com" and you get:
+
+> ldap_add: No such object
+
+The entry "dc=domain,dc=com" likely doesn't exist. You can use ldapsearch to
+see if does exist:
+
+> ldapsearch -b 'dc=domain,dc=com' -s base '(objectclass=*)'
+
+If it doesn't, add it. See {{SECT:A Quick-Start Guide}} for assistance.
+
+Note: if the entry being added is the same as database suffix, it's parent
+isn't required. i.e.: if your suffix is "dc=domain,dc=com", "dc=com" doesn't
+need to exist to add "dc=domain,dc=com".
+
+This error will also occur if you try to add any entry that the server is not
+configured to hold.
+
+For example, if your database suffix is "dc=domain,dc=com" and you attempt to
+add "dc=domain2,dc=com", "dc=com", "dc=domain,dc=org", "o=domain,c=us", or an
+other DN in the "dc=domain,dc=com" subtree, the server will return a
+ "No such object" (or referral) error.
+
+{{slapd}}(8) will generally return "no global superior knowledge" as additional
+information indicating its return noSuchObject instead of a referral as the
+server is not configured with knowledge of a global superior server.
+
+
H3: ldap add: invalid structural object class chain
+This particular error refers to the rule about STRUCTURAL objectclasses, which
+states that an object is of one STRUCTURAL class, the structural class of the
+object. The object is said to belong to this class, zero or more auxiliaries
+ classes, and their super classes.
+
+While all of these classes are commonly listed in the objectClass attribute of
+the entry, one of these classes is the structural object class of the entry.
+Thus, it is OK for an objectClass attribute
+to contain inetOrgPerson, organizationalPerson, and person because they inherit
+ one from another to form a single super class chain. That is, inetOrgPerson SUPs
+organizationPerson SUPs person. On the other hand, it is invalid for both inetOrgPerson
+and account to be listed in objectClass as inetOrgPerson and account are not
+part of the same super class chain (unless some other class is also listed
+with is a subclass of both).
+
+To resolve this problem, one must determine which class will better serve
+structural object class for the entry, adding this class to the objectClass
+attribute (if not already present), and remove any other structural class from
+the entry's objectClass attribute which is not a super class of the structural
+object class.
+
+Which object class is better depends on the particulars of the situation.
+One generally should consult the documentation for the applications one is
+using for help in making the determination.
+
H3: ldap_add: no structuralObjectClass operational attribute
+ldapadd(1) may error:
+
+> adding new entry "uid=XXX,ou=People,o=campus,c=ru"
+> ldap_add: Internal (implementation specific) error (80)
+> additional info: no structuralObjectClass operational attribute
+
+when slapd(8) cannot determine, based upon the contents of the objectClass
+attribute, what the structural class of the object should be.
+
+
H3: ldap_add/modify/rename: Naming violation
+OpenLDAP's slapd checks for naming attributes and distinguished values consistency,
+according to RFC 4512.
+
+Naming attributes are those attributeTypes that appear in an entry's RDN;
+ distinguished values are the values of the naming attributes that appear in
+an entry's RDN, e.g, in
+
+> cn=Someone+mail=someone@example.com,dc=example,dc=com
+
+the naming attributes are cn and mail, and the distinguished values are
+Someone and someone@example.com.
+
+OpenLDAP's slapd checks for consistency when:
+
+* adding an entry
+* modifying an entry, if the values of the naming attributes are changed
+* renaming an entry, if the RDN of the entry changes
+
+Possible causes of error are:
+
+* the naming attributes are not present in the entry; for example:
+
+> dn: dc=example,dc=com
+> objectClass: organization
+> o: Example
+> # note: "dc: example" is missing
+
+* the naming attributes are present in the entry, but in the attributeType
+definition they are marked as:
+- collective
+- operational
+- obsolete
+
+* the naming attributes are present in the entry, but the distinguished values
+are not; for example:
+
+> dn: dc=example,dc=com
+> objectClass: domain
+> dc: foobar
+> # note: "dc" is present, but the value is not "example"
+
+* the naming attributes are present in the entry, with the distinguished values, but the naming attributes:
+- do not have an equality field, so equality cannot be asserted
+- the matching rule is not supported (yet)
+- the matching rule is not appropriate
+
+* the given distinguished values do not comply with their syntax
+
+* other errors occurred during the validation/normalization/match process;
+this is a catchall: look at previous logs for details in case none of the above
+apply to your case.
+
+In any case, make sure that the attributeType definition for the naming attributes
+contains an appropriate EQUALITY field; or that of the superior, if they are
+defined based on a superior attributeType (look at the SUP field). See RFC 4512 for details.
+
+
H3: ldap_add/delete/modify/rename: no global superior knowledge
+If the target entry name places is not within any of the databases the server
+is configured to hold and the server has no knowledge of a global superior,
+the server will indicate it is unwilling to perform the operation and provide
+the text "no global superior knowledge" as additional text.
+
+Likely the entry name is incorrect, or the server is not properly configured
+to hold the named entry, or, in distributed directory environments, a default
+referral was not configured.
+
+
H3: ldap_bind: Insufficient access
+Current versions of slapd(8) requires that clients have authentication
+permission to attribute types used for authentication purposes before accessing
+them to perform the bind operation. As all bind operations are done anonymously
+(regardless of previous bind success), the auth access must be granted to anonymous.
+
+In the example ACL below grants the following access:
+
+* to anonymous users:
+- permission to authenticate using values of userPassword
+* to authenticated users:
+- permission to update (but not read) their userPassword
+- permission to read any object excepting values of userPassword
+
+All other access is denied.
+
+> access to attr=userPassword
+> by self =w
+> by anonymous auth
+
+> access *
+> by self write
+> by users read
+
+
H3: ldap_bind: Invalid credentials
-H3: ldap_bind: No such object
+The error usually occurs when the credentials (password) provided does not
+match the userPassword held in entry you are binding to.
+
+The error can also occur when the bind DN specified is not known to the server.
+
+Check both! In addition to the cases mentioned above you should check if the
+server denied access to userPassword on selected parts of the directory. In
+fact, slapd always returns "Invalid credentials" in case of failed bind,
+regardless of the failure reason, since other return codes could reveal the
+validity of the user's name.
+
+To debug access rules defined in slapd.conf, add "ACL" to log level.
H3: ldap_bind: Protocol error
+There error is generally occurs when the LDAP version requested by the
+client is not supported by the server.
+
+The OpenLDAP Software 2.x server, by default, only accepts version 3 LDAP Bind
+requests but can be configured to accept a version 2 LDAP Bind request.
+
+Note: The 2.x server expects LDAPv3 [RFC4510] to be used when the client
+requests version 3 and expects a limited LDAPv3 variant (basically, LDAPv3
+syntax and semantics in an LDAPv2 PDUs) to be used when version 2 is expected.
+
+This variant is also sometimes referred to as LDAPv2+, but differs from the U-Mich
+LDAP variant in a number of ways.
+
H3: ldap_modify: cannot modify object class
+This message is commonly returned when attempting to modify the objectClass
+attribute in a manner inconsistent with the LDAP/X.500 information model. In
+particular, it commonly occurs when one tries to change the structure of the
+object from one class to another, for instance, trying to change an 'apple'
+into a 'pear' or a 'fruit' into a 'pear'.
+
+Such changes are disallowed by the slapd(8) in accordance with LDAP and X.500 restrictions.
+
+
H3: ldap_sasl_interactive_bind_s: ...
+If you intended to bind using a DN and password and get an error from
+ldap_sasl_interactive_bind_s, you likely forgot to provide a '-x' option to
+the command. By default, SASL authentication is used. '-x' is necessary to
+select "simple" authentication.
+
+
H3: ldap_sasl_interactive_bind_s: No such Object
+This indicates that LDAP SASL authentication function could not read the
+Root DSE.
+The error will occur when the server doesn't provide a root DSE. This may be
+due to access controls.
+
+
H3: ldap_sasl_interactive_bind_s: No such attribute
+This indicates that LDAP SASL authentication function could read the Root
+DSE but it contained no supportedSASLMechanism attribute.
+
+The supportedSASLmechanism attribute lists mechanisms currently available.
+The list may be empty because none of the supported mechanisms are currently
+available. For example, EXTERNAL is listed only if the client has established
+its identity by authenticating at a lower level (e.g. TLS).
+
+Note: the attribute may not be visible due to access controls
+
+Note: SASL bind is the default for all OpenLDAP tools, e.g. ldapsearch(1), ldapmodify(1). To force use of "simple" bind, use the "-x" option. Use of "simple" bind is not recommended unless one has adequate confidentiality protection in place (e.g. TLS/SSL, IPSEC).
+
H3: ldap_sasl_interactive_bind_s: Unknown authentication method
+This indicates that none of the SASL authentication supported by the server
+are supported by the client, or that they are too weak or otherwise inappropriate
+for use by the client. Note that the default security options disallows the use
+of certain mechanisms such as ANONYMOUS and PLAIN (without TLS).
+
+Note: SASL bind is the default for all OpenLDAP tools. To force use of "simple" bind, use the "-x" option. Use of "simple" bind is not recommended unless one has adequate confidentiality protection in place (e.g. TLS/SSL, IPSEC).
+
H3: ldap_sasl_interactive_bind_s: Local error (82)
+Apparently not having forward and reverse DNS entries for the LDAP server can result in this error.
+
+
H3: ldap_search: Partial results and referral received
+This error is returned with the server responses to an LDAPv2 search query
+with both results (zero or more matched entries) and references (referrals to other servers).
+See also: ldapsearch(1).
+
+If the updatedn on the replica does not exist, a referral will be returned.
+It may do this as well if the ACL needs tweaking.
+
H3: ldap_start_tls: Operations error
-H2: Other errors:
+ldapsearch(1) and other tools will return
+
+> ldap_start_tls: Operations error (1)
+> additional info: TLS already started
+
+When the user (though command line options and/or ldap.conf(5)) has requested
+TLS (SSL) be started twice. For instance, when specifying both "-H ldaps://server.do.main" and "-ZZ".
+
+H2: Other Errors
H3: ber_get_next on fd X failed errno=34 (Numerical result out of range)
+This slapd error generally indicates that the client sent a message that
+exceeded an administrative limit. See sockbuf_max_incoming and sockbuf_max_incoming_auth
+configuration directives in slapd.conf(5).
+
H3: ber_get_next on fd X failed errno=11 (Resource temporarily unavailable)
+This message is not indicative of abnormal behavior or error. It simply means
+that expected data is not yet available from the resource, in this context, a
+network socket. slapd(8) will process the data once it does becomes available.
+
H3: daemon: socket() failed errno=97 (Address family not supported)
+This message indicates that the operating system does not support one of the
+(protocol) address families which slapd(8) was configured to support. Most
+commonly, this occurs when slapd(8) was configured to support IPv6 yet the
+operating system kernel wasn't. In such cases, the message can be ignored.
+
H3: GSSAPI: gss_acquire_cred: Miscellaneous failure; Permission denied;
+This message means that slapd is not running as root and, thus, it cannot get
+its Kerberos 5 key from the keytab, usually file /etc/krb5.keytab.
+
+A keytab file is used to store keys that are to be used by services or daemons
+that are started at boot time. It is very important that these secrets are kept
+beyond reach of intruders.
+
+That's why the default keytab file is owned by root and protected from being
+read by others. Do not mess with these permissions, build a different keytab
+file for slapd instead.
+
+To do this, start kadmin, and enter the following commands:
+
+> addprinc -randkey ldap/ldap.example.com@EXAMPLE.COM
+> ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM
+
+Then, on the shell, do:
+
+> chown ldap.ldap /etc/openldap/ldap.keytab
+> chmod 600 /etc/openldap/ldap.keytab
+
+Now you have to tell slapd (well, actually tell the gssapi library in Kerberos 5
+that is invoked by Cyrus SASL) where to find the new keytab. You do this by
+setting the environment variable KRB5_KTNAME like this:
+
+> export KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"
+
+Set that environment variable on the slapd start script (Red Hat users might
+find /etc/sysconfig/ldap a perfect place).
+
+This only works if you are using MIT kerberos. It doesn't work with Heimdal,
+for instance.
+
+
+In Heimdal there is a function gsskrb5_register_acceptor_identity() that sets
+the path of the keytab file you want to use. In Cyrus SASL 2 you can add
+
+> keytab: /path/to/file
+
+to your application's SASL config file to use this feature. This only works with Heimdal.
+
+
H3: access from unknown denied
+This related to TCP wrappers. See hosts_access(5) for more information.
+in the log file: "access from unknown denied" This related to TCP wrappers.
+See hosts_access(5) for more information.
+for example: add the line "slapd: .hosts.you.want.to.allow" in /etc/hosts.allow
+to get rid of the error.
+
H3: ldap_read: want=# error=Resource temporarily unavailable
+This message occurs normally. It means that pending data is not yet available
+from the resource, a network socket. slapd(8) will process the data once it
+becomes available.
+
H3: `make test' fails
+Some times, `make test' fails at the very first test with an obscure message like
+
+> make test
+> make[1]: Entering directory `/ldap_files/openldap-2.4.6/tests'
+> make[2]: Entering directory `/ldap_files/openldap-2.4.6/tests'
+> Initiating LDAP tests for BDB...
+> Cleaning up test run directory leftover from previous run.
+> Running ./scripts/all...
+> >>>>> Executing all LDAP tests for bdb
+> >>>>> Starting test000-rootdse ...
+> running defines.sh
+> Starting slapd on TCP/IP port 9011...
+> Using ldapsearch to retrieve the root DSE...
+> Waiting 5 seconds for slapd to start...
+> ./scripts/test000-rootdse: line 40: 10607 Segmentation fault $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1
+> Waiting 5 seconds for slapd to start...
+> Waiting 5 seconds for slapd to start...
+> Waiting 5 seconds for slapd to start...
+> Waiting 5 seconds for slapd to start...
+> Waiting 5 seconds for slapd to start...
+> ./scripts/test000-rootdse: kill: (10607) - No such pid
+> ldap_sasl_bind_s: Can't contact LDAP server (-1)
+> >>>>> Test failed
+> >>>>> ./scripts/test000-rootdse failed (exit 1)
+> make[2]: *** [bdb-yes] Error 1
+> make[2]: Leaving directory `/ldap_files/openldap-2.4.6/tests'
+> make[1]: *** [test] Error 2
+> make[1]: Leaving directory `/ldap_files/openldap-2.4.6/tests'
+> make: *** [test] Error 2
+
+or so. Usually, the five lines
+
+ Waiting 5 seconds for slapd to start...
+
+indicate that slapd didn't start at all.
+
+In tests/testrun/slapd.1.log there is a full log of what slapd wrote while
+trying to start. The log level can be increased by setting the environment
+variable SLAPD_DEBUG to the corresponding value; see loglevel in slapd.conf(5)
+for the meaning of log levels.
+
+A typical reason for this behavior is a runtime link problem, i.e. slapd cannot
+find some dynamic libraries it was linked against. Try running ldd(1) on slapd
+(for those architectures that support runtime linking).
+
+There might well be other reasons; the contents of the log file should help
+clarifying them.
+
+Tests that fire up multiple instances of slapd typically log to tests/testrun/slapd.<n>.log,
+with a distinct <n> for each instance of slapd; list tests/testrun/ for possible
+values of <n>.
+
+H3: ldap_*: Internal (implementation specific) error (80) - additional info: entry index delete failed
+
+This seems to be related with wrong ownership of the BDB's dir (/var/lib/ldap)
+and files.
+
+> chmod -R openldap:openldap /var/lib/ldap
+
+fixes it in Debian
+
+
+H3: ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
+
+Using SASL, when a client contacts LDAP server, the slapd service dies
+immediately and client gets an error :
+
+> SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
+
+Then check the slapd service, it stopped.
+
+This may come from incompatible of using different versions of BerkeleyDB for
+installing of SASL and installing of OpenLDAP. The problem arises in case of
+using multiple version of BerkeleyDB. Solution: - Check which version of
+BerkeleyDB when install Cyrus SASL.
+
+Reinstall OpenLDAP with the version of BerkeleyDB above.
+
projects / openldap / blobdiff