Freigeben über

Some Password Policy Settings Are Not Enforced When Disconnected

  • Artikel

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.

Comments

  • Anonymous
    April 23, 2006
    Of course, Jesper, you still have tha account lockout problem with expired passwords for your Outlook/OWA users.  It is nice that we do not lockout the account on the local machine.  It is a problem, though, when my usually disconnected and mobile users are trying to access mail and get locked out.  

    At some point, it would be nice for OWA and Outlook to spit back an error complaining about an expired password.  At least I would get a much better response from my users as opposed to "I can't get my mail."  

    Any thoughts on how this will be managed in the future?  
  • Anonymous
    April 25, 2006
    Not a big point by any means but...  you stated, "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."

    Of course, IF this were the only reason then it would still be better than allowing the infinite number of attempts away from the network that the system allows now.
  • Anonymous
    April 25, 2006
    JC, I actually would not mind much if the account lockout functionality were removed from the operating system (not that it ever will be, it is a CC requirement). The problem is that account lockout is attempting, and failing, to protect against the problem of bad passwords. Unfortunately, bad passwords will fail eventually, whether you have account lockout or not. The proper solution to that is to not use bad passwords, which is surprisingly easy. Even something that we would consider pretty lousy resists account lockout well. Mathematically, if you can make the assumption (which may be a stretch in some environments today) that the password is seemingly random to the attacker - in other words, the attacker cannot use heuristics to attack it - then even a 6-character password based only a character set consisting of the upper case, lower case, numbers and top row characters will resist the types of attacks account lockout protects against for far longer than those passwords will be good for. I addressed this at length in my FAQ on passwords, at http://www.microsoft.com/technet/community/columns/secmgmt/sm1005.mspx.
  • Anonymous
    April 25, 2006
    Jason (sorry for answering these out of order), have you seen problems with expired accounts in Outlook? I think OWA might block them, but Outlook with RPC over HTTPS does not in my experience. I was still able to use it when mine expired a while ago.

    That said, it would be nice to get beter error messages. I don't know if the team has plans on fixing that but I'll pass along the feedback. You may want to submit that to the Exchange team blog too.
  • Anonymous
    April 26, 2006
    Jason, I just got this KB forwarded to me:
    http://support.microsoft.com/default.aspx?scid=kb;en-us;297121

    It describes how to use the change password feature in IIS in conjunction with OWA. When you do that users will get much better prompts and password management ability in OWA.
  • Anonymous
    April 28, 2006
    RPC over HTTP does not lock your users out because it uses basic authentication. Basic authentication in IIS is not integrated with the Domain Lockout Policy, AFAIK.
    At least not until IIS5 for sure. Not sure it this changed in IIS6 (don't think it did but I have not tried nor extensivelly searched for that) or even if it will change in IIS7.... it might be something to consider, though, if it has not been changed yet.
    In fact, until now, brute forcing account passwords over basic auth is possible without having the acounts locked out..... it is even a suggested technique in one of the "Hacking Exposed" serie of books, if I don't recall wrong....

    When using OWA with Forms-Based auth, instead, the application might have its own logic to handle this, but I am also not really sure it actually does (you should talk to the Exchange/OWA team to know this...).
  • Anonymous
    May 02, 2006
    Jesper: Apologies for not getting back in a timely fashion on this one.  I was running around fixing some other stuff last week.  Namely, getting my wiki working.  ;-)

    Essentially, RPC over HTTP works wonderfully.  I have had problems when users have become locked out--that normally occurs after a user "fat-fingers" their password in the authentication dialog they see in Outlook in this scenario.  As a result, Outlook continues the authentication process until it locks the user out.  Of course, the user gets no notification that their account is locked, and I normally get a call.  

    As for the KB you mentioned, I am looking at it now.  I believe I will definitely be giving it a look and possible implementation within the coming weeks.  Thanks for passing it along!