Terminate PEAP on freeradius then proxy MSCHAPv2 to NPS
Hello All, Could someone tell me if it is possible to terminate PEAP on a freeradius server then proxy the request to an NPS server using MSCHAPv2? Thenk you and best regards, Bertalan
On 01/25/2013 01:19 PM, Bertalan Voros wrote:
Hello All,
Could someone tell me if it is possible to terminate PEAP on a freeradius server then proxy the request to an NPS server using MSCHAPv2?
Yes. Simply set "Proxy-To-Realm" in inner-tunnel/authorize, and FreeRADIUS will proxy the packets. server inner-tunnel { authorize { ... update control { Proxy-To-Realm := NPS } ... } However, personally I would strongly recommend you proxy the inner as EAP-MSCHAPv2, rather than using the magic "turn into plain mschapv2" code i.e. you *should* set in "eap.conf": eap { ... peap { ... proxy_tunneled_request_as_eap = yes ... } } If you set this option to "no" the proxied packet will be changed into plain MSCHAP, but that code path is complex and has had problems in the past. NPS can handle EAP-MSCHAPv2 just fine, so you shouldn't need to do this.
Hi Phil, Thanks a lot for the quick response. The reason I was attempting this is because I have to provide a service for roaming users and I was having issues with obtaining a certificate for the NPS server. Does this mean that I could use a self signed certificate for the NPS that is recognized by the freeradius and have a commercial certificate on the freeradius that is then recognized by the clients? So it's kept EAP-MSCHAPv2 all the way. Is this correct? Sorry for the lame questions but I am reasonably new to freeradius have only been using it to blindly proxy requests to the NPS. On 25 January 2013 13:45, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 01/25/2013 01:19 PM, Bertalan Voros wrote:
Hello All,
Could someone tell me if it is possible to terminate PEAP on a freeradius server then proxy the request to an NPS server using MSCHAPv2?
Yes. Simply set "Proxy-To-Realm" in inner-tunnel/authorize, and FreeRADIUS will proxy the packets.
server inner-tunnel { authorize { ... update control { Proxy-To-Realm := NPS } ... }
However, personally I would strongly recommend you proxy the inner as EAP-MSCHAPv2, rather than using the magic "turn into plain mschapv2" code i.e. you *should* set in "eap.conf":
eap { ... peap { ... proxy_tunneled_request_as_eap = yes ... } }
If you set this option to "no" the proxied packet will be changed into plain MSCHAP, but that code path is complex and has had problems in the past. NPS can handle EAP-MSCHAPv2 just fine, so you shouldn't need to do this. - List info/subscribe/unsubscribe? See http://www.freeradius.org/** list/users.html <http://www.freeradius.org/list/users.html>
-- Bertalan Voros m: 07932858025
Hi,
The reason I was attempting this is because I have to provide a service for roaming users and I was having issues with obtaining a certificate for the NPS server.
whats wrong with just using your current FR certificate on the NPS box?
Does this mean that I could use a self signed certificate for the NPS that is recognized by the freeradius and have a commercial certificate on the freeradius that is then recognized by the clients?
what are your clients/userbase? why do you have to use a commercial certificate for your server? if the clients authenticating are your clients then they can have the required private CA installed - the authentication is a closed loop. if you use a commercial cert eg thawte, verisign etc and only use that as trust then anyone can get a cert signed by that commercial CA as a first point to subverting your security alan
The clients are employees of a fairly loose network of companies, each on their own AD, some doesn't even have ad. A frustrating mixture of Windows and OSX. We maintain a central AD with all the user accounts in it but there are no machines associated with that AD. The self signed certificate works but people get prompted to accept it and we were asked if it was possible for that to not happen. The most likely users of this service would be the VIP types, it is expected to "just work" so here I am. Self signed or commercial makes no difference as the certificate is only used for server authentication. The only difference is users having to manually trust a cert or not. Unless I am wrong. On 25 January 2013 14:23, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
The reason I was attempting this is because I have to provide a service for roaming users and I was having issues with obtaining a certificate for the NPS server.
whats wrong with just using your current FR certificate on the NPS box?
Does this mean that I could use a self signed certificate for the NPS that is recognized by the freeradius and have a commercial certificate on the freeradius that is then recognized by the clients?
what are your clients/userbase? why do you have to use a commercial certificate for your server? if the clients authenticating are your clients then they can have the required private CA installed - the authentication is a closed loop. if you use a commercial cert eg thawte, verisign etc and only use that as trust then anyone can get a cert signed by that commercial CA as a first point to subverting your security
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Bertalan Voros m: 07932858025
Hi,
We maintain a central AD with all the user accounts in it but there are no machines associated with that AD.
any reasons for proxying to the NPS rather than binding the FR system into the AD and authenticating locally?
The self signed certificate works but people get prompted to accept it and we were asked if it was possible for that to not happen.
some clients may prompt for the RADIUS or CA certificate anyway.
The most likely users of this service would be the VIP types, it is expected to "just work" so here I am.
ah...the VIP types who 'just want it to work!' - and thus decide that security requirements are superfluous and get in the way. fine, you need to demonstrate the issue with a classic man in the middle attack - a couple of easy to boot systems exist which do that.
Self signed or commercial makes no difference as the certificate is only used for server authentication.
correct.
The only difference is users having to manually trust a cert or not. Unless I am wrong.
I would seriously advise that you look to having the right security in place and avoid users/clients having to configure their systems - ie an 802.1X deployment tool (such as XpressConnect from CloudPath) which will do all the work/configuration and installation of a CA for you as per your requirements - multi-platform and will do wireless and wired. (there are alternatives but none that are as feature-rich and support as many clients) alan
Hi Alan, Thanks for your insight, you are absolutely correct regarding the issues. I will have to find a compromise that is acceptable by everyone.
We maintain a central AD with all the user accounts in it but there are no machines associated with that AD.
any reasons for proxying to the NPS rather than binding the FR system into the AD and authenticating locally?
Only that the FR site mentioned it to be complicated and we already have an NPS that we are otherwise happy with. Looks like this would be the best option.
The self signed certificate works but people get prompted to accept it and we were asked if it was possible for that to not happen.
some clients may prompt for the RADIUS or CA certificate anyway.
The most likely users of this service would be the VIP types, it is expected to "just work" so here I am.
ah...the VIP types who 'just want it to work!' - and thus decide that security requirements are superfluous and get in the way. fine, you need to demonstrate the issue with a classic man in the middle attack - a couple of easy to boot systems exist which do that.
Self signed or commercial makes no difference as the certificate is only used for server authentication.
correct.
The only difference is users having to manually trust a cert or not. Unless I am wrong.
I would seriously advise that you look to having the right security in place and avoid users/clients having to configure their systems - ie an 802.1X deployment tool (such as XpressConnect from CloudPath) which will do all the work/configuration and installation of a CA for you as per your requirements - multi-platform and will do wireless and wired. (there are alternatives but none that are as feature-rich and support as many clients)
Will definitely look into that. The difficulty is that some of the users are so remote from us that our only encounter with them is seeing a log entry. This is a global solution very removed from the local tech team, only used to let roaming users on the wireless network. We are providing a radius so they don't have to maintain a full copy of all the users in the network (network of companies). It's a continuous headache for us.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Bertalan Voros m: 07932858025
Am 25.01.2013 16:25, schrieb Bertalan Voros:
Hi Alan,
Thanks for your insight, you are absolutely correct regarding the issues. I will have to find a compromise that is acceptable by everyone.
Post somewhere, e.g. possibly on a captive portal, a link to the CA certificate with instruction on how to install it on the various systems involved. cheers Erich
Bertalan Voros wrote:
The self signed certificate works but people get prompted to accept it and we were asked if it was possible for that to not happen.
So give them the CA used to sign that certificate. The message will go away. You can fix a problem so that it never happens again. Or, you can put patches on top of patches, which are fragile, complicated, and tend to break. The choice is yours. Alan DeKok.
Hi,
Could someone tell me if it is possible to terminate PEAP on a freeradius server then proxy the request to an NPS server using MSCHAPv2?
Yes. Simply set "Proxy-To-Realm" in inner-tunnel/authorize, and FreeRADIUS will proxy the packets.
..and be aware that any clients that have strict cryptobindings enabled may not be happy that the authentication was not done by the RADIUS server which terminated the EAP tunnel. alan
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Bertalan Voros -
Erich Titl -
Phil Mayers