With Windows Server 2008, Microsoft introduced Fine-Grained Password policies which utilizes a new Active Directory object called Password Settings Object (PSO). These objects allow you to more easily create and assign password policies to subsets of users, albeit with a bit of an unpolished implementation method compared to the old method via group policy (GPO).
If you decide to use PSOs instead of GPOs for your password policies, it’s still a good idea to specify a “blanket” GPO password policy via the Default Domain Policy and make it match the standard policy you implement via PSO. This ensures no user accounts fall through the cracks. Keep in mind that while PSOs always override GPOs, having a blanket password policy via your Default Domain Policy ensures all users will be subject to a standard global password policy if they (for some reason) are not subject to any PSOs within your domain. (Example: A user is not in the Domain Users group, but your standard PSO is assigned to Domain Users).
HOW TO CREATE A PASSWORD SETTINGS OBJECT (PSO)
I’ll show you how to create a Password Settings Object (PSO) using ADSI Edit, but you can also use PowerShell or the “ldifde” command to create PSOs.
1. Load ADSI Edit by clicking Start, then Run, typing adsiedit.msc and clicking OK.
2. In ADSI Edit, right-click the ADSI Edit root folder and choose Connect to.
3. In the Name field, type the fully qualified domain name (FQDN) for your domain. Click OK.
4. In the left pane, expand your domain by double-clicking it.
5. Expand DC=(your domain) folder under your domain (is named the same) by double-clicking it.
6. Expand CN=System by double-clicking it.
7. Click CN=Password Settings Container. The Password Settings Container is where your PSOs will live. Any PSO objects created in your domain will appear here.
8. Right-click CN=Password Settings Container, click New, and then click Object.
9. In the Create Object dialog box, under Select a class, click msDS-PasswordSettings, and then click Next.
10. In Value, type the name of the new PSO, and then click Next.
Continue with the wizard, and enter appropriate values for all attributes (see Managing Password Settings Objects below).
MANAGING PASSWORD SETTINGS OBJECTS (PSO)
After PSOs are created, you can later edit them using Active Directory Users and Computers.
1. Open Active Directory Users and Computers.
2. Make sure Advanced Features is checked in the View menu.
3. Expand the System folder.
4. Click on the Password Settings Container.
5. Your PSOs are listed in the right pane. Double-click a PSO.
6. Click the Attribute Editor tab.
PSO attributes start with “msDS-” and the values you specify require adherence to strict syntax rules, but there is NO built-in syntax validation.
Let’s take a closer look at the individual settings. Below is an example of a PSO you could use as a default password policy, applied to the Domain Users group, we’ll call it “Standard Global Password Policy”.
Standard Global Password Policy
And here’s an “exception” policy that would allow accounts in a group called “Password Exceptions” to have no password expiration.
Password Exception Policy
Here’s what each setting means (using the Standard Global Password Policy as the example):
Specifies the number of minutes a locked out account remains locked out. In this case, 5 minutes.
This setting is the same as the “Reset account lockout counter after” setting in a group policy object. It specifies the amount of minutes that must elapse after a failed login attempt before the observation window resets, in this case, 1 minute. In other words, this setting specifies the amount of time BETWEEN failed logon attempts.
Example: If you attempt to logon to an account with the wrong password, the “badPwdCount” attribute for your account is incremented by 1. This starts the clock. If the clock reaches the value specified in the “msDS-LockoutObservationWindow” setting, then the process starts from scratch, and the “badPwdCount” attribute resets to zero. But if another failed logon attempt is recorded before the “msDS-LockoutObservationWindow” setting is reached, then the “badPwdCount” attribute is incremented (again) by 1. If the “badPwdCount” attribute reaches the value specified for the “msDS-LockoutThreshold” (see next attribute) the account will be locked.
Specifies the number of failed login attempts that causes a user account to be locked out, in this case, 50 attempts.
Specifies the maximum time before a password must be reset (password expiration), in this case, 90 days. You must use the format exactly as it appears in this example.
Specifies the minimum time before a password change is allowed. If you don’t need this setting, then set it to “(none)”. And yes, it needs to be set to exactly that, without the quotes, otherwise observe the same syntax used for msDS-MaximumPasswordAge.
The minimum character length of a password.
If set to TRUE, passwords require complexity. If set to FALSE, passwords do not require complexity. There is no customization of the complexity ruleset with this setting. It’s either on or off.
Specifies how many historical passwords Active Directory should remember for each user account, so that users are forced to use a fresh/unique password with each password change. In this case, a user will not be able to repeat the same password for 24 cycles (90 days each), which is almost 6 years.
Setting this value to TRUE specifies Active Directory to store passwords with a reversible HASH, to allow certain authentication protocols like CHAP and HTTP Digest Authentication to decrypt passwords. In most cases this should be set to (FALSE) for better security.
This setting applies to the Password Settings Object (PSO) itself, and it is one of the reasons to use PSOs instead of GPOs for password policies. This value specifies the order in which this PSO is applied. As you can see, the Standard Global Password Policy PSO is 2nd in priority. The Password Exceptions Policy PSO is 1st. If you are going to have user accounts that need to be exempt from the standard password policy, you need a separate policy with higher preference, that is why the Password Exceptions Policy PSO has a precendence of 1.
This setting controls which user accounts receive the password policy settings via this PSO. You can specify as many individual users or groups as necessary via each user/group’s distinguished name.