I recently encountered a situation in which a client had a fully-featured password  Group Policy Object (GPO) being pushed – but I discovered that the policy was not being applied.

The policy was linked and enabled, and was properly scaled to apply to user workstations and computers. Yet, users were not being required to adhere to complexity requirements nor change their passwords on a 90-day schedule as per the policy. What gives?

First, some background. The typical enterprise password policy in an Active Directory domain environment consists of the following elements:

• Complexity requirements – combo of uppercase / lowercase letters, numbers, and/or symbols.
• Character length – nowadays, shouldn’t be less than 10; the more, the better.
• No reusing any of the past 3 passwords.
• 90-day expiration, give or take.

(…And yes, password expiration schedules are on the outs per NIST and Microsoft guidance – but a lot of regulatory structures still require it. Until that changes, password expiration will remain a common part of enterprise password policies.)

The above is basically what was being applied at the client site – but users were not being held to the policy. In fact, there were basically NO password standards being enforced.

I began by going over the GPO with a fine-toothed comb, seeing the following:

• Policy settings were all enabled.
• Policy linked to the right OU (just top-level domain) and enabled.
• Applied to the right user groups (Authenticated Users).
• User accounts were not set to “Password Never Expires”.
• The GPO was enforced.
• The GPO was propagating correctly – using Group Policy Results wizard showed the policy being pushed and (technically) applied.

….And yet, nothing. Interestingly, a lot of Google-Fu yielded no help either. I couldn’t find any posts or articles from anyone explaining similar issues.

After a lot of detective action and some guesswork between a team member and I, we figured it out: The Local Password Policy settings on the Domain Controllers were interfering with the GPO! I had never seen anything like it, so a fascinating learning experience.

Here’s the long and short of what happened: At some point, a past IT admin had modified the Local GPO on the domain controllers to define password policy settings with very low to nonexistent standards – disabled complexity req’s, no expiration schedule, etc. This was in direct contradiction to the Domain GPO, which defined these settings much more strictly.

As to why exactly it works out that Local GPO on the Domain Controller overrides the Domain GPO, I’m still not certain – here’s my suspicion: Because the DC is what handles AD user account processing, it was looking at it’s own local password policy when handling logon/logoff rather than the domain policy. Normally, this isn’t necessarily a problem – as the local policy will be modified by the domain GPO to reflect the same settings. But because someone, for reasons unknown, modified the local policy – the domain GPO was not being enforced.

If you find yourself in a similar situation – a domain GPO is not being applied in practice even though everything looks to be in place in theory – then check the local GPO settings on the affected machines. If there’s a conflict between local policy and domain policy, that’s a good place to start.

Do you have a better technical explanation for why this occurs? Share it with us in the comments below! Inquiring minds want to know.

Categories: Tips