Finding Where Group Policy is Applied

I need some ideas on finding Group Policy -- and where things might be coming from.

We recently implemented a new Password Policy.  The issue is, it is not being applied to the users!

- We implemented complex passwords, can't reuse 3 passwords and only have to change every 365 days.
- I placed the policy in the OU in which the users live (because we want to have different policies per OU in the future)
- It is still forcing people to change them every 60 or 90 days (whatever they were previously made to do).
- I have removed that setting or changed in every policy I can find it.
- Other polices I have applied work.
- I have also tried doing it in the Win2012R2 console as Microsoft suggests for more granular password policies via groups -- no good.

Environment: Windows 2012R2 Active Directory Domain in Native Mode, 2 Domain Controllers

I am going to attach a screenshot of one of the OUs for reference.

What is the best way to find where this policy is being applied in a way that is not allowing me to even apply it when I put the policy at the top in the OU?  Help would be appreciated!  Thank you in advance!
Cedar Crest CollegeAsked:
Who is Participating?

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

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.

This is working as designed. The web (including EE) is full of explanations about this.
The default password policy ...
* must be linked to the domain root
* must apply to the Domain Controllers
* when applied to an OU with user objects, it will have no effect
* when applied to an OU with computer objects, it will only influence the password policy for local accounts on said computers
Full stop. That's how it is. No "whens", "buts", "ifs", "blocking inheritance", "enforcing", "filtering".

For everything else, you will need "Fine-Grained Password Policies".
Note that you can't apply password policies by OU, not even with Fine-Grained Password Policies; you will need security groups.
This definitely works, unless your AD has serious issues:
Step-by-Step: Enabling and Using Fine-Grained Password Policies in AD
Cedar Crest CollegeAuthor Commented:
That makes sense and thank you for that information -- but you did not actually answer my question.

There is nowhere that I can find that has the 60/90 day password expiration set.  And I have tried the fine grained based on those instructions... and it sort of works but does not change the password expiration.

If I look in the policies that are linked to the domain root, and no password policy is set there... where else am I looking?
Cedar Crest CollegeAuthor Commented:
Follow up question: if I do put the password policy in domain root (which I have to according to your list) -- I can then go into granular settings and that will override the ones set at the root?
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

If no password policies are configured, then the default settings apply.
You can run rsop.msc or a GPMC report for a DC and check where (and which) the password policies are coming from. You might want to do that for each DC. If the settings differ, you have a replication problem, or your DCs organized in a strange way.
Yes, fine-grained password policies have priority over the default password policy.

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
Shaun VermaakTechnical SpecialistCommented:
The domain password policy does not need to be linked to domain root or domain controllers, only the PDCe

The reason for putting it on the domain root relates to setting a password policy for local accounts on domain members

You cannot create more that one password policy for domain password policy only for local password policy

To create multiple domain password policies use find-grained password policies (actually a PSO object, not a GPO)

With a PSO you can do interesting things like:

How to create an Intelligent Password Policy for Active Directory
The password policy gets created on domain root when you form new AD domain, that is default domain policy and password setting in this policy would always win regardless you apply new password gpo on ou level or even on domain controller ou
You may attach new password policy at domain root level
What happened here is you have cleared password settings from default domain policy and removed any other policy from domain root which contains password policy
But this action will enforce ad to apply default policy to all users which keeps passwords for 42 days i believe
Better you add password settings with your choice back in default domain policy or any other policy applied to domain root and let allow to replicate it to all dcs
After that you can have granular settings in fine grained password policy/ies and apply it on ad groups
The fine grained password policy overrides default password policy set at domain level for that group
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
Group Policy management

From novice to tech pro — start learning today.