Analysis: Require Domain Controller Authentication to Unlock Workstation

Among the many security options that are configurable via Group Policy, there is a setting Interactive logon: Require Domain Controller authentication to unlock workstation. For security reasons, this is often enabled. Let’s have a closer look at the implications. Those are different from what one might think because the name is a little misleading.

What Does it Do?

By default, when a locked Windows computer is unlocked, it does not communicate with a domain controller. It validates the password against its list of locally stored cached credentials. Enabling Require Domain Controller authentication to unlock workstation does not change this, at least not if the computer is offline. If no domain controller can be reached, the computer still uses its locally cached credentials to authenticate the user.

Only when the computer is online does enabling Require Domain Controller authentication to unlock workstation change the system’s behavior. In that case, it tries to communicate with a domain controller. If that attempt succeeds, it performs additional checks, for example, if the account is disabled.

Securing the Lock Screen

If you want to force communication with a domain controller when users need to be authenticated, the list of cached credentials needs to be disabled. To do that, set the following security option to 0: Interactive logon: Number of previous logons to cache (in case domain controller is not available). That severely limits the usefulness of affected computers in mobile scenarios, though.

Conclusion

The policy Interactive logon: Require Domain Controller authentication to unlock workstation should rather be called Do not use cached credentials when unlocking workstations when a domain controller can be reached. The usefulness of this setting on clients is overrated. It can be valuable to secure terminal servers, though, where end users do not have access to the physical machine.