Active Directory: Password Policies

Introduction

Since the int​roduction of Fine Grained Password policies in Windows Server 2008 we no longer have the restrictions of the single password policy per domain in Windows 2000 and 2003 environments. There is still however a fair bit of confusion over password policies and implementations of different policies for different sets of users. This post should address these issues and provide information and options to achieve your desired results.

Passwords policies and group policy

Every new domain by default has two group policy objects. The Default Domain Policy and the Default Domain Controllers Policy. The domain policy is linked at the domain level and the domain controller policy is linked to the Domain Controllers OU.

The default domain policy contains a set of default password settings. I’ll explain all of these settings shortly.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb19.png

What we are concerned with here is the fact that this policy contains the password settings. As already mentioned, in Windows 2000 and 2003 we didn’t have the option to create fine grained password policies. And only one password policy to affect domain user accounts could exist. A common misconception is that the only password policy is the default domain policy. This is not true, in fact we can create another policy and have it apply to our domain user accounts, this however is only true if the policy is applied at the domain level with the highest precedence order, otherwise the default domain policy will always win (in Windows environments where fine grained password policies do not exist). Lets take a look at this in a little more detail.

We are going to login to our domain using a new user account, with the password change required at next login.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb20.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb21.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb22.png

We are using the a brand new domain, and no changes have been made to the Default Domain Policy. We can tell from the policy settings that the following password requirements are set by default on a Server 2012 domain.

Policy	Setting	Description
Enforce Password History	24 remembered	This setting prevents the user using the same password twice for the period of passwords specified. In this case once the user has changed their password 24 times they can re-use the password again. This is the previous 24 passwords remembered – so once they hit 24 password changes, it starts back at 1 again, so they could re-use their first password they used, but not the 2nd 3rd or 4th and so on.
Maximum password age	42 days	This setting expires the password automatically after x amount of days. In this case a users password can not be valid for longer than 42 days.
Minimum password age	1 day	This is the minimum password age setting. This prevents a user changing their password too often. In this case if a user changes their password, they can not change their password again for another day. This setting is just for user based changed, Active Directory administrators, through ADUC can still change a user password more frequently.
Minimum password length	7 characters	This is how many characters the password must contain as a minimum. In this case the password must be at least 7 characters long.
Password must meet complexity requirements	Enabled	If this setting is enabled the password must conform to certain requirements. This means is can not be the username or part of the users full name that exceed two consecutive characters. It must be at least 6 characters in length (this is overwritten by the minimum password length if the minimum password length is more than 6. ) It must contain at least one character from three of the following four categories: English upper case (A to Z), English lowercase (a through z) A numerical digit (0 through 9), non alphabetical characters such as $ % #)
Store password using reversible encryption	Disabled	This setting should never be enabled. It effectively stores your password in plain text. The only use for this is if you have applications that require this – but even then, you should force the application vendor to upgrade their software or find an alternative..

So the original password we set in AD for Joe Bloggs was Password1 – this meets the minimum requirements as it needed to be 7 character long, its 9, and it needed to be complex – it contains a capital letter, lower case letters, and a number.

If we try and change the password to just Password we receive an error

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb23.png

since we don’t meet the password policy requirements. So if we change it to Password@ this works as the it meets the requirements.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb24.png

Joe now decides he no longer like the password with the @ symbol and he wants to change it to Password2

From the CTRL-ALT-DEL screen Joe clicks Change a password and types in his current password (Password@) and his new password (Password2)

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb25.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb26.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb27.png

Again we get the same error and we can’t change the password. Why? Because of the password policy stating that the password must be at least one day old before it can be changed.

So, so far we have covered the basics of the password policy. Now lets delve a little deeper and take a look at how this password policy applies, and why we can only have one password policy.

Where does the password policy apply?

So far we have talked about the password policy and how it affects users changing their passwords. But is the policy applying to user accounts or computers? This is sometimes a little confusing as the password policy is actually applying to computers, not users. We know this because if we look where the password policy settings are in the group policy they are within the computer section of the policy template, not the user section. The computers affected by this policy are your domain controllers. Why, because your user accounts are stored within the Active Directory database held on your domain controllers. So when you are changing a password the change is taking place on the domain controller. The policy is also applying to your own client computer but this is affecting your local computer accounts rather than your AD accounts. We can prove this and see the impact of various changes through another example.

We are going to create a new password policy in our domain. This policy is then going to be linked to three OU’s – Contoso Users, Contoso Computers and Domain Controllers.

The only difference in the password policy we are going to set is the minimum password length, we are going to increase this from 7 to 10 characters.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb28.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb29.png

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb30.png

Lets start by running GPUPDATE /Force on the client computer and our domain controller. And then we can check to make sure the ‘New Password Policy’ has applied

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb31.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb32.png

Now what happens when we try and change the password. Remember we have created a new policy with the password settings making the minimum password length 10 characters. We are going to set Joe.Bloggs password to Password3 which is only 9 characters long.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb33.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb34.png

We can see this was a successful password change – but how since we created a new policy saying the password needed to be at least 10 characters long?

As we have previously mentioned, only one password group policy can exist per domain. This policy needs to be linked at the Domain level and have the highest processing order. We will see this in our next example. But for now lets see what this new policy has just done.

We are going to create a local user account called Contoso-Local-User on the Windows 8 workstation. We will attempt to set the password to Password1

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb35.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb36.png

As you can see we are unable to set the password because it doesn’t meet the requirements for the password policy. We will try and set the password to Password123

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb37.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb38.png

We have now successfully created the user account. We now understand that when we have multiple password policies, any policy which is not at the highest domain level will only affect local user accounts and the workstations and servers the policy applies on.

I have now linked the ‘New Password Policy’’ to the domain level, and moved the link order to 1. We will see what happens when we set the password to Password4 (only 9 characters) for the joe.bloggs domain account.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb39.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb40.png

The ‘new password policy’ has taken effect and the password count now must be a minimum of ten characters. Remember that the policy must have applied to your Domain Controllers to take effect.

Blocking the password policy

In group policy we have the option to block policies from applying to certain OU’s. We need to understand the impact of blocking policy inheritance on the domain controllers OU.

So on the Domain Controllers OU I have blocked policy inheritance, so the only domain policy being applied is the Default Domain Controllers Policy. Neither the New Password Policy of Default Domain Policy are enforced.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb41.png

I will write about group policy processing in more detail in separate post, but for now we just need to be concerned with the fact that when blocked inheritance is enabled on an OU any non-enforced group policy will not apply. So in theory the password policy shouldn’t apply and users wouldn’t need to set a password following any password requirements. If we test this theory we can see what really happens.

First we force a GPUPDATE on the Domain Controller.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb42.png

Then we run gpresult /r /scope:computer /v to get a verbose output of the computer settings applied to the domain controller.

We can see the new password policy and default domain policy haven’t been applied due to filtering (blocked inheritance)

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb43.png

So what happens when we go back to our client computer and try and change Joe.Bloggs password. We are going to try and change it to the word password.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb44.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb45.png

Why is this? The password policy isn’t applied, yet the restrictions are still in place. Take a look at my blog post on FSMO roles and read up on the PDC role.

Having multiple password policies

So you need to have different password policies for different users. We now know that we can only have one domain based password policy set by group policy, so what’s the answer? Fine Grained Password Policies come to the rescue.

Fine Grained Password Policies (FGPP) were introduced with Windows Server 2008 Active Directory. To take benefit of FGPP you need to get your domain up to at least a 2008 domain functional level. FGPP settings are stored in a new type of object known as a password setting object, or PSO for short. Whilst you can create these new objects before your domain is at 2008 DFL they will have no impact on your users. Introducing a 2008 or higher DC to your domain extended the schema to contain a new class known as msDS-PasswordSettings. If you are unfamiliar with how the schema works or what it is take a look at my previous article here.

PSOs can be applied to either users or global security groups. A single PSO can be applied to multiple users and groups, And a user or group can have multiple PSOs assigned to it. Each PSO has a forward-link attribute msDS-PSOAppliesTo that links back to a group or user. In turn each user and group has a respective back-link attribute msDS-PSOApplied to the PSO. Each PSO also has a priority attribute. The lower the priority number(1 – 2,147,483,646) the higher the policy precedence. You should ideally create unique priority values for you polices, although nothing is stopping you creating multiple PSO with the same priority order. If this does happen, the lowest calculated GUID on the PSO will win. The priority is stored within the msDS-PasswordSettingsPrecedence attribute on the PSO. One more important attribute exists, msDS-ResultantPSO. This isn’t a normal attribute, rather its a constructed attribute which means it is automatically generated when queried, you can’t actually manually query this through an LDAP filter though.

There are a number of ways to create PSOs: Active Directory Administrative Centre, PSOMgr by Joeware and ADSI Edit and PowerShell. Lets go ahead and create a PSO object and apply it to a user. We are going to do this with the Active Directory Administrative Centre – the simplest method to create a PSO. Since this was only made available to us with the Administrative Centre provided with Windows 8 and Server 2012 I will also show how to configure the same policy through ADSI Edit.

Launch Active Directory Administrate Centre from Server 2012 or Windows 8, and expand the tree selecting password settings. From the tasks menu select New > Password Settings

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb46.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb47.png

You can now setup your password policy. You will notice the options are the same as in the group policy method mentioned above. There is an additional option which is the Precedence, we discussed this earlier. I’ve applied the PSO to Joe.Bloggs by selecting Add under Directly Applies To and selecting him from the AD Search window. You could also select a global security group here though.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb48.png

If we take a look at Joe Bloggs account through the attribute editor we can see the msDS-PSOObjectApplied attribute is now populated with the name of our PSO. You need to ensure your filter is set to show back-links otherwise you will not see the attribute.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb49.png

The ADAC has created a new active directory object called a PSO and created it in the CN=Password Settings Container,CN=System,DC=Contoso,DC=int container. We can see the object through ADSI Edit

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb50.png 

Working with PSO in your environment

My preferred method of applying password policies is through Active Directory Global Security Groups. For each PSO I have one group. I then apply the PSO to the group and add users or other groups into this group. As we previously talked about you can apply multiple PSO objects to the same user / group. When this occurs, the PSO with the highest precedence (lowest priority number) wins. If they are the same the GUID is used to calculate which PSO to apply.

If you want to check what password policy will apply to that user you can do so quite easily through ADAC. Simply locate the user account, right click and select View resultant password settings.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb51.png

Summary

We have learned that only one password policy applied through group policy can affect our domain user accounts. This policy must be applied at the domain level, and must have the highest priority processing order. Any other password policy configured through group policy will only apply to local user accounts on computers and servers. To give us more flexibility Microsoft introduced fine grained password policies. These allow us to create multiple password settings for different users and groups of users without the need for 3rd party software or creating a new domain. Configuring PSO has been made very easy when using Windows 8 or Server 2012 Active Directory Administrative Center.