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-test@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}" } } }