If you are logged on to your computer with a domain account, change your password (say from another computer), then lock your workstation, you can unlock it with your old password even though the password has been changed. Why is that?
When you log on, the Winlogon service remembers a hash of that password, and when you attempt to unlock a locked workstation, the password you enter is hashed and compared to the hash of the password you used to log on. If they match, then Winlogon proceeds to unlock the workstation, even though the password might be stale. This behavior is a network performance optimization to avoid inundating the domain controller with authentication requests. Most unlock operations are with the correct password, and avoiding the connection to the domain controller reduces network traffic and significantly improves performance over slow network connections.
But wait, does this mean that you can't lock users out of the network by changing their passwords?
No, you can still lock users out of the network by changing their passwords. The cached password hash is used only for accessing the local workstation. Once the user tries to access a network resource, that network resource will ask the domain controller, "Hey, is this really the guy he claims to be?" and the domain controller will reply, "Nice try."
But wait, does this mean that you can keep unlocking your workstation with a stale password and therefore bypass a password change on the domain controller and thereby keep using your workstation?
Well, yeah, but you could already do that: the trick is called don't lock your workstation in the first place. If you never lock your workstation, then it doesn't matter how the workstation unlocking algorithm works, because it never even runs!
If you would prefer that unlocking a workstation connect to the domain controller to verify that the password has not expired, then you can use the Group Policy Editor to enable the Require Domain Controller authentication to unlock workstation policy.
Note that this one-level password cache for unlocking a workstation is different from cached domain logon credentials. Cached credentials are used when a domain controller is not available to verify a password. Under those conditions, the password entered by the user is compared to the one stored in the cache, and if they match (or more accurately, if the hashes of the hashes match), then the logon is deemed to have succeeded. Whereas the cache for unlocking a workstation is a performance optimization to avoid contacting the domain controller (even though it is available), the credentials cache is a fallback used when the domain controller is unavailable entirely, but you still want to let users access local machine resources.
Cached credentials can be both a blessing and a curse, depending on what color glasses you're wearing. For laptop users, cached credentials are essential for logging on to the laptop when the computer is disconnected from the corporate network. Without them, laptops would just become paperweights when not in the office, which counteracts one of the reasons for having laptops in the first place.
On the other hand, cached credentials permit an offline attack on the information stored in the credential cache. If the laptop falls into unfriendly hands, an attacker can take all the time in the world to try to guess the user's password without your domain controller finding out. Mind you, the credential cache doesn't contain the passwords or even the hashes of the passwords, so a purported "cracked" password is only a probabilistic success (and you can tilt the odds in your favor by requiring strong passwords). Of course, a stolen laptop grants unrestricted physical access to the hacker, so the unencrypted information on the laptop itself is already compromised, password or no password. Even so, if the idea of cached credentials give you the heebie-jeebies (warranted or not), you can set the CachedLogonsCount to zero to disable them. If you combine this with Require Domain Controller authentication to unlock workstation policy, you've got the password caches turned off in both directions.
Web site, "The Old New Thing
," and identically titled book (Addison-Wesley, 2007) deal with Windows history, Win32 programming, and Krashen's Comprehensible Input Hypothesis.