Yes, I conflated SSL and SASL in my answer.   So let me clean that up…

So, let’s say that my F5 is load balancing based on the name 
ldapserver.example.com.  In the slapd.conf file each of my real servers use, I 
put the statement:

sasl-host ldapserver.example.com

And in the keytab file that each OpenLDAP server uses, I have a key for 
ldap/ldapserver.example.com@realm

Now, when a GSSAPI connection comes in, OpenLDAP talks to SASL using the 
ldap/ldapserver.example.com@realm key and verifies that the GSSAPI package is 
all good. 

I honestly do not know if AD has the equivalent of the OpenLDAP sasl-host 
configuration option or not.

—
Frank Swasey
Systems Architecture & Administration

From:  Tadashi Inayama <t...@qad.com>
Date:  Tuesday, February 16, 2016 at 1:37 PM
To:  Frank Swasey <frank.swa...@uvm.edu>
Cc:  "cyrus-sasl@lists.andrew.cmu.edu" <cyrus-sasl@lists.andrew.cmu.edu>
Subject:  Re: Load-balancing LDAP using GSSAPI/Kerberos/Cryus-SASL

Hello Frank, 

Thank very much you for your reply.  I believe that the solution you are 
mentioning applies more to load-balancing services that uses ssl certs, such as 
https.  Please correct me if I am wrong.  (Or does kerberos\gssapi\sasl use SSL 
Cert somewhere along the chain?)


RedHat Support referred me to this blog:  

https://ssimo.org/blog/id_019.html


In this example, the three https web servers that required kerberos 
authentication for access were load-balanced.  


So the picture looked something more like this:


uno.ipa.com    due.ipa.com    tre.ipa.com 
            \               |            /
             \              |           /
              \             |          /
               \            |         /
                \           |        /

                   all.ipa.com   (F5 Load Balancer Virtual Server)   

                            |
                            |
                            |
              linux_client.ipa.com   ------ authentication request 
------------>    KCD (OpenLDAP/Active Directory)
                                              <------ kerberos ticket 
-------------------------


In this case we can have the ssl certs use shared hostnames so we can list 
uno.ipa.com, due.ipa.com, and tre.ipa.com in the all.ipa.com cert under shared 
name.  (A wild card cert may work also.)

What we are attempting to do is slightly different.  We are tryin to 
load-balance the Active Directory Domain Controllers.  We can use shared name 
for SSL Certs, but is there a mechanism either (1) within kerberos to share the 
hostnames for SPN's or (2) configure Cyrus-SASL to let us use the keytab for 
authentication so we can import the keys for the domain controllers into the 
keytab stored the linux clients.

Thank you,
Tadashi



A redundant picture:

dc1.test.com     dc2.test.com  (Windows Domain Controllers)
      \                          /
       \                        /
        \                      /
         \                    /
          ldap.test.com (virtual server on F5 LTM)
                   |
                   |
                   |
             linux_client.test.com









On Tue, Feb 16, 2016 at 5:25 AM, Frank Swasey <frank.swa...@uvm.edu> wrote:
With OpenLDAP you solve this by using an ssl cert with Alternative names on 
each server – and you use the sasl-host parameter to tell OpenLDAP to use that 
common name between the various certs on the actual LDAP servers.  How you 
duplicate that in AD is left to the reader…

—
Frank Swasey
Systems Architecture & Administration

From: Cyrus-sasl <cyrus-sasl-bounces+frank.swasey=uvm....@lists.andrew.cmu.edu> 
on behalf of Tadashi Inayama via Cyrus-sasl <cyrus-sasl@lists.andrew.cmu.edu>
Reply-To: Tadashi Inayama <t...@qad.com>
Date: Friday, February 12, 2016 at 5:10 PM
To: "cyrus-sasl@lists.andrew.cmu.edu" <cyrus-sasl@lists.andrew.cmu.edu>
Subject: Load-balancing LDAP using GSSAPI/Kerberos/Cryus-SASL

Hello, 

I am new to using GSSAPI/Kerberos/SASL but we got it working for authorization 
for LDAP queries from RHEL 5.11 and RHEL 6.7 clients against Win2k12 R2 Domain 
Controllers.

But when we try to load balance the LDAP traffic with F5 LTM (with dc1.test.com 
and dc2.test.com as the pool members), ldapsearch via gssapi works half the 
time, and the other half we get an error that the message is changed 
mid-stream.  We are guessing that Cyrus-SASL does a reverse dns lookup of the 
domain controllers as a final check, and if the ip address of the domain 
controller does not match the hostname of the F5 Virtual Server then the error 
pops back as message changed mid-stream.  So it work half of the time.

So we did some googling and came across this post:

http://www.openldap.org/lists/openldap-software/200902/msg00019.html

"There is a work around for this at the GSSAPI layer, which is to tell the 
server to trust any principal that exists in the service's keytab. 
Unfortunately, Cyrus SASL doesn't seem to expose a mechanism for doing this, 
and so the only way to do so is via a code change to the SASL library."

This post was from 2009.  So is there currently a mechanism in Cyrus SASL to 
trust the principals whose key exists in the krb5.keytab?  Or is there some 
established method to load balance between two MS Domain Controllers?

(The reason we are trying to load balance the ldap queries is so that when we 
perform patch or other maintenance work on the individual domain controllers, 
we don't break the authentication/authorization on the RHEL servers.  Without 
load balancing, we will need to change the authentication server entries on 
krb5.conf and sssd.conf in each of the RHEL servers.  And we already have dns, 
ntp, and kerberos load-balancing using the F5, we just need to get the ldap 
portion completed.)

Thank you very much,
Tadashi


dc1.test.com     dc2.test.com  (Windows Domain Controllers)
      \                          /
       \                        /
        \                      /
         \                    /
          ldap.test.com (virtual server on F5 LTM)
                   |
                   |
                   |
             linux_client.test.com



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to