We are having an odd issue with out AD. We have changed the password policy to be as follows:
Enforce password history 5 passwords remembered
Maximum password age
120 days Minimum password age 1 day
Minimum password length 8 characters
This policy has been in affect since before January of this year. Our users are still having to change their password every 42 days, though. I understand that the policy doesn't take effect until your password has been changed. Our users have changed their passwords a handful of times since the change.
On the server when I run net accounts I see the following:
Force user logoff how long after time expires?: Never
Minimum password age (days): 1
Maximum password age (days): 120
Minimum password length: 8
Length of password history maintained: 5
Lockout threshold: 15
Lockout duration (minutes): 5
Lockout observation window (minutes): 5
Computer role: PRIMARY
Great! 120 days for Maximum Password! Now I check on a specific user with net user
User name Removed
Full Name Removed
Comment
User's comment
Country/region code 000 (System Default)
Account active Yes
Account expires Never
Password last set 5/5/2015 2:54:35 PM
Password expires 9/2/2015 2:54:35 PM
Password changeable 5/6/2015 2:54:35 PM
Password required Yes
User may change password Yes
Workstations allowed All
Logon script
User profile
Home directory
Last logon 4/9/2015 4:13:10 PM
Logon hours allowed All
Ok, perfect! 9/2 is 120 days after 5/5! This is typical, however. Before this user changed their password on 5/5 it was showing a date beyond 5/5 (when their password actually expired.
Today I found a new-to-me way to check a users password expiration. So I check this same user with this tool that uses Get-ADUserResultantPasswordPolicy to determine MaxPasswordAge (I was able to confirm it was going down the $accountFGPP -ne $null route by manually running Get-ADUserResultantPasswordPolicy. The function spits this out:
Password of account: SameUserAsBefore expires on: 06/16/2015 14:54:35
Wait, what? net user had said the password didn't expire until 9/2! When I ran Get-ADUserResultantPasswordPolicy on this user I found the root of the issue:
PS C:\Windows\system32> Get-ADUserResultantPasswordPolicy (Get-ADUser SameUserAsBefore -properties PasswordExpired, PasswordNeverExpires, PasswordLastSet)
AppliesTo : {CN=Domain Users,CN=Users,DC=REMOVED,DC=LOCAL}
ComplexityEnabled : False
DistinguishedName : CN=Default-#####,CN=Password Settings Container,CN=System,DC=REMOVED,DC=LOCAL
LockoutDuration : 00:30:00
LockoutObservationWindow : 00:30:00
LockoutThreshold : 10
MaxPasswordAge : 42.00:00:00
MinPasswordAge : 1.00:00:00
MinPasswordLength : 7
Name : Default-#####
ObjectClass : msDS-PasswordSettings
ObjectGUID : GUIDRemoved
PasswordHistoryCount : 3
Precedence : 1
ReversibleEncryptionEnabled : False
And here I am, dumbfounded as to why it's 42 days despite the Group Policy I have set which is enforced and linked at the domain level. It's set to apply to Authenticated Users. I have tried deleting this and remaking it in case the policy had become corrupt in some way.
Does anyone have any idea why the group policy isn't actually taking affect?
Answer
This issue has finally been solved! A whole new world of Windows Server has been revealed to me.
From Mec Beau and edited by Excellll:
By creating GPO on OU, This will not work for what you're trying to do. GPOs pertaining to Password policies can only be set at the domain level. However, In order to apply a policy to a subset of domain users then you need to use Fine-Grained password policies.
These can be applied at the group level, so you need to ensure all the users you wish to affect with this new policy are a member of the appropriate group.
To do this on a Windows 2012 domain, do the following from a DC .
- From the Start Screen type DSAC.EXE to start the Directory Service Administrative Center.
- Navigate to the System\Password Settings Container
- Right Click and select New or use New under the Tasks menu.
- Choose Password Settings
- Create a New Password policy either for a User or a group.
- Set its Precedence in case if u have multiple policies created, so lower the number higher the priority.
It's fairly self-explanatory from there.
No comments:
Post a Comment