Windows Wireless and Cisco ACS Machine Access Restriction don’t always play nice together

Recently, I have been seeing a number of customers reporting problems attempting to implement a specific feature of Cisco’s Access Control Server (ACS) 4.0.  This feature is called Machine Access Restriction (MAR). <?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” />

The issue that arises is that this feature can sometimes inadvertently lock out a legitimate client, forcing the client to reboot in order to regain access to the network.  First, let’s talk about what this feature does.

MAR basically attempts to solve a common problem inherent in most of the current and popular EAP methods, namely that machine authentication and user authentication are separate, unrelated processes. Clients can be authenticated as a machine or as a user, but not as both simultaneously. How do you tie a user’s authentication to a trusted hardware that also needs to authenticate? 

Take, for example, a Windows Vista client.  As the machine boots it will present its credentials to RADIUS for validation.  This is a distinct individual process.  When the user logs in, the RADIUS server handles the user’s authentication also as a separate process and has no method of checking to see if the hardware the user is logging in from is trusted or belongs to the domain. 

MAR addresses this by keeping track of all the machine authentications.  It tracks the Calling-Station-Id attribute of all successful machine authentications and stores them in a database for a defined period of time, the default being 24 hours. When a user authentication is processed, MAR will check to see if the Calling-Station-Id of the user’s request matches a record in its database of valid machines.  If it matches, the user is allowed to authenticate; if it does not the request is rejected.

This sounds great, so what is the problem?

Well, while MAR is a tremendous step forward in addressing the problem described above, it does not take into account how the Windows wireless supplicant works.  I described the Windows 802.1x process briefly above and the point that should be taken way is that when no user is logged on, Windows will use its machine credentials to establish the network connection.  When the user logs on, we change security contexts so that the logged on user credentials are used for all subsequent 802.1x authentication prompts.  There are some exceptions to this, but suffice to say that whatever context we are in, we will only use one set of credentials.

Let’s take a look at the next two scenarios and we will see why MAR can sometimes cause problems.

Scenario 1:

Mr. CEO has been working all day on his laptop connected via a wireless connection.  At the end of the day, he simply closes the lid and heads home.  This puts the laptop in hibernation.  The next day, Mr. CEO comes back into the office and powers his laptop up.  Now he is unable to establish a wireless connection.  Yesterday he had no problems whatsoever, but today he cannot connect.  What has happened?

When you hibernate your Windows system, you take a snapshot of the system in its current state to include the context of who is logged on.  During the night, the MAR cached entry for Mr. CEO’s laptop expired and was purged.  However, when the laptop was powered up, it did not do machine authentication. It instead went straight into a user authentication since that was what the hibernation recorded.  The only way to resolve this is to log off Mr. CEO or to reboot his computer.

Scenario 2:

As system administrator, you have implemented 802.1x authentication on your wired network.  You have implemented a MAR cache timer of 24 hours.  The first day goes off without a hitch, but the second day you start seeing support calls that users cannot access the network.  The third day you see even more reported issues.  However, not everyone is experiencing the problem.

The problem is the same as above – the MAR cache entries are expiring.  When the end users reboot or log off, the problem is resolved because the machine authentication resets an entry in the MAR cache.  The reason this issue is not seen across the board is because some users actually log off whereas others only lock their machines at the end of the day.


Although MAR is a good feature, it has potential to cause network disruption.  These disruptions can be difficult to troubleshoot until you understand the way it works. When implementing MAR, it is important to educate your end users on how to properly shut down computers and to log off every machine at the end of the day.