Local accounts can actually look at the password policy applied to the container the computer object resides in.
So if you think LDSOU for policy application it is the one time where the "one password policy per domain" has a caveat. You can apply a password policy on a OU that will affect the LOCAL account on the computers in the OU. Of course I am talking native stuff here (no customized code) and pre-FGP policy now in 2K8. From: Jon Harris [mailto:[email protected]] Sent: Friday, March 19, 2010 3:19 PM To: NT System Admin Issues Subject: Re: Determining Password Complexity Requirements Either Bob is right about a custom GINA or local policies are over riding domain policies. Then again local accounts only look at the local policy I believe. Jon On Fri, Mar 19, 2010 at 3:08 PM, John Cook <[email protected]> wrote: Sounds to me like it has some malware (wink) I'd nuke it and rebuild! ________________________________ From: Free, Bob To: NT System Admin Issues Sent: Fri Mar 19 15:01:25 2010 Subject: RE: Determining Password Complexity Requirements Does it have a custom GINA? ________________________________ From: John Hornbuckle [mailto:[email protected]] Sent: Friday, March 19, 2010 10:46 AM To: NT System Admin Issues Subject: RE: Determining Password Complexity Requirements Thanks-we'll check this out. The other weird thing is that we can't access the machine via Remote Desktop or Remote Assistance. We have group policies to enable these, but either they're not accepting connections on this machine or there's some other software blocking access. We checked Windows built-in firewall, and it's configured to allow (our domain policies configure this). Grrr.... From: Joe Tinney [mailto:[email protected]] Sent: Friday, March 19, 2010 1:39 PM To: NT System Admin Issues Subject: RE: Determining Password Complexity Requirements John, Try running secpol.msc (Local Security Policy) and looking at Account Policies > Password Policies and see if that differs from the information you are seeing in gpedit.msc (Local Group Policy). I can't recall if they are different or if they operate independently, but it can't hurt. Also, from my experience, this is one of those settings that doesn't revert itself once the policy is no longer applied to the machine. I've had to go in and manually change this when we've needed to take the machines off the domain and use them for other purposes. Best of luck, Joe From: John Hornbuckle [mailto:[email protected]] Sent: Friday, March 19, 2010 11:26 AM To: NT System Admin Issues Subject: Determining Password Complexity Requirements We have a machine that the Army sent our ROTC folks, and it's giving us a hard time. It's not our standard machine, and came pre-configured from the Army. We joined it to our domain, and it seems to be picking up group policy from the domain-but a couple of things still aren't right. The biggest issue is that something on the machine seems to be requiring passwords of greater complexity than our domain policy requires. What I can't figure out is (A.) why that is and (B.) what those requirements are. I had my technician run gpedit.msc on the machine and look under Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy. All of the settings there match our regular domain settings. And yet every time she tries to set a local account's password to one that we know meets those requirements (because it's one we use on multiple machines with no problems), Windows pops up a dialog saying it doesn't meet the requirements. But if we put in a (much) longer and more complex password, the system will take it. I ran through the fix from MSKB 313222, but to no avail (although that did fix several other settings the Army had imposed on the machine). So, what the heck? Where is this machine getting its ideas about password requirements from? And how can I determine what those requirements are? John Hornbuckle MIS Department Taylor County School District www.taylor.k12.fl.us <http://www.taylor.k12.fl.us/> NOTICE: Florida has a broad public records law. Most written communications to or from this entity are public records that will be disclosed to the public and the media upon request. E-mail communications may be subject to public disclosure. NOTICE: Florida has a broad public records law. Most written communications to or from this entity are public records that will be disclosed to the public and the media upon request. E-mail communications may be subject to public disclosure. ________________________________ CONFIDENTIALITY STATEMENT: The information transmitted, or contained or attached to or with this Notice is intended only for the person or entity to which it is addressed and may contain Protected Health Information (PHI), confidential and/or privileged material. Any review, transmission, dissemination, or other use of, and taking any action in reliance upon this information by persons or entities other than the intended recipient without the express written consent of the sender are prohibited. This information may be protected by the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other Federal and Florida laws. Improper or unauthorized use or disclosure of this information could result in civil and/or criminal penalties. Consider the environment. Please don't print this e-mail unless you really need to. This email and any attached files are confidential and intended solely for the intended recipient(s). If you are not the named recipient you should not read, distribute, copy or alter this email. Any views or opinions expressed in this email are those of the author and do not represent those of the company. Warning: Although precautions have been taken to make sure no viruses are present in this email, the company cannot accept responsibility for any loss or damage that arise from the use of this email or attachments. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
