[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now

x
?
Solved

Default Domain Policy password settings not working correctly

Posted on 2013-01-19
15
Medium Priority
?
2,095 Views
Last Modified: 2013-01-27
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
Comment
Question by:anotherjallen
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 8
  • 3
  • 2
  • +1
15 Comments
 
LVL 57

Assisted Solution

by:Mike Kline
Mike Kline earned 572 total points
ID: 38797109
is the 42 days set on the default domain policy?  did you run an rsop report

 thanks

mike
0
 
LVL 4

Author Comment

by:anotherjallen
ID: 38797115
I did run an rsop and the setting matches the default domain policy, which is where it is set to 180 days.
0
 
LVL 4

Author Comment

by:anotherjallen
ID: 38797162
another note, when I run "net accounts" it tells me that maximum password age is 42.....
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
LVL 18

Assisted Solution

by:Sarang Tinguria
Sarang Tinguria earned 572 total points
ID: 38797285
42 is the default value for this policy settings ...You might be missing something here
0
 
LVL 4

Author Comment

by:anotherjallen
ID: 38797295
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
 
LVL 57

Assisted Solution

by:Mike Kline
Mike Kline earned 572 total points
ID: 38797408
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
 
LVL 56

Assisted Solution

by:McKnife
McKnife earned 856 total points
ID: 38799345
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
 
LVL 4

Author Comment

by:anotherjallen
ID: 38801337
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
 
LVL 56

Assisted Solution

by:McKnife
McKnife earned 856 total points
ID: 38802378
Please run rsop.msc at the DC and see what it says about how many days.
0
 
LVL 4

Author Comment

by:anotherjallen
ID: 38802861
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
 
LVL 18

Assisted Solution

by:Sarang Tinguria
Sarang Tinguria earned 572 total points
ID: 38803021
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
 
LVL 4

Author Comment

by:anotherjallen
ID: 38803061
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
 
LVL 56

Assisted Solution

by:McKnife
McKnife earned 856 total points
ID: 38803344
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
 
LVL 4

Accepted Solution

by:
anotherjallen earned 0 total points
ID: 38807479
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.
0
 
LVL 4

Author Closing Comment

by:anotherjallen
ID: 38823834
Thank you all for your help!
0

Featured Post

NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This process allows computer passwords to be managed and secured without using LAPS. This is an improvement on an existing process, enhanced to store password encrypted, instead of clear-text files within SQL
Wouldn't it be nice if objects in Active Directory automatically moved into the correct Organizational Units? This is what AutoAD aims to do and as a plus, it automatically creates Sites, Subnets, and Organizational Units.
This tutorial will walk an individual through the steps necessary to install and configure the Windows Server Backup Utility. Directly connect an external storage device such as a USB drive, or CD\DVD burner: If the device is a USB drive, ensure i…
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…
Suggested Courses

656 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question