EAP/TTLS + virtual_server woes
Alexander Clouter
alex at digriz.org.uk
Thu Oct 1 19:15:22 CEST 2009
Hi,
Okay, I munched over the source code and I'm guessing I'm being a
crettin, but I'm hoping you can tell me what I'm doing wrong.
If you use the 'virtual_server' functionality in the ttls{} section of
eap.conf, everything works great if you get an Access-Accept from the
inner virtual server ('auth' for me). When I say "works great", I mean
the 'post-auth' section of the EAP calling ('auth-eap') virtual server
is munched through. However, if 'Access-Reject' is returned then
'post-auth' is not parsed and it bombs immediently back out to the to
outer virtual server's ('dot1x') post-proxy section.
My convoluted (for reasons of 'code' reuse) virtual server approach is:
dot1x -> auth-eap -> auth
Down in 'auth' is where all the LDAP magic to check user credentials is
done, 'auth-eap' is dead simple:
----
server auth-eap {
authorize {
eap
}
authenticate {
eap
}
post-auth {
# if 'eap' fails, post-auth does not get run
# and we have no way to get User-Name/Reply-Message :(
# probably a bug I should report at some stage
#Post-Auth-Type Reject {
#}
# slip some goodies upstream (goes into 'control' so
# we can get the original request username if need be)
update outer.control {
User-Name := "%{reply:User-Name}"
}
# if we put this into 'control' then we get two
# Auth-Type's (although it works), if we put it
# into 'reply' it gets filtered
update outer.request {
Auth-Type := "%{%{reply:Auth-Type}:-%{Auth-Type}}"
EAP-Type := "%{EAP-Type}"
}
}
}
----
Any suggestions, it would be nice if on Access-Reject that post-auth
section was passed in 'auth-eap'.
Of course if you want config files and/or logs, do ask.
Cheers
--
Alexander Clouter
.sigmonster says: Pushing 30 is exercise enough.
More information about the Freeradius-Users
mailing list