[RADIATOR] Upgrade to 4.6 caused me problems
Hugh Irvine
hugh at open.com.au
Tue Apr 27 01:26:00 CDT 2010
Hello Jethro -
Comments below.
On 26 Apr 2010, at 19:33, Jethro R Binks wrote:
> Hi Hugh,
>
> On Sat, 24 Apr 2010, Hugh Irvine wrote:
>
>>> 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.
>
> OK .. did I miss part of history.html that details this, or is it
> something that could be made clearer?
>
Not sure how it could be made clearer - sadly EAP by its nature is not clear.
>>> 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.
>
> Hmm, I already do have EAPAnonymous %0 (see below), and for the purposes
> of this testing I'm using the Windows native client and PEAP/MSCHAPv2,
> which as far as I can tell uses the same FQ username on both the outer and
> inner auths. But I see your logic, and will do more tests. This worked
> in 3.17.1 with Realm=, which is the annoying part of it.
Yes - we've had quite a bit of trouble with EAPAnonymous.
I suggest you use the following if the User-Name is correct in the outer request:
EAPAnonymous %{User-Name}
>
>>> 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?
>
> I have:
>
> DbDir /usr/local/etc/radiusd
> ...
> DefineGlobalVar CertDir %D/certificates-4.6
> ...
> <AuthBy FILE>
> Identifier ITSAuthEAPOuter
> Filename %D/dot1X_anon.users
> #EAPType MSCHAP-V2,PAP,PEAP,TTLS
> EAPType PEAP,TTLS
> # Use whatever username was passed to us as the EAP Anonymous user.
> EAPAnonymous %0
> EAPTLS_CAFile %D/certificates-4.6/demoCA/cacert.pem
> #EAPTLS_CAPath %D/certificates-4.6/demoCA
> EAPTLS_CertificateFile %D/certificates-4.6/cert-srv.pem
> #EAPTLS_CertificateFile %{GlobalVar:CertDir}/cert-srv.pem
> EAPTLS_PrivateKeyFile %D/certificates-4.6/cert-srv.pem
> EAPTLS_CertificateType PEM
> AutoMPPEKeys
> ...
> </AuthBy>
>
> If I use:
>
> EAPTLS_CertificateFile %D/certificates-4.6/cert-srv.pem
>
> It works. If I replace with:
>
> EAPTLS_CertificateFile %{GlobalVar:CertDir}/cert-srv.pem
>
> it fails with:
>
> Mon Apr 26 10:01:56 2010: DEBUG: Handling with Radius::AuthFILE: ITSAuthEAPOuter
> Mon Apr 26 10:01:56 2010: DEBUG: Handling with EAP: code 2, 5, 25, 1
> Mon Apr 26 10:01:56 2010: DEBUG: Response type 1
> Mon Apr 26 10:01:56 2010: ERR: TLS could not use_certificate_file %{GlobalVar:CertDir}/cert-srv.pem, 1: 78428: 1 - error:0906D06C:PEM routines:PEM_read_bio:no start line
> 78428: 2 - error:02001002:system library:fopen:No such file or directory
> 78428: 3 - error:20074002:BIO routines:FILE_CTRL:system lib
> 78428: 4 - error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system lib
> Mon Apr 26 10:01:56 2010: DEBUG: EAP result: 1, EAP TLS Could not initialise context
> Mon Apr 26 10:01:56 2010: DEBUG: AuthBy FILE result: REJECT, EAP TLS Could not initialise context
> Mon Apr 26 10:01:56 2010: INFO: Access rejected for xyz at strath.ac.uk: EAP TLS Could not initialise context
>
> I've eyeballed this several times in case there is a typo etc but am not
> spotting it if there is!
>
Well - Radiator is doing exactly what you are telling it to.
If you want the %D expanded you should use this:
DefineFormattedGlobalVar CertDir %D/certificates-4.6
See sections 5.4.23 and 5.4.24 in the Radiator 4.6 reference manual ("doc/ref.pdf").
>
> Here's something else I neglected to mention earlier. I am getting
> garbage for some parameters in my logging... not all the time.
>
> Aha... now I have looked more closely to give you an example, I see what
> is happening. In particular, I have been logging the NAS-IP-Address
> attribute:
>
> Mon Apr 26 00:03:26 2010 OK client=tambala.net.strath.ac.uk
> clientip=130.159.17.137 clientident=SquidProxy nasip=<82><9F>^Q<89> nasid=
> naspttype= requser=abc replyuser= outeruser=abc eapidentity=,
> calling-st-id= called-st-id= fr amed-ip-addr= handler=strathrealm
> rmessage=
>
> The config is:
>
> SuccessFormat %l OK \
> client=%C \
> clientip=%c \
> clientident=%{Client:Identifier} \
> nasip=%N \
> nasid=%{NAS-Identifier} \
> naspttype=%{NAS-Port-Type} \
> ...
>
> So note "nasip=<82><9F>^Q<89>". This is actually my terminal's
> representation of the hi-bit characters, and it turns out they are the hex
> equivalent of the IP address: 0x82h == 130, 0x9f == 159, etc. Before 4.6
> (3.17.1 previously) this was seamlessly translated to a printable IP
> address, but it now appears this is being printed "raw".
>
> I have a similar case where a NAS IP address is "10.2.25.102", which when
> printed using:
>
> nasip=%{OuterRequest:NAS-IP-Address}
>
> writes the hex equivalent, the first character of which is 0x10h which is
> newline, so it breaks the log line. It continues with "^B^Yf" on the next
> line. This line breaking screwed me for a bit as I was grepping the logs
> to debug the previous problems and was only seeing half of each relevant
> log line!
>
> So I suppose my question is, has the code deliberately stopped translating
> the IP addresses from hex to printable IP address string, and if so, what
> can I do to translate it to something printable?
>
> Jethro.
>
I'll have to get back to you on this one - it looks suspicious.
regards
Hugh
>
>>
>> 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.
>>
>>
>>
>>
>
> . . . . . . . . . . . . . . . . . . . . . . . . .
> 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.
More information about the radiator
mailing list