Active Directory - Fine-Grained Password Policy

So I have been doing quite a bit of consulting lately and thought I would document some of the more interesting tasks that I run across.  In the last couple of weeks I have dealt with software deployments through GPO and KACE boxes.  Exchange Troubleshooting, VMware Performance troubleshooting, and several other things. 

Got the opportunity to finally implement Fine-Grained password policies.  For those of you that don't know what that is, by default using an AD domain you set one password policy at the domain level and everyone inherits that.  So what if you want to set different policies on different OUs?  No big deal create a couple of GPOs with the policies that you want and apply them to the correct OUs - WRONG!!! That doesn't work.  You can't set password policies on an OU.  You have to set up what they call Fine-Grained Password Policies. 

I found a pretty good TechNet article that pointed me in the right direction.  The problem with a lot of Microsoft's direction is that they point you in the right direction and you are in Los Angeles and want to go to NYC and they say go East.  Now it is on you to figure out how to get there.  This article was exactly that way.  It left out lots of switches and several other things to make sure it was working correctly.

https://technet.microsoft.com/en-us/library/cc754461(v=ws.10).aspx

As I have started to delve more and more back into the Microsoft world I have really come to empower PowerShell quite a bit more than ever.  It started with Exchange where I did a complete migration from Exchange 2010 to Exchange 2013 via PowerShell from Setup to migration to tear down.  Maybe I was bored, maybe I was trying to be cool (As much as computer dorks can be cool).

So I accomplished a lot of this task using PowerShell.  The concept is pretty Easy.  You have to create what is called a PSO (Password Setting Object).  You create this by using the New-ADFineGrainedPasswordPolicy cmdlet.  You then have to specify things like MaxPasswordAge, MinPasswordAge, and a few other parameters.  Not all that hard. 

Once you create the PSO you can view it using ADSI Edit under the Password Settings Container.  You can also modify settings from here if needed.  Once you have gotten this far, it still doesn't work.  Now, you have to assign who is going to have this policy applied to them. 

You would think that you can apply this to an OU, but you would be wrong.  You have to create a Domain Security Group and then grant that group permissions to the PSO.  Now you would think just go to properties and the security tab add it in and you are done.  You are wrong.  You have to go to ADSI Edit, go to that Password Settings Container and locate the PSO you just created.  Click Properties and then click the Attribute Editor tab.  Look for the msDS-PsoAppliesTo attribute.  You then enter the full DN (Distinguished Name) of the Global Security Group.

After that add users to the Group and you are good.

So how do you test.  Well I picked a user (the wrong user) and added him to the group, we then did a bunch of restarts and nothing.  So I found out after some prodding that he changed his password last week but didn't think that would count.  So I checked his expiration date.  It showed a really long number.  Now I had no clue what that number meant.  It showed a regular date in the viewing box but when you tried to modify it (which you couldn't) it showed this long number. 

So what does that long number mean out of curiosity I looked it up.  This attribute is Integer8, a large 64-bit number that represents a date as the number of 100-nanosecond intervals since 12:00 AM January 1, 1601.  1601???  Wow, not quite sure why that number but OK.

Anyway I found a user whose password expired about 2 months ago (He had the password never expires on him, which I had to deselect to see this value).  I added him to the group and did a restart and he had to change his password.  It worked like it should.  So for those of you that want to accomplish this, it isn't really difficult, just play around in a test network like your customers production machines and play around.