Link to home
Start Free TrialLog in
Avatar of Chris Christensen
Chris Christensen

asked on

AD default domain policy issue

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?
Avatar of gilnov
gilnov
Flag of United States of America image

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.
Avatar of Hypercat (Deb)
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
Avatar of Chris Christensen
Chris Christensen

ASKER

Ok, so is there no way of setting this back?
I'm not sure without a bit more research.
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.
So here is the output from
get-addefaultdomainpasswordpolicy

Open in new window


User generated image
Here is the output from secpol.msc from a workstation

User generated image
The secpol.msc is showing setting that are inside of the default domain controller policy which has not been touched.
Would setting the max password age to 0 possible reset this setting?
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?
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/
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.
Or would it be a better idea to create a new FGPP for the accounts that should never expire?
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.
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.
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?
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.
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?
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
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?
ASKER CERTIFIED SOLUTION
Avatar of gilnov
gilnov
Flag of United States of America 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
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.
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."
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.
Hood work! Happy I could help in some small way.