openldap-technical October 2011

openldap-technical@openldap.org

85 participants
99 discussions

Re: TLS very strange behaviour
by Rich Megginson 14 Oct '11

14 Oct '11

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 ? >>

1 0

Re: Syncrepl SSL fail
by Hugo Deprez 14 Oct '11

14 Oct '11

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 >> >> >

3 2

Re: Syncrepl SSL fail
by Hugo Deprez 14 Oct '11

14 Oct '11

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 >

1 0

Re: Borked olcDatabase={1}hdb.ldif
by Jan Geep 13 Oct '11

13 Oct '11

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...

1 0

Borked olcDatabase={1}hdb.ldif
by Jan Geep 13 Oct '11

13 Oct '11

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

2 1

authentication failure: bad digest-uri: doesn't match service
by Juergen.Sprenger＠swisscom.com 12 Oct '11

12 Oct '11

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

3 4

syncrepl tls_cert file not red ?
by Olivier 12 Oct '11

12 Oct '11

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.

3 4

Re: TLS very strange behaviour
by Rich Megginson 12 Oct '11

12 Oct '11

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 ? >>

1 0

adding module with cn=config and bdd
by Hubert Chomette 12 Oct '11

12 Oct '11

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,

1 0

syncrepl failing with TLS negotiation failure
by Iain Georgeson 12 Oct '11

12 Oct '11

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

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2011