First things first. The password policy is only relevant for authorities that change passwords. In an AD domain, this is the DC that owns the PDC emulator FSMO role. As a consequence, in a default environment there are only two spots where you can apply a password policy in theory:
- The domain (root)
- The OU "Domain Controllers" (directly below the domain root)
So if you apply a password policy on an OU that does not contain the PDC emulator somewhere, it can and will not have any effect. You will see the settings on a client though when viewing with
secpol.msc, but they are meaningless. Only the settings that apply to the PDC emulator will count.
Now, there is something special about password policies. They are designed to apply to the whole domain. MS therefore does not support password policies that are applied to the "Domain Controllers" OU. So your only playground left is the domain. There you can indeed have a custom GPO that contains password policies. To win against the Default Domain Policy or other GPOs that contain password policies, you have two possibilities:
- Enforce your custom GPO (assuming it will be the first enforced GPO on domain level)
- Move your custom GPO above all other GPOs (containing password policies and assuming they are not enforced) concerning the link order. That means give it a smaller number. The GPOs are applied in reverse order, so the GPO with link order number 1 will be applied last and thus will win.