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.



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

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.

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

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
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..


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: