How to Configure Redundant LDAP Authorization?

[Jason Smyth]

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]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/DM6PR16MB36713451AFA69A524EC80AB6CFEE2%40DM6PR16MB3671.namprd16.prod.outlook.com.

[Chad Wilson]

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.

https://github.com/gocd/gocd-ldap-authentication-plugin/blob/a0236ed52cc95646f322220c72a20360893c548c/src/main/java/cd/go/apacheds/ConnectionConfiguration.java

Vs

https://github.com/gocd/gocd-ldap-authorization-plugin/blob/master/src/main/java/com/thoughtworks/gocd/authorization/ldap/apacheds/ConnectionConfiguration.java

-Chad

[Jason Smyth]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CAA1RwH8AuQbTdpa37pBi3TaRGTa%3DKH%2Bq2X2UxKeOE3DazpdRSA%40mail.gmail.com.

[Sriram Narayanan]

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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/DM6PR16MB36711D531B13495FEDA4CF0ECFEA2%40DM6PR16MB3671.namprd16.prod.outlook.com.