Security

Reply
Occasional Contributor II

Machine Auth and Alternative Supplicants

Hi Guys,

 

I have a client who wants to enforce the use of corporate devices (Windows 7) on a particular SSID using IAPs and CPPM.

 

We're currently solving this using Machine Authentication on the devices, followed by EAP-PEAP for User Authentication - in CPPM we don't allow the user auth to be accepted unless the device MAC Address is already assigned a specific Machine Authentication role.  

 

This works fine, however the Machine authentication is pretty weak - eg: it's pretty much the Machine Name being sent and validated by Active Directory.

 

What we'd like is to validate the Machine Auth via EAP-TLS and then the User via EAP-PEAP, and again only allow the user in if their MAC is already an authenticated machine.

 

I am painfully aware that the Windows 7 supplicant is not capable of performing these two different EAP methods on both Machine and User auth, however I was wondering what alternative supplicants people are using/recommend for this task?

 

I have had a look at:

XSupplicant - Free, but doesn't seem to install on Windows 7, so unsure if it can do the above

Juniper Odyssey - Licensed, supports dual EAP methods

Cisco Anyconnect - Licensed, unsure if it supports dual EAP methods

others?

 

Cheers,

 

Ben

 

Guru Elite

Re: Machine Auth and Alternative Supplicants

Not aware of any supplicant that can provide the machine cert via EAP-TLS and the user certificate via PEAP.  You are probably better just using EAP-TLS for machine 100% on wireless and allowing the user to authenticate to the machine via whatever the machine supports.  Configure your domain machines to use EAP-TLS with "Machine Only" under IEEE advanced settings.  Your users can login via username and password to the machine based on what is allowed on that machine

 

Upshot:  - EAP-TLS via machine certificates provides the security of having a device that is physically plugged into your network.  Users are still authenticated via whatever is allowed on your domain.  If they have a valid username and password that is allowed on your network, they get in.  If they don't, they dont.  If the device is not a domain device, it does not get on the wireless, period.

This is all assuming that you have EAP-TLS for domain machines configured and working already.

******************
Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.
******************
Occasional Contributor II

Re: Machine Auth and Alternative Supplicants

 

I understand what you are suggesting, but in sticking with Machine-Based EAP-TLS, you lose all the user-based smarts - eg: authorisation parameters and role assignment based on AD group membership etc. and User-based EAP-TLS is a nightmare of chicken-and-egg (can't log on without a certficate, can't update certficate without logging on etc.), so we don't want to go there..

 

Thanks or your feedback though - it's been a few years since I last set this up on a large scale - I can't believe this gap still exists!

 

I'm surprised Microsoft et. al. haven't addressed this yet.. Or is there something more to this in the spec that would make it hard/impossible?

Guru Elite

Re: Machine Auth and Alternative Supplicants

You should pick the appropriate security method for your deployment.  You already have a AD group policy setup.  You can:

 

- Extend this by doing machine-based wireless auth and allowing group policy to take care of the rest or:

- use PEAP with user and machine authentication and then you can use CPPM's [Machine Authenticated] built-in role and combine it with CPPM's built-in [User Authenticated] role to make decisions about devices.

 

******************
Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.
******************
Aruba

Re: Machine Auth and Alternative Supplicants


bdale wrote:

 

This works fine, however the Machine authentication is pretty weak - eg: it's pretty much the Machine Name being sent and validated by Active Directory.

 


@bdale, I for one prefer EAP-TLS in deployments, but the machine doing EAP-PEAP is no weaker than a user doing the same.   The machine does more than present its name to AD for validation; it also passes its machine password in the process, just like a user would.

 

 

------------------------------------------------
Systems Engineer, Northeast USA
AMFX | ACCX | ACDX | ACMX

Occasional Contributor II

Re: Machine Auth and Alternative Supplicants

Thanks @clembo - I'd completely forgotten about the use of the AD Machine password - that makes a lot more sense now.  

 

I have discussed with the customer and we've decided that EAP-PEAP and forcing Server Certficate validation via group policy on the wireless connection allays any concerns they have.

 

A big thanks for both your time,

 

Ben

New Contributor

Re: Machine Auth and Alternative Supplicants

Anyconnect supports dual EAP modes for user and machine.

Guru Elite

Re: Machine Auth and Alternative Supplicants

Jimmy Z

If the customer does not already use anycinnect, it would be a hardship to deploy, configure, and then train end users on what to do.

Thanks for the info, however..
******************
Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.
******************
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: