Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by hyc＠symas.com
online(a)mark.ziesemer.com wrote:
> Full_Name: Mark A. Ziesemer
> Version: 2.4.21
> OS: Ubuntu Linux 10.04
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d)
>
>
> Many "connection_read(): no connection!" warnings are written to /var/log/debug
> and /var/log/syslog by slapd. As stated at
> http://www.openldap.org/lists/openldap-software/200811/msg00079.html , this is
> apparently not a problem with slapd, but a client that is disconnecting without
> first unbinding.
This also happens when the connection manager queues up a thread to handle a
"socket is readable" event on a socket that's in the process of closing.
Pretty much unavoidable, when a lot of threads are active. I don't see this as
a high enough priority to warrant fixing.
> This appears to be an issue with the libldap client library provided by OpenLDAP
> itself (2.4.21), and not the slapd daemon.
>
> Issue is reproducible even by just using "ldapsearch -H ldapi:///", but only if
> a bind DN is specified (-D) and external authentication is not used.
>
> Running slapd with logging enabled (-d 8) shows the following 3 sequences -
> ldapsearch command followed by the slapd logs. Note that the
> "connection_read(): no connection!" is only visible on the middle pair.
>
>
> $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b ""
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> No such object (32)
>
> slap_listener_activate(9):
>>>> slap_listener(ldapi:///)
> connection_get(14): got connid=1000
> connection_read(14): checking for input on id=1000
> ber_get_next
> ber_get_next: tag 0x30 len 24 contents:
> op tag 0x60, time 1273546410
> ber_get_next
> conn=1000 op=0 do_bind
> ber_scanf fmt ({imt) ber:
> ber_scanf fmt ({m) ber:
> ber_scanf fmt (m) ber:
> ber_scanf fmt (}}) ber:
>>>> dnPrettyNormal:<>
> <<< dnPrettyNormal:<>,<>
> do_bind: dn () SASL mech EXTERNAL
> ==>slap_sasl2dn: converting SASL name
> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN
> <==slap_sasl2dn: Converted SASL name to<nothing>
> SASL Authorize [conn=1000]: proxy authorization allowed authzDN=""
> send_ldap_sasl: err=0 len=-1
> do_bind: SASL/EXTERNAL bind:
> dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" sasl_ssf=0
> send_ldap_response: msgid=1 tag=97 err=0
> ber_flush2: 14 bytes to sd 14
> <== slap_sasl_bind: rc=0
> connection_get(14): got connid=1000
> connection_read(14): checking for input on id=1000
> ber_get_next
> ber_get_next: tag 0x30 len 37 contents:
> op tag 0x63, time 1273546410
> ber_get_next
> conn=1000 op=1 do_search
> ber_scanf fmt ({miiiib) ber:
>>>> dnPrettyNormal:<>
> <<< dnPrettyNormal:<>,<>
> ber_scanf fmt (m) ber:
> ber_scanf fmt ({M}}) ber:
> send_ldap_result: conn=1000 op=1 p=3
> send_ldap_response: msgid=2 tag=101 err=32
> ber_flush2: 14 bytes to sd 14
> connection_get(14): got connid=1000
> connection_read(14): checking for input on id=1000
> ber_get_next
> ber_get_next: tag 0x30 len 5 contents:
> op tag 0x42, time 1273546410
> ber_get_next
> conn=1000 op=2 do_unbind
> connection_close: conn=1000 sd=14
>
> $ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W
> Enter LDAP Password:
> ldap_bind: Invalid credentials (49)
>
> slap_listener_activate(9):
>>>> slap_listener(ldapi:///)
> connection_get(14): got connid=1001
> connection_read(14): checking for input on id=1001
> ber_get_next
> ber_get_next: tag 0x30 len 44 contents:
> op tag 0x60, time 1273546420
> ber_get_next
> conn=1001 op=0 do_bind
> ber_scanf fmt ({imt) ber:
> ber_scanf fmt (m}) ber:
>>>> dnPrettyNormal:<cn=admin,dc=example,dc=com>
> <<< dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com>
> do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128
> send_ldap_result: conn=1001 op=0 p=3
> send_ldap_response: msgid=1 tag=97 err=49
> ber_flush2: 14 bytes to sd 14
> connection_get(14): got connid=1001
> connection_read(14): checking for input on id=1001
> ber_get_next
> ber_get_next on fd 14 failed errno=0 (Success)
> connection_close: conn=1001 sd=14
> connection_read(14): no connection!
> connection_read(14): no connection!
>
> $ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W
> Enter LDAP Password:
> ldap_bind: Invalid credentials (49)
>
> slap_listener_activate(8):
>>>> slap_listener(ldap:///)
> connection_get(14): got connid=1002
> connection_read(14): checking for input on id=1002
> ber_get_next
> ber_get_next: tag 0x30 len 44 contents:
> op tag 0x60, time 1273546425
> ber_get_next
> conn=1002 op=0 do_bind
> ber_scanf fmt ({imt) ber:
> ber_scanf fmt (m}) ber:
>>>> dnPrettyNormal:<cn=admin,dc=example,dc=com>
> <<< dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com>
> do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128
> send_ldap_result: conn=1002 op=0 p=3
> send_ldap_response: msgid=1 tag=97 err=49
> ber_flush2: 14 bytes to sd 14
> connection_get(14): got connid=1002
> connection_read(14): checking for input on id=1002
> ber_get_next
> ber_get_next on fd 14 failed errno=0 (Success)
> connection_close: conn=1002 sd=14
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 4 months
Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig666A26622E67D44DE6AFFA9C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I see someone has tagged this as unreproducable in head/re24.=20
Ok.... Are you saying that 2.4.23 will not have this bug or that I did
something wrong in compiling 2.4.22????
--=20
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
--------------enig666A26622E67D44DE6AFFA9C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJL6qe8AAoJEK5S4SsZ5NvSFWcQAJJ3SvQyoD+Te4dvxJghyF44
FlOv9y6hi9vWw6fHcPJlvKBY6ZCgJoq7QeWjYXhYCk8643Yq7HRA0q3TtADwRw08
8UObJjrNoABII3QHuta7wQWNC6xKoGRUd17hzTDTZAv2AH8lMYRQPjpUKNOXAE1G
gaVOcIEM5ZHTX3y1uusu5xUbEVc/t8YlDRMIzDBukyLJaPO+/Aqy+adhpEkdULV3
1K3AlcrQDZWiD6TeWd1xIPGtrNaW1poHKIDa7ziU75D/8GQdP4FIDxwb83wQUbwi
5ZjYD0jjtoRqSvaprRL5GUPrq/s9E5ccqlPsjaVUoalHc3/VoMMpFWYewE2P/b5e
R89U9kHKkimFOUROyC4gS/cI9SiNhL0L9TOryUAE4JUG1PEGiAHEYoxxRQj8Cmk0
7OcVTNLS5Jtyx3MRCqds2CSfNL71rXJxJok6n/1OlZvkx4E7GlVXWxmWs7o9uL5P
GsYHlbTiWH08NoEb5cejOekALV6p8OY8gXLYSvxslc0p4a5HTAQI6ozwMhAY1JNS
0hZAG7cOTsBcmoNsF1Vf2DQbkZ68je6N/Hz75QfBJgzkFvd/kqadpIwu3yCljCEo
eZal5tkC5CcmcPNOIndxPgyMrafX7CogSvZ80cPGlwWd8rBL7rAccBO7JjGhf9dM
9X57ftTkOpZzsi1/oA+q
=sb/D
-----END PGP SIGNATURE-----
--------------enig666A26622E67D44DE6AFFA9C--
13 years, 4 months
(ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by online＠mark.ziesemer.com
Full_Name: Mark A. Ziesemer
Version: 2.4.21
OS: Ubuntu Linux 10.04
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d)
Many "connection_read(): no connection!" warnings are written to /var/log/debug
and /var/log/syslog by slapd. As stated at
http://www.openldap.org/lists/openldap-software/200811/msg00079.html , this is
apparently not a problem with slapd, but a client that is disconnecting without
first unbinding.
This appears to be an issue with the libldap client library provided by OpenLDAP
itself (2.4.21), and not the slapd daemon.
Issue is reproducible even by just using "ldapsearch -H ldapi:///", but only if
a bind DN is specified (-D) and external authentication is not used.
Running slapd with logging enabled (-d 8) shows the following 3 sequences -
ldapsearch command followed by the slapd logs. Note that the
"connection_read(): no connection!" is only visible on the middle pair.
$ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b ""
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
No such object (32)
slap_listener_activate(9):
>>> slap_listener(ldapi:///)
connection_get(14): got connid=1000
connection_read(14): checking for input on id=1000
ber_get_next
ber_get_next: tag 0x30 len 24 contents:
op tag 0x60, time 1273546410
ber_get_next
conn=1000 op=0 do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt ({m) ber:
ber_scanf fmt (m) ber:
ber_scanf fmt (}}) ber:
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
do_bind: dn () SASL mech EXTERNAL
==>slap_sasl2dn: converting SASL name
gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN
<==slap_sasl2dn: Converted SASL name to <nothing>
SASL Authorize [conn=1000]: proxy authorization allowed authzDN=""
send_ldap_sasl: err=0 len=-1
do_bind: SASL/EXTERNAL bind:
dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" sasl_ssf=0
send_ldap_response: msgid=1 tag=97 err=0
ber_flush2: 14 bytes to sd 14
<== slap_sasl_bind: rc=0
connection_get(14): got connid=1000
connection_read(14): checking for input on id=1000
ber_get_next
ber_get_next: tag 0x30 len 37 contents:
op tag 0x63, time 1273546410
ber_get_next
conn=1000 op=1 do_search
ber_scanf fmt ({miiiib) ber:
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
ber_scanf fmt (m) ber:
ber_scanf fmt ({M}}) ber:
send_ldap_result: conn=1000 op=1 p=3
send_ldap_response: msgid=2 tag=101 err=32
ber_flush2: 14 bytes to sd 14
connection_get(14): got connid=1000
connection_read(14): checking for input on id=1000
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
op tag 0x42, time 1273546410
ber_get_next
conn=1000 op=2 do_unbind
connection_close: conn=1000 sd=14
$ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
slap_listener_activate(9):
>>> slap_listener(ldapi:///)
connection_get(14): got connid=1001
connection_read(14): checking for input on id=1001
ber_get_next
ber_get_next: tag 0x30 len 44 contents:
op tag 0x60, time 1273546420
ber_get_next
conn=1001 op=0 do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt (m}) ber:
>>> dnPrettyNormal: <cn=admin,dc=example,dc=com>
<<< dnPrettyNormal: <cn=admin,dc=example,dc=com>, <cn=admin,dc=example,dc=com>
do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128
send_ldap_result: conn=1001 op=0 p=3
send_ldap_response: msgid=1 tag=97 err=49
ber_flush2: 14 bytes to sd 14
connection_get(14): got connid=1001
connection_read(14): checking for input on id=1001
ber_get_next
ber_get_next on fd 14 failed errno=0 (Success)
connection_close: conn=1001 sd=14
connection_read(14): no connection!
connection_read(14): no connection!
$ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
slap_listener_activate(8):
>>> slap_listener(ldap:///)
connection_get(14): got connid=1002
connection_read(14): checking for input on id=1002
ber_get_next
ber_get_next: tag 0x30 len 44 contents:
op tag 0x60, time 1273546425
ber_get_next
conn=1002 op=0 do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt (m}) ber:
>>> dnPrettyNormal: <cn=admin,dc=example,dc=com>
<<< dnPrettyNormal: <cn=admin,dc=example,dc=com>, <cn=admin,dc=example,dc=com>
do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128
send_ldap_result: conn=1002 op=0 p=3
send_ldap_response: msgid=1 tag=97 err=49
ber_flush2: 14 bytes to sd 14
connection_get(14): got connid=1002
connection_read(14): checking for input on id=1002
ber_get_next
ber_get_next on fd 14 failed errno=0 (Success)
connection_close: conn=1002 sd=14
13 years, 4 months
(ITS#6546) Default olcRootDN of "cn=config" should be documented
by bugs＠mark.ziesemer.com
Full_Name: Mark A. Ziesemer
Version: 2.4.21
OS: Ubuntu Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2001:470:1f11:3ae:4d06:cdd1:50ce:9c64)
While using the "cn=config" configuration, I found that "cn=config" is also the
default olcRootDN. By just configuring a olcRootPW , login to the config
database is possible using "cn=config" and the configured olcRootPW. This
default should be documented in the admin guide, etc.
IRC user hyc on #openldap mentioned "it's been the default since 2005", but "I
can't find the reference either, perhaps we lost it."
13 years, 4 months
Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu
On 5/6/10 3:18 PM, Quanah Gibson-Mount wrote:
> Can you please show the contents of the accesslog databsae for this
> change?
dn: reqStart=20100506114012.000002Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20100506114012.000002Z
reqEnd: 20100506114012.000003Z
reqType: modify
reqSession: 1006
reqAuthzID: cn=manager,dc=uvm,dc=edu
reqDN: uid=fcswasey,ou=People,dc=uvm,dc=edu
reqResult: 0
reqMod: sn:= Swasey
reqMod: sn:= Swasey
reqMod: entryCSN:= 20100506114012.200297Z#000000#000#000000
reqMod: modifiersName:= cn=manager,dc=uvm,dc=edu
reqMod: modifyTimestamp:= 20100506114012Z
entryUUID: 7ba18504-6f3b-450a-8420-a101ba6b76c5
creatorsName: cn=accesslog
createTimestamp: 20100506114012Z
entryCSN: 20100506114012.200297Z#000000#000#000000
modifiersName: cn=accesslog
modifyTimestamp: 20100506114012Z
entryDN: reqStart=20100506114012.000002Z,cn=accesslog
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
13 years, 4 months
Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by quanah＠zimbra.com
--On Wednesday, May 05, 2010 5:37 PM +0000 Frank.Swasey(a)uvm.edu wrote:
> Full_Name: Francis Swasey
> Version: 2.4.22
> OS: Red Hat Enterprise Linux 5 update 5 64-bit
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (132.198.107.64)
>
>
> Platform: Red Hat Enterprise Linux 5, update 5, 64-bit
> OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl.
>
> The following modify ldif successfully applies to the master:
>
> dn: uid=fcswasey,ou=People,dc=uvm,dc=edu
> changetype: modify
> replace: sn
> sn: Swasey
> -
> replace: sn
> sn: Swasey
> -
>
> syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more
> than once)
Can you please show the contents of the accesslog databsae for this change?
Thanks,
Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
13 years, 4 months
(ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu
Full_Name: Francis Swasey
Version: 2.4.22
OS: Red Hat Enterprise Linux 5 update 5 64-bit
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (132.198.107.64)
Platform: Red Hat Enterprise Linux 5, update 5, 64-bit
OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl.
The following modify ldif successfully applies to the master:
dn: uid=fcswasey,ou=People,dc=uvm,dc=edu
changetype: modify
replace: sn
sn: Swasey
-
replace: sn
sn: Swasey
-
In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn"
attribute is presented twice. In OpenLDAP 2.4 -- it works, but the
delta-syncrepl replica pukes on it with this error:
syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more
than once)
13 years, 4 months
Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com
I made an important discovery this morning (with a fresh set of eyes...): without Pierangelo's patch, chaining does
*NOT* work, as originally stated. So, the patch does fix the broken test that started this ITS, making it both valid
and absolutely necessary, but alas, the functionality of the chaining configuration is the same with both the patched
and unpatched package: the DN is not being passed through, so the automatic chasing of the referral does not work.
Here is an example with ldapvi:
### Command issued on slave to change one attribute of user uid=ryans,ou=Users,dc=example,dc=com
ryans@slave:~# ldapvi --ldap-conf --starttls -h localhost --bind=simple -D cn=admin,dc=example,dc=com -w `cat
/etc/ldap.secret` --discover
159 entries read
add: 0, rename: 0, modify: 1, delete: 0
Action? [yYqQvVebB*rsf+?] y
Received referral to ldap://ldapmaster.example.com/uid=ryans,ou=Users,dc=example,dc=com.
You are not logged in to ldap://ldapmaster.example.com:389 yet.
Type '!' or 'y' to do so.
Rebind? [y!nB*qQ?]
### Logs on slave generated by ldapvi command
May 5 10:27:04 slave slapd[30408]: conn=44 fd=41 ACCEPT from IP=127.0.0.1:34118 (IP=0.0.0.0:389)
May 5 10:27:04 slave slapd[30408]: conn=44 op=0 EXT oid=1.3.6.1.4.1.1466.20037
May 5 10:27:04 slave slapd[30408]: conn=44 op=0 STARTTLS
May 5 10:27:04 slave slapd[30408]: conn=44 op=0 RESULT oid= err=0 text=
May 5 10:27:04 slave slapd[30408]: conn=44 fd=41 TLS established tls_ssf=128 ssf=128
May 5 10:27:04 slave slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128
May 5 10:27:04 slave slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0
May 5 10:27:04 slave slapd[30408]: conn=44 op=1 RESULT tag=97 err=0 text=
May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SRCH attr=+ *
May 5 10:27:04 slave slapd[30408]: conn=44 op=2 ENTRY dn=""
May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=admin,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="ou=users,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="ou=groups,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="uid=xxxxx,ou=users,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="uid=ryans,ou=users,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="uid=xxxxx,ou=users,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=xxxxx,ou=groups,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=ryans,ou=groups,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=xxxxxx,ou=groups,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101 err=0 nentries=159 text=
May 5 10:27:22 slave slapd[30408]: conn=44 op=4 MOD dn="uid=ryans,ou=Users,dc=example,dc=com"
May 5 10:27:22 slave slapd[30408]: conn=44 op=4 MOD attr=displayColor
May 5 10:27:22 slave slapd[30408]: conn=44 op=4 RESULT tag=103 err=10 text=
The referral is generated (err=10), and sent to the master, and here's what the logs there look like:
### Logs on master generated by referral
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 fd=273 ACCEPT from IP=10.0.1.196:43376 (IP=0.0.0.0:389)
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=0 BIND dn="" method=128
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0 text=
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com"
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 MOD attr=displayColor
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8 text=modifications require authentication
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=2 UNBIND
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 fd=273 closed
May 5 10:43:04 ldap1 slapd[8794]: conn=402476 fd=273 ACCEPT from IP=10.0.1.196:43377 (IP=0.0.0.0:389)
As you can see, the DN is empty. It might be worth mentioning that I have tried the olcDbURI with dotted-quads,
hostnames, and with and without quotes, and the value portions of the attr=value pairs in the olcDbIDAssertBind
attribute with and without quotes, to no avail, though I did not expect it to. I have also tried with and without TLS
(my configuration supports both) in the chaining configuration, and explicitly with olcDbChaseReferrals set to TRUE,
though that should be the default. I've also tried with and without proxy authz (authzTo/authzFrom) in a vain attempt
to get this working, as is mentioned above in this ITS (because it is referenced in the Admin Guide section on
chaining), but that too failed.
However, most of this would seem unnecessary since test022-ppolicy does almost none of them, although that test was
recently patched to detect the bug fixed by Pierangelo's patch so it may not be an ironclad example. But since there's
no other officially documented example of setting up chaining with cn=config, it's really all the community has to go
on. Again, for reference, the most recent configuration used is provided below:
1 cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb.la
olcModuleLoad: {1}autogroup.la
olcModuleLoad: {2}back_ldap.la
20 olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
21 olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbURI: "ldap://10.1.1.164:389"
olcDbStartTLS: start
olcDbIDAssertBind: bindmethod="simple" binddn="cn=admin,dc=example,dc=com" credentials="secret" mode="self"
olcDbChaseReferrals: TRUE
If you want an example using an officially distributed tool, or one that doesn't handle referrals, here it is, using
ldappasswd:
### Command issued on slave
ryans@slave:~# ldappasswd -h localhost uid=ryans,ou=Users,dc=example,dc=com
New password:
Re-enter new password:
Enter LDAP Password:
Result: Strong(er) authentication required (8)
Additional info: only authenticated users may change passwords
### Slave side logs using ldappasswd
May 5 10:30:47 slave slapd[30408]: conn=47 fd=41 ACCEPT from IP=127.0.0.1:32947 (IP=0.0.0.0:389)
May 5 10:30:47 slave slapd[30408]: conn=47 op=0 EXT oid=1.3.6.1.4.1.1466.20037
May 5 10:30:47 slave slapd[30408]: conn=47 op=0 STARTTLS
May 5 10:30:47 slave slapd[30408]: conn=47 op=0 RESULT oid= err=0 text=
May 5 10:30:47 slave slapd[30408]: conn=47 fd=41 TLS established tls_ssf=128 ssf=128
May 5 10:30:47 slave slapd[30408]: conn=47 op=1 BIND dn="uid=ryans,ou=Users,dc=example,dc=com" method=128
May 5 10:30:47 slave slapd[30408]: conn=47 op=1 BIND dn="uid=ryans,ou=Users,dc=example,dc=com" mech=SIMPLE ssf=0
May 5 10:30:47 slave slapd[30408]: conn=47 op=1 RESULT tag=97 err=0 text=
May 5 10:30:47 slave slapd[30408]: conn=47 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1
May 5 10:30:47 slave slapd[30408]: conn=47 op=2 PASSMOD id="uid=ryans,ou=Users,dc=example,dc=com" new
May 5 10:30:47 slave slapd[30408]: conn=47 op=2 RESULT oid= err=8 text=only authenticated users may change passwords
13 years, 4 months
