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

6 Ways to Improve your IT Documentation

I came into this position last year, knowing that I had a challenge ahead of me.  The previous system administrator left our department with little to no documentation as part of their legacy.  The documentation that was left had not been updated for over six years. You know how that goes with technology, a lot happens over six years. This was a problem, as our server environment had grown over 300% since the introduction of VMware into our environment.   We now had well over 80 servers, most of them new in the past couple years.  No system configuration info, hostnames, IP addresses, purpose/role of the server, and no reason why certain servers had the configurations and setups they did.  Talk about starting from the ground up!  I had to go through each server and document what each one did, where it was in the rack, physical or virtual, who accesses it, is it secured and how so, when does the software maintenance expire, is it backed up and where, I could go for days on what needed to be done and what had not been done!

From my experiences, I have decided to share six items that I recommend to use to help improve documentation in any IT environment:

1. MediaWiki - I setup a WAMP server a few years back and installed MediaWiki on it to use it as a knowledge base.  Doing so helped offload the enormous amount of questions that our field technicians would ask me about. When I moved into a server position, it turned out to be a great tool to use for active documentation as well.  The hard part was getting our techs and other staff to start using it.  Since we all are in the bad habit of not documenting ANYTHING.  It has taken some time, but we are slowly getting everyone on board.  Implementing MediaWiki has helped increase turn around time, system up time, and the need of continuity within department.
   
   
2. Evernote - Anything to take notes with really... Using Evernote during project planning, server installation, migration/upgrade planning, and keeping an up-to-date to-do list, is a quick and easy way to make notes, store online resources, email correspondence, screen clippings, and do it all on the go or from your primary PC.  I use it to take notes during installs, trainings, webinars, and meetings.  It also comes in handy when I can't sleep because of my brain not being able to dump my daily anxiety and the knowledge of tomorrows needs, I can make a quick note on what's bothering me and have it ready to add to my schedule the next day.  Once I have a note completed if it is pertinent to our environment I can copy it into our Wiki Knowledge Base to keep my system documentation updated.
   
   
3. Benefit from Vendor Documentation and Forums - I can't thank EMC enough for how well documented a lot of their products are, most accessible in PDF format.  I'm able to download the doc's, store them on our file server or upload them to our Wiki for later reference.  Thus, increasing our local documentation.  If I don't want to make a call to support and waste their time and mine, I'll take a look through the Admin Guide or Best Practices for certain products, or I'll jump on the forums for the company to see if anyone else has the same issue.  Being in a PDF format is also great if I am looking for a bit of "light" reading, I can upload it to my e-reader, which I have with me 98% of the time.
   
   
4. Blog IT - I don't know how many times I've researched, researched, and Googled errors and had found no results.  I do find one thing in common, other people with the same problem and no answers.  After another day or so of troubleshooting, I finally resolve the issue, then, share it with no one by my Wiki.  This is one reason why I too have started a blog.  I have found so many answers from other administrators, frustrated users, and helpful support personnel on their blogs than from dedicated support sites. Start up a blog and get your time intensive problem resolutions posted so others can benefit from your research.
   
   
5. Take the Extra Time - It's worth it in the end! We all know how much faster it is when you just want to get something quick up and running or fixed, then throw our hands in the air like you just roped a calf in a rodeo event and call it good, without documenting anything. This is what gets us in trouble and how we start to fail at documentation.  Try to make it your best practice to do screenshots, write down steps taken, resources used, contacts who assisted you, and the involvement of others.  Simply taking a few notes during an install,  where you installed it, configurations you made, why you made the change, and keeping that documented in a location accessible to your team can relieve future headaches.  It is never pleasant when you are completed with a project and you don't know where something was left out.  Having the documentation in place and notes taken, benefit you when you are troubleshooting an issue.
   
   
6. Keep Everything  - Cover yourself! You never know when something can come back and bite you.  I keep everything, email, online chats from support, webex recordings from support calls (if you ask nice, sometimes they are more than willing to get you a copy), voice mails and soon, live voice recordings from phone calls.  The way things have turned over the past decade, you need to cover yourself, your family, your coworkers, and your company.  I don't know how many times someone has asked me, "Do you remember what we did three years ago for this person?". We've also had, "I've been waiting for weeks and now I am going up the ladder to complain!" It most times comes down to doing a search in my Outlook, through my PSTs (yes i still use them) or EmailXtender Archive, and there it is an email chain with the person and the proof that I need to back me up.  However, there are downsides to keeping everything. Being the Exchange and EmailXtender administrator, I've had instances where someone requests an investigation to see if a correspondence between two individuals did exist, we can tell if the email has been read, forwarded or replied to very easily.  So in that persons case, the idea of keeping everything unfortunately bit them.
   

You never know what will happen in the future.  For the benefit of your coworkers, your company, your integrity, your legacy, document, document, document!  Please, don't be the conceded, power hungry, arrogant, know-it-all admin that loves watching others fail without your help.  You are hired to help others and provide a service to your company and customers.  Don't leave them hanging if a server rack falls on you.

WSUS Content Folder Filled Up Disk

Today our WSUS server wanted be a pain and inform us that its content folder has reached 120 GB.

After running the Server Cleanup Wizard from the MMC, we found that we needed to have more space cleaned up.

The server is a Virtual Machine, so adding additional space and extending the partition is always easy.  However, we want to avoid continually adding space and extending the partition since we can use the valuable SAN space for more important services.

We are able to clean it up by stopping the WSUS service, delete all the folders and their contents from the content directory. Then from command prompt C:\Program Files\Update Services\Tools, we ran "wsusutil.exe reset".

This allowed the server to then re-download the content and only get what it should need.  This can take some time since there is an enormous amount of updates out there to get for our over 1,500 multi-OS systems.  The last time we did this was about 8 months ago, so it helped for quite a while before needing to be run again.  I will have to do some investigating to see if anyone has a script out there to perform a cleanup every few months.

From here I will monitor the server and if it continues to grow unreasonably, I will probably fire up a 2008 R2 box and start new so we get it off of the 2003 box anyway.

Granting Service Accounts Receive As and Send As Permissions

We recently needed to add a service account to have Send-As and Receive-As permissions on one of our Exchange 2007 databases.  I was able to do so by issuing the following commands.

First, I verified the user did not have the rights about to be assigned.

Get-Mailboxdatabase -Identity DBIdentity | Get-ADPermission -User SERVICEACCOUNT

I did not receive any results from the above cmdlet.

Next, I added the permissions to the database for the service account.


Get-Mailboxdatabase -Identity DBIdentity | Add-ADPermission -User SERVICEACCOUNT -AccessRights ExtendedRight -ExtendedRights receive-as, send-as

Once I issued that command, I verified they applied successfully by running the get-adpermission command again.

This worked for me but I cannot guarantee it will work for others.

Raising Domain Functional Level to Windows Server 2008 R2

Yesterday, I raised our DFL to 2008 R2. Pretty simple once all the domain controllers in your domain are up to 2008 R2. Pretty much, right click, "Raise functional level..." choose Server 2008 R2, and OK.  Once raised, replication across the domain will take care of the other DC's.

I did make sure to research any issues that might come up after raising the level.  The only forum I really found was someone having issues with a third party app performing an LDAP search.  I will keep an eye out on our applications that query LDAP, such as VoIP.

Now we wait until all the other domain administrators in our forest update their domains to 2008 R2, so we can update our Forest Functional Level.