Have you ever had issues when trying to apply different password policies to users or groups on the same domain? If so keep reading.
Server 2012 now has a GUI-based version of Active Directory (AD) as well as the more conventional version we are all used to. You can do everything in the new version that you could in the old, but in slightly different ways. Although this may take a bit of time to get used to, stick with it, as I wouldn't be at all surprised if the next release of Windows Server has the GUI version only (although this is my own personal opinion, we'll have to wait and see if Microsoft announces anything).
When you build a server and configure it to act as your new domain controller, you often want to create various policies such as drive maps, printer allocations and resource restrictions and assign them to a group of users or computers. This is all standard practice and works just fine.
However, those of you that have tried to set various password policies for different users or groups will have found that it takes a lot of configuration in Active Directory to achieve. The issue occurs because there can only be one default domain policy, and password settings need to be configured within this policy. This then applies to the entire domain meaning that you have to create a separate forest for each set of users and configure the new default domain policy for each forest.
This all makes your job of managing the server much more complicated and could ultimately be a huge headache.
In Server 2008R2, Microsoft introduced a new feature called Password Settings Objects (PSO's) which can override the password policy at domain level. However, this had to be done using ADSIedit or Powershell and wasn't very user-friendly.
Not to worry, I have some great news for you. Using Server 2012 Active Directory Administrative Centre (ADAC) you can now configure and manage PSO's easily in a very user-friendly GUI.
I'm going to talk you through configuring multiple PSO's and assigning them to different security groups. I will then explain how to prioritise which PSO will be assigned to a user account that is a member of multiple security groups with a PSO assigned to them.
Once you have configured your 2012 Server, and promoted it to a domain controller you will see that there is a new icon on your start screen for ADAC.
Open this up and browse to the following folder:
Yourdomain (local)SystemPassword Settings Container
From here you can click the "new" button in the top right corner and you will be presented with the new password settings object (PSO) screen.
Create your required policy, name it, and set the precedence to 1. Do this for all your policies, then assign each policy to the required security group. I have created three security groups, and a policy for each of these groups. Here is my Helpdesk users' policy:
I have created a test user, and added it to all three security groups: Helpdesk, Admin, and Management.
Now you want to test which policy my test user account will have assigned to it.
To do this, in ADAC, go to the container where you created the test user, select this user, and then on the right hand side you will be able to select "view resultant password settings".
When you click this, the password policy that has been assigned to the user will appear.
*TIP - If you have named the policies something meaningful you will instantly know which policy you are looking at, and which group it is meant for. I suggest naming each policy after the security group you will assign it to, or at least put the purpose of the policy in the description.
You may now find that users that are members of multiple security groups with PSO's assigned to them are picking up the wrong password policy. This is because all policies have the same precedence level, and the policy deemed more secure will be applied.
This can cause issues when you have a user that is part of a security group that has access to secure data, and should have a certain policy applied, but because this user is also a member of another security group with a PSO applied to it, the account may be assigned the wrong password policy therefore compromising your security.
To combat this, we need to set the precedence of the password policies so that no matter how many groups a user is a member of, the user account will always use the policy with the highest precedence.
For instance, a user is a member of both the helpdesk and admin security groups as the user works in both departments. Because of this, you need to make sure that the policy applied to this user is secure to meet your company requirements.
So, we set the policies in order of precedence so that the admin policy has a higher precedence than the helpdesk policy, thus forcing the user account to pick up the admin password policy.
This way we can be sure that there is no way a manager's or director's user account can pick up an insecure password policy, and forces them to use a secure password and perhaps change it on a weekly basis, as per the policy settings you created earlier.
As a basic rule of thumb, if a user account has multiple password policies applied to it through its membership of security groups, it will always use the policy with the highest precedence score (the lower the numerical value, the higher the precedence!)
This configuration is useful in all sorts of different organisations, whether in a business or, for instance, a school environment. In this case admin staff might have access to confidential files, and therefore have a much stricter password policy than that of the students and other staff.
This works really well and hopefully will be a benefit to you in your environment.
