I really don't see the need for validating complexity beyond what we already have. The only time this becomes an issue is when you make a change to an existing password complexity policy. The mostly like cause of a change in policy is a regulatory need or some incident so forcing password changes on the organization is probably a good thing (tm). As someone else has already mentioned, it wouldn't be a big deal to force password changes on a rolling basis if your organization is large enough that you don't want to do it in one shot.
-Jeff Steward On Thu, Aug 26, 2010 at 3:01 PM, Brian Desmond <[email protected]>wrote: > Inline > > Thanks, > Brian Desmond > [email protected] > > c - 312.731.3132 > > > -----Original Message----- > From: Ben Scott [mailto:[email protected]] > Sent: Thursday, August 26, 2010 1:12 PM > To: NT System Admin Issues > Subject: Re: Minimum password length GPO > > On Thu, Aug 26, 2010 at 1:40 PM, Andrew S. Baker <[email protected]> > wrote: > > You and Brian are correct about the client's knowledge of the policy, > > but the client is only responsible for enforcing the policy for the > > repository it maintains. > > Ah, so even though the client has all the code needed to enforce password > policy, it's not actually done on the client for domain passwords. > Interesting. > [Brian Desmond] Correct - all this happens inside LSA on the DC > > > Sure, it could always evaluate against local policy any password that > > the DC approved and then force a password change request for the user > > account, but even that process is not straightforward at that point. > > Well, I haven't seen the code, but the client's part of handling password > expiration already happens after the DC checks the password. > [Brian Desmond] Right but the client is being informed to request a PW > change > It seems like one should be able to add a check to evaluate the cleartext > password against policy at that point as well. The mechanism is already > there for prompting for a forced password change. > [Brian Desmond] Anything is possible although you've got totally separate > code paths here and you need to factor in a bunch of other stuff. > The client still has the cleartext password at that point, too, I think. > Obviously nothing is free when it comes to code changes, but as changes go > I would expect that to be fairly self-contained. > > Again, the above is speculation; for all I know the code's a mess and/or > has tons of hooks, and any change is a nightmare. > [Brian Desmond] It's definitely VERY old stuff. Some of this really hasn't > changed much since the beginning of time. Factor in other things like in > WS08+ you can apply different password policies to different groups of users > so now you need to calculate the effective policy before you can enforce it. > > > the benefits can be realized in other ways that are more controllable > (IMO). > > Oh, I do agree that one can achieve similar results by setting the > force-change flag whenever one changes password policy, and that since you > can break that into more-manageable chunks it actually has benefits. This > was just a "Wouldn't it be nice if". :) > > -- Ben > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ < > http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
