How to Configure Even Stronger Password Policies to Help Meet Your Security Standards by Using AWS Directory Service for Microsoft Active Directory
With AWS Directory Service for Microsoft Active Directory (Enterprise Edition), also known as AWS Microsoft AD, you can now create and enforce custom password policies for your Microsoft Windows users. AWS Microsoft AD now includes five empty password policies that you can edit and apply with standard Microsoft password policy tools such as Active Directory Administrative Center (ADAC). With this capability, you are no longer limited to the default Windows password policy. Now, you can configure even stronger password policies and define lockout policies that specify when to lock out an account after login failures.
In this blog post, I demonstrate how to edit these new password policies to help you meet your security standards by using AWS Microsoft AD. I also introduce the password attributes you can modify and demonstrate how to apply password policies to user groups in your domain.
The instructions in this post assume that you already have the following components running:
- An active AWS Microsoft AD directory.
- An Amazon EC2 for Windows Server instance that is domain joined to your AWS Microsoft AD directory and on which you have installed ADAC.
If you still need to meet these prerequisites before proceeding:
- For information about how to deploy AWS Microsoft AD, see How to Create a Microsoft AD directory.
- To join an EC2 for Windows Server instance to your AWS Microsoft AD domain on which you run ADAC, see Manually Add a Windows Instance.
- Follow the steps in Installing the Active Directory Administration Tools to install Active Directory Administration Tools on your EC2 for Windows Server instance.
Let’s say I am the Active Directory (AD) administrator of Example Corp. At Example Corp., we have a group of technical administrators, several groups of senior managers, and general, nontechnical employees. I need to create password policies for these groups that match our security standards.
Our general employees have access only to low-sensitivity information. However, our senior managers regularly access confidential information and we want to enforce password complexity (a mix of upper and lower case letters, numbers, and special characters) to reduce the risk of data theft. For our administrators, we want to enforce password complexity policies to prevent unauthorized access to our system administration tools.
Our security standards call for the following enforced password and account lockout policies:
- General employees – To make it easier for nontechnical general employees to remember their passwords, we do not enforce password complexity. However, we want to enforce a minimum password length of 8 characters and a lockout policy after 6 failed login attempts as a minimum bar to protect against unwanted access to our low-sensitivity information. If a general employee forgets their password and becomes locked out, we let them try again in 5 minutes, rather than require escalated password resets. We also want general employees to rotate their passwords every 60 days with no duplicated passwords in the past 10 password changes.
- Senior managers – For senior managers, we enforce a minimum password length of 10 characters and require password complexity. An account lockout is enforced after 6 failed attempts with an account lockout duration of 15 minutes. Senior managers must rotate their passwords every 45 days, and they cannot duplicate passwords from the past 20 changes.
- Administrators – For administrators, we enforce password complexity with a minimum password length of 15 characters. We also want to lock out accounts after 6 failed attempts, have password rotation every 30 days, and disallow duplicate passwords in the past 30 changes. When a lockout occurs, we require a special administrator to intervene and unlock the account so that we can be aware of any potential hacking.
- Fine-Grained Password Policy administrators – To ensure that only trusted administrators unlock accounts, we have two special administrator accounts (admin and midas) that can unlock accounts. These two accounts have the same policy as the other administrators except they have an account lockout duration of 15 minutes, rather than requiring a password reset. These two accounts are also the accounts used to manage Example Corp.’s password policies.
The following table summarizes how I edit each of the four policies I intend to use.
|User group||Fine-Grained Password Policy Administrators||Other Administrators||Senior Managers||General Employees|
|Minimum password length||15||15||10||8|
|Maximum password age||30 days||30 days||45 days||60 days|
|Number of failed logon attempts allowed||6||6||6||6|
|Duration||15 minutes||Not applicable||15 minutes||5 minutes|
|Until admin manually unlocks account||Not applicable||Selected||Not applicable||Not applicable|
To implement these password policies, I use 4 of the 5 new password policies available in AWS Microsoft AD:
- I first explain how to configure the password policies.
- I then demonstrate how to apply the four password policies that match Example Corp.’s security standards for these user groups.
1. Configure password policies in AWS Microsoft AD
To help you get started with password policies, AWS has added the Fine-Grained Pwd Policy Admins AD security group to your AWS Microsoft AD directory. Any user or other security group that is part of the Fine-Grained Pwd Policy Admins group has permissions to edit and apply the five new password policies. By default, your directory Admin is part of the new group and can add other users or groups to this group.
Adding users to the Fine-Grained Pwd Policy Admins user group
Follow these steps to add more users or AD security groups to the Fine-Grained Pwd Policy Admins security group so that they can administer fine-grained password policies:
- Launch ADAC from your managed instance.
- Switch to the Tree View and navigate to CORP > Users.
- Find the Fine Grained Pwd Policy Admins user group. Add any users or groups in your domain to this group.
Edit password policies
To edit fine-grained password policies, open ADAC from any management instance joined to your domain. Switch to the Tree View and navigate to System > Password Settings Container. You will see the five policies containing the string -PSO- that AWS added to your directory, as shown in the following screenshot. Select a policy to edit it.
After editing the password policy, apply the policy by adding users or AD security groups to these policies by choosing Add. The default domain GPO applies if you do not configure any of the five password policies. For additional details about using Password Settings Container, go to Step-by-Step: Enabling and Using Fine-Grained Password Policies in AD on the Microsoft TechNet Blog.
The password attributes you can edit
AWS allows you to edit all of the password attributes except Precedence (I explain more about Precedence in the next section). These attributes include:
- Password history
- Minimum password length
- Minimum password age
- Maximum password age
- Store password using reversible encryption
- Password must meet complexity requirements
You also can enforce the following attributes for account lockout settings:
- The number of failed login attempts allowed
- Account lockout duration
- Reset failed login attempts after a specified duration
For more details about how these attributes affect password enforcement, see AD DS: Fine-Grained Password Policies on Microsoft TechNet.
Understanding password policy precedence
AD password policies have a precedence (a numerical attribute that AD uses to determine the resultant policy) associated with them. Policies with a lower value for Precedence have higher priority than other policies. A user inherits all policies that you apply directly to the user or to any groups to which the user belongs. For example, suppose jsmith is a member of the HR group and also a member of the MANAGERS group. If I apply a policy with a Precedence of 50 to the HR group and a policy with a Precedence of 40 to MANAGERS, the policy with the Precedence value of 40 ranks higher and AD applies that policy to jsmith.
If you apply multiple policies to a user or group, the resultant policy is determined as follows by AD:
- If you apply a policy directly to a user, AD enforces the lowest directly applied password policy.
- If you did not apply a policy directly to the user, AD enforces the policy with the lowest Precedence value of all policies inherited by the user through the user’s group membership.
For more information about AD fine-grained policies, see AD DS: Fine-Grained Password Policies on Microsoft TechNet.
2. Apply password policies to user groups
In this section, I demonstrate how to apply Example Corp.’s password policies. Except in rare cases, I only apply policies by group membership, which ensures that AD does not enforce a lower priority policy on an individual user if have I added them to a group with a higher priority policy.
Because my directory is new, I use a Remote Desktop Protocol (RDP) connection to sign in to the Windows Server instance I domain joined to my AWS Microsoft AD directory. Signing in with the admin account, I launch ADAC to perform the following tasks:
- First, I set up my groups so that I can apply password policies to them. Later, I can create user accounts and add them to my groups and AD applies the right policy by using the policy precedence and resultant policy algorithms I discussed previously. I start by adding the two special administrative accounts (admin and midas) that I described previously to the Fine-Grained Pwd Policy Admins. Because AWS Microsoft AD adds my default admin account to Fine-Grained Pwd Policy Admins, I only need to create midas and then add midas to the Fine-Grained Pwd Policy Admins group.
- Next, I create the Other Administrators, Senior Managers, and General Employees groups that I described previously, as shown in the following screenshot.
For this post’s example, I use these four policies:
- EXAMPLE-PSO-01 (highest priority policy) – For the administrators who manage Example Corp.’s password policies. Applying this highest priority policy to the Fine-Grained Pwd Policy Admins group prevents these users from being locked out if they also are assigned to a different policy.
- EXAMPLE-PSO-02 (the second highest priority policy) – For Example Corp.’s other administrators.
- EXAMPLE-PSO-03 (the third highest priority policy) – For Example Corp.’s senior managers.
- EXAMPLE-PSO-05 (the lowest priority policy) – For Example Corp.’s general employees.
This leaves me one password policy (EXAMPLE-PSO-04) that I can use for in the future if needed.
I start by editing the policy, EXAMPLE-PSO-01. To edit the policy, I follow the Edit password policies section from earlier in this post. When finished, I add the Fine-Grained Pwd Policy Admins group to that policy, as shown in the following screenshot. I then repeat the process for each of the remaining policies, as described in the Scenario overview section earlier in this post.
Though AD enforces new password policies, the timing related to how password policies replicate in the directory, the types of attributes that are changed, and the timing of user password changes can cause variability in the immediacy of policy enforcement. In general, after the policies are replicated throughout the directory, attributes that affect account lockout and password age take effect. Attributes that affect the quality of a password, such as password length, take effect when the password is changed. If the password age for a user is in compliance, but their password strength is out of compliance, the user is not forced to change their password. For more information password policy impact, see this Microsoft TechNet article.
In this post, I have demonstrated how you can configure strong password policies to meet your security standards by using AWS Microsoft AD. To learn more about AWS Microsoft AD, see the AWS Directory Service home page.
If you have comments about this post, submit them in the “Comments” section below. If you have questions about this blog post, start a new thread on the Directory Service forum.