woensdag 18 juli 2007 10:59
Active Directory Domain Services: Fine-grained Password Policies
[This information is based on the Windows Server 2008 June CTP and is subject to change...]
Windows Server 2008 provides a way to define different password and account lockout policies for different sets of users in a Windows Server 2008
In Microsoft Windows 2000 and Windows Server 2003 Active Directory domains, only one password policy and account lockout policy could be applied to all users in the domain. These policies were specified in the Default Domain Policy for the domain. As a result, organizations that wanted different password and account lockout settings for different sets of users, had to either create a password filter, deploy multiple domains or implement third party password filter solutions like Anixis Password Policy Enforcer, SpecOpsSoftware Password Policy, etc...).
Now, when the domain functional level is set to Windows Server 2008, password policies can be assigned on a per user and/or per group (global security group) basis. A fine-grained password policy can not be applied to an organizational unit (OU) directly. To apply fine-grained password policy to users of an OU, you can use a shadow group.
A shadow group is a global security group that is logically mapped to an OU to enforce a fine-grained password policy. You add users of the OU as members of the newly created shadow group and then apply the fine-grained password policy to this shadow group. You can create additional shadow groups for other OUs as needed.
And now the bad news; there is no GUI available to set these password policies; meaning ADSIedit still stays your best friend...
To store fine-grained password policies, Windows Server 2008 includes two new object classes in the Active Directory Domain Services (AD DS) schema:
- Password Settings Container (PSC)
- Password Settings Object (PSO) (msDS-PasswordSettings)
A Password Settings Container (PSC) is created by default under the System container in the domain. You can view it by using the Active Directory Users and Computers snap-in with Advanced features enabled. It stores the Password Settings objects (PSOs) for that domain only.
A PSO has attributes for all the settings that can be defined in the Default Domain Policy (both Password Policy & Account Lockout Policy except Kerberos settings).
These settings include attributes for the following "Password Policy" settings:
- Enforce password history (msDS-PasswordHistoryLength - integer)
- Maximum password age (msDS-MaximumPasswordAge - integer8)
- Minimum password age (msDS-MinimumPasswordAge - integer8)
- Minimum password length (msDS-MinimumPasswordLength - integer)
- Passwords must meet complexity requirements (msDS-PasswordComplexityEnabled - boolean)
- Store passwords using reversible encryption (msDS-PasswordReversibleEncryptionEnabled - boolean)
These settings also include attributes for the following "Account Lockout Policy" settings:
- Account lockout duration (msDS-LockoutDuration - integer8)
- Account lockout threshold (msDS-LockoutThreshold - integer)
- Reset account lockout after (msDS-LockoutObservationWindow - integer8)
These nine attributes are mandatory attributes. This means that you must define a value for each one.
Settings from multiple PSOs are and can not be merged. In addition, a PSO has the following two new attributes:
- PSO Link (msDS-PSOAppliesTo - string): a multivalued attribute that is linked to user(s) and/or global group(s)
- Precedence (msDS-PasswordSettingsPrecedence - integer): an integer value that is used to resolve conflicts if multiple PSOs are applied to a user or group object. A lower value for the precedence attribute indicates that the PSO has a higher rank/priority than other PSOs.
NOTE: Integer8 attributes are 64-bit numbers (8 bytes) which usually represent time in 100-nanosecond intervals. If the Integer8 attribute is a date, the value represents the number of 100-nanosecond intervals since 12:00 AM January 1, 1601.
To link the PSO (Password Security Object) to a global security group or user, you just need to add the distinguished-name ("CN=group, OU=Organisational Unit, DC=win2008, DC=net") of the user or group in the attribute msDS-PSOAppliesTo of the Password Settings Object (PSO).
So a PSO is linked to users or global security groups via a standard forward/backlink mechanism (like the group membership among others). The forward link (msDS-PSOAppliesTo) is on the PSO, the backlink (msDS-PSOApplied) is on the user/group object.
By default, only members of the Domain Admins group can set fine-grained password policies by creating PSOs.
Only members of this group have the Create Child and Delete Child permissions on the Password Settings Container object. In addition, only members of the Domain Admins group have Write Property permissions on the PSO by default. Therefore, only members of the Domain Admins group can apply a PSO to a group or user.
However, you can also delegate the ability to set these policies to other users.
The settings on the PSO may be considered confidential. Therefore, by default, Authenticated Users do not have Read Property permissions for a PSO.
You do not need permissions on the user or group object to be able to apply a PSO to it. Having Write permissions on the user or group object does not give you the ability to link a PSO to the user or group. The ability of linking a PSO to a group or user is given to the owner of the PSO, because the forward link is on the PSO.
Multiple PSOs applied
A user or group object can have multiple PSOs linked to it, either because of membership in multiple groups where each have different PSOs applied to them or because multiple PSOs are applied to the object directly. However, only one PSO can be applied as the effective password policy. The settings from other PSOs that are linked to the user or group cannot be merged in any way.
If multiple PSOs are linked to a user or group, the resultant PSO that is applied is determined as follows:
1. A PSO that is linked directly to the user object is the resultant PSO. If more than one PSO is linked directly to the user object, a warning message is logged in the event log and the PSO with the lowest precedence value is the resultant PSO.
2. If no PSO is linked to the user object, the global security group membership(s) of the user, and all PSOs that are applicable to the user based on those global group memberships, are compared. The PSO with the lowest precedence value is the resultant PSO.
3. If no PSO is obtained from conditions (1) and (2), the Default Domain Policy is applied.
Microsoft positions this feature as alternative for deploying multiple domains due to the "single domain password policy"-limitation. Fine-grained password policies do NOT interfere with custom password filter solutions (passflt.dll) that you might use in the same domain. Organizations that have deployed custom password filters to domain controllers running Windows 2000 or Windows Server 2003 can continue to use those password filters to enforce additional restrictions for passwords.
- Fine-grained password policies apply only to users and global security groups - NO OUs!!
- Only members of the Domain Admins group can set fine-grained password policies
- Only one PSO can be applied as the effective password policy to a user and/or group
- Settings from other PSOs linked to a user and/or group cannot be merged.
- Fine-grained password policies do NOT replace custom built password filters.
For more information: Windows Server 2008 Technical Library
Also: Manage Fine-Grained Password Policies with Powershell, Ulf B. Simon-Weidner's blog
Also have a look at the free UI Console for Fine-Grained Password Policies (using Powershell password policy cmdlets)
Filed under: WindowsServer2008, ActiveDirectory, Security