I agree. Some customers do have specific needs around complexity outside of what the built-in functionality can provide. These customers typically a) force all password changes through a web portal, or b) put a third party password filter in, or c) try and DIY on the password filter (rarely good).
Thanks, Brian Desmond [email protected] c - 312.731.3132 From: Jeff Steward [mailto:[email protected]] Sent: Thursday, August 26, 2010 2:56 PM To: NT System Admin Issues Subject: Re: Minimum password length GPO 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]<mailto:[email protected]>> wrote: Inline Thanks, Brian Desmond [email protected]<mailto:[email protected]> c - 312.731.3132 -----Original Message----- From: Ben Scott [mailto:[email protected]<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]<mailto:[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/> ~
