Win Server 2008 Directory Services, Password Policies Implementations

The previous installment of our series dedicated to Windows Server 2008 Directory Services, laid out an innovative approach to providing granular Password and Account Lockout Policy settings, incorporated into a set of features available in Windows Server 2008 domain functional level (for their overview, refer to our earlier article). The new functionality allows you to overcome the limitation persisting since Microsoft’s entry into the directory services market (affecting both Active Directory and legacy SAM-based installations), which imposed a single set rules governing password and lockout characteristics for all domain accounts. So far, we have reviewed concepts that constitute basis for these rules and described new schema objects and attributes that facilitate modifications to their rigid structure.

Learn how to implement password properties and lockout behavior at a granular level.

Now it is time to focus on their sample implementation and discuss best practices that simplify their creation and maintenance.

As we have explained, the mechanism employed by Fine Grained Password Policies involves creating individual Password Settings objects (instances of msDS-PasswordSettings class) within the Password Settings Container residing in the System portion of the domain partition of Active Directory database. These objects, which individual attributes correspond to specific password or lockout properties (determining password age, length, or complexity restrictions as well as lockout duration and threshold — equivalent to the standard configuration options available via Group Policies) are, in turn, associated with designated user or group accounts using multivalued PSO Link (msDS-PSOAppliesTo) attribute. In cases where multiple, potentially conflicting policies apply to the same user, their relative relevance can be adjusted by modifying value of msDS-PasswordSettingsPrecedence attribute.

One of the most common complaints about the new functionality is its lack of a friendly interface that would simplify its management. A typical implementation involves the use of Active Directory Services Interface Editor (ADSI Edit), which allows lower-level editing of AD database content. The tool, included with the Windows Server 2008 operating system, is located in the Administrative Tools menu (alternatively, it can be accessed by typing in ADSIEdit.msc in the Open text box available via Start->Run menu) and takes the form of a MMC snap-in. After you launch it, select Connect to... option from the context-sensitive menu of the ADSI Edit node in the tree pane. This will trigger display of the Connection Settings dialog box, where you specify the domain naming context you intend to make changes to.

Assuming you are logged on to the target domain with sufficient privileges (as explained earlier, by default, only Domain Admins are permitted to create Password Setting objects, although this task can be delegated), the predefined option (Default naming context with path set to LDAP://FQDN_of_your_domain/Default naming context) is the correct choice. After clicking on OK command button, expand the Default naming context tree structure representing your domain and drill down to CN=System folder.

Next, choose New->Object... entry from the context sensitive menu of its CN=Password Settings Container subfolder, which will trigger Create Object wizard. Its first page should contain a single entry labeled msDS-PasswordSettings. Once you select it and click on Next button, you will be prompted to provide values for the following set of attributes (which format we have listed in our previous article):

• cn – (Common-Name) an arbitrary Unicode string (capable of holding up to 64 bytes) that identifies the Password Setting object (it typically references intended group of users or its specific password and lockout settings).
• msDS-PasswordSetttingsPrecedence – a positive integer that indicates relative priority of this Password Setting object in relation to others (applicable in scenarios where there multiple PSOs are applied to the same user). In our example, we will assign to it a value of 10 (lower numbers translate into higher priority).
• msDS-PasswordReversibleEncryptionEnabled – a Boolean (True or False) value determining whether passwords should be stored using reversible encryption. In general, you want to keep this feature disabled (with the attribute set to False). Enabling it has negative security implications and should be considered only in case of compatibility issues (such as, for example, when using Challenge Handshake Authentication Protocol with Remote Access and Internet Authentication Services, or when employing Digest Authentication in Internet Information Services). Interestingly, this behavior can also be controlled directly for individual user accounts (by modifying their userAccountControl attribute), taking precedence over all domain or PSO-level settings.
• msDS-PasswordHistoryLength – an integer between 0 and 1023, designating minimum number of password changes that need to take place before their current value can be reused. We will set it to 24, which is identical to the default domain-level setting.
• msDS-PasswordComplexityEnabled – a Boolean value that governs password complexity requirements, encompassing such characteristics as its length (at least 6 characters), expected character set (at least three of five categories, including digits, non-alphanumeric, Unicode, as well as standard English uppercase and lowercase characters), and randomness (user name can not be part of of the password). We will follow Microsoft recommendation and set it to True.
• msDS-MinimumPasswordLength – an integer between 0 and 255 dictating the minimum permitted password length. Just as before, we will use here the domain default of 7 characters.
• msDS-MinimumPasswordAge – a non-zero value in d:hh:mm:ss format representing minimum password age. In our example, we will use the domain default of one 1 day (expressed as 1:00:00:00). This setting is rendered irrelevant if “Password does not expire” user-level setting is enabled for a target account.
• msDS-MaximumPasswordAge – analogically, this is a non-zero value in d:hh:mm:ss format representing maximum password age (set by us to the domain default of 42 days or 42:00:00:00).
• msDS-LockoutThreshold – an integer between 0 and 65535, which specifies a number of invalid logon attempts that will result in account lockout. For the purpose of testing, we will deviate here from the domain default of 0 and set it to 3.
• msDS-LockoutObservationWindow – a non-zero value in d:hh:mm:ss format representing amount of time after which the failed logon attempt count is reset to 0. We will set it to 1 hour (0:01:00:00).
• msDS-LockoutDuration – a non-zero value in d:hh:mm:ss format, which assings amount of time the account will stay locked before is automatically unlocked. Note that (never) value can also be used, if you want to ensure that account will remain in this state until it is explicitly unlocked by an administrator. We will set its value to 42 days 42:00:00:00.

After the last of these mandatory arguments is set, you will be given an option of configuring optional ones (which we will ignore for now) and finalize creation of the Password Setting Object (by clicking on Finish command button), which should immediately appear in the details pane of ADSI Edit console. At this point, it is possible to activate its Properties dialog box (by double clicking on it or by selecting Properties entry from its context sensitive menu), containing Attribute Editor and Security tabs. The first one of them allows you to modify any of its attributes (use Filter command button to control which ones should be displayed). We will use it to specify a domain user or global group accounts that will be affected by settings listed above. To accomplish this, double-click on the msDS-PSOAppliesTo entry in the list of Attributes.

Once the dialog box labeled Multi-valued Distinguished Name with Security Principal Editor appears, click on Add Windows Account… command button and locate an appropriate security principal using Select Users, Computers or Groups object picker. Note that the same can be accomplished from Active Directory Users and Computers, by turning on Advanced Features option in its View menu, which reveals System parent folder of the Password Settings Container, with the newly created Policy Settings object and Attribute Editor in its tabbed Properties dialog box. To test the new configuration, wait for AD replication to complete and attempt to logon with a test account, intentionally mistyping its password four times in a row, which should result in its lockout.

In general, to simplify management of fine-grained password policies, it is recommended to create individual domain global security groups corresponding to a specific Password Settings objects and link them using msDS-PSOAppliesTo attribute. Control of membership of these group can be subsequently delegated to trusted administrative staff, eliminating this way the need to modify permissions of the Password Settings Container and its content. At the same rate, to eliminate potential confusion and simplify troubleshooting, you should also avoid situations where the same user is a subject of two (or more) PSOs. One way to accomplish this is tp design an Organizational Unit structure that reflects a desired password and lockout policy settings. While it is not possible to assign PSOs directly to OUs, you can then create corresponding AD domain global groups (with one-to-one relationship between them), populate groups with users who are members of corresponding OUs, and use the msDS-PSOAppliesTo attribute to associate each group with appropriate PSO.

Note that such an approach requires that user membership of the designated global groups (frequently referred to in this context as “shadow” groups) be updated on regular basis. That is easily done by employing a custom script running on scheduled basis, which monitors changes to OUs content and modifies accordingly list of members in the respective groups. If you have a significant number of custom policies to configure, consider taking advantage of Microsoft LDIFDE (for more information about its use, review the Knowledge Base article 237677) and more common third-party freeware utilities (such as Specops Password Policy Basic, joeware’s PSOMgr, or Quest’s Active Directory PowerShell
Cmdlets and the corresponding GUI console), which simplify their creation and management.

This concludes our discussion regarding Fine-Grained Password Policies. We will continue the overview of remaining Directory Services features introduced in Windows Server 2008 in the next article of our series, focusing on characteristics and usage of the Database Mounting Tool.