MAR Cache & Why not to use it

I recently watched a discussion on MAR unfold on WebEx. This guy had deployed MAR in his network, and now coming into the office, most people were unable to authenticate. Despite several people telling him that using MAR is a bad idea and what to do instead, he completely ignored it. He kept asking the same technical questions about MAR.

So what exactly is MAR?
MAR was an attempt to provide both Machine and User Authentication without a proprietary protocol such as EAP-FASTv2 (EAP Chaining).
The concept is simple; A User Authentication will only be successful if there is a successful Machine authentication within the last X hours already. (Default 5 hours in ISE 2.2+)

There are multiple drawbacks to this approach, though.

• The built-in Windows supplicant performs Machine Authentication only at bootup or when it’s at the login prompt (Basically as long as no one is logged on the machine)
• The MAR Cache is built on MAC Addresses causing issues for machines roaming between Wired and Wireless.

Supplicant
The built-in Windows Supplicant performs Machine Authentication only at bootup or when it’s at the login prompt (As long as no one is logged on the machine)

The idea is that you boot up the machine. At the login prompt, it performs a successful machine authentication. When you log in, it performs another User Authentication. Because there has been a successful machine authentication within the last 8 hours, user authentication is successful.

Complications occur when the client goes home and closes the laptop without actually shutting down the OS. The Windows Host takes a snapshot of the current state of the machine, and when the lid is opened the following day again, the state is resumed causing the machine to go straight back to User Authentication, but because the MAR Cached entry has expired for the machine, it’s unable to authenticate.

Wired/Wireless Roaming
The MAR Cache is basically just a list of MAC Addresses of the NICs and when they last performed a Machine Authentication. Say you dock your PC, boot it up, and log in. An entry in the MAR Cache is created for the MAC Address of your Wired NIC. At some point, you have a meeting elsewhere and undock to connect to WiFi.
When you enter your credentials for WiFi and perform a User Authentication, the MAR Cache has no way of knowing that you have an existing successful Machine Authentication from the Wired Media. It cannot correlate between your Wired and Wireless MAC Addresses.

The only solution to this is to log off, which causes a new machine authentication from the WiFi MAC Address.

Solution
The Anyconnect Supplicant also provides configurable options for MAR Cache. Still, the same issues occur in terms of Machine Authentication only being able to happen when no user is logged on. The best alternative to MAR Cache is EAP-Chaining or TEAP, which combines User and Machine Authentication in a single Authentication process.

Configuration
MAR is enabled from the Advanced Settings section of the AD Configuration (It is enabled per default when integrating an AD)

In the following example, I have created a Wired 802.1X Policy Set, which allows EAP-MSCHAPv2 authentications to be processed by Active Directory.
In the Authorization section, I have created a rule with a condition that matches whether the Computer Object is present in /Users/Domain Computers and given it limited access to the network. Since a machine authentication happens only when no one is logged on the computer, we can assume that the machine is probably at the login prompt.

Below I created another rule that matches on a successful AD User Logon and whether the machine was authenticated before the current authentication, which indicates that the user is trying to access the network from a corporate-owned device.

Authentication PolicyAuthorization Policy