[RADIATOR] Upgrade to 4.6 caused me problems
Jethro R Binks
jethro.binks at strath.ac.uk
Mon Apr 26 04:33:25 CDT 2010
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?
> > 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.
> > 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!
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.
>
> 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
More information about the radiator
mailing list