Re: TLS very strange behaviour
by Rich Megginson
On 10/14/2011 01:48 AM, Olivier Guillard wrote:
> Hi Rich
>
> as far as I remember, when I used this version :
> openldap-servers-2.4.23-15.el6_1.1.x86_64
>
> I could use external mecanism in syncrepl and was
> able to present the client certificate without asking for
> the server one.
>
> My syncrepl sections looked like this :
>
> syncrepl rid=121
> provider=ldap://ldap2.example.fr
> searchbase="dc=example,dc=fr"
> schemachecking=on
> type=refreshOnly
> interval=00:00:00:05
> retry="10 +"
> bindmethod=sasl
> saslmech=external
> tls_cert=/etc/openldap/cacerts/syncrepl.crt
> tls_key=/etc/openldap/cacerts/syncrepl.key
>
> And that worked. BTW, I'm not sure that his should have
> worked since I think normaly the protocole indicates that
> the client should check the server cert before sending its.
Yes, that's odd.
> Anyway that worked (-:
>
> With openldap-servers-2.4.23-15.el6_1.3.x86_64, I'm not
> able to use the external mecanism anymore if I don't add
> explicitely the following directives in syncrepl: "starttls=yes",
> "tls_cacert=.../cacerts/CA.crt" and "tls_reqcert=allow/try/demand"
I don't think it ever should have worked without at least specifying
starttls=yes (and assuming that didn't fallback - I think starttls=yes
is misleading, as it will just silently fallback to plain LDAP if it
doesn't establish a TLS connection - everything will seem to be working,
but unless you have set up the server to require a TLS connection, it
will just work and you won't know that it is not using TLS). I
recommend always using starttls=critical to make sure your client will
only work if TLS was successfully established.
> That works in master/slave mode, that doesn't in multimaster.
>
> Now last thing : I've never been able to make work syncrepl
> with : "starttls=yes", "tls_cacert=.../cacerts/CA.crt" and
> "tls_reqcert=allow/try/demand" in multimaster N-WAY mode
> anyway (nor now, nor before).
>
> I only made it work in master/salve and that weither using
> simple or sasl bindmethod.
>
> So the problem is not linked to sasl in my view but with
> tls in synchrepl (may be both slapd try to use the first
> TLS session opened to exchange in both direction in
> multimaster, a shared variable mixing information about
> certicates ? something like that).
Would it be possible for you to get it working with simple
binddn/password auth first, to see if that is working? Then we could at
least narrow down the problem to being related to sasl/external auth.
> I just realise that I had a core dump collected by abrtd (not
> sure if that could help nor how to use it, I'm not familiar with
> this kind of debugging) : let me know if that file could help
> (or if I could try to run any gdb command using that file).
Yes indeed that would be very helpful.
https://bugzilla.redhat.com/show_bug.cgi?id=701678#c6 has some
information about handling openldap core dumps on RHEL6
> Best,
>
> ---
> Olivier
>
> On Wed, Oct 12, 2011 at 10:25 PM, Rich Megginson
> <rich.megginson(a)gmail.com> wrote:
>> On 10/11/2011 02:38 AM, Olivier Guillard wrote:
>>> Thanks Rich, see below :
>>>
>>>> -12272 is SSL_ERROR_BAD_MAC_ALERT and -12273 is SSL_ERROR_BAD_MAC_READ
>>>> I've seen this when the client and server do not have the same SSL
>>>> certificate signature algorithm support. Is everything running on RHEL6
>>>> and/or Fedora 14 and later?
>>> [root@ldap2 ~]# cat /etc/issue
>>> Red Hat Enterprise Linux Server release 6.1 (Santiago)
>>> Kernel \r on an \m
>>>
>>> [root@ldap2 ~]# rpm -qa | grep -i openldap
>>> openldap-2.4.23-15.el6_1.3.x86_64
>>> openldap-servers-2.4.23-15.el6_1.3.x86_64
>>> openldap-debuginfo-2.4.23-15.el6_1.1.x86_64
>>> openldap-clients-2.4.23-15.el6_1.3.x86_64
>>>
>>> [root@ldap1 ~]# cat /etc/issue
>>> Red Hat Enterprise Linux Server release 6.1 (Santiago)
>>> Kernel \r on an \m
>>>
>>> [root@ldap1 ~]# rpm -qa | grep -i openldap
>>> openldap-debuginfo-2.4.23-15.el6_1.1.x86_64
>>> openldap-clients-2.4.23-15.el6_1.3.x86_64
>>> openldap-2.4.23-15.el6_1.3.x86_64
>>> openldap-servers-2.4.23-15.el6_1.3.x86_64
>>>
>>> [root@ldap2 cacerts]# rpm -qa | grep openssl
>>> openssl-1.0.0-10.el6_1.4.x86_64
>>>
>>> [root@ldap1 ldap1]# rpm -qa | grep openssl
>>> openssl-1.0.0-10.el6_1.4.x86_64
>>>
>>> Not sure if that made a difference but I "yum-updated"
>>> on last friday and openldap servers version passed :
>>>
>>> from
>>> openldap-servers-2.4.23-15.el6_1.1.x86_64
>>> to
>>> openldap-servers-2.4.23-15.el6_1.3.x86_64
>> Was it working before you yum updated?
>>> ---
>>> Olivier
>>>
>>> On Mon, Oct 10, 2011 at 9:54 PM, Rich Megginson
>>> <rich.megginson(a)gmail.com> wrote:
>>>
>>>>> here is what I get :
>>>>>
>>>>> ldap1 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
>>>>> ...
>>>>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>>>>> -12273
>>>>> TLS: can't accept: TLS error -12273:Unknown code ___P 15.
>>>>> TLS: error: connect - force handshake failure: errno 0 - moznss error
>>>>> -12272
>>>>> TLS: can't connect: TLS error -12272:Unknown code ___P 16.
>>>>> slap_client_connect: URI=ldap://ldap2.example.fr Warning,
>>>>> ldap_start_tls failed (-11)
>>>>> slap_client_connect: URI=ldap://ldap2.example.fr
>>>>> ldap_sasl_interactive_bind_s failed (-6)
>>>>> do_syncrepl: rid=121 rc -6 retrying
>>>>>
>>>>> ldap2 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
>>>>> ...
>>>>> TLS: error: connect - force handshake failure: errno 0 - moznss error
>>>>> -12272
>>>>> TLS: can't connect: TLS error -12272:Unknown code ___P 16.
>>>>> slap_client_connect: URI=ldap://ldap1.eaxample.fr:389 Warning,
>>>>> ldap_start_tls failed (-11)
>>>>> slap_client_connect: URI=ldap://ldap1.example.fr:389
>>>>> ldap_sasl_interactive_bind_s failed (-6)
>>>>> do_syncrepl: rid=211 rc -6 retrying
>>>>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>>>>> -12273
>>>>> TLS: can't accept: TLS error -12273:Unknown code ___P 15.
>>>>>
>>>>> Any idea ?
>>
12 years, 1 month
Re: Syncrepl SSL fail
by Hugo Deprez
Hello,
On the provider I have the following settings :
TLSCACertificateFile /etc/ssl/certs/ldap-cert.pem
TLSCertificateFile /etc/ssl/certs/ldap-cert.pem
TLSCertificateKeyFile /etc/ldap/ssl/ldap-key.pem
but no TLSCipherSuite defined.
I added the starttls=yes on the consumer :
Syncrepl rid=003
provider=ldaps://ldap.mydomain.fr:1024/
type=refreshOnly
retry="60 10 600 +"
interval=00:00:00:10
searchbase="dc=mydomain,dc=fr"
scope=sub
schemachecking=on
bindmethod=simple
starttls=yes
tls_cert=/etc/ssl/certs/ldap-cert.pem
tls_cacert=/etc/ssl/certs/ldap-cert-ca.pem
binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
credentials=my_password
But still the same error.
Any idea ?
Hugo
On 14 October 2011 13:52, Olivier Guillard <olivier(a)guillard.nom.fr> wrote:
> Hi,
>
> Have you set up the follwing appropriately :
>
> TLSCertificateFile
> TLSCertificateKeyFile
> TLSCipherSuite
>
> On the provider ?
>
> You probably also want to set this up correctly in
> your syncrepl section :
>
> starttls=yes
> tls_cacert=/path/to/certificate
>
> I suspect better if TLS_CACERT is also properly
> set up in both ldap server slapd config.
>
> ---
> Olivier
>
> On Thu, Oct 13, 2011 at 6:38 PM, Hugo Deprez <hugo.deprez(a)gmail.com> wrote:
>> Dear community,
>>
>> I setup a syncrepl between my master openldap server and a consumer.
>>
>> I am trying to use SSL for this syncrepl
>> I got the following error in the log when I start slapd on the consumer :
>>
>> Oct 13 17:04:59 server slapd[16905]: slapd starting
>> Oct 13 17:04:59 server slapd[16905]: slap_client_connect:
>> URI=ldaps://ldap.mydomain.fr:1024/
>> DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s
>> failed (-1)
>> Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1
>> retrying (9 retries left)
>>
>>
>> I don't understand why it is failing as a single ldapsearch from the
>> same server with the syncrepl user is working.
>>
>> here is my syncrepl configuration :
>>
>> Syncrepl rid=003
>> provider=ldaps://ldap.mydomain.fr:1024/
>> type=refreshOnly
>> retry="60 10 600 +"
>> interval=00:00:00:10
>> searchbase="dc=mydomain,dc=fr"
>> scope=sub
>> schemachecking=on
>> bindmethod=simple
>> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
>> credentials=my_password
>>
>>
>> Any idea ?
>>
>> Regards,
>>
>> Hugo
>>
>>
>
12 years, 1 month
Re: Syncrepl SSL fail
by Hugo Deprez
Hello,
I use the following ldapsearch command :
ldapsearch -H ldaps://ldap.mydomain.fr:1024 -x -W -D
"cn=syncrepluser,o=others,dc=mydomain,dc=fr"
I did configure TLS cert file before syncrepl configuration :
TLSCACertificateFile /etc/ssl/certs/ldap-replic-cert.pem
TLSCertificateFile /etc/ssl/certs/ldap-replic-cert.pem
TLSCertificateKeyFile /etc/ssl/certs/ldap-replic-cert.pem
But those certificate are for the ldap consumer if I'm not wrong.
I am currently trying the following configuration thanks to your information :
Syncrepl rid=003
provider=ldaps://ldap.mydomain.fr:1024/
type=refreshOnly
retry="60 10 600 +"
interval=00:00:00:10
searchbase="dc=mydomain,dc=fr"
scope=sub
schemachecking=on
bindmethod=simple
tls_cert=/etc/ssl/certs/ldap-cert.pem
tls_cacert=/etc/ssl/certs/ldap-cert-ca.pem
binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
credentials=my_password
where tls_cert and tls_cacert provide the cert from the master server.
It seems that the replication is working but I get an other error confusing :
ct 14 12:46:53 server slapd[32470]: slap_client_connect:
URI=ldaps://ldap.mydomain.fr:1024/ TLS context initialization failed
(-1)
Oct 14 12:46:53 server slapd[32470]: do_syncrepl: rid=003 rc -1
retrying (9 retries left)
Oct 14 12:47:53 server slapd[32470]: do_syncrep2: rid=003
LDAP_RES_INTERMEDIATE - SYNC_ID_SET
Oct 14 12:47:53 server slapd[32470]: do_syncrep2: rid=003
LDAP_RES_INTERMEDIATE - SYNC_ID_SET
Oct 14 12:47:53 server slapd[32470]: do_syncrep2: rid=003
LDAP_RES_INTERMEDIATE - SYNC_ID_SET
I don't really understand the TLS context initialization failed (-1)
as my replication is working ?
Thanks for the tips.
Hugo
On 13 October 2011 19:29, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Thursday, October 13, 2011 6:38 PM +0200 Hugo Deprez
> <hugo.deprez(a)gmail.com> wrote:
>
>> Dear community,
>>
>> I setup a syncrepl between my master openldap server and a consumer.
>>
>> I am trying to use SSL for this syncrepl
>> I got the following error in the log when I start slapd on the consumer :
>>
>> Oct 13 17:04:59 server slapd[16905]: slapd starting
>> Oct 13 17:04:59 server slapd[16905]: slap_client_connect:
>> URI=ldaps://ldap.mydomain.fr:1024/
>> DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s
>> failed (-1)
>> Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1
>> retrying (9 retries left)
>>
>>
>> I don't understand why it is failing as a single ldapsearch from the
>> same server with the syncrepl user is working.
>>
>> here is my syncrepl configuration :
>>
>> Syncrepl rid=003
>> provider=ldaps://ldap.mydomain.fr:1024/
>> type=refreshOnly
>> retry="60 10 600 +"
>> interval=00:00:00:10
>> searchbase="dc=mydomain,dc=fr"
>> scope=sub
>> schemachecking=on
>> bindmethod=simple
>> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
>> credentials=my_password
>>
>>
>> Any idea ?
>
> I don't see any of the tls_* options to the syncrepl configuration here.
> Likely the syncrepl client is unable to verify the master's cert. I would
> note that using refreshOnly is ill-advised.
>
> --Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
12 years, 1 month
Re: Borked olcDatabase={1}hdb.ldif
by Jan Geep
On Thu, Oct 13, 2011 at 10:57 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> I would suggest you go and read the LDIF specification, so you can realize
> this is not a bug nor a problem.
Mea culpa, a rather naive question I guess, still cutting my teeth
with openldap. I was aware of the line spanning, but it was
I perceived as an errant space in "anonymou s" that threw me.
Looks like the ldapmodify will do after all...
12 years, 1 month
Borked olcDatabase={1}hdb.ldif
by Jan Geep
Somewhere along the way I've discovered that somehow my
olcDatabase={1}hdb.ldif is missing "olcAccess:" for samba* entries.
To fix this I wanted to update using ldapmodify and the following
ldif:
----- modify.ldif ------------
dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {0}
-
add: olcAccess
olcAccess: {0} to
attrs=userPassword,shadowLastChange,sambaPwdMustChange,sambaLMPassword,sambaPwdLastSet,sambaNTPassword
by dn="cn=admin,dc=domain,dc=tld" write by anonymous auth by self
write by * none
-
----- modify.ldif ------------
The "olcAccess: {0}...." contents all being on one line. (adding
via: ldapmodify -x -D "cn=admin,dc=domain,dc=tld" -W -f modify.ldif)
But manually looking at my current olcDatabase={1}hdb.ldif I see that
somehow the current "olcAccess: {0}" entry that I want to update has
been split into two lines, as follows:
----- oldAccess: {0} ------------
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write
by anonymou
s auth by dn="cn=admin,dc=frontline" write by * none
----- oldAccess: {0} ------------
As this is a live system at the moment, is there any way, other than
stopping slapd and manually viming olcDatabase={1}hdb.ldif to fix the
split line and add the samba* entries?
For what it's worth:
OS: Ubuntu 11.04
OpenLDAP 2.4.23
Samba: 3.5.8
t.i.a
Jan
12 years, 1 month
authentication failure: bad digest-uri: doesn't match service
by Juergen.Sprenger＠swisscom.com
Hi,
I am trying to authenticate an Oracle db user against OpenLDAP.
Porting of schema information is ok, ssl-handshake ok, sasl-bind seems ok, SASL works:
ldapwhoami -U testuser -R us.oracle.com -H ldap:/// -Y DIGEST-MD5
SASL/DIGEST-MD5 authentication started
Please enter your password:
SASL username: testuser
SASL SSF: 128
SASL data security layer installed.
dn:cn=testuser,cn=users,dc=its
Trying to authenticate the oracle-client throws a 'bad digest-uri'-error assuming
digest-uri="ldap:/us.oracle.com":
ber_dump: buf=60b898 ptr=60b8c7 end=60b9e3 len=284
0000: 00 82 01 18 04 0a 44 49 47 45 53 54 2d 4d 44 35 ......DIGEST-MD5
0010: 04 82 01 08 64 69 67 65 73 74 2d 75 72 69 3d 22 ....digest-uri="
0020: 6c 64 61 70 3a 2f 75 73 2e 6f 72 61 63 6c 65 2e ldap:/us.oracle.
0030: 63 6f 6d 22 2c 6d 61 78 62 75 66 3d 36 35 35 33 com",maxbuf=6553
0040: 36 2c 63 68 61 72 73 65 74 3d 75 74 66 2d 38 2c 6,charset=utf-8,
0050: 71 6f 70 3d 61 75 74 68 2c 75 73 65 72 6e 61 6d qop=auth,usernam
0060: 65 3d 22 63 6e 3d 6c 64 61 70 74 65 73 74 2c 63 e="cn=ldaptest,c
0070: 6e 3d 6f 72 61 63 6c 65 63 6f 6e 74 65 78 74 2c n=oraclecontext,
0080: 64 63 3d 69 74 73 22 2c 6e 6f 6e 63 65 3d 22 30 dc=its",nonce="0
0090: 2f 41 41 52 37 47 39 48 39 2f 44 72 34 56 36 32 /AAR7G9H9/Dr4V62
00a0: 6f 50 54 6c 45 48 75 36 56 72 6b 41 46 6f 33 52 oPTlEHu6VrkAFo3R
00b0: 66 31 56 30 6b 73 35 47 71 6f 3d 22 2c 63 6e 6f f1V0ks5Gqo=",cno
00c0: 6e 63 65 3d 22 38 35 33 32 33 35 45 30 44 39 38 nce="853235E0D98
00d0: 41 32 37 39 43 43 30 36 30 34 45 45 39 31 36 31 A279CC0604EE9161
00e0: 34 42 39 30 38 22 2c 6e 63 3d 30 30 30 30 30 30 4B908",nc=000000
00f0: 30 31 2c 72 65 73 70 6f 6e 73 65 3d 37 33 61 64 01,response=73ad
0100: 37 38 31 33 64 31 39 38 34 37 38 63 34 39 37 65 7813d198478c497e
0110: 64 66 30 63 31 36 61 36 61 32 34 36 df0c16a6a246
ber_scanf fmt (m) ber:
ber_dump: buf=60b898 ptr=60b8d7 end=60b9e3 len=268
0000: 00 82 01 08 64 69 67 65 73 74 2d 75 72 69 3d 22 ....digest-uri="
0010: 6c 64 61 70 3a 2f 75 73 2e 6f 72 61 63 6c 65 2e ldap:/us.oracle.
0020: 63 6f 6d 22 2c 6d 61 78 62 75 66 3d 36 35 35 33 com",maxbuf=6553
0030: 36 2c 63 68 61 72 73 65 74 3d 75 74 66 2d 38 2c 6,charset=utf-8,
0040: 71 6f 70 3d 61 75 74 68 2c 75 73 65 72 6e 61 6d qop=auth,usernam
0050: 65 3d 22 63 6e 3d 6c 64 61 70 74 65 73 74 2c 63 e="cn=ldaptest,c
0060: 6e 3d 6f 72 61 63 6c 65 63 6f 6e 74 65 78 74 2c n=oraclecontext,
0070: 64 63 3d 69 74 73 22 2c 6e 6f 6e 63 65 3d 22 30 dc=its",nonce="0
0080: 2f 41 41 52 37 47 39 48 39 2f 44 72 34 56 36 32 /AAR7G9H9/Dr4V62
0090: 6f 50 54 6c 45 48 75 36 56 72 6b 41 46 6f 33 52 oPTlEHu6VrkAFo3R
00a0: 66 31 56 30 6b 73 35 47 71 6f 3d 22 2c 63 6e 6f f1V0ks5Gqo=",cno
00b0: 6e 63 65 3d 22 38 35 33 32 33 35 45 30 44 39 38 nce="853235E0D98
00c0: 41 32 37 39 43 43 30 36 30 34 45 45 39 31 36 31 A279CC0604EE9161
00d0: 34 42 39 30 38 22 2c 6e 63 3d 30 30 30 30 30 30 4B908",nc=000000
00e0: 30 31 2c 72 65 73 70 6f 6e 73 65 3d 37 33 61 64 01,response=73ad
00f0: 37 38 31 33 64 31 39 38 34 37 38 63 34 39 37 65 7813d198478c497e
0100: 64 66 30 63 31 36 61 36 61 32 34 36 df0c16a6a246
ber_scanf fmt (}}) ber:
ber_dump: buf=60b898 ptr=60b9e3 end=60b9e3 len=0
>>> dnPrettyNormal: <cn=ldaptest,cn=oraclecontext,dc=its>
=> ldap_bv2dn(cn=ldaptest,cn=oraclecontext,dc=its,0)
<= ldap_bv2dn(cn=ldaptest,cn=oraclecontext,dc=its)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=ldaptest,cn=oraclecontext,dc=its)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=ldaptest,cn=oraclecontext,dc=its)=0
<<< dnPrettyNormal: <cn=ldaptest,cn=oraclecontext,dc=its>, <cn=ldaptest,cn=oraclecontext,dc=its>
conn=1014 op=1 BIND dn="cn=ldaptest,cn=oraclecontext,dc=its" method=163
do_bind: dn (cn=ldaptest,cn=oraclecontext,dc=its) SASL mech DIGEST-MD5
==> sasl_bind: dn="cn=ldaptest,cn=oraclecontext,dc=its" mech=<continuing> datalen=264
SASL [conn=1014] Debug: DIGEST-MD5 server step 2
SASL [conn=1014] Failure: bad digest-uri: doesn't match service
send_ldap_result: conn=1014 op=1 p=3
send_ldap_result: err=49 matched="" text="SASL(-13): authentication failure: bad digest-uri: doesn't match service"
send_ldap_response: msgid=2 tag=97 err=49
ber_flush2: 86 bytes to sd 16
0000: 30 54 02 01 02 61 4f 0a 01 31 04 00 04 48 53 41 0T...aO..1...HSA
0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent
0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure:
0030: 20 62 61 64 20 64 69 67 65 73 74 2d 75 72 69 3a bad digest-uri:
0040: 20 64 6f 65 73 6e 27 74 20 6d 61 74 63 68 20 73 doesn't match s
0050: 65 72 76 69 63 65 ervice
tls_write: want=146, written=146
0000: 17 03 00 00 18 c7 75 ac 06 20 dd 58 b7 38 55 82 ......u.. .X.8U.
0010: ab f0 ea 72 79 d0 22 ad 95 dc ab 26 d3 17 03 00 ...ry."....&....
0020: 00 70 64 23 8e ce fc 05 73 d5 16 a2 cc 62 e4 ae .pd#....s....b..
0030: ee 02 96 ff 16 3d 42 15 54 25 54 7b 60 6d 25 ef .....=B.T%T{`m%.
0040: e3 82 84 1f 42 ec 38 96 82 78 8c 09 b4 be 96 e5 ....B.8..x......
0050: b9 95 01 e0 58 f3 a4 49 a0 58 53 6d 24 8e 0a 9b ....X..I.XSm$...
0060: 8b cd 4b fd cd 0e cd 51 0b e0 89 73 c6 b6 88 2f ..K....Q...s.../
0070: 66 05 49 4a 89 0e 29 0e 53 5a 0c 0d ce 1d 8e 40 f.IJ..).SZ.....@
0080: 90 dd 9f b2 4d b4 6e 7d 2b cf a1 ed 13 96 df 1a ....M.n}+.......
0090: 44 1c D.
ldap_write: want=86, written=86
0000: 30 54 02 01 02 61 4f 0a 01 31 04 00 04 48 53 41 0T...aO..1...HSA
0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent
0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure:
0030: 20 62 61 64 20 64 69 67 65 73 74 2d 75 72 69 3a bad digest-uri:
0040: 20 64 6f 65 73 6e 27 74 20 6d 61 74 63 68 20 73 doesn't match s
0050: 65 72 76 69 63 65 ervice
conn=1014 op=1 RESULT tag=97 err=49 text=SASL(-13): authentication failure: bad digest-uri: doesn't match service
<== slap_sasl_bind: rc=49
daemon: activity on 1 descriptor
daemon: activity on: 16r
daemon: read activity on 16
daemon: select: listen=7 active_threads=0 tvp=NULL
connection_get(16)
daemon: select: listen=8 active_threads=0 tvp=NULL
connection_get(16): got connid=1014
daemon: select: listen=9 active_threads=0 tvp=NULL
connection_read(16): checking for input on id=1014
ber_get_next
daemon: select: listen=10 active_threads=0 tvp=NULL
tls_read: want=5, got=5
0000: 17 03 00 00 20 ....
tls_read: want=32, got=32
0000: 93 5b 37 05 07 4b dd 2b a9 1c 7e 70 db b4 8f c7 .[7..K.+..~p....
0010: a5 f7 d7 d0 b8 e0 17 cf b9 08 dd a2 c9 df 28 7b ..............({
ldap_read: want=8, got=7
0000: 30 05 02 01 03 42 00 0....B.
ber_get_next: tag 0x30 len 5 contents:
ber_dump: buf=5f7de0 ptr=5f7de0 end=5f7de5 len=5
0000: 02 01 03 42 00 ...B.
op tag 0x42, time 1317892029
ber_get_next
tls_read: want=5, got=5
0000: 15 03 00 00 18 .....
tls_read: want=24, got=24
0000: d7 de f4 58 8a 4e fc 6b d5 6f 93 55 ee 5e 72 cd ...X.N.k.o.U.^r.
0010: 3c 8b a2 e1 ba 87 94 5a <......Z
TLS trace: SSL3 alert read:warning:close notify
ldap_read: want=8, got=0
ber_get_next on fd 16 failed errno=0 (Error 0)
connection_read(16): input error=-2 id=1014, closing.
connection_closing: readying conn=1014 sd=16 for close
connection_close: deferring conn=1014 sd=16
daemon: activity on 1 descriptor
conn=1014 op=2 do_unbind
daemon: waked
conn=1014 op=2 UNBIND
daemon: select: listen=7 active_threads=0 tvp=NULL
daemon: select: listen=8 active_threads=0 tvp=NULL
connection_resched: attempting closing conn=1014 sd=16
connection_close: conn=1014 sd=16
daemon: select: listen=9 active_threads=0 tvp=NULL
daemon: select: listen=10 active_threads=0 tvp=NULL
daemon: removing 16
tls_write: want=29, written=29
0000: 15 03 00 00 18 1c 8a dd b1 bb 30 32 1b ca c2 a1 ..........02....
0010: 2d e8 33 fc 9e 7b 6b e4 49 cf ce f2 fb -.3..{k.I....
TLS trace: SSL3 alert write:warning:close notify
conn=1014 fd=16 closed
On the Oracle client:
SQL> connect testuser
Enter password:
ERROR:
ORA-28043: invalid bind credentials for DB-OID connection
Warning: You are no longer connected to ORACLE.
SQL>
Any suggestions how to make digest-uri match service?
Regards
Juergen
12 years, 1 month
syncrepl tls_cert file not red ?
by Olivier
I now have a new issue with TLS : certificate files are even not red and
presented to the server anymore.
I have this on server ldap2 :
syncrepl rid=211
provider=ldap://ldap1.example.fr:389
searchbase="dc=example,dc=fr"
schemachecking=on
type=refreshOnly
interval=00:00:00:05
retry="10 +"
bindmethod=sasl
saslmech=external
authcid="cn=replicator,ou=system,dc=example,dc=fr"
authzid="dn:cn=replicator,ou=system,dc=example,dc=fr"
tls_cacert=/etc/openldap/cacerts/CA.crt
tls_cert=/etc/openldap/cacerts/syncrepl.crt
tls_key=/etc/openldap/cacerts/syncrepl.key
tls_reqcert=demand
I get this as error : "ldap_sasl_interactive_bind_s failed (-6)"
and if I launch slapd through strace I see that
/etc/openldap/cacerts/syncrepl.crt
is never opened (then never presented to the server).
Note that on the server I have configured :
TLSVerifyClient demand
To be sure that the server ask for the certificate.
What have I forgotten ? Please help me to diag where is the problem.
---
Olivier
P.S :
I can't be absolutely affirmative since I'm under testing, but I
think that worked before, and I start to beleive that update
from
openldap-servers-2.4.23-15.el6_1.1.x86_64
to
openldap-servers-2.4.23-15.el6_1.3.x86_64
on redhat 6 produces problems.
12 years, 1 month
Re: TLS very strange behaviour
by Rich Megginson
On 10/11/2011 02:38 AM, Olivier Guillard wrote:
> Thanks Rich, see below :
>
>> -12272 is SSL_ERROR_BAD_MAC_ALERT and -12273 is SSL_ERROR_BAD_MAC_READ
>> I've seen this when the client and server do not have the same SSL
>> certificate signature algorithm support. Is everything running on RHEL6
>> and/or Fedora 14 and later?
> [root@ldap2 ~]# cat /etc/issue
> Red Hat Enterprise Linux Server release 6.1 (Santiago)
> Kernel \r on an \m
>
> [root@ldap2 ~]# rpm -qa | grep -i openldap
> openldap-2.4.23-15.el6_1.3.x86_64
> openldap-servers-2.4.23-15.el6_1.3.x86_64
> openldap-debuginfo-2.4.23-15.el6_1.1.x86_64
> openldap-clients-2.4.23-15.el6_1.3.x86_64
>
> [root@ldap1 ~]# cat /etc/issue
> Red Hat Enterprise Linux Server release 6.1 (Santiago)
> Kernel \r on an \m
>
> [root@ldap1 ~]# rpm -qa | grep -i openldap
> openldap-debuginfo-2.4.23-15.el6_1.1.x86_64
> openldap-clients-2.4.23-15.el6_1.3.x86_64
> openldap-2.4.23-15.el6_1.3.x86_64
> openldap-servers-2.4.23-15.el6_1.3.x86_64
>
> [root@ldap2 cacerts]# rpm -qa | grep openssl
> openssl-1.0.0-10.el6_1.4.x86_64
>
> [root@ldap1 ldap1]# rpm -qa | grep openssl
> openssl-1.0.0-10.el6_1.4.x86_64
>
> Not sure if that made a difference but I "yum-updated"
> on last friday and openldap servers version passed :
>
> from
> openldap-servers-2.4.23-15.el6_1.1.x86_64
> to
> openldap-servers-2.4.23-15.el6_1.3.x86_64
Was it working before you yum updated?
> ---
> Olivier
>
> On Mon, Oct 10, 2011 at 9:54 PM, Rich Megginson
> <rich.megginson(a)gmail.com> wrote:
>
>>> here is what I get :
>>>
>>> ldap1 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
>>> ...
>>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>>> -12273
>>> TLS: can't accept: TLS error -12273:Unknown code ___P 15.
>>> TLS: error: connect - force handshake failure: errno 0 - moznss error
>>> -12272
>>> TLS: can't connect: TLS error -12272:Unknown code ___P 16.
>>> slap_client_connect: URI=ldap://ldap2.example.fr Warning,
>>> ldap_start_tls failed (-11)
>>> slap_client_connect: URI=ldap://ldap2.example.fr
>>> ldap_sasl_interactive_bind_s failed (-6)
>>> do_syncrepl: rid=121 rc -6 retrying
>>>
>>> ldap2 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
>>> ...
>>> TLS: error: connect - force handshake failure: errno 0 - moznss error
>>> -12272
>>> TLS: can't connect: TLS error -12272:Unknown code ___P 16.
>>> slap_client_connect: URI=ldap://ldap1.eaxample.fr:389 Warning,
>>> ldap_start_tls failed (-11)
>>> slap_client_connect: URI=ldap://ldap1.example.fr:389
>>> ldap_sasl_interactive_bind_s failed (-6)
>>> do_syncrepl: rid=211 rc -6 retrying
>>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>>> -12273
>>> TLS: can't accept: TLS error -12273:Unknown code ___P 15.
>>>
>>> Any idea ?
>>
12 years, 1 month
adding module with cn=config and bdd
by Hubert Chomette
Hi folks,
I'm newbie on openldap and try to add memberof overlay to my openldap configuration. I use cn=config and have a bdb database. All documentations I fund uses hdb database.
I add memberof.la to module {0}.
I fund that I should add too this entry: " cn=config/olcDatabase={1}hdb/olcOverlay\=\{0\}member of "
What will be the equivalent using bdb frontend?
Thank's for your Help,
12 years, 1 month
syncrepl failing with TLS negotiation failure
by Iain Georgeson
Hello,
I'm trying to get syncrepl working, using simple bind over TLS. TLS is
failing with
Consumer:
Oct 12 17:21:53 auth-01 slapd[23241]: slap_client_connect:
URI=ldap://auth-00.vis.kaust.edu.sa Error, ldap_start_tls failed (-11)
Oct 12 17:21:53 auth-01 slapd[23241]: do_syncrepl: rid=000 rc -11
retrying (3 retries left)
Provider:
Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 fd=137 ACCEPT from
IP=109.171.138.17:39458 (IP=0.0.0.0:389)
Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 op=0 STARTTLS
Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 op=0 RESULT oid= err=0 text=
Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 fd=137 closed (TLS
negotiation failure)
TLS is working for other uses of the server including ldapsearch:
auth-01$ ldapsearch -ZZ -x -D cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa
-W -H ldap://auth-00.vis.kaust.edu.sa uid=iain
Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 fd=137 ACCEPT from
IP=109.171.138.17:39460 (IP=0.0.0.0:389)
Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 op=0 STARTTLS
Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 op=0 RESULT oid= err=0 text=
Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 fd=137 TLS established
tls_ssf=256 ssf=256
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=1 BIND
dn="cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa" method=128
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=1 BIND
dn="cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa" mech=SIMPLE ssf=0
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=1 RESULT tag=97 err=0 text=
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=2 SRCH
base="dc=vis,dc=kaust,dc=edu,dc=sa" scope=2 deref=0
filter="(uid=iain)"
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=2 ENTRY
dn="uid=iain,ou=people,dc=vis,dc=kaust,dc=edu,dc=sa"
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=2 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=3 UNBIND
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 fd=137 closed
and any number of clients are cheerfully using it through
{pam,nss}_ldap and sssd.
I'm not sure where to attack this from. The TLS settings should be
identical. Any thoughts on how to proceed would be appreciated.
consumer:
$ lsb_release -a
LSB Version: :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: Scientific
Description: Scientific Linux release 6.1 (Carbon)
Release: 6.1
Codename: Carbon
$ rpm -q openldap-servers
openldap-servers-2.4.23-15.el6.x86_64
>From slapd.conf:
syncrepl rid=000
provider=ldap://auth-00.vis.kaust.edu.sa
searchbase=dc=vis,dc=kaust,dc=edu,dc=sa
bindmethod=simple
binddn=cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa
credentials=mysecret
type=refreshOnly
retry="10 3 120 5 600 +"
tls_cacert=/etc/ssl/VisLabCA.pem
tls_reqcert=allow
starttls=critical
provider:
$ lsb_release -a
LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 5.6 (Final)
Release: 5.6
Codename: Final
$ rpm -q openldap-servers
openldap-servers-2.3.43-12.el5_5.3
Iain.
--
Systems Engineer
KAUST Visualisation Laboratory
12 years, 1 month
