On 20/07/11 14:27, Scott Armitage wrote:
[ttls] Using saved attributes from the original Access-Accept
Reply-Message = "Authenticated by Test ORPS"
Ok, looking at the debug the reason this is happening is that you are
doing TTLS/MSCHAP, as opposed to TTLS/EAP-MSCHAP.
[ttls] Got tunneled request
User-Name = "scott-t...@example.ac.uk"
MS-CHAP-Challenge = 0xcab2e5bc6ccc5e4b382dfbabf81cdd6c
MS-CHAP2-Response =
0x3f00546f8b7903000016283b4f647a91a9c20000000000000000db0d79340d9306bdb4cb590b8e4317c8d4afab58bd715d14
FreeRADIUS-Proxied-To = 127.0.0.1
The "eap" module is what copies the User-Name to the reply in
Access-Accept, and since you're not running an EAP inner, this doesn't
happen.
I must admit, I didn't know you could even *do* TTLS w/ plain MSCHAP
inner, because I had assumed it was subject to replay attacks (in
MSCHAP, the NAS generates the MSCHAP challenge, but of course in TTLS,
the client must do it).
However, a glance at the source code suggests TTLS has support for
"implicit" challenge generation based on the TTLS session, eliminating
the replay attack.
You'll need to set the User-Name in Access-Accept yourself for non-EAP
inner methods (including TTLS/PAP). Alex has given one suggestion, but
personally I like this in "inner-tunnel":
post-auth {
if (!reply:User-Name) {
update reply {
User-Name := "%{User-Name}"
}
}
}
...and then this in the outer-server:
post-auth {
# ensure reply username contains user@domain for
# routing of accounting traffic
if (reply:User-Name !~ /.*@.+/) {
update reply {
User-Name := "%{reply:User-Name}@%{Stripped-User-Domain}"
}
}
}
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
