Cedar Crest College
asked on
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!
Screen-Shot-2018-10-16-at-11.03.04-A.png
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!
Screen-Shot-2018-10-16-at-11.03.04-A.png
ASKER
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?
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?
ASKER
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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
https://www.experts-exchange.com/articles/33078/How-to-create-an-Intelligent-Password-Policy-for-Active-Directory.html?headerLink=workspace_article
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
https://www.experts-exchange.com/articles/33078/How-to-create-an-Intelligent-Password-Policy-for-Active-Directory.html?headerLink=workspace_article
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
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
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
https://blogs.technet.microsoft.com/canitpro/2013/05/29/step-by-step-enabling-and-using-fine-grained-password-policies-in-ad/