[RADIATOR] Upgrade to 4.6 caused me problems

[Hugh Irvine]

Hello Jethro -

Many thanks for your thoughtful comments.

See my responses below inline:


On 24 Apr 2010, at 05:12, Jethro R Binks wrote:

> I lately upgraded from an aged 3.17.1 to 4.6+patches.  Basic 
> authentication was fine with virtually no config file changes (hurrah 
> thankyou!), but EAP stuff has been giving me headaches.
> 

Sadly EAP gives most people headaches....

:-(

> For one thing, I had to juggle the locations of stuff like EAPType and 
> EAPTLS_CAFile: I did have these set at the AuthBy GROUP level in some 
> cases, but had to move them into the actual real AuthBy clauses.  Does 
> that sound reasonable?  Perhaps this has something to do with it: 
> "Improvements to AuthBy GROUP so that it better handles chains of 
> authenticators with EAP type requests, such as LEAP, EAP-MSCHAPV2 etc. 
> Reported by Jani Kariniemi."
> 

Yes - this is because many people need to mix both EAP and non-EAP in an AuthBy GROUP - hence the change.

> However this bit in particular is bugging me.  I will happily accept that 
> I've missed something in the release notes somewhere, but for a typical 
> configuration where there are matches for the inner auth and outer auth, I 
> used to have:
> 
>  <Handler Realm="strath.ac.uk", TunnelledByTTLS=1>
> 
> to match the inner auth.  This now no longer works since the upgrade: the 
> handler is not matched.  This works:
> 
>  <Handler TunnelledByTTLS=1>
> 
> but now I've lost my ability to do things per-realm (I didn't need to 
> though).  On the basis of that quick description, have I missed something?  
> Or is there a bug?
> 

No this isn't a bug, but you need to make sure that the User-Name attribute passed to the inner request has the Realm suffix available.

You can either use something like EAPAnonymous %0 (if the EAP identity contains the fully qualified username), or use a PreHandlerHook in the outer AuthBy.


> A couple of other minor things I have noted along the way:
> 
> "Revision 4.1 (2008-02-22) Bug fixes
> ...
> Reinstated support for EAPErrorReject which was accidentally lost from 
> some modules."
> 
> But "EAPErrorReject" is not documented, nor does Google find any hits 
> other than the release notes.
> 

Noted - this will be fixed for the next release.

> Also, I took the notion to define a GlobalVar for the location of my cert 
> stuff.  Unfortunately, it seems EAPTLS_PrivateKeyFile and friends do not 
> parse their argument for GlobalVars, so I couldn't do:
> 
> EAPTLS_PrivateKeyFile %{GlobalVar:CertDir}/cert-srv.pem

Hmmm - from what I can see in the code this should work, so can you please send me an example showing it not to work?

regards

Hugh


> 
> Thanks,
> 
> Jethro.
> 
> .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
> Jethro R Binks
> Computing Officer, IT Services, University Of Strathclyde, Glasgow, UK
> _______________________________________________
> 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.