Issues with LDAP failover (FreeRad 3.0.22)
Hi Team, I'm having issues getting LDAP group membership checking working with multiple LDAP servers. Here's my config: ldap { server = "${ldap.2} ${ldap.1}" # server = "${ldap.1}" server = "${ldap.3}" server = "${ldap.4}" base_dn = 'DC=thing,DC=local' identity = ${eduroamLDAPAccount.username} password = ${eduroamLDAPAccount.password} user { base_dn = "${..base_dn}" scope = sub filter = "(&(objectclass=user)(sAMAccountName=%{Stripped-User-Name}))" } group { base_dn = "${..base_dn}" filter = "(objectclass=group)" membership_filter = "(member=%{control:Ldap-UserDn})" cacheable_name ='yes' cacheable_dn = 'no' cache_attribute = 'LDAP-Cached-Membership' } options { # ldap_debug = 0x0028 chase_referrals = yes rebind = yes res_timeout = 2 srv_timelimit = 5 net_timeout = 2 } } The issue - we have been having network wobbles + FreeRad crashes out if it can't talk to a LDAP server (we previously only had 1 LDAP server listed), so I'd like it to either round robin LDAP servers or fail over smoothly. All ldap.X server variables are resolvable hostnames (final one is domain, so RR-s round all domain controllers) and the servers work individually (/if I put them at the top of the list). To emulate a network failure I'm using iptables -I INPUT -s <ldap.1 IP> -j DROP (also tried blocking output). With this in place I see netstat -np | grep 389 shows fleeting connections to other LDAP Servers: Working/pre iptables: * tcp 0 91 10.1.18.32:43066 10.1.12.201:389 ESTABLISHED 285161/radiusd blocked/iptables blocking 10.1.12.201 only: * tcp 0 109 10.1.18.32:39856 192.168.7.250:389 ESTABLISHED 285161/radiusd * tcp 0 99 10.1.18.32:43066 10.1.12.201:389 FIN_WAIT1 - * tcp 0 109 10.1.18.32:44864 172.16.2.124:389 ESTABLISHED 285161/radiusd * tcp 0 108 10.1.18.32:39868 192.168.7.250:389 ESTABLISHED 285161/radiusd * tcp 0 0 10.1.18.32:43856 10.1.12.200:389 ESTABLISHED 285161/radiusd (but auths fail/blocked, connections drop, freerad crashes moments later) radiusd -X -C shows: ldap { server = "uks-adds-02.thing.local uks-adds-01.thing.local" identity = edu.check@thing.local<mailto:edu.check@thing.local> password = <<< secret >>> sasl { (So only first server listed?) Choice bits from log file: At startup: Mon May 13 11:59:50 2024 : Warning: - server = 'uks-adds-02.thing.local uks-adds-01.thing.local' Mon May 13 11:59:50 2024 : Warning: + server = 'uks-adds-02.thing.local' Mon May 13 11:59:50 2024 : Warning: + server = 'uks-adds-01.thing.local' (one way or another it knows about multiple servers?) At failure: Mon May 13 11:59:45 2024 : Mon May 13 11:59:39 2024 : Error: (379) Ignoring duplicate packet from client bra-wlc-p01 port 63991 - ID: 15 due to unfinished request in component authenticate module eap_peap (guess this is clients getting impatient?) Error: rlm_ldap (ldap): Bind with edu.check@thing.local<mailto:edu.check@thing.local> to ldap://uks-adds-02.thing.local:389 ldap://uks-adds-01.thing.local:389 ldap://ukw-adds-01.thing.local:389 ldap://thing.local:389 ldap://uks-adds-01.thing.local:389 failed: Timed out while waiting for server to respond (but I know it can talk to all but the first LDAP server) Hope that explains it all adequately... Any ideas what I'm missing here? Thanks, Jim Potter Jisc
On May 13, 2024, at 7:22 AM, James Potter via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Hi Team,
I'm having issues getting LDAP group membership checking working with multiple LDAP servers. Here's my config:
http://wiki.freeradius.org/list-help We don't need to see the configuration files. It very rarely helps.
Choice bits from log file: At startup: Mon May 13 11:59:50 2024 : Warning: - server = 'uks-adds-02.thing.local uks-adds-01.thing.local'
Reading the rest of the warning messages should get you the following: Listing multiple LDAP servers in the 'server' configuration item is deprecated and will be removed in a future release. Use multiple 'server' configuration items instead It's good to read all of the warning messages.
At failure: Mon May 13 11:59:45 2024 : Mon May 13 11:59:39 2024 : Error: (379) Ignoring duplicate packet from client bra-wlc-p01 port 63991 - ID: 15 due to unfinished request in component authenticate module eap_peap (guess this is clients getting impatient?) Error: rlm_ldap (ldap): Bind with edu.check@thing.local<mailto:edu.check@thing.local> to ldap://uks-adds-02.thing.local:389 ldap://uks-adds-01.thing.local:389 ldap://ukw-adds-01.thing.local:389 ldap://thing.local:389 ldap://uks-adds-01.thing.local:389 failed: Timed out while waiting for server to respond (but I know it can talk to all but the first LDAP server)
Hope that explains it all adequately... Any ideas what I'm missing here?
The LDAP server is down. Fail-over between servers is handled by libldap, and isn't really under the control of FreeRADIUS. If an LDAP server is critical for the operation of FreeRADIUS, it's best to make sure that the LDAP server stays up. Adding multiple fail-over LDAP servers is a hack which will paper over any issues, but won't correct them. i.e. It's for extreme circumstances where many things are going wrong. You shouldn't depend on it for daily operation. Why? Fail-over takes time. If the LDAP servers randomly go up and down during the day, there will be many periods where FreeRADIUS will be unable to contact the LDAP servers for many seconds. It will take time to determine that the LDAP server isn't just slow, but it's down. During that time, many many users will not get authenticated. Fail-over is for the case where the main LDAP server is down accidentally, and rarely. Since the main server is down, most people aren't getting online. So *anyone* getting authenticated is better than nothing, It is not possible to fix broken networks by adding more fail-over configuration. The correct solution is to make sure that your network doesn't break. Alan DeKok.
participants (2)
-
Alan DeKok -
James Potter