Re: Example configuration that proxy PEAP MSCHAPv2 to an IAS server

27 Aug 2011

      On 08/26/2011 10:40 PM, Glenn Machin wrote:
...
I using radiusd: FreeRADIUS Version 2.1.11.
I cannot seem to get the RHEL5 (2.6.18-238.9.1.el5) ntlm_auth program to
properly authenticate the challenge and nt-response packets.
If I set the password using clear-text and also set
MS-CHAP-Use-NTLM-Auth, the authentication works fine. The version of
ntlm_auth is Version 3.5.4-0.83.el5
If you supply the debugging output of "radiusd -X", perhaps someone can 
help you with that.
...
So my next step is to try to filter PEAP MSCHAPv2 requests and proxy
them off to an IAS server. However I still want PEAP GTC packets handled
on this server.
Can't be done cleanly. You can only proxy the inner-EAP conversation, 
since it's only there that you know the inner-EAP type. But the problem 
is you need to proxy the *entire* inner EAP conversation, and that 
includes the EAP-Identity packet, which comes before any EAP type has 
been decided.

You could proxy the inner EAP-MSCHAP as plain-MSCHAP, but you still have 
to set the proxy up early enough; something like this might work:

server inner-tunnel {
   authorize {
     ...
     # use horrible technique to find EAP-MSCHAP packets
     if (EAP-Message =~ /^0x02..00061a..$/) {
       update control {
         Proxy-To-Realm := IAS_SERVERS
       }
     }
   }
}

...and in eap.conf:

eap {
   peap {
     proxy_tunneled_request_as_eap = no
   }
}

...but that solution has problems of its own, namely the EAP-MSCHAP -> 
plain-MSCHAP conversion is a step that, personally, I think is dangerous 
and fiddly, and to be avoided if possible.

As I said; I would avoid this. Try to get Samba working if at all possible.

Re: Example configuration that proxy PEAP MSCHAPv2 to an IAS server

Phil Mayers