Load balance LDAP servers for group checking
Hi, I have a very interesting freeradius 2.2setup, that works like this: 1. Check MAC address in static file /etc/raddb/mac_auth 2. Check EAP-TLS machine certificate (issued by Windows AD CA) 3. Check if the username from the certificate is a member of an AD group And it works quite good for me, I've also managed to write PowerShell scripts to create certificates for Linux machines, and both my Windows and Linux computes can authenticate if they're in a right group. But, sometimes I rarely get a hickup in LDAP binding, and since the bind fail, because freeradius cannot connect to LDAP, request is rejected and user cannot connect. Usually, this is random, and if user retries authentication right away, it will get connected, but still it happens once a month. I've tried to follow https://wiki.freeradius.org/config/Load-balancing this to set up redundance/load balancing, but all the time for group checking, it's actually using the server I put last in the list, srom my case, it's 2nd ldap server defined in /etc/raddb/modules/ldap2 In post-auth, I am first checking the format of the username, since Windows and Linux are differently sending username (Windows is host/ machine.domain.com while Linux is what you set in identity of the 802.1x setup in network manager, so I fix both to be in username@domain.com format) Here is a copy of my default file, I just stripped out comments: authorize { preprocess auth_log rewrite.calling_station_id mac_auth if (!ok) { reject } if (!EAP-Message) { update control { Auth-Type := Accept } } else { eap } } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } digest unix eap Auth-Type LDAP { redundant { ldap1 ldap2 } } } preacct { preprocess acct_unique suffix files } accounting { detail exec } session { radutmp } post-auth { if (User-Name =~ /host\/([a-z0-9\-]*)[\.]{1}domain[\.]{1}com/i) { update request { #Stripped-User-Name := "%{1}$" Stripped-User-Name := "%{1}.domain.com" } } if (LDAP-Group == "Users") { update reply { Tunnel-Type = VLAN Tunnel-Medium-Type = IEEE-802 Tunnel-Private-Group-ID = "user" } } else { reject } exec attr_filter.access_reject } pre-proxy { } post-proxy { eap } Thanks for the help in advance, I am not a freeradius advanced user, so I imagine I maybe did some errors here in trying to provide fault tolerance
On May 12, 2017, at 10:09 AM, Petar Marinkovic <highl1@gmail.com> wrote:
But, sometimes I rarely get a hickup in LDAP binding, and since the bind fail, because freeradius cannot connect to LDAP, request is rejected and user cannot connect. Usually, this is random, and if user retries authentication right away, it will get connected, but still it happens once a month.
The short answer is to keep your LDAP servers up. Poking FreeRADIUS is a bandaid, and won't fix the problem.
I've tried to follow https://wiki.freeradius.org/config/Load-balancing this to set up redundance/load balancing, but all the time for group checking, it's actually using the server I put last in the list, srom my case, it's 2nd ldap server defined in /etc/raddb/modules/ldap2
Because you configured it to check LDAP-Group, which uses a *particular* module. And doesn't do load balancing. Upgrade to v3. It will cache the group checks. That will lower the load on LDAP quite a bit. And, make FreeRADIUS less dependent on LDAP. Alan DeKok.
Well, LDAP is Windows AD, and they're constantly up, I more think it's a issue from the KVM running freeradius VM, that for some reason networking is lost, or the switches. I would get failed authentications somewhere else as well, not just through freeradius with group AD check. At v3, how long are the group checks cached? Is there a setting it can be defined or ? Also, does that mean at the next re-authentication request, it will check the MAC address and certificate, but will use the cached group value? Thanks for your help. Petar On Fri, May 12, 2017 at 5:03 PM, Alan DeKok <aland@deployingradius.com> wrote:
On May 12, 2017, at 10:09 AM, Petar Marinkovic <highl1@gmail.com> wrote:
But, sometimes I rarely get a hickup in LDAP binding, and since the bind fail, because freeradius cannot connect to LDAP, request is rejected and user cannot connect. Usually, this is random, and if user retries authentication right away, it will get connected, but still it happens once a month.
The short answer is to keep your LDAP servers up. Poking FreeRADIUS is a bandaid, and won't fix the problem.
I've tried to follow https://wiki.freeradius.org/config/Load-balancing this to set up redundance/load balancing, but all the time for group checking, it's actually using the server I put last in the list, srom my case, it's 2nd ldap server defined in /etc/raddb/modules/ldap2
Because you configured it to check LDAP-Group, which uses a *particular* module. And doesn't do load balancing.
Upgrade to v3. It will cache the group checks. That will lower the load on LDAP quite a bit.
And, make FreeRADIUS less dependent on LDAP.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
Well, LDAP is Windows AD, and they're constantly up, I more think it's a issue from the KVM running freeradius VM, that for some reason networking is lost, or the switches. I would get failed authentications somewhere else as well, not just through freeradius with group AD check.
Well... Active Directory *loves* referrals and if one of the DCs that is being referred to is slow to respond you get... timeouts. It may not be related to your case, but keep that in mind too. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
I have this in my ldap module config # seconds to wait for LDAP query to finish. default: 20 timeout = 4 # seconds LDAP server has to process the query (server-side # time limit). default: 20 # # LDAP_OPT_TIMELIMIT is set to this value. timelimit = 3 # # seconds to wait for response of the server. (network # failures) default: 10 # # LDAP_OPT_NETWORK_TIMEOUT is set to this value. net_timeout = 1 And I am almost positve that I didn't change this one. Does this means I am only allowing 4 seconds for LDAP query to finish, and only 3 for LDAP to process? Also, timeout is just 1 second, which seems pretty low. Guess that if my settings here are wrong, I can fix my problem just by setting bigger values, since the LDAP is not down Thanks for all your help! On Fri, May 12, 2017 at 6:24 PM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
Well, LDAP is Windows AD, and they're constantly up, I more think it's a issue from the KVM running freeradius VM, that for some reason networking is lost, or the switches. I would get failed authentications somewhere else as well, not just through freeradius with group AD check.
Well... Active Directory *loves* referrals and if one of the DCs that is being referred to is slow to respond you get... timeouts.
It may not be related to your case, but keep that in mind too.
Stefan Paetow Moonshot Industry & Research Liaison Coordinator
t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet
jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On May 12, 2017, at 12:19 PM, Petar Marinkovic <highl1@gmail.com> wrote:
Well, LDAP is Windows AD, and they're constantly up, I more think it's a issue from the KVM running freeradius VM, that for some reason networking is lost, or the switches.
That's possible, too.
I would get failed authentications somewhere else as well, not just through freeradius with group AD check.
Maybe. But with v2, FreeRADIUS is probably doing more LDAP queries than anything else.
At v3, how long are the group checks cached? Is there a setting it can be defined or ? Also, does that mean at the next re-authentication request, it will check the MAC address and certificate, but will use the cached group value?
No. Each request is independent of others. When it does the first LDAP group check, it caches *all* of the groups. So that subsequent group checks for the same request use the cached entries. Alan DeKok.
Thanks. This message got lost in the chain, if anyone can maybe verify what I am doing is right: I have this in my ldap module config # seconds to wait for LDAP query to finish. default: 20 timeout = 4 # seconds LDAP server has to process the query (server-side # time limit). default: 20 # # LDAP_OPT_TIMELIMIT is set to this value. timelimit = 3 # # seconds to wait for response of the server. (network # failures) default: 10 # # LDAP_OPT_NETWORK_TIMEOUT is set to this value. net_timeout = 1 And I am almost positve that I didn't change this one. Does this means I am only allowing 4 seconds for LDAP query to finish, and only 3 for LDAP to process? Also, timeout is just 1 second, which seems pretty low. Guess that if my settings here are wrong, I can fix my problem just by setting bigger values, since the LDAP is not down Thanks for all your help! On Fri, May 12, 2017 at 6:52 PM, Alan DeKok <aland@deployingradius.com> wrote:
On May 12, 2017, at 12:19 PM, Petar Marinkovic <highl1@gmail.com> wrote:
Well, LDAP is Windows AD, and they're constantly up, I more think it's a issue from the KVM running freeradius VM, that for some reason networking is lost, or the switches.
That's possible, too.
I would get failed authentications somewhere else as well, not just through freeradius with group AD check.
Maybe. But with v2, FreeRADIUS is probably doing more LDAP queries than anything else.
At v3, how long are the group checks cached? Is there a setting it can be defined or ? Also, does that mean at the next re-authentication request, it will check the MAC address and certificate, but will use the cached group value?
No. Each request is independent of others.
When it does the first LDAP group check, it caches *all* of the groups. So that subsequent group checks for the same request use the cached entries.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
participants (3)
-
Alan DeKok -
Petar Marinkovic -
Stefan Paetow