# $OpenLDAP$
-# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 2007-2008 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Common errors encountered when using OpenLDAP Software
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.
+argument is a valid LDAP url corresponding to the interface the server is
+supposed to be listening on.
H3: ldap_*: No such object
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.
+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.
You should use
- ldapsearch -b 'dc=example,dc=com' '(cn=jane*)'
+> ldapsearch -b 'dc=example,dc=com' '(cn=jane*)'
to tell it where to start the search.
-The -b should be specified for all LDAP commands unless you have an ldap.conf(5) default configured.
+The {{F:-b}} should be specified for all LDAP commands unless you have an
+{{ldap.conf}}(5) default configured.
-See Also: ldapsearch(1), ldapmodify(1), and (Xref) How do I specify default base DN for clients?
-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.
+See {{ldapsearch}}(1), {{ldapmodify}}(1)
-One known common error in database creation is putting a blank line before the first entry in the LDIF file. There must be no leading blank lines in the LDIF file.
+Also, {{slapadd}}(8) and its ancillary programs are very strict about the
+syntax of 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 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 /var/lib/ldap are created with user and group root and with permission 600, making the contents inaccessible to the slapd server.
+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
+> referral ldap://root.openldap.org
-in 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.
+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) slapd.conf(5)
+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
-The OpenLDAP server 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.
+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
+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.
-See also: ldapadd(1) ldapdelete(1) ldapmodify(1) ldapmodrdn(1) ldapsearch(1) slapd.conf(5)
-(Xref) ldap_bind: Insufficient access (Xref) Access Control
+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.
+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 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:
+This is most often caused through misconfiguration of the server's default
+referral. The default referral should not be itself:
-That is, on ldap://myldap/ the default referral should not be ldap://myldap/ (or any hostname/ip which is equivalent to myldap).
+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. See also: (Xref) ldap_*: other error.
+In some versions of {{slapd}}(8), {{operationsError}} was returned instead of other.
H3: ldap_*: other error
-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.
+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).
+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)
+* 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.
+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.
+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.
+> 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. See also (Xref) ldap add: invalid structural object class chain.
- Structural object class modification
- Modify operation attempts to change the structural class of the entry. See also (Xref) ldap_modify: cannot modify object class.
- 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.
+> 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...
+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
+> ldap_add: No such object
-The entry "dc=domain,dc=com" likely doesn't exist. You can use ldapsearch to see if does exist:
+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=*)'
+> ldapsearch -b 'dc=domain,dc=com' -s base '(objectclass=*)'
-If it doesn't, add it. See the Quick Start Guide (http://www.openldap.org/doc/admin/quickstart.html) for assistance.
+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.
+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".
-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.
+This error will also occur if you try to add any entry that the server is not
+configured to hold.
-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.
-See also: ldapadd(1) ldapmodify(1) (Xref) ldap_add/delete/modify/rename: no global superior knowledge
+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.
-H3: ldap add: invalid structural object class chain
+{{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.
-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.
+H3: ldap add: invalid structural object class chain
-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.
+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
+> 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.
+when slapd(8) cannot determine, based upon the contents of the objectClass
+attribute, what the structural class of the object should be.
-While this normally should produce an object class violation error, some versions of slapd(8) contain a minor bug which cause the object class error not to be properly detected. In these versions, slapd(8) instead catches its failure to populate the structuralObjectClass operational attribute (hence the internal error).
-Kurt@OpenLDAP.org
-See also: (Xref) ldap add: invalid structural object class chain
-Kurt@OpenLDAP.org
H3: ldap_add/modify/rename: Naming violation
-OpenLDAP's slapd checks for naming attributes and distinguished values consistency, according to RFC 4512.
+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
+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
+> 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.
+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
+* 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:
+* 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
- 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 in the attributeType definition they are marked as:
- o collective
- o operational
- o obsolete
- * the naming attributes are present in the entry, but the distinguished values are not; for example:
+* 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"
+> 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:
- o do not have an equality field, so equality cannot be asserted
- o the matching rule is not supported (yet)
- o 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.
+* 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.
-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.
-ando@sys-net.it, Kurt@OpenLDAP.org
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.
+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.
-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.
-Kurt@OpenLDAP.org
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.
+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:
- o permission to authenticate using values of userPassword
- * to authenticated users:
- o permission to update (but not read) their userPassword
- o permission to read any object excepting values of userPassword
+* 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 to attr=userPassword
+> by self =w
+> by anonymous auth
- access *
- by self write
- by users read
+> access *
+> by self write
+> by users read
-Note that latest versions of slapd(8) will report invalid credentials in cases where the client has insufficient access to complete the operation. This is avoid inappropriate disclosure of the validity of the user's name.
-See also: ldapadd(1) ldapdelete(1) ldapmodify(1) ldapmodrdn(1) ldapsearch(1) slapd.conf(5) (Xref) Access Control
-
H3: ldap_bind: Invalid credentials
-The error usually occurs when the credentials (password) provided does not match the userPassword held in entry you are binding to.
+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.
+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.
-See also: ldapadd(1) ldapdelete(1) ldapmodify(1) ldapmodrdn(1) ldapsearch(1) slapd.conf(5) (Xref) ldap_bind: No such object
-
-H3: ldap_bind: No such object
-
-This answer is specific to OpenLDAP 1.2 and earlier releases. In later releases, ldap_bind returns (Xref) ldap_bind: Invalid credentials instead.
-'No such object' is only returned by ldap_bind operation in a few special cases. Normally, the server returns (Xref) ldap_bind: Invalid credentials when the entry associated with the bind DN cannot be located.
-This error occurs when binding using the rootdn and the asserted value doesn't match configured password value. Rootpw values must be conform to RFC 2307 format defined for userPassword.
-See also: ldapadd(1) ldapdelete(1) ldapmodify(1) ldapmodrdn(1) ldapsearch(1) slapd.conf(5) (Xref) ldap_bind: Invalid credentials
H3: ldap_bind: Protocol error
-There error is generally occurs when the LDAP version requested by the client is not supported by the server.
+There error is generally occurs when the LDAP version requested by the
+client is not supported by the server.
-The OpenLDAP Software 1.x server only accepts version 2 LDAP Bind requests. Note that 1.x server expects U-Mich LDAP, an LDAPv2 variant, to be used. This variant is sometimes referred to as LDAPv2+.
+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.
-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 that 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.
+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.
-Use of LDAPv3!
-See also: (Xref) How to configure slapd(8) with LDAPv2 support (for legacy clients)?.
+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.
+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.
-To overcome this restriction in 2.3 (and prior releases), one must re-create the object with the desired new structural object class (e.g., delete old object then add new object). In 2.4, support for a new control will (hopefully) be introduced to allow the (authorized) user to request this (and various other model restrictions) be temporarily relaxed.
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.
-Kurt@OpenLDAP.org
+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.
+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.
-Note, also, that LDAPv2 servers, such as those OpenLDAP 1.x's slapd(8), do not provide a root DSE. Use -P 2 when LDAPv2 is desired. LDAPv2 servers also do not support SASL binds, so you will need to use a "simple" bind instead.
-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: 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).
+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).
+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)
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).
+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.
+
+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
ldapsearch(1) and other tools will return
- ldap_start_tls: Operations error (1)
- additional info: TLS already started
+> 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".
+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).
+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.
+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.
+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.
+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.
+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.
+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
+> 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
+> 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:
-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"
-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).
-Set that environment variable on the slapd start script (Red Hat users might find /etc/sysconfig/ldap a perfect place).
-jsanchez@openldap.org, hyc@openldap.org
-This only works if you are using MIT kerberos. It doesn't work with Heimdal, for instance.
-andreas@conectiva.com.br
-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
+This only works if you are using MIT kerberos. It doesn't work with Heimdal,
+for instance.
- keytab: /path/to/file
+
+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.
-hyc@openldap.org
+
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.
+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.
+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.2.13/tests'
- make[2]: Entering directory `/ldap_files/openldap-2.2.13/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_bind: 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.2.13/tests'
- make[1]: *** [test] Error 2
- make[1]: Leaving directory `/ldap_files/openldap-2.2.13/tests'
- make: *** [test] Error 2
+> 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
indicate that slapd didn't start at all.
-For OpenLDAP 2.2 and later, 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.
+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).
+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.
+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>.
-ando@sys-net.it
+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 Etch.
-I don't really know how the wrong permission went into place, but I suspect it has something to do with slapd's starting, no database existing (I had deleted it to get a new, fresh one), and slapd creating one before chroot.
-After a bug report, some insightful feedback, and some amount of testing, i found out that the 'wrong ownership of new files' problem is not with slapd but with slapadd. This happens when one initially populates the Directory.
-Oh, and the right switch of chown is '-R', not '-r'.
-My God! What a mess! The right command to correct this problem is: chown -R /var/lib/ldap
+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
+
-pedrorandrade@gmail.com
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)
+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.
-It was my case and that was the solution I did and it worked :) Hope this gives you some information.
--- Le Trung Kien
+
+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