Implementing Fine-Grained Password Policies in Active Directory Domain Services

The Problem

Since being on Active Directory after moving from Windows NT in 2003, we finally made the jump to Windows Server 2008 R2.   Even though we were planning on going to 2008 R2 across the board, there were many advantages of us upgrading our AD DS servers and eventually the domain functional level to Windows Server 2008 R2. First and foremost, Fine-Grained Password Policies.

There were several factors that pushed us to implement Fine-Grained Password Policies.

• All  faculty and staff account passwords were set to NEVER expire.  So everyone could have had the same password they have been using since 2003.  Unfortunately, this was the case for several of our users, who had used the same password for eight years.  
• In November 2010, we were hit by a spear-phishing scam, where several of our Faculty and Staff members handed out their log in information to the phishers. This in turn hit our mail servers hard, as the phishers had full access to send emails as our hit users. Causing us to become blacklisted for up to three weeks at some sites. After we remediated the known affected users accounts, by changing passwords and forcing log offs and a log on to make the changes take full affect, and by blocking all hijacked emails being sent on behalf of them, we thought we were in the clear.   That was until four months later, we found out other faculty and staff members had given their user account info to the phishers that November day. The scammers held onto their account information, and since our passwords never expired, they were able to use their accounts four months later.  We were blacklisted again, this time longer.
• That was enough, I was tired of working holiday's and weekends because our users had the problem of handing out their information to anyone who said they were part of IT. It was time to make a change. Since making a huge change for a thousand users can affect a lot of items, I had to throw together a proposal and present it before our administration.  The administration was all ears, since they were most affected by the blacklisting and complaints from users.  They gave the go ahead to schedule the password enforcement.  

After reviewing our domain's password policy, it was determined that the basics were in place and I could roll this out to all faculty/staff users by simply unchecking their accounts to allow their password to expire.  This would allow us to enforce 90 day password expiration, and minimum password length.  Unfortunately, at that time, we were unable to enforce password complexity.  Doing so would affect 5000 students that never login on campus. We don't have the personnel to handle the phone calls, especially if we increase the call volume by 600% in one day.

I sent an email to all users informing them about the upcoming changes and timeline, some ho hummed about the changes, others were grateful.  Once the scheduled evening arrived, I set all faculty and staff user passwords to expire.  The next morning, the phone began to ring. Our implementation had begun.

The Implementation

Scenario: Three types of users,  Faculty/Staff, Domain Admins, and Students, each need their own unique password enforcement.
Requirements:Windows Server 2008 or Windows Server 2008 R2 Domain Functional Level, Knowledge of ADSI Edit, Groups Created in Active Directory that you will apply the Policies to. Exchange Client Access Server configured to allow for changing of expired passwords.

The Plan

Faculty and Staff Password Policy (Common-Name)

Enforce Password History (Password History Length for User Accounts)	10 Passwords (10)
Maximum Password Age (Maximum Password Age for User Accounts)	90 Days (90:00:00:00)
Minimum Password Age (Minimum Password Age for User Accounts)	2 Days (2:00:00:00)
Minimum Password Length (Minimum Password Length for User Accounts)	8 Characters (8)
Password Must Meet Complexity Requirements (Password Complexity Status for User Accounts)	Enabled (True)
Lockout Duration (Lockout Duration for Locked out User Accounts)	30 Minutes  (00:00:30:00)
Lockout Threshold (Lockout Threshold for Lockout of User Accounts)	5 Invalid Attempts (5)
Reset Counter (Observation Window for Lockout of User Accounts)	5 minutes (00:00:5:00)
Domain Groups	DOMAINNAME\Faculty Group; DOMAINNAME\Staff Group
Password Settings Precedence	2
Password Reversible Encryption Status for User Accounts	False

Domain Admins Password Policy (Common-Name)

Enforce Password History (Password History Length for User Accounts)	24 Passwords (24)
Maximum Password Age (Maximum Password Age for User Accounts)	45 Days (45:00:00:00)
Minimum Password Age (Minimum Password Age for User Accounts)	2 Days (2:00:00:00)
Minimum Password Length (Minimum Password Length for User Accounts)	12 Characters (12)
Password Must Meet Complexity Requirements (Password Complexity Status for User Accounts)	Enabled (True)
Lockout Duration (Lockout Duration for Locked Out User Accounts)	60 Minutes (00:00:60:00)
Lockout Threshold (Lockout Threshold for Lockout of User Accounts)	3 Invalid Attempts (3)
Reset Counter (Observation Window for Lockout of User Accounts)	5 minutes (00:00:5:00)
Domain Groups	DOMAINNAME\Domain Admins
Password Settings Precedence	1
Password Reversible Encryption Status for User Accounts	False

Student Password Policy (Common-Name)

Enforce Password History (Password History Length for User Accounts)	10 Passwords (10)
Maximum Password Age (Maximum Password Age for User Accounts)	90 Days (90:00:00:00)
Minimum Password Age (Minimum Password Age for User Accounts)	2 Days (2:00:00:00)
Minimum Password Length (Minimum Password Length for User Accounts)	6 Characters (6)
Password Must Meet Complexity Requirements (Password Complexity Status for User Accounts)	Disabled (False)
Lockout Duration (Lockout Duration for Locked out User Accounts	30 Minutes (00:00:30:00)
Lockout Threshold (Lockout Threshold for Lockout of User Accounts)	5 Invalid Attempts (5)
Reset Counter (Observation Window for Lockout of User Accounts)	5 minutes (00:00:5:00)
Domain Groups	DOMAINNAME\Students Group
Password Settings Precedence	3
Password Reversible Encryption Status for User Accounts	False

The Action
Create Password Settings Object in ADSI Edit

1. Create a group in AD if it does not already exist to add users/groups to, to force the password policy on.
2. Add users or groups that will be affected by the Policy
3. Open ADSI Edit
4. If not available, right click ADSI Edit select "Connect to..."
5. Connect to Default Naming Context for your domain
6. Expand Default Naming Context
7. Expand DC=domain,DC=suffix
8. Expand CN=System
9. Select CN=Password Settings Container
10. In the middle pane, right click in the white space, hover over "New" and Select "Object..."
11. Select msDS-PasswordSettings, click Next
12. Set the Common-Name, click Next
13. Set the Password Settings Precedence (lowest wins) as an integer, click Next
14. Choose if you want Password Reversible Encryption Status for User Accounts; must be True or False, click Next
15. Set the Password History Length for User Accounts (how many passwords to remember, will not allow user to set password as any previous X passwords), click Next
16. Set Password Complexity Status for User Accounts, must be set as True or False
17. Set Minimum Password Length for User Accounts (password must be this long to log on), click Next
18. Set Minimum Password Age for User Accounts (how long after changing the password, can it be changed again; prevents users from changing their passwords x amount of times to get back to old password), must be in DD:HH:MM:SS format, 2:00:00:00 = 2 Days, click Next
19. Set Maximum Password Age for User Accounts (how many days can the user use the password), must be in DD:HH:MM:SS format, 90:00:00:00 = 90 Days, Click Next
20. Set the Lockout Threshold for Lockout of User Accounts (how many attempts before locking user out), click Next
21. Set the Observation Windows for Lockout of User Accounts (if x invalid attempts within this time window occur, lock account) MUST BE less than or equal to Lockout Duration, also must be in DD:HH:MM:SS format, 00:00:5:00 = 5 minutes, Click Next
22. Set Lockout Duration for Locked Out User Accounts (how long will account be locked before it unlocks automatically) MUST BE greater than or equal to Observation Windows for Lockout, also must be in DD:HH:MM:SS format, 00:00:30:00 = 30 minutes, Click Next
• If you do not configure the Lockout Duration to be greater than or equal to the Observation Window you will receive an error on completion Operation failed. Error code: 0x20e7 The modification was not permitted for security reasons. 000020E7: SvcErr: DSID-030506C3, problem 5003 (WILL_NOT_PERFORM), data 0 which can be resolved by backing up through the wizard and modifying the Lockout Duration time to be greater than or equal to the Observation Window
23. Set additional attributes if needed by clicking the "More Attributes" button or...
24. Click Finish
25. Right click on the Password Policy Object you just created and select Properties
26. On the Attribute Editor tab, scroll down and select msDS-PSOAppliesTo
27. With msDS-PSOAppliesTo selected, click Edit
28. Click the "Add Windows Account..." button
29. Type in the Group Name you created earlier that will have the members passwords enforced, click OK
30. Click OK to close the Multi-valued Distinguished Name with Security Principal Editor window
31. Click OK to close the PSO Properties window.
32. Add Users to your AD Password Policy Group created 
33. If your users currently have their passwords set to "Password never expires" remove that check mark from their accounts.
34. Lastly, enjoy your latest security and rest easier at night.

The Relief

I rolled ours out group by group day at a time, allowing our helpdesk to better help the affected customers and handle the overwhelming call volume.

By the end, sure, a handful of users were not pleased with the password policy, but our users are safer and our network is all that more secure.

Resources:
http://technet.microsoft.com/en-us/library/cc770842(WS.10).aspx
http://technet.microsoft.com/en-us/magazine/2007.12.securitywatch.aspx