Search results for "starttls" - openldap-technical

Re: Problems with 4-way multi-master

by Mark

Ok, that's embarrassing. I forgot the last couple lines of each of the slapd.confs. Just pretend each of the four ends with the following lines after all the syncrepl rids have been configured: mirrormode TRUE overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 On Thu, Mar 31, 2011 at 9:06 PM, Mark <mah042(a)gmail.com> wrote: > I've been testing a 4-way multi-master setup using OpenLDAP 2.4.25 and I'm > having some sporadic problems with it that I'm having difficulty > diagnosing.. > > I have four identical RHEL 4.9 machines on the same switch (NTP syncronized > to same stratum 2 servers): > dual-core Xeon 5110 1.60GHz > 8GB RAM > 100Mb full-duplex NIC > OpenLDAP 2.4.25, BDB 4.8.30, OpenSSL 1.0.0d, Cyrus SASL 2.1.23 (using no > tls/ssl at this time) > > I start the slapds with '-d conns,sync' then commence. I ldapadd 1000 DNs > to one of the servers. After all the syncing has stopped I then compare the > slapd contents against each other looking for differences. Occasionally > there are as much as a couple hundred DNs missing from one or more of the > instances. When that happens I've noticed that the mmaster with less DNs has > lost its consumer connection to a mmaster provider (confirmed using lsof and > netstat) and will never attempt a re-connect, but the provider still shows > the connection (using lsof and netstat). When the consumer gets in this > state I can connect to its cn=config and cn=monitor backends (and browse > them) but when I try to connect to its multi-master'd backend the connection > attempt just hangs. It's almost like the connect succeeds but the client is > waiting for a response from the server (and never gets it). Also, the > consumer slapd will not respond to a 'kill -TERM' at this time and must be > 'kill -KILL'd. The same thing occurs sometimes when I delete the entire > tree. > > I've been trying to catch logging information that might help but so far > nothing's jumping out at me. While I continue to try to reproduce and parse > through logfiles maybe someone can look at my slapd.confs below and see if I > might have configured something wrong (I'm listing the original slapd.conf > files below, but I've used slaptest to convert them to > slapd.d/cn=config.ldif format): > > HOST1 slapd.conf: > > include /tmp/openldap/multi-master/etc/schema/core.schema > include /tmp/openldap/multi-master/etc/schema/cosine.schema > include /tmp/openldap/multi-master/etc/schema/nis.schema > argsfile /tmp/openldap/multi-master/var/run/slapd.args > pidfile /tmp/openldap/multi-master/var/run/slapd.pid > threads 16 > idletimeout 0 > writetimeout 5 > reverse-lookup off > timelimit time.soft=30 time.hard=300 > sizelimit size.soft=500 size.hard=1000 > password-hash {SSHA} > loglevel stats sync > serverid 001 > modulepath /tmp/openldap/multi-master/libexec > moduleload back_monitor.la > moduleload back_hdb.la > moduleload syncprov.la > > database config > rootdn cn=manager,cn=config > rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm > > database monitor > rootdn cn=manager,cn=monitor > rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R > > database hdb > suffix dc=example,dc=com > rootdn cn=manager,dc=example,dc=com > rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI > directory /tmp/openldap/multi-master/var/data/dc=example,dc=com > cachesize 30000 > cachefree 5 > checkpoint 128 15 > dncachesize 25000 > idlcachesize 100000 > index objectClass eq > index entryCSN eq > index entryUUID eq > > syncrepl rid=001 > provider=ldap://host2:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=002 > provider=ldap://host3:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=003 > provider=ldap://host4:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > > HOST2 slapd.conf: > > include /tmp/openldap/multi-master/etc/schema/core.schema > include /tmp/openldap/multi-master/etc/schema/cosine.schema > include /tmp/openldap/multi-master/etc/schema/nis.schema > argsfile /tmp/openldap/multi-master/var/run/slapd.args > pidfile /tmp/openldap/multi-master/var/run/slapd.pid > threads 16 > idletimeout 0 > writetimeout 5 > reverse-lookup off > timelimit time.soft=30 time.hard=300 > sizelimit size.soft=500 size.hard=1000 > password-hash {SSHA} > loglevel stats sync > serverid 002 > modulepath /tmp/openldap/multi-master/libexec > moduleload back_monitor.la > moduleload back_hdb.la > moduleload syncprov.la > > database config > rootdn cn=manager,cn=config > rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm > > database monitor > rootdn cn=manager,cn=monitor > rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R > > database hdb > suffix dc=example,dc=com > rootdn cn=manager,dc=example,dc=com > rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI > directory /tmp/openldap/multi-master/var/data/dc=example,dc=com > cachesize 30000 > cachefree 5 > checkpoint 128 15 > dncachesize 25000 > idlcachesize 100000 > index objectClass eq > index entryCSN eq > index entryUUID eq > > syncrepl rid=001 > provider=ldap://host1:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=002 > provider=ldap://host3:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=003 > provider=ldap://host4:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > > HOST3 slapd.conf: > > include /tmp/openldap/multi-master/etc/schema/core.schema > include /tmp/openldap/multi-master/etc/schema/cosine.schema > include /tmp/openldap/multi-master/etc/schema/nis.schema > argsfile /tmp/openldap/multi-master/var/run/slapd.args > pidfile /tmp/openldap/multi-master/var/run/slapd.pid > threads 16 > idletimeout 0 > writetimeout 5 > reverse-lookup off > timelimit time.soft=30 time.hard=300 > sizelimit size.soft=500 size.hard=1000 > password-hash {SSHA} > loglevel stats sync > serverid 003 > modulepath /tmp/openldap/multi-master/libexec > moduleload back_monitor.la > moduleload back_hdb.la > moduleload syncprov.la > > database config > rootdn cn=manager,cn=config > rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm > > database monitor > rootdn cn=manager,cn=monitor > rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R > > database hdb > suffix dc=example,dc=com > rootdn cn=manager,dc=example,dc=com > rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI > directory /tmp/openldap/multi-master/var/data/dc=example,dc=com > cachesize 30000 > cachefree 5 > checkpoint 128 15 > dncachesize 25000 > idlcachesize 100000 > index objectClass eq > index entryCSN eq > index entryUUID eq > > syncrepl rid=001 > provider=ldap://host1:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=002 > provider=ldap://host2:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=003 > provider=ldap://host4:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > HOST4 slapd.conf: > > include /tmp/openldap/multi-master/etc/schema/core.schema > include /tmp/openldap/multi-master/etc/schema/cosine.schema > include /tmp/openldap/multi-master/etc/schema/nis.schema > argsfile /tmp/openldap/multi-master/var/run/slapd.args > pidfile /tmp/openldap/multi-master/var/run/slapd.pid > threads 16 > idletimeout 0 > writetimeout 5 > reverse-lookup off > timelimit time.soft=30 time.hard=300 > sizelimit size.soft=500 size.hard=1000 > password-hash {SSHA} > loglevel stats sync > serverid 004 > modulepath /tmp/openldap/multi-master/libexec > moduleload back_monitor.la > moduleload back_hdb.la > moduleload syncprov.la > > database config > rootdn cn=manager,cn=config > rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm > > database monitor > rootdn cn=manager,cn=monitor > rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R > > database hdb > suffix dc=example,dc=com > rootdn cn=manager,dc=example,dc=com > rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI > directory /tmp/openldap/multi-master/var/data/dc=example,dc=com > cachesize 30000 > cachefree 5 > checkpoint 128 15 > dncachesize 25000 > idlcachesize 100000 > index objectClass eq > index entryCSN eq > index entryUUID eq > > syncrepl rid=001 > provider=ldap://host1:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=002 > provider=ldap://host2:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=003 > provider=ldap://host3:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > > Thank you. > > >

15 years, 6 months

Re: Syncrepl SSL fail

by Rich Megginson

On 10/14/2011 07:10 AM, Hugo Deprez wrote: > 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. That should be fine. You don't need to define a TLSCipherSuite > 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 You should have starttls=critical or it will attempt to fallback to plain LDAP if it cannot establish TLS. > tls_cert=/etc/ssl/certs/ldap-cert.pem You should not have tls_cert here, since you are trying to use dn/password auth. tls_cert is useless without tls_key anyway. > 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 >>> >>>

15 years

ldap_start_tls: Connect error - self signed certificate in certificate chain

by paul.jc＠yahoo.com

Hello, I have recently upgraded from openldap 2.4.45 to 2.5.53. I are running into one issue when running ldapsearch wth StartTLS locally on the openldap servers. I get the following error whereas I did not prior to upgrade. Any input/suggestions welcome. $ ldapsearch -ZZ -LLL -H ldap://<uri> -x -D "cn=admin, dc=<test.dc,dc=com" -b "dc=test,dc=com" -w ${pw} ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) Here is the debug: -------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 3, err: 19, subject: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority, issuer: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS trace: SSL_connect:error in error TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). ldap_err2string ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) -------------- This does not happen with the same ldapsearch done remotely - TLS works just fine with remote ldapsearch queries. Running ldapsearch without StartTLS locally on the server works just fine as well. Prior to this upgrade, we had built openldap with MozNSS (--with-tls=moznss) but now are using the recommended openssl. With our earlier version, running ldapsearch with StartTLS locally on the openldap servers worked without issue. Our certs are not self signed but it appears tls with ldapsearch is seeing the CA cert from our CA as self signed when running locally on the server. Is this even a problem since remote connectivity with TLS works fine? Since we were running moznss prior, I am not sure what the expected behavior is now but it seems that it should work the same as before. A few more details: ------------------ -Servers are CentOS Linux release 7.5 -We are running Openldap version: OpenSSL 1.0.2k-fips 26 Jan 2017 -We are using the same certs (no changes to the certs as part of the upgrade) -Here is partial output from openssl s_client -connect <hostname-here>:636 (same result with openssl s_client -connect <hostname-here>:389 -starttls ldap): This shows return code of 0 (ok): -------------- New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Verify return code: 0 (ok) -------------- -Ran openssl s_client -verify 3 -connect localhost:636 (and with hostname as well) and openssl s_client -showcerts -connect localhost:636. Both return code 0 (ok): Verify return code: 0 (ok) -Checked the certs: openssl verify -verbose -x509_strict -CAfile ca.crt slapd.crt slapd.crt: OK -Here is our cert config: olcTLSCACertificateFile: /etc/openldap/certs/ca.crt olcTLSCertificateFile: /etc/openldap/certs/slapd.crt olcTLSCertificateKeyFile: /etc/openldap/certs/slapd.key For reference, here is the debug output when running the same ldapsearch command locally on the server on our previous version (2.4.45 with moznss) and the same cert is validated. -------------- TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/openldap/certs prefix . TLS: certificate [CN=*<test-domain-here>,OU=Domain Control Validated] is valid TLS certificate verification: subject: CN=*<test-domain-here>,OU=Domain Control Validated, issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US, cipher: AES-256-GCM, security level: high, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0 ldap_sasl_bind -------------- Any suggestions are appreciated. Thanks. Paul

6 years

Re: LDAPS Multi-master replication

by Quanah Gibson-Mount

Hello, Please keep replies on the list. --On Tuesday, January 28, 2020 8:06 AM +0000 Клеусов Владимир Сергеевич <Kleusov.Vladimir(a)wildberries.ru> wrote: > Fixed Not sure what you're saying was fixed. There was not really any errors discussed in your prior email, simply a note that the replication you were configurating would only replicate the cn=config database. Your modification appears to keep that behavior. > dn: olcDatabase={0}config,cn=config > changetype: modify > replace: olcSyncRepl > olcSyncRepl: rid=001 provider=ldaps://infra-ldap-m9.wb.ru > searchbase="cn=config" bindmethod=simple credentials=5fX?BLR2 > binddn="cn=admin,cn=config" starttls=no > tls_cert="/etc/ldap/sasl2/wb.ru.crt" tls_key="/etc/ldap/sasl2/wb.ru.key" > tls_cacert="/etc/ldap/sasl2/commercial_ca.crt" tls_reqcert=allow > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncRepl: rid=002 provider=ldaps://infra-ldap.dl.wb.ru > searchbase="cn=config" bindmethod=simple credentials=5fX?BLR2 > binddn="cn=admin,cn=config" credentials=5fX?BLR2 starttls=no > tls_cert="/etc/ldap/sasl2/w.ru.crt" tls_key="/etc/ldap/sasl2/wb.ru.key" > tls_cacert="/etc/ldap/sasl2/commercial_ca.crt" tls_reqcert=allow > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncRepl: rid=003 provider=ldaps://infra-ldap.dp.wb.ru > searchbase="cn=config" bindmethod=simple credentials=5fX?BLR2 > binddn="cn=admin,cn=config" starttls=no > tls_cert="/etc/ldap/sasl2/wb.ru.crt" > tls_key="/etc/ldap/sasl2/wb.ru.key"tls_cacert="/etc/ldap/sasl2/commercial > _ca.crt" tls_reqcert=allow type=refreshAndPersist retry="5 5 300 5" > timeout=1 Your above configuration seems very odd. You are not doing client cert authentication via SASL EXTERNAL, and yet you've specified a client cert and key. I would expect the only TLS configuration bits to be for the CA cert. > But in logs on each server > slap_client_connect: URI=ldaps://infra-ldap.dl.wb.ru > DN="cn=admin,cn=config" ldap_sasl_bind_s failed So it's not able to bind with the configuration to the other server. > openssl s_client -connect infra-ldap.dp.wb.ru:636 > Verify return code: 0 (ok) > Do I need to specify port 636 in steps 5 and 7 ? For example, it was > ldaps:/ / infra-ldap-m9.wb. ru and will become ldaps://infra-ldap-m9.wb. > ru:636 No, port 636 is the default for ldaps. > And how else can you figure out what's wrong ? I would use the ldapwhoami utility to ensure you can bind with the specified identity to each server. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 9 months

mdb grows to olcDbMaxsize if searched before syncrepl completes.

by Jancewicz, Russell

I am experiencing strange behavior when running an mdb database, as compared to the same system configured with hdb. If I conduct any queries while the server is receiving its initial data the server via syncrepl it stops receiving new entries and the data.mdb file balloons to the olcDbMaxsize value. I have tried adjusting configuration settings but regardless this continues to occur is this to be expected with mdb? It should be noted that if I wait for the entire database to replicate I can query the database fine and the size of data.mdb does not change. Furthermore if new changes are propagated down to the replica the issue does not arise. Any help would be appreciated. Please find below configuration ldifs and version information. -Russell J. Jancewicz University of Connecticut Version: @(#) $OpenLDAP: slapd 2.4.35 (Jun 17 2013 12:21:32) $ My olcDatabaseConfig: # {1}mdb, config dn: olcDatabase={1}mdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbDirectory: /srv/ldap/example.com olcSuffix: dc=example,dc=com olcRootDN: dc=example,dc=com olcRootPW: secret olcDbMaxsize: 4294967296 olcDbNoSync: FALSE olcReadOnly: TRUE olcDbCheckpoint: 512 30 olcDbIndex: default pres,eq olcAccess: to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * break olcAccess: to * by * none olcSyncrepl: rid=101 provider=ldap://replica0.ldap.example.com starttls=critical bindmethod=simple binddn="dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 5 300 +" olcSyncrepl: rid=102 provider=ldap://replica1.ldap.example.com starttls=critical bindmethod=simple binddn="dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 5 300 +" # {1}memberof, {1}hdb, config dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: top objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof

13 years, 3 months

Re: TLS, integrity and root DSE

by Michael Ströder

On Wed, 24 Jul 2013 07:59:21 -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote > --On Wednesday, July 24, 2013 4:08 PM +0200 Ulrich Windl > <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > > > Hi! > > > > When trying to require integrity for LDAP connections by specifying > > "ssf=1" in Security, I have a problem with Perl where the cat bites its > > tail: > > > > It's recommended to query the root DSE for TLS extension before trying to > > use TLS like this: > > > > my $dse = $ldap->root_dse(); > > > > if ($dse->supported_extension(LDAP_EXTENSION_START_TLS)) { > > my $msg = $ldap->start_tls('verify' => 'require', > > 'capath' => '/etc/ssl/certs'); > > ... > > Personally, I just always try to startTLS regardless. Then you can decide > whether or not you wish to continue after that point based on whether or > not it succeeds or fails. >From RFC 2830, section 6 "Security Considerations": Additionally, an active-intermediary attacker can remove the Start TLS extended operation from the supportedExtension attribute of the root DSE. => Always try startTLS at the client side if set in local configuration. Furthermore from this section: Therefore, both parties SHOULD independently ascertain and consent to the security level achieved once TLS is established and before beginning use of the TLS connection. For example, the security level of the TLS connection might have been negotiated down to plaintext. So your client has to query the effective security level from the LDAP API and make a decision based on comparison to local config. Not sure which option to use in case of TLS though. Ciao, Michael.

13 years, 3 months

Re: Reg OpenLdap on Ubuntu

by Michael Ströder

Asimananda Mohanty wrote: > > The first command works fine (ldapsearch -x -H ldap://ldap-company.com > <http://ldap-company.com/> -ZZ) but the second one (ldapsearch -x -H > ldaps://ldap-company.com:636 <http://ldap-company.com:636/> -ZZ) is > showing error : > > *ldap_start_tls: Operations error (1)* Sorry, stupid copy&paste by me. Should have another coffee. Omit the -ZZ in the second command since LDAPS and StartTLS ext.op. cannot be used together. See also: http://www.openldap.org/faq/data/cache/605.html Ciao, Michael. -- Michael Ströder E-Mail: michael(a)stroeder.com http://www.stroeder.com

17 years, 3 months

Re: LDAPS Support

by Michael Ströder

On 06/05/2018 04:36 AM, web(a)tomjay.co.uk wrote: > I'm under the impression that LDAPS (and not StartTLS) has been > depreciated in OpenLDAP, but I can't find anything on the OpenLDAP > website that says this. Is this the case, and is there a reference for it? The "LDAPS is deprecated" is rather obsolete. It was caused by lack of formal specification for LDAPS. Personally I was always against this position. It simply works anyway. And any directory server vendor dropping support for LDAPS would be seriously punished by its customer base. See also the discussion I've started a couple of months ago: https://www.openldap.org/lists/openldap-technical/201802/msg00004.html Ciao, Michael.

8 years, 4 months

Re: LDAPS Support

by Dieter Klünter

Am Tue, 05 Jun 2018 03:36:11 +0100 schrieb web(a)tomjay.co.uk: > Hello, > > I'm under the impression that LDAPS (and not StartTLS) has been > depreciated in OpenLDAP, but I can't find anything on the OpenLDAP > website that says this. Is this the case, and is there a reference > for it? RFC 4511 and 4513 are quite clear about this. While start TLS is defined in RFC 2830, there is no formal specification for ldaps, furthermore read on ldaps in /etc/services. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

8 years, 4 months

Re: ldaprc with ldaps:// and ldap:// fallback

by Michael Ströder

Emmanuel Dreyfus wrote: > Dieter Kluenter <dieter(a)dkluenter.de> wrote: > >> No, ldapi:/// doesn't present a certificate, but you may establish a >> startTLS session to ldapi:///, in this case the client requests a >> server certificate. > > Let me rephrase: I would like to specify two LDAP servers in ldaprc > - one ldapi:/// with anonymous bind > - one ldaps:// with SASL EXTERNAL for and required server certificate > > It seems to me it is not possible. Why not use SASL/EXTERNAL in both cases and let slapd map SASL authc-DN to the same authz-DN? Ciao, Michael.

16 years, 4 months

openldap-technical search results for query "starttls"