Example configuration that proxy PEAP MSCHAPv2 to an IAS server

[Jacob Dawson]

That's the case here.  Our AD servers are set to only accept NTLMv2, and they won't budge from that.  The workaround for us is to proxy the inner tunnel on domain user authentications to IAS and let it handle talking to AD over NTLMv2.  There's a registry hack involved, and it either lets them cheat and speak NTLMv1, or it somehow lets them have a v2 conversation; I've never been clear on which it is.

Full disclosure, I haven't been able to get this proxy-inner-tunnel stuff to fly consistently under 2.1.11.
- Jacob Dawson

On 30 Aug 2011, at 17:53, Danner, Mearl wrote:

> Might be the LAN Manager authentication level  on the 2K8 servers. It needs to be "downgraded".  Probably to "Send LM and NTLM".
> 
> Samba used to put a  note about that in the documentation.
> 
> 
>> It still bugs that ntlm_auth would not authenticate to the domain 
>> controllers the challenge and nt-response.
> 
> 
>> I assume no one else is having any issues using ntlm_auth to W2008 
>> servers?   It may be some Windows GPO at our site for all I know.
> 
> 
> 
> 
> 
> On 8/27/11 5:01 AM, Phil Mayers wrote:
>> 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.
>> -
>> List info/subscribe/unsubscribe? See 
>> http://www.freeradius.org/list/users.html
>> 
>> 
> 
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html