Security

last person joined: 13 hours ago 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

Machine Auth and Alternative Supplicants

This thread has been viewed 2 times
  • 1.  Machine Auth and Alternative Supplicants

    Posted Sep 22, 2013 08:36 PM

    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

     



  • 2.  RE: Machine Auth and Alternative Supplicants
    Best Answer

    EMPLOYEE
    Posted Sep 22, 2013 08:55 PM

    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.



  • 3.  RE: Machine Auth and Alternative Supplicants

    Posted Sep 22, 2013 10:29 PM

     

    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?



  • 4.  RE: Machine Auth and Alternative Supplicants

    EMPLOYEE
    Posted Sep 22, 2013 10:35 PM

    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.

     



  • 5.  RE: Machine Auth and Alternative Supplicants
    Best Answer

    Posted Sep 23, 2013 01:02 PM

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

     

     



  • 6.  RE: Machine Auth and Alternative Supplicants

    Posted Sep 24, 2013 12:55 AM

    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



  • 7.  RE: Machine Auth and Alternative Supplicants

    Posted Dec 23, 2014 07:57 PM

    Anyconnect supports dual EAP modes for user and machine.



  • 8.  RE: Machine Auth and Alternative Supplicants

    EMPLOYEE
    Posted Dec 23, 2014 09:03 PM
    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..