Creating Fine Grained Password Policies

Step right up folks!  Our proven Fine-grained password policies are guaranteed to cure all your password policy problems.  We have complex passwords, for that end user that calls because their WeatherBug plugin isn’t working.  We have simple passwords, for the lazy admin who doesn’t want to type in a long complex password like the rest of his company.  Whatever you need, we have.

Okay, I’m being a little sarcastic, but you get the idea.  Fine-grained password policies are great when you need to have multiple password policies in the same domain.  By the way, I recommend all my customers make their Admin’s use complex passwords that change quarterly.

What should you know about FGPP’s?

First off, your domain functional level must be at Windows Server 2008.  Second, Fine-grained password policies ONLY apply to user objects, and global security groups.  Linking them to universal or domain local groups is ineffective.  I know what you’re thinking, what about OU’s?  Nope, Fine-grained password policy cannot be applied to an organizational unit (OU) directly.  The third thing to keep in mind is, by default only members of the Domain Admins group can set fine-grained password policies.  However, you can delegate this ability to other users if needed.

Create a New Password Settings Object (PSO)

Okay, we talked about what you should know, but let’s now talk about the different ways you can create a Fine-grained password policy.  I’ll admit it, creating a new Password Settings Object on a 2008 Server is cra*…Hmm, I should use a more appropriate word here.  “Not pleasant”  Yeah, let’s go with that.  You have a couple of options, ADSI Edit or PowerShell.  Let’s use ADSI Edit first.

ADSI Edit:

1. Click on Start, Run, type Adsiedit.msc and click on OK.

2. Connect to Default naming context.

image

3. Expand CN=System,DC=Contoso,DC=com  (Replace DC=Contoso,DC=com with your domain)

4. Right click CN=Password Settings Container and select New, Object…

image

5. It will launch Create Object wizard.

image

6. Confirm msDS-PasswordSettings class is selected and click Next.

7. For different attributes, type the values you would like to set.  Below are the samples I used.
cn: TestPSOGroup
msDS-PasswordSettingsPrecedence: 5
msDS-PasswordReversibleEncryptionEnabled: FALSE
msDS-PasswordHistoryLength: 24
msDS-PasswordComplexityEnabled: TRUE
msDS-MinimumPasswordLength: 5
msDS-MinimumPasswordAge: 05:00:00:00 (5 days)
msDS-MaximumPasswordAge: 20:00:00:00  (20 days)
msDS-LockoutThreshold: 0
msDS-LockoutObservationWindow: 0:00:30:00 (30 minutes)
msDS-LockoutDuration: 0:00:30:00(30 minutes)

8. Click Finish to complete the creation of this object.

image

PowerShell:

Now we can set all the same PSO settings using PowerShell as well.  Just remember to import the Active Directory Module into PowerShell first.  “Import-Module ActiveDirectory

image

New-ADFineGrainedPasswordPolicy -Name "TestPSOGroup" -Precedence 5 -ComplexityEnabled $true -Description "The PSO Test Policy"-DisplayName "Tes tPSO Group" -LockoutDuration "0.00:30:00" -LockoutObservationWindow "0.00:30:00" -LockoutThreshold 0 -MaxPasswordAge "20.00:00:00" -MinPasswordAge "5.00:00:00" -MinPasswordLength 5 -PasswordHistoryCount 24 -ReversibleEncryptionEnabled $false

Windows Server 2012:

With Windows Server 2012, you can now use the Active Directory Administrative Center to create new PSO’s.  It’s extremely simple, and if you use Fine-grained password policies, you should upgrade to WIndows Server 2012 A.S.A.P.

1. Open Server Manager Dashboard, click on Tools Menu, and click Active Directory Administrative Center.

2. Navigate to the Password Settings Container. (Domain > System > Password Settings Container)

image

3.  You can now either right click, and select New, and then Password Settings.  Or on the right side of the screen under Tasks select New, and then Password Settings.

4. Complete the dialog box and then click OK.

image

That was easy!

Apply your new Password Settings Object

So after we go though the trouble of setting up a new PSO, I guess we should apply it to someone or some group.  With Windows Server 2008, you will once again use ADSI Edit.

Windows Server 2008:

1. Click on Start, Run, type Adsiedit.msc and click on OK.

2. Connect to Default naming context.

3. Expand CN=Password Settings Container,CN=System,DC=Contoso,DC=com  (Replace DC=Contoso,DC=com with your domain)

4. Right click on the TestPSOGroup object in the details pane and select Properties.

5. Click the Attribute Editor tab and select msDS-PSOAppliesTo attribute from the list of attributes.

6. Click Edit.

7. Click Add Windows Account

8. Type the account\group name in the Select Users, Computers, or Groups dialog and click OK.

9. Click OK in the Multi-valued Distinguished Name with Security Principal Editor dialog box.

10. Confirm correct value is set for msDS-PSOAppliesTo attribute.

11. Click OK.

Windows Server 2012:

In Windows Server 2012 adding members to your PSO is extremely easy.  In the same screen where you created the Password Setting, click the add button.  After that, Type the account\group name in the Select Users, Computers, or Groups dialog and click OK.

image

 

Password Settings Precedence

When we created our Password Settings Object, we set the “Password Settings Precedence”.  The Password Settings Precedence is a number you assign to the PSO incase multiple PSOs are applied to a user or group object.

Example:

PSO-A with a Precedence of “5”
PSO-B with a Precedence of “6”

You have both Password Settings Objects (PSO-A & PSO-B) applied to the same user.  Which PSO would the user inherited?  The answer is “PSO-A”, since it has the lower Precedence number.

What if both PSO’s have the same precedence number?  In that case, the PSO with the smallest globally unique identifier (GUID) is applied.

It is recommended that you assign a unique Password Settings Precedence value for each PSO that you create.

Hopefully now you feel comfortable working with Fine-Grained Password Policies, and you will use them for good and not evil.  Overall you should try and limit the number of PSO’s defined.  This is due to the additional overhead for your admin’s in creating and managing PSO’s.  Along with explaining to end users why Sue’s password policy is different then Ed’s policy.