Search results for "starttls" - openldap-technical

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation

by Dieter Kluenter

Robert Heller <heller(a)deepsoft.com> writes: R> At Thu, 28 Sep 2017 10:19:43 -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > >> >> --On Thursday, September 28, 2017 2:08 PM -0400 Robert Heller >> <heller(a)deepsoft.com> wrote: >> >> > OK, I have narrowed things down to slapd and sssd not playing nice with >> > each other. slapd is able to listen on ldaps (port 636) and accept SSL >> > connections (eg from openssl s_client and other applications using >> > straight SSL). slapd will also listen on ldap (port 389), but refuses >> > to negotiate a TLS connection on port 389. It also refuses to negotiate >> > TLS connection on port 636. sssd seems to *insist* on negotiating a TLS >> > connection on port 636 or port 389 and won't just connect using ssl to >> > port 636. (At least that is what I *think* is going on.) >> > >> > So, I either need to get slapd to do TLS negotiation on port 389 OR port >> > 636, or get sssd to NOT do TLS negotiation on port 636 and just connect >> > with SSL. >> >> You're using a bit of a confusing word soup. > > Well, yes... > >> >> ldaps == Deprecated, non-standard way of securing connection to LDAP. >> Usually on port 636 >> startTLS == RFC standard way of securing connections to LDAP. Usually on >> port 389 > > > >> >> If you are using ldaps, then you want startTLS to be disabled >> if you are using startTLS, then you want it enabled. >> >> Your SSD config has: >> >> ldap_id_use_start_tls = false >> >> so this would be correct with use with ldaps:/// > > But SSSD does not work with ldaps:///... It *wants* startTLS over ldap:///, > which does not *seem* to work. > >> >> You don't provide any error messages or other useful information, so one >> can only specualte what issues you may be having. > > Slapd is reporting TLS Negotiation failure when SSSD tries to connect to it. > For both port 389 (ldap:///) and 636 (ldaps:///). So I guess something is > wrong with slapd's TLS configuration -- it is failing to do TLS Negotiation, > either it is just not doing it or it is doing it wrong (somehow). Unless SSSD > is not configured properly. >> >> I would note that most versions of openssl s_client do not support startTLS >> with LDAP (Thus you cannot use it to test port 389). That feature was only >> recently added to OpenSSL. OK, back to basics, 1. check whether sssd is compiled with openssl's libcrypto: ldd sssd which should present something like libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 2. check whether slapd has been build with openssl ldd slapd, which should present: libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 3. verify your certificates: openssl verify -CAfile <file> <hostcert> 4. run slapd -h ldaps:///; than test connection: openssl s_client -connect <host:636> -CAfile <file> -Dieter >> If you want to test startTLS on port 389, your best bet is to use an ldap >> client utility such as ldapwhoami, like: >> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w [...] -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

7 years, 8 months

Re: IETF opinion change on "implicit TLS" vs. StartTLS

by Michael Ströder

Dieter Klünter wrote: > Am Mon, 12 Feb 2018 18:10:29 -0800 > schrieb Quanah Gibson-Mount <quanah(a)symas.com>: > >> --On Tuesday, February 13, 2018 9:31 AM +1000 William Brown >> <wibrown(a)redhat.com> wrote: >> >>> On Mon, 2018-02-12 at 14:30 +0100, Michael Ströder wrote: >>>> HI! >>>> >>>> To me this rationale for SMTP submission with implicit TLS seems >>>> also applicable to LDAPS vs. StartTLS: >>>> >>>> https://tools.ietf.org/html/rfc8314#appendix-A >>>> >>>> So LDAPS should not be considered deprecated. Rather it should be >>>> recommended and the _optional_ use of StartTLS should be strongly >>>> discouraged. >>> >>> Yes, I strongly agree with this. I have evidence to this fact and >>> can provide it if required, >> >> Personally, I'm all for it. I'd suggest using the above RFC as a >> template for one formalizing port 636, so it's finally a documented >> standard. > > We have had discussed this topic some 10 years ago, at that time Kurt > had some concerns with regard to ldaps and port 636. Unfortunately I > can't remember details. The above mentioned Appendix A references this section which summarizes the concerns: https://tools.ietf.org/html/rfc2595#section-7 IMO all these "issues" were even debatable at that time. Ciao, Michael.

7 years, 3 months

TLS very strange behaviour

by Olivier

Hello, I have two ldap servers, my goal is to configure them in multimaster mode with an sasl authentication based on certificates. With the following configurations, that works well : ### slapd.conf for ldap1 : 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 authcid="cn=replicator,ou=system,dc=example,dc=fr" authzid="dn:cn=replicator,ou=system,dc=example,dc=fr" tls_cert=/etc/openldap/cacerts/syncrepl.crt tls_key=/etc/openldap/cacerts/syncrepl.key tls_reqcert=demand mirrormode on ### slapd.conf for ldap1 : 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 authcid="cn=replicator,ou=system,dc=example,dc=fr" authzid="dn:cn=replicator,ou=system,dc=example,dc=fr" tls_cert=/etc/openldap/cacerts/syncrepl.crt tls_key=/etc/openldap/cacerts/syncrepl.key tls_reqcert=demand mirrormode on # of course I have provided the CA certificate in both files. TLSCACertificateFile /etc/openldap/cacerts/CA.crt # I also configured properly acl for "replicator" # and have issued the right certificate -> No problem, it works. Now I also have configured certificates to be able to talk with the servers on TLS : ### slapd.conf for ldap1 : TLSCertificateFile /etc/openldap/cacerts/server1.crt TLSCertificateKeyFile /etc/openldap/cacerts/server1.key TLSCipherSuite HIGH ### slapd.conf for ldap2 : TLSCertificateFile /etc/openldap/cacerts/server2.crt TLSCertificateKeyFile /etc/openldap/cacerts/server2.key TLSCipherSuite HIGH That also works perfectly ( ldapsearch with -ZZ responds properly ) I therefore decided to try to starttls for synchronisation. I added in syncrepl for ldap1 : ## ldap1 syncrepl ... starttls=yes tls_cacert=/etc/openldap/cacerts/CA.crt ... And the synchronizations worked well, TLS being started when ldap1 is client. I then added the starttls directive on server ldap2 and removed it on server ldap1 : ## ldap2 syncrepl ... starttls=yes tls_cacert=/etc/openldap/cacerts/CA.crt ... The synchronization also worked well, TLS being started this time when ldap2 is client. HERE IS THE PROBLEM : II tried to starttls in bothe syncrepl directives on both servers ldap1 and ldap2, 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 ? --- Olivier

13 years, 8 months

RE: [EXTERNAL] Re: back-ldap and ldaps not working

by Quanah Gibson-Mount

--On Friday, July 07, 2017 9:39 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > Yeah, that's actually how I started and where the starttls=no setting > came from. > > This .conf section > > overlay chain > chain-uri "ldaps://ds2-q.global.aep.com" > chain-rebind-as-user TRUE > chain-idassert-bind bindmethod=simple > binddn="cn=syncuser,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" > credentials=<redacted> mode="self" chain-tls ldaps > tls_cacert=/appl/openldap/etc/openldap/tls/cacerts.cer chain-return-error > TRUE Hm, if the conversion is adding that "starttls=no" to the cn=config database, that seems like a serious bug in the conversion process. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 years, 11 months

RE: slapo-chain + TLS = help

by Chris Jacobs

There are some good instances where StartTLS isn't attractive: when the LDAP servers are behind F5 BigIPs for example. My 2 cents. - chris This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

12 years, 10 months

Re: Understanding TLS SSF

by Dieter Kluenter

"Patrick Patterson" <ppatters(a)gmail.com> writes: > Hello > > On Wed, Jul 30, 2008 at 9:59 AM, J Davis <mrsalty0(a)gmail.com> wrote: > > Greetings, > > I'm testing an installation of openldap 2.4.9. I want to enforce TLS for > all access to the directory. > My problem is that I cannot get the client to meet the ssf restictions I > have in place. The documentation I've seen on ssf and tls_ssf is very > sparse so I don't really understand what it does. > > I'm using self signed cert created using the openssl CA.sh script. > > Relevant portions of the slapd.conf... > > TLSCACertificateFile /etc/ldap/ssl/cacert.pem > TLSCertificateFile /etc/ldap/ssl/servercrt.pem > TLSCertificateKeyFile /etc/ldap/ssl/serverkey.pem > ... > access to * > by tls_ssf=128 ssf=128 anonymous auth > by tls_ssf=128 ssf=128 self write > > Relevant portions of the lapd.conf... > > TLS_CACERT /etc/ldap/ssl/cacert.pem > > With those ACLs in place I get the following error: > > $ ldapsearch -x -ZZ -D "uid=jake,ou=people,dc=example,dc=com" -W -b > "uid=jake,ou=people,dc=example,dc=com" > ldap_bind: Invalid credentials (49) > > You may want to try adding -q as one of the options to your ldapsearch. It > appears that the tls_ssf turns on STARTTLS, instead of LDAP over SSL and in > order to use that, you need to tell the client to use starttls as well, which > is what (if I read the man page correctly), -q does. Where did you read this? from man ldapsearch(5) -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

16 years, 10 months

Re: problem with syncrepl and STARTTLS

by r0m5

Le 2017-06-02 17:46, r0m5 a écrit : > Le 2017-06-02 16:55, Quanah Gibson-Mount a écrit : > --On Friday, June 02, 2017 11:01 AM +0200 r0m5 <r0m5(a)r0m5.eu> wrote: > > Hello, > > I am facing an issue with syncrepl and STARTTLS on 389 port. The kind of > problem happening only sometimes, and disappearing "by itself". I use > Debian Jessie, OpenLDAP 2.4.40+dfsg-1+deb8u2. > 2.4.40 is 2.5 years old, 5 point releases behind, and had significant known replication issues. I believe there is a build of 2.4.44 in backports for Jessie. I would advise using that instead. > > As far as debug logging, you would need to use "-d -1" to slapd, rather than attempting to set the loglevel to -1, as some debug logging is only possible via the slapd daemon. But your first step is to move to a current release. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> Hello ! Thanks for your reply. I just upgraded the preproduction environment provider and consumers to the jessie-backports version. I will check the prod to preprod injections during the next days then let you know. Have a good weekend ! Hello ! I upgraded to 2.4.44 but still had problems (less, though). So I used "-d -1" with slapd instead of olcLoglevel as you said then I noticed there was a problem with certificate validation even with using demand or allow for TLS reqcert in olcSyncrepl and in /etc/ldap/ldap.conf. I was at that time using self-signed certificates. So I set up a PKI and now it looks OK regarding syncrepl. So I guess my problem might be related to ITS#8427, which I didn't see before posting here. I still have issues though, with applications randomly failing STARTTLS to my consumers :-( Regards,

7 years, 10 months

RE: Strange behavior with TLS with self-signed certs

by Chris Jacobs

Equipment limitation: Our old load balancers could load balance StartTLS, not SSL. Our new ones can load balance SSL, not StartTLS. Paranoia: If you wish to encrypt the entire session, from the very beginning, use SSL. Firewall limits you to port 389 (corp policy, difficult network/firewall team, etc): ... and want encryption, then use StartTLS. - chris From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Michael Starling Sent: Friday, January 07, 2011 11:45 AM To: daff(a)pseudoterminal.org; openldap-technical(a)openldap.org Subject: RE: Strange behavior with TLS with self-signed certs Ok..I implemented what you explained for testing purposes and found the following to be true: If I use ssl start_tls with the ldap:// URL schema then my client connects to my LDAP server on port 389. If I use ssl on with ldaps://. then my client connects on port 636. I think i remember reading somewhere that TLS could use either port so my question is when my client connects on 389 using ssl start_tls is the session encrypted? My other question would be why the two different means to the same end? Is it just a matter of which port you want to use? -Mike > From: daff(a)pseudoterminal.org > To: openldap-technical(a)openldap.org > Subject: Re: Strange behavior with TLS with self-signed certs > Date: Fri, 7 Jan 2011 19:45:46 +0100 > > On Friday 07 January 2011 04:18:40 Michael Starling wrote: > > #TLS settings > > ssl start_tls > > ssl on > > That should be either "ssl start_tls" OR "ssl on", not both. If you > specify "ssl start_tls" then you should use the ldap:// URL schema, if > you specify "ssl on" then you should use ldaps://. > > Andreas ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

14 years, 5 months

Syncrepl TLS certificate verification - configurable

by Siddhartha Jain

Hi, I have setup replication between two primary servers to use TLS. The config says: {0}rid=101 provider=ldap://pldap01.xyz.net binddn="cn=Manager,dc=xyz,dc=net" bindmethod=simple credentials=secret searchbase="dc=xyz,dc=net" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cert=/etc/openldap/cacerts/newcert.pem tls_cacert=/etc/openldap/cacerts/cacert.pem tls_key=/etc/openldap/cacerts/newreq.pem {1}rid=102 provider=ldap://pldap02.xyz.net binddn="cn=Manager,dc=xyz,dc=net" bindmethod=simple credentials=secret searchbase="dc=xyz,dc=net" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cert=/etc/openldap/cacerts/newcert.pem tls_cacert=/etc/openldap/cacerts/cacert.pem tls_key=/etc/openldap/cacerts/newreq.pem Replication works alright but logs show these lines on pldap01: Apr 22 03:47:20 pldap01 slapd[3451]: conn=1089 fd=22 TLS established tls_ssf=256 ssf=256 Apr 22 03:47:20 pldap01 slapd[3451]: slap_client_connect: URI=ldap://pldap02.xyz.net Warning, ldap_start_tls failed (-11) And, this on pldap02: Apr 22 03:47:40 pldap02 slapd[2564]: conn=1096 fd=26 TLS established tls_ssf=256 ssf=256 Apr 22 03:47:51 pldap02 slapd[2564]: slap_client_connect: URI=ldap://pldap01.xyz.net Warning, ldap_start_tls failed (-11) To be fair, the certificates are self-signed and don't match the DN but I am assuming that "starttls=yes" forces TLS and the consumers cannot default to plaintext. Right? If yes, does this mean that in syncrepl, tls use is hardcoded to verify certificates and fall back to non-verified TLS session if verification fails? Or, is this configurable meaning can I enforce verification (preferable in production)? Thanks, - Siddhartha

15 years, 1 month

Re: STARTTLS vs LDAPS

by Quanah Gibson-Mount

--On Thursday, March 31, 2022 12:16 PM -0400 Braiam <braiamp(a)gmail.com> wrote: > What would be the process to modify content on the openldap.org page? Depends on the content. The main web pages are in the OpenLDAP Web git repository. --Quanah

3 years, 2 months

openldap-technical search results for query "starttls"