Re: Secure replication

2017-05-09 Thread Quanah Gibson-Mount
--On Tuesday, May 09, 2017 2:11 AM + "Real, Elizabeth (392K)" 
 wrote:


Hi Elizabeth,


If "ldap://; is secure already then I do not need to proceed further.


That says nothing about whether or not your configuration is secure. 
Again, if it is "ldap://; with the startTLS LDAPv3 extension, and you've 
configured it be required that it succeed, then it is secure.  You've not 
provided the information that would be necessary to make such a 
determination.  I would again advise reading the slapd-config(5) man page 
for the olcSyncRepl attribute, specifically the bits on the starttls, 
tls_cacert/tls_cacertdir, tls_cipher_suite, and tls_protocol_min 
configuration parameters.


You may also want to set olcSecurity (A value of "ssf=1" requires any and 
all connections to the server be encrypted).  Changing this value from the 
default requires a server restart for it to go into effect.



SSLv3
TLSv1.2


Those look like protocol versions, not cipher suites. ;)


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.


You can read through the OpenLDAP Release notes here: 



Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:





Re: Secure replication

2017-05-09 Thread Michael Ströder
Ulrich Windl wrote:
 Michael Ströder  schrieb am 08.05.2017 um 23:39 in
>> When running different replicas which terminate TLS themselves you can issue 
>> a
>> different server cert with distinct subject-DN for each of them and put 
>> FQDN(s) of
>> the same HA address(es) (e.g. of your load-balancer(s)) into subjectAltName
>> extension in all these different server certs.
> 
> So you have one certificate for all servers, and the answer is that you cannot
> have different certificates? If so, we had discussed that before. I thought 
> you
> were advising otherwise now, and I was surprised how that would work.

Did you deliberately misread my answer? I cannot imagine how I can make more 
clear that I
have different certs on all replicas. And probably you also misread my former 
postings
about that topic.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Secure replication

2017-05-08 Thread Real, Elizabeth (392K)
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 <qua...@symas.com>
Reply-To: Quanah Gibson-Mount <qua...@symas.com>
Date: Saturday, May 6, 2017 at 1:02 PM
To: "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov>, 
"openldap-technical@openldap.org" <openldap-technical@openldap.org>
Subject: Re: Secure replication

--On Saturday, May 06, 2017 1:56 AM + "Real, Elizabeth (392K)"
<elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@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>




Re: Antw: Re: Secure replication

2017-05-08 Thread Michael Ströder
Ulrich Windl wrote:
> I have a related question: Can you have different certificates, depending on
> "Normal use" and replication? I guess no, so if you use a load balancer, 
> you'll
> have a problem with every server having a different cert (This is how I reaed
> your message).

Didn't we discuss that before?

When running different replicas which terminate TLS themselves you can issue a 
different
server cert with distinct subject-DN for each of them and put FQDN(s) of the 
same HA
address(es) (e.g. of your load-balancer(s)) into subjectAltName extension in 
all these
different server certs.

Does that answer your question?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Secure replication

2017-05-06 Thread Quanah Gibson-Mount
--On Saturday, May 06, 2017 1:56 AM + "Real, Elizabeth (392K)" 
 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:





Re: Secure replication

2017-05-06 Thread Alex M
On 05/06/2017 02:56 AM, Real, Elizabeth (392K) wrote:
> Hey guys,
> 
> I’m running multi-master OpenLDAP (version 2.4.40) servers and need to secure 
> replication. Can you point me to where I can find that information? What I 
> found online is old and does not apply to the version I’m running.
> 
> The olcSyncRepl directive on both systems needs to go from:
> olcSyncRepl: rid=001 provider=ldap
> to:
> olcSyncRepl: rid=001 provider=ldaps
> 
> Thank you,
> Liz
> 

Hi,

First you'll need to generate ssl certificates and enable tls/ssl on
your services.

After it is done you can use ldaps:// uri with tls parameters to point
to the provider/consumer servers.

This is discussed in multiple places, in addition to official openldap
admin guide just google your favorite linux distribution with openldap tls.





Re: Secure replication

2017-05-06 Thread Michael Ströder
Real, Elizabeth (392K) wrote:
> I’m running multi-master OpenLDAP (version 2.4.40) servers and need to secure
> replication. Can you point me to where I can find that information? What I 
> found online
> is old and does not apply to the version I’m running.

The term "secure replication" is a bit blurry.

In general I setup replication like this:
- TLS everywhere => every replica has server cert
- use the *individual* server certs as client certs for authenticating replicas
- use SASL/EXTERNAL with authz-regexp mapping to map to distinct replica entry
- use an LDAP group entry for replication ACLs
- tighten TLS protocol to 1.2
- set cipher settings to use perfect-forward secrecy (PFS)

YMMV

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature


Secure replication

2017-05-05 Thread Real, Elizabeth (392K)
Hey guys,

I’m running multi-master OpenLDAP (version 2.4.40) servers and need to secure 
replication. Can you point me to where I can find that information? What I 
found online is old and does not apply to the version I’m running.

The olcSyncRepl directive on both systems needs to go from:
olcSyncRepl: rid=001 provider=ldap
to:
olcSyncRepl: rid=001 provider=ldaps

Thank you,
Liz