--On Saturday, May 06, 2017 1:56 AM +0000 "Real, Elizabeth (392K)" Elizabeth.Real@jpl.nasa.gov wrote:
The olcSyncRepl directive on both systems needs to go from:
olcSyncRepl: rid=001 provider=ldap
to:
olcSyncRepl: rid=001 provider=ldaps
The use of "ldap://" does not mean that you have insecure replication. The "ldaps" designation was developed to allow for SSL encrypted connections as a part of LDAPv2, which did not have a formal design spec for allowing SSL encryption. The LDAPv3 spec, which is what OpenLDAP 2.4 (and much earlier version) implement, specifically has startTLS as a part of that specification, which uses "ldap:///". I.e., ldaps is a bastardized hack for LDAPv2. The proper way to do TLS encryption with LDAPv3 capable servers such as OpenLDAP 2.[1-4+] is to use the startTLS extended operation over a "ldap:///" URI.
In addition, there are other ways to have an encrypted connection between an LDAP client and server without involving TLS at all, such as SASL/GSSAPI.
As Michael noted, you can, in addition to enabling TLS encryption between the client and servers, use client cert authentication (SASL/EXTERNAL) so as to remove the requirement for clear text credentials to be stored in the olcSyncRepl attribute (if using simple binds). And again, the usage of SASL/GSSAPI also precludes the neccessity of storing cleartext credentials in the olcSyncRepl attribute.
As an aside, I would note that 2.4.40 is completely unsafe to use with multimaster replication.
I would generally suggest forming a clear set of requirements for your replication environment, and then asking how to implement them. Your current question is too vague/general to really be answered well.
Hope that helps!
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah,
I ran netstat -a | egrep ":ldap" and found that the replication between my two test servers was not ldaps thus me reaching out to this forum.
If “ldap://” is secure already then I do not need to proceed further. These are the SLAPD_URLS in the /etc/sysconfig/slapd file: SLAPD_URLS="ldapi:/// ldap:/// ldaps:///"
I have TLS enabled everywhere and have encrypted connections between clients and servers.
These are the ciphers running on both masters: SSLv3 TLSv1.2
I am using simple binds so I’ll look at SASL/EXTERNAL with authz-regexp mapping.
Why is version 2.4.40 unsafe for multi-master replication? I can upgrade at a later time I just wanted to find out how to enable ldaps between the two servers.
Thank you, Liz
From: Quanah Gibson-Mount quanah@symas.com Reply-To: Quanah Gibson-Mount quanah@symas.com Date: Saturday, May 6, 2017 at 1:02 PM To: "Real, Elizabeth (392K)" Elizabeth.Real@jpl.nasa.gov, "openldap-technical@openldap.org" openldap-technical@openldap.org Subject: Re: Secure replication
--On Saturday, May 06, 2017 1:56 AM +0000 "Real, Elizabeth (392K)" <Elizabeth.Real@jpl.nasa.govmailto:Elizabeth.Real@jpl.nasa.gov> wrote:
The olcSyncRepl directive on both systems needs to go from:
olcSyncRepl: rid=001 provider=ldap
to:
olcSyncRepl: rid=001 provider=ldaps
The use of "ldap://" does not mean that you have insecure replication. The "ldaps" designation was developed to allow for SSL encrypted connections as a part of LDAPv2, which did not have a formal design spec for allowing SSL encryption. The LDAPv3 spec, which is what OpenLDAP 2.4 (and much earlier version) implement, specifically has startTLS as a part of that specification, which uses "ldap:///". I.e., ldaps is a bastardized hack for LDAPv2. The proper way to do TLS encryption with LDAPv3 capable servers such as OpenLDAP 2.[1-4+] is to use the startTLS extended operation over a "ldap:///" URI.
In addition, there are other ways to have an encrypted connection between an LDAP client and server without involving TLS at all, such as SASL/GSSAPI.
As Michael noted, you can, in addition to enabling TLS encryption between the client and servers, use client cert authentication (SASL/EXTERNAL) so as to remove the requirement for clear text credentials to be stored in the olcSyncRepl attribute (if using simple binds). And again, the usage of SASL/GSSAPI also precludes the neccessity of storing cleartext credentials in the olcSyncRepl attribute.
As an aside, I would note that 2.4.40 is completely unsafe to use with multimaster replication.
I would generally suggest forming a clear set of requirements for your replication environment, and then asking how to implement them. Your current question is too vague/general to really be answered well.
Hope that helps!
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Quanah Gibson-Mount -
Real, Elizabeth (392K)