Search results for "starttls" - openldap-technical

Re: slapd-meta and tls_reqcert=allow

by Manuel Gaupp

Jim Vanes <jimvanes(a)yahoo.ca> wrote: > I'm using OpenLDAP 2.4.23-26 from Centos 6. I seem to be hitting a configuration issue regarding slapd-meta and SSL/TLS. > > Here is my meta config: > > database meta > suffix "dc=virtual,dc=local" > rootdn "cn=root,dc=virtual,dc=local" > rootpw password > > # Local > uri ldap://localhost/dc=ds1,dc=virtual,dc=local > suffixmassage "dc=ds1,dc=virtual,dc=local" "dc=lab,dc=local" > idassert-bind bindmethod=simple binddn="cn=root,dc=lab,dc=local" credentials=password > > #Remote AD server > uri ldap://10.33.63.125:389/dc=ad1,dc=virtual,dc=local > tls start > suffixmassage "dc=ad1,dc=virtual,dc=local" "dc=mslab,dc=local" > idassert-bind bindmethod=simple binddn="CN=Sync,CN=Users,DC=lab,DC=local" credentials="Password1" starttls="yes" tls_reqcert="allow" > > It seems as though tls_reqcert="allow" is ignored for the remote AD server. If set that variable in the ldap.conf everything works fine. But shouldn't the above function as an override to the default of 'demand'? The behaviour is the same when I change the above to use SSL instead. I think you're running into an issue that I reported in September 2010. See http://www.openldap.org/lists/openldap-technical/201009/msg00073.html and http://www.openldap.org/its/index.cgi?findid=6642 According to the Release Change Log, this issue should have been fixed in release 2.4.24. So you should definitely update to a more recent release. Best regards, Manuel

13 years, 7 months

Re: STARTTLS vs LDAPS

by Braiam

On Thu, Mar 31, 2022 at 5:40 AM Norman Gray <gray(a)nxg.name> wrote: > > Quanah and all, hello. > > On 30 Mar 2022, at 18:54, Quanah Gibson-Mount wrote: > > > --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania < > stefan(a)kania-online.de> wrote: > > > >> That's what can be found in the FAQ on openldap.org: > >> > >> https://www.openldap.org/faq/data/cache/605.html > >> > >> I would trust this more then any rumors on any stackxxxx page ;) > > > > Unfortunately, the FAQ is dead weight we want to kill and not > maintained in any way, shape, or form. It's currently provided for > historical purposes. > > Since the copyright dates at the bottom of that page are '1998-2013', so > that the content of the site is now nearly a decade out of date, I feel the > FAQ-o-matic now has negative utility, and that you should give in to the > urge to kill it. > > I respect and applaud the desire to preserve the content for historical > reasons, but surely that goal can be served by making a tarball of the > content available at whatever page https://www.openldap.org/faq/.../* > were to redirect to (ie, the pages shouldn't be 404-ed, but neither should > they be 200; 301 is good). > > I have previously (indeed recently) looked at that page and, without > thinking much about the question, taken its deprecation of LDAPS as current > doctrine. > > And.... ah, FAQ-o-matic I have fond memories of FAQ-o-matics, back when > wikis were new... > > Best wishes, > > Norman > > > -- > Norman Gray : https://nxg.me.uk > What would be the process to modify content on the openldap.org page? -- Braiam

4 years, 5 months

Re: TLS negation failure

by espeake＠oreillyauto.com

From: Aaron Richton <richton(a)nbcs.rutgers.edu> To: espeake(a)oreillyauto.com Cc: openldap-technical(a)openldap.org Date: 09/19/2013 10:13 AM Subject: Re: TLS negation failure On Thu, 19 Sep 2013, espeake(a)oreillyauto.com wrote: > We have a client server that is failing on the ssl handshake using TLS. > The following is from the server log when the client is trying to connect. > > Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 ACCEPT from > IP=172.17.1.10:55469 (IP=0.0.0.0:389) > Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 EXT > oid=1.3.6.1.4.1.1466.20037 > Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 STARTTLS > Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 RESULT oid= > err=0 text= > Sep 19 09:12:50 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 closed (TLS > negotiation failure) > The above information is from a connection when a server is running an application that is trying to access the LDAP server. And this is what the logging is doing on the server. I tried to change the logging level to debug but my changes aren't going through. I tried deleting the olcLogLevel and and then adding it back and tried a replace with no luck. I also tried adding olcTLSCACertificatePath but none of my ldapmodifies seem to be working. I am on version 2.4.31 with a 3 node n-way multimaster setup. Try something like https://groups.google.com/forum/#!topic/mailing.openssl.users/1OOwXp45iIw if you'd like. Or OpenLDAP Software such as ldapsearch(1). The above allowed me to connect and the connection was closed as soon as it opened. Thanks, Eric This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.

12 years, 12 months

Re: SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server - client certificate not read

by Howard Chu

Hauke Coltzau wrote: > Hello everybody, > > I'm just trying to set up a LDAPS server using my own > certification authority, but the ldap server does not > accept/understand my client certificate. Instead, the server > sais: > > TLS: can't accept: The peer did not send any certificate.. > Here are the details: > > Client: > ======= > > # ldapsearch -x -LLL -ZZ -d 1 > > ldap_create > ldap_extended_operation_s > ldap_extended_operation > ldap_send_initial_request > ldap_new_connection 1 1 0 > ldap_int_open_connection > ldap_connect_to_host: TCP<serverip>:636 > ldap_new_socket: 3 > ldap_prepare_socket: 3 > ldap_connect_to_host: Trying<serverip>:636 > ldap_pvt_connect: fd: 3 tm: -1 async: 0 > TLS: can't connect: A TLS packet with unexpected length was received.. > ldap_err2string > ldap_start_tls: Can't contact LDAP server (-1) > > > Server: > ======== > > # slapd -VV > @(#) $OpenLDAP: slapd 2.4.9 (Aug 1 2008 01:09:46) $ > buildd@king:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slapd > > > # slapd -h "ldaps://<ip>/" -u openldap -g openldap -d 127 You cannot use StartTLS (ldapsearch -Z) with an ldaps:// server, it's redundant. > ldap.conf (partially) > --------------------- > > uri ldaps://132.176.4.6/ > ssl yes > tls_cacertfile /usr/lib/ssl/cacartes/<ca>.chain.crt > tls_ciphers TLSv1 The above 3 keywords are not valid for ldap.conf. Read the ldap.conf(5) manpage. > tls_cert /usr/lib/ssl/certs/<clientfqdn>.cert.pem > tls_key /usr/lib/ssl/private/<clientfqdn>.key.pem > What did I do wrong? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

18 years

slapadd hanging initializing mdb backend

by Mark

When I try to slapadd initial data into an empty mdb backend, the slapadd hangs: $ /tmp/openldap-2.4.31/sbin/slapadd -w -S 1 -c -F /tmp/openldap-2.4.31/etc/slapd.d -b dc=example,dc=com -l /tmp/openldap-2.4.31/etc/initdb.ldif _#################### 100.00% eta none elapsed none fast! (does not return to a shell prompt. I have to INT it.) I add '-d -1' to get some debugging output and I get this after removing the data.mdb and lock.mdb created above: $ /tmp/openldap-2.4.31/sbin/slapadd -d -1 -w -S 1 -c -F /tmp/openldap-2.4.31/etc/slapd.d -b dc=example,dc=com -l /tmp/openldap-2.4.31/etc/initdb.ldif (lines removed for brevity but can be submitted if need be) 4f9ea9c0 => str2entry: "dn: ou=Users,dc=example,dc=com objectClass: organizationalUnit ou: Users " 4f9ea9c0 >>> dnPrettyNormal: <ou=Users,dc=example,dc=com> 4f9ea9c0 <<< dnPrettyNormal: <ou=Users,dc=example,dc=com>, <ou=users,dc=example,dc=com> 4f9ea9c0 <= str2entry(ou=Users,dc=example,dc=com) -> 0x6afeba8 4f9ea9c0 oc_check_required entry (ou=Users,dc=example,dc=com), objectClass "organizationalUnit" 4f9ea9c0 oc_check_allowed type "objectClass" 4f9ea9c0 oc_check_allowed type "ou" 4f9ea9c0 oc_check_allowed type "structuralObjectClass" 4f9ea9c0 => mdb_tool_entry_put( -1, "ou=Users,dc=example,dc=com" ) 4f9ea9c0 => mdb_dn2id("ou=users,dc=example,dc=com") 4f9ea9c0 <= mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pair found (-30798) 4f9ea9c0 => mdb_dn2id_add 0x6: "ou=users,dc=example,dc=com" 4f9ea9c0 <= mdb_dn2id_add 0x6: 0 4f9ea9c0 => index_entry_add( 6, "ou=Users,dc=example,dc=com" ) 4f9ea9c0 mdb_idl_insert_keys: 6 [9bee355f] 4f9ea9c0 mdb_idl_insert_keys: 6 [ef1184ca] 4f9ea9c0 mdb_idl_insert_keys: 6 4f9ea9c0 <= index_entry_add( 6, "ou=Users,dc=example,dc=com" ) success 4f9ea9c0 => mdb_entry_encode(0x00000006): ou=Users,dc=example,dc=com 4f9ea9c0 <= mdb_entry_encode(0x00000006): ou=Users,dc=example,dc=com 4f9ea9c0 => mdb_dn2id("dc=example,dc=com") 4f9ea9c0 <= mdb_dn2id: got id=0x1 4f9ea9c0 => mdb_entry_decode: 4f9ea9c0 <= mdb_entry_decode 4f9ea9c0 => mdb_tool_entry_modify( 1, "(null)" ) (it's hung) Here is the /tmp/openldap-2.4.31/etc/initdb.ldif: ### BEGIN INITDB.LDIF dn: dc=example,dc=com objectClass: organization objectClass: dcObject dc: example o: example.com dn: cn=manager,dc=example,dc=com objectClass: organizationalRole objectClass: simpleSecurityObject cn: manager userPassword: {SSHA}asif dn: cn=replicator,dc=example,dc=com objectClass: organizationalRole objectClass: simpleSecurityObject cn: replicator userPassword: {SSHA}asif dn: ou=Groups,dc=example,dc=com objectClass: organizationalUnit ou: Groups dn: cn=LDAP Admins,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames cn: LDAP Admins uniqueMember: cn=manager,dc=example,dc=com dn: ou=Users,dc=example,dc=com objectClass: organizationalUnit ou: Users ### END INITDB.LDIF I used the following slaptest commands to create the initial slapd.d/ directory from a slapd.conf file: $ /tmp/openldap-2.4.31/sbin/slaptest -u -f /tmp/openldap-2.4.31/etc/slapd.conf -F /tmp/openldap-2.4.31/etc/slapd.d config file testing succeeded $ /tmp/openldap-2.4.31/sbin/slaptest -f /tmp/openldap-2.4.31/etc/slapd.conf -F /tmp/openldap-2.4.31/etc/slapd.d 4f9eab15 mdb_db_open: database "dc=example,dc=com" cannot be opened, err 2. Restore from backup! 4f9eab15 backend_startup_one (type=mdb, suffix="dc=example,dc=com"): bi_db_open failed! (2) slap_startup failed (test would succeed using the -u switch) Here is the /tmp/openldap-2.4.31/etc/slapd.conf: ### BEGIN SLAPD.CONF include /tmp/openldap-2.4.31/etc/schema/core.schema include /tmp/openldap-2.4.31/etc/schema/cosine.schema include /tmp/openldap-2.4.31/etc/schema/nis.schema include /tmp/openldap-2.4.31/etc/schema/inetorgperson.schema argsfile /tmp/openldap-2.4.31/var/run/slapd.args pidfile /tmp/openldap-2.4.31/var/run/slapd.pid threads 8 tool-threads 2 idletimeout 0 writetimeout 0 reverse-lookup off loglevel stats serverid 1 ldap://boardwalk:2389 modulepath /tmp/openldap-2.4.31/libexec moduleload back_monitor.la moduleload back_mdb.la moduleload syncprov.la password-hash {SSHA} sizelimit unlimited database config rootdn "cn=manager,dc=example,dc=com" access to * by group="cn=LDAP Admins,ou=Groups,dc=example,dc=com" write by users read by * none database monitor rootdn "cn=manager,dc=example,dc=com" access to * by users read by * none database mdb suffix "dc=example,dc=com" rootdn "cn=manager,dc=example,dc=com" directory /tmp/openldap-2.4.31/var/data index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://boardwalk:2389 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=example,dc=com" credentials="asif" searchbase="dc=example,dc=com" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://chance:2389 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=example,dc=com" credentials="asif" searchbase="dc=example,dc=com" starttls=no schemachecking=off syncrepl rid=003 provider=ldap://freeparking:2389 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=example,dc=com" credentials="asif" searchbase="dc=example,dc=com" starttls=no schemachecking=off mirrormode TRUE overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 access to attrs=userPassword by anonymous auth by self write by dn.exact="cn=replicator,dc=example,dc=com" read by * none access to * by group="cn=LDAP Admins,ou=Groups,dc=example,dc=com" write by dn.exact="cn=replicator,dc=example,dc=com" read by users read by * none limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ### END SLAPD.CONF I compiled from the following source: OpenLDAP 2.4.31 OpenSSL 1.0.1b Cyrus-SASL 2.1.25 I am running in the following environment: Dell Poweredge 2950; dual-core Intel(R) Xeon(R) CPU 5110 @ 1.60GHz; 8GB RAM Scientific Linux 5.7 Am I doing something wrong (besides the ACLs for cn=LDAP Admins,ou=Groups,dc=example,dc=com. I'm still struggling there) ? Thank you, Mark

14 years, 4 months

Re: Ubuntu Server 12.04: StartTLS

by Admus

On 11/05/2012 07:41 PM, Khosrow Ebrahimpour wrote: > Hi, > > On November 4, 2012 11:13:27 PM admus wrote: >> Hello, >> I'm following >> https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls >> -replication how to: LDAP serwer starts correctly but when I tries to test >> StartTLS: >> ldapsearch -x -H ldap:/// -ZZ -d -1 >> I gets the following error: >> TLS: peer cert untrusted or revoked (0x42) >> TLS: can't connect: (unknown error code). >> ldap_err2string >> ldap_start_tls: Connect error (-11) >> additional info: (unknown error code) >> Any idea? > Have you verified your certificate? What is the output of : > > openssl s_client -connect ldap1.example.com:636 -showcerts > > or on the server itself you can dump the cert info > > cat ldap-cert.pem | openssl x509 -text > > The certificate info is as follow: Certificate: Data: Version: 3 (0x2) Serial Number: 1352064827 (0x5096df3b) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=ldap1.example.com Validity Not Before: Nov 4 21:33:47 2012 GMT Not After : Nov 2 21:33:47 2022 GMT Subject: O=Example Com, CN=ldap1.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2432 bit) Modulus: 00:e7:06:b9:1d:19:c7:67:de:93:8e:db:e8:a3:1f: e2:c7:39:62:20:bb:7d:5b:d3:5a:78:5c:7c:89:5d: 27:00:a8:71:03:73:b0:9a:a9:fe:31:a7:22:f0:ac: d5:9f:f4:3b:a4:9a:08:95:ba:f7:cf:7d:6e:a6:86: 2d:39:7e:c1:06:aa:27:07:43:78:77:6e:b0:20:a2: 6f:80:4a:cf:39:8b:e3:91:92:c3:9c:ca:84:2a:45: 4f:35:48:87:bd:02:8d:48:04:e0:9b:7a:9d:a8:bd: 7b:f8:e3:6d:64:88:25:ab:2f:66:d6:4a:0e:5c:3b: 47:a9:21:27:5d:0c:f6:47:ac:d1:e0:55:0b:41:27: a9:9b:b2:97:4e:07:5c:ef:5f:ad:0a:9a:ad:f5:ed: f0:0f:16:56:2e:54:8e:e9:64:65:47:67:26:69:65: 31:9d:18:74:b7:67:af:72:1c:9a:bb:ad:89:3a:d0: bb:15:13:88:13:59:e0:cb:61:05:9a:da:a7:d7:88: 15:6b:f2:78:52:be:da:a5:79:a7:bd:cc:94:70:17: 47:58:f3:48:2c:0f:47:7f:bb:ed:05:9c:32:26:1c: 79:f2:4f:b8:2e:82:e4:5c:7f:13:31:92:4a:7e:67: 76:7a:8c:5a:bb:2d:13:31:34:05:2e:19:88:70:dc: 34:db:14:38:18:71:fb:8f:c1:2a:9d:56:75:80:54: ff:34:e6:b3:ad:9c:96:de:f9:c7:39:df:f1:83:63: a6:af:47:8b:a8:d2:6e:92:30:e9:94:14:27:9c:18: 0a:08:6d:c7:4d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Subject Key Identifier: 50:88:10:B9:46:9D:61:37:B9:24:2E:A0:33:6A:15:34:23:38:1B:1E X509v3 Authority Key Identifier: keyid:8E:98:97:7B:2E:DC:62:92:44:14:55:74:EF:31:E5:BC:60:3F:57:70

13 years, 10 months

consumer state is newer than provider (was "can I replicate several branches to the same slave from one master?")

by Zeus Panchenko

greetings, alas, but I still face the issue ... :-\ ---[ replica log quotation start ]------------------------------------------- ... Jul 27 12:29:46 ABC slapd[15466]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jul 27 12:29:46 ABC slapd[15466]: do_syncrep2: rid=000 (53) Server is unwilling to perform Jul 27 12:29:46 ABC slapd[15466]: do_syncrepl: rid=000 rc -2 retrying ... ---[ replica log quotation end ]------------------------------------------- ---[ master log quotation start ]------------------------------------------- ... Jul 27 12:29:46 master slapd[45467]: conn=2610 op=1 BIND dn="uid=replABC,ou=repl,ou=system,dc=example" method=128 Jul 27 12:29:46 master slapd[45467]: conn=2610 op=1 BIND dn="uid=replABC,ou=repl,ou=system,dc=example" mech=SIMPLE ssf=0 Jul 27 12:29:46 master slapd[45467]: conn=2610 op=1 RESULT tag=97 err=0 text= Jul 27 12:29:46 master slapd[45467]: conn=2611 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 27 12:29:46 master slapd[45467]: conn=2611 op=0 STARTTLS Jul 27 12:29:46 master slapd[45467]: conn=2611 op=0 RESULT oid= err=0 text= Jul 27 12:29:46 master slapd[45467]: conn=2610 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jul 27 12:29:46 master slapd[45467]: conn=2610 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jul 27 12:29:46 master slapd[45467]: conn=2610 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jul 27 12:29:46 master slapd[45467]: conn=2610 op=3 UNBIND ... ---[ master log quotation end ]------------------------------------------- please advise Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > slapd[38004]: conn=30116 op=3 SEARCH RESULT tag=101 err=53 nentries=0 > > text=consumer state is newer than provider! > > It sounds like your replica was not configured correctly initially and > self-generated its own CSN that is newer than the one on the provider. what in replica configuration can lead to that? I configured replica just as it is described in the documentation "18.3.2.1. Delta-syncrepl Provider configuration" > It would be interesting to make a modification on the provider so that > its CSN is updated (and thus has one newer than on the consumer). doesn't help ... helps only deleting consumer DB (in some cases for a several times) DB replicates but after some time it looses sync again ... can master configuration cause that as well? here is (just to remind) how master/replica are configured ... ---[ replica slapd.conf quotation start ]------------------------------------------- ... syncrepl rid=0 provider=ldap://master.example:389 starttls=critical searchbase="dc=example" bindmethod=simple binddn="uid=replABC,ou=repl,dc=example" credentials="***" tls_cacert=/usr/local/etc/openldap/ssl/ca.crt tls_cert=/usr/local/etc/openldap/ssl/ABC.crt tls_key=/usr/local/etc/openldap/ssl/ABC.key tls_reqcert=try type=refreshAndPersist retry="60 +" logbase="cn=example-accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog ... ---[ replica slapd.conf quotation end ]------------------------------------------- ---[ master configuration quotation start ]------------------------------------------- ... access to dn.subtree="cn=example-accesslog" by dn.onelevel="ou=repl,ou=system,dc=example" read by * break ###--- ABC access to dn.regex="^uid=(.*)@foo.bar,authorizedService=(mail|xmpp)@foo.bar,uid=(.*),ou=People,dc=example$" attrs=entry,entryCSN,entryUUID,objectClass,cn,... by dn.exact="uid=replABC,ou=repl,ou=system,dc=example" read by * break access to dn.regex="ou=ABC,ou=Sendmail,dc=example|ou=ABC,ou=DHCP,dc=example" by dn.exact="uid=replABC,ou=repl,ou=system,dc=example" read by * stop ... ---[ master configuration quotation end ]------------------------------------------- -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)

9 years, 1 month

Error, ldap_start_tls failed (-11)

by arun.sasi1＠wipro.com

Hello Guillaume Rousse/team, I am getting below error from the master server when I give 636 port number in my HDB config file Sep 16 06:41:59 gb0135embldap01 slapd[4672]: conn=349739 fd=39 ACCEPT from IP=163.183.2.145:43965 (IP=0.0.0.0:636) Sep 16 06:41:59 gb0135embldap01 slapd[4672]: conn=349739 fd=39 closed (TLS negotiation failure) and When I gibe 389 in my HDB config, I get below message from master server. Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 fd=38 ACCEPT from IP=163.183.2.145:49242 (IP=0.0.0.0:389) Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 op=0 STARTTLS Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 op=0 RESULT oid= err=0 text= Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349040 op=6 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(gidNumber=443298))" Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349040 op=6 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349040 op=6 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349044 op=2 UNBIND Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349044 fd=19 closed Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349037 fd=60 closed (connection lost) but there is no much data replication happened I get below message from slave server... for 636 Sep 16 10:47:26 ae0043app05 slapd[10982]: slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com:636 Error, ldap_start_tls failed (-1) Sep 16 10:47:26 ae0043app05 slapd[10982]: do_syncrepl: rid=365 rc -1 retrying for 389 Sep 16 10:31:42 ae0043app05 slapd[10282]: slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com:389 Error, ldap_start_tls failed (-11) I dont know how to check TLS manually... could you please help me... Thanks & Regards, Arun Sasi Venmalassery ------------------------------------------------------------------------------------------------------------------------------------- Sr. Engineer - Server Management (UNIX), Wipro Ltd (Dubai) |Mob: +971 566489491 | E: arun.sasi1(a)wipro.com ________________________________________ From: openldap-technical-bounces(a)OpenLDAP.org [openldap-technical-bounces(a)OpenLDAP.org] on behalf of openldap-technical-request(a)OpenLDAP.org [openldap-technical-request(a)OpenLDAP.org] Sent: Friday, September 14, 2012 5:30 PM To: openldap-technical(a)openldap.org Subject: openldap-technical Digest, Vol 58, Issue 12 ------------------------------ Message: 3 Date: Thu, 13 Sep 2012 14:38:20 +0200 From: Guillaume Rousse <guillomovitch(a)gmail.com> To: openldap-technical(a)openldap.org Subject: Re: Error, ldap_start_tls failed (-11) Message-ID: <5051D3BC.3020207(a)gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Le 13/09/2012 14:16, arun.sasi1(a)wipro.com a ?crit : > Hello Team, > > I have an issue with OpenLDAP TLS based replication > > Getting below error > slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com Error, > ldap_start_tls failed (-11) > Sep 13 16:13:34 ae0043app05 slapd[2582]: do_syncrepl: rid=365 rc -11 > retrying > > I have openLDAP in Ubuntu 9.04 version 2.4.19 then I thought to updgrade > it and first I upgraded on my consumer openldap server which I migrated > to Ubuntu 12.04 and version 2.4.28. > > I have created the certificate for my consumer from existing server. but > when I go for TLS based replication, the database is not syncing and it > is synching when remove starttls=no What does the master log say, and did you try a manual connection with the same credentials from the slave to the master, using TLS ? -- BOFH excuse #166: /pub/lunch The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

13 years, 12 months

Re: 2 way SSL configuration in OpenLDAP 2.4

by Philip Guenther

On Wed, 11 Dec 2013, vidya bharadwaj wrote: > have to implement a 2 way SSL mechanism on a LDAP connector in our > product. In order to test the implementation, we have chosen openLDAP2.4 > as the data source. You should *first* get SSL working without client certs. Once you have that working, *then* add client certs to the config. Next: is your intent to do a) "upgrade from cleartext to SSL" (i.e., make an ldap:// connection and then use the StartTLS extension to negotiate TLS), OR b) "SSL on connect" (i.e., make an ldaps:// connection where SSL is negotiated immediately after connecting) ? I ask, because your config bits mix the two, which won't work: port 636 is reserved for ldaps (choice (b)), but you used the -Z option to ldapsearch (choice (a)). You must pick one. If you want to do (a), then you should be using ldap:// on port 389 with the -Z (or -ZZ) option. If you want to do (b), then you should be using ldaps:// on port 636 and *not* use the -Z option. ... > 6. Following changes > were made in sldap.conf > TLSCipherSuite MEDIUM:+SSLv2:+SSLv3:RSA So you want to be completely insecure? Why bother enabling SSL if you're going to permit SSLv2 and even ciphers that DON'T ENCRYPT. $ openssl ciphers -v MEDIUM:+SSLv2:+SSLv3:RSA | grep Enc=None NULL-SHA SSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1 NULL-MD5 SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5 $ You should yell at the person or documentation that suggested using that line and stop trusting them for anything involving security. ... > On the client side: > 1. Following changes were made in ldap.conf > HOST spsdel192 > PORT 636 Do not use the HOST and PORT options. Use the URI option, as that lets you specify the schema (ldap vs ldaps) in the same line. Next, in order for the server certificate to be validated, the hostname you connect to (in the URI) must match what's in the certificate, which should be an FQDN. I.e., something like: URI ldaps://spsdel192.YOUR.DOMAIN.GOES.HERE:636/ Philip Guenther

12 years, 9 months

Re: Dovecot can't connect to openldap over starttls

by info＠gwarband.de

Am 2017-03-19 01:09, schrieb Dan White: > Reformatted: > >>>>>> On 03/17/2017 04:27 PM, info(a)gwarband.de wrote: >>>>>>> Hello guys, >>>>>>> >>>>>>> actually I'm trying to configure dovecot to access openldap for >>>>>>> passwordcheck. > >>>>>>> All datalinks: >>>>>>> >>>>>>> https://gwarband.de/openldap/dovecot.log > > Mar 11 11:18:26 s1 dovecot: auth: Debug: Read auth token secret from > /var/run/dovecot/auth-token-secret.dat > Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() > failed: Connect error > Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() > failed: Connect error > Mar 11 11:18:26 s1 dovecot: auth: Debug: auth client connected > (pid=27177) > Mar 11 11:18:33 s1 dovecot: imap-login: Disconnected (no auth > attempts in 7 secs): user=<>, rip=149.172.171.148, lip=188.68.37.50, > session=<gcDtzHFKbwCVrKuU> > >>>>>>> https://gwarband.de/openldap/dovecot-ldap.conf > > uris = ldap://ldap.gwarband.de > dn = cn=T000000002,ou=tech,dc=gwarband,dc=de > dnpass = secret > tls = yes > tls_ca_cert_file = /etc/ssl/certs/LetsEncrypt.pem > auth_bind = yes > ldap_version = 3 > base = dc=gwarband,dc=de > scope = subtree > user_attrs = > mail=maildir:/var/vmail/%{ldap:mailbox},uid=vmail,gid=vmail > user_filter = > (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de)) > pass_attrs = email=user > pass_filter = > (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de)) > >>>>>>> https://gwarband.de/openldap/openldap.log > > Mar 11 10:48:38 s1 slapd[26962]: conn=1001 fd=14 ACCEPT from > IP=188.68.37.50:60814 (IP=188.68.37.50:389) > > Mar 11 10:48:38 s1 slapd[26962]: conn=1001 op=0 STARTTLS > > Mar 11 10:48:38 s1 slapd[26962]: conn=1002 fd=15 ACCEPT from > IP=188.68.37.50:60815 (IP=188.68.37.50:389) > > Mar 11 10:48:38 s1 slapd[26962]: conn=1002 op=0 STARTTLS > > Mar 11 10:49:42 s1 slapd[26962]: connection_get(14): got connid=1001 > Mar 11 10:49:42 s1 slapd[26962]: connection_read(14): checking for > input on id=1001 > Mar 11 10:49:42 s1 slapd[26962]: connection_read(14): TLS accept > failure error=-1 id=1001, closing > > Mar 11 10:49:42 s1 slapd[26962]: connection_get(15): got connid=1002 > Mar 11 10:49:42 s1 slapd[26962]: connection_read(15): checking for > input on id=1002 > Mar 11 10:49:42 s1 slapd[26962]: connection_read(15): TLS accept > failure error=-1 id=1002, closing > > Mar 11 10:49:42 s1 slapd[26962]: conn=1001 fd=14 closed (TLS > negotiation failure) > Mar 11 10:49:42 s1 slapd[26962]: conn=1002 fd=15 closed (TLS > negotiation failure) > >>>>>>> https://gwarband.de/openldap/trace.dump > > It appears that the client is sending an unbind request after the > server > sends a successful starttls response. > >>>>>>> The bugreportinglink from openldap: >>>>>>> >>>>>>> http://www.openldap.org/its/index.cgi/Incoming?id=8615 > >>>>> Am 2017-03-17 22:48, schrieb Tomas Habarta: >>>>>> been running Dovecot 2.2.27 against OpenLDAP 2.4.40 normally over >>>>>> the unix socket on the same machine, but tried over inet with >>>>>> STARTTLS and it's working ok... I would suggest double-checking >>>>>> key/certs setup on OpenLDAP side; for the test I have used LE >>>>>> certs, >>>>>> utilizing following cn=config attributes: >>>>>> >>>>>> olcTLSCertificateKeyFile contains private key >>>>>> olcTLSCertificateFile contains certificate >>>>>> olcTLSCACertificateFile contains both certs (DST Root CA X3 >>>>>> and Let's Encrypt Authority X3) >>>>>> >>>>>> and used the same CA file in Dovecot's tls_ca_cert_file >>>>>> Is ldapsearch working ok (-ZZ) and only Dovecot has troubles or >>>>>> ... ? > >>>> On 03/18/2017 09:41 AM, info(a)gwarband.de wrote: >>>>> I have also installed LE certs. But nothing helps, I have >>>>> double-checking all certs. ldapsearch with -ZZ works see: >>>>> >>>>> https://gwarband.de/openldap/ldapsearch.log > > ldapsearch -x -ZZ -D "cn=admin,dc=gwarband,dc=de" -W "cn=mailbox" > >>>>> I have also uploaded the TLSCACertificateFile, maybe I have a >>>>> failure >>>>> in the merge of the two fiels: >>>>> >>>>> https://gwarband.de/openldap/LetsEncrypt.crt >>>>> >>>>> And also I have uploaded my complete openldap configuration: >>>>> >>>>> https://gwarband.de/openldap/openldap.conf > > # Certificate > TLSCACertificateFile /etc/ssl/certs/LetsEncrypt.pem > TLSCertificateFile /etc/ssl/certs/gwarbandDE_LDAP.pem > TLSCertificateKeyFile /etc/ssl/certs/gwarbandDE_LDAP.key > TLSCipherSuite > SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM > TLSProtocolMin 3.1 > TLSVerifyClient never > >>>>> All other components can work and communicate with my openldap >>>>> server. The components are postfix, openxchange, apache >>>>> (phpldapadmin). My installated software is: >>>>> >>>>> Debian 8 >>>>> OpenLDAP 2.4.40 >>>>> Dovecot 2.2.13 > >>> Am 2017-03-18 12:30, schrieb Tomas Habarta: >>>> Well, if ldapsearch works, try to replicate its settings for >>>> dovecot >>>> client. It's not obvious what settings ldapsearch uses, have a >>>> look >>>> at default client settings in /etc/openldap/ldap.conf, there may be >>>> something set a slightly different way. Also double check >>>> permissions >>>> for files used by dovecot, I mean mainly the file listed for >>>> tls_ca_cert_file as dovecot may not have an access for reading... >>>> I >>>> cannot see anything downright bad, just posted CA cert (which is >>>> ok, >>>> tested) is *.crt and your config mentions *.pem but I consider it's >>>> the same file. Finally, I would recommend to enable debug option >>>> for >>>> dovecot's client >>>> >>>> debug_level = -1 (which logs all available) in your >>>> dovecot-ldap.conf >>>> >>>> to see what the library reports and work further on that. You can >>>> compare with output from ldapsearch by adding -d-1 switch to it. >>>> Hard >>>> to tell more at the moment. > > What are the contents of /etc/ldap/ldap.conf? > >> On 03/18/2017 01:31 PM, info(a)gwarband.de wrote: >>> I've replicate the settings from ldapsearch to dovecot but no >>> success. >>> >>> To the certificate: >>> Yes it's a *.crt file but I have linked the *.pem file to it and >>> dovecot has read access to that file. I have enabled the debugging >>> in >>> dovecot and have uploaded the output: >>> https://gwarband.de/openldap/dovecot-connect.log > > Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_extended_operation_s > Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_extended_operation > > Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_connect_to_host: TCP > ldap.gwarband.de:389 > > Mar 18 12:43:31 s1 dovecot: auth: Error: connect success > > Mar 18 12:43:31 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() > failed: Connect error > >>> >>> And the other site with ldapsearch: >>> https://gwarband.de/openldap/ldapsearch-connect.log >>> I'm pretty sure that there is a problem with the sslhandshaking >>> between >>> openldap and dovecot, but I can't find the source of the problem. >>> One >>> of the steps in the sslhandshaking is not success but in the >>> debugging >>> output I can't find any line with a hit to it. > > Am 2017-03-18 14:01, schrieb Tomas Habarta: >> Increase log level on server side as well to see what the server >> says... >> You may remove anything in TLSCipherSuite for the purpose of testing >> too. Hopefully anyone knowing OpenLDAP internals could help you >> analyse >> it more deeply. > > Your ldapsearch command should reference your ldap.conf config > (ldap.conf(5)), and your dovecot-ldap.conf (assuming that it uses > libldap) > will also, but overwrite any settings using dovecot-ldap.conf. Compare > any > differences. > > Look for permissions problems. Run your ldapsearch command as the same > user > dovecot runs under. The ldap.conf has no difference to the dovecot-ldap.conf. See: https://gwarband.de/openldap/ldap.conf The point "TLS_REQCERT" is in both confs "demand". I've changed it after that. The ldapsearch command works also under the user "dovecot" See: https://gwarband.de/openldap/ldapsearch-dovecot.log

9 years, 6 months

openldap-technical search results for query "starttls"