Windows 7, wired 802.1x, native EAP-TLS w/o AD, NPS
Hello list, I'm trying to implement 802.1x/EAP-TLS on a wired network. Getting that to work on Linux clients was reasonably straightforward using wpa_supplicant (and freeradius as the back-end). However, we also have Windows (7) clients on the network, and I'm having issues setting that up. It is my understanding that a) EAP-TLS is mandatory for systems that claim to support 802.1x b) Windows claims to support 802.1x. Unfortunately, every resource I could find either assumes there's an Active Directory infrastructure (which, fortunately, we don't use here) and other shady things involved (NPS -- seems to be sort of an ersatz-radius), OR talks about wireless, OR refers to other versions of Windows, OR ... None seems to describe the combination Windows 7, native supplicant, freeradius, no AD/NPS. So my question, although not directly freeradius-related, is: Does anyone have experience setting up EAP-TLS on a wired network on Windows 7 clients? Is AD strictly required? If so, I wonder how Windows could get away claiming to support 802.1x. I.e.: Does anybody know whether this is possible *at all*? I'm already considering trying 3rd party supplicants, but I'd much rather go with the native one. Thanks, Timo
On 10.04.2017 11:46, Timo Buhrmester wrote:
Hello list,
I'm trying to implement 802.1x/EAP-TLS on a wired network. Getting that to work on Linux clients was reasonably straightforward using wpa_supplicant (and freeradius as the back-end).
However, we also have Windows (7) clients on the network, and I'm having issues setting that up. It is my understanding that a) EAP-TLS is mandatory for systems that claim to support 802.1x b) Windows claims to support 802.1x.
Unfortunately, every resource I could find either assumes there's an Active Directory infrastructure (which, fortunately, we don't use here) and other shady things involved (NPS -- seems to be sort of an ersatz-radius), OR talks about wireless, OR refers to other versions of Windows, OR ... None seems to describe the combination Windows 7, native supplicant, freeradius, no AD/NPS.
So my question, although not directly freeradius-related, is: Does anyone have experience setting up EAP-TLS on a wired network on Windows 7 clients? Is AD strictly required? If so, I wonder how Windows could get away claiming to support 802.1x.
I.e.: Does anybody know whether this is possible *at all*? Of course it is. The problem is that Windows 7 does not support EAP-TTLS natively. First, you will have to enable and start the Windows service called "Wired AutoConfig." Then, you will have to install 3rd party software, most notably SecureW2. After that, you will have to configure *both* the interface *and* SecureW2. It is pretty straightforward.
Please see: https://documentation.meraki.com/MS/Access_Control/Configuring_802.1X_Wired_... I've done it with success on many Windows 7 systems.
I'm already considering trying 3rd party supplicants, but I'd much rather go with the native one.
Thanks, Timo - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Cheers, Selahattin ÇİLEK --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Hello,
Of course it is. The problem is that Windows 7 does not support EAP-TTLS
The OP did not ask for EAP-TTLS. He wants to do EAP-TLS, which is built-in and does not require a third-party supplicant. But yes, *of course* it should work just fine. Basically, follow all those fine instructions for wireless, and do them on the wired interface instead. This may or may not need the "Wired AutoConfig" service as a precondition on Windows 7 indeed. Greetings, Stefan Winter
natively. First, you will have to enable and start the Windows service called "Wired AutoConfig." Then, you will have to install 3rd party software, most notably SecureW2. After that, you will have to configure *both* the interface *and* SecureW2. It is pretty straightforward.
Please see: https://documentation.meraki.com/MS/Access_Control/Configuring_802.1X_Wired_...
I've done it with success on many Windows 7 systems.
I'm already considering trying 3rd party supplicants, but I'd much rather go with the native one.
Thanks, Timo - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Cheers,
Selahattin ÇİLEK
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Thanks for your replies.
Basically, follow all those fine instructions for wireless, and do them on the wired interface instead. The thing is, all those fine instructions seem to start with going via dialogs that are specifically about to wireless networks.
It's not like there's some configuration which I could simply s/wlan0/eth0/g. E.g. "Connect to a network", "Manage wireless networks", "Add a wireless network", etc. Some of those aren't even visible unless the machine in question has a WiFi Adapter. I've looked at: https://supportforums.cisco.com/document/128096/configure-wireless-clients-r... Garbage, also assumes NPS https://msdn.microsoft.com/en-us/library/dd759246(v=ws.11).aspx Seems to deal with the server-side only, assumes NPS and AD https://documentation.meraki.com/MR/Encryption_and_Authentication/Enabling_E... There's no "Manage wireless networks" without WiFi Hardware present. Adding some, it asks for things like SSID, which doesn't exist on wired networks. https://youtu.be/UBE5s6qY5xY Windows XP ..and a ton of other resources. What *seems* to come closest, is to enable 802.1x authentication (possible on the wired interface if the Wired Autoconfig service is running), selecting "Microsoft SmardCard or other certificate" (which I assume is a code for EAP-TLS since the only other option is PEAP -- or is the Windows- way to do PEAP/EAP-TLS?), but the machine never reacts to the "Request Identity" packet (even though it does transmit an EAPOL Start"). Occasionally it will inform me that "A certificate is required to connect to this network", but that's about it. Needless to point out, the aproporiate CA and client certificates are imported into the Windows certificate store. Oddly enough, the machine realizes that a certificate is needed without anything hitting the RADUIS server. What a giant clusterf*ck. If you do have a resource that actually does map to wired networks even though written for wireless, please share. Thanks, Timo
Hi,
What *seems* to come closest, is to enable 802.1x authentication (possible on the wired interface if the Wired Autoconfig service is running), selecting "Microsoft SmardCard or other certificate" (which I assume is a code for EAP-TLS since the only other option is PEAP -- or is the Windows- way to do PEAP/EAP-TLS?),
That's right. "Other certificate" is what you need.
but the machine never reacts to the "Request Identity" packet (even though it does transmit an EAPOL Start").
Occasionally it will inform me that "A certificate is required to connect to this network", but that's about it. Needless to point out, the aproporiate CA and client certificates are imported into the Windows certificate store. Oddly enough, the machine realizes that a certificate is needed without anything hitting the RADUIS server.
What a giant clusterf*ck.
Many people do what you try to do without issues. If it doesn't work, the problem is most likely on your own end. You shouldn't give yourself names like that.
If you do have a resource that actually does map to wired networks even though written for wireless, please share.
Random searches on DuckDuckGo quickly turned up this: https://lapserv.maths.cam.ac.uk/docs/win7_eduroam_wired.html (did you for example check that it's "user authentication", not machine authentication?) This is for PEAP obviously, but the difference between PEAP and TLS is that it's a different drop-down entry in one of the screenshots. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Mon, Apr 10, 2017 at 01:23:19PM +0200, Timo Buhrmester wrote:
Basically, follow all those fine instructions for wireless, and do them on the wired interface instead. The thing is, all those fine instructions seem to start with going via dialogs that are specifically about to wireless networks.
Once you install the Wired Autoconfig option in Windows, the same 802.1X display tabs appear on the wired interfaces as they do on the wireless ones. The instructions are basically the same from there onwards. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Once you install the Wired Autoconfig option in Windows, the same 802.1X display tabs appear on the wired interfaces as they do on the wireless ones. Yes, I've been there already. I probably haven't tried all possible permutations of settings in that dialog(s), but unless I set PEAP there the machine doesn't even react to "Request identity", as pointed out in an earlier email.
Thanks, anyway.
Hi,
Yes, I've been there already. I probably haven't tried all possible permutations of settings in that dialog(s), but unless I set PEAP there the machine doesn't even react to "Request identity", as pointed out in an earlier email.
Then chances are that something's wrong with your client certificate. You could post it's PEM values to the list, or mail me privately, or just tell us where you got the client cert from. FreeRADIUS' Makefile or elsewhere? Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Then chances are that something's wrong with your client certificate. Apparently there was something wrong with how the certificate was imported -- I've tried a different format now (pkcs12), getting me one step further: The machine does now indeed respond to "Request Identity".
(Before that, importing in .der format, the certificate manager would hang for a few minutes when importing the cert, but eventually claim "Import successful".) The cert is generated by freeradius' makefile, however, the EAP session stalls and FR complains: | WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | WARNING: !! EAP session for state 0xe0880a2ce3de07a8 did not finish! | WARNING: !! Please read http://wiki.freeradius.org/guide/Certificate_Compatibility | WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! which seems a bit circular, but I'll try to resolve this myself before asking for further assistence. Thank you so far, Timo
The cert is generated by freeradius' makefile, however, the EAP session stalls and FR complains: | WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | WARNING: !! EAP session for state 0xe0880a2ce3de07a8 did not finish! | WARNING: !! Please read http://wiki.freeradius.org/guide/Certificate_Compatibility | WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! which seems a bit circular, but I'll try to resolve this myself before asking for further assistence. Progress! It turns out that 2048-bit certificates (as generated by FR's Makefile) cause the EAP session to stall, while 1024 bit certs do work!
So that might indeed be an MTU issue. It's mildly surprising, though, because the FR certs are supposedly known to work. I'll provide more accurate data tomorrow (FR output, traffic dumps between client and NAS as well as between NAS and FR), and verify the MTU hypo- thesis as soon as I figure out how to set the MTU in Windows. Cheers, Timo
On 10/04/17 16:48, Timo Buhrmester wrote:
The cert is generated by freeradius' makefile, however, the EAP session stalls and FR complains: | WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | WARNING: !! EAP session for state 0xe0880a2ce3de07a8 did not finish! | WARNING: !! Please read http://wiki.freeradius.org/guide/Certificate_Compatibility | WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! which seems a bit circular, but I'll try to resolve this myself before asking for further assistence. Progress! It turns out that 2048-bit certificates (as generated by FR's Makefile) cause the EAP session to stall, while 1024 bit certs do work!
So that might indeed be an MTU issue. It's mildly surprising, though, because the FR certs are supposedly known to work.
Couple of things to note: There are two MTUs to consider - the IP MTU between the NAS and radius server, and the layer2 MTU between the NAS and the supplicant. The EAP/TLS code will segment the EAP/TLS (or TLS-based like PEAP/TTLS) data into chunks of len == Framed-MTU (from the Access-Accept) or if that's absent, the "fragment_size" option from the tls{} block of the EAP method. So if the Access-Accept contains Framed-MTU=1024 you'll get an Access-Accept that's a few hundred bytes larger (framing plus the other attributes) which should then be a 1024-byte EAP frame at layer2. It would be interesting to know if you're getting a Framed-MTU from the NAS, and what size radius replies you are seeing going from FR to the NAS.
Hi,
The cert is generated by freeradius' makefile, however, the EAP session stalls and FR complains: | WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | WARNING: !! EAP session for state 0xe0880a2ce3de07a8 did not finish! | WARNING: !! Please read http://wiki.freeradius.org/guide/Certificate_Compatibility | WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! which seems a bit circular, but I'll try to resolve this myself before asking for further assistence. Progress! It turns out that 2048-bit certificates (as generated by FR's Makefile) cause the EAP session to stall, while 1024 bit certs do work!
You tried both client certs with the same server cert, issued by the same server-CA? Because this error message /often/ comes from the client seeing an unexpected server certificate, which it doesn't trust and then walks away silently. If you can exclude server trust issues, then yes, this looks a lot like an MTU problem.
So that might indeed be an MTU issue. It's mildly surprising, though, because the FR certs are supposedly known to work.
They do: FreeRADIUS can't help it if your network has MTU problems.
Couple of things to note:
There are two MTUs to consider - the IP MTU between the NAS and radius server, and the layer2 MTU between the NAS and the supplicant.
The EAP/TLS code will segment the EAP/TLS (or TLS-based like PEAP/TTLS) data into chunks of len == Framed-MTU (from the Access-Accept) or if that's absent, the "fragment_size" option from the tls{} block of the EAP method.
So if the Access-Accept contains Framed-MTU=1024 you'll get an Access-Accept that's a few hundred bytes larger (framing plus the other attributes) which should then be a 1024-byte EAP frame at layer2.
It would be interesting to know if you're getting a Framed-MTU from the NAS, and what size radius replies you are seeing going from FR to the NAS.
I don't think this particular explanation is very helpful. Framed-MTU and fragment_size only helps in situations where the /server/ has a large chunk to send and needs to decide how to chop it up. If the conversation breaks as the /client/ certificate gets bigger, none of those two is going to help. Supplicants have their own logic for creating fragments. They know which link they are attached to, and what the MTU on that link is. So the layer2 MTU is not a problem; they can't possibly go above that. We can safely assume that this MTU is 1500 or higher on any modern network. If the client certificate is ~ 1500 or more bytes, the EAP payload needs to be fragmented. The decision on size is - as per my observations - the following: - wpa_supplicant (and by consequence MacOS, iOS, Android, Linux) has a configurable parameter which defaults to something way below 1500. - Windows fills the MTU to the max. So, when you have a Windows supplicant, be prepared that there's a full 1500 byte EAP payload coming to your NAS. The NAS then wraps this inside a RADIUS packet, which adds size, resulting in a UDP datagram that is deterministic >1500 bytes. Which in turn means that UDP fragmentation *will* occur, and the network *must* be prepared to safely deliver the multiple fragments to the RADIUS server destination. For eduroam, we are requiring UDP fragmentation support for many years, for this exact reason (and also because it also helps server-side for admins setting a high MTU in that direction). So, fix your network: let UDP fragments pass to the RADIUS server. Otherwise, your EAP-TLS deployment is going to get stuck. Or at least, fragments of it ;-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
participants (5)
-
Matthew Newton -
Phil Mayers -
Selahattin Cilek -
Stefan Winter -
Timo Buhrmester