AWS Directory Service
Administration Guide (Version 1.0)

Best Practices for AWS Managed Microsoft AD

Here are some suggestions and guidelines you should consider to avoid problems and get the most out of AWS Managed Microsoft AD.

Setting Up: Prerequisites

Consider these guidelines before creating your directory.

Verify You Have the Right Directory Type

AWS Directory Service provides multiple ways to use Microsoft Active Directory with other AWS services. You can choose the directory service with the features you need at a cost that fits your budget:

  • AWS Directory Service for Microsoft Active Directory is a feature-rich managed Microsoft Active Directory hosted on the AWS cloud. AWS Managed Microsoft AD is your best choice if you have more than 5,000 users and need a trust relationship set up between an AWS hosted directory and your on-premises directories.

  • AD Connector simply connects your existing on-premises Active Directory to AWS. AD Connector is your best choice when you want to use your existing on-premises directory with AWS services.

  • Simple AD is an inexpensive Active Directory–compatible service with the common directory features. In most cases, Simple AD is the least expensive option and your best choice if you have 5,000 or fewer users and don’t need the more advanced Microsoft Active Directory features.

For a more detailed comparison of AWS Directory Service options, see Which to Choose.

Ensure Your VPCs and Instances are Configured Correctly

In order to connect to, manage, and use your directories, you must properly configure the VPCs that the directories are associated with. See either AWS Managed Microsoft AD Prerequisites, AD Connector Prerequisites, or Simple AD Prerequisites for information about the VPC security and networking requirements.

If you are adding an instance to your domain, ensure that you have connectivity and remote access to your instance as described in Join an EC2 Instance to Your AWS Managed Microsoft AD Directory.

Be Aware of Your Limits

Learn about the various limits for your specific directory type. The available storage and the aggregate size of your objects are the only limitations on the number of objects you may store in your directory. See either Limits for AWS Managed Microsoft AD, Limits for AD Connector, or Limits for Simple AD for details about your chosen directory.

Understand Your Directory’s AWS Security Group Configuration and Use

AWS creates a security group and attaches it to your directory’s domain controller elastic network interfaces. This security group blocks unnecessary traffic to the domain controller and allows traffic that is necessary for Active Directory communications. AWS configures the security group to open only the ports that are required for Active Directory communications. In the default configuration, the security group accepts traffic to these ports from any IP address. AWS attaches the security group to your domain controllers’ interfaces that are accessible from within your peered or resized VPCs. These interfaces are inaccessible from the internet even if you modify routing tables, change the network connections to your VPC, and configure the NAT Gateway service. As such, only instances and computers that have a network path into the VPC can access the directory. This simplifies setup by eliminating the requirement for you to configure specific address ranges. Instead, you configure routes and security groups into the VPC that permit traffic only from trusted instances and computers.

Modifying the Directory Security Group

If you want to increase the security of your directories’ security groups, you can modify them to accept traffic from a more restrictive list of IP addresses. For example, you could change the accepted addresses from 0.0.0.0/0 to a CIDR range that is specific to a single subnet or computer. Similarly, you might choose to restrict the destination addresses to which your domain controllers can communicate. Make such changes only if you fully understand how security group filtering works. For more information, see Amazon EC2 Security Groups for Linux Instances in the Amazon EC2 User Guide. Improper changes can result in loss of communications to intended computers and instances. AWS recommends that you do not attempt to open additional ports to the domain controller as this decreases the security of your directory. Please carefully review the AWS Shared Responsibility Model.

Warning

It is technically possible for you to associate the security groups, which your directory uses, with other EC2 instances that you create. However, AWS recommends against this practice. AWS may have reasons to modify the security group without notice to address functional or security needs of the managed directory. Such changes affect any instances with which you associate the directory security group. Furthermore, associating the directory security group with your EC2 instances creates a potential security risk for your EC2 instances. The directory security group accepts traffic on required Active Directory ports from any IP address. If you associate this Security Group with an EC2 instance that has a public IP address attached to the internet, then any computer on the internet can communicate with your EC2 instance on the opened ports.

Setting Up: Creating Your Directory

Here are some suggestions to consider as you create your directory.

Remember Your Administrator ID and Password

When you set up your directory, you provide a password for the administrator account. That account ID is Admin for AWS Managed Microsoft AD. Remember the password that you create for this account; otherwise you will not be able to add objects to your directory.

Create a DHCP Options Set

We recommend that you create a DHCP options set for your AWS Directory Service directory and assign the DHCP options set to the VPC that your directory is in. That way any instances in that VPC can point to the specified domain, and DNS servers can resolve their domain names.

For more information about DHCP options sets, see Create a DHCP Options Set.

Understand Username Restrictions for AWS Applications

AWS Directory Service provides support for most character formats that can be used in the construction of usernames. However, there are character restrictions that are enforced on usernames that will be used for signing in to AWS applications, such as Amazon WorkSpaces, Amazon WorkDocs, Amazon WorkMail, or Amazon QuickSight. These restrictions require that the following characters not be used:

  • Spaces

  • !"#$%&'()*+,/:;<=>?@[\]^`{|}~

Note

The @ symbol is allowed as long as it precedes a UPN suffix.

Using Your Directory

Here are some suggestions to keep in mind when using your directory.

Do Not Alter Predefined Users, Groups and Organization Units

When you use AWS Directory Service to launch a directory, AWS creates an organizational unit (OU) that contains all your directory’s objects. This OU, which has the NetBIOS name that you typed when you created your directory, is located in the domain root. The domain root is owned and managed by AWS. Several groups and an administrative user are also created.

Do not move, delete or in any other way alter these predefined objects. Doing so can make your directory inaccessible by both yourself and AWS. For more information, see What Gets Created.

Automatically Join Domains

When launching a Windows instance that is to be part of an AWS Directory Service domain, it is often easiest to join the domain as part of the instance creation process rather than manually adding the instance later. To automatically join a domain, simply select the correct directory for Domain join directory when launching a new instance. You can find details in Seamlessly Join a Windows EC2 Instance.

Set Up Trusts Correctly

When setting up trust relationship between your AWS Managed Microsoft AD directory and another directory, keep in mind these guidelines:

  • Both trusts must be forest trusts.

  • Both fully qualified domain names (FQDNs) must be unique.

  • If adding a NetBIOS name, that should also be unique.

For more details and specific instructions on setting up a trust relationship, see When to Create a Trust Relationship.

Managing Your Directory

Consider these suggestions for managing your directory.

Carefully Plan For Schema Extensions

Thoughtfully apply schema extensions to index your directory for important and frequent queries. Use care to not over-index the directory as indexes consume directory space and rapidly changing indexed values can result in performance problems. To add indexes, you must create a Lightweight Directory Access Protocol (LDAP) Directory Interchange Format (LDIF) file and extend your schema change. For more information, see Extend Your Schema.

About Load Balancers

Do not use a load balancer in front of the AWS Managed Microsoft AD end-points. Microsoft designed Active Directory (AD) for use with a domain controller (DC) discovery algorithm that finds the most responsive operational DC without external load balancing. External network load balancers inaccurately detect active DCs and can result in your application being sent to a DC that is coming up but not ready for use. For more information, see Load balancers and Active Directory on Microsoft TechNet which recommends fixing applications to use AD correctly rather than implementing external load balancers.

Make a Backup of Your Instance

If you decide to manually add an instance to an existing AWS Directory Service domain, make a backup or take a snapshot of that instance first. This is particularly important when joining a Linux instance. Some of the procedures used to add an instance, if not performed correctly, can render your instance unreachable or unusable. For more information, see Snapshot or Restore Your Directory.

Set Up SNS Messaging

With Amazon Simple Notification Service (Amazon SNS), you can receive email or text (SMS) messages when the status of your directory changes. You will be notified if your directory goes from an Active status to an Impaired or Inoperable status. You also receive a notification when the directory returns to an Active status.

Also remember that if you have an SNS topic that receives messages from AWS Directory Service, before deleting that topic from the Amazon SNS console, you should associate your directory with a different SNS topic. Otherwise you risk missing important directory status messages. For information about how to set up Amazon SNS, see Configure Directory Status Notifications.

Remove Amazon Enterprise Applications Before Deleting a Directory

Before deleting a directory that is associated with one or more Amazon Enterprise Applications such as, Amazon WorkSpaces, Amazon WorkSpaces Application Manager, Amazon WorkDocs, Amazon WorkMail, AWS Management Console, or Amazon Relational Database Service (Amazon RDS), you must first remove each application. For more information how to remove these applications, see Delete Your Directory.

Programming Your Applications

Before you program your applications, consider the following:

Use the Windows DC Locator Service

When developing applications, use the Windows DC locator service or use the Dynamic DNS (DDNS) service of your AWS Managed Microsoft AD to locate domain controllers (DCs). Do not hard code applications with the address of a DC. The DC locator service helps ensure directory load is distributed and enables you to take advantage of horizontal scaling by adding domain controllers to your deployment. If you bind your application to a fixed DC and the DC undergoes patching or recovery, your application will lose access to the DC instead of using one of the remaining DCs. Furthermore, hard coding of the DC can result in hot spotting on a single DC. In severe cases, hot spotting may cause your DC to become unresponsive. Such cases may also cause AWS directory automation to flag the directory as impaired and may trigger recovery processes that replace the unresponsive DC.

Load Test Before Rolling Out to Production

Be sure to do lab testing with objects and requests that are representative of your production workload to confirm that the directory scales to the load of your application. Should you require additional capacity, test with additional DCs while distributing requests between the DCs. For more information, see Deploy Additional Domain Controllers.

Use Efficient LDAP Queries

Broad LDAP queries to a domain controller across tens of thousands of objects can consume significant CPU cycles in a single DC, resulting in hot spotting. This may affect applications that share the same DC during the query.