(RADIATOR) AuthByPolicy ContinueUntilAccept problems

Hugh Irvine hugh at open.com.au
Tue Jun 6 18:58:58 CDT 2006


Hello Matt -

It is often the case that one might want to store the accounting with  
the Realm suffix, but do the authentication without it.

If this is the case, using UsernameMatchesWithoutRealm makes sense.

regards

Hugh


On 6 Jun 2006, at 15:11, Matthew Alexander wrote:

> I'm curious as to why you would need the  
> UsernameMatchesWithoutRealm flag. Why couldn't you just  
> RewriteUsername?
>
> It looks like I am working on something very similar (PEAP EAP- 
> MSCHAPv2 machine + user auth via AuthBy NTLM).  I just used  
> RewriteUsername to get rid of the realm.  Did you run into an issue  
> that I can look forward to experiencing?
>
> Thanks,
> Matt
>
> ----- Original Message ----- From: "Hugh Irvine" <hugh at open.com.au>
> To: "Robin Breathe" <rbreathe at brookes.ac.uk>
> Cc: <radiator at open.com.au>
> Sent: Friday, June 02, 2006 1:45 PM
> Subject: Re: (RADIATOR) AuthByPolicy ContinueUntilAccept problems
>
>
>>
>> Hello Robin -
>>
>> Excellent - I'm very pleased.
>>
>> Perhaps you might consider posting an overview of what you are  
>> doing  to the list for reference?
>>
>> regards
>>
>> Hugh
>>
>>
>> On 2 Jun 2006, at 06:51, Robin Breathe wrote:
>>
>>> Hugh Irvine wrote:
>>>> What I tend to do in my consulting practice for complex  
>>>> requirements
>>>> like this is use an AuthBy INTERNAL with a hook, and select the
>>>> appropriate AuthBy clause in the hook code.
>>>>
>>>> I don't know whether this will work in your case, but you can  
>>>> try it.
>>>> There are numerous example hooks showing how to do various  
>>>> things in
>>>> "goodies/hooks.txt".
>>>
>>> Hugh,
>>>
>>> Thanks for this suggestion, I've got things working beautifully  
>>> with a
>>> little Radius::AuthGeneric::find()->handle_request() magic!
>>>
>>> Robin
>>> -- 
>>> Robin Breathe, Computer Services, Oxford Brookes University,   
>>> Oxford, UK
>>> rbreathe at brookes.ac.uk       Tel: +44 1865 483685  Fax: +44 1865   
>>> 483073
>>>
>>
>>
>> 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.
>
> --
> 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: I am travelling this week, so there may be delays in our  
correspondence.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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.


More information about the radiator mailing list