Latest posts by Michael Pietroforte (see all)
- Result of the 4sysops 2016 topic poll - Tue, Apr 5 2016
- New free eBooks for SysAdmins and DevOps – VMware NSX, Windows 10, SQL Server 2016 - Mon, Mar 14 2016
- Introducing the 4sysops IT pro network - Tue, Mar 1 2016
Different security groups in your domain have different rights. The more rights they have the stronger their passwords should be. Of course, you could work with just one policy enforcing very strong passwords for all users. However, this might stress your helpdesk, because users will forget their passwords more often as a result.
This is especially true if you are working with a short maximum password age. It makes sense to commit administrators to changing their password every month or so. But if you do this with standard users, it will certainly mean a lot of extra work for your helpdesk staff. This time might be better invested somewhere else.
So, I really like this new feature of Windows 2008. However, I don’t like how one has to configure multiple password policies. Like in Win2k/Win2k3 you can setup only one password policy for the whole domain using the Group Policy Editor. If you want to use more than one policy, you have to mess around with ADSIedit.msc.
First, you have to create a so-called Password Settings Object (PSO) underneath the Password Settings Container which you find under System. A wizard will guide you thru the creation of the PSO asking you to set the values for attributes like password complexity, minimum password length or lockout threshold. Simon Weidner has a complete list of all password policy attributes with a detailed description of each. Note that the wizard expects negative integers for some attributes.
Next, you have to link this PSO to a global group. If you enabled “Advanced Features” in the Active Directory Users and Computes snap-in, you’ll see the System container and underneath the Password Settings Container. There, you can access the properties of the PSO you just created. You can link this PSO to a global group or user by adding its name to the msDS-PSOAppliesTo attribute. Note that you have to use the distinguished name in the form “cn=group name, ou=group container, dc=domain name, dc=com”. It is also possible to link a PSO to multiple groups.
It could happen that you create conflicting password policies where a user belongs to multiple groups. However, only one PSO can be effective for a certain user object. There are several rules used to calculate the so called Resultant Set of Policy (RSOP). You can check out this Technet article for more information. The best way certainly is that you specify in advance which PSO is effective. For this you can use the msDS-PasswordSettingsPrecedence attribute. A lower value for this attribute indicates that the PSO has a higher priority. If you assign a unique precedence value to each PSO, it will always be easy to determine the effective password policy for a certain user object.
Even though my short article only covered the essentials of the new fine-grained password feature, you’ve probably realized that things can get quite complicated. I certainly would prefer using Group Policy for this.