[RADIATOR] ContinueWhileIgnore in AuthByGroup with LDAP
Raphael Luta
raphael.luta at aptiwan.com
Mon Oct 12 04:31:54 CDT 2009
Bob,
If your need is simply to have a back-up LDAP server, it's probably
better to leverage the built-in host load-balancing features of
Net::LDAP with this simple Radiator patch:
--- Radiator-4.4/Radius/Ldap.pm 2008-07-16 18:56:18.000000000 -0400
+++ /usr/lib/perl5/site_perl/5.8.8/Radius/Ldap.pm 2009-09-14
08:39:33.000000000 -0400
@@ -239,6 +239,13 @@
my $port =
&Radius::Util::get_port(&Radius::Util::format_special($self->{Port}));
$self->{connectedHost} = "$host:$port";
$self->log($main::LOG_INFO, "Connecting to $self-
>{connectedHost}");
+
+ my @host = ();
+ foreach(split(/ /,$host))
+ {
+ push @host, "$_:$port";
+ }
+ $host = \@host;
$self->{bound} = undef;
if ($self->{UseSSL})
Once this patch is applied, you can simply specify multiple space
separated hostnames on a single Host line and Net::LDAP will connect
to the first that is available and you'll only need one AuthBY clause
Example fail-over AuthBy LDAP2 conf:
<AuthBY LDAP2>
Host myhost1 myhost2
AuthDN cn=radius,dc=example,dc=com
AuthPasswd password
BaseDN dc=example,dc=com
...
</AuthBy>
-- raphael
Le 12 oct. 09 à 00:56, Hugh Irvine a écrit :
>
> Hello Bob -
>
> You are correct - the protocol has to return reject.
>
> regards
>
> Hugh
>
>
> On 10 Oct 2009, at 19:07, Bob Shafer wrote:
>
>> Hugh,
>>
>> Just for completeness -
>>
>> When I'd tested with ContinueUntilAccept I did not test beyond
>> making sure the failover happened. When I tested this more
>> completly I found that ContinueUntilAccept seems to act like
>> ContinueWhileAccept for EAP-PEAP-MSCHAP-V2 - testing the credentials
>> on both LDAP servers with success, but failing in the end.
>>
>> I finally went with ContinueWhileReject. Which seems to work just
>> fine. It still tries both servers when a client has bad
>> credentials, but it also will fail over properly when the first LDAP
>> server goes south.
>>
>> Is there any chance that EAP-PEAP-MSCHAP-V2 could return Ignore when
>> it can't connect to the LDAP server? Or is there something inherent
>> in the protocol that implies that it has to return Reject when it
>> can't connect?
>>
>> Thanks,
>>
>> Bob
>>
>>
>> Hugh Irvine wrote:
>>> Hello Bob -
>>> This is more likely to be due to EAP and MSCHAP-V2.
>>> I think you will need to continue using ContinueUntilAccept.
>>> regards
>>> Hugh
>>> On 2 Oct 2009, at 18:54, Bob Shafer wrote:
>>>> I'm pretty sure, at one time, this acted as I wished:
>>>>
>>>> <AuthBy GROUP>
>>>> AuthByPolicy ContinueWhileIgnore
>>>> AuthBy LDAP-AUTH
>>>> AuthBy BU-LDAP-AUTH
>>>> </AuthBy>
>>>>
>>>> The intent being to try a primary LDAP server as configured in
>>>> AuthBy LDAP-AUTH, and if that server was unavailable, to try the
>>>> back up server as configured in AuthBy BU-LDAP-AUTH.
>>>>
>>>> At some point, and I'm not sure when, because I did not test this
>>>> after every upgrade, it stopped working.
>>>>
>>>> It appears that, when the primary fails, instead of returning
>>>> IGNORE, radiator is returning REJECT:
>>>>
>>>> Fri Oct 2 02:18:40 2009: ERR: Could not open LDAP connection to
>>>> ldap.du.edu:636. Backing off for 600 seconds.
>>>> Fri Oct 2 02:18:40 2009: DEBUG: EAP result: 1, EAP MSCHAP V2
>>>> failed: no such user xyzzy
>>>> Fri Oct 2 02:18:40 2009: DEBUG: AuthBy GROUP result: REJECT, EAP
>>>> MSCHAP V2 failed: no such user xyzzy
>>>> Fri Oct 2 02:18:40 2009: INFO: Access rejected for 872120688: EAP
>>>> MSCHAP V2 failed: no such user xyzzy
>>>>
>>>> If I switch from ContinueWhileIgnore to ContinueUntilAccept, fail
>>>> over works. But that means that, when the user enters their
>>>> credentials incorrectly, that radiator will, unnecessarily, test
>>>> them against the backup server.
>>>>
>>>> The server is running 4.4 with patches that were available as of
>>>> last Friday.
>>>>
>>>> If you need to see the entire configuration file and/or debug
>>>> output let me know and I will send it under separate cover.
>>>>
>>>> Bob
>>>> _______________________________________________
>>>> radiator mailing list
>>>> radiator at open.com.au
>>>> http://www.open.com.au/mailman/listinfo/radiator
>>> NB:
>>> Have you read the reference manual ("doc/ref.html")?
>>> Have you searched the mailing list archive (www.open.com.au/archives/radiator
>>> )?
>>> Have you had a quick look on Google (www.google.com)?
>>> Have you included a copy of your configuration file (no secrets),
>>> together with a trace 4 debug showing what is happening?
>>> Have you checked the RadiusExpert wiki:
>>> http://www.open.com.au/wiki/index.php/Main_Page
>
>
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/archives/radiator
> )?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> Have you checked the RadiusExpert wiki:
> http://www.open.com.au/wiki/index.php/Main_Page
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> Includes support for reliable RADIUS transport (RadSec),
> and DIAMETER translation agent.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
Raphael Luta
raphael.luta at aptiwan.com
More information about the radiator
mailing list