Q: Does a Windows workstation contact the domain controller (DC) to authenticate a user’s credentials when he or she attempts to unlock the workstation, or does Windows rely on information collected at the time the user originally logged on?
A: The Interactive logon: Require Domain Controller authentication to unlock policy is disabled by default. With that policy disabled, a Windows workstation uses cached credentials on the local workstation to authenticate the user. If you enable this policy, Windows won’t unlock the workstation until it contacts a DC to authenticate the user against the account’s current credentials stored on the DC. You’ll find the Interactive logon: Require Domain Controller authentication to unlock policy by running gpedit.msc, loading your local computer’s Group Policy Object (GPO), and looking under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.
What difference does the setting make in practical terms? With the policy disabled, it’s possible for someone to disconnect a locked workstation from the network and then unlock it using an old password or a disabled account, although the chance of that weakness being exploited is pretty slim. If you enable this policy, you’ll generate a little more work for DCs because they'll now be servicing authentication requests whenever users unlock workstations.
If you’ve enabled audit account logon events on your DCs, you’ll also get additional Account Logon events whenever a user unlocks a workstation, and it will be difficult to distinguish events that indicate new logons from those caused by users unlocking a workstation. For what it’s worth, you can more easily distinguish unlocked consoles in a workstation’s Security log than you can in the DC’s Security log. Enable audit logon events (not to be confused with audit account logon events) on the workstation and then look for event ID 528 (Successful Logon)—in Vista, event ID 4624 with a Logon Type of 7.
