[RADIATOR] AuthByPolicy Question - "anything else"

[Hugh Irvine]

Hello Joe -

In this scenario you need to use a ReplyHook in the AuthBy RADIUS clause to call the AuthBy FILE *after* the authentication.

Your AuthBy FILE clause should also have "AcceptIfMissing" set.

Something like this:


......

<AuthBy FILE>
	Identifier CheckUserAttributes
	AcceptIfMissing
	Filename %D/users.attributes
</AuthBy>

<AuthBy RADIUS>
	Identifier DoRemoteAuthentication
	......
	ReplyHook file:"%D/getUserAttributes.pl"
</AuthBy>

.....

# define Realm or Handler

<Handler .....>
	AuthBy DoRemoteAuthentication
	.....
</Handler>

.....

There is an example in "goodies/hooks.txt" in the Radiator 4.5.1 distribution.

regards

Hugh


On 2 Jan 2010, at 10:49, Joe Hughes wrote:

> On Page 93 of the manual it describes an AuthByPolicy of 'anything else' - does this literally mean a random string (e.g bleh), I'll explain.
> 
> I have a scenario whereby I have an AuthBy GROUP which contains an AuthBy FILE and an AuthBy RADIUS.
> 
> The AuthBy FILE contains a list of users along with some user specific attributes for 'authorisation' purposes, it does not contain any authentication information (e.g. passwords).
> 
> The AuthBy RADIUS needs to do the actual authentication. I want the system to grab the attributes from the file (if they exist) and then perform the authentication against the AuthBy RADIUS - returning the Accept\Reject - and any attributes that were in the file (if the user was accepted). 
> 
> The important point is, not *every* user will need additional attributes so they may not exist in the file, but they will on the external RADIUS server. The external RADIUS server isnt capable of returning any user attributes - literally accept\reject. I don't want to store passwords on this (radiator) box for admin purposes, just attributes if necessary.
> 
> Sample config (some bits stripped);
> 
>     <AuthBy GROUP>
>         AuthByPolicy bleh
> 
>         <AuthBy FILE>
>         Filename %D/UserAttribs.txt
>         </AuthBy>
> 
>         <AuthBy RADIUS>          
>             Host test
>             Secret 22mxm12cCX
>         </AuthBy>
>     </AuthBy>
> 
> I have tried;
> 
> - ContinueWhileAccept - which works if *every* user exists in the UserAttribs.txt file - but fails if they dont (because it generates a REJECT)
> - ContinueUntilAccept - which works but never actually authenticates against the RADIUS server if the user definition exists (because it gets an initial ACCEPT).
> 
> - AuthByPolicy bleh;
> If the user exists :- it gets a ACCEPT at the AuthBy FILE *and* an ACCEPT at the second AuthBy RADIUS - the AuthBy GROUP honours the 2nd ACCEPT along with the attributes from the AuthBy FILE
> If the user doesn't exist - it gets a REJECT at the AuthBy FILE but an ACCEPT at the second AuthBy RADIUS - the AuthBy GROUP returns the ACCEPT but with *no* FILE attributes
> 
> My question is; is my choice of "AuthByPolicy bleh" the best option for my given scenario and is this is best way of approaching this?
> 
> Cheers
> 
> Joe
> _______________________________________________
> 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?

-- 
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.