How to Configure Redundant LDAP Authorization?

13 views
Skip to first unread message

Jason Smyth

unread,
May 17, 2024, 10:53:54 AMMay 17
to go-cd
Hi everyone,

We are looking to move from the bundled LDAP authentication plugin to the LDAP authorization plugin.

For redundancy, our current setup uses 2 LDAP connectors, each pointing to a different Active Directory domain controller in the same domain.  If we switch to the LDAP authorization plugin we can still create redundant authentication links, but does this mean we will need to create duplicate role configurations as well?

Is there any documentation we should be referencing in terms of the "right" way to set up a redundant connection to AD?

Any feedback is appreciated.

Regards,
Jason Smyth

Sriram Narayanan

unread,
May 17, 2024, 12:46:32 PMMay 17
to go...@googlegroups.com
For connection redundancy, I’ve used TCP load balancers. For on premise setups, I’ve used DNS round robin to point to two different load balancer instances.



Any feedback is appreciated.

Regards,
Jason Smyth

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/4b37a890-f442-4966-a053-0fb985f73e3cn%40googlegroups.com.

Jason Smyth

unread,
May 17, 2024, 2:29:00 PMMay 17
to go...@googlegroups.com

Hi Sriram,

 

Thank you for the feedback.

 

Do you know how the plugin handles SSL negotiation? We considered DNS round-robin but ruled it a non-starter, under the assumption that LDAPS would require that the hostname and certificate name match.

 

Regards,

Jason Smyth

--
You received this message because you are subscribed to a topic in the Google Groups "go-cd" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/go-cd/eEHCCj-vOuo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CANiY96ZECHfCOjUw5f-XS6kvsChV%2B8K%3Dry21%3DW%3DeOuFM011opw%40mail.gmail.com.

Chad Wilson

unread,
May 17, 2024, 11:22:03 PMMay 17
to go...@googlegroups.com
I discovered recently that the plugins are on an ancient version of the Apache LDAP library that means they don't actually seem to validate the server certs fully by default (e.g on expiry), so may not validate the hostname either. But that's probably a bug, not a feature? Your call if you want to give it a go and rely on it for now.

If the default is made more secure in future I'd like to think there's be an opt-out. But yeah - those LDAP plugins need some love.

-Chad

Chad Wilson

unread,
May 18, 2024, 12:19:32 AMMay 18
to go...@googlegroups.com
Minor correction, it's possible the LDAP authz plugin is validating the certs in a way that the authentication plugin does not, despite both being on old LDAP client API versions. Would need to dig deeper to validate.


Vs


-Chad

Jason Smyth

unread,
May 21, 2024, 11:46:51 AMMay 21
to go...@googlegroups.com

Hi Chad,

 

Thank you for the feedback.

 

I ran some tests, and it seems that the LDAP Authorization plugin does not validate that the certificate name matches. At least, I was able to successfully connect using both hostname and IP address.

 

So, it seems our options are:

 

  1. Use round-robin DNS or a TCP load balancer and accept the risk that a future update to the plugin may tighten security and break our implementation, or
  2. Create duplicate LDAP Authorization connectors like we currently have for LDAP Authentication and accept that we would need duplicate role configurations as well.

 

Does that seem about right? Is there anything I am mssing?

 

Regards,

Jason Smyth

Sriram Narayanan

unread,
May 21, 2024, 12:10:31 PMMay 21
to go...@googlegroups.com
On Tue, May 21, 2024 at 11:46 PM Jason Smyth <JSm...@taqauto.com> wrote:

Hi Chad,

 

Thank you for the feedback.

 

I ran some tests, and it seems that the LDAP Authorization plugin does not validate that the certificate name matches. At least, I was able to successfully connect using both hostname and IP address.

 

So, it seems our options are:

 

  1. Use round-robin DNS or a TCP load balancer and accept the risk that a future update to the plugin may tighten security and break our implementation, or
  2. Create duplicate LDAP Authorization connectors like we currently have for LDAP Authentication and accept that we would need duplicate role configurations as well.

 

Does that seem about right? Is there anything I am mssing?


I had missed replying to you earlier. I wanted to clarify that my LDAP Authentication load balancing was for SVN and Git repositories. I used the pen load balancer back then, and later haproxy. What I wanted to communicate is that it is possible to TCP load-balance LDAPS calls to different AD servers, with the focus of LDAPS clients being more on ensuring that the OU and such are correct and the TLS name on the cert not being that important (i.e. matching what Chad suggested and you observed first hand).

Another note: I had also configured VRRP to make multiple physical pen load balancers available on the same IP address. While we never had an incident, we had tested the fail-over by pulling the network cables out as part of a test plan. 


Reply all
Reply to author
Forward
0 new messages