[RADIATOR] DYNADDRESS and multiple Authby

[Heikki Vatiainen]

On 01/18/2011 04:41 PM, Jim wrote:

> I need to configure Radiator to allocate Dynamic IP's but we are already 
> using multiple AuthBy's with ContinueWhileReject.  Our current handler 
> would be:
> 
> <Realm>
>     AuthByPolicy ContinueWhileReject
>     AuthBy LdapAuthenticator
>     AuthBy TooManyFail
> </Realm>
> 
> Where if the request is rejected it will check the "TooManyFail" AuthBy 
> which connect the user in a walled garden if they have spammed too many 
> failed auths.
> 
> Now for DYNADDRESS we would need to use ContinueWhileAccept instead 
> which would break our current TooManyFail auth check:
> 
> <Realm>
>     AuthByPolicy ContinueWhileAccept
>     AuthBy LdapAuthenticator
>     <AuthBy DYNADDRESS>
>          AddressAllocator SQLAllocator
>     </AuthBy>
> </Realm>

Is the above example missing AuthBy TooManyFail? If I understood
correctly, this TooManyFail is not going anywhere and the only change is
that AuthBy DYNADDRESS, that works together with AuthBy
LdapAuthenticator, is added.

> How would I go about implementing Dynamic IP allocation and a 2nd authby 
> to return a generic walled garden answer when they have too many 
> failures?  I was thinking either:

My suggestion, based on my understanding of your situation, is this:

<Realm>
    AuthByPolicy ContinueWhileReject

    <AuthBy GROUP>
        AuthByPolicy ContinueWhileAccept
        AuthBy LdapAuthenticator
        <AuthBy DYNADDRESS>
            AddressAllocator SQLAllocator
       </AuthBy>
    </AuthBy>

    AuthBy TooManyFail
</Realm>

How does this look like?

> 1. Put a PostAuthHook or PostProcessingHook (not sure which) in our 
> current Realm which checks to see if the reply is an ACCEPT with no 
> Framed-IP-Address, and if so allocate a Dynamic IP.  Would also require 
> config in accounting handler to deallocate IP.
> 
> 2. Setup our realm as in the 2nd example and have a PostAuthHook or 
> PostProcessingHook which checks to see if the response is a REJECT.  If 
> it is then check to see if they are in our 'badlist' and if so modify 
> the access response to an Accept with the walled garden attributes?
> 
> Are both of these 2 solutions valid?  If so what are your thoughts on 
> the them - is one much better than the other?  I have not implemented 
> any hooks so far (or any Perl programming for that matter) so any advice 
> and pointers appreciated.

I would first check groups and the possibilities group level policies offer.

Thanks!
Heikki

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.