Win Server 2008 Directory Services, Fine-Grained Password Policies
Since its entry into directory services market (introduced in the Windows NT product line), Microsoft has been consistently restricting individual domains to a single, uniform policy dictating characteristics of passwords (e.g., minimum and maximum age, maximum length, complexity and uniqueness) and lockouts (duration and threshold) affecting all user accounts.
|Managing password properties and lockout behavior gets granular in Windows Server 2008.|
Although this approach ensured consistency in the manner many organizations desired, it was frequently viewed as too limited, as it forced the creation of separate domains solely to accommodate varying security requirements among different groups of users. This lack of flexibility continued in Windows Server 2000 and 2003 Active Directory domains. Third-party vendors, such as SpecOps, Anixis and nFront, provided some relief with their custom password filter implementations. Such workarounds required additional management and brought with them additional overhead and stability issues.
The situation finally changed with the release of Windows Server 2008 platform, although, as we will demonstrate, the current solution still leaves room for improvement.
In general, policies affecting password properties and lockout behavior of Windows users are determined by configuration of a database in which their accounts are defined. In the case of stand-alone systems or domain members, Security Accounts Manager (SAM) database provides the storage. Domain accounts, on the other hand, are defined in a dedicated partition of Active Directory implemented as NTDS.DIT file. With a single (albeit distributed via replication) database, all are the subject of the same password policy regardless of the options assigned via Group Policy Objects specific to organizational units or sites, since they affect only local accounts defined on computers residing in these containers. Also remember it is not possible to leverage Security Group filtering to alter this behavior for arbitrary domain users or groups, since settings relevant in this context are part of the Computer Configuration node of Group Policy Objects.
Domain-wide password and lockout rules take effect as soon as the first domain controller forms a new domain, due to automatic creation of the Default Domain Policy. Direct modification is not recommended. Instead, if its results must be altered, the preferred approach involves creating another GPO with desired values, linking it to the domain, and increasing its priority to ensure it will take precedence. You can examine its content by launching Group Policy Editor (via Active Directory Users and Computers or Group Policy Management Console). In the Account Policies subnode of the Windows SettingsSecurity Settings hierarchy (under Computer Configuration node), you will find the following entries:
- Password Policy includes settings that "Enforce password history" (impose a minimum number of password changes that must take place before the same value is reused); dictate "Maximum password age," "Minimum password age" and "Minimum password length"; declare that "Password must meet complexity requirements"; and control whether it is possible to "Store passwords using reversible encryption," which is required in scenarios involving IIS Digest authentication and CHAP via RAS or IAS).
- Account Lockout Policy includes settings that determine "Account local duration," "Account lockout threshold" (the number of invalid logon attempts that would trigger account lockout), and define duration of time to "Reset account lockout after."
- Kerberos Policy includes settings that allow you to "Enforce user logon restrictions" (causing Kerberos Key Distribution Center to validate user rights policy), as well as affect "Maximum lifetime for service ticket," "Maximum lifetime for user ticket," "Maximum lifetime for user ticket renewal" and "Maximum tolerance for computer clock synchronization."
These options (along with their preset values) are identical in the Default Domain Policy in case of Windows Server 2003 and 2008 Domain Functional Levels. However, with the latter, it is finally possible to customize password and lockout properties of arbitrarily selected accounts. This is possible regardless of the domain-wide configuration, by taking advantage of the new feature called fine-grained password policies. Note that its capabilities do not include Kerberos Policy-specific entries.
The functionality is based on ability to define unique groupings of Password Policy and Account Lockout Policy settings and associating them with one or more individual domain user accounts or domain global security groups. You can also use instances of inetOrgPerson class in environments leveraging third-party X.500 directory services for this purpose. Since there is no mechanism for merging multiple policies, additional rules govern the way any potential conflicts are resolved, in scenarios where several groupings are linked to the same users or groups.
Recent Articles About Windows Server 2008
» Win Server 2008 Directory Services, More About RDOCs
» Win Server 2008 Directory Services, Read Only Domain
» Win Server 2008 Directory Services, Windows Server 2008 Functional Levels Overview
Read More About Windows Server 2008
The actual implementation leverages two newly introduced Active Directory object classes (as well as a number of attribute classes associated with them). The groupings take the form of Password Settings objects (instances of msDS-PasswordSettings class), which are located in the Password Settings Container and stored in the System portion of the domain partition. You can view both by enabling Advanced Features option in the View menu of Active Directory Users and Computers console. Each Password Settings Object (PSO) created contains a number of mandatory attributes, which correspond to individual Password and Account Lockout settings. They appear here in the same sequence as their domain-based Group Policy equivalents listed above:
- msDS-PasswordHistoryLength - an integer, with a value between 0 and 1023.
- msDS-MaximumPasswordAge - a non-zero value entered in d:hh:mm:ss format (if using ADSI Edit) or an integer representing number of negative 100-nanosecond intervals equivalent to desired time interval. For example, 1 hour is equal to negative 60 (minutes) * 60 (seconds) * (10 to the power of 7) nanoseconds. For more information on this topic, refer to PSO Attribute Constraints TechNet article.
- msDS-MinimumPasswordAge - a value in the same format as msDS-MaximumPasswordAge. Note that it cannot be larger than the one assigned to msDS-MaximumPasswordAge.
- msDS-MinimumPasswordLength - an integer value between 0 and 255.
- msDS-PasswordComplexityEnabled - a boolean value (TRUE or FALSE).
- msDS-PasswordReversibleEncryptionEnabled - a boolean value (TRUE or FALSE).
- msDS-LockoutDuration - a value in the same format as msDS-MaximumPasswordAge.
- msDS-LockoutThreshold - an integer value between 0 and 65535.
- msDS-LockoutObservationWindow - a value in the same format as msDS-MaximumPasswordAge. It cannot be larger than the one assigned to msDS-LockoutDuration.
In addition, each Password Settings Object contains two other unique attributes. The first one, optional and multi-valued PSO Link (msDS-PSOAppliesTo), is intended for distinguished names of Active Directory user and group accounts to which all of the attributes listed above will be applied.
The second one (msDS-PasswordSettingsPrecedence) is mandatory, and its value (a positive integer) determines priority of this particular PSO (lowering the number increases priority) to provide means of conflict resolution in cases where multiple PSOs are associated with the same account user or domain global security group, which implies that only its relative, rather than absolute, value is relevant. However, any PSOs linked directly to a user account always take precedence over those associated with global groups of which the user is a member. If any of them have equal priority levels, lower value of globally unique identifier (GUID) is used as the selection criterion.
Alternatively, if there are no PSOs that affect a user account either directly or via its group membership, the domain-level Group Policy with the highest link order takes effect, was the case in earlier versions of Active Directory domains. In any of these scenarios, custom password filters implemented still apply.
To determine Password Settings Objects linked to a specific user or group account (directly or indirectly via group membership), you can look up the value of the msDS-PSOApplied attribute of their AD objects. This is easily done using the Attribute Editor tab of the object's Properties dialog box, visible once you enable Advanced Features in the View menu of Active Directory Users and Computers console. Be sure to also select Backlink type under the Show Read-Only Attributes option accessible via the submenu of the Filter command button in the lower right corner of the dialog box.
To establish which of these PSOs actually took precedence over others, examine the values of the msDS-ResultantPSO attribute of a target user account. This attribute is not applicable to groups. As before, you can use for this purpose the Attribute Editor tab of that user's Properties dialog box in Active Directory Users and Computers console. This time, you must ensure that Constructed type under Show Read-Only Attributes in the submenu of the Filter command button is checked on.
The ability to manage Password Settings Objects is limited by default to members of Domain Admins group (based on "Create all child objects," "Delete all child objects," "Read," and "Write" permissions on the Password Settings Container and Password Settings objects).
Effectively, they are also the only ones who have ability to assign PSOs to arbitrary Active Directory users and groups by modifying the value of their msDS-PSOAppliesTo attribute. This can be done even without permission to modify target accounts. Although it is possible to delegate management of individual PSOs to designated groups by modifying default permissions, this approach is not recommended.
We will review best management practices and provide examples of implementing fine-grained password policies in the next article of our series.