I've seen what you're describing a few times, but for different reasons.
In your scenario, are the controllers the user is moving between a master/local, or master and different master (or in fact a local off another master)? i.e. are they moving between controllers that don't have a direct relationship (I'm not talking about mobility relationship)?
If so (and if I remember how this works correctly), the machine-auth enforce won't always kick even if you have mobility configured etc. The machine auth-enforce works by adding a mac to the local user database (of the host) during initial boot-up. It's important to note that most MS OS hosts typically only do this when it thinks no user has ever logged on (i.e. during boot). When a subsequent user auth comes in (when a user roams or logs in initially), the controller actually checks the local database for a host mac (which gets added when the host connected during boot up). If it's not there, the user gets a restricted role. Note that in this scenario, a
Let's look at what happens to you. You say sometimes this works, and sometimes not? If so, I'm guessing this might also be determined by the time it took the user to move and where they went (out of APs range or not). Check your user AAA and firewall idle timeouts as a guide for this too. When a user does roam to the new controller, the machine will most likely still send a dot1x when the user logs back in. This is irrespecitive of if the WiFi nic is on or off. I've observed different client nic behaviour, but most often the host/nic combo will send another fresh dot1x when the user logs in (after lifting the lid). You could confirm this by looking at your radius logs. If this is happening, and the controller database that the user moved to doesn't have their mac in it, they'll get restricted UNLESS an original user entry is on the previous controller with a full role. So...
1. User does initial log on. All good.
2. User moves (at this point, the original controller might also start idle timers (if it sees no user packets)).
3. User opens lids and tries to logon.
IF the user sent no packets between steps 2 and 3 (very likely with lid shut), and the length of time taken was greater than the user timeout;
A. The original session on the first controller would have aged out and been removed. The result would be mobility wouldn't help, as this isn't a roam anymore (client isn't roaming, they're silent moving).
B. When the laptop wakes up at the new location, it starts a fresh dot1x on a new controller (which doesn't have the host mac in the DB potentially) using user credentials (instead of host) and gets restricted. You reboot (which causes a host auth) to resolve the issue.
Point B might also be affected by the role of the second controller. I'm a bit sketchy on my memory of this, but I'm pretty sure in v5 the controllers always leverage their own databases for machine-auth enforce. However, it might be that locals check against a master (but I'm not sure they'd be able to add macs to it). Note this feature changed massively in v6 (now uses local key caches etc in addition).
So... you should do a controlled test.
1. Check your user idle timeouts.
2. Get a user to "roam" having made a note of the original controller type, second controller type and time they took. Actively watch on the controllers for the user as they idle out on the original and get added to the second.
3. When they open the lid, if they get restricted (before rebooting) record how long they took, and whether the first idled them out before the second saw them. Also, check the new hosting controller local-user db. Is their host mac there?
If the user idle timeout didn't purge the user, and they did achieve proper mobility in this case, I'd expect them to get their original role. However, I'm wondering if either;
1. The machine-auth enforce is over-riding the mobility (user role during handover doesn't get preserved)
2. and/or the user entry is aging out on the original before the new one starts, therefore this isn't a roam at all and you start as a user (get restricted).
I'm also asking the other questions to refresh my memory about where v5 local-db macs for hosts get added (local dbs or up to the masters)! :-)