Example configuration that proxy PEAP MSCHAPv2 to an IAS server
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 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. Anyone doing such a thing? If so can you tell me how you set up eap.conf, sites-enabled/inner-tunnel and sites-enabled/default, or any other configuration files? Thanks
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.
Phil - thanks for the feedback. I just ended up proxying out to the IAS server usernames starting with "DOMAIN\". I configured the freeradius server to not support mschapv2 but will support PEAP/GTC EAP/TLS. It seems to be working fine with the Macs, iPads and Linux systems while the windows systems are happy to talk to the IAS server. 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. Thanks again. Glenn 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
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
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
Jacob Dawson wrote:
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.
It really should work... it works for my tests. Alan DeKok.
It's largely successful, but as I mentioned in my note to this group from the 29th, I've run into problems with Windows clients having a disagreement with FreeRADIUS about the final stages of the PEAP-MSCHAPv2 conversation, after IAS has authenticated them successfully. - Jacob On 31 Aug 2011, at 16:32, Alan DeKok wrote:
It really should work... it works for my tests.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 30/08/11 22: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.
That's related to the LM/NT hashes used to authenticate an SMB connection. It's unrelated to the use of ntlm_auth in helper mode. There seems to be some confusion about this; just so people are clear, in a working Samba/ntlm_auth configuration, the following is true: 1. Samba is joined into the domain, and thus has its own machine account credentials 2. Winbind is running, and maintains a long-lived SMB connection to a domain controller 3. That SMB connection is authenticated using the machine account credentials; provided you have a recent enough version of Samba, it can have all the security bells & whistles enabled 4. When "ntlm_auth" is called, it passes the mschap challenge/response to winbind, which calls an RPC (over the SMB connection) on the domain controller, which is basically: SamLogonUserEx(username, mschap_challenge, mschap_response) ...and the domain controller says yes or no. "LAN Manager authentication level" is largely irrelevant to all that.
On 30/08/11 21:12, Glenn Machin wrote:
Phil - thanks for the feedback.
I just ended up proxying out to the IAS server usernames starting with "DOMAIN\".
Ok. Obviously that will fail if enters their wireless credentials without a domain.
I configured the freeradius server to not support mschapv2 but will support PEAP/GTC EAP/TLS.
It seems to be working fine with the Macs, iPads and Linux systems while the windows systems are happy to talk to the IAS server.
It still bugs that ntlm_auth would not authenticate to the domain controllers the challenge and nt-response.
I repeat: if you send debug info, people may be able to help.
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.
Exactly which version of windows (2008 or 2008R2?) and at which functional level is your domain? Did you try increasing the debug level for winbind using "smbcontrol" and then examining the debug logs after a failed auth? For what it's worth, we have no problems with Windows 2008R2 domain controllers and the "samba3x" package available under RHEL5 (samba version 3.5.4-0.70.el5). We did have problems with earlier (Samba 3.3) versions after we'd upgraded to 2008R2 and upgraded functional level.
participants (5)
-
Alan DeKok -
Danner, Mearl -
Glenn Machin -
Jacob Dawson -
Phil Mayers