Hello list, I'm using a sql database for authorization and ldap for authentication. For fail-over reasons I want to authenticate against user-password information stored in my sql database if my ldap servers are not available (all ldap modules return fail). For authentication I configured: Auth-Type LDAP { redundant-load-balance { ldap1 ldap2 ldap3 } if(fail) { pap } } So I set the network interfaces of my ldap servers manually to down and startet testing. But the timeouts for every ldap module are too big (circa 50 seconds). I noticed the timeout directives in the ldap module. In all three ldap modules the net_timeout is set to "1". Question 1: How can I reduce these timeouts? Question 2: Can I check earlier my ldap servers are available and if not skip Auth-Type LDAP or setting Auth-Type to PAP? Question 3: Are there any other opportunities to do Auth-Type PAP if Auth-Type LDAP fails? Thanks in advance, Tobias Hachmer
On 18/04/12 09:40, Tobias Hachmer wrote:
Hello list,
I'm using a sql database for authorization and ldap for authentication. For fail-over reasons I want to authenticate against user-password information stored in my sql database if my ldap servers are not available (all ldap modules return fail).
Why would you do this? If SQL contains the users, just auth to SQL, surely? If you can explain your use-case, people might be able to make better suggestions.
For authentication I configured:
Auth-Type LDAP { redundant-load-balance { ldap1 ldap2 ldap3 } if(fail) { pap } }
So I set the network interfaces of my ldap servers manually to down and startet testing. But the timeouts for every ldap module are too big (circa 50 seconds). I noticed the timeout directives in the ldap module. In all three ldap modules the net_timeout is set to "1".
Question 1: How can I reduce these timeouts?
Which LDAP client libraries are you using, and which version? Which version of FreeRADIUS? What does a "tcpdump" show for port 389 during your tests? Do you get TCP RSTs, ICMP errors, or what?
Question 2: Can I check earlier my ldap servers are available and if not skip Auth-Type LDAP or setting Auth-Type to PAP?
Not natively in FreeRADIUS. LDAP is problematic in this regard; the libldap APIs are pretty weak, and don't offer good asynchronous support, or timely error notification in some failure modes. It's difficult for me to see what FreeRADIUS can do in situations like this.
Question 3: Are there any other opportunities to do Auth-Type PAP if Auth-Type LDAP fails?
I'm not sure what you're asking here.
Am 18.04.2012 12:33, schrieb Phil Mayers:
On 18/04/12 09:40, Tobias Hachmer wrote:
I'm using a sql database for authorization and ldap for authentication. For fail-over reasons I want to authenticate against user-password information stored in my sql database if my ldap servers are not available (all ldap modules return fail). Why would you do this? Simply as a fallback, in case there is a maintanance on the network where the ldap servers are conected to. In this case we need to log on to our switches though.
If SQL contains the users, just auth to SQL, surely? If you can explain your use-case, people might be able to make better suggestions. Ok, I configure the same users, these are about 10-15 users, which are stored in Active Directory, in the sql database. The sql database schould be used for authentication only if the ldap servers are not available.
So I set the network interfaces of my ldap servers manually to down and startet testing. But the timeouts for every ldap module are too big (circa 50 seconds). I noticed the timeout directives in the ldap module. In all three ldap modules the net_timeout is set to "1".
Question 1: How can I reduce these timeouts?
Which LDAP client libraries are you using, and which version? I use debian squeeze with libldap package libldap-2.4-2, an apt-cache show libldap-2.4-2 shows the Version: 2.4.23-7.2
Which version of FreeRADIUS? FreeRADIUS 2.1.12
What does a "tcpdump" show for port 389 during your tests? Do you get TCP RSTs, ICMP errors, or what? So I just sniffed the network for packets and recognized that my freeradius machine sends out a lot of arp packets for the dns server. Then I added the ldap server to the hosts file and now the net_timeout = 1 seems to work. The timeouts now are ok and the first radius-request is answered in time.
After that I changed my configuration to this: Auth-Type LDAP { redundant { redundant-load-balance { ldap1 ldap2 ldap3 } pap } } and it works now as expected. My questions are answered and my problems seems to be solved. If anyone has any further suggestions please let me know, either. Thank you for your reply. You pointed me the right direction. Regards, Tobias Hachmer
Tobias Hachmer wrote:
Simply as a fallback, in case there is a maintanance on the network where the ldap servers are conected to. In this case we need to log on to our switches though.
"Hi, I want my network to keep working when I take my network down." That doesn't really make sense. You're trying to work around a problem that can't be worked around. Hacking the RADIUS server is a bad choice. Alan DeKok.
Am 18.04.2012 14:32, schrieb Alan DeKok:
Tobias Hachmer wrote:
Simply as a fallback, in case there is a maintanance on the network where the ldap servers are conected to. In this case we need to log on to our switches though.
"Hi, I want my network to keep working when I take my network down."
That doesn't really make sense. You're trying to work around a problem that can't be worked around. Hacking the RADIUS server is a bad choice.
Hi, well, I think it's not. In a big network, there's a backbone and multiple networks connected to that backbone. The network the active directory servers are connected to is on of them. When there is a maintenance on this network, e.g. switching the ospf area or whatever, I want that the network administrators can administer the network devices in the other networks, which are not under maintenance and still working. Tobias Hachmer
On 18/04/12 13:16, Tobias Hachmer wrote:
Ok, I configure the same users, these are about 10-15 users, which are stored in Active Directory, in the sql database. The sql database schould be used for authentication only if the ldap servers are not available.
So the SQL server contains an "emergency" subset of the real users? I guess that makes sense.
Which LDAP client libraries are you using, and which version? I use debian squeeze with libldap package libldap-2.4-2, an apt-cache show libldap-2.4-2 shows the Version: 2.4.23-7.2
Which version of FreeRADIUS? FreeRADIUS 2.1.12
What does a "tcpdump" show for port 389 during your tests? Do you get TCP RSTs, ICMP errors, or what?
So I just sniffed the network for packets and recognized that my freeradius machine sends out a lot of arp packets for the dns server. Then I added the ldap server to the hosts file and now the net_timeout = 1 seems to work. The timeouts now are ok and the first radius-request is answered in time.
Ok, that's good to know. This is sort of what I mean when I refer to libldap having an API that is sub-optimal in some cases; the net_timeout should really apply to an entire connection attempt, not just the connect() or read() calls. It's hard to know what FreeRADIUS can do about this; maybe there is scope for some kind of long-lived helper process that pools and polls the LDAP servers, pro-actively detecting failures. But it seems a complex solution.
Am 18.04.2012 14:36, schrieb Phil Mayers:
On 18/04/12 13:16, Tobias Hachmer wrote:
Ok, I configure the same users, these are about 10-15 users, which are stored in Active Directory, in the sql database. The sql database schould be used for authentication only if the ldap servers are not available.
So the SQL server contains an "emergency" subset of the real users? Yes, that's what I tried to explain.
So I just sniffed the network for packets and recognized that my freeradius machine sends out a lot of arp packets for the dns server. Then I added the ldap server to the hosts file and now the net_timeout = 1 seems to work. The timeouts now are ok and the first radius-request is answered in time.
Ok, that's good to know.
This is sort of what I mean when I refer to libldap having an API that is sub-optimal in some cases; the net_timeout should really apply to an entire connection attempt, not just the connect() or read() calls.
It's hard to know what FreeRADIUS can do about this; maybe there is scope for some kind of long-lived helper process that pools and polls the LDAP servers, pro-actively detecting failures. But it seems a complex solution.
I worried about this, so I asked for any other opportunities. Tobias Hachmer
participants (3)
-
Alan DeKok -
Phil Mayers -
Tobias Hachmer