Link to home
Start Free TrialLog in
Avatar of enviros_it
enviros_it

asked on

Group policy settings for 'password policy' not working on domain

I am trying to test a change to our domain password policy so that all users have to use a complex password, but when I apply the new settings in a test GPO and apply it to a test user the local policy is changed on the computer but it is not applied when logged into the domain. I have added the policy into the root of the domain and changed the link order so that it is the first but when I log into the domain as the test user and change it's password I am able to use a non complex password e.g. password.

Can anyone help as to why the domain policy is not working?

Thanks
Avatar of InteraX
InteraX
Flag of United Kingdom of Great Britain and Northern Ireland image

Hello enviros_it,

From what I was told on the MS course 2 weeks ago, you have to make this change on the default domain policy. This will override any other password policy.

With Server 2008, this changes though.

Regards,

InteraX
You could run RSOP to find out where this policy is being over-ridden. Where are you applying the policy?
To learn more about using RSOP for troubleshooting group policy problems see this:
http://technet2.microsoft.com/windowsserver/en/library/64c6f0f4-6099-4da2-9411-354dec73ca401033.mspx?mfr=true
Avatar of enviros_it
enviros_it

ASKER

We are trying to test the changes to our password policy before changing it for all users, I was under the impression that if the GPO was above the default domain policy then this will take precedence. I would like to test the policy first with a test user just to make sure it is working correctly before adding it into the default domain policy.

Is there no other way of testing this in Group Policy??

Thanks
InteraX is right.  One password policy per domain.  
enviros_it,

Taken from http://technet2.microsoft.com/windowsserver/en/technologies/featured/gp/faq.mspx

"Domain password policies may be enabled and linked at the domain only. This limitation is because of the design of where these values are stored in Active Directory. Password policy settings, such as Minimum Password age, Maximum Password age, and Minimum Password length are stored as attributes on the domain object in Active Directory. The current design does not allow these values to read from any other object. Password policy settings linked at other containers will not affect domain users, but will apply to local users of the computer.
"

InteraX
We found this in a TechNet guide (see extract below) and at first I read it as meaning you could create another GPO with password settings in it as long as it was above the Default Domain Policy in the link order. The last section states you should create a new GPO with your settings and make it higher priority than the default GPO. If this is the correct way of doing it can you only set the GPO to affect all users instead of a select group e.g. a group for testing the GPO?

Thanks

Storing Password Policy Information
Before implementing password policies, you need to understand how password policy configuration information is stored. This is because the mechanisms for storing password policy limit the number of different password policies you can implement and affect how you apply your password policy settings.

There can be only a single password policy for each account database. An Active Directory domain is considered a single account database, as is the local account database on stand-alone computers. Computers that are members of a domain also have a local account database, but most organizations that have deployed Active Directory domains require their users to log on to their computers and the network by using domain-based accounts. Consequently, if you specify a minimum password length of 14 characters for a domain, all users in the domain must use passwords of 14 or more characters when they create new passwords. To establish different requirements for a specific set of users, you must create a new domain for their accounts.

Active Directory domains use GPOs to store a wide variety of configuration information, including password policy settings. Although Active Directory is a hierarchical directory service that supports multiple levels of organizational units (OUs) and multiple GPOs, password policy settings for the domain must be defined in the root container for the domain. When the first domain controller is created for a new Active Directory domain, two GPOs are automatically created: the Default Domain Policy GPO and the Default Domain Controller Policy GPO. Default Domain Policy is linked to the root container. It contains a few critical domain-wide settings including the default password policy settings. Default Domain Controller Policy is linked to the Domain Controllers OU and contains initial security settings for domain controllers.

It is a best practice to avoid modifying these built-in GPOs. If you need to apply password policy settings that diverge from the default settings, you should create a new GPO instead and link it to the root container for the domain, or to the Domain Controllers OU and assign it a higher priority than the built-in GPO. If two GPOs that have conflicting settings are linked to the same container, the one with higher priority takes precedence.

This will set the password policy on the computers not the domain accounts.  This is exactly what you are getting as per your first post.  If affects the local policy on the computers.  not the domain policy.

There can only be one password policy/domain in a 2003 environment.  In 2008 that changes.

This is a very popular question on Experts Exchange.  Unfortunately you can't do it.
https://www.experts-exchange.com/questions/22594589/how-to-craete-exceptions-for-the-password-policy-in-windows-2003-server-domain.html
https://www.experts-exchange.com/questions/22944545/Password-policy-on-AD-OU.html
https://www.experts-exchange.com/questions/22689938/password-policy.html
https://www.experts-exchange.com/questions/21987271/Password-Policies.html
Well I have taken out the test GPO and have amended the Default GPO to include our new password policy settings but the machine and user account I am testing it on still lets me change the password to someting non complex even though I have run gpupdate /force on the machine and have restarted it and logged back into the domain.

Any ideas why the changes aren't taking affect??

Thanks
You may need to wait for replication on your DC's before the policy will be available to the desktops.  Try doing a GPupdate /force on your DC's as this is where the policy actually comes into play because it is the domain accounts.

Also run RSOP.MSC on your desktop.  It will load up the policy and you can navigate to the password policy and it will tell you what policy is setting it.

gpresult from the command line on the client is also good for troubleshooting.
Pber,

To force replication, you will need to force replication of the AD information to the authenticating server and for the replication of the SYSVOL share using FRS. As the SYSVOL replication is managed seperately to directory replication you can use frsutil to force this.

InteraX
InteraX

You are 100% right.  There are two replication engines to deal with with respect to GPO's.

Pat.
I was unable to find how to use the frs utility so left the changes to replicate automatically overnight but on testing the policy today using two different domain user login accounts the group policy is still allowing non complex passwords to be set. I have checked the Default Domain Policy and the password settings are still there with the Complex Passwords option being enabled in Computer Configuration.

Can anyone suggest how to resolve this issue??

Thanks
It would seem the DC's aren't getting the policy.  Do you have any policy blocking on the Domain Controllers OU.
I would run a RSOP or Gpresult on the DC's and see what policies are getting applied.
enviros_it,

I would also check the USN numbers on replmon to check that directory replication is working OK and run the following command to force the FRS replication. You can also use sonar to check FRS replication. This si a downloadable tool.

ntfrsutl forcerepl ComputerName /r "Domain system volume (SYSVOL share)" /p Source domain controller.domain.com

See http://support.microsoft.com/kb/896669 for info on why this can take a long time.

InteraX
enviros_it,

Which server was GPMC connected to when you made the change? The infrastructure master or another DC?

InteraX
I have just checked my GPMC and it is connected to another DC and not the infrastructure master, will this make any difference??

Thanks
I have checked the settings when connected to the infrastructure master and the password policy settings are correct for what I need to push out to all users, is this a replication problem??

Thanks
Running gpresult on the infrastructure master shows that in the computer settings section the default domain controllers policy is running, and a policy we setup for pushing out windows firewall settings and the local group policy. I have checked the default domain controllers policy and it is link enabled and does not have any settings defined in the password policy section.

Thanks
Using replmon on the infrastructure master it shows a large number of 'deleted server' entries under DC, and both CN sections can the 'deleted server' entries be removed from the lists??

Thanks
ASKER CERTIFIED SOLUTION
Avatar of InteraX
InteraX
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks for your time on this.