I currently have a working openldap/tls/sssd setup with one ldap server. I'm using self signed server side and client side certificates and the CA for the certificates happens to live on the openldap server. This is, obviously, fraught with peril if the openldap server dies! So, I've setup a second server as a replica server and I want to be able to have my sssd clients failover to the replica if the primary goes away. Thus far, my testing has been unsuccessful. I've cut a server cert for the new server but when I try to use the secondary server as the authorized ldap server I get errors like:
additional info: TLS: hostname does not match CN in peer certificate
With my working setup I specify the ldap_tls_cacert, ldap_tls_cert, and ldap_tls_key in my sssd.conf, in my ldap.conf, and in my .ldaprc and authentication works and ldapsearch works (with starttls). If I change my ldap_tls_cert and key stuff to point to my 2nd server keys, everything fails. I'm not sure how to get this working. Ultimately, I'm going to have 4 total ldap servers, 2 each in disparate regions of the country, one of which is the "master" and the 3 others replicas. Any and all help appreciated as I'm very confused at this point.
Thanks.
Kevin Martin
On Fri, Feb 05, 2016 at 09:14:10PM -0000, Kevin Martin wrote:
I currently have a working openldap/tls/sssd setup with one ldap server. I'm using self signed server side and client side certificates and the CA for the certificates happens to live on the openldap server. This is, obviously, fraught with peril if the openldap server dies! So, I've setup a second server as a replica server and I want to be able to have my sssd clients failover to the replica if the primary goes away. Thus far, my testing has been unsuccessful. I've cut a server cert for the new server but when I try to use the secondary server as the authorized ldap server I get errors like:
additional info: TLS: hostname does not match CN in peer certificate
With my working setup I specify the ldap_tls_cacert, ldap_tls_cert, and ldap_tls_key in my sssd.conf, in my ldap.conf, and in my .ldaprc and authentication works and ldapsearch works (with starttls). If I change my ldap_tls_cert and key stuff to point to my 2nd server keys, everything fails. I'm not sure how to get this working. Ultimately, I'm going to have 4 total ldap servers, 2 each in disparate regions of the country, one of which is the "master" and the 3 others replicas. Any and all help appreciated as I'm very confused at this point.
This is a bit off-topic for this list, but I think a better way to be to trust the CA that issues the certs for your servers..
thanks for responding. After posting the question I went back and thought it over and realized what I needed to do to get this working and, it works now!
Kevin
On 05/02/2016 21:14, Kevin Martin wrote:
I currently have a working openldap/tls/sssd setup with one ldap server. I'm using self signed server side and client side certificates and the CA for the certificates happens to live on the openldap server. This is, obviously, fraught with peril if the openldap server dies! So, I've setup a second server as a replica server and I want to be able to have my sssd clients failover to the replica if the primary goes away. Thus far, my testing has been unsuccessful. I've cut a server cert for the new server but when I try to use the secondary server as the authorized ldap server I get errors like:
A better approach in my opinion is to load balance your LDAP servers and use a single address for your clients to point at. That way as your organisation or load grows you can just throw additional peers at the LDAP end and not worry about how the clients are configured.
keepalived and haproxy will do this very nicely.
On Thu, 11 Feb 2016, Liam Gretton wrote:
A better approach in my opinion is to load balance your LDAP servers and use a single address for your clients to point at. That way as your organisation or load grows you can just throw additional peers at the LDAP end and not worry about how the clients are configured.
keepalived and haproxy will do this very nicely.
What does that offer over using SRV records?
jh
On 11/02/2016 16:00, John Hodrien wrote:
keepalived and haproxy will do this very nicely.
What does that offer over using SRV records?
That's another way of doing it, I think that's what Active Directory does, correct?
With HA Proxy you get more options for load balancing which can be useful.
On Thu, 11 Feb 2016, Liam Gretton wrote:
On 11/02/2016 16:00, John Hodrien wrote:
keepalived and haproxy will do this very nicely.
What does that offer over using SRV records?
That's another way of doing it, I think that's what Active Directory does, correct?
Yes. Paired with "sites", you get a fairly flexible method for balancing usage.
With HA Proxy you get more options for load balancing which can be useful.
SRV works well when a server goes bad. If server returns a result that tells the client that there's an error (rather than failing to return a result), SSSD can mark the server as bad, and try another one.
If they're all hiding behind a single IP, you lose that ability as far as I can see.
jh
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
John Hodrien -
Kevin Martin -
Liam Gretton