Password Management and Account Lockout Policies in Windows Server 2008

One of the most frustrating aspects that accompany the lives of network administrators in the domain Active Directory Windows 2000 and Windows 2003 is the inability to create different security policies on the characteristics of passwords of users, groups and differentiating them by type of use. You can not have groups with more restrictive policy on passwords or user groups that have specific policies about passwords and synchronized with other data sources. Currently, you can create one and only one password policy, specified in the Default Domain Policy, and that applies throughout the domain, regardless. In fact, the graphical interface of the current Group Policy Management Console is misleading. If we try, for example, to create a new password policy level we have created an OU in our domain and which contains some user accounts and computer accounts, everything seems to work well and do not receive any error message. But in reality it is not. The only real force in the password policy is set at the domain level. The creation of a different password policy enforcement at the OU only affects user accounts that log on locally to the machines contained in the OU in question, has no effect on user accounts that regularly access the Active Directory domain.

In Windows Server 2008 was finally introduced a method, albeit not very intuitive to define multiple password policies and assign them to different users and user groups within the domain. The basic requirement to apply this new feature you have already upgraded the domain functional level to Windows Server 2008, which means that all domain controllers must have Windows Server 2008 operating system and can not in principle have no domain controller system previous operating (Windows Server 2003, Windows 2000 Server, or the obsolete Windows NT Server 4.0). The domain functional level to Windows Server 2008, introduces two new classes of objects in the Active Directory schema:

• Password Settings Container
• Password Settings Objects

The class folder Password Settings Container (PSC) is also created in the container System snap-in Active Directory Users and Computers (see enhanced mode) are stored here and the Password Settings Object (PSO) for the domain. You can not delete, move or rename the Password Settings Container.

The new password policy can be assigned only to users and security groups. You can not directly assign a new password policy for a computer account or to an OU.

1. First we go to Administrative Tools and open the ADSI Edit console. Top left, we click right on ADSI Edit and select Connect to ...
2. In the Name field insert the domain name in FQDN format in which we will create a new PSO. In our case it will betadomain.local.
3. Then we go down in the structure of ADSI Edit to betadomain DC = DC = local, CN = System, CN = Password Settings. Right-click on CN = Password Settings and select New / Object ...
4. In the object creation (ie our PSO), scroll-PasswordSettings msDS proposal and proceed.
5. In the screen that appears enter the name you assign to the PSO ("Password policy very restrictive").

Later on just follow the screen instructions.

At the last screen you click the More Attributes button in the upper right hand in the window that appears, under the Select Which Properties to view select Options in the drop down menu Select a property to view msDS-PSOAppliesTo select Edit Attribute field and insert the DN of the IT-Admins security group at the end by clicking on Add. Close the window by clicking OK and then Finish. The new PSO will appear in the right pane in the CN = Password Settings Container in ADSI Edit. Now we need to ensure that the new settings have been properly stored in Active Directory. Return in Active Directory Users and Computers and descend to betadomain.local / System / Password Settings Container. Here we find our PSO and clicking Properties, Attribute Editor tab, find the attribute that points to the msDS-PSOAppliesTo Distinguished Name CN = IT-Admins, OU = Groups, DC = domain, DC = local. Going into its properties and click on the Attribute Editor tab, we can find attribute msDS-ResultantPSO with the correct value of the PSO. If the attribute did not have a mean value that would enable the password policy of the Default Domain Policy. If in the future we want to apply the PSO "very strict password policy" also, for example, members of the Sales-Europe, just go in Active Directory Users and Computers, go down to betadomain.local / System / Password Settings Container, click Properties of the PSO, the Attribute Editor tab, select the attribute msDS-PSOAppliesTo the bottom left corner and click the Edit button. By clicking on the Add button at the bottom ... then enter the DN of the DN Sales-Europe (CN = Sales-Europe, OU = Sales, DC = betadomain, DC = local) and give OK.

Before concluding, we should provide more details about a couple of things a bit 'mysterious that we encountered during configuration. The four values entered in the wizard to create the PSO concerning the maximum and minimum password, account lockout duration and the time that must elapse before the counter is reset attempts, were entered as I8. This format stores the unit of time at intervals of -100 nanoseconds and it is therefore necessary to first convert the usual format in minutes, hours or days at intervals of 100 nanoseconds and prefix the result of the minus sign. In establishing new PSO, please note that:

• the value-msDS MinimumPasswordAge must be less than or equal to the value-msDS MaximumPasswordAge.
• the value-msDS LockoutObservationWindow can not be less than the value msDS-LockoutDuration.
• the value-msDS MaximumPasswordAge can not be zero.

The second window of the wizard to create the PSO asked us the value of an attribute relative to the precedence of the password policy. What is this value? A user or group can find themselves assigned more than one PSO, either because a user can belong to more than one group or because, perhaps wrongly, have been assigned to an object directly over PSO. In any case, only one PSO can be as active as password policy settings and only the PSO that act on that user or that group, the settings of any other PSO can not be added. The above (with the attribute-msDS PasswordSettingsPrecedence) is to define the priority of a PSO over another. More than one value is lower, its priority is high. If we create a new PSO completely different from what had just conceived and that the PSO-PasswordSettingsPrecedence msDS attribute with a value of 9, giving the IT-Admins group would have a precedence (priority) and become more active for the PSO that group, replacing the PSO Password policy very strictly.