On a recent deployment, I noticed that some user authentications were failing because the machine authentication record for their device no longer existed in the ISE machine auth cache. The deployment was in monitor mode so the user never knew there was a problem. But, on occasion, I’d see a reauth meet the “WasMachineAuthenticated” condition in my AuthZ policy. In looking into it further, when a user logged off and back on, or rebooted and logged in, the policy would match. As it turns out, the Aging Time for machine auth cache entries was set to 6 hours (Administration->Identity Management->External Identity Sources->Active Directory->Advanced Settings). So, if the user doesn’t logoff or reboot within that period, their machine auth record is purged. Herein lies a major issue with MAR (machine access restrictions) – where the auth server is mapping a machine auth with a user auth. We do this a lot to provide differentiation between corporate provisioned workstations and those that employees bring from home (or guests of course). So, you have to get that cache entry to remain for a longer period of time so when a user logs in, there is a machine auth entry that ISE can map with the user auth. The common workaround at this point is to extend that machine auth Aging Time to a longer period. This particular customer automatically reboots every machine in the network on Sunday mornings. So, by setting that field to 8 days, we pretty much ensured that the machine auth record would be there for ISE to use in a user auth attempt.
The real solution to this problem is to use EAP Chaining with EAP-FAST v2. This bypasses MAR altogether because in the auth attempt, the supplicant provides the authentication server (ISE) both the machine and user credentials for each auth attempt. Currently, this is only supported by the Cisco AnyConnect 3.1 client/supplicant (free). There is also a checkbox in ISE to enable its support (Policy->Policy Elements->Results->Authentication->Allowed Protocols->Default Network Access <for example>->Allow EAP-FAST). I have to imagine that the adoption of the AC 3.1 client will increase significantly, especially when Cisco integrates the NAC agent into the AnyConnect product.
Many customers still resist adding another piece of software to their builds though. For the IT department, it is another thing to manage. But, this process is a bit easier if the customer is already planning to use AnyConnect for their VPN access. In this case, you are simply “bolting on” the NAM module in the AnyConnect client, not installing a totally different piece of software.