First published on TechNet on Oct 07, 2013
Hi, Dougga here again and I just can’t leave password policies alone. So, are you ready for another password policy issue? I saw the hand up in the back, so let’s give it a shot. Previously, I had a post on Fun and Games with Active Directory Password Policies . I would like to call this post a continuation on that topic, but that wouldn’t be true. Rather a recent ADRAP I performed we (the customer mostly) found an interesting twist to Fine Grained Passwords. The ADRAP tool just pointed it out.
So what‘s the issue? Let me answer that with a quiz that I hope all reading this know the answer.
<\Begin One Question Quiz>
1. After creating a fine grained password policy the policy can be applied to (Choose All that Apply):
a. User
b. Organizational Unit (OU)
c. Global Groups
d. Domain Local Groups
e. Universal Groups
</End One Question Quiz>
You can find the answer with a quick search on http://bing.com I am sure. If you don’t know the answer without looking it up, I bet you will figure it out as you read through this blog post.
Scenario – Setup fine grained password policy for the corporate users.
First we will start with a Sales OU with a Users OU and a Groups OU.
We cannot apply a fine grained password policy to an Organizational Unit, so we will need to create a global security group and place the Sales Users in the group. You can do this manually or write a script to populate the group with members of the “Users” OU found under the “Sales” OU.
For my demo here, I will only have one Sales User, and will use a global security group to apply the policy to the user. Are you getting close to getting the answer above?
· Create a user in the Sales\Users OU – I created a user named “Sales One”
· Create a Global Group called “FGPP – Sales” in the Sales\Groups OU and put the Sales User created above in that group.
 |
So far so good. Nothing you haven’t done already. So the next step is to create a fine grain password for the Sales User to be applied to the “FGPP – Sales” group.
I am going to rely on your knowledge and not provide step by step to create a fine grain password. If you want step by step check out this article . However, if you have a Windows 8 Client with RSAT or Windows 2012 with AD tools installed you can use a GUI interface to create the policy.
To use Windows 8 with RSAT:
- From the Start Screen type DSAC.EXE to start the Directory Service Administrative Center.
- Navigate to the System\Password Settings Container
- Right Click and select New or use New under the Tasks menu.
- Choose Password Settings
 |
Fill out the desired settings AND add the security principals to apply the policy to.
All is now setup and you can use ADSIedit in 2008 or 2008R2 to see the “Resultant PSO.”
- Using 2008 or 2008 R2 you can use ADSIedit or active directory users and computers with View/Advanced Features enabled and use the Attribute Editor tab. Find the Sales user and open the Sales user properties.
- Click on Filter and select Constructed Attributes (if it is not already checked)
 |
Find MSDS-ResultantPSO
Using PowerShell 3.0 on Windows 8 type Get-ADuserResultantPasswordPolicy Sales1
Okay, So what. This is nothing new. So here comes the twist and the reason for this post. Remember the 1 question quiz above?
1. After creating a fine grained password policy the policy can be applied to (Choose All that Apply):
a. User
b. Organizational Unit (OU)
c. Global Groups
d. Domain Local Groups
e. Universal Groups
Easy way to remember this is that fine grained passwords are per domain and groups that can contain users from other domains would not work. Makes sense.
So the system protects you from using a Domain Local or Universal group, right? Yes and no. In the Windows 8 GUI (DSAC.EXE), the Universal Group is not available to add to the apply the policy to . However on Windows 2008R2 and ADSIedit the object picker allows any type of security group to be added. What is the result of this capability?
In my lab I have created a Universal Group named “FGPP Universal”, created a new user “Sales2”, placed this user in the group, and applied the existing fine grain password policy “FGPP Sales” to “FGPP Universal.” So what is the ResultantPSO for this Sales2?.
 |
Nothing returned means no fine grain password policy. A look at the GUI reveals the same.
 |
Note: On Windows 8 or Server 2012 Directory Services Administration Center (DSAC.EXE) you will find an option on a user account with a right click for checking resultant password policies. This does not work until the schema is extended to support Windows 2012 domain controllers. The powershell command does work without extending the schema.
What to take from this post is that fine grain passwords will not apply to groups that can contain members outside if the domain. While there is some protection it is still easy to get in this situation.
Here are a few examples of how this could happen:
1. Windows 2008R2 ADSIedit does not prevent incorrect groups
a. Windows 8 and Server 2012 do prevent this
2. You can convert a group from Global to Universal and there is not a warning that any fine grain password policies applied to that group will discontinue working.
3. You can convert the group from Universal to Domain Local. This still does not allow the fine grain password policy to apply.
4. Once a group has been converted to Universal or Domain Local, members from outside the domain may prevent conversion back to a Global group
a. Will have to remove foreign domain users from the group to be able to convert to Global.
This issue easily hides because it does not have a direct and immediate impact on the users unless the domain policy is more restrictive than the FGPP and even then the impact could be delayed. So, in the end, if you are using FGPP a periodic review of the groups designated to apply the policy may be worth a few minutes of your time.
Doug “I have one more password policy post coming” Gabbard