NAC reports that a wired Windows 7 client's authentication request has become stale. This occurs on both EOS and XOS platforms. Here's the scenario. The Windows 7 host is setup to authenticate using host name, which has been joined to the Domain. On boot-up, Host authentication is successful to NAC based on machine name and then a local admin account on the Windows 7 machine is used to login to the machine. Once logged in, the Authentication information in the Local Area Network interface configuration is changed from Computer Authentication to User and Computer Authentication. Immediately, the host uses the Administrator login as the User credentials and fails, since it is not a Domain account. NAC responds to the switch with respect to the failure and the switch notifies the host machine. A packet capture shows the switch sending a packet to the host, but the host doesn't respond. After some research, this Microsoft Windows 7 SP1 bug was discovered to be the culprit.
Interestingly, logging off and back on, as well as rebooting, doesn't usually clear the situation. After time, the host starts talking .1x again, as observed by seeing EAP packets captured from the port, but it's not clear how long this time window is. Disconnecting the Ethernet cable to the host seems to reset the DOT3SVC more reliably, but there were times it did not. Restarting the AutoConfig service (DOT3SVC?) was more reliable.
Rather than risking the Microsoft Hot Fix, Domain credentials were used to authenticate to the domain initially, so that a .1x failure didn't occur when using the local Administrator account. Any authentication failure, host or user, along the way would usually trigger the Microsoft issue.