Docker Community Forums

Share and learn in the Docker community.

DTR 1.1.1: Any chance to configure LDAP auth with more than one backend server?


(Andreasaskrause) #1

Hi, I tried to configure more than one LDAP server in Auth Settings. Neither of these work:

ldaps://ldap1 ldaps://ldap2
ldaps://ldap1,ldaps://ldap2
ldap1 ldap2
ldap1,ldap2

whereas these two work:

ldaps://ldap1
ldap1

Is there any way to configure more than one LDAP server to be used by docker_trusted_registry_auth_server?

Regards, Andreas


(Brandon Mangold) #2

Hi Andreas! What would the behavior be? Would DTR try multiple severs until it got a ‘yes’ response, ignoring any ‘No’ responses along the way? Is this for load balancing purposes in case the first LDAP cannot be reached (timeout), then tries the next LDAP server if it gets no response?

Would love to hear more about this and your specific use cases! Also, do you use any other products/tools that support what you want to do?


(Ryan Trauntvein) #3

Failover / Loadbalancing would be my use case.

For example, a replicated directory environment. I may have three replicas of my LDAP tree in different geographical sites.

192.168.5.1 - site A
192.168.6.1 - site B
192.168.7.1 - site C

All servers should have the same user data, but if one fails or goes offline it is nice to have the built in capability to failover.


(Brandon Mangold) #4

If you set a DNS entry with multiple A record entries for each and every LDAP server you have access to in your ‘site’, DTR will try the first A record entry that comes back from a DNS lookup. If this A record entry cannot be contacted (timeout), it will try the next DNS A record, until it exhausts all of them.

So, if you have this:
;; ANSWER SECTION:
your_ldap_server.intranet.example.com. 60 IN A 192.168.5.1
your_ldap_server.intranet.example.com. 60 IN A 192.168.6.1
your_ldap_server.intranet.example.com. 60 IN A 192.168.7.1

… DTR will try 192.168.5.1 , then 192.168.6.1, then 192.168.7.1 (stops upon successful connection) … I think with this, you will have to test the order of the A records that come back if order matters. However, in your case, since you have three replicas, it should not matter which you are using.


(Ryan Trauntvein) #5

Fair enough, that would be an acceptable solution :sunglasses:


(Brandon Mangold) #6

@djdefi In an environment without access to configuring DNS records, this approach wouldnt work. Also, there is a timeout delay that gets added for each failed LDAP attempt so there is a tradeoff involved. Can you think of any other problems that you might encounter with this? Or think of any alternative theoretical solutions?


(Ryan Trauntvein) #7

I agree that DNS may not always be an option.

I have encountered some pretty kludgey environments, especially in the primary and secondary education and government orgs.

Some other non-standard use cases for directory failover:

  • Directory replicas setup where a site may be listening on
    a non-standard port.
  • Some replicas may not use SSL, while others do
    (not a great situation, but sometimes it happens.)

Another LDAP possibility would be to allow support for multiple different (non-replicated) directories.

Example:

  • 1 Open LDAP server
  • 1 Active Directory server

One could specify credentials and a search OU for each directory tree, and they would be aggregated together, granting or denying access based on the first match. Maybe have a way to specify the order of directories checked.


(Andreasaskrause) #8

Hi Brandon,

first, sorry for not responding last week, I was in short vacation.

My use case is availability, so in case the first LDAP server cannot be reached, the next is tried. All LDAP servers have a distinct IP address.

@Ryan, such a environment is not as kludgy as you might think. Just have a look at the ldap.conf manpage or the one for sssd.conf, both accept multiple LDAP servers in its URI/ldap_uri parameter. Even for the DNS-based HA setup I found the suggestion to state multiple URIs with the same name to allow multiple connect attempts: https://linux.web.cern.ch/linux/docs/account-mgmt.shtml