I’m sure like many of you in your organization you have certain service accounts in active directory where the passwords don’t change that often. When you do change them, like when an employee leaves, sometimes you might miss a few on some old servers that you forgot you had, and all of a sudden, that service account is getting locked out.
There are good reasons to leave it that way. For one, it protects your service accounts from brute force/dictionary password attacks. Also, if a service account gets locked out, you usually know right away because an application server will stop working.
The problem with it though is although it may protect you from guessing password attacks, it could potentially leave you at risk for a DoS attack. Think about it, all an attacker would have to di is keep running a brute force attack on a service account, and it would lock out keeping your service from working. That last reason is a good reason too in itself… The service stops working!
This used to be a pain in the arse in Windows 2000 and 2003. According to Windows Architecture:
In Windows Server 2000 and Windows Server 2003 applying password policy was restricted to Default Domain Policy. With this approach if organization has to plan for different set of password policy for their users spread across the globe , it was not possible.
Lucky for us, Microsoft fixed this limitation in Windows Server 2008 and 2008 R2. Instead of applying password policy in the default domain policy, you can create multiple PSO’s (Password Settings Objects). Just make sure to leave the password policy settings in the default domain policy as undefined. In order to make this work though, YOU HAVE TO RAISE THE FUNCTIONAL LEVEL OF YOUR DOMAIN TO 2008 OR BETTER! That means if you still have 2003 DC’s in your domain, it is finally time to upgrade! Instead of applying the PSO at an OU level, now you do it with security groups. Pretty slick right?
Before creating your PSO’s, first plan it out. We only needed two in my domain. One for regular user accounts, and the other for service accounts. Now, since we don’t want service accounts to lock out, but we don’t want bad guys guessing our passwords either, we set the accounts to not lock out, and also set a minimum password length to be really long (like 40 characters).
Also it is important to note that when running the wizard to create the PSO’s there are four different kinds of fields:
- Unicode String – This can be anything. Generally used to name your PSO
- Boolean – For this it is looking for True or False
- Integer – For this it is looking for a single number
- Duration – For this is is looking for a time frame (I.E. 90:00:00:00 = 90 days, and 00:00:30:00 = 30 minutes)
Now we have a basic idea of what we want, we are ready to create our PSO’s. You have to do this using ADSI EDIT doing the following:
- Open ADSI EDIT, right click on ADSI Edit at the top of the root and select Connect To
- In the Name field type in the FQDN of your domain
- Expand down to CN=System> CN=Password Settings Container
- Click on CN=Password Settings Container
- On the right side if there are any PSO’s, they will be there. If this is the first time you are doing this, it will be blank
- Right click on CN=Password Settings Container and select New>Object
- For Select Class, you should only have one option which is msDS-PasswordSettings, click Next
- On the next page, give your new PSO a name (I.E. ServiceAccounts) and click Next
- On the next page is the Password Settings Precedence. The lower the number, the higher the precedence. For example, a precedence of 1 will override a precedence of 2. See the diagram below
- Follow the prompts for the rest to fit your environment. Remember what I wrote above for the four different value types
- Also note that for the msDS-LockouTThreshold field, if you set that to 0, then lockouts will be disabled. Otherwise the Integer value represents the number of attempts
Repeat the above process for all the PSO’s you want to create. Make sure you set important ones with higher precedence. For example, I set our Regular Users to a precedence of 2, and the Service Accounts PSO to a precedence of 1.
Once you have your PSO’s created, now you will want to create security groups to apply the PSO’s to. In my environment I applied the Regular Users PSO to the Domain Users group because that is the default group for all users. Then I created a second group for Security Users that I applied the Security Users PSO to. When I assign a service account to the Security Users group, the Security Users PSO takes priority over the Regular Users PSO, and boom! No more lock outs!
To assign a group to a PSO do the following:
- Open Active Directory Users and Computers, and make sure view Advanced Features is enabled
- In Active Directory Users and Computers expand down to Services>Password Settings Container
- In Password Settings Container, find your newly created PSO’s. Right click on one and select Properties
- Click on the Attribute Editor tab
- Scroll down to msDS-PSOAppliesTo, click on it and select the Edit button
- Click the Add Windows Account Button, and enter the name of the security group you want to apply the PSO to and click OK
- Click OK, then Apply
- Now you’re done!
It seems complicated at first, but once you look at it, it’s actually pretty simple and ingenious. Makes me wonder why Microsoft hadn’t done this before!
Have any questions or comments? Hit us up below!