Before you read this blog, it is recommended to have a basic understanding of:
Active Directory features, Group policies and password policy, Active directory schema and objects. There are related Microsoft articles available for further information. I have written this with the inspiration from Harivishnu to just provide an overview of the fine grained password policy which we have recently implemented and tested in our test domain LEARNING.COM.
Are you familiar with active directory password policies?
It is an easy subject for Windows administrators. But for non windows people, Password policy is a way to enhance security by implementing a set of rules related to your password. As you all know our system password has certain criteria to be met. When you set a password, it must meet the complexity requirements. These complexity requirements and other settings will be decided according the organization’s requirements.
In Windows 2003 account policies will be set in a group policy which is enforced to the entire domain. Due to this, all the users in a domain must follow the same password complexity requirements and settings i.e. you cannot have multiple password policies in a windows 2003 domain. The screen shot of the group policy shows the settings in Account Policy. Account policy has settings for password policy, account lockout policy and Kerberos policy. You can notice that all these settings come under the computer settings and not under user settings. So once the domain is set up, the local Security Accounts Manager (SAM) in each domain computer will be controlled using the above settings. That’s how it works in 2003 domain
Windows Administrators always wanted multiple password policies for different kinds of user accounts. They have been asked to set different password complexity settings for a privileged account and a normal user. But as I mentioned earlier this is not possible in windows 2003 and we will have only one password policy in each domain. It is now the time to say ‘yes’ to the requirement. In Windows 2008 domain you can have multiple password policies!! Fine grained password policies let you have different password policy settings for different sets of users. This will allow you to set stricter account lockout and password restrictions for privileged accounts and looser ones for normal users. Cool. Isn’t it?
How can you achieve that? The approach is entirely different in 2008 Active directory. Instead of having the Account Policies in a group policy, the settings have now moved out of group policy. Account Policies is no longer based on computer accounts. It is now possible to target individual users and groups of users to control their password restrictions. You can use ADSI Edit (or any other LDAP Editing tool) to modify the Active Directory object and its associated account policy attributes. In fact the settings are configured in AD database.
Fine-grained password policies apply to user objects and global security groups. In order to store the fine grained password policies there are two new object categories in the Active Directory Domain Services (AD DS) schema: Password Settings Container (PSC) and Password settings Objects (PSO). Password Settings Container (PSC) will be created by default under the System Container of the domain, which is visible in Active Directory users and Computers with the Advanced Features enabled. As the name indicates it is the container used to store the Password settings Objects (PSO). The default PSC cannot be renamed, moved or deleted. But you can create your own custom additional PSC. (Microsoft does not recommend this and custom Password settings Containers will not be considered when computing the Resultant set of policy (RSOP)). Settings other than the Kerberos settings can be defined in the Password Settings Objects (PSO). These include the following password settings and account lockout settings:
- Enforce password history
- Maximum password age
- Minimum password age
- Minimum password length
- Passwords must meet complexity requirements
- Store passwords using reversible encryption
- Account lockout duration
- Account lockout threshold
- Reset account lockout after defined time
In addition, a PSO has the following new attributes:
- msDS-PSOAppliesTo. This attribute has multiple values and shows the link to a user or group object
- msDS-PasswordSettingsPrecedence. An integer value, used to avoid conflicts if multiple PSOs are applied to a user or group.
You must define the settings under the above 9 categories. All of them are must have attributes. The msDS-PSOAppliesTo, a multi valued attribute contains link to user and groups objects. You can apply a PSO to multiple users or groups i.e. you can create one password policy and apply it to different sets of users or groups. A couple of new attributes msDS-PSOApplied and msDS-ResultantPso have been introduced to the user and group as well (msDS-ResultantPso for User). The msDS-PSOApplied attribute has a link back to the PSO.
You can apply a PSO to user either directly or indirectly through group memberships. In this way user or group object can have multiple PSOs linked, either due to the membership in multiple groups with linked PSOs or because PSO applied to the object directly. But only one of them will take effect. msDS-PasswordSettingsPrecedence attribute helps to calculate the winning one from the conflict. The PSO which is directly linked to the user object has the highest priority (You could not link multiple PSOs directly to a user). If there is no directly linked PSO, the PSOs from the group memberships will come in to the play. The PSO with the lowest precedence value (value of msDS-PasswordSettingsPrecedence) will take effect. A lower value of this attribute indicates that it has higher precedence. For Example: A user has no directly linked PSO and has two PSOs applied through group memberships with a precedence of 2 and 4, the PSO with a precedence value 2 will take effect. If there are no PSOs linked to a user directly or indirectly, the default domain policy will take effect. Things will be more complex if you have no directly linked PSO and have multiple PSOs with the same precedence value (Microsoft recommends unique precedence value for each PSO). In this case the GUIDs of the PSOs will be compared and the PSO with the lowest GUID will be applied. The msDS-ResultantPso attribute will be calculated based on the above rules. This shows the final PSO which got applied to the user.
Important Points to Remember:
- Microsoft says the userAccountControl settings like Reversible password encryption required, Password not required, Password does not expire will override the settings in the resultant PSO.
- Your domain must be running in Windows 2008 functional level to utilize the fine grained password policy. This indirectly states that you cannot have windows 2000, 2003 Domain controllers in your domain.
- Fine grained password policies are available in all editions of Windows 2008.
- If you are not creating fine grained password policies, the settings in the Default domain policy will take effect (Just like your windows 2003 domain).
- Only domain administrators or delegated users can create or modify the PSOs.
The fine grained password policies cannot be applied to an organizational unit. But you can create a global security group called shadow group and can add the users of an OU to the group. This shadow group can be used to apply the fine-grained password policy. If you move users between OUs, you must update the shadow group membership.