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.
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
--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>
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.
"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
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,
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.
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
--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
Hi Michael,
On Monday, 28. May 2012, Michael Ströder wrote:
> Peter Marschall wrote:
> > On Monday, 28. May 2012, Philip Guenther wrote:
> >> On Mon, 28 May 2012, Michael Ströder wrote:
> >>> Peter Marschall wrote:
> >>>> how do the openldap tools technically verfify certificates with
> >>>> ldapi:// ?
> >>>
> >>> Which certs do you want to verify?
> >>
> >> I assume the answer is "the one the server returns when you do StartTLS
> >> on the ldapi:// connection".
> >
> > Correct.
>
> So if the quite liberal RFC 6125 does not provide any inspiration this
> boils down to being undefined. StartTLS over LDAPI is an unusal scenario
> anyway.
Thanks for your reply.
It helps a bit ("looking at the issue from the standard angle"), but
my question was how the openldap tools do it.
Best
Peter
--
Peter Marschall
peter(a)adpm.de
