Security

We have a business requirement to only allow corporate users to connect to the corporate wireless if they are using a corporate machine and a they are a valid corporate user. Sounds normal.

Our windows devices are set to "computer or user auth".

When the device boots and is not wired to the network, it machine auths ok, and the [machine auth] entry sits in the table.

When the device boots and is on the wired network, the wireless never kicks in - as expected.

When a user logs into a device that has booted (and been machine authed) on the wireless network, then their AD credentials are checked, and the [machine auth] and [user auth] roles are checked, and then they are allowed to connect - perfect.  And when they log off again, the device goes back to [machine auth]; again - perfect.

If a user tries to use their AD credentials to logon to the wireless using a non-domain joined device (e.g. Macbook), the access is denied because there is no [machine auth] record for that device - perfect.

However....(and this is where it all falls over)  IF the device boots connected to the wired network, and has not booted on the wireless network for longer than "cache-time" (or ever), then there is NO valid [machine auth] role for that device.  When the user logs onto that device (on the wired network), no wireless auth is done - ok. IF the user then undocks the device, the wireless will kick in, and authenticate the user, which will be against their AD credentials, and the authentication will be ok.  BUT, because there is no [machine auth] role in the cache for the device, access will be denied to the network, and the user's session will be cut off with a "no wireless access" symptom, even though the device is working fine, and if they dock the device again, the network will burst back into life.

As far as we have been able to determine, the only way to get this user's wireless to work on this device is to get them to log off the device when they undock, forcing a wireless machine authentication, and then get the user to log back in again (cue screams and wails from the end users).

 

Any ideas?

 

Ross

Yes, that's correct. A log off or restart is required to trigger a new machine authentication.

 

Why not use just machine authentication? 

We need to be able to validate the end user as well, find out what domain in the forest they are in, and what groups they are members of, so we can allocate the right role/vlan back to the controllers.

The only option based on your requirements would be to use the OnGuard persistent agent on the machine to handle the user authentication. The supplicant would stay machine only.

Hmmm, that's not going to happen.

Looks like we are back to "managing user expectations"

 

Thanks for the help.

 

What radius server are you using?  If it is clearpass, why not just extend the Machine Authentication Cache Timeout?

We have already extended the timeout to 30 days.

 

The BIG issue we are seeing is those users who hardly ever/never log on/off when the device is undocked, and therefore we have a huge percentage of our device fleet that does not have a [machine authenticated] status, and that means lots of users are failing to connect because the logic says that if there is no [machine authenticated] status then it is not a corporate machine, and therefore not allowed access to corporate wireless (these devices should be on our guest SSID).

Why is using the OnGuard agent in auth only mode out of the question?

Two reasons -

1 - cost.  The business doesn't want to spend even more money on upgrading the wireless solution.

2 - device footprint.  We already have web enforcement agents, AV and anti spam and device inspection and anti malware and software white/blacklisting agents running.  It would be nice to have some memory and CPU left for running user applications.

 

Running it in auth only mode does not require OnGuard licensing and since it is not collecting health data, it uses very little resources.

AHA.  Both of those pieces of information are not immediately obvious from any of the documentation I have seen.

Thanks for that - it may be the long term solution, but in the meantime I have screaming end users.

 

Thanks again

---

@rosswakelin wrote:

We have already extended the timeout to 30 days.

 

The BIG issue we are seeing is those users who hardly ever/never log on/off when the device is undocked, and therefore we have a huge percentage of our device fleet that does not have a [machine authenticated] status, and that means lots of users are failing to connect because the logic says that if there is no [machine authenticated] status then it is not a corporate machine, and therefore not allowed access to corporate wireless (these devices should be on our guest SSID).

---

rosswakelin,

 

If a device machine authenticates successfully, any user on that machine.who authenticates within the 30 day window renews the machine authentication cache.   So even a successful user authentication within that 30 day window with the same mac address renews the machine authentication cache...

Yes, thanks, we're aware of that.  The issue is that the user auth forces an EXTENSION of a current machine auth - in our case we have users whose machine has NEVER authenticated, so there is no auth to extend.  

This issue has come about because we are moving from an older wireless technology to the Aruba, and the older platform never cared about whether the device was authenticated or not - its our own fault really for trying to increase the security level of the environment!!