Archive | Active Directory

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.


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…


5. It will launch Create Object wizard.


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.



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


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)


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.


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.



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.


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.

Installing a 2012 Domain Controller with PowerShell

If you didn’t know, the default installation for Server 2012 is Server Core.  You can still install the GUI, but if possible 2012 Core should be considered.  Server Core has come along way, and is a no brainer if you want to use less of the system processor, and less memory.  Without the GUI, your servers are also less of a target to attacks.  Less code means, less vulnerabilities.  So how are you going to take care of your Core Servers?  PowerShell of course!

In today’s article, we will be promoting a Windows 2012 server to a Domain Controller with PowerShell.  Exciting right!  Well maybe not, but you still need to know how to do it.  Okay, lets get started.

Just like in my pervious post, the first thing we will need to do is install the Active Directory Domain Service Role.

AD DS Role Installation:

PS C:\> Get-WindowsFeature AD-Doamin-Services


PS C:\> Get-WindowsFeature AD-Domain-Services | Install-WindowsFeature


Just like with the GUI, we will need to do the prerequisite checks.  The Prerequisites Check is a new feature in AD DS 2012 domain configuration.  These checks will alert you with suggested repair options, and inform you of new security changes that will affect older operating systems.  These test’s will also run during the installation process of a Domain Controller, so they don’t have to be run separately.  However for todays tutorial, we will run them.

Note: The domain controller promotion process cannot continue until all prerequisite tests pass.

 PS C:\> Test-ADDSForestInstallation

You will be prompted for your Domain Name, and the Safe Mode Administrator Password.


PS C:\> Test-ADDSDomainInstallation




AD Forest …Check

AD Domain…Check


Mission Control, we are a GO…

Domain Controller Promotion:

If you haven’t already imported the ADDS Deployment module, we will have to do that first.

PS C:\> Import-Module ADDSDeployment

If you want all the defaults and quickly add a new Domain Controller to your environment just type the following.

PS C:\> Install-ADDSDomainController

Now since that won’t work for 99% of you, lets take a closer look at this cmdlet.  By default, the cmdlet “Install-ADDSDomainController” will configure your Domain Controller with the following settings:

  • Read-only Domain Controller: No
  • Global Catalog: Yes
  • DNS Server: Yes*
  • Database Folder: C:\Windows\NTDS
  • Log File Folder: C:\Windows\NTDS
  • SYSVOL Folder: C:\Windows\SYSVOL

*DNS Server

1. New forest: always install DNS
2. New child or new tree domain: if the parent/tree domain hosts DNS, install DNS
3. Replica: if the current domain hosts DNS, install DNS

Unless those settings work for you, I always recommend installing your Domain Controllers by a script.  This will allow a consistency throughout your environment, and make your life easier.

The Script

The script is fairly simple.  Just fill in and configure your settings.  You will also need to set the execution policy on the server before you can run any scripts on it.  I’m going to use “Remote Signed”.

 Set-ExecutionPolicy RemoteSigned

# PowerShell Script to Install Domain Controllers #

Import-Module ADDSDeployment
Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-InstallDns:$false `
-CreateDnsDelegation:$false `
-CriticalReplicationOnly:$false `
-DatabasePath "C:\Windows\NTDS" `
-LogPath "C:\Windows\NTDS" `
-SysvolPath "C:\Windows\SYSVOL" `
-DomainName "contoso.local" `
-NoRebootOnCompletion:$false `
-SiteName "SiteName" `

As you see from the script above, I will be configuring the server with these settings.

  • Read-only Domain Controller: No
  • Global Catalog: No
  • DNS Server: No
  • Create Dns Delegation: No
  • Database Folder: C:\Windows\NTDS
  • Log File Folder: C:\Windows\NTDS
  • SYSVOL Folder: C:\Windows\SYSVOL
  • No Reboot On Completion: No
  • Site Name: Name of site
  • For a full list of switches and settings, review this TechNet article.

Now that we have the script configured, save it as a “.ps1” file and run it.  Since we didn’t specify the “Safe Mode Administrator Password”, you will have to enter it in manually.  To fully automate this process just add the following argument “-safemodeadministratorpassword”, and password.


That’s it.  Go get a cup of coffee, or take the afternoon off.  When you get back, you should have a brand new 2012 Domain Controller.