PEAP and MSCHAPv2 with personal supplicant certificates
Good afternoon everyone. I'm new to freeradius and I have been trying a few setups to implement 802.1x on our wired infrastructure + WPA Enterprise on our wireless infrastructure. We have a mixed environment with Linux and Windows 7 client machines and I have successfully configured freeradius to authenticate to our AD server, through both PEAP and EAP-TLS. Over EAP-TLS the client certificate is being verified against the CA and on the CN against the declared EAP username. I am still working on encrypting the client certificate with personal passwords on each supplicant machine (and I believe I'll succeed soon). I believe I'm close to replicating this behavior over PEAP, which would add the MSCHAPv2 authentication after the TLS validation, however this is not the full functionality that we desire. The idea is to have individual certificates for each user, encrypted with a personal password. The certificates being signed by the server CA with usernames as CNs, which we are already able to check thanks to the great templates available, and as the second step we'd like to have the user authenticated (under the encrypted TLS connection) with MSCHAP against our Active Directory. The current challenge is to lock the tunneled authentication to the same username of the certificate step. This would ensure (or at least make it harder) for privileged users to steal another certificate and impersonate that user with that certificate. I'm not sure if I have made myself clear, but we want to make sure users will only be able to use their own certificates, on their own computers and not be able to authenticate their credentials with a certificate from someone else's. What has been troublesome for me is this last step, to lock the AD authentication to the same user declared on the certificate. It seems to me that the RADIUS server would be able to reject this kind of abuse, though it might not be the way it is supposed to work. I couldn't find the right documentation on how to do it, so anything close to it can help me. Our lab right now is on a Debian server with freeradius 2.2.5, but we expect to put it in production on a pfSense firewall (I should confirm soon which version will be available there). Thank you for your time, Att, *Renato Zippert*
On Sep 26, 2016, at 10:16 AM, Renato Rodrigues via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
We have a mixed environment with Linux and Windows 7 client machines and I have successfully configured freeradius to authenticate to our AD server, through both PEAP and EAP-TLS. Over EAP-TLS the client certificate is being verified against the CA and on the CN against the declared EAP username. I am still working on encrypting the client certificate with personal passwords on each supplicant machine (and I believe I'll succeed soon). I believe I'm close to replicating this behavior over PEAP, which would add the MSCHAPv2 authentication after the TLS validation, however this is not the full functionality that we desire.
Windows will not do PEAP with client certificates and MS-CHAPv2.
The idea is to have individual certificates for each user, encrypted with a personal password. The certificates being signed by the server CA with usernames as CNs, which we are already able to check thanks to the great templates available, and as the second step we'd like to have the user authenticated (under the encrypted TLS connection) with MSCHAP against our Active Directory. The current challenge is to lock the tunneled authentication to the same username of the certificate step.
You can check the inner-tunnel User-Name against the outer user-name, and against the outer certificate identity. See TLS-Cert-Subject-Alt-Name-Email in raddb/sites-available/default.
What has been troublesome for me is this last step, to lock the AD authentication to the same user declared on the certificate. It seems to me that the RADIUS server would be able to reject this kind of abuse, though it might not be the way it is supposed to work. I couldn't find the right documentation on how to do it, so anything close to it can help me. Our lab right now is on a Debian server with freeradius 2.2.5,
Upgrade to version 3. It will be a LOT easier to configure. I have no idea why Debian insists on shipping versions of FreeRADIUS that are *years* out of date. Alan DeKok.
On Mon, Sep 26, 2016 at 11:16:08AM -0300, Renato Rodrigues via Freeradius-Users wrote:
We have a mixed environment with Linux and Windows 7 client machines and I ... (and I believe I'll succeed soon). I believe I'm close to replicating this behavior over PEAP, which would add the MSCHAPv2 authentication after the TLS validation, however this is not the full functionality that we desire.
The Windows supplicant refuses to send a client certificate with PEAP, so you can't do both at the same time. You might get it working with Linux and wpasupplicant.
What has been troublesome for me is this last step, to lock the AD authentication to the same user declared on the certificate. It seems to me that the RADIUS server would be able to reject this kind of abuse, though it might not be the way it is supposed to work.
You could probably do this in the check-eap-tls virtual server in v3. But only if you got a client certificate.
right now is on a Debian server with freeradius 2.2.5, but we expect to put it in production on a pfSense firewall (I should confirm soon which version
Version 2 is obsolete. Don't use it for new deployments. Start with the latest version of 3.0. 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>
Thank you both very much for your recommendations. I'm building a new lab on CentOS 7 (for now) and I'm pretty optimistic on this. Att, *Renato Zipper * <http://www.mt4.com.br/> 2016-09-26 11:38 GMT-03:00 Matthew Newton <mcn4@leicester.ac.uk>:
On Mon, Sep 26, 2016 at 11:16:08AM -0300, Renato Rodrigues via Freeradius-Users wrote:
We have a mixed environment with Linux and Windows 7 client machines and I ... (and I believe I'll succeed soon). I believe I'm close to replicating this behavior over PEAP, which would add the MSCHAPv2 authentication after the TLS validation, however this is not the full functionality that we desire.
The Windows supplicant refuses to send a client certificate with PEAP, so you can't do both at the same time.
You might get it working with Linux and wpasupplicant.
What has been troublesome for me is this last step, to lock the AD authentication to the same user declared on the certificate. It seems to me that the RADIUS server would be able to reject this kind of abuse, though it might not be the way it is supposed to work.
You could probably do this in the check-eap-tls virtual server in v3. But only if you got a client certificate.
right now is on a Debian server with freeradius 2.2.5, but we expect to put it in production on a pfSense firewall (I should confirm soon which version
Version 2 is obsolete. Don't use it for new deployments. Start with the latest version of 3.0.
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>
participants (3)
-
Alan DeKok -
Matthew Newton -
Renato Rodrigues