Unable to modify Local Security Policy settings on domain joined Windows 7 machines

Hello
We are maintaining a 2008 Active Directory Environment with Windows 7 workstations. Much of user\workstation management is handled through Group Policy. We do not normally use local user accounts except in 2 or 3 instances. The password policy that is configured via Group Policy for domain users does not apply to the rare instances where we are using local user accounts to login to domain joined machines. We have confirmed through testing that the Local Security Policy on those machines is governing the password policy for local user accounts. However, we are unable to modify the Password policy through Local Security Policy (secpol.msc) on the local machine. If I disjoin one of the affected machines from the domain, I am then able to modify Password policies via secpol.msc. However, rejoining the machine results in the original issue reappearing. I am not able to find where the cause of this problem lies. I've reviewed our Group Policy settings and I cannot find what prevents us from editing local group policy on domain joined workstations. Any recommendations?
Thanks in Advance
dwl805Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

David Johnson, CD, MVPOwnerCommented:
Always remember LSDOU, where the higher numbers overwrite the lower ones.
1) Local, (2) Site, (3) Domain, (4) OU
Walter CurtisSharePoint AEDCommented:
Isn't  password policy a domain policy that can't be overridden. (At least in old AD). That means that the domain password policy is applied when the machine joins the domain. Yes, taking the machine out of the domain allows local policy to kick in.

This could be all wrong though, this is how it was done in W2K3 server.
dwl805Author Commented:
The issue here is our ability to manage Local Security Policy, which affects local user accounts on a machine. While password policy for domain users can't be overridden, it is the local security policy which governs password policy for local user accounts. At the moment, the password policy for local user accounts does not match what we have implemented for domain users. And again, currently we are unable to modify the Local Security Policy on a domain joined workstation.
The 7 Worst Nightmares of a Sysadmin

Fear not! To defend your business’ IT systems we’re going to shine a light on the seven most sinister terrors that haunt sysadmins. That way you can be sure there’s nothing in your stack waiting to go bump in the night.

Walter CurtisSharePoint AEDCommented:
Yes, as David listed above, on a Domain machine, domain policy overrides local security policy. That is per design. If that were not the case every local admin on the machine (and in some companies that would be everybody), the user would set his account to never expire and other "nice" settings that would make any company or domain security policy useless.

Hope that  helps
dwl805Author Commented:
So the implication here is that neither a domain or local admin has the ability to manage password policy for local user accounts, even if the password policy for local user accounts is not consistent with what the domain policy dictates.
Walter CurtisSharePoint AEDCommented:
Local accounts can have some setting such as "password never expires" active and it will work, because that is not overwritten by any GPO. A local password policy such as expiration interval or password complexity is overwritten by Domain policy when the machine is part of a domain.

After reading your original questions again - yes, you are able to modify local policy when the machine is not in the domain, as soon as the machine joins the domain, that is no longer possible. The machine become part of the collective and is assimilated (a little Borg terminology there).

What are you trying to configure for the local account. What settings do you need to modify?
dwl805Author Commented:
I am trying to configure the password policy for local user accounts so that it matches the password policy for domain users. This is the issue.

 For a little clarification, we have third parties who use our resources periodically. We do not wish to give these users domain credentials. We have historically given these users a local account to use and do not intend to deviate from that. For the record, no one outside of IT staff has local admin privileges on any workstation.
Walter CurtisSharePoint AEDCommented:
That makes more sense now, and great about the local admin privileges. Wish more people had that best practice in place.

Here is a good article that might help. I am sure you know and have tried this, but here it is just in case:

https://technet.microsoft.com/en-us/library/cc770642.aspx

I am not sure if this is going to be overridden by the Domain Policy. I have used local accounts as service account and normally I don't want passwords to expire. That setting is not overridden I know.

Hope that helps
dwl805Author Commented:
We have found the cause of the issue here. While, the password policy for domain users is configured under our default domain policy, the password policy for local users on domain joined machines exists in other GPOs governing specific OUs. We can modify those policies there. That has been tested and verified. Thanks.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Walter CurtisSharePoint AEDCommented:
Glad you found your solution! Good job.
dwl805Author Commented:
We were able to determine the cause and the solution ourselves. While the other comments were useful, they did not provide a solution to our issue.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Security

From novice to tech pro — start learning today.