(RADIATOR) AuthBy flow control

[Hugh Irvine]

Hello Andrew -

Is this what you are looking for?


<Handler Client-Identifier = VPN>

                 AuthByPolicy ContinueUntilAccept

#blacklist - accepts, but doesn't get an address, so effectively  
rejected
                 <AuthBy FILE>
                         Filename %D/blocked.txt
                 </AuthBy>

#guests
                 <AuthBy GROUP>
                         AuthByPolicy ContinueWhileAccept

                         <AuthBy FILE>
                                 Filename %D/include/vpn.guest
                         </AuthBy>

                         <AuthBy DYNADDRESS>
                                 AddressAllocator noc-dhcp-allocator
                                 StripFromReply PoolHint
                         </AuthBy>
                 </AuthBy>

#directory
                 <AuthBy GROUP>
                         AuthByPolicy ContinueWhileAccept

# whitelist
                         <AuthBy FILE>
                                 Filename %D/include/whitelist
                         </AuthBy>

                         <AuthBy LDAP2>
                                 Include %D/include/directory.cfg
                                 AuthAttrDef request
                         </AuthBy>

                         <AuthBy DYNADDRESS>
                                 AddressAllocator noc-dhcp-allocator
                                 StripFromReply PoolHint
                         </AuthBy>
                 </AuthBy>

         AcctLogFileName %L/detail

</Handler>


Its not exactly clear to me what your requirements are, so if the  
above is not correct let me know.

regards

Hugh


On 11 Aug 2005, at 05:00, Andrew D. Clark wrote:

> Hi,
>
> I'm running Radiator 3.11.  I've got an intractable (to me) problem  
> in a
> particular handler.  What I've got setup currently is a handler  
> where VPN
> users get authenticated (or blacklisted) and then get allocated an  
> address.
>
> <Handler Client-Identifier = VPN>
>         <AuthBy GROUP>
>                 AuthByPolicy ContinueUntilAccept
>
> #blacklist - accepts, but doesn't get an address, so effectively  
> rejected
>                 <AuthBy FILE>
>                         Filename %D/blocked.txt
>                 </AuthBy>
>
> #guests
>                 <AuthBy GROUP>
>             AuthByPolicy ContinueWhileAccept
>
>                         <AuthBy FILE>
>                                 Filename %D/include/vpn.guest
>                         </AuthBy>
>
>                         <AuthBy DYNADDRESS>
>                                 AddressAllocator noc-dhcp-allocator
>                                 StripFromReply PoolHint
>                         </AuthBy>
>                 </AuthBy>
>
> #directory
>                 <AuthBy GROUP>
>                         AuthByPolicy ContinueWhileAccept
>
> # whitelist
>                         <AuthBy FILE>
>                                 Filename %D/include/whitelist
>                         </AuthBy>
>
>                         <AuthBy LDAP2>
>                                 Include %D/include/directory.cfg
>                                 AuthAttrDef request
>                         </AuthBy>
>
>                         <AuthBy DYNADDRESS>
>                                 AddressAllocator noc-dhcp-allocator
>                                 StripFromReply PoolHint
>                         </AuthBy>
>                 </AuthBy>
>
>         </AuthBy>
>
>         AcctLogFileName %L/detail
>
> </Handler>
>
> If guest auth suceeds, I basically want to break at that point (or  
> have the
> outer AuthByPolicy take effect, since I've suceeded), but since I  
> need an
> AuthByPolicy of ContinueWhileAccept in the guest block to get address
> allocation (which needs to come after the AuthBy File to pick up the
> PoolHint), I end up continuing on to the next AuthBy Group, which  
> ends up
> rejecting the request.  I get similar fun if I swap the guests and  
> the LDAP
> users around.  Is there a way to do get the flow-control I'm  
> looking for?
>
> -- 
> Andrew Clark
> Campus Network Programmer
> University of California, Santa Barbara
> andrew.clark at ucsb.edu (805) 893-5311
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>


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?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
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.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.