How to fully remove domain password policy from on-prem AD

[Claire_4]

Hi,

We have recently changed our AD password mastering to a 3rd part IDP, the passwords are changed on their system and are pushed to the users profile in AD, all of this is working fine.

Users log on to their domain joined laptops with their AD accounts, users and computers are all on the same domain.

We have removed the password policy from our default domain policy, the change has replicated across GPO’s on other DC’s and there is no password policy being applied via any other GPO’s.

However, when running the query Get-ADDefaultDomainPasswordPolicy it still shows the password policy criteria that were removed from the domain policy.

The local security policy and local group policy on the domain controllers shows the same password criteria so I assume that’s where it’s coming from.

The local security policy and local group policy on the laptops is just showing what looks like some default settings.

Is there another step that needs to be done in order to fully remove the password criteria, i.e do we need to manually adjust the local settings on the domain controllers back to default/something else?

If anyone has any input it would be appreciated.

Thanks

[#2]

Hi @Claire_4,

To fully remove the domain password policy from on-prem Active Directory, you need to follow these steps:

1. Open the Group Policy Management console on one of your domain controllers.
2. Expand the forest and domain, then navigate to the "Default Domain Policy" or the GPO that previously contained the password policy settings.
3. Right-click on the policy and select "Edit" to open the Group Policy Management Editor.
4. In the Group Policy Management Editor, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy.
   
   
5. Review the password policy settings and ensure they are set to "Not Defined" or the desired default values.
6. Wait for the changes to replicate across your domain controllers.
   
   

You can also view the default password policy with Powershell using this command. 

Get-ADDefaultDomainPasswordPolicy


Please click Mark as Best Response & Like if my post helped you to solve your issue. This will help others to find the correct solution easily. It also closes the item. If the post was useful in other ways, please consider giving it Like.

Kindest regards

Leon Pavesic

[#3]

@LeonPavesic Thank you for the reply. Yes that's exactly what we've done, all settings under Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy - are set to not defined. Replication across domain controllers is working. I've attached a screenshot showing the group policy at the top with the correct settings, and the local security and group policy for that particular DC showing the incorrect settings. We have ran a GPUpdate on the DC's and rebooted both of them but the settings still remain.

[#4]

Hi @Claire_,

thanks for the update. You did everything right.

To ensure that the password policy is applied to the Active Directory domain controllers, you need to apply the policy directly to the OU where the domain controllers are located. Modifying the Default Domain Policy, which is linked at the root of the domain, may not have the desired effect if inheritance is blocked on the Domain Controllers OU. Make sure to target the policy specifically to the Domain Controllers OU to control the password policy for the Active Directory.

Please, check out this links:

Password policy changes aren't applied - Windows Server | Microsoft Learn

Changes are not applied when you change the password policy - Microsoft Support

Please click Mark as Best Response & Like if my post helped you to solve your issue. This will help others to find the correct solution easily. It also closes the item. If the post was useful in other ways, please consider giving it Like.

Kindest regards

Leon Pavesic

[#5]

@LeonPavesic Inheritance on the DC's OU is not blocked, and the domain controllers are in the correct OU, and the password policy is not coming from any other GPO.