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. > 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. 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. 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. > 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/> ~
