At my company we recently decided to change our password policy by increasing the password age to a year but doubling the length. So we planned to change the password age via Group Policy so that everyone would have to change their password by the 2nd week of January. Once everyone had changed their password we would push the age to 365 days. But try as we might the policies in our Default Domain Policy just wouldn’t take.
In trouble shooting we decided to use the Group Policy Results in the Group Policy Management Console. Oddly enough it showed that the changes were applied to the computers we tested against. At this point we thought maybe something was blocking Group Policy updates. So we used SPECOPS: GPOUPDATE utility to do a batch run of the gpoupdate /force command on the Active Directory OU that house our client PC’s. So we used the following power shell command from the Quest ActiveRoles Management Shell for Active Directory to find out the password expiration date of a few users who were properly getting our GPO’s:
Get-XADUserPasswordExpirationDate USERNAME
What we noticed was that their expiration date was still reflecting the old policy. So we decided to see if we could use PowerShell to edit the Default Domain Password Policy, and you can! So we ran the following command to get what PowerShell was reporting as the Default Domain Password Policy
Get-ADDefaultDomainPasswordPolicy
The output confirmed that though we modified the Default Domain Password Policy that the Group Policy was still retaining the old settings. At this point I was baffled, that is until I took a hard look at the Group Policy Management Console and noticed something blaringly obvious. The Default Domain Policy was not at the root of the domain but at the root of the OU we created for our office location. Once I moved the Default Domain Policy to the root of the domain and re-ran the command I saw the new settings take effect. Which is similar to how a PC will keep the last applied GPO settings when disjoined from a domain, the root of our domain retained the last applied GPO settings applied at the root level after the Default Domain Policy was removed.
This is also when I ran into another head slapping obvious moment. After the policy was moved to the proper location and was reapplied to the OU that our client computers were located in, the updated password policy still wasn’t being applied to all our users. This is because all users authenticate to a domain controller and that is where the policy takes effect, not at the client PC. Once applied we were able to check the password age of a few user accounts and see that the new settings did take effect
So the take away
- The Default Domain Policy must always be at the root of the domain
- If possible avoid using the Default Domain Policy all together and use separate polices to push down settings.
- Since domain users authenticate against domain controllers, password policy settings must be applied to the domain controller and not the client PC’s
