First published on TechNet on Jan 14, 2013
Hi All! DougG here to share some insight on password policies – enjoy.
We were all excited when Windows 2008 Domain Functional level introduced FGPP (Fine Grained Password Policies). After several years in the field I have not seen abuse of this feature. In-fact, I am pleased to share that those using the FGPP are taking the conservative approach. By that, I mean I am not finding 20 or 30 FGPPs in domains. Rather, only 1 to 3 FGPP have been typically sufficient for most customers using FGPP. This means you are still using the Default Domain Policy to manage passwords for users that do not have a FGPP applied to them.
It is the Domain Password Policy that is the more complex of the two and the reason for this post.
WARNING!
First and for most, if you try to demo this or follow along on a domain make sure you are in a lab environment. What I am about to show you will impact the users and if you are in a production environment this will cause an RPE or CLM (Resume’ Producing Event or Career Limiting Move) – take your pick.
If you know these three facts you will be able to understand why things work the way they do.
1. Only policies applied at the DOMAIN level will apply a password policy to domain users. This can be the Default Domain Policy DDP or a policy that you have added that has a higher precedence (lower number than the DDP). Or it can be a combination of policies at the domain level.
2. Any policies applied to OUs, INCLUDING the domain controller OU, which has password policies will not be applied.
3. The password policy is written at the domain head by the PDCe (remember the stance that we don’t support sub OUs for domain controllers?)
Where do we get tripped up? RSOP for one. RSOP results will show you the policy including any OU that has a password policy setting. But only policies at the Domain level apply to the domain users. So when you look at an RSOP result you scratch your head, because what the user is experiencing is not what is on the RSOP report.
For example: If you wanted users in a specific OU to have shorter password length requirement and applied a password policy on their OU you will see your new settings in an RSOP report for those users. However, the real answer can be seen with
Net Accounts /Domain
Create a simple lab:
I have a 2008 R2 single domain forest with two domain controllers. Good to have two so you can prove one of the points about the PDCe.
I have one Windows 7 client – I have placed this machine account in the W7User OU to facilitate demonstration. It is not recommended to combine users and machines in the same OU.
I have User 1 in the same OU, W7Users, with a policy defining password policy settings.
Problem number 1:
Trying to apply a password policy at an OU.
Hopefully you know this won’t work, but going to show it anyway.
Logged in as user1 on my LAB domain, NWT.COM, using net accounts /domain you see I am getting the policy with the default settings that come from the domain:
However, my administrator tried to give me a much easier password policy. He created a policy on my W7Users OU where both my user account and machine account reside with the new settings. You can see from the RSOP result on my Win7-32 client that User 1 has logged on at least once.
Look closely and it appears that I am getting some settings from the Default Domain Policy and some from MyPasswordPolicy. Using net accounts /domain you can see what the password policy is for the user:
No matter how many time you reboot or run GPupdate /force, the OU policy will not affect the domain user account.
Where this setting does take affect is on the local machine for local users. To see that, drop the “/domain” from the net accounts and you will see the settings applied to the local machine.
Net accounts
You can tell which “net accounts” you ran by the last line. If it says “Primary” or “Backup” then you are getting that from the domain via the PDCe or another domain controller and the command was run with the /domain switch. If it says “Workstation” it is the local workstation policy and the command was ran without the /domain switch.
Just to continue to prove a point, we can just leave this garbage policy on the OU. It isn’t doing anything other than making the client read a policy that doesn’t do anything to him – but it is consuming time reading the policy and retrieving information from SYSVOL.
Problem Number 2
Blocking inheritance on OUs with the domain controller OU or on sub OUs within the domain controller OU.
Many environments have sub OUs under the domain controller OU to facilitate applying updates via WSUS or other tool. To help with that, some have created an OU structure so the patches are rolled in stages. So I created a North and South OU for my environment. I have also blocked inheritance on the North OU (this is where my PDCe is now) because the Security Team is patching the DCs tonight and I don’t want the North DCs to get the patch until next week.
The PDCe is the path to get the policy applied to the domain. So you can probably guess what is going to happen or rather not happen. Not to mention the fact that the Default Domain Controller Policy is also blocked now. What a mess. You are in your lab, right?
The next day the Security team requests to change the password policy to require 10 character passwords. No problem, you get the change request and open the default domain policy and modify it as requested:
Ticket closed.
A couple of hours later the Security Team calls you and informs you that users are still able to have 7 character passwords. You look at the policy settings and send the screenshot above showing the setting and tell the security team to be patient it is probably just a replication timing thing, you know how that goes.
You return to work tomorrow with an email from the Security Team reporting the password policy still is not in affect and has an output from user 1’s “net accounts /domain” command (smart guys).
It is then you remembered that you had temporarily blocked inheritance on the North OU where your PDCe is located. Patching went well the other night, so you get a change request to allow the North DCs to be patched as well and unblock inheritance. Once that was complete you ran “GPupdate /force” on the PDCe. It would have applied in 5 minutes anyway, but we were in a hurry.
You call security and let them know the issue is resolved and they reply with a thank you and a screen shot of the net accounts /domain. Clients will have to restart, run gpupdate /force, or wait for background refresh to update the policy.
Problem Number 3
You have a work around for last month’s password problem when you had blocked inheritance on OUs with the domain controller OU or on sub OUs with the domain controller OU.
You again blocked inheritance on the North OU, but to work around the issue you also linked the DDP to the North OU as well, just in-case there is a change request.
Cool! We’re covered. Of course the 10 character password we set last month is causing some problems so the Security Team requested a change to return the password back to 7 characters. No problem you get the ticket to change the setting back to 7 characters and since DDP is linked to the domain and the North OU, the PDCe will pick it up. Right? Well let’s see.
Since you learned from last month you run “net accounts /domain” on the PDCe and get the following results:
It didn’t work.
Again you have to unblock inheritance on the North OU to allow the PDCe to read the domain level policy to apply the password policy to the domain.
This has been a rough couple of months any you have decided to change your patching process and go the supported configuration and move all DCs back to the domain controller OU and delete all the sub OU with in the domain controller OU.
Problem Number 4
Multiple policies at the domain level with password policy settings.
The password policy applied to the domain does not have to be in the default domain policy. However, it is best practice to keep it there.
On the off-chance that someone has added policies at the domain level with password settings, they may not apply. By default a new policy added will be lower on the priority list and will be overridden by the default domain policy if there is a conflict in a setting. You would have to consciously change the precedence of the new policy to supersede the DDP.
I have shown you everything so far, so let’s do it one more time.
New policy on the domain head with password settings. I set a couple of items so we can see what happens. Changes include:
Maximum password age: 90 Days
Minimum password length: 10
I think you have got the trend down from this blog post, so let’s jump straight to net accounts /domain. Note that the new password age and length requirements did not apply.
Surprised? Nothing from our new policy came through. If you use GPMC and click on the domain name (nwt.com in my case) you can see the order of precedence:
But you probably also noticed there are arrows to change the precedence, so let’s do that. Depending on which one is highlighted, hit the up or down arrow to move “New Password Setting” to the top (or at least a lower number than the DDP).
Gpupdate /force
Net accounts /domain again. And now you can see the changes take affect with a (0 day password with a 10 character length requirement.
What is interesting here, is the password policy is FINALLY acting like other GPOs. If there is a conflict in settings, the higher precedence wins. If the setting is only defined in one of the policies, it will be applied regardless of precedence.
Some notes to bring FGPP back into the discussion
1. FGPP take precedence if assigned to a security principle (groups or users typically)
a. You cannot assign FGPP to OUs.
2. If no FGPP is applied to the user logging in, they follow the password policy applied to the domain.
What should you get out of this post? Hopefully a better understanding of Domain Password Policies. To wrap this post up I have copied the three things you need to know to understand how passwords are applied:
If you know these three facts you will be able to understand why things work the way they do.
1. Only policies applied at the DOMAIN level will apply a password policy to domain users. This can be the Default Domain Policy DDP or a policy that you have added that has a higher precedence (lower number than the DDP). Or it can be a combination of policies at the domain level.
2. Any policies applied to OUs, INCLUDING the domain controller OU, which has password policies will not be applied.
3. The password policy is written at the domain head by the PDCe (remember the stance that we don’t support sub OUs for domain controllers?)
Now wasn't that fun?