Introduction
When you are using both user and machine authentication for corporate devices (joined to an Active Directory domain) connecting to your network there needs to be something keeping track of which computers have successfully authenticated themselves.
This is because the most common EAP methods that deal with both user and machine authentication (PEAP-MSCHAPv2, PEAP-EAP-TLS, and regular EAP-TLS) only perform machine authentication during bootup or if the user logs out. For most users, this would mean that can they will have their computer go through the authentication early in the day and not again until the next day (if they remember to log out or shut down their computer, that is).
What is the MAR Cache?
The Machine Access Restriction cache, or MAR, in ISE, keeps track of computers that have successfully gone through authentication. Essentially the MAR cache is just a database of timestamps and MAC addresses keeping a record of which computers have been allowed on the network.
The timeout/aging value for MAC addresses in the MAR cache in ISE can be configured in the advanced settings for an Active Directory external identity store. In ISE 2.2 the default value for MAR is 5 hours. That means that when 5 hours have passed another machine authentication has to take place before the user can get back their proper network access. While the user won't be just thrown out from the network after 5 hours they would have to face some problem if their wireless session times out or if they disconnect their network cable to move to another room. In any case, it's gonna get ugly.
The MAR cache doesn't exactly scream security either. Since it's only based on the MAC address, anyone spoofing the MAC address of an authenticated computer could get access to whatever network the computer has access to. It's pretty common to put the computer itself on a separate subnet/VLAN while it's waiting for the user authentication to take place. This is to ensure the computer can still receive GPO updates while no user is logged in.
To have ISE look in the MAR cache to confirm that the machine was indeed authenticated as well as the user you can use the following dictionary in your deployment's policies:
NetworkAccess: WasMachineAuthenticated EQUALS True
Since the MAR cache timeout is a configurable value we can turn it up a lot to deal with at least this particular issue. You can even turn it up to even a year (8765 hours). This would make the situation somewhat more manageable, but here come the big cons:
Switching between wireless and wired connection
Since the MAC address of your computer's wireless network adapter and wired network adapter isn't the same, this means there would be some trouble switching from a wired connection to wireless, and vice versa.
Imagine starting your day connected to the wired network. You boot up your computer in the morning which triggers the machine authentication and then proceed to log into Windows which triggers the user authentication. You are assigned appropriate network permissions based on the group membership or attributes of your AD account and you're good to go.
But let's say you'll be attending a meeting for the rest of the day. You unplug your computer from the wired network and want to use the wireless network while you're in the conference room. Since you haven't gone through machine authentication with your wireless network adapter, this means your attempt to connect to the network would fail because this MAC address hasn't been added to the MAR cache, only the wireless one. To trigger the machine authentication you would have to reboot or log out, which gets annoying pretty fast. This would make sure that the MAC address of your wireless network adapter also gets added to the MAR cache.
MAR Cache is not synced between ISE PSN nodes
Unfortunately, the database of MAC addresses that is the MAR cache isn’t actually synchronized between the ISE PSN nodes (Policy Service Node, the kind of node that does the actual authentication of users and machines) or any other of the nodes for that matter. This means every PSN node only knows about the authenticated computers on the network that itself has dealt with and approved. Continue reading to see why no synchronization is gonna be really inconvenient.
When ISE PSN nodes are behind a load-balancer
In bigger distributed deployments of ISE, it is not too uncommon that the ISE PSN nodes' IP addresses are hidden behind a load-balancer. This is to evenly distribute the requests for network access so that one PSN node doesn't have to do all the work. While Cisco switches can follow a round-robin algorithm if configured to talk to several ISE PSN-nodes, Cisco WLAN controllers are kinda locked to talk to only one IP address until it stops responding, and only then will it move on to the next one in its list. A proper load-balancer (like F5) would make sure the WLC sends its requests to several different ISE PSN nodes.
Let's say you boot your computer and during the machine authentication the load-balancer makes you communicate with ISE-PSN-001 in order to authenticate yourself. The authentication is successful and your MAC address is added to the MAR cache of that particular ISE PSN node.
You continue to log into Windows. Your credentials or a certificate would be used to authenticate you as a user, but this time the load-balancer makes your computer talk to ISE-PSN-002 instead of the first one. This new PSN node has no idea of your previous successful machine authentication and will therefore deny access to the network. As you probably figured out by now, getting a successful machine authentication on ALL the PSN nodes of the deployment would be a nightmare and not user-friendly in any way.
When an ISE PSN node goes down…
In the event of an ISE PSN node going down either from loss of network, VMware crash, appliance crash, or similar, all of your users would have to manually log out to trigger a new machine authentication in order to populate the next ISE PSN node's MAR cache with their computers' MAC-addresses... there is no way this would end well.
As you can see, there are far too many potential problems with MAR which makes it almost unusable. I would definitely recommend staying away from relying on MAR and instead consider going for EAP-FASTv2 using Cisco AnyConnect Network Access Module if both user and machine authentication is required. EAP-FASTv2 has the ability to simultaneously perform user and machine authentication which means we don't have to use MAR at all.
Final Notes
Machines that use PEAP-MSCHAPv2 to authenticate themself will automatically have their MAC address added to the MAR cache. However, if you are using certificates for machine authentication then you have to make sure the following is enabled in your Certificate Authorization Profile:
