[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Syncrepl - ldap_bind: Invalid credentials error
Further research in the archives reveals that this is not an error, it just means that it was looking for the index of a value that doesn't exist in the DB.
http://www.openldap.org/lists/openldap-technical/201005/msg00011.html
I can see that the servers are talking to each other. I can see db files in the consumer's accesslog directory, but an ldap search on the consumer fails with:
ldap_search: No such object
Further logging reveals it can't find the main suffix laid out in slapd.conf dc=city,dc=ac,dc=uk
=> bdb_dn2id("dc=city,dc=ac,dc=uk")
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988)
I thought this would be automatically added from the conf file and also contained in the data replicated from the consumer. Can someone point out my (probably obvious) mistake?
Thanks very much,
Mark
-----Original Message-----
From: Gocher, Mark
Sent: 02 June 2010 14:08
To: openldap-technical@openldap.org
Subject: RE: Syncrepl - ldap_bind: Invalid credentials error
Thanks very much for your response. I found that I had created replicator as a uid on one server and a cn on the other. I then changed my dn password to SSHA and the consumer can now talk to the provider.
I found, however, that no content was being provided to the consumer. I'm not sure if the error was already there or was caused by something I just "fixed", but when I start my provider db I get this error:
daemon: select: listen=7 active_threads=0 tvp=zero
daemon: select: listen=8 active_threads=0 tvp=zero
=> hdb_search
bdb_dn2entry("cn=accesslog")
=> access_allowed: search access to "cn=accesslog" "entry" requested
<= root access granted
=> access_allowed: search access granted by manage(=mwrscxd)
search_candidates: base="cn=accesslog" (0x00000002) scope=1
=> hdb_dn2idl("cn=accesslog")
=> bdb_filter_candidates
AND
=> bdb_list_candidates 0xa0
=> bdb_filter_candidates
OR
=> bdb_list_candidates 0xa1
=> bdb_filter_candidates
EQUALITY
=> bdb_equality_candidates (objectClass)
=> key_read
bdb_idl_fetch_key: [b49d1940]
<= bdb_index_read: failed (-30988)
<= bdb_equality_candidates: id=0, first=0, last=0
<= bdb_filter_candidates: id=0 first=0 last=0
=> bdb_filter_candidates
LE
=> bdb_inequality_candidates (reqStart)
=> key_read
bdb_idl_fetch_key:
<= bdb_index_read: failed (-30988)
<= bdb_inequality_candidates: id=0, first=0, last=0
<= bdb_filter_candidates: id=0 first=0 last=0
<= bdb_list_candidates: id=0 first=0 last=0
<= bdb_filter_candidates: id=0 first=0 last=0
<= bdb_list_candidates: id=0 first=0 last=0
<= bdb_filter_candidates: id=0 first=0 last=0
bdb_search_candidates: id=0 first=0 last=0
hdb_search: no candidates
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=0 matched="" text=""
I have re-indexed and performed a db_recovery and can see no errors in the logs. I can perform ldapsearches on my db successfully. I'm at a bit of a loss as to what the cause or repair of the index read failure might be. Any help would be very gratefully received.
Reindex and db_recovery output snippet:
./slapindex -f /usr/local/openldap-2.4.22/servers/slapd/slapd.conf -v -d 1
slapindex init: initiated tool.
slap_sasl_init: initialized!
bdb_back_initialize: initialize BDB backend
bdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008)
hdb_back_initialize: initialize HDB backend
hdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008)
==> translucent_initialize
bdb_db_init: Initializing BDB database
>>> dnPrettyNormal: <dc=city,dc=ac,dc=uk>
<<< dnPrettyNormal: <dc=city,dc=ac,dc=uk>, <dc=city,dc=ac,dc=uk>
>>> dnPrettyNormal: <cn=DSAmgr,dc=city,dc=ac,dc=uk>
<<< dnPrettyNormal: <cn=DSAmgr,dc=city,dc=ac,dc=uk>, <cn=dsamgr,dc=city,dc=ac,dc=uk>
>>> dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
<<< dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
>>> dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
<<< dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
hdb_db_init: Initializing HDB database
����� back-bdb/back-hdb monitor: "olmBDBAttributes" previously defined "1.3.6.1.4.1.4203.666.1.55.0.1.1"
����� back-bdb/back-hdb monitor: "olmBDBObjectClasses" previously defined "1.3.6.1.4.1.4203.666.3.16.0.1.1"
>>> dnPrettyNormal: <cn=accesslog>
<<< dnPrettyNormal: <cn=accesslog>, <cn=accesslog>
>>> dnPrettyNormal: <cn=accesslog>
<<< dnPrettyNormal: <cn=accesslog>, <cn=accesslog>
>>> dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
<<< dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
>>> dnPrettyNormal: <cn=accesslog>
<<< dnPrettyNormal: <cn=accesslog>, <cn=accesslog>
>>> dnPrettyNormal: <cn=Monitor>
<<< dnPrettyNormal: <cn=Monitor>, <cn=monitor>
>>> dnNormalize: <cn=Subschema>
<<< dnNormalize: <cn=subschema>
matching_rule_use_init
----snipped to end of output-----
<= key_change 0
=> key_change(ADD,c)
<= key_change 0
<= index_entry_add( 12, "cn=DSAmgr,dc=city,dc=ac,dc=uk" ) success
slapindex shutdown: initiated
====> bdb_cache_release_all
slapindex destroy: freeing system resources.
-bash-3.00# /usr/local/BerkeleyDB.4.7/bin/db_recover -vFinding last valid log LSN: file: 1 offset 28
Regards,
Mark
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: 01 June 2010 17:20
To: Gocher, Mark; openldap-technical@openldap.org
Subject: Re: Syncrepl - ldap_bind: Invalid credentials error
--On Tuesday, June 01, 2010 9:51 AM +0100 "Gocher, Mark"
<Mark.Gocher.1@city.ac.uk> wrote:
>
>
> I'm receiving the following error on my consumer, using logging -d
> stats + args + trace + sync 2> /var/log/ldap
>
>
>
> @(#) $OpenLDAP: slapd 2.4.22 (May 21 2010 12:10:42) $
>
> @cambridge:/usr/local/openldap-2.4.22/servers/slapd
>
> slapd starting
>
> slap_client_connect: URI=ldap://oxford.unix1.city.ac.uk:389
> DN="cn=replicator,dc=city,dc=ac,dc=uk" ldap_sasl_bind_s failed (49)
Error 49 says that an invalid password was provided (or that the DN isn't
right).
> I have created the uid for replicator and repeated this search with the
> 'access to attrs=userPassword' line commented out on the provider to
> ensure that the userPassword for replicator is clear text 'secret'. I
> can also perform this search from the consumer successfully.
Your provider conf file is a mess. It has a mix of global and database
specific directives peppered through it. You load modules after using
them, etc. I would spend some time cleaning up your provider's
configuration (and possible the replica one too, I didn't look at it
closely).
> Provider ldap.conf:
>
> database bdb
>
> suffix "dc=city,dc=ac,dc=uk"
>
> rootdn "cn=DSAmgr,dc=city,dc=ac,dc=uk"
>
> rootpw {CRYPT}aZmvWMwFgg.vk
Crypt is non portable. You should use SSHA or similar.