[RADIATOR] AuthBy FILE + IfNotExist and/or maintaining Access response

[Hugh Irvine]

Hello Nathan -

There is already an "AddToReplyIfNotExist" in the standard code.

And the PostAuthHook (and PostProcessingHook) fire after the AuthBy's  
have been evaluated under the control of the AuthByPolicy.

So you can use AuthByPolicy ContinueUntilAccept and call a  
PostAuthHook, or you can use AddToReplyIfNotExist in the AuthBy GROUP.


<Handler OSC-Client-Identifier = DELL>
  <AuthBy GROUP>
    AuthByPolicy ContinueUntilAccept
    <AuthBy LDAP2> ... </AuthBy>
    <AuthBy LDAP2> ... </AuthBy>
    <AuthBy FILE> ... </AuthBy>
     AddToReplyIfNotExist Service-Type=Administrative-User
  </AuthBy>
</Handler>


regards

Hugh


On 26 Oct 2009, at 21:47, Nathan Anderson wrote:

> On 10/22/09, Hugh Irvine <hugh at open.com.au> wrote:
>
>> Hello Nathan -
>>
>> I would suggest a ClientHook to add an attribute to the request,
>> identifying the type of device - you could use OSC-Client-Identifier
>> for example.
>>
>> Then set up different Handlers for each type of device:
>
> [snip]
>
> Hello Hugh,
>
> Thanks for the response.
>
> As I mentioned in another reply, I considered using Handlers (which  
> I should be able to define without ClientHook and limit to 2 total  
> Handlers, a Default and a DELL, given that I know how to identify  
> the special-case devices, the Dells, and the others work fine with a  
> unified configuration), but the issue I ended up running into is  
> that for each Handler, three AuthBys need to be consulted BEFORE the  
> reply attribute rewrite is performed, and a given user/pass will  
> only have a match in one out of the three AuthBy sources.  For the  
> Default/non-DELL one, this isn't a problem; I just use AuthByPolicy  
> ContinueUntilAccept.  But for the DELL Handler, I can't do that  
> because before I reach the end of execution in the Handler, I need  
> to perform the Service-Type reply attribute replacement as the *very  
> last action*, and because there is no way to preserve an Access- 
> Accept if one of the earlier AuthBys accepts it and a later one  
> rejects it, unless the user/pass match happens in the very last  
> AuthBy, the client will get back Access-Reject even for valid  
> matches for AuthBys other than the very last one in the Handler.  (I  
> hope that made sense...)
>
> Would it have worked to combine your two suggestions together, and  
> use AuthBy GROUP within the Handler like this?:
>
> <Handler OSC-Client-Identifier = DELL>
>  <AuthBy GROUP>
>    AuthByPolicy ContinueUntilAccept
>
>    <AuthBy LDAP2> ... </AuthBy>
>    <AuthBy LDAP2> ... </AuthBy>
>    <AuthBy FILE> ... </AuthBy>
>  </AuthBy>
>
>  StripFromReply Service-Type
>  AddToReply Service-Type=Administrative-User
> </Handler>
>
> In the end, I didn't get to test this out because I came up with  
> another solution.  I was able to patch Radiator to do one of the two  
> things I originally suggested I could use to fix the problem.  One  
> proposal was to lock-in an Access-Accept once one is obtained in an  
> AuthBy chain.  I didn't work on that, though it might be a handy  
> tool to have in my belt in the future.  What I did do was create a  
> simple one-line patch to AuthGeneric.pm that checks to see if a  
> reply attribute with the same name already exists in the constructed  
> reply packet before adding another one.  It's quick-and-dirty, but  
> it works and it solved my problem.  I now have one streamlined  
> default Handler or Realm defined that works with all of my equipment.
>
> I have attached a patch to AuthGeneric.pm with my change, and I also  
> added a toggle to enable or disable the new behavior.  Since  
> AuthFILE inherits from AuthGeneric, you can toggle this feature on  
> inside the <AuthBy FILE> part of your config.  This probably isn't  
> ready for prime-time, so in its current state you probably don't  
> want to merge it in with the main Radiator source tree. ;)  I'm also  
> not married to the name I came up with for the feature toggle.  But  
> perhaps it would be useful to someone else regardless, so I'm  
> posting it here (maybe a candidate for the 'goodies' directory?).
>
> Thanks,
>
> -- 
> Nathan Anderson
> First Step Internet, LLC
> nathana at fsr.com
> <AddReplyAttributeIfNotExist-4.4.patch>



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.