Max password age not taking effect

Check this out...

http://www.windowsnetworking.com/articles-tutorials/windows-server-2008/Top-10-Reasons-Why-Group-Policy-Fails-to-Apply-Part1.html

Thanks carolinasgirl128; that's an interesting article.

I've checked all those things and my policy looks fine.

Any other ideas please?

Well there are a couple things to keep in mind with password expiration.  1st its not really across the board so everyone in your environment after 90 days will have to reset their password.  Also if password does not expire checkbox is ticked this overrides GPO.

Ok with the password policy lets say I changed my password 30 days ago and you implemented the policy as of right now.  This does not mean after 90 days I will be forced to change my password.  The policy looks at when I changed my password and notices I changed my password 30 days ago (even though this was before implementing GPO) so my password will expire in 60 days.

This same rule applies to people that have never changed their password.  So lets say another user hasn't changed their password in 120 days.  You implement the 90 day policy on them and their password will instantly expire forcing them to change their password.  

Follow me?

Thanks for your reply NRhode. I understand how the policy works, thank you.

I don't think that is the issue. I personally changed my password today, and the policy has been in place for a few months. Yet I ran this command and it showed that my password will expire in 42 days:

net user %USERNAME% /domain

Password last set            30/10/2013 14:00:07
Password expires             11/12/2013 14:00:07

If I run "net accounts":

Maximum password age (days):                          90

Contradicting information!

You should use Group Policy modeling to verify that you have the policies setup correctly and applied to the correct groups. Modeling allows you to verify the settings that a user and computer SHOULD be getting.

You can run it from the Group Policy Management Console and it allows you to select a computer and a user to test with, those are the only two important selections when you are going through the wizard.

You can then run the Group Policy results wizard to see what settings the user ACTUALLY got the last time they logged into a computer.

If you run the modeling and it shows that they should be getting it and you run the results and it shows they got it, which you probably won't see, then it is something else.

My guess would be that it isn't setup correctly or you will find errors in the event logs of the machines that the policies are applying too.

Let me know after you run those two tools.

Hi McKnife

Now you have an existing account... will it take note of the policy change? Of course not. It will not have to follow the new rules until its password is changed! People tend to forget that."

I understand that, and I don't expect those who have not changed their password to receive the new policy. However the policy has been set to 90 days for a few weeks now. We have had plenty of users change their password in that time period, yet none of them are receiving the 90 day policy. It's always 42 days.

Hi xKincaidx

Aha! Getting somewhere now...when I run the modelling, the Max password age setting is not there! The default domain policy is being applied according to the summary tab, however some of the settings within it are totally missing from the settings tab! Some of the policy settings are listed though, just not all of them!?

What could be the cause of this?

The policy is not setup correctly or if you have multiple policies the permissions are not correct.

If the policy is failing to apply all the settings the settings may conflict with another policy below it in the tree or you may just need to delete it and create a new one.

Let's first set things straight: where did you run the gpo modeling? Why did you run modeling at all? That does not matter...modeling is for planning (it shows how it should be, not how it actually is), not for diagnosis as we need it here. So use GPresult instead and not at the clients but at all Domain Controllers.

The policy is not setup correctly or if you have multiple policies the permissions are not correct.

If the policy is failing to apply all the settings the settings may conflict with another policy below it in the tree or you may just need to delete it and create a new one.

I have checked the permissions which look fine, and gone through every single GPO to see if there is a conflicting setting, which there isn't. Max password age is not set in any other GPO other than the Default Domain Policy.

I'm not deleting the Default Domain Policy! However I could remove the setting from it, and create a separate GPO for the setting, and see if that applies?

Let's first set things straight: where did you run the gpo modeling? Why did you run modeling at all? That does not matter...modeling is for planning (it shows how it should be, not how it actually is), not for diagnosis as we need it here. So use GPresult instead and not at the clients but at all Domain Controllers.

I ran the modelling from the GP management console on my laptop (connected to a DC). I ran it because xKincaidx recommended that I should.

I ran gpresult on all four of my DCs - they all show that the Default Domain Policy, where the password settings are set, is being applied successfully.

It is not enough to know that the policy applied. It is important to see if the settings are in effect. User gpresult /h outputfile.html and see in the outputfile whether the desired settings are active at all the DCs.

Why? Because there could be other policies that override your password policy, some that you might "not have on your list" at all.

That's a really useful command, thanks!

I ran it on all four DCs and the Max Password Age setting is missing from all of them. The report confirms the Default Domain Policy is being applied though.

See - there's the problem.
Now open rsop.msc at the DC, rightclick the item "computer configuration" in rsop and select "properties". There you find a tab "error information" - anything useful inside?

No errors unfortunately. It reports that Group Policy Infrastructure, Registry, Group Policy Files and Security are all completed successfully.

Do the following for a test: define a new policy and link it to the DCs OU. Set it to "no override" and configure just the pw policy settings. Do a GPupdate at a DC and redo the steps with gpresult.

I created the new policy with only Max Password Age set, linked it to the DCs OU and set it to Enforced (I presume that's the same as "no override"?).

Did the gpupdate, confirmed the new policy was applied, and ran the output.html.

The Max Password Age setting is still not listed! The output.html confirms the new policy is applied and enforced though.

Well... what could that be.
Please do another test, take the same test policy and configure some other non-critical setting like the screensaver and see if it applies.

OK it seems that anything I change in Computer, Policies, Windows Settings, Security Settings, Account Policies does not take effect and is not listed in the gpresult /h output.html

If I change something in Computer, Policies, Windows Settings, Security Settings, Local Policies however, this DOES take effect e.g. I added an Audit Policy and it took effect instantly.

Fixed!!

I found this article:

http://www.ultimatewindowssecurity.com/wiki/WindowsSecuritySettings/Account-Policies-Explained

It explains that Account Policies only get applied if they are set at the domain level.

If you create a GPO with Account Policies and link that to an OU, it won't take effect.

Originally I disabled inheritance on my DC OU because I didn't want it to inherit settings from other domain level GPOs. I then created a link to the Default Domain Policy on the DC OU.

I have just changed that design.

I have now re-enabled inheritance, removed the link to the Default Domain Policy, so it now inherits it from the domain level instead, and the Account Policies are now taking effect! Hooray!

I have had to configure the security on the domain level GPOs that I don't want to take effect on DCs though. I have denied read permissions to the Domain Controllers group in those GPOs.

I told you the whole time that it has to be applied to the DC.
The info you found is partly correct if it says "that Account Policies only get applied if they are set at the domain level" - because it does not necessarily need to be a policy that gets applied to the domain head but CAN be.

So if the policies were applied to the DCs before, they would have to work - not in theory, but in practice. There will be something else that caused this effect.
--

Now for the important part:
>  I don't want to take effect on DCs though.
You still don't understand it... :) It HAS to take effect at the DCs! The domain passwords are not stored at the clients, but at the DCs.

I told you the whole time that it has to be applied to the DC.

The policy WAS applied to the DCs the whole time...it just wasn't being inherited from the domain level, it was OU linked instead. That was causing the problem.

 

Now for the important part:
>  I don't want to take effect on DCs though.
You still don't understand it... :) It HAS to take effect at the DCs! The domain passwords are not stored at the clients, but at the DCs.

I do understand, and never said I didn't want the Default Domain Policy to take effect on the DCs...it's OTHER GPOs that I don't want to take effect on the DCs, e.g. domain level GPOs that contain settings that are only meant for client PCs for example.

Ok...
let's see: I am trying to tell you that your opinion "it just wasn't being inherited from the domain level, it was OU linked instead. That was causing the problem" is wrong. Because I had it configured OU-linked and it worked - that's why I wrote "...not only in theory, but in practice".

Then you write "I have had to configure the security on the domain level GPOs that I don't want to take effect on DCs though" - what should that mean, what "security"? You mean these password policy settings we are talking about?

I am aware that you solved it and are happy, but I am trying to avoid that you run into future problems :)

So you are saying that you tested this exact same scenario? You disabled inheritance on the DC OU, then OU-linked the Default Domain Policy? Changed Account Policies and the changes were applied?

If so, then fair enough, my suspicion was incorrect.

The security permissions are on GPOs at the Doman Level that I don't want to be inherited by the domain controllers, therefore I set deny to the domain controllers security group on the delegation tab.

Thanks for your help and advise so far by the way - I've learnt a great deal!

I've requested that this question be closed as follows:

Accepted answer: 0 points for failed's comment #a39616734

for the following reason:

This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.

I object.

That article is wrong. It had another cause. The asker should decide what to do.

I think the solution was in this article: http://www.ultimatewindowssecurity.com/wiki/WindowsSecuritySettings/Account-Policies-Explained

However I want to award all the points to McKnife since he helped me get to the solution and did lots of troubleshooting with me.