Security

In an age where users (including myself) "CLAM" machines, and don't power off. Waking from sleep seems to cause issues with Aruba + EAP MS-CHAPv2.

In our 802.1x policy, we have

    Machine Authentication: Default Machine role : Authenticated   <- full network access

    Machine Authentication: Default User Role: Logon                     <- access to the logon systems

Often when waking, the machine isn't "Authenticated" - it seems fine with the user, but somehow the machine hasn't authenticated.

I understand from our support company that there is a "timeout"? To help with this, but the PC needs to fully login.

That's not acceptible in a world where people CLAM shut their device.

So I am left trying to fix this, or find another solution - which so far is a choice of 2:

1. EAP TLS - and have the support overhead of managing certificates on devices
2. PPSK (move to Aerohive) and use a unique WPA2 key for each user.

I really like the idea of PPSK, and now have Aerohive on trial. But that is a big step and we are invested in Aruba.

But it is all about user experience, so if at the end of the day PPSK works, so be it.

Does anyone else have knowledge in this area and can give me some avenues to explore?

Romulan,

The Machine Authentication Cache timeout determines how long a user can shut his/her machine before the machine authentication is checked again.  By default it is 24 hours, but it certainly can be extended to obtain the behavior you desire if you want to deal with that situation specifically:

(Aruba3600) #show aaa authentication dot1x default | include Machine
Enforce Machine Authentication                             Disabled
Machine Authentication: Default Machine Role               guest
Machine Authentication Cache Timeout                       24 hr(s)
Blacklist on Machine Authentication Failure                Disabled
Machine Authentication: Default User Role                  guest

 There are more flexibile solutions with an external radius server like CPPM, but if you only want to deal with that issue with sleeping devices, the parameter above deals with it.

Thanks. What is "typical" for this setting? Would 7 days be considered too long? I'm presuming people would reboot at least _once_ per week.

 It all depends on your environment.  Try it with 7 days (168 hours) and see.  

If you make the change, please keep in mind it will take effect for only NEW machine authentications, going forward.

I would also recommend looking at ClearPass.  That will allow you to get much more flexible with machine authentication, TLS certificates (using OnBoard), and still allowing users access regardless of the machine going to sleep.  The Machine auth parameters set on the controller would go away in favor of more policy management with ClearPass!

What some of our customers do is to switch to machine authentication. You can configure Windows to use the machine and/or user account to authenticate.

By using the machine account only, you are certain that only AD managed systems get on the network. That is a more secure alternative than PPSK, as PPSK does not check any domain membership for the client.

With a AD group policy, you can easily enroll all your clients with these settings.

If you add client (user/device) certificates to that, the authentication is even stronger. When using AD, machine certificates can be automatically enrolled to your domain systems (with Microsoft Certificate Authority).

ClearPass Onboard can distribute certificates to non-Active Directory systems. You may also create accounts (in the local database) for unmanaged devices and let those be used to authenticate a device (or user).

Summary:

- EAP-TLS provides the best security, for Active Directory managed systems this is also easy to deploy, no device configuration required. For non-AD systems, Onboard can be used.

- EAP-PEAP with dedicated user accounts (in local database, or ClearPass, or AD in a specific OU/Group) gives you the same functionality as PPSK, but based on technology standards.

- Use 'machine authentication only' if you want only domain machines on the network.

Aerohive's Private PSK solution is an excellent solution for guest users (unique passphrase per user with each passphrase having an optional duration limit) but has the same security issues as a standard PSK.  Therefore, it should not be used for domain level access unless you are comfortable with PSK level security.