In "Windows Server 2008 Password Policies," Jan De Clercq gave an excellent introduction to fine-grained password policies. However, using ADSI Edit to administer these objects is cumbersome and time-consuming. To reduce the amount of time it takes, I recommend using Windows PowerShell. Although PowerShell 1.0 doesn't contain the functionality needed to directly manage Active Directory (AD) objects, you can download a free set of PowerShell cmdlets for administering AD. Some of these cmdlets let you manage fine-grained password policies.
You can download the AD cmdlets from the Free PowerShell Commands for Active Directory Web page and install them on any computer running PowerShell. You can use the cmdlets remotely with any AD domain controller (DC) running Windows 2000 or later. The AD cmdlets work through Active Directory Service Interfaces (ADSI), so you don't need to make any modifications to AD or the DC.
All PowerShell cmdlet names consist of a verb and a noun separated by a hyphen. This makes understanding the purpose of a cmdlet much easier because they essentially are self-describing. The AD cmdlets have "QAD" as a prefix to the noun to help identify their origin and to ensure unique names. Ideally vendors should follow the suggested PowerShell guidelines and use a vendor prefix. This aids the user by helping to identify the cmdlets and preventing name clashes.
The following examples demonstrate how to use the AD cmdlets to administer fine-grained password policies on Server 2008. If you're unfamiliar with these policies, see "Windows Server 2008 Password Policies" for an explanation of Password Settings objects (PSOs) and how they work. Although the commands that follow are on multiple lines so that they fit on a Web page, you'd enter each command on a single line, wrapping only when necessary. For information about how to properly wrap commands, see "How to Handle Long PowerShell Statements."
Let's begin by viewing all the PSOs in a domain. To do so, you'd use the Get-QADPasswordSettingsObject cmdlet in a statement such as
Get-QADPasswordSettingsObject | Format-List
Figure 1 shows sample results.
To create a new fine-grained password policy, you use the New-QADPasswordSettingsObject cmdlet in a command such as
New-QADPasswordSettingsObject -Name "Administrators" -Precedence 5 -MaximumPasswordAge ( New-TimeSpan -days 20 ) -PasswordComplexityEnabled $true -PasswordHistoryLength 40 -LockoutThreshold 3 -MinimumPasswordAge ( New-TimeSpan -days 1 ) -MinimumPasswordLength 11
This command creates a new fine-grained password policy named Administrators, which has a precedence of 5. (Precedence is used to resolve conflicts if multiple PSOs are applied to a user or group account—the lower value, the higher the priority.) The password's minimum and maximum age are 1 day and 20 days, respectively. (TimeSpan is a .NET object used for a specific time period.) The password's history length is set to 40, which means 40 passwords are remembered. The minimum password length is 11 characters, with password complexity enabled ($true is a PowerShell Boolean value). The lockout threshold is set to 3 incorrect attempts before the account is locked. The parameter names should be familiar if you've worked with password and account lockout policies in Group Policy Objects (GPOs). If you haven't worked with these types of policies, the parameters are described in the "ActiveRoles Management Shell for Active Directory - Administrator's Guide," which you can download from the Free PowerShell Commands for Active Directory Web page or in the QAD Cmdlets Reference Web page.
You can apply the new policy one of two ways. The first way is to use the New-QADPasswordSettingsObject cmdlet's -AppliesTo parameter when you're initially creating the PSO. After the parameter, you list the users or groups you want to apply the PSO to. You can use sAMAccountNames (or domain\sAMAccountName), display names, distinguished names (DNs), user principal names (UPNs), SIDs, or globally unique identifiers (GUIDs), separating each entry with a comma.
Alternatively, you can use the Add-QADPasswordSettingsObjectAppliesTo cmdlet to apply an existing policy to users or groups. For example, if you want to apply the Administrators policy to a group named AdminStaff, you'd use the statement
Add-QADPasswordSettingsObjectAppliesTo 'Administrators' -AppliesTo 'manticore\AdminStaff'
The following command applies the Help Desk policy to the Help Desk group:
Add-QADPasswordSettingsObjectAppliesTo 'Help Desk' -AppliesTo 'manticore\Help Desk'
If you need to stop applying a particular policy, you can use the Remove-QADPasswordSettingsObjectAppliesTo cmdlet in a command such as
Remove-QADPasswordSettingsObjectAppliesTo 'Help Desk' -AppliesTo 'manticore\Help Desk'
There is no specific cmdlet to manage the individual attributes of fine-grained password policies after they've been created. Instead, you use the generic Set-QADObject cmdlet, which you can use to set the attributes of any AD object. In PowerShell, Set is used as the verb for any cmdlet that has a modifying action.
To specify the PSO you want to modify, you use the Set-QADObject cmdlet's -Identity attribute followed by the PSO's sAMAccountName, display name, DN, UPN, SID, or GUID. You then specify the PSO attributes you want to set. Some PSO attributes can be set directly using the Set-QADObject cmdlet's named parameters. For example, you can use the cmdlet's -Description parameter to set a policy's description. All other attributes have to be set using the -ObjectAttributes parameter. This parameter's syntax is
-ObjectAttributes @\{attr1='val1'\}
where attr1 is the PSO attribute's name (i.e., the name you'd use in ADSI Edit) and val1 is the value you're assigning to that attribute. (You can specify more than one attribute, provided you separate attribute name-value pairs with semicolons.) For example, the command
Set-QADObject -Identity 'CN=Administrators,
CN=Password Settings Container,CN=System,DC=Manticore,
DC=org' -ObjectAttributes @\{'msDS-LockoutThreshold'=1\}
-Description "PSO for Administrators"
uses the -ObjectAttributes parameter to set the msDS-LockoutThreshold attribute to 1 in the Administrators PSO. The command also uses the -Description named parameter to set the PSO's description to PSO for Administrators.
Windows-based environments are becoming more complex with each new release of the Windows family—and Server 2008 is no exception. It's not possible to keep increasing administrative budgets in order to match this growth in complexity. Fortunately, automation of administrative tasks can optimize the management of Windows environments. As these examples show, PowerShell and the AD cmdlets can simply the management of fine-grained password policies in Server 2008.
—Richard Siddaway, Microsoft Practice Leader, Centiq Ltd.