Some Password Policy Settings Are Not Enforced When Disconnected

This is a post I was asked to do a while ago and have been procrastinating on. I apologize for that. For various reasons, every so often, certain FAQ items come up again. One of them is whether certain password policies are enforced when a system is not on the domain. It makes sense to once and for all declare how it really works.

When a domain-joined system is not connected to the domain you can still log on to it with cached credentials. I have addressed how those work both in the book and in a separate article, so I will not go into that here. However, it is important to understand that when you logon with cached credentials certain password policies cannot be enforced. The policies that do not get enforced are the account lockout and password expiration settings.

The reason these are not enforced is because of how they are enforced on domain joined systems. Let's look at each in turn. Password expiration is easiest, so we will do that first.

When a credential is cached locally it is cached by doing another cipher operation on it and then stored in the security key in the registry. Only the credential is cached, however. In the case of a password logon that means the password hash. In the case of a smart card logon both the public key and the password hash are cached. No other information about the account is cached. That means that while getting logged on with cached credentials the system has no knowledge of the expiration date of the password, and therefore cannot enforce that. Of course, we could cache the expiration date, but two problems would occur if we do that. First, and most obvious, it would prevent you from logging on at all. If you have to log on with cached credentials you cannot reach the DC. If you cannot reach the DC you cannot change the password. If you cannot change the password you cannot extend the expiration so the only option the system has is to block the logon. You can imagine the havoc this would cause. You are on an airplane. You have to log on to do some work. You can't because your password has expired. Now your options are to either use the horrendously expensive AirPhone, or the slightly less horrendously expensive in-air WLAN, if either is available, to VPN in so you can change your password. Alternatively, you turn off your system, have a glass of The Glenlivet, and watch the inflight movie instead. (Now that I think about it, that's not so much of a problem really, is it?) The second problem you would run into is that the administrator may well have changed the expiration date on the account on the domain while you were gone. However, the roaming system does not know that and cannot enforce it. Obviously that is much less of an issue, but it could still cause problems.

The second setting that is not enforced when disconnected is the Account Lockout setting. If you have read my writings in the past you know that my opinion is that you should never use account lockout anyway, but it is also not enforced. The reason has to do with how it is enforced when you are on the domain. When a user logs on to a system the request is handled by a domain controller (DC). If the authentication fails on that DC the request is forwarded to the Primary DC (PDC, or in the case of Windows 2000 and higher, the PDC Emulator). Only if it fails there is the account lockout threshold counter incremented. The lockout counter is actually maintained on the PDC. Each DC has a local account lockout counter, but only if the PDC is not available are those used. If it were maintained and incremented on each DC then it would have to be synchronized with all the DCs, otherwise the user would get n tries per DC. By forwarding to the PDC we avoid that issue, and the associated performance hit with it. However, since account lockout is only tracked on the PDC, by definition, it is not enforced when the system cannot reach the PDC. If it were, we would run into the same synchronization problems we would have on the domain. A user could try n passwords on the client and then another n on the DC. Further, what happens on the client if the account is locked out? How does it get unlocked? Only domain admins can do that. Here again is the "airplane problem," except that in this case, just VPNing in would not resolve the problem. Requiring users to take their machine back into the network just to get their accounts unlocked is untenable. Therefore we do not enforce account lockout at all when the machine is disconnected.

There are a couple of related KB articles on this, such as 297157 and 906305. However, as far as I know there is nothing stating explicitly what I say above.