Solved

AD default domain policy issue

Posted on 2016-11-10
24
23 Views
Last Modified: 2016-11-11
I inherited a domain a while back that had what I later came to find out a fine grained password policy. We were looking at trying to find where the policy was coming from and ended up editing a setting in the default domain policy. We changed the password expiration to 180 days. Ran a check from powershell
get-addefaultdomainpasswordpolicy

Open in new window

and it read that 180 day setting correctly, I went and changed it back to undefined. I just ran that same powershell command above and the setting seems to have held even the the setting in the gpo is undefined.

Now we have passwords expiring that shouldn't. My question is why is that setting still being seen? I have checked every GPO on each DC and they all show that computer configuration/Windows Settings\Security Settings\Account Policies\Password Policy as undefined.

Why is this setting hanging around?
0
Comment
Question by:Chris Christensen
  • 12
  • 11
24 Comments
 
LVL 6

Expert Comment

by:gilnov
Comment Utility
Some GP settings aren't reversed when set back to "Not Configured."  "Not Configured" just means the object does not get set via group policy but it does not necessarily mean the setting goes back to what it was before the policy was applied. This is because there is no mechanism for AD to record the current settings when applying policy. Only settings that have a default will go back to what they were when the policy is removed or set to "Not Configured." Many settings have a default but many do not.
0
 
LVL 38

Expert Comment

by:Hypercat (Deb)
Comment Utility
Policy settings change registry entries on the affected machines.  The pace of the changes is based on the group policy update frequency setting (90 minutes by default) and some other factors, including what portions of the registry it affects.  If you want to confirm that the change to the policy will push out correctly, you need either to run a "gpupdate /force" command on one of the affected machines or, in some cases you need to restart the affected machines.  Furthermore, because this is a password policy and affects your DCs and active directory, I'm not in fact certain what the affect would be of changing it from "not configured" to a specific number of days and then immediately back again to "not configured."  Your DCs may require a restart in order to make the change back to "not configured" effective.

In terms of checking the current settings, take a look at this article:

https://blogs.manageengine.com/active-directory/2014/05/16/domain-password-policies-configuring-and-auditing-correctly.html
0
 

Author Comment

by:Chris Christensen
Comment Utility
Ok, so is there no way of setting this back?
0
 
LVL 6

Expert Comment

by:gilnov
Comment Utility
I'm not sure without a bit more research.
0
 

Author Comment

by:Chris Christensen
Comment Utility
So in the article linked, it would appear to be possible to create a blank GPO linked at the top level and give it a higher precedence than the default domain policy.

What is odd here is that we have accounts that are set to 'Never Expire' and some of them did, while some did not, guessing that check box does not exclude you from anything. I am also guessing that the setting was only alive for so long which meant that some accounts were hit while others were not.
0
 

Author Comment

by:Chris Christensen
Comment Utility
So here is the output from
get-addefaultdomainpasswordpolicy

Open in new window


2016-11-10-08_47_52-WS01-IT---Remote.png
Here is the output from secpol.msc from a workstation

2016-11-10-08_47_22-WS01-IT---Remote.png
The secpol.msc is showing setting that are inside of the default domain controller policy which has not been touched.
0
 

Author Comment

by:Chris Christensen
Comment Utility
Would setting the max password age to 0 possible reset this setting?
0
 
LVL 6

Expert Comment

by:gilnov
Comment Utility
0
 

Author Comment

by:Chris Christensen
Comment Utility
Ok, so I wonder if there is a way to get the max password age setting to go back to what it was, undefined. Maybe in ADSI edit?
0
 
LVL 6

Expert Comment

by:gilnov
Comment Utility
Maybe. You have no way of knowing what the setting was before but you can probably set it to what you want with ADSI or a PowerShell script (I'm not a PS scriptwriter though). Are you trying to set ALL accounts to never expire?

It sounds like your predecessor may have used something like GPP to implement fine-grained policy. Fine-grained policy involves client side extensions. Have a look at the GPP doco and see if it can shed any light. https://technet.microsoft.com/en-us/library/cc731892(v=ws.10).aspx

Also, I recommend against having overlapping default policies at the top of the domain. You're just asking for trouble. Remember that GP is applied LSDOU which stands for Local Site Domain Organizational Unit. Basically, local policy is trumped by site policies which are, in turn, superseded by domain polices and, finally, policies at the OU level (and sub-OU) level are applied. If there is a policy conflict, the last one applied will be effective.

Here are a couple of good GP articles that are worth a read:
http://www.windowsnetworking.com/articles-tutorials/windows-server-2008/Top-10-Reasons-Why-Group-Policy-Fails-to-Apply-Part1.html
https://deployhappiness.com/cse-processing-order-know-lsdou-learn-this-too/
0
 

Author Comment

by:Chris Christensen
Comment Utility
The max password age was not set prior to this, so running get-addefaultdomainpassword policy in powershell did return a result that had MaxPasswordAge in it.

You are correct, we are using fine grained password policies that are doled out based a group membership. Those are working, but there are accounts that are not members of those groups, and those account had passwords that were set to never expire. Unfortunately the change I made expired quite a few of those accounts. My goal is to just get it back to what it was, where the accounts that are not members of the groups that are targeted in the fine grained password polices have passwords that will not expire.
0
 

Author Comment

by:Chris Christensen
Comment Utility
Or would it be a better idea to create a new FGPP for the accounts that should never expire?
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 6

Expert Comment

by:gilnov
Comment Utility
You want to avoid two scenarios: 1) trying to put a policy at the top of the domain and wiggle and wrangle things so that the overlapping polices work or 2) having to set policies on an account-by-account basis. It would be better/easier to put the accounts into OU's (either existing or new) and apply policies at that level.
0
 
LVL 6

Expert Comment

by:gilnov
Comment Utility
Another thought that just occurred to me is that, since GPP relies on client-side extensions, it is possible that some computers don't have the the CSE's installed. That would make it seem like the policies are not being applied to the ACCOUNT when it's actually that the granular policies aren't available on the MACHINE.
0
 

Author Comment

by:Chris Christensen
Comment Utility
All workstations here are Windows 8.1 pro x64 and servers are 2008 r2 or 2012r2, I thought CSE's were ready to go on those OS's. The majority of the user accounts in AD are being controlled by the FGPP. The ones that aren't are being used by services and what not. They were marked for the passwords to never expire, however changing that setting for Max Password Age expired a good chunk of these accounts. I have since reset the passwords for those account.

My goal I am trying to achieve is to get to back to what it was. I do not want to have these account passwords expire again 6 months from now. It sounds like since I set the Max password age to 180, undefining it will not set it back, and that it what I am trying to do. Is that a possibility?
0
 
LVL 6

Expert Comment

by:gilnov
Comment Utility
That is correct. Setting a max password age via GP "tattoos" the account in AD since there is no mechanism for storing the existing value at the moment when the policy is applied. Setting the MaxPasswordAge policy back to "not configured" just stops enforcing it from the domain perspective and leaves the local registry value in place. You will either need to go to each account in AD and set the "account never expires" flag manually or put all the service accounts in a "Service Accounts" OU and apply a policy that sets the never expires flag. I don't know off the top of my head exactly which GP/registry setting that would be but it should be easy enough to find via your favorite search engine. Incidentally, setting the flag manually in the ADUC snap-in will override any settings that come from group policy...for when you want to be absolutely sure. Also, as you may have discovered by now, setting never expires on an account (by whatever method) does not remove the expired condition. You will still need to reset passwords.
0
 

Author Comment

by:Chris Christensen
Comment Utility
So I believe what you're saying is that the setting is tattooed in the registry even though the policy is no longer enforcing it. I am taking this to mean that I need fix this or else it going to expire the accounts again in 6 months.  Is that correct?
0
 
LVL 6

Expert Comment

by:gilnov
Comment Utility
From what you have described about your environment, that is essentially correct except it's not tattooing the workstations, it's the AD user account. Whenever a user logs on to a workstation for the first time, certain registry settings are copied from AD to the NTUSER.dat file. The settings in NTUSER.dat will fill in the blanks or override any conflicting values in the HKCU section of the registry. That's where the expired password settings reside. That's why you need to attack the problem in AD not from the workstation side.

In my mind, the most straight-forward approach is to create an OU in ADUC called "Service Accounts" or whatever you like, move all the accounts you want to not expire into the OU, select all the accounts at once, right-click one of the accounts, select Properties, click the Account tab, put a check in the box labeled "Password never expires", click OK the requisite number of times and, bang! Done. This will override all Group Policy settings that might be squirreling things up on those accounts. However, as mentioned earlier, once the account has been flagged as having an expired password, you will still need to unflag it by resetting the password which can be a pain if there are dozens or hundreds of service accounts (if there are hundreds of service accounts in your domain...well, that is a whole other topic).

The problem with setting the "Password never expires" flag on the AD user accounts as described above, however, is that it is inflexible. If you ever want to change the setting on an account or group of accounts, you'll have to do it manually. It's not that big a deal since it's quick but if you want to make it flexible, you'll need to build a GPO to set passwords to never expire then link it to the OU. Here's a how-to I ran across. I haven't tested it so proceed with caution: https://support.software.dell.com/password-manager/kb/136971
0
 

Author Comment

by:Chris Christensen
Comment Utility
That doesn't sound too bad, I do want to get your thoughts on this one. I should preface this by saying that our functional level is 2008.

I was speaking with someone else today and they said that I could set the Max Password Age in the default policy to 0 which would removed the 180 day tattoo and the rest of the accounts that are already managed by FGPP's would essentially be untouched. Does that sound correct to you?
0
 
LVL 6

Accepted Solution

by:
gilnov earned 500 total points
Comment Utility
From what you have told me, that would PROBABLY work...but not necessarily. I haven't poked around your entire AD tree so I can't give a definitive answer but because of LSDOU (GP processing order), any policies applied at the domain level will be superseded by conflicting policies at the OU level.

If your default domain policy has a 0 MaxPasswordAge value set, and the granular polices are set for 180 days at the OU level, users in affected OU's will have a 180 day expiration. If, on the other hand, user accounts are just floating around in OU's that don't have policies, who knows? Maybe they'll be 180, maybe zero or maybe something else if they got tattooed along the way.

The same principle we use when assigning share and NTFS permissions where you assign permissions to groups then put users in the groups to grant access carries over into Group Policy thinking. To complete the thought in GP parlance, assign policies to OU's and then add objects to the OU's to implement policy. That's the way GP is designed to work so you're swimming upstream if you try to do it differently. That is to say, you don't HAVE to do it that way but you'll have an easier time of it if you don't fight the way the system is designed to work.

In the domain I currently manage, we set our general password policies in the default domain policy as many people do but we just manually set the "Password never expires" flag when creating an account we want to exempt from the expiration part of the policy. This isn't ideal but it works fine. As with any network, things tend to get a bit...organic over time. It was done that way before anyone on the current staff came aboard and we just haven't ever bothered to change it. Bottom line: either option (setting the flag or putting a policy on an OU) will yield the desired result. It's really just a matter of personal preference.
0
 

Author Comment

by:Chris Christensen
Comment Utility
The only thing that was a little odd today is that there were some account that are flagged for Password does not expire and those account came up with password change needed. I am going to give it a go a tomorrow morning.
0
 
LVL 6

Expert Comment

by:gilnov
Comment Utility
That is not inconsistent with my experience. Remember, the "Password never expires" flag is a different flag than the "Password IS expired" flag. Once the account is flagged expired, the password needs to be reset before the never expires flag can stop it being flagged in the future. In other words the never expires flag is not retroactive. It only looks forward in time and says, "never again."
0
 

Author Closing Comment

by:Chris Christensen
Comment Utility
This worked out, our FGPP has 2 different polices set up. They both target security groups, a 90 day and 180 day group. All domain users are members of on of the aforementioned groups and the service accounts and non expiring user accounts (i know this is bad, but it was approved by the powers that be) are no longer affected. Thank you for the assistance with this one.
0
 
LVL 6

Expert Comment

by:gilnov
Comment Utility
Hood work! Happy I could help in some small way.
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

I'm sure that every Windows systems administrator has written, or at least used, a batch or VBS login script at some point in their career, whether it is to map network drives, install printers, or set some user preferences.  No more! With Window…
Installing a printer using group policy preferences is not that hard let’s take a look at it. First lets open up your group policy console and edit the policy you want to add it to. I recommend creating a new policy for each printer makes it a l…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …

771 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

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now