Simultaneous EAP-TLS and PEAP-MSCHAPv2 (machine/user authentication)
Hi, For my private network I would like to use 802.1X (managed switch) and WPA2 Enterprise via freeradius. I want to allow (1) username/password login with LDAP backend without installing any software/certificates on the clients and (2) machine-level authentication by installing a simple certificate on the client. Both methods should work with as many clients (Windows, Android, iOS, ...) as possible. I assume for (1) PEAP-MSCHAPv2 with LDAP is good. Got this working now. I assume for (2) EAP-TLS is good. Is this true so far? Now I am confused regarding certificates. For (1) I set the certificates in "tls" section of "eap" (since PEAP is based on TLS). Since I do not want to install any certificates on the clients, I would use a certificate officially signed by a CA trusted by the client (e.g. StartSSL, LetsEncrypt, VeriSign, ...). But what to choose an CN? Anything else to consider when creating the certificate? Now the problem for (2) is that I need an own CA. I would assume the configuration for EAP-TLS goes into the "tls" section under "eap" but as written above this is already taken by PEAP! Can't be so difficult ... how to implement this scenario appropriately? Thanks! Luke PS: I use freeradius 2.1.12 in Debian stable.
On Dec 24, 2015, at 9:01 PM, Lukas Haase <lukashaase@gmx.at> wrote:
For my private network I would like to use 802.1X (managed switch) and WPA2 Enterprise via freeradius. I want to allow (1) username/password login with LDAP backend without installing any software/certificates on the clients
That doesn't work. You need a CA cert installed on the laptops / end machines.
and (2) machine-level authentication by installing a simple certificate on the client.
Windows can do machine-level authentication, by automatically provisioning the certificates. For every other system, there is no "machine auth". There are only user accounts, and user credentials.
Both methods should work with as many clients (Windows, Android, iOS, ...) as possible.
See above. The system-specific limitations are very limiting.
I assume for (1) PEAP-MSCHAPv2 with LDAP is good. Got this working now.
You need to add / enable a CA for the 802.1X authentication. Disabling server certificate verification "works", for various insecure definitions of "works".
I assume for (2) EAP-TLS is good. Is this true so far?
You can't do both on the same machine in the same account.
Now I am confused regarding certificates.
For (1) I set the certificates in "tls" section of "eap" (since PEAP is based on TLS). Since I do not want to install any certificates on the clients, I would use a certificate officially signed by a CA trusted by the client (e.g. StartSSL, LetsEncrypt, VeriSign, ...).
That is not recommended. You should use a self-signed CA.
But what to choose an CN? Anything else to consider when creating the certificate?
Use the certificate creation scripts distributed with the server.
Now the problem for (2) is that I need an own CA. I would assume the configuration for EAP-TLS goes into the "tls" section under "eap" but as written above this is already taken by PEAP!
While you can put two CA certificates into the raddb/certs directory... you *can't* use two different 802.1X configurations for the same machine. Even on Windows.
Can't be so difficult ... how to implement this scenario appropriately?
It's impossible. You can only have one 802.1X configuration per end user account.
PS: I use freeradius 2.1.12 in Debian stable.
Ugh. Install 2.2.9. It's really not hard. Using a 5 year-old version of the server is depressing. Alan DeKok.
Alan, thanks. On 2015-12-25 4:07, Alan DeKok wrote:
On Dec 24, 2015, at 9:01 PM, Lukas Haase <lukashaase@gmx.at> wrote:
For my private network I would like to use 802.1X (managed switch) and WPA2 Enterprise via freeradius. I want to allow (1) username/password login with LDAP backend without installing any software/certificates on the clients
That doesn't work. You need a CA cert installed on the laptops / end machines.
I was afraid so and technically it makes sense (since there is not even an "anchor" that can relate the RADIUS server with the CN as it is for DNS). Currently it works with the self-signed certificate (but Windows presents the certificate warning). For my level of security in my private network this is acceptable. However, I found tons of references and howtos where it is stated that (a) installing certificates on the client is optional (b) using a server certificate signed by an official CA is recommended.
and (2) machine-level authentication by installing a simple certificate on the client.
Windows can do machine-level authentication, by automatically provisioning the certificates.
I cannot find good references to that; do you have a pointer? Conceptionally, would I need to add machines as user accounts (as for a PDC) or is it enough to have the client certificate signed by the server certificate? I would not want the former case.
For every other system, there is no "machine auth". There are only user accounts, and user credentials.
At least I could use a users file containing "machine" accounts with long passwords ... but this is again much more difficult than just deploying a simple certificate file. In that case: Why then sign the client certificate with the server cert at all?
[...]
I assume for (2) EAP-TLS is good. Is this true so far?
You can't do both on the same machine in the same account.
What do you mean by "same account"? I really can't use anything in parallel with PEAP?
Now I am confused regarding certificates.
For (1) I set the certificates in "tls" section of "eap" (since PEAP is based on TLS). Since I do not want to install any certificates on the clients, I would use a certificate officially signed by a CA trusted by the client (e.g. StartSSL, LetsEncrypt, VeriSign, ...).
That is not recommended. You should use a self-signed CA.
As mentioned, in this case too many broken howtos and references out there :(
[...]
Now the problem for (2) is that I need an own CA. I would assume the configuration for EAP-TLS goes into the "tls" section under "eap" but as written above this is already taken by PEAP!
While you can put two CA certificates into the raddb/certs directory... you *can't* use two different 802.1X configurations for the same machine. Even on Windows.
Again ... with machine you mean the client or the RADIUS server? Per "end user account" I *only* want to use PEAP-MSCHAPv2 (because it is most widely supported) using login/password information looked up via OpenLDAP (this works). Independently from an "end user account" I would like the authentication to succeed when the client presents a certificate signed by the server, same as it is the case for OpenVPN in PKI mode. I think this can be done with EAP-TLS. So if FreeRADIUS can't be set up serving EAP-TLS and PEAP-MSCHAPv2 at the same time, can't it be configured with virtual servers? For example, there is "modules/inner-eap" which contains a separate TLS configuration. I though this is the key to the correct configuration.
Can't be so difficult ... how to implement this scenario appropriately?
It's impossible. You can only have one 802.1X configuration per end user account.
What I mean: There are tons of deployments in companies supporting which present a username/password prompt when connecting to the network but connect automatically without a prompt when a certain certificate is installed on the system. I've seen that. So I assume this is a very common setup which shouldn't be too hard to implement. Thanks Luke
On Dec 25, 2015, at 5:42 AM, Lukas Haase <lukashaase@gmx.at> wrote:
However, I found tons of references and howtos where it is stated that (a) installing certificates on the client is optional (b) using a server certificate signed by an official CA is recommended.
The only reason (a) *might* be true is if you believe (b). Which I don't. When you allow a public CA for a particular SSID, it means that *any* certificate issued by that CA will be allowed for that SSID. This isn't what you want. We recommend using a self-signed CA, because it's more secure. The people who recommend using public CAs generally don't know what they're talking about.
Windows can do machine-level authentication, by automatically provisioning the certificates.
I cannot find good references to that; do you have a pointer?
It's done via Active Directory. See that documentation.
For every other system, there is no "machine auth". There are only user accounts, and user credentials.
At least I could use a users file containing "machine" accounts with long passwords ... but this is again much more difficult than just deploying a simple certificate file.
Why would you do this in the first place? You can only authenticate once with 802.1X. Once you're authenticated, you're in the network. 802.1X has no concept of "machine" accounts versus "people" accounts.
In that case: Why then sign the client certificate with the server cert at all?
You don't. You sign the client certificate with the CA cert.
You can't do both on the same machine in the same account.
What do you mean by "same account"?
Why do you think there are multiple accounts? Do you think there are multiple 802.1X authentications? The problem here is that you have certain assumptions about how things work. Those assumptions are wrong. I'm trying to correct them, but because your assumptions and terminology are wrong, you're not really understanding my answers.
I really can't use anything in parallel with PEAP?
You can't authenticate twice in 802.1X. Once a system is authenticated, it's on the network. i.e. you're asking the wrong questions.
As mentioned, in this case too many broken howtos and references out there :(
I'm saying what you should do. You can (a) believe it and follow instructions, and get the systems on the net, or (b) ignore what I'm saying, keep with whatever ideas you have, and not get anything done. Pick one.
Again ... with machine you mean the client or the RADIUS server?
I mean supplicant / laptop / desktop. Once a system is on the net, it's on the net. How do *you* expect to use EAP-TLS and PEAP at the same time, from the same machine? Please explain.
Per "end user account" I *only* want to use PEAP-MSCHAPv2 (because it is most widely supported) using login/password information looked up via OpenLDAP (this works).
Sure.
Independently from an "end user account" I would like the authentication to succeed when the client presents a certificate signed by the server, same as it is the case for OpenVPN in PKI mode. I think this can be done with EAP-TLS.
Sure. But... how do you expect EAP-TLS and PEAP to work together? Explain. In detail.
So if FreeRADIUS can't be set up serving EAP-TLS and PEAP-MSCHAPv2 at the same time,
You're not paying attention. It's not a FreeRADIUS limitation. It's a limitation of the machine trying to get on the network, and the network.
can't it be configured with virtual servers? For example, there is "modules/inner-eap" which contains a separate TLS configuration. I though this is the key to the correct configuration.
It helps to understand the concepts before trying random solutions.
It's impossible. You can only have one 802.1X configuration per end user account.
What I mean: There are tons of deployments in companies supporting which present a username/password prompt when connecting to the network but connect automatically without a prompt when a certain certificate is installed on the system.
Sure. That' s doing *either* PEAP or EAP-TLS. Only one 802.1X configuration is active at a time.
I've seen that. So I assume this is a very common setup which shouldn't be too hard to implement.
Authenticating one machine using EAP-TLS and PEAP at the same time is impossible. FreeRADIUS can authenticate anything. If one machine does EAP-TLS, and another does PEAP. That's fine. If one machine does EAP-TLS, logs off of the network, and then comes back with PEAP, that's fine. Please understand what I'm saying. You have some kind of assumption about how the network works. Those assumptions are wrong. Because those assumptions are wrong, you're asking the wrong questions. And not understanding my answers. It's really quite simple. Configure a system to do: a) PEAP or b) EAP-TLS. Pick one. It will be able to do 802.1X and get on the network. Doing some kind of magical "PEAP and EAP-TLS at the same time" is impossible. Stop trying to do it. You're wasting everyones time. Alan DeKok.
Windows can't do machine authentication and then additionally user authentication. You can do either do machine OR user auth. It is kind of annoying. 2015-12-26 15:07 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Dec 25, 2015, at 5:42 AM, Lukas Haase <lukashaase@gmx.at> wrote:
However, I found tons of references and howtos where it is stated that (a) installing certificates on the client is optional (b) using a server certificate signed by an official CA is recommended.
The only reason (a) *might* be true is if you believe (b). Which I don't.
When you allow a public CA for a particular SSID, it means that *any* certificate issued by that CA will be allowed for that SSID.
This isn't what you want.
We recommend using a self-signed CA, because it's more secure. The people who recommend using public CAs generally don't know what they're talking about.
Windows can do machine-level authentication, by automatically provisioning the certificates.
I cannot find good references to that; do you have a pointer?
It's done via Active Directory. See that documentation.
For every other system, there is no "machine auth". There are only user accounts, and user credentials.
At least I could use a users file containing "machine" accounts with long passwords ... but this is again much more difficult than just deploying a simple certificate file.
Why would you do this in the first place?
You can only authenticate once with 802.1X. Once you're authenticated, you're in the network. 802.1X has no concept of "machine" accounts versus "people" accounts.
In that case: Why then sign the client certificate with the server cert at all?
You don't. You sign the client certificate with the CA cert.
You can't do both on the same machine in the same account.
What do you mean by "same account"?
Why do you think there are multiple accounts? Do you think there are multiple 802.1X authentications?
The problem here is that you have certain assumptions about how things work. Those assumptions are wrong. I'm trying to correct them, but because your assumptions and terminology are wrong, you're not really understanding my answers.
I really can't use anything in parallel with PEAP?
You can't authenticate twice in 802.1X. Once a system is authenticated, it's on the network.
i.e. you're asking the wrong questions.
As mentioned, in this case too many broken howtos and references out there :(
I'm saying what you should do. You can
(a) believe it and follow instructions, and get the systems on the net,
or
(b) ignore what I'm saying, keep with whatever ideas you have, and not get anything done.
Pick one.
Again ... with machine you mean the client or the RADIUS server?
I mean supplicant / laptop / desktop. Once a system is on the net, it's on the net.
How do *you* expect to use EAP-TLS and PEAP at the same time, from the same machine?
Please explain.
Per "end user account" I *only* want to use PEAP-MSCHAPv2 (because it is most widely supported) using login/password information looked up via OpenLDAP (this works).
Sure.
Independently from an "end user account" I would like the authentication to succeed when the client presents a certificate signed by the server, same as it is the case for OpenVPN in PKI mode. I think this can be done with EAP-TLS.
Sure.
But... how do you expect EAP-TLS and PEAP to work together?
Explain. In detail.
So if FreeRADIUS can't be set up serving EAP-TLS and PEAP-MSCHAPv2 at the same time,
You're not paying attention.
It's not a FreeRADIUS limitation. It's a limitation of the machine trying to get on the network, and the network.
can't it be configured with virtual servers? For example, there is "modules/inner-eap" which contains a separate TLS configuration. I though this is the key to the correct configuration.
It helps to understand the concepts before trying random solutions.
It's impossible. You can only have one 802.1X configuration per end user account.
What I mean: There are tons of deployments in companies supporting which present a username/password prompt when connecting to the network but connect automatically without a prompt when a certain certificate is installed on the system.
Sure. That' s doing *either* PEAP or EAP-TLS. Only one 802.1X configuration is active at a time.
I've seen that. So I assume this is a very common setup which shouldn't be too hard to implement.
Authenticating one machine using EAP-TLS and PEAP at the same time is impossible.
FreeRADIUS can authenticate anything. If one machine does EAP-TLS, and another does PEAP. That's fine. If one machine does EAP-TLS, logs off of the network, and then comes back with PEAP, that's fine.
Please understand what I'm saying. You have some kind of assumption about how the network works. Those assumptions are wrong. Because those assumptions are wrong, you're asking the wrong questions. And not understanding my answers.
It's really quite simple. Configure a system to do:
a) PEAP
or
b) EAP-TLS.
Pick one. It will be able to do 802.1X and get on the network.
Doing some kind of magical "PEAP and EAP-TLS at the same time" is impossible. Stop trying to do it. You're wasting everyones time.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
We need something like EAP-TEAP that supports chaining to solve that one properly. Nick
On 26 Dec 2015, at 09:55, Ben Humpert <ben@an3k.de> wrote:
Windows can't do machine authentication and then additionally user authentication. You can do either do machine OR user auth. It is kind of annoying.
Has someone actually tried requiring a peer certificate and seeing what the Windows supplicant does? PEAP with mutual TLS authentication does work with wpa_supplicant, we even have a test for it... -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Sat, Dec 26, 2015 at 11:07:05AM -0500, Arran Cudbard-Bell wrote:
On 26 Dec 2015, at 09:55, Ben Humpert <ben@an3k.de> wrote:
Windows can't do machine authentication and then additionally user authentication. You can do either do machine OR user auth. It is kind of annoying.
Has someone actually tried requiring a peer certificate and seeing what the Windows supplicant does?
Fails to authenticate as soon as you require a client cert. Tried a while ago; would have been quite nice. Matthew -- Matthew Newton, Ph.D. <mcn4@le.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>
The guy to talk to about this is Tripp Parks: https://twitter.com/trippparks https://twitter.com/trippparks/status/667097734911016960 Cheers, Nick
On Dec 26, 2015, at 5:02 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Has someone actually tried requiring a peer certificate and seeing what the Windows supplicant does?
Fails to authenticate as soon as you require a client cert. Tried a while ago; would have been quite nice.
You should be able to add a client cert on the Windows side, and still do PEAP. Last I tried it worked. Tho that was probably 8 years ago... Alan DeKok.
That's with EAP-TLS as the inner to EAP-PEAP, which we know works. You don't have a second factor at that point though because the client cert is only via the inner. In the case that EAP-MS-CHAPv2 is the inner, you can't use a client cert. On Sat, Dec 26, 2015 at 10:20 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 26, 2015, at 5:02 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Has someone actually tried requiring a peer certificate and seeing what the Windows supplicant does?
Fails to authenticate as soon as you require a client cert. Tried a while ago; would have been quite nice.
You should be able to add a client cert on the Windows side, and still do PEAP.
Last I tried it worked. Tho that was probably 8 years ago...
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
When i try to authenticate through EAP/PEAP/MSCHAPV2 i got the following error Mon Dec 28 20:25:20 2015 : Debug: rlm_ldap (ldap): Reserved connection (4) Mon Dec 28 20:25:20 2015 : ERROR: (1) ldap : (uid=%u) Mon Dec 28 20:25:20 2015 : ERROR: (1) ldap : ^ Invalid variable expansion Mon Dec 28 20:25:20 2015 : ERROR: (1) ldap : Unable to create filter Mon Dec 28 20:25:20 2015 : Debug: rlm_ldap (ldap): Released connection (4) Does anybody knows where its come from? I have had to use my own built that may explain many but i don't know where to seek for solutions Thanks for your help!!!! FYI: I'm using eapol_test with the following configuration file network={ key_mgmt=NONE eap=MSCHAPV2 identity="XXXXX" password="******" } He is my ldap module configuration file ldap { server = "127.0.0.1" identity = "cn=Manager, dc=pipoiohxui" password = "********" basedn = "ou=Users,dc=pipoiohxui" filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" base_filter = "(objectclass=radiusprofile)" ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 tls { start_tls = no } dictionary_mapping = ${confdir}/ldap.attrmap edir_account_policy_check = no } Here is the start of radiusd Mon Dec 28 20:19:01 2015 : Info: radiusd: FreeRADIUS Version 3.0.3, for host x86_64-redhat-linux-gnu, built on Dec 28 2015 at 20:12:25^[[0m Mon Dec 28 20:19:01 2015 : Debug: Server was built with: Mon Dec 28 20:19:01 2015 : Debug: accounting Mon Dec 28 20:19:01 2015 : Debug: authentication Mon Dec 28 20:19:01 2015 : Debug: ascend binary attributes Mon Dec 28 20:19:01 2015 : Debug: coa Mon Dec 28 20:19:01 2015 : Debug: control-socket Mon Dec 28 20:19:01 2015 : Debug: detail Mon Dec 28 20:19:01 2015 : Debug: dhcp Mon Dec 28 20:19:01 2015 : Debug: dynamic clients Mon Dec 28 20:19:01 2015 : Debug: proxy Mon Dec 28 20:19:01 2015 : Debug: regex-pcre Mon Dec 28 20:19:01 2015 : Debug: session-management Mon Dec 28 20:19:01 2015 : Debug: stats Mon Dec 28 20:19:01 2015 : Debug: tcp Mon Dec 28 20:19:01 2015 : Debug: threads Mon Dec 28 20:19:01 2015 : Debug: tls Mon Dec 28 20:19:01 2015 : Debug: unlang Mon Dec 28 20:19:01 2015 : Debug: vmps Mon Dec 28 20:19:01 2015 : Debug: Server core libs: Mon Dec 28 20:19:01 2015 : Debug: talloc : 2.0.* Mon Dec 28 20:19:01 2015 : Debug: ssl : OpenSSL 1.0.1g-fips 23 Dec 2015 0x01000107f (1.0.1g-15) Mon Dec 28 20:19:01 2015 : Debug: Library magic number: Mon Dec 28 20:19:01 2015 : Debug: 0xf403000300000000 Mon Dec 28 20:19:01 2015 : Debug: Endianess: Mon Dec 28 20:19:01 2015 : Debug: little This is my own build for security purposes linked to openSSL library.
On 28 Dec 2015, at 14:36, Orion Timbale <timbaledorion@hotmail.com> wrote:
When i try to authenticate through EAP/PEAP/MSCHAPV2 i got the following error
Mon Dec 28 20:25:20 2015 : Debug: rlm_ldap (ldap): Reserved connection (4) Mon Dec 28 20:25:20 2015 : ERROR: (1) ldap : (uid=%u) Mon Dec 28 20:25:20 2015 : ERROR: (1) ldap : ^ Invalid variable expansion Mon Dec 28 20:25:20 2015 : ERROR: (1) ldap : Unable to create filter Mon Dec 28 20:25:20 2015 : Debug: rlm_ldap (ldap): Released connection (4)
Does anybody knows where its come from? I have had to use my own built that may explain many but i don't know where to seek for solutions Thanks for your help!!!!
I don't understand what your question is. %u is an invalid one letter expansion. If you wanted User-Name use %{User-Name} Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Here is what i get in my ldap conf files no %u but something that is more complex and like %{User-Name} but ldap module seems to see only %u ldap { server = "127.0.0.1" identity = "cn=Manager, dc=pipoiohxui" password = "********" basedn = "ou=Users,dc=pipoiohxui" filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" base_filter = "(objectclass=radiusprofile)" ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 tls { start_tls = no } dictionary_mapping = ${confdir}/ldap.attrmap edir_account_policy_check = no } Le 28/12/2015 20:47, Arran Cudbard-Bell a écrit :
On 28 Dec 2015, at 14:36, Orion Timbale <timbaledorion@hotmail.com> wrote:
When i try to authenticate through EAP/PEAP/MSCHAPV2 i got the following error
Mon Dec 28 20:25:20 2015 : Debug: rlm_ldap (ldap): Reserved connection (4) Mon Dec 28 20:25:20 2015 : ERROR: (1) ldap : (uid=%u) Mon Dec 28 20:25:20 2015 : ERROR: (1) ldap : ^ Invalid variable expansion Mon Dec 28 20:25:20 2015 : ERROR: (1) ldap : Unable to create filter Mon Dec 28 20:25:20 2015 : Debug: rlm_ldap (ldap): Released connection (4)
Does anybody knows where its come from? I have had to use my own built that may explain many but i don't know where to seek for solutions Thanks for your help!!!! I don't understand what your question is. %u is an invalid one letter expansion.
If you wanted User-Name use %{User-Name}
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 28, 2015, at 2:53 PM, Orion Timbale <timbaledorion@hotmail.com> wrote:
Here is what i get in my ldap conf files no %u but something that is more complex and like %{User-Name}
Read the debug output to see where the '%u' comes from. You WILL see a '%u' when you start the server via "radiusd -X". And it WILL tell you which file that configuration is read from. Alan DeKok.
On Sat, Dec 26, 2015 at 10:24:34PM +0000, Nick Lowe wrote:
That's with EAP-TLS as the inner to EAP-PEAP, which we know works. You don't have a second factor at that point though because the client cert is only via the inner. In the case that EAP-MS-CHAPv2 is the inner, you can't use a client cert.
Yes, we're doing PEAP/EAP-TLS with windows; that works fine. It's requiring a client cert when using PEAP/EAP-MSCHAPv2 where it bombs out. Tried a lot of combinations, but it was 2-3 years ago so I can't remember what... Matthew -- Matthew Newton, Ph.D. <mcn4@le.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>
On Dec 26, 2015, at 9:55 AM, Ben Humpert <ben@an3k.de> wrote:
Windows can't do machine authentication and then additionally user authentication. You can do either do machine OR user auth. It is kind of annoying.
It's not Windows. It's a fundamental limitation of the protocols involved. When a system authenticates itself to the network and gets access... its *on the network*. There's no magical multi-step process. Even using PEAP with a client certificate means that the client certificate is under the user control. He can delete it, or copy it to another machine. Alan DeKok.
Hi Ben, On 2015-12-26 15:55, Ben Humpert wrote:
Windows can't do machine authentication and then additionally user authentication. You can do either do machine OR user auth. It is kind of annoying.
This is not what I want anyway. Once again the intended setup: 1.) Client presents a certificate signed by the CA -> authentication should succeed ("machine authentication"). (I thought this would best be done via EAP-TLS but not sure) 2.) If the client does NOT have a client certificate signed by the CA installed it should query for username/password ("user authentication") exactly as in my current setup. Authentication should succeed via PEAP-MSCHAPv2 if correct credentials are presented. Luke
2015-12-26 15:07 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Dec 25, 2015, at 5:42 AM, Lukas Haase <lukashaase@gmx.at> wrote:
However, I found tons of references and howtos where it is stated that (a) installing certificates on the client is optional (b) using a server certificate signed by an official CA is recommended.
The only reason (a) *might* be true is if you believe (b). Which I don't.
When you allow a public CA for a particular SSID, it means that *any* certificate issued by that CA will be allowed for that SSID.
This isn't what you want.
We recommend using a self-signed CA, because it's more secure. The people who recommend using public CAs generally don't know what they're talking about.
Windows can do machine-level authentication, by automatically provisioning the certificates.
I cannot find good references to that; do you have a pointer?
It's done via Active Directory. See that documentation.
For every other system, there is no "machine auth". There are only user accounts, and user credentials.
At least I could use a users file containing "machine" accounts with long passwords ... but this is again much more difficult than just deploying a simple certificate file.
Why would you do this in the first place?
You can only authenticate once with 802.1X. Once you're authenticated, you're in the network. 802.1X has no concept of "machine" accounts versus "people" accounts.
In that case: Why then sign the client certificate with the server cert at all?
You don't. You sign the client certificate with the CA cert.
You can't do both on the same machine in the same account.
What do you mean by "same account"?
Why do you think there are multiple accounts? Do you think there are multiple 802.1X authentications?
The problem here is that you have certain assumptions about how things work. Those assumptions are wrong. I'm trying to correct them, but because your assumptions and terminology are wrong, you're not really understanding my answers.
I really can't use anything in parallel with PEAP?
You can't authenticate twice in 802.1X. Once a system is authenticated, it's on the network.
i.e. you're asking the wrong questions.
As mentioned, in this case too many broken howtos and references out there :(
I'm saying what you should do. You can
(a) believe it and follow instructions, and get the systems on the net,
or
(b) ignore what I'm saying, keep with whatever ideas you have, and not get anything done.
Pick one.
Again ... with machine you mean the client or the RADIUS server?
I mean supplicant / laptop / desktop. Once a system is on the net, it's on the net.
How do *you* expect to use EAP-TLS and PEAP at the same time, from the same machine?
Please explain.
Per "end user account" I *only* want to use PEAP-MSCHAPv2 (because it is most widely supported) using login/password information looked up via OpenLDAP (this works).
Sure.
Independently from an "end user account" I would like the authentication to succeed when the client presents a certificate signed by the server, same as it is the case for OpenVPN in PKI mode. I think this can be done with EAP-TLS.
Sure.
But... how do you expect EAP-TLS and PEAP to work together?
Explain. In detail.
So if FreeRADIUS can't be set up serving EAP-TLS and PEAP-MSCHAPv2 at the same time,
You're not paying attention.
It's not a FreeRADIUS limitation. It's a limitation of the machine trying to get on the network, and the network.
can't it be configured with virtual servers? For example, there is "modules/inner-eap" which contains a separate TLS configuration. I though this is the key to the correct configuration.
It helps to understand the concepts before trying random solutions.
It's impossible. You can only have one 802.1X configuration per end user account.
What I mean: There are tons of deployments in companies supporting which present a username/password prompt when connecting to the network but connect automatically without a prompt when a certain certificate is installed on the system.
Sure. That' s doing *either* PEAP or EAP-TLS. Only one 802.1X configuration is active at a time.
I've seen that. So I assume this is a very common setup which shouldn't be too hard to implement.
Authenticating one machine using EAP-TLS and PEAP at the same time is impossible.
FreeRADIUS can authenticate anything. If one machine does EAP-TLS, and another does PEAP. That's fine. If one machine does EAP-TLS, logs off of the network, and then comes back with PEAP, that's fine.
Please understand what I'm saying. You have some kind of assumption about how the network works. Those assumptions are wrong. Because those assumptions are wrong, you're asking the wrong questions. And not understanding my answers.
It's really quite simple. Configure a system to do:
a) PEAP
or
b) EAP-TLS.
Pick one. It will be able to do 802.1X and get on the network.
Doing some kind of magical "PEAP and EAP-TLS at the same time" is impossible. Stop trying to do it. You're wasting everyones time.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 26, 2015, at 12:45 PM, Lukas Haase <lukashaase@gmx.at> wrote:
This is not what I want anyway. Once again the intended setup:
1.) Client presents a certificate signed by the CA -> authentication should succeed ("machine authentication").
No. That is not "machine authentication". Machine authentication is where a Windows system uses credentials provisioned by Active Directory to do 802.1X. When that happens, the user does *not* provide any credentials.
(I thought this would best be done via EAP-TLS but not sure)
The TLS-based EAP methods are EAP-TLS, PEAP, and TTLS.
2.) If the client does NOT have a client certificate signed by the CA installed it should query for username/password ("user authentication") exactly as in my current setup. Authentication should succeed via PEAP-MSCHAPv2 if correct credentials are presented.
That's PEAP. Mostly. You can configure an end system to do 802.1X. It has a preferred EAP method, which it uses for authentication. i.e. it uses *one* EAP method. What you're talking about amounts to this: 1) some systems have client certificates. These systems are configured to do EAP-TLS. 2) some systems don't have client certificates. These systems are configured to do PEAP-MSCHAPv2. That's it. Alan DeKok.
So in short you simply want to authenticate with either username / password OR a certificate. You can do that with Windows natively, regardless of wired or wireless connection. However, each client has to be configured. There is no Plug&Play. If you don't have a certificate for a given client enable PEAP in the NIC Authentication settings. If you have a certificate enable "Smartcard or other certificate". For EAP-TLS FreeRADIUS is already ready to go, just give it the required certificates, keys, etc. For PEAP you need to add your users and their passwords to the users file. The Windows settings are kind of confusing (and sometimes really stupid) and I can only help you with them (as well as Android/iOS) since I don't have any Linux or Mac clients. 2015-12-26 18:45 GMT+01:00 Lukas Haase <lukashaase@gmx.at>:
Hi Ben,
On 2015-12-26 15:55, Ben Humpert wrote:
Windows can't do machine authentication and then additionally user authentication. You can do either do machine OR user auth. It is kind of annoying.
This is not what I want anyway. Once again the intended setup:
1.) Client presents a certificate signed by the CA -> authentication should succeed ("machine authentication"). (I thought this would best be done via EAP-TLS but not sure)
2.) If the client does NOT have a client certificate signed by the CA installed it should query for username/password ("user authentication") exactly as in my current setup. Authentication should succeed via PEAP-MSCHAPv2 if correct credentials are presented.
Luke
2015-12-26 15:07 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Dec 25, 2015, at 5:42 AM, Lukas Haase <lukashaase@gmx.at> wrote:
However, I found tons of references and howtos where it is stated that (a) installing certificates on the client is optional (b) using a server certificate signed by an official CA is recommended.
The only reason (a) *might* be true is if you believe (b). Which I don't.
When you allow a public CA for a particular SSID, it means that *any* certificate issued by that CA will be allowed for that SSID.
This isn't what you want.
We recommend using a self-signed CA, because it's more secure. The people who recommend using public CAs generally don't know what they're talking about.
Windows can do machine-level authentication, by automatically provisioning the certificates.
I cannot find good references to that; do you have a pointer?
It's done via Active Directory. See that documentation.
For every other system, there is no "machine auth". There are only user accounts, and user credentials.
At least I could use a users file containing "machine" accounts with long passwords ... but this is again much more difficult than just deploying a simple certificate file.
Why would you do this in the first place?
You can only authenticate once with 802.1X. Once you're authenticated, you're in the network. 802.1X has no concept of "machine" accounts versus "people" accounts.
In that case: Why then sign the client certificate with the server cert at all?
You don't. You sign the client certificate with the CA cert.
You can't do both on the same machine in the same account.
What do you mean by "same account"?
Why do you think there are multiple accounts? Do you think there are multiple 802.1X authentications?
The problem here is that you have certain assumptions about how things work. Those assumptions are wrong. I'm trying to correct them, but because your assumptions and terminology are wrong, you're not really understanding my answers.
I really can't use anything in parallel with PEAP?
You can't authenticate twice in 802.1X. Once a system is authenticated, it's on the network.
i.e. you're asking the wrong questions.
As mentioned, in this case too many broken howtos and references out there :(
I'm saying what you should do. You can
(a) believe it and follow instructions, and get the systems on the net,
or
(b) ignore what I'm saying, keep with whatever ideas you have, and not get anything done.
Pick one.
Again ... with machine you mean the client or the RADIUS server?
I mean supplicant / laptop / desktop. Once a system is on the net, it's on the net.
How do *you* expect to use EAP-TLS and PEAP at the same time, from the same machine?
Please explain.
Per "end user account" I *only* want to use PEAP-MSCHAPv2 (because it is most widely supported) using login/password information looked up via OpenLDAP (this works).
Sure.
Independently from an "end user account" I would like the authentication to succeed when the client presents a certificate signed by the server, same as it is the case for OpenVPN in PKI mode. I think this can be done with EAP-TLS.
Sure.
But... how do you expect EAP-TLS and PEAP to work together?
Explain. In detail.
So if FreeRADIUS can't be set up serving EAP-TLS and PEAP-MSCHAPv2 at the same time,
You're not paying attention.
It's not a FreeRADIUS limitation. It's a limitation of the machine trying to get on the network, and the network.
can't it be configured with virtual servers? For example, there is "modules/inner-eap" which contains a separate TLS configuration. I though this is the key to the correct configuration.
It helps to understand the concepts before trying random solutions.
It's impossible. You can only have one 802.1X configuration per end user account.
What I mean: There are tons of deployments in companies supporting which present a username/password prompt when connecting to the network but connect automatically without a prompt when a certain certificate is installed on the system.
Sure. That' s doing *either* PEAP or EAP-TLS. Only one 802.1X configuration is active at a time.
I've seen that. So I assume this is a very common setup which shouldn't be too hard to implement.
Authenticating one machine using EAP-TLS and PEAP at the same time is impossible.
FreeRADIUS can authenticate anything. If one machine does EAP-TLS, and another does PEAP. That's fine. If one machine does EAP-TLS, logs off of the network, and then comes back with PEAP, that's fine.
Please understand what I'm saying. You have some kind of assumption about how the network works. Those assumptions are wrong. Because those assumptions are wrong, you're asking the wrong questions. And not understanding my answers.
It's really quite simple. Configure a system to do:
a) PEAP
or
b) EAP-TLS.
Pick one. It will be able to do 802.1X and get on the network.
Doing some kind of magical "PEAP and EAP-TLS at the same time" is impossible. Stop trying to do it. You're wasting everyones time.
Alan DeKok.
- 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
Hi Alan, I think parts of our conversation move towards a non-productive direction; probably because I am using different terminology (e.g. "machine authentication") due to my unfamiliarity with the topic. Before going ahead let me once again describe the setup I want: 1.) Client presents a certificate signed by the CA -> authentication should succeed ("machine authentication"). (I thought this would best be done via EAP-TLS but not sure) 2.) If the client does NOT have a client certificate signed by the CA installed it should query for username/password ("user authentication") exactly as in my current setup. Authentication should succeed via PEAP-MSCHAPv2 if correct credentials are presented. For (1) I do NOT want machine accounts in AD/Samba etc - just presenting the correct client certificate should be enough. This should work with Windows clients as well as Android clients. On 2015-12-26 15:07, Alan DeKok wrote:
On Dec 25, 2015, at 5:42 AM, Lukas Haase <lukashaase@gmx.at> wrote: [...]
Windows can do machine-level authentication, by automatically provisioning the certificates.
I cannot find good references to that; do you have a pointer? It's done via Active Directory. See that documentation.
I think we spoke about different things. This is not what I want anyway ...
For every other system, there is no "machine auth". There are only user accounts, and user credentials.
At least I could use a users file containing "machine" accounts with long passwords ... but this is again much more difficult than just deploying a simple certificate file.
Why would you do this in the first place?
You can only authenticate once with 802.1X. Once you're authenticated, you're in the network. 802.1X has no concept of "machine" accounts versus "people" accounts.
Sorry for the confusion; not what I want, see above.
In that case: Why then sign the client certificate with the server cert at all?
You don't. You sign the client certificate with the CA cert.
Of course, my bad.
You can't do both on the same machine in the same account.
What do you mean by "same account"?
Why do you think there are multiple accounts? Do you think there are multiple 802.1X authentications?
The problem here is that you have certain assumptions about how things work. Those assumptions are wrong. I'm trying to correct them, but because your assumptions and terminology are wrong, you're not really understanding my answers.
Yes, I think so. No I do not want multiple 802.1X authentications. My understanding is that it works similar as PAM etc.: It's a stack of authentication methods which are tried as long as either one succeeds or all fail. The first one that should be tried should be EAP-TLS with nothing but a client certificate (what I call "machine authentication") and the second one should be PEAP-MSCHAPv2 (what I call "user authentication"). If both fail, network authentication fails.
[...]
Again ... with machine you mean the client or the RADIUS server?
I mean supplicant / laptop / desktop. Once a system is on the net, it's on the net.
How do *you* expect to use EAP-TLS and PEAP at the same time, from the same machine?
Please explain.
I used wrong terminology, see above. Hope it's clear now.
Independently from an "end user account" I would like the authentication to succeed when the client presents a certificate signed by the server, same as it is the case for OpenVPN in PKI mode. I think this can be done with EAP-TLS.
Sure.
But... how do you expect EAP-TLS and PEAP to work together?
Explain. In detail.
I am not sure if it is possible, hence my question. See above: I would expect that a client certificate is attempted first and if that fails username/password via PEAP-MSCHAPv2. If this is *not* possible with EAP-TLS and PEAP-MSCHAPv2 on the same RADIUS server, maybe it's possible with PEAP only.
So if FreeRADIUS can't be set up serving EAP-TLS and PEAP-MSCHAPv2 at the same time,
You're not paying attention.
It's not a FreeRADIUS limitation. It's a limitation of the machine trying to get on the network, and the network.
can't it be configured with virtual servers? For example, there is "modules/inner-eap" which contains a separate TLS configuration. I though this is the key to the correct configuration.
It helps to understand the concepts before trying random solutions.
It's impossible. You can only have one 802.1X configuration per end user account.
What I mean: There are tons of deployments in companies supporting which present a username/password prompt when connecting to the network but connect automatically without a prompt when a certain certificate is installed on the system.
Sure. That' s doing *either* PEAP or EAP-TLS. Only one 802.1X configuration is active at a time.
Ok.
I've seen that. So I assume this is a very common setup which shouldn't be too hard to implement.
Authenticating one machine using EAP-TLS and PEAP at the same time is impossible.
See above, not what I want. As soon as client sends EAP-TLS client certificate which is valid -> done. If not, the client would just attempt to authenticate with PEAP-MSCHAPv2.
FreeRADIUS can authenticate anything. If one machine does EAP-TLS, and another does PEAP. That's fine.
This is what I want! And my question is precicely how to set up freeradius to be able to handle both. Possibly with different server certificates/CAs for EAP-TLS and PEAP. Because both seem to use the "tls" section in eap.conf for key/certificate configuration. Thanks, Luke
I think parts of our conversation move towards a non-productive direction; probably because I am using different terminology (e.g. "machine authentication") due to my unfamiliarity with the topic.
Before going ahead let me once again describe the setup I want:
1.) Client presents a certificate signed by the CA -> authentication should succeed ("machine authentication"). (I thought this would best be done via EAP-TLS but not sure)
If the client is configured with a cert and to use TTLS then freeradius will use that. The radius server does not tell the client which method to use.
2.) If the client does NOT have a client certificate signed by the CA installed it should query for username/password ("user authentication") exactly as in my current setup. Authentication should succeed via PEAP-MSCHAPv2 if correct credentials are presented.
If you have a certificate the client will be need to be configured for TTLS. If not the client/supplicant will be configured for PEAP. I'll repeat, the radius server responds to the method configured in the client/supplicant. It is all a client configuration issue. The client configuration determines the authentication method, not the radius server.
On Dec 26, 2015, at 1:03 PM, Lukas Haase <lukashaase@gmx.at> wrote:
I think parts of our conversation move towards a non-productive direction; probably because I am using different terminology (e.g. "machine authentication") due to my unfamiliarity with the topic.
The solution is to *not* use terminology you're unfamiliar with. Use simple terminology. Which helps to keep your questions clear. The alternative is to ask questions using the wrong terminology, which is unhelpful and confusing.
Before going ahead let me once again describe the setup I want:
1.) Client presents a certificate signed by the CA -> authentication should succeed ("machine authentication").
Stop calling it "machine authentication". Part of becoming familiar with the topic is that you *don't* use the wrong terminology. Get the idea of "machine authentication" out of your head. Just stop it. It's unhelpful, confusing, and wastes everyones time.
(I thought this would best be done via EAP-TLS but not sure)
I've explained this repeatedly. How can you be "not sure"? What part of my explanations are unclear?
2.) If the client does NOT have a client certificate signed by the CA installed it should query for username/password ("user authentication")
No. Stop using wrong terminology. It's unhelpful. Stop talking about "user authentication". There is nothing in EAP which distinguishes "user" from "machine" authentication. It's all just "authentication".
exactly as in my current setup. Authentication should succeed via PEAP-MSCHAPv2 if correct credentials are presented.
OK...
For (1) I do NOT want machine accounts in AD/Samba etc - just presenting the correct client certificate should be enough. This should work with Windows clients as well as Android clients.
Please read my messages. What I said is: What you're talking about amounts to this: 1) some systems have client certificates. These systems are configured to do EAP-TLS. 2) some systems don't have client certificates. These systems are configured to do PEAP-MSCHAPv2. That's it. Is there any part of those two choices which are unclear? Alan DeKok.
2015-12-26 20:54 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Dec 26, 2015, at 1:03 PM, Lukas Haase <lukashaase@gmx.at> wrote:
1.) Client presents a certificate signed by the CA -> authentication should succeed ("machine authentication").
Stop calling it "machine authentication". Part of becoming familiar with the topic is that you *don't* use the wrong terminology.
Get the idea of "machine authentication" out of your head. Just stop it. It's unhelpful, confusing, and wastes everyones time.
It isn't wrong terminology. Windows (XP -> 10) uses this. One can chose between machine and user authentication. The difference between both is: Machine auth happens BEFORE a user logs into Windows. User auth happens AFTER a user logged into Windows. One actually could use two certificates, one for the machine (is the machine allowed to access the network? If yes into which VLAN should we put it?) and one for the user (is the user allowed to access the network?). Using both you could do machine auth first and get the machine put into VLAN 1 to get DHCP stuff and access to eg. Active directory (which is required for user auth). Then you can do user auth and put the machine into the VLAN the user actually belongs to. This way no one could BYOD which may be infected / insecure. Additionally one could block inexperienced users from using administrative computers. The problem is this only works with an Active Directory / Primary Domain Controller, thus you need Microsoft Windows Server. It doesn't work with Samba or whatever else. Correct however is that from the FR point of view both authentications look "the same". It just Windows making a (beneficial) difference I wish every OS would do.
On Dec 28, 2015, at 9:51 AM, Ben Humpert <ben@an3k.de> wrote:
It isn't wrong terminology.
He was using the term "machine authentication" to refer to a network which didn't have Active Directory, and which had non-Windows machines. This was wrong.
One actually could use two certificates, one for the machine (is the machine allowed to access the network? If yes into which VLAN should we put it?) and one for the user (is the user allowed to access the network?).
No. Once a system is on the network, it's on the network.
Using both you could do machine auth first and get the machine put into VLAN 1 to get DHCP stuff and access to eg. Active directory (which is required for user auth).
i.e. 802.1X with EAP-TLS, and auto-provisioned credentials via Active Directory.
Then you can do user auth and put the machine into the VLAN the user actually belongs to.
No. Once a system is on the network, it's on the network. You're probably referring to "user authentication" as "user authenticates to Active Directory". This has nothing to do with 802.1X. It uses TCP/IP and proprietary Microsoft protocols. It is possible for the system to drop it's network connection, and then re-authenticate via 802.1X, and the user's credentials. Alan DeKok.
participants (9)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Ben Humpert -
Danner, Mearl -
Lukas Haase -
Matthew Newton -
Nick Lowe -
Orion Timbale