[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2171
  • Last Modified:

Default Domain Policy password settings not working correctly

In my server 2008 r2 domain I have a password policy set at the domain level saying that passwords expire every 180 days.  41 days ago I forced a reset of all users passwords and now everyone is getting a message saying that their password expires tomorrow.  When I check the gpo it still says 180 days.  When I look at the properties of the domain under AD Users and Computers it says password expires every 42 days but I thought that only applied to the default domain administrator account. I did try changing that but it resets itself back to 42 days when I refresh. Any help would be greatly appreciated!!
0
anotherjallen
Asked:
anotherjallen
  • 8
  • 3
  • 2
  • +1
8 Solutions
 
Mike KlineCommented:
is the 42 days set on the default domain policy?  did you run an rsop report

 thanks

mike
0
 
anotherjallenAuthor Commented:
I did run an rsop and the setting matches the default domain policy, which is where it is set to 180 days.
0
 
anotherjallenAuthor Commented:
another note, when I run "net accounts" it tells me that maximum password age is 42.....
0
Veeam Disaster Recovery in Microsoft Azure

Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.

 
Sarang TinguriaSr EngineerCommented:
42 is the default value for this policy settings ...You might be missing something here
0
 
anotherjallenAuthor Commented:
I think I am.  I have the default domain policy, in it I have specified that passwords expire after 180 days and specifies a max password length and complexity.  This was added to the DDP a week before forcing the users to reset their passwords.  I do not have any other gpos linked at the domain level and I am not using Fine Grained Password Policies.  When I set this up I was under the impression that when a user resets their password it will then check the password settings on a gpo only at the domain level and this then applies to their account.  When I do a reset of a user now then check their account using net user /domain username before the reset it would say it expired tomorrow, 42 days from the reset.  After the reset it will say it was reset today but then lists the expiration as 180 days from today.  So the settings are working now, but nothing has changed in group policy since the week before the reset, so that is where my greatest confusion comes from.
0
 
Mike KlineCommented:
That is odd, go through this askpfe blog from last week

http://blogs.technet.com/b/askpfeplat/archive/2013/01/14/fun-and-games-active-directory-password-policies.aspx

any of those issues occurring?

Thanks

Mike
0
 
McKnifeCommented:
You should start with the basics: where should the policy apply and does it apply there. As simple as that. We have no idea if your DDP does apply at the DCs (normally it should but you might have blocked it or set override/enforce in another policy). Because, if we talk about domain accounts, only the DCs matter, the rest does not need to apply the pw policy.
0
 
anotherjallenAuthor Commented:
The policy is applied to the entire OU structure, we do not have any blocking inheritance.  I have run RSOP reports on both the DCs and the workstations and they all say that the DDP is being applied.

As near as I can tell there is nothing wrong with the GPO or with it being applied.  Is their anywhere else at all that could be causing the accounts to see 42 days?

I also checked to make sure that we do not have fine grained password policies in use.  We do not.

I also tried running Get-ADDefaultDomainPasswordPolicy from PS and it lists the expiration time as 42 days.  When I run Set-ADDefaultDomainPasswordPolicy it changes it to 180 days, but after about a minute it changes it back to 42... Could this be a replication problem between my DCs?  I have 5 total and 2 are RODCs.
0
 
McKnifeCommented:
Please run rsop.msc at the DC and see what it says about how many days.
0
 
anotherjallenAuthor Commented:
I think I have an idea on what was causing this.  We have 5 DCs, two are RODCs.  The one that hosts the PDC emulator was the one that all of the GP changes were being made to.  When I changed to check the GPO by specifying a different DC the Default Domain Policy had different settings.  So apparently our GPOs are not replicating between all of our DCs, and that is probably what caused the issue.  I do know that replication works for AD, DNS and DHCP so not sure why just those are not working but I am going to run a few tests and check replication logs to see.

Does this sound like anything you have run into before?
0
 
Sarang TinguriaSr EngineerCommented:
Good caught...This could be issue

Check for event ID's 13508(error),13509(issue resolved after repeated entries),13568 (FRS is in Journal Wrap)in FRS logs
If you find any post here
0
 
anotherjallenAuthor Commented:
I did a check for those event errors and I found a few, all from over 6 months ago, nothing more recent than that.
0
 
McKnifeCommented:
anotherjallen, failing replication could be the cause, yes.
Please check on a client, what logonserver he is connected to.
echo %logonserver%
is a command for checking.
Then log on to %logonserver% and run rsop.msc at that DC and report back whether that DC has applied the correct values or not.

That way you can definitely at least rule out that the problem is at the client side.
0
 
anotherjallenAuthor Commented:
Okay, so I spent all morning on the phone with MS tech support, they even remoted in and took a look at my DCs.  After looking around and doing a bunch of tests they told me there weren't any problems with replication.  I have spent this afternoon testing and that seems to be the case.

On that note, I did watch them quite carefully as they were in there, and there were two things they did.  One was to remove the replication connections under NTDS settings AD Sites and Services and let them regenerate themselves.  Two was they stopped and started the File replication service on each DC.  I have no idea if one of those was the cause but it is no longer happening, and they told me they didn't know why it happened in the first place.
1
 
anotherjallenAuthor Commented:
Thank you all for your help!
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

  • 8
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now