- Interact with Azure Cosmos DB with PowerShell - Tue, Sep 14 2021
- Azure health services: Track Microsoft cloud outages and maintenance - Wed, Sep 8 2021
- Powerline: Customize your PowerShell console - Tue, Aug 31 2021
There was a time, not so long ago, in which Active Directory domains were limited to one and only one password policy. Microsoft eventually learned from its customers that this was a bad idea because some shops have different groups of domain users with different security requirements.
Service accounts are another example of security principals that are often subject to different password policies than traditional user accounts. Managed service accounts help, but again we are faced with complicated setup steps that many Windows systems administrators don’t have time to bother with.
Windows Server 2008 introduced fine-grained password policies, in which we administrators could indeed deploy more than one password policy within a single domain. However, the configuration steps are clunky and require monkeying around in ADSI Edit or Windows PowerShell 2.0.
NOTE: Third-party developers have created GUI front-ends to ease fine-grained password policy in Windows Server 2008. See this TechNet blog post for more details.
Finally, in Windows Server 2012, Microsoft has given us a truly user-friendly interface for deploying fine-grained password policy, or FGPP. As you can and should expect, we can create these policies by using either GUI tools or Windows PowerShell 3.0.
Determining our security requirements ^
Let’s imagine we are administrators for an Active Directory domain named 4sysopslab.com. We have used the Group Policy Management Console (GPMC) to deploy a baseline password policy by editing the Default Domain Policy Group Policy Object (GPO).
However, we have a global security group named HiSec whose members have more stringent password policy requirements than do the rest of our domain users. How can we use FGPP to accomplish this goal?
Our first step is to verify our HiSec security group membership. In Windows Server 2012 Server Manager, select Active Directory Administrative Center from the Tools menu.
Opening the ADAC from Server Manager
From the List View in Active Directory Administrative Center (ADAC), select Users and verify that the security group exists and its membership is correct. On my test system, the HiSec group contains a single user named Tim Warner.
Verifying Active Directory users for fine-grained password policies
Our next step is to actually create the FGPP.
Defining the password policy ^
To create the FGPP, switch to the Tree View in ADAC and navigate to System > Password Settings Container. Right-click the Password Settings Container object and select New > Password Settings.
Opening the Password Settings Container
In the Create Password Settings dialog box, we can specify all of the familiar password policy settings by using a simple, single-screen interface. In my view, this is much more intuitive way to define policy as compared to the Group Policy method. Required fields are specified with a red asterisk; you can see the interface in the following screenshot.
Defining a Fine-Grained Password Policy
You can review the meaning of the password policy settings by consulting TechNet. What we should take a closer look at is the Directly Applies To field. Click Add in the Create Password Settings dialog box to attach our newly created FGPP object to a specific Active Directory groups and/or users. You can see in Figure 4 that I attached the Hi-Sec FGPP to my HiSec global group.
An alternative method for attaching FGPP objects to Active Directory groups is to open the group’s properties page in ADAC and navigating to the Password Settings section. We can then click Assign to select a FGPP. This is shown in the following figure:
Directly assigning Fine-Grained Password Policy
In the previous two screenshots you doubtless noticed the Precedence field. What exactly does this option do? Well, although it isn’t necessarily recommended, you can apply more than one FGPP to an AD group or user. The precedence field accepts arbitrary integer values in which lower numbers denote higher priority. You can use 1 and 2, 100 and 200, or some other numbering schema—it doesn’t matter. The FGPP with the lowest integer value takes priority for that AD user or group.
Alrighty then! Now that we have created our FGPP, it is time to verify its association with our HiSec group and Tim Warner account and test the policy in practice.
Testing the password policy ^
In ADAC, switch the view to List View, select your domain, and locate an AD user account who we expect to be affected by our new fine-grained password policy. Right-click that account and select View resultant password settings from the shortcut menu.
NOTE: You can view the FGPP settings for an AD group by right-clicking the object, selecting Properties from the shortcut menu, and navigating to the Password Settings area in the resultant dialog box.
Checking on a user's Fine-Grained Password Policy settings
If the selected user does have a FGPP applied, then you will see the properties page for that FGPP object appear. If the user. If the user does not have a FGPP applied, then you will see the message box shown in the following figure:
Warning if selected AD user has no Fine-Grained Password Policy settings
The following message box appears when you try to change the password for a user account with a FGPP applied to it and that password fails to meet the policy requirements:
Fine-Grained Password Policy enforcement
In this blog post we learned how to use the much more user-friendly fine-grained password policy feature in Windows Server 2012. You now understand how to deploy and manage more than one set of password requirements within a single Active Directory Domain Services (AD DS) domain.