Cisco ISE Machine Authentication Cache

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.


7 thoughts on “Cisco ISE Machine Authentication Cache

  1. I too had a lot of issues with machine authentication timing out when using PEAP. Frankly, it was a pain, so switched to EAP chaining with EAP-FAST just as you say, which always sends machine and user authentication together. One other gotcha I found was that Windows 8 would not pass the machine password to the anyconnect client, but after applying a microsoft hotfix, that issue was resolved.

    1. Thanks Hroyd for your comments. A couple of months ago, I completed a pilot where the network admin was using Win8 for several test laptops. When testing the use cases requiring machine authentication, the Win8 machines failed. A bit of research came up with the need to apply hotfix There is an AC3.1 bug you can review as well that mentions this hotfix: CSCuc13862. We tested AC3.1.3103, AC3.1.2040, Win8 native supplicant, and all needed that hotfix for machine authentication to work.

      Another note is that IE10 running on Win8 does seem to require compatibility mode when using the redirect to deploy the NAC Agent.

    2. I am planning to use PEAP for machine authentication
      So if I turn out the Aging Time for machine auth cache to 8 days (Administration->Identity Management->External Identity Sources->Active Directory->Advanced Settings)

      What would be the effect of thise PEAP session time out
      Administration > System > Settings.

      1. John,

        The PEAP session timeout is to allow ISE to cache the TLS session created during the first phase of PEAP (but cached only if PEAP phase two is successful). If a user needs to reconnect and the original PEAP session has not timed out yet, ISE will use that cached session allowing subsequent authentications to be faster (while that session is active). This is related to an individual session and not specific to machine authentication. The Aging Time tells ISE how long to keep record of machine authentications from the endpoints. Many authz policies for 802.1X have conditions that not only verify a user credential, but also verify that ISE has seen a successful machine authentication for that endpoint. Also, you would have to have Machine Authentication and MAR (Machine Access Restrictions) enabled at Administration -> Identity Management -> External Identity Sources -> Active Directory -> Advanced Settings. Often, we use machine authentication to help differentiate between personally owned devices and corporately owned/provided devices. The corporately owned devices would be joined to the corporate domain and can therefore perform a machine authentication if configured to do so. The personally owned devices could not since they would not be part of the corporate domain.

  2. Thanks Twireless
    Many user on my network disconnect and reconnect his network cable several time without close windows session

    It mean that if I use default PEAP session time out (Administration > System > Settings)
    and configure Aging Time for machine auth cache to 8 days (Administration->Identity Management->External Identity Sources->Active Directory->Advanced Settings)

    Machine authentication will hapen at the day 1 first connection then user will have access without need to restart or log off – login windows session

    And machine authentication will hapen again only at day 9

    1. Hi Steve, just the Base license should allow you to take advantage of EAP Chaining. Keep in mind that you must have the AnyConnect NAM module in use on your endpoints to have the option to use EAP Chaining. RFC7170 is out there for the TEAP specification, but it appears to be a little into the future before we’ll see that supported in native supplicants. TEAP will be a standard EAP type that will hopefully be adopted by most supplicants so we can use EAP Chaining without a 3rd party solution. Don’t get me wrong, I like AnyConnect, but there are times where a native supplicant is the only option – whether that be because of feasibility or politics…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s