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 <h...@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.
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
