

# AD Connector
<a name="directory_ad_connector"></a>

AD Connector is a directory gateway with which you can redirect directory requests to your on-premises Microsoft Active Directory without caching any information in the cloud. AD Connector comes in two sizes, small and large. A small AD Connector is designed for smaller organizations and is intended to handle a low number of operations per second. A large AD Connector is designed for larger organizations and is intended to handle a moderate to high number of operations per second. You can spread application loads across multiple AD Connectors to scale to your performance needs. There are no enforced user or connection limits. 

AD Connector does not support Active Directory transitive trusts. AD Connectors and your on-premises Active Directory domains have a 1-to-1 relationship. That is, for each on-premises domain, including child domains in an Active Directory forest that you want to authenticate against, you must create a unique AD Connector.

**Note**  
AD Connector cannot be shared with other AWS accounts. If this is a requirement, consider using AWS Managed Microsoft AD to [Share your AWS Managed Microsoft AD](ms_ad_directory_sharing.md). AD Connector is also not multi-VPC aware, which means that AWS applications like [WorkSpaces](https://aws.amazon.com/workspaces) are required to be provisioned into the same VPC as your AD Connector.

Once set up, AD Connector offers the following benefits:
+ Your end users and IT administrators can use their existing corporate credentials to log on to AWS applications such as WorkSpaces, WorkDocs, or Amazon WorkMail.
+ You can manage AWS resources like Amazon EC2 instances or Amazon S3 buckets through IAM role-based access to the AWS Management Console.
+ You can consistently enforce existing security policies (such as password expiration, password history, and account lockouts) whether users or IT administrators are accessing resources in your on-premises infrastructure or in the AWS Cloud.
+ You can use AD Connector to enable multi-factor authentication by integrating with your existing RADIUS-based MFA infrastructure to provide an additional layer of security when users access AWS applications.

Continue reading the topics in this section to learn how to connect to a directory and make the most of AD Connector features.

**Topics**
+ [Getting started with AD Connector](ad_connector_getting_started.md)
+ [Best practices for AD Connector](ad_connector_best_practices.md)
+ [Maintain your AD Connector directory](ad_connector_maintain.md)
+ [Secure your AD Connector directory](ad_connector_security.md)
+ [Monitor your AD Connector directory](ad_connector_monitor.md)
+ [Access to AWS applications and services from AD Connector](ad_connector_manage_apps_services.md)
+ [Ways to join an Amazon EC2 instance to your Active Directory](ad_connector_join_instance.md)
+ [AD Connector quotas](ad_connector_limits.md)
+ [Troubleshooting AD Connector](ad_connector_troubleshooting.md)

# Getting started with AD Connector
<a name="ad_connector_getting_started"></a>

With AD Connector you can connect Directory Service to your existing enterprise Active Directory. When connected to your existing directory, all of your directory data remains on your domain controllers. Directory Service does not replicate any of your directory data.

**Topics**
+ [AD Connector prerequisites](#prereq_connector)
+ [Create an AD Connector](#create_ad_connector)
+ [What gets created with your AD Connector](create_details_ad_connector.md)

## AD Connector prerequisites
<a name="prereq_connector"></a>

To connect to your existing directory with AD Connector, you need the following:

**Amazon VPC**  
Set up a VPC with the following:  
+ At least two subnets. Each of the subnets must be in a different Availability Zone and must be of same network type.

  You can use IPv6 for your VPC. For more information, see [IPv6 support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) in the *Amazon Virtual Private Cloud User Guide*.
+ The VPC must be connected to your existing network through a virtual private network (VPN) connection or Direct Connect.
+ The VPC must have default hardware tenancy.
Directory Service uses a two VPC structure. The EC2 instances which make up your directory run outside of your AWS account, and are managed by AWS. They have two network adapters, `ETH0` and `ETH1`. `ETH0` is the management adapter, and exists outside of your account. `ETH1` is created within your account.   
The management IP range of your directory's `ETH0` network is chosen programmatically to ensure it does not conflict with the VPC where your directory is deployed. This IP range can be in either of the following pairs (as Directories run in two subnets):  
+ 10.0.1.0/24 & 10.0.2.0/24 
+ 169.254.0.0/16
+ 192.168.1.0/24 & 192.168.2.0/24 
We avoid conflicts by checking the first octet of the `ETH1` CIDR. If it starts with a 10, then we choose a 192.168.0.0/16 VPC with 192.168.1.0/24 and 192.168.2.0/24 subnets. If the first octet is anything else other than a 10 we choose a 10.0.0.0/16 VPC with 10.0.1.0/24 and 10.0.2.0/24 subnets.   
The selection algorithm does not include routes on your VPC. It is therefore possible to have an IP routing conflict result from this scenario.   
For more information, see the following topics in the *Amazon VPC User Guide*:  
+ [What is Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Introduction.html)
+ [Subnets in your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPCSubnet)
+ [Adding a Hardware Virtual Private Gateway to Your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_VPN.html)
For more information about AWS Direct Connect, see the [AWS Direct Connect User Guide](https://docs.aws.amazon.com/directconnect/latest/UserGuide/).

**Existing Active Directory**  
You will need to connect to an existing network with an Active Directory domain.  
AD Connector does not support [Single Label Domains](https://support.microsoft.com/en-us/help/2269810/microsoft-support-for-single-label-domains).
The functional level of this Active Directory domain must be `Windows Server 2003` or higher. AD Connector also supports connecting to a domain hosted on an Amazon EC2 instance.  
AD Connector does not support Read-only domain controllers (RODC) when used in combination with the Amazon EC2 domain-join feature. 

**Service account**  
You must have credentials for a service account in the existing directory which has been delegated the following privileges:  
+ Read users and groups - Required
+ Join computers to the domain - Required only when using Seamless Domain Join and WorkSpaces
+ Create computer objects - Required only when using Seamless Domain Join and WorkSpaces
+ The service account password should be compliant with AWS password requirements. AWS passwords should be:
  + Between 8 and 128 characters in length, inclusive. 
  + Contain at least one character from three of the following four categories:
    + Lowercase letters (a-z)
    + Uppercase letters (A-Z)
    + Numbers (0-9)
    + Non-alphanumeric characters (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)
For more information, see [Delegate privileges to your service account](#connect_delegate_privileges).   
AD Connector uses Kerberos for authentication and authorization of AWS applications. LDAP is only used for user and group object lookups (read operations). With the LDAP transactions, nothing is mutable and credentials are not passed in clear text. Authentication is handled by an AWS internal service, which uses Kerberos tickets to perform LDAP operations as a user.

**User permissions**  
All Active Directory users must have permissions to read their own attributes. Specifically the following attributes:  
+ GivenName
+ SurName
+ Mail
+ SamAccountName
+ UserPrincipalName
+ UserAccountControl
+ MemberOf
By default, Active Directory users do have read permission to these attributes. However, Administrators can alter these permissions over time so you might want to verify your users have these read permissions prior to setting up AD Connector for the first time.

**IP addresses**  
Get the IP addresses of two DNS servers or domain controllers in your existing directory.  
AD Connector obtains the `_ldap._tcp.<DnsDomainName>` and `_kerberos._tcp.<DnsDomainName>` SRV records from these servers when connecting to your directory, so these servers must contain these SRV records. The AD Connector attempts to find a common domain controller that will provide both LDAP and Kerberos services, so these SRV records must include at least one common domain controller. For more information about SRV records, go to [SRV Resource Records](http://technet.microsoft.com/en-us/library/cc961719.aspx) on Microsoft TechNet.

**Ports for subnets**  
For AD Connector to redirect directory requests to your existing Active Directory domain controllers, the firewall for your existing network must have the following ports open to the CIDRs for both subnets in your Amazon VPC.  
+ TCP/UDP 53 - DNS
+ TCP/UDP 88 - Kerberos authentication
+ TCP/UDP 389 - LDAP
These are the minimum ports that are needed before AD Connector can connect to your directory. Your specific configuration may require additional ports be open.  
If you want to use AD Connector and Amazon WorkSpaces, the DisableVLVSupportLDAP attribute needs to be set to 0 for your domain controllers. This is the default setting for the domain controllers. AD Connector will be unable to query users in the directory if the DisableVLVSupportLDAP attribute is enabled. This prevents AD Connector from working with Amazon WorkSpaces.  
If the DNS servers or Domain Controller servers for your existing Active Directory Domain are within the VPC, the security groups associated with those servers must have the above ports open to the CIDRs for both subnets in the VPC. 
For additional port requirements, see [AD and AD DS Port Requirements](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772723(v=ws.10)) on Microsoft documentation.

**Kerberos preauthentication**  
Your user accounts must have Kerberos preauthentication enabled. For detailed instructions on how to enable this setting, see [Ensure that Kerberos pre-authentication is enabled](ms_ad_tutorial_setup_trust_prepare_onprem.md#tutorial_setup_trust_enable_kerberos). For general information about this setting, go to [Preauthentication](http://technet.microsoft.com/en-us/library/cc961961.aspx) on Microsoft TechNet.

**Encryption types**  
AD Connector supports the following encryption types when authenticating via Kerberos to your Active Directory domain controllers:  
+ AES-256-HMAC
+ AES-128-HMAC
+ RC4-HMAC

### AWS IAM Identity Center prerequisites
<a name="prereq_aws_sso_ad_connector"></a>

If you plan to use IAM Identity Center with AD Connector, you need to ensure that the following are true:
+ Your AD Connector is set up in your AWS organization's management account.
+ Your instance of IAM Identity Center is in the same Region where your AD Connector is set up. 

For more information, see [IAM Identity Center prerequisites](https://docs.aws.amazon.com/singlesignon/latest/userguide/prereqs.html) in the AWS IAM Identity Center User Guide.

### Multi-factor authentication prerequisites
<a name="mfa_prereqs"></a>

To support multi-factor authentication with your AD Connector directory, you need the following:
+ A [Remote Authentication Dial-In User Service](https://en.wikipedia.org/wiki/RADIUS) (RADIUS) server in your existing network that has two client endpoints. The RADIUS client endpoints have the following requirements:
  + To create the endpoints, you need the IP addresses of the Directory Service servers. These IP addresses can be obtained from the **Directory IP Address** field of your directory details. 
  + Both RADIUS endpoints must use the same shared secret code.
+ Your existing network must allow inbound traffic over the default RADIUS server port (1812) from the Directory Service servers.
+ The usernames between your RADIUS server and your existing directory must be identical.

For more information about using AD Connector with MFA, see [Enabling multi-factor authentication for AD Connector](ad_connector_mfa.md). 

### Delegate privileges to your service account
<a name="connect_delegate_privileges"></a>

To connect to your existing directory, you must have the credentials for your AD Connector service account in the existing directory that has been delegated certain privileges. While members of the **Domain Admins** group have sufficient privileges to connect to the directory, as a best practice, you should use a service account that only has the minimum privileges necessary to connect to the directory. The following procedure demonstrates how to create a new group called `Connectors`, delegate the necessary privileges that are needed to connect Directory Service to this group, and then add a new service account to this group. 

This procedure must be performed on a machine that is joined to your directory and has the **Active Directory User and Computers** MMC snap-in installed. You must also be logged in as a domain administrator.

**To delegate privileges to your service account**

1. Open **Active Directory User and Computers** and select your domain root in the navigation tree.

1. In the list in the left-hand pane, right-click **Users**, select **New**, and then select **Group**. 

1. In the **New Object - Group** dialog box, enter the following and click **OK**.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_getting_started.html)

1. In the **Active Directory User and Computers** navigation tree, select identify the Organizational Unit (OU) where the computer accounts will be created. In the menu, select **Action**, and then **Delegate Control**. You may select a parent OU up to the domain as permissions propagate to the child OUs. If your AD Connector is connected to AWS Managed Microsoft AD, you will not have access to delegate control at the domain root level. In this case, to delegate control, select the OU under your directory OU where your computer objects will be created.

1. On the **Delegation of Control Wizard** page, click **Next**, then click **Add**.

1. In the **Select Users, Computers, or Groups** dialog box, enter `Connectors` and click **OK**. If more than one object is found, select the `Connectors` group created above. Click **Next**.

1. On the **Tasks to Delegate** page, select **Create a custom task to delegate**, and then choose **Next**.

1. Select **Only the following objects in the folder**, and then select **Computer objects** and **User objects**.

1. Select **Create selected objects in this folder** and **Delete selected objects in this folder**. Then choose **Next**.  
![\[Delegation of Control Wizard - Only the following objects in the folder, user objects, create selected objects in this folder, and delete selected objects in this folder options are selected.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/aduc_delegate_join_linux.png)

1. Select **Read**, and then choose **Next**.
**Note**  
If you will be using Seamless Domain Join or WorkSpaces, you must also enable **Write** permissions so that the Active Directory can create computer objects.  
![\[Delegation of Control Wizard - Under Show these permissions, general, property-specific, and read are selected.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/aduc_delegate_join_permissions.png)

1. Verify the information on the **Completing the Delegation of Control Wizard** page, and click **Finish**. 

1. Create a user account with a strong password and add that user to the `Connectors` group. This user will be known as your AD Connector service account and since it is now a member of the `Connectors` group it now has sufficient privileges to connect Directory Service to the directory.

### Test your AD Connector
<a name="connect_verification"></a>

For AD Connector to connect to your existing directory, the firewall for your existing network must have certain ports open to the CIDRs for both subnets in the VPC. To test if these conditions are met, perform the following steps:

**To test the connection**

1. Launch a Windows instance in the VPC and connect to it over RDP. The instance must be a member of your existing domain. The remaining steps are performed on this VPC instance.

1. Download and unzip the [DirectoryServicePortTest](samples/DirectoryServicePortTest.zip) test application. The source code and Visual Studio project files are included so you can modify the test application if desired.
**Note**  
This script is not supported on Windows Server 2003 or older operating systems.

1. From a Windows command prompt, run the **DirectoryServicePortTest** test application with the following options:
**Note**  
The DirectoryServicePortTest test application can only be used when the domain and forest functional levels are set to Windows Server 2012 R2 and below.

   ```
   DirectoryServicePortTest.exe -d <domain_name> -ip <server_IP_address> -tcp "53,88,389" -udp "53,88,389"
   ```  
*<domain\$1name>*  
The fully qualified domain name. This is used to test the forest and domain functional levels. If you exclude the domain name, the functional levels won't be tested.  
*<server\$1IP\$1address>*  
The IP address of a domain controller in your existing domain. The ports will be tested against this IP address. If you exclude the IP address, the ports won't be tested.

   This test app determines if the necessary ports are open from the VPC to your domain, and also verifies the minimum forest and domain functional levels.

   The output will be similar to the following:

   ```
   Testing forest functional level.
   Forest Functional Level = Windows2008R2Forest : PASSED
   
   Testing domain functional level.
   Domain Functional Level = Windows2008R2Domain : PASSED
   
   Testing required TCP ports to <server_IP_address>:
   Checking TCP port 53: PASSED
   Checking TCP port 88: PASSED
   Checking TCP port 389: PASSED
   
   Testing required UDP ports to <server_IP_address>:
   Checking UDP port 53: PASSED
   Checking UDP port 88: PASSED
   Checking UDP port 389: PASSED
   ```

The following is the source code for the **DirectoryServicePortTest** application.

```
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading.Tasks;
using System.DirectoryServices.ActiveDirectory;
using System.Threading;
using System.DirectoryServices.AccountManagement;
using System.DirectoryServices;
using System.Security.Authentication;
using System.Security.AccessControl;
using System.Security.Principal;

namespace DirectoryServicePortTest
{
    class Program
    {
        private static List<int> _tcpPorts;
        private static List<int> _udpPorts;

        private static string _domain = "";
        private static IPAddress _ipAddr = null;

        static void Main(string[] args)
        {
            if (ParseArgs(args))
            {
                try
                {
                    if (_domain.Length > 0)
                    {
                        try
                        {
                            TestForestFunctionalLevel();

                            TestDomainFunctionalLevel();
                        }
                        catch (ActiveDirectoryObjectNotFoundException)
                        {
                            Console.WriteLine("The domain {0} could not be found.\n", _domain);
                        }
                    }

                    if (null != _ipAddr)
                    {
                        if (_tcpPorts.Count > 0)
                        {
                            TestTcpPorts(_tcpPorts);
                        }

                        if (_udpPorts.Count > 0)
                        {
                            TestUdpPorts(_udpPorts);
                        }
                    }
                }
                catch (AuthenticationException ex)
                {
                    Console.WriteLine(ex.Message);
                }
            }
            else
            {
                PrintUsage();
            }

            Console.Write("Press <enter> to continue.");
            Console.ReadLine();
        }

        static void PrintUsage()
        {
            string currentApp = Path.GetFileName(System.Reflection.Assembly.GetExecutingAssembly().Location);
            Console.WriteLine("Usage: {0} \n-d <domain> \n-ip \"<server IP address>\" \n[-tcp \"<tcp_port1>,<tcp_port2>,etc\"] \n[-udp \"<udp_port1>,<udp_port2>,etc\"]", currentApp);
        }

        static bool ParseArgs(string[] args)
        {
            bool fReturn = false;
            string ipAddress = "";

            try
            {
                _tcpPorts = new List<int>();
                _udpPorts = new List<int>();

                for (int i = 0; i < args.Length; i++)
                {
                    string arg = args[i];

                    if ("-tcp" == arg | "/tcp" == arg)
                    {
                        i++;
                        string portList = args[i];
                        _tcpPorts = ParsePortList(portList);
                    }

                    if ("-udp" == arg | "/udp" == arg)
                    {
                        i++;
                        string portList = args[i];
                        _udpPorts = ParsePortList(portList);
                    }

                    if ("-d" == arg | "/d" == arg)
                    {
                        i++;
                        _domain = args[i];
                    }

                    if ("-ip" == arg | "/ip" == arg)
                    {
                        i++;
                        ipAddress = args[i];
                    }
                }
            }
            catch (ArgumentOutOfRangeException)
            {
                return false;
            }

            if (_domain.Length > 0 || ipAddress.Length > 0)
            {
                fReturn = true;
            }

            if (ipAddress.Length > 0)
            { 
                _ipAddr = IPAddress.Parse(ipAddress); 
            }
            
            return fReturn;
        }

        static List<int> ParsePortList(string portList)
        {
            List<int> ports = new List<int>();

            char[] separators = {',', ';', ':'};

            string[] portStrings = portList.Split(separators);
            foreach (string portString in portStrings)
            {
                try
                {
                    ports.Add(Convert.ToInt32(portString));
                }
                catch (FormatException)
                {
                }
            }

            return ports;
        }

        static void TestForestFunctionalLevel()
        {
            Console.WriteLine("Testing forest functional level.");

            DirectoryContext dirContext = new DirectoryContext(DirectoryContextType.Forest, _domain, null, null);
            Forest forestContext = Forest.GetForest(dirContext);

            Console.Write("Forest Functional Level = {0} : ", forestContext.ForestMode);

            if (forestContext.ForestMode >= ForestMode.Windows2003Forest)
            {
                Console.WriteLine("PASSED");
            }
            else
            {
                Console.WriteLine("FAILED");
            }

            Console.WriteLine();
        }

        static void TestDomainFunctionalLevel()
        {
            Console.WriteLine("Testing domain functional level.");

            DirectoryContext dirContext = new DirectoryContext(DirectoryContextType.Domain, _domain, null, null);
            Domain domainObject = Domain.GetDomain(dirContext);

            Console.Write("Domain Functional Level = {0} : ", domainObject.DomainMode);

            if (domainObject.DomainMode >= DomainMode.Windows2003Domain)
            {
                Console.WriteLine("PASSED");
            }
            else
            {
                Console.WriteLine("FAILED");
            }

            Console.WriteLine();
        }

        static List<int> TestTcpPorts(List<int> portList)
        {
            Console.WriteLine("Testing TCP ports to {0}:", _ipAddr.ToString());

            List<int> failedPorts = new List<int>();

            foreach (int port in portList)
            {
                Console.Write("Checking TCP port {0}: ", port);

                TcpClient tcpClient = new TcpClient();

                try
                {
                    tcpClient.Connect(_ipAddr, port);

                    tcpClient.Close();
                    Console.WriteLine("PASSED");
                }
                catch (SocketException)
                {
                    failedPorts.Add(port);
                    Console.WriteLine("FAILED");
                }
            }

            Console.WriteLine();

            return failedPorts;
        }

        static List<int> TestUdpPorts(List<int> portList)
        {
            Console.WriteLine("Testing UDP ports to {0}:", _ipAddr.ToString());

            List<int> failedPorts = new List<int>();

            foreach (int port in portList)
            {
                Console.Write("Checking UDP port {0}: ", port);

                UdpClient udpClient = new UdpClient();

                try
                {
                    udpClient.Connect(_ipAddr, port);
                    udpClient.Close();
                    Console.WriteLine("PASSED");
                }
                catch (SocketException)
                {
                    failedPorts.Add(port);
                    Console.WriteLine("FAILED");
                }
            }

            Console.WriteLine();

            return failedPorts;
        }
    }
}
```

## Create an AD Connector
<a name="create_ad_connector"></a>

To connect to your existing directory with AD Connector, perform the following steps. Before starting this procedure, make sure you have completed the prerequisites identified in [AD Connector prerequisites](#prereq_connector).

**Note**  
You cannot create an AD Connector with a Cloud Formation template.

**To connect with AD Connector**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, choose **Directories** and then choose **Set up directory**.

1. On the **Select directory type** page, choose **AD Connector**, and then choose **Next**.

1. On the **Enter AD Connector information** page, provide the following information:  
**Directory size**  
Choose from either the **Small** or **Large** size option. For more information about sizes, see [AD Connector](directory_ad_connector.md).  
**Directory description**  
An optional description for the directory.

1. On the **Choose VPC and subnets** page, provide the following information, and then choose **Next**.  
**VPC**  
The VPC for the directory.  
**Subnets**  
Choose the subnets for the domain controllers. The two subnets must be in different Availability Zones. 

1. On the **Connect to AD** page, provide the following information:  
**Directory DNS name**  
The fully qualified name of your existing directory, such as `corp.example.com`.  
**Directory NetBIOS name**  
The short name of your existing directory, such as `CORP`.  
**DNS IP addresses**  
The IP address of at least one DNS server in your existing directory. These servers must be accessible from each subnet specified in step 4. These servers can be located outside of AWS, as long as there is network connectivity between the specified subnets and the DNS server IP addresses.  
**Service account username**  
The user name of a user in the existing directory. For more information about this account, see the [AD Connector prerequisites](#prereq_connector).  
**Service account password**  
The password for the existing user account. This password is case-sensitive and must be between 8 and 128 characters in length, inclusive. It must also contain at least one character from three of the following four categories:  
   + Lowercase letters (a-z)
   + Uppercase letters (A-Z)
   + Numbers (0-9)
   + Non-alphanumeric characters (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)  
**Confirm password**  
Retype the password for the existing user account.

1. On the **Review & create** page, review the directory information and make any necessary changes. When the information is correct, choose **Create directory**. It takes several minutes for the directory to be created. Once created, the **Status** value changes to **Active**.

For more information on what is created with your AD Connector, see [What gets created with your AD Connector](create_details_ad_connector.md).

# What gets created with your AD Connector
<a name="create_details_ad_connector"></a>

When you create an AD Connector, Directory Service automatically creates and associates an elastic network interface (ENI) with each of your AD Connector instances. Each of these ENIs are essential for connectivity between your VPC and Directory Service AD Connector and should never be deleted. You can identify all network interfaces reserved for use with Directory Service by the description: "AWS created network interface for directory *directory-id*". For more information, see [Elastic Network Interfaces](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) in the Amazon EC2 User Guide.

**Note**  
AD Connector instances are deployed across two Availability Zones in a Region by default and connected to your Amazon Virtual Private Cloud (VPC). AD Connector instances that fail are automatically replaced in the same Availability Zone using the same IP address.

When you sign in to any AWS application or service integrated with an AD Connector (AWS IAM Identity Center included), the app or service forwards your authentication request to AD Connector which then forwards the request to a domain controller in your self-managed Active Directory for authentication. If you are successfully authenticated to your self-managed Active Directory, AD Connector then returns an authentication token to the app or service (similar to a Kerberos token). At this point, you can now access the AWS app or service.

# Best practices for AD Connector
<a name="ad_connector_best_practices"></a>

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

## Setting up: Prerequisites
<a name="ad_connector_best_practices_prereq"></a>

Consider these guidelines before creating your directory.

### Verify you have the right directory type
<a name="choose_right_type"></a>

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 a low-scale, low-cost directory with basic Active Directory compatibility. It supports 5,000 or fewer users, Samba 4–compatible applications, and LDAP compatibility for LDAP-aware applications.

For a more detailed comparison of Directory Service options, see [Which to choose](what_is.md#choosing_an_option).

### Ensure your VPCs and instances are configured correctly
<a name="vpc_config"></a>

In order to connect to, manage, and use your directories, you must properly configure the VPCs that the directories are associated with. See either [Prerequisites for creating a AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_prereqs), [AD Connector prerequisites](ad_connector_getting_started.md#prereq_connector), or [Simple AD prerequisites](simple_ad_getting_started.md#prereq_simple) 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 [Ways to join an Amazon EC2 instance to your AWS Managed Microsoft AD](ms_ad_join_instance.md). 

### Be aware of your limits
<a name="aware_of_limits"></a>

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 [AWS Managed Microsoft AD quotas](ms_ad_limits.md), [AD Connector quotas](ad_connector_limits.md), or [Simple AD quotas](simple_ad_limits.md) for details about your chosen directory.

### Understand your directory's AWS security group configuration and use
<a name="ad_connector_understandsecgroup"></a>

AWS creates a [security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) and attaches it to your directory's [elastic network interfaces](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) that are accessible from within your peered or resized [VPCs](https://aws.amazon.com/vpc/). AWS configures the security group to block unnecessary traffic to the directory and allows necessary traffic. 

#### Modifying the directory security group
<a name="ad_connector_modifyingsecgroup"></a>

To modify the security of your security groups directories, you can do so. Make such changes only if you fully understand how security group filtering works. For more information, see [Amazon EC2 security groups for Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) 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 your directory as this decreases the security of your directory. Please carefully review the [AWS Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/). 

**Warning**  
It is technically possible for you to associate the directory's security group 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 and may disrupt operation of the associated instances. Furthermore, associating the directory security group with your EC2 instances may create a potential security risk for your EC2 instances.

### Configure on-premises sites and subnets correctly when using AD Connector
<a name="ad_connector_config_onprem"></a>

If your on-premises network has Active Directory sites defined, you must make sure the subnets in the VPC where your AD Connector resides are defined in an Active Directory site, and that no conflicts exist between the subnets in your VPC and the subnets in your other sites.

To discover domain controllers, AD Connector uses the Active Directory site whose subnet IP address ranges are close to those in the VPC that contain the AD Connector. If you have a site whose subnets have the same IP address ranges as those in your VPC, AD Connector will discover the domain controllers in that site, which may not be physically close to your Region. 

### Understand username restrictions for AWS applications
<a name="ad_connector_usernamerestrictions"></a>

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 WorkSpaces, WorkDocs, Amazon WorkMail, or Quick. These restrictions require that the following characters not be used:
+ Spaces
+ Multibyte characters
+ \$1"\$1\$1%&'()\$1\$1,/:;<=>?@[\$1]^`\$1\$1\$1\$1

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

## Programming your applications
<a name="ad_connector_program_apps"></a>

Before you program your applications, consider the following:

### Load test before rolling out to production
<a name="ad_connector_program_load_test"></a>

Be sure to do lab testing with applications 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, spread your loads across multiple AD Connector directories.

## Using your directory
<a name="ad_connector_bp_using_directory"></a>

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

### Rotate Admin credentials regularly
<a name="rotate_admin_creds"></a>

Change your AD Connector service account Admin password regularly, and make sure that the password is consistent with your existing Active Directory password policies. For instructions on how to change the service account password, see [Updating your AD Connector service account credentials in AWS Management Console](ad_connector_update_creds.md).

### Use unique AD Connectors for each domain
<a name="ad_connector_use_unique_connector"></a>

AD Connectors and your on-premises AD domains have a 1-to-1 relationship. That is, for each on-premises domain, including child domains in an AD forest that you want to authenticate against, you must create a unique AD Connector. Each AD Connector that you create must use a different service account, even if they are connected to the same directory.

### Check for compatibility
<a name="ad_connector_compatibility"></a>

When using AD Connector, you must ensure that your on-premises directory is and remains compatible with Directory Service. For more information on your responsibilities, please see our [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model).

# Maintain your AD Connector directory
<a name="ad_connector_maintain"></a>

You can use the AWS Management Console to maintain your AD Connector and complete day-to-day administrative tasks. Ways you can maintain your directory include:
+ [View details about your AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_view_directory_info.html).
+ [Update DNS address your AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_update_dns.html) points to.
+ [Delete your AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_delete.html) when it is no longer needed.

# Viewing AD Connector directory information
<a name="ad_connector_view_directory_info"></a>

**To view detailed directory information**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, under **Active Directory**, select **Directories**.

1. Choose the directory ID link for your directory. Information about the directory is displayed in the **Directory details** page. 

For more information about the **Status** field, see [Understanding your directory status](ad_connector_directory_status.md).

# Updating directory network type
<a name="ad_connector_update-directory-type"></a>

You can update your Directory Service directory's network type from IPv4 to Dual-stack (IPv4 and IPv6). Updating the network type to include IPv6 IP addresses provides a larger address space than IPv4. IPv4 and IPv6 communication are independent of each other.

For details, see [Compare IPv4 and IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/ipv4-ipv6-comparison.html) in the *Amazon Virtual Private Cloud User Guide*.

**Important**  
This is a one-way operation that cannot be reversed. Test in a non-production environment first.

## Prerequisites
<a name="ad_connector_update-directory-type-prereq"></a>

Before you update your directory network type, ensure the following requirements are met:
+ Your VPC must be configured with IPv6 CIDR ranges. For details, see [IPv6 support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) in the *Amazon Virtual Private Cloud User Guide*.
+ You have administrative access to the AWS Management Console.
+ Your directory must be in Active state.
+ You have appropriate IAM permissions to modify Directory Service settings.

## To update directory network type
<a name="ad_connector_update-directory-type-procedure"></a>

**To update your directory to dual-stack networking**
**Note**  
If your directory is replicated in multiple regions, perform this update in each region.

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, choose **Directories**.

1. Select the target directory.

1. Go to the **Networking & security** tab.

1. Choose **Add IPv6 support**. This option is only available for IPv4-only directories.

1. Review the update information and pricing details.

1. Choose **Add** to confirm the update.

After initiating the update, the directory status changes to **Updating** during the update process The update typically takes 15-30 minutes to complete Once complete, the directory status returns to **Active**.

# Updating the DNS address for your AD Connector
<a name="ad_connector_update_dns"></a>

Use the following steps to update the DNS addresses that your AD Connector is pointing to.

**Note**  
If you have an update in progress, you must wait until it is complete before submitting another update.  
If you are using WorkSpaces with your AD Connector, ensure that the DNS addresses for your WorkSpace are updated as well. For more information, see [Update DNS servers for WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/update-dns-server.html).

**To update your DNS settings for AD Connector**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, under **Active Directory**, choose **Directories**.

1. Choose the directory ID link for your directory.

1. On the **Directory details** page, choose the **Network & Security** tab. 

1. Scroll down to the **Existing DNS settings** section and choose **Update**.

1. In the **Update existing DNS addresses** dialog, type the updated DNS IP addresses, and then choose **Update**.

For more information on troubleshooting AD Connector, see [Troubleshooting AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_troubleshooting.html).

# Deleting your AD Connector
<a name="ad_connector_delete"></a>

When an AD Connector is deleted, your on-premises directory remains intact. All instances that are joined to the directory also remain intact and remain joined to your on-premises directory. You can still use your directory credentials to log in to these instances.

**To delete AD Connector**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**. Ensure you are in the AWS Region where your AD Connector is deployed. For more information, see [Choosing a Region](https://docs.aws.amazon.com//awsconsolehelpdocs/latest/gsg/select-region.html).

1. Ensure that no AWS applications are enabled for the AD Connector you intend to delete. Enabled AWS applications will prevent you for deleting your AD Connector.

   1. On the **Directories** page, choose your directory ID.

   1. On the **Directory details** page, select the **Application management** tab. In the **AWS apps & services** section, you see which AWS applications are enabled for your AD Connector.
      + Disable AWS Management Console access. For more information, see [Disabling AWS Management Console access](ms_ad_management_console_access.md#console_disable).
      + To disable Amazon WorkSpaces, you must deregister the service from the directory in the WorkSpaces console. For more information, see [Delete a directory](https://docs.aws.amazon.com/workspaces/latest/adminguide/delete-workspaces-directory.html) in the *Amazon WorkSpaces Administration Guide*.
      + To disable WorkDocs, you must delete the WorkDocs site in the WorkDocs console. For more information, see [Delete a site](https://docs.aws.amazon.com/workdocs/latest/adminguide/delete_site.html) in the *Amazon WorkDocs Administration Guide*.
      + To disable Amazon WorkMail, you must remove the Amazon WorkMail organization in the Amazon WorkMail console. For more information, see [Remove an organization](https://docs.aws.amazon.com/workmail/latest/adminguide/remove_organization.html) in the *Amazon WorkMail Administrator Guide*.
      + To disable Amazon FSx for Windows File Server, you must remove the Amazon FSx file system from the domain. For more information, see [Working with Active Directory in FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/aws-ad-integration-fsxW.html) in the *Amazon FSx for Windows File Server User Guide*.
      + To disable Amazon Relational Database Service, you must remove the Amazon RDS instance from the domain. For more information, see [Managing a DB instance in a domain](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.html#USER_SQLServerWinAuth.Managing) in the *Amazon RDS User Guide*.
      + To disable AWS Client VPN Service, you must remove the directory service from the Client VPN Endpoint. For more information, see [Work with Client VPN](https://docs.aws.amazon.com//vpn/latest/clientvpn-admin/cvpn-working.html) in the *AWS Client VPN Administrator Guide*.
      + To disable Amazon Connect, you must delete the Amazon Connect Instance. For more information, see [Delete your Amazon Connect instance](https://docs.aws.amazon.com/connect/latest/adminguide/delete-connect-instance.html) in the *Amazon Connect Administration Guide*.
      + To disable Amazon Quick, you must unsubscribe from Amazon Quick. For more information, see [Closing your Amazon Quick account](https://docs.aws.amazon.com/quicksight/latest/user/closing-account.html) in the *Amazon Quick User Guide*.
**Note**  
If you are using AWS IAM Identity Center and have previously connected it to the AWS Managed Microsoft AD directory you plan to delete, you must first change the identity source before you can delete it. For more information, see [Change your identity source ](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-change.html) in the *IAM Identity Center User Guide*.

1. In the navigation pane, choose **Directories**.

1. Select only the AD Connector to be deleted and click **Delete**. It takes several minutes for the AD Connector to be deleted. When the AD Connector has been deleted, it is removed from your directory list.

# Secure your AD Connector directory
<a name="ad_connector_security"></a>

You can use features like multi-factor authentication (MFA), client-side Lightweight Directory Access Protocol over Secure Sockets Layer (SSL)/Transport Layer Security (TLS) (LDAPS), and AWS Private Certificate Authority to secure your AD Connector. Ways you can secure your AD Connector include:
+ Enable MFA which increases your AD Connector security.
+ Enable client-side Lightweight Directory Access Protocol over Secure Socket Layer (SSL)/Transport Layer Security (TLS) (LDAPS) so that communications over LDAP are encrypted and improves security.
+ Enable certificate-based mutual Transport Layer Security (mTLS) authentication with smart cards which allows users to authenticate in to Amazon Web Services through your Active Directory and AD Connector.
+ Update your AD Connector service account credentials.
+ Set up AWS Private CA Connector for AD so you can issue and manage certificates for your AD Connector.

**Topics**
+ [Enabling multi-factor authentication for AD Connector](ad_connector_mfa.md)
+ [Enabling client-side LDAPS using AD Connector](ad_connector_ldap_client_side.md)
+ [Enabling mTLS authentication in AD Connector for use with smart cards](ad_connector_clientauth.md)
+ [Updating your AD Connector service account credentials in AWS Management Console](ad_connector_update_creds.md)
+ [Set up AWS Private CA Connector for AD](ad_connector_pca_connector.md)

# Enabling multi-factor authentication for AD Connector
<a name="ad_connector_mfa"></a>

You can enable multi-factor authentication for AD Connector when you have Active Directory running on-premises or in Amazon EC2 instances. For more information about using multi-factor authentication with Directory Service, see [AD Connector prerequisites](ad_connector_getting_started.md#prereq_connector).

**Note**  
Multi-factor authentication is not available for Simple AD. However, MFA can be enabled for your AWS Managed Microsoft AD directory. For more information, see [Enabling multi-factor authentication for AWS Managed Microsoft AD](ms_ad_mfa.md).

**To enable multi-factor authentication for AD Connector**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**.

1. Choose the directory ID link for your AD Connector directory.

1. On the **Directory details** page, select the **Networking & security** tab.

1. In the **Multi-factor authentication** section, choose **Actions**, and then choose **Enable**.

1. On the **Enable multi-factor authentication (MFA)** page, provide the following values:   
**Display label**  
Provide a label name.  
**RADIUS server DNS name or IP addresses**  
The IP addresses of your RADIUS server endpoints, or the IP address of your RADIUS server load balancer. You can enter multiple IP addresses by separating them with a comma (e.g., `192.0.0.0,192.0.0.12`).  
RADIUS MFA is applicable only to authenticate access to the AWS Management Console, or to Amazon Enterprise applications and services such as WorkSpaces, Amazon Quick, or Amazon Chime. It does not provide MFA to Windows workloads running on EC2 instances, or for signing into an EC2 instance. Directory Service does not support RADIUS Challenge/Response authentication.  
Users must have their MFA code at the time they enter their username and password. Alternatively, you must use a solution that performs MFA out-of-band such as SMS text verification for the user. In out-of-band MFA solutions, you must make sure you set the RADIUS time-out value appropriately for your solution. When using an out-of-band MFA solution, the sign-in page will prompt the user for an MFA code. In this case, the best practice is for users to enter their password in both the password field and the MFA field.  
**Port**  
The port that your RADIUS server is using for communications. Your on-premises network must allow inbound traffic over the default RADIUS server port (UDP:1812) from the Directory Service servers.  
**Shared secret code**  
The shared secret code that was specified when your RADIUS endpoints were created.  
**Confirm shared secret code**  
Confirm the shared secret code for your RADIUS endpoints.  
**Protocol**  
Select the protocol that was specified when your RADIUS endpoints were created.  
**Server timeout (in seconds)**  
The amount of time, in seconds, to wait for the RADIUS server to respond. This must be a value between 1 and 50.  
**Max RADIUS request retries**  
The number of times that communication with the RADIUS server is attempted. This must be a value between 0 and 10.

   Multi-factor authentication is available when the **RADIUS Status** changes to **Enabled**. 

1. Choose **Enable**. 

# Enabling client-side LDAPS using AD Connector
<a name="ad_connector_ldap_client_side"></a>

Client-side LDAPS support in AD Connector encrypts communications between Microsoft Active Directory (AD) and AWS applications. Examples of such applications include WorkSpaces, AWS IAM Identity Center, Quick, and Amazon Chime. This encryption helps you to better protect your organization's identity data and meet your security requirements.

You can also deregister and disable client-side LDAPS.

**Topics**
+ [Prerequisites](#prereqs-ldap-client-side)
+ [Enabling client-side LDAPS](#enable-ldap-client-side)
+ [Managing client-side LDAPS](manage-ldap-client-side.md)

## Prerequisites
<a name="prereqs-ldap-client-side"></a>

Before you enable client-side LDAPS, you need to meet the following requirements.

**Topics**
+ [Deploy server certificates in Active Directory](#deploy_server_certs_ldap_client_side)
+ [CA certificate requirements](#cert_requirements_ldap_client_side)
+ [Networking requirements](#networking_requirements_ldap_client_side)

### Deploy server certificates in Active Directory
<a name="deploy_server_certs_ldap_client_side"></a>

In order to enable client-side LDAPS, you need to obtain and install server certificates for each domain controller in Active Directory. These certificates will be used by the LDAP service to listen for and automatically accept SSL connections from LDAP clients. You can use SSL certificates that are either issued by an in-house Active Directory Certificate Services (ADCS) deployment or purchased from a commercial issuer. For more information on Active Directory server certificate requirements, see [LDAP over SSL (LDAPS) Certificate](https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx) on the Microsoft website.

### CA certificate requirements
<a name="cert_requirements_ldap_client_side"></a>

A certificate authority (CA) certificate, which represents the issuer of your server certificates, is required for client-side LDAPS operation. CA certificates are matched with the server certificates that are presented by your Active Directory domain controllers to encrypt LDAP communications. Note the following CA certificate requirements:
+  To register a certificate, it must be more than 90 days away from expiration.
+ Certificates must be in Privacy-Enhanced Mail (PEM) format. If exporting CA certificates from inside Active Directory, choose base64 encoded X.509 (.CER) as the export file format.
+ A maximum of five (5) CA certificates can be stored per AD Connector directory.
+ Certificates using the RSASSA-PSS signature algorithm are not supported.

### Networking requirements
<a name="networking_requirements_ldap_client_side"></a>

AWS application LDAP traffic will run exclusively on TCP port 636, with no fallback to LDAP port 389. However, Windows LDAP communications supporting replication, trusts, and more will continue using LDAP port 389 with Windows-native security. Configure AWS security groups and network firewalls to allow TCP communications on port 636 in AD Connector (outbound) and self-managed Active Directory (inbound). 

## Enabling client-side LDAPS
<a name="enable-ldap-client-side"></a>

To enable client-side LDAPS, you import your certificate authority (CA) certificate into AD Connector, and then enable LDAPS on your directory. Upon enabling, all LDAP traffic between AWS applications and your self-managed Active Directory will flow with Secure Sockets Layer (SSL) channel encryption.

You can use two different methods to enable client-side LDAPS for your directory. You can use either the AWS Management Console method or the AWS CLI method.

### Registering certificate in Directory Service
<a name="step1-register-cert-ldap-client-side"></a>

Use either of the following methods to register a certificate in Directory Service.

**Method 1: To register your certificate in Directory Service (AWS Management Console)**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**.

1. Choose the directory ID link for your directory.

1. On the **Directory details** page, choose the **Networking & security** tab.

1. In the **Client-side LDAPS** section, select the **Actions** menu, and then select **Register certificate**.

1. In the **Register a CA certificate** dialog box, select **Browse**, and then select the certificate and choose **Open**.

1. Choose **Register certificate**.

**Method 2: To register your certificate in Directory Service (AWS CLI)**
+ Run the following command. For the certificate data, point to the location of your CA certificate file. A certificate ID will be provided in the response.

  ```
  aws ds register-certificate --directory-id your_directory_id --certificate-data file://your_file_path
  ```

### Checking registration status
<a name="step2-check-registration-status-ldap-client-side"></a>

To see the status of a certificate registration or a list of registered certificates, use either of the following methods.

**Method 1: To check certificate registration status in Directory Service (AWS Management Console)**

1. Go to the **Client-side LDAPS** section on the **Directory details** page.

1. Review the current certificate registration state that is displayed under the **Registration status** column. When the registration status value changes to **Registered**, your certificate has been successfully registered.

**Method 2: To check certificate registration status in Directory Service (AWS CLI)**
+ Run the following command. If the status value returns `Registered`, your certificate has been successfully registered.

  ```
  aws ds list-certificates --directory-id your_directory_id
  ```

### Enabling client-side LDAPS
<a name="step3-enable-ldap-client-side"></a>

Use either of the following methods to enable client-side LDAPS in Directory Service.

**Note**  
You must have successfully registered at least one certificate before you can enable client-side LDAPS.

**Method 1: To enable client-side LDAPS in Directory Service (AWS Management Console)**

1. Go to the **Client-side LDAPS** section on the **Directory details** page.

1. Choose **Enable**. If this option is not available, verify that a valid certificate has been successfully registered, and then try again.

1. In the **Enable client-side LDAPS** dialog box, choose **Enable**.

**Method 2: To enable client-side LDAPS in Directory Service (AWS CLI)**
+ Run the following command.

  ```
  aws ds enable-ldaps --directory-id your_directory_id --type Client
  ```

### Checking LDAPS status
<a name="step4-check-status-ldap-client-side"></a>

Use either of the following methods to check the LDAPS status in Directory Service.

**Method 1: To check LDAPS status in Directory Service (AWS Management Console)**

1. Go to the **Client-side LDAPS** section on the **Directory details** page.

1. If the status value is displayed as **Enabled**, LDAPS has been successfully configured.

**Method 2: To check LDAPS status in Directory Service (AWS CLI)**
+ Run the following command. If the status value returns `Enabled`, LDAPS has been successfully configured.

  ```
  aws ds describe-ldaps-settings –directory-id your_directory_id
  ```

For more information on viewing your client-side LDAPS certificate, deregistering or disabling your LDAPS certificate, see [Managing client-side LDAPS](manage-ldap-client-side.md).

# Managing client-side LDAPS
<a name="manage-ldap-client-side"></a>

Use these commands to manage your LDAPS configuration.

You can use two different methods to manage client-side LDAPS settings. You can use either the AWS Management Console method or the AWS CLI method.

## View certificate details
<a name="describe-a-certificate-ldap-client-side"></a>

Use either of the following methods to see when a certificate is set to expire.

**Method 1: To view certificate details in Directory Service (AWS Management Console)**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**.

1. Choose the directory ID link for your directory.

1. On the **Directory details** page, choose the **Networking & security** tab.

1. In the **Client-side LDAPS** section, under **CA certificates**, information about the certificate will be displayed.

**Method 2: To view certificate details in Directory Service (AWS CLI)**
+ Run the following command. For the certificate ID, use the identifier returned by `register-certificate` or `list-certificates`. 

  ```
  aws ds describe-certificate --directory-id your_directory_id --certificate-id your_cert_id
  ```

## Deregister a certificate
<a name="dergister-a-certificate-ldap-client-side"></a>

Use either of the following methods to deregister a certificate.

**Note**  
If only one certificate is registered, you must first disable LDAPS before you can deregister the certificate.

**Method 1: To deregister a certificate in Directory Service (AWS Management Console)**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**.

1. Choose the directory ID link for your directory.

1. On the **Directory details** page, choose the **Networking & security** tab.

1. In the **Client-side LDAPS** section, choose **Actions**, and then choose **Deregister certificate**.

1. In the **Deregister a CA certificate** dialog box, choose **Deregister**.

**Method 2: To deregister a certificate in Directory Service (AWS CLI)**
+ Run the following command. For the certificate ID, use the identifier returned by `register-certificate` or `list-certificates`. 

  ```
  aws ds deregister-certificate --directory-id your_directory_id --certificate-id your_cert_id
  ```

## Disable client-side LDAPS
<a name="disable-client-side-ldaps"></a>

Use either of the following methods to disable client-side LDAPS.

**Method 1: To disable client-side LDAPS in Directory Service (AWS Management Console)**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**.

1. Choose the directory ID link for your directory.

1. On the **Directory details** page, choose the **Networking & security** tab.

1. In the **Client-side LDAPS** section, choose **Disable**.

1. In the **Disable client-side LDAPS** dialog box, choose **Disable**.

**Method 2: To disable client-side LDAPS in Directory Service (AWS CLI)**
+ Run the following command.

  ```
  aws ds disable-ldaps --directory-id your_directory_id --type Client
  ```

# Enabling mTLS authentication in AD Connector for use with smart cards
<a name="ad_connector_clientauth"></a>

You can use certificate-based mutual Transport Layer Security (mTLS) authentication with smart cards to authenticate users into Amazon WorkSpaces through your self-managed Active Directory (AD) and AD Connector. When enabled, users select their smart card at the WorkSpaces login screen and enter a PIN to authenticate, instead of using a username and password. From there, the Windows or Linux virtual desktop uses the smart card to authenticate into AD from the native desktop OS. 

**Note**  
Smart card authentication in AD Connector is only available in the following AWS Regions, and only with WorkSpaces. Other AWS applications are not supported at this time.  
US East (N. Virginia)
US West (Oregon)
Asia Pacific (Sydney)
Asia Pacific (Tokyo)
Europe (Ireland)
AWS GovCloud (US-West)
AWS GovCloud (US-East)

You can also deregister and disable the certificates.

**Topics**
+ [Prerequisites](#prereqs-clientauth)
+ [Enabling smart card authentication](#enable-clientauth)
+ [Managing smart card authentication settings](manage-clientauth.md)

## Prerequisites
<a name="prereqs-clientauth"></a>

To enable certificate-based mutual Transport Layer Security (mTLS) authentication using smart cards for the Amazon WorkSpaces client, you need an operational smart card infrastructure integrated with your self-managed Active Directory. For more information on how to set up smart card authentication with Amazon WorkSpaces and Active Directory, see the [Amazon WorkSpaces Administration Guide](https://docs.aws.amazon.com/workspaces/latest/adminguide/smart-cards.html).

Before you enable smart card authentication for WorkSpaces, please review the following prerequisites:
+ [CA certificate requirements](#ca-cert)
+ [User certificate requirements](#user-cert)
+ [Certificate revocation checking process](#ocsp)
+ [Considerations](#other)

### CA certificate requirements
<a name="ca-cert"></a>

AD Connector requires a certificate authority (CA) certificate, which represents the issuer of your user certificates, for smart card authentication. AD Connector matches CA certificates with the certificates presented by your users with their smart cards. Note the following CA certificate requirements:
+ Before you can register a CA certificate, it must be more than 90 days away from expiration.
+  CA certificates must be in Privacy-Enhanced Mail (PEM) format. If you export CA certificates from inside Active Directory, choose Base64-encoded X.509 (.CER) as the export file format.
+ All root and intermediary CA certificates that chain from an issuing CA to user certificates must be uploaded for smart card authentication to succeed.
+ A maximum of 100 CA certificates can be stored per AD Connector directory
+ AD Connector does not support the RSASSA-PSS signature algorithm for CA certificates.
+ Verify the Certificate Propagation Service is set to Automatic and running.

### User certificate requirements
<a name="user-cert"></a>

The following are some of the requirements for the user certificate:
+  The user's smart card certificate has a Subject Alternative Name (SAN) of the user's userPrincipalName (UPN).
+ The user's smart card certificate has Enhanced Key Usage as the smart card log-on (1.3.6.1.4.1.311.20.2.2) Client Authentication (1.3.6.1.5.5.7.3.2).
+ The Online Certificate Status Protocol (OCSP) information for the user's smart card certificate should be Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) in the Authority Information Access.

For more information on AD Connector and smart card authentication requirements, see [Requirements](https://docs.aws.amazon.com//workspaces/latest/adminguide/smart-cards.html#smart-cards-requirements) in *Amazon WorkSpaces Administration Guide*. For help troubleshooting Amazon WorkSpaces issues, like logging into WorkSpaces, resetting password, or connecting to WorkSpaces, see [Troubleshoot WorkSpaces client issues](https://docs.aws.amazon.com//workspaces/latest/userguide/client_troubleshooting.html) in *Amazon WorkSpaces User Guide*.

### Certificate revocation checking process
<a name="ocsp"></a>

In order to perform smart card authentication, AD Connector must check the revocation status of user certificates using Online Certificate Status Protocol (OCSP). To perform certificate revocation checking, an OCSP responder URL must be internet-accessible. If using a DNS name, an OCSP responder URL must use a top-level domain found in the [Internet Assigned Numbers Authority (IANA) Root Zone Database](https://www.iana.org/domains/root/db). 

**Note**  
Directories created after October 7, 2025, require that OCSP servers used for SmartCard certificate validation be routable through your VPC's network configuration. If your OCSP server is not accessible via your VPC's routing tables, security groups, and network ACLs, SmartCard authentication will fail during certificate revocation checks. To resolve this issue, please ensure that:  
Network Routing: Your VPC route tables allow traffic to reach your OCSP server from the subnets where your AD Connector directory instances are deployed.
Security Groups: The security groups associated with your directory's network interfaces permit outbound traffic to your OCSP server on port 80 (HTTP).
Network ACLs: Your subnet network ACLs allow bidirectional traffic to/from your OCSP server.
Internet Gateway/NAT: If your OCSP server is internet-facing, ensure your VPC has appropriate internet gateway or NAT gateway configuration for the directory subnets. If your network type is IPv4, you will need to have NAT and internet gateway configured with your VPC.

AD Connector certificate revocation checking uses the following process:
+ AD Connector must check the Authority Information Access (AIA) extension in the user certificate for an OCSP responder URL, then AD Connector uses the URL to check for revocation.
+ If AD Connector cannot resolve the URL found in the user certificate AIA extension, or find an OCSP responder URL in the user certificate, then AD Connector uses the optional OCSP URL provided during root CA certificate registration.

  If the URL in the user certificate AIA extension resolves but is unresponsive, then user authentication fails.
+ If the OCSP responder URL provided during root CA certificate registration cannot resolve, is unresponsive, or no OCSP responder URL was provided, user authentication fails.
+ The OCSP server must be compliant with [RFC 6960](https://datatracker.ietf.org/doc/html/rfc6960). Additionally, the OCSP server must support requests using the GET method for requests that are less than or equal to 255 bytes in total.

**Note**  
AD Connector requires an **HTTP** URL for the OCSP responder URL.

### Considerations
<a name="other"></a>

Before enabling smart card authentication in AD Connector, consider the following items:
+ AD Connector uses certificate-based mutual Transport Layer Security authentication (mutual TLS) to authenticate users to Active Directory using hardware or software-based smart card certificates. Only common access cards (CAC) and personal identity verification (PIV) cards are supported at this time. Other types of hardware or software-based smart cards might work but have not been tested for use with the WorkSpaces Streaming Protocol.
+ Smart card authentication replaces username and password authentication to WorkSpaces.

  If you have other AWS applications configured on your AD Connector directory with smart card authentication enabled, those applications still present the username and password input screen. 
+ Enabling smart card authentication limits the user session length to the maximum lifetime for Kerberos service tickets. You can configure this setting using a Group Policy, and is set to 10 hours by default. For more information on this setting, see [Microsoft documentation](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-service-ticket).
+ The AD Connector service account's supported Kerberos encryption type should match each of the domain controller's supported Kerberos encryption type.

## Enabling smart card authentication
<a name="enable-clientauth"></a>

To enable smart card authentication for WorkSpaces on your AD Connector, first you need to import your certificate authority (CA) certificates into AD Connector. You can import your CA certificates into AD Connector using AWS Directory Service console, [API](https://docs.aws.amazon.com/directoryservice/latest/devguide/welcome.html) or [CLI](https://docs.aws.amazon.com/cli/latest/reference/ds/index.html). Use the following steps to import your CA certificates and subsequently enable smart card authentication.

**Topics**
+ [Enabling Kerberos constrained delegation for the AD Connector service account](#step1)
+ [Registering the CA certificate in AD Connector](#step2)
+ [Enabling smart card authentication for supported AWS applications and services](#step3)

### Enabling Kerberos constrained delegation for the AD Connector service account
<a name="step1"></a>

To use smart card authentication with AD Connector, you must enable **Kerberos Constrained Delegation (KCD)** for the AD Connector Service account to the LDAP service in the self-managed AD directory.

Kerberos Constrained Delegation is a feature in Windows Server. This feature enables administrators to specify and enforce application trust boundaries by limiting the scope where application services can act on a user's behalf. For more information, see [Kerberos constrained delegation](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_key_concepts_kerberos.html). 
**Note**  
**Kerberos Constrained Delegation (KCD)** requires the username portion of the AD Connector service account to match the sAMAccountName of the same user. The sAMAccountName is restricted to 20 characters. sAMAccountName is a Microsoft Active Directory attribute used as a sign in name for prior versions of Windows clients and servers.

1. Use the `SetSpn` command to set a Service Principal Name (SPN) for the AD Connector service account in the self-managed AD. This enables the service account for delegation configuration.

   The SPN can be any service or name combination but not a duplicate of an existing SPN. The `-s` checks for duplicates.

   ```
   setspn -s my/spn service_account
   ```

1. In **AD Users and Computers**, open the context (right-click) menu and choose the AD Connector service account and choose **Properties**.

1. Choose the **Delegation** tab.

1. Choose the **Trust this user for delegation to specified service only** and **Use any authentication protocol** options.

1. Choose **Add** and then **Users or Computers** to locate the domain controller. 

1. Choose **OK** to display a list of available services used for delegation.

1. Choose the **ldap** service type and choose **OK**. 

1. Choose **OK** again to save the configuration.

1. Repeat this process for other domain controllers in the Active Directory. Alternatively you can automate the process using PowerShell.

### Registering the CA certificate in AD Connector
<a name="step2"></a>

Use either of the following methods to register a CA certificate for your AD Connector directory.

**Method 1: To register your CA certificate in AD Connector (AWS Management Console)**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**.

1. Choose the directory ID link for your directory.

1. On the **Directory details** page, choose the **Networking & security** tab.

1. In the **Smart card authentication** section, choose **Actions**, and then choose **Register certificate**.

1. In the **Register a certificate** dialog box, select **Choose file**, and then choose a certificate and choose **Open**. You can optionally choose to perform revocation checking for this certificate by providing an Online Certificate Status Protocol (OCSP) responder URL. For more information about OCSP, see [Certificate revocation checking process](#ocsp).

1. Choose **Register certificate**. When you see the certificate status change to **Registered**, the registration process has completed successfully. 

**Method 2: To register your CA certificate in AD Connector (AWS CLI)**
+ Run the following command. For the certificate data, point to the location of your CA certificate file. To provide a secondary OCSP responder address, use the optional `ClientCertAuthSettings` object. 

  ```
  aws ds register-certificate --directory-id your_directory_id --certificate-data file://your_file_path --type ClientCertAuth --client-cert-auth-settings OCSPUrl=http://your_OCSP_address
  ```

  If successful, the response provides a certificate ID. You can also verify your CA certificate registered successfully by running the following CLI command:

  ```
  aws ds list-certificates --directory-id your_directory_id
  ```

  If the status value returns `Registered`, you have successfully registered your certificate.

### Enabling smart card authentication for supported AWS applications and services
<a name="step3"></a>

Use either of the following methods to register a CA certificate for your AD Connector directory.

**Method 1: To enable smart card authentication in AD Connector (AWS Management Console)**

1. Navigate to the **Smart card authentication** section on the **Directory details** page, and choose **Enable**. If this option is not available, verify that a valid certificate has been successfully registered, and then try again.

1. In the **Enable smart card authentication** dialog box, select **Enable**.

**Method 2: To enable smart card authentication in AD Connector (AWS CLI)**
+ Run the following command.

  ```
  aws ds enable-client-authentication --directory-id your_directory_id --type SmartCard
  ```

  If successful, AD Connector returns an `HTTP 200` response with an empty HTTP body.

For more information on viewing your certificate, deregistering or disabling your certificate, see [Managing smart card authentication settings](manage-clientauth.md).

# Managing smart card authentication settings
<a name="manage-clientauth"></a>

You can use two different methods to manage smart card settings. You can use either the AWS Management Console method or the AWS CLI method.

**Topics**
+ [View certificate details](#describe-a-certificate-clientauth)
+ [Deregister a certificate](#dergister-a-certificate-clientauth)
+ [Disable smart card authentication](#disable-smart-card-clientauth)

## View certificate details
<a name="describe-a-certificate-clientauth"></a>

Use either of the following methods to see when a certificate is set to expire.

**Method 1: To view certificate details in Directory Service (AWS Management Console)**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**.

1. Choose the directory ID link for your AD Connector directory.

1. On the **Directory details** page, choose the **Networking & security** tab.

1. In the **Smart card authentication** section, under **CA certificates**, choose the certificate ID to display details about that certificate.

**Method 2: To view certificate details in Directory Service (AWS CLI)**
+ Run the following command. For the certificate ID, use the identifier returned by `register-certificate` or `list-certificates`. 

  ```
  aws ds describe-certificate --directory-id your_directory_id --certificate-id your_cert_id
  ```

## Deregister a certificate
<a name="dergister-a-certificate-clientauth"></a>

Use either of the following methods to deregister a certificate.

**Note**  
If only one certificate is registered, you must first disable smart card authentication before you can deregister the certificate.

**Method 1: To deregister a certificate in Directory Service (AWS Management Console)**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**.

1. Choose the directory ID link for your AD Connector directory.

1. On the **Directory details** page, choose the **Networking & security** tab.

1. In the **Smart card authentication** section, under **CA certificates**, select the certificate you want to deregister, choose **Actions**, and then choose **Deregister certificate**. 
**Important**  
Ensure that the certificate you are about to deregister is not active or is currently being used as part of a CA certificate chain for smart card authentication.

1. In the **Deregister a CA certificate** dialog box, choose **Deregister**.

**Method 2: To deregister a certificate in Directory Service (AWS CLI)**
+ Run the following command. For the certificate ID, use the identifier returned by `register-certificate` or `list-certificates`. 

  ```
  aws ds deregister-certificate --directory-id your_directory_id --certificate-id your_cert_id
  ```

## Disable smart card authentication
<a name="disable-smart-card-clientauth"></a>

Use either of the following methods to disable smart card authentication.

**Method 1: To disable smart card authentication in Directory Service (AWS Management Console)**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**.

1. Choose the directory ID link for your AD Connector directory.

1. On the **Directory details** page, choose the **Networking & security** tab.

1. In the **Smart card authentication** section, choose **Disable**.

1. In the **Disable smart card authentication** dialog box, choose **Disable**.

**Method 2: To disable smart card authentication in Directory Service (AWS CLI)**
+ Run the following command.

  ```
  aws ds disable-client-authentication --directory-id your_directory_id --type SmartCard
  ```

# Updating your AD Connector service account credentials in AWS Management Console
<a name="ad_connector_update_creds"></a>

The AD Connector credentials you provide in Directory Service represent the service account that is used to access your existing on-premises directory. You can modify the service account credentials in Directory Service by performing the following steps.

**Note**  
If AWS IAM Identity Center is enabled for the directory, Directory Service must transfer the service principal name (SPN) from the current service account to the new service account. If the current service account does not have permission to delete the SPN or the new service account does not have permission to add the SPN, you are prompted for the credentials of a directory account that does have permission to perform both actions. These credentials are only used to transfer the SPN and are not stored by the service.

**To update your AD Connector service account credentials in Directory Service**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, under **Active Directory**, choose **Directories**.

1. Choose the directory ID link for your directory.

1. On the **Directory details** page, scroll down to the **Service account credentials** section.

1. In the **Service account credentials** section, choose **Update**. 

1. In the **Update service account credentials** dialog box, type the service account username and password. Reenter the password to confirm it and then choose **Update**.

# Set up AWS Private CA Connector for AD
<a name="ad_connector_pca_connector"></a>

You can integrate your self-managed Active Directory with AWS Private Certificate Authority using AD Connector to issue and manage certificates for your AD domain-joined users, groups, and machines. AWS Private CA Connector for AD provides a fully managed AWS Private CA as a drop-in replacement for your self-managed enterprise CAs without requiring you to deploy, patch, or update local agents or proxy servers.

You can set up this integration through the Directory Service console, the AWS Private CA Connector for AD console, or by calling the [https://docs.aws.amazon.com/pca-connector-ad/latest/APIReference/API-CreateTemplate.html](https://docs.aws.amazon.com/pca-connector-ad/latest/APIReference/API-CreateTemplate.html) API. To use the AWS Private CA Connector for Active Directory console, see [AWS Private CA Connector for Active Directory](https://docs.aws.amazon.com/privateca/latest/userguide/connector-for-ad.html). The following sections describe how to set up this integration from the Directory Service console.

## Prerequisites
<a name="ad_connector_pca_connector_pre-reqs"></a>

For setup instructions, see [Set up Connector for AD](https://docs.aws.amazon.com/privateca/latest/userguide/connector-for-ad-getting-started-prerequisites.html) in the AWS Private CA Connector for AD User Guide.

## Setting up AWS Private CA Connector for AD
<a name="ad_connector_pca_connector_set_up"></a>

**To create a Private CA connector for Active Directory**

1. Sign in to the AWS Management Console and open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/).

1. On the **Directories** page, choose your directory ID.

1. Under the **Application Management** tab and **AWS apps & services** section, choose **AWS Private CA Connector for AD**.

1. On the **Create Private CA certificate for Active Directory** page, complete the steps to create your Private CA for Active Directory connector.

For more information, see [Creating a connector](https://docs.aws.amazon.com/privateca/latest/userguide/create-connector-for-ad.html).

## View your AWS Private CA Connector for AD
<a name="ad_connector_pca_connector_view"></a>

**To view Private CA connector details**

1. Sign in to the AWS Management Console and open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/).

1. On the **Directories** page, choose your directory ID.

1. Under the **Application Management** tab and **AWS apps & services** section, view your Private CA connectors and associated Private CA. The following fields display:

   1. **AWS Private CA Connector ID** – The unique identifier for a AWS Private CA connector. Choose it to view the details page.

   1. **AWS Private CA subject** – Information regarding the distinguished name for the CA. Choose it to view the details page.

   1. **Status** – Status check results for the AWS Private CA Connector and AWS Private CA:
      + **Active** – Both checks pass
      + **1/2 checks failed** – One check fails
      + **Failed** – Both checks fail

      For failed status details, hover over the hyperlink to see which check failed.

   1. **DC Certificates Enrollment status** – Status check for domain controller certificate status:
      + **Enabled** – Certificate enrollment is enabled
      + **Disabled** – Certificate enrollment is disabled

   1. **Date created** – When the AWS Private CA Connector was created.

For more information, see [View connector details](https://docs.aws.amazon.com/privateca/latest/userguide/view-connector-for-ad.html).

## Verify certificate issuance to AD users
<a name="ms_ad_pca_connector_confirm"></a>

Complete the following steps to confirm that AWS Private CA is issuing certificates to your self-managed Active Directory:
+ Restart your on-premises domain controllers.
+ View your certificates with Microsoft Management Console. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-view-certificates-with-the-mmc-snap-in).

# Monitor your AD Connector directory
<a name="ad_connector_monitor"></a>

You can get the most out of your AD Connector by learning more about the different AD Connector status and what they mean for your AD Connector. You can also use Amazon Simple Notification Service to receive notifications regarding your AD Connector status.

**Topics**
+ [Understanding your directory status](ad_connector_directory_status.md)
+ [Enabling AD Connector directory status notifications with Amazon SNS](ad_connector_enable_notifications.md)

# Understanding your directory status
<a name="ad_connector_directory_status"></a>

The following are the various statuses for a directory.

**Active**  
The directory is operating normally. No issues have been detected by the Directory Service for your directory. 

**Creating**  
The directory is currently being created. Directory creation typically takes between 20 to 45 minutes but may vary depending on the system load. 

**Deleted**  
The directory has been deleted. All resources for the directory have been released. Once a directory enters this state, it cannot be recovered. 

**Deleting**  
The directory is currently being deleted. The directory will remain in this state until it has been completely deleted. Once a directory enters this state, the delete operation cannot be cancelled, and the directory cannot be recovered. 

**Failed**  
The directory could not be created. Please delete this directory. If this problem persists, please contact the [AWS Support Center](https://console.aws.amazon.com/support/home#/).

**Impaired**  
The directory is running in a degraded state. One or more issues have been detected, and not all directory operations may be working at full operational capacity. There are many potential reasons for the directory being in this state. These include normal operational maintenance activity such as patching or EC2 instance rotation, temporary hot spotting by an application on one of your domain controllers, or changes you made to your network that inadvertently disrupt directory communications. For more information, see either [Troubleshooting AWS Managed Microsoft AD](ms_ad_troubleshooting.md), [Troubleshooting AD Connector](ad_connector_troubleshooting.md), [Troubleshooting Simple AD](simple_ad_troubleshooting.md). For normal maintenance related issues, AWS resolves these issues within 40 minutes. If after reviewing the troubleshooting topic, your directory is in an Impaired state longer than 40 minutes, we recommend that you contact the [AWS Support Center](https://console.aws.amazon.com/support/home#/).  
Do not restore a snapshot while a directory is in an Impaired state. It is rare that snapshot restore is necessary to resolve impairments. For more information, see [Restoring your AWS Managed Microsoft AD with snapshots](ms_ad_snapshots.md).

**Inoperable**  
The directory is not functional. All directory endpoints have reported issues. 

**Requested**  
A request to create your directory is currently pending. 

# Enabling AD Connector directory status notifications with Amazon SNS
<a name="ad_connector_enable_notifications"></a>

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

## How it works
<a name="ds_sns_overview"></a>

Amazon SNS uses “topics” to collect and distribute messages. Each topic has one or more subscribers who receive the messages that have been published to that topic. Using the steps below you can add Directory Service as publisher to an Amazon SNS topic. When Directory Service detects a change in your directory’s status, it publishes a message to that topic, which is then sent to the topic's subscribers. 

You can associate multiple directories as publishers to a single topic. You can also add directory status messages to topics that you’ve previously created in Amazon SNS. You have detailed control over who can publish to and subscribe to a topic. For complete information about Amazon SNS, see [What is Amazon SNS?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html).

**To enable SNS messaging for your directory**

1. Sign in to the AWS Management Console and open the [Directory Service console](https://console.aws.amazon.com/directoryservicev2/).

1.  On the **Directories** page, choose your directory ID.

1. Select the **Maintenance** tab.

1. In the **Directory monitoring** section, choose **Actions**, and then select **Create notification**.

1. On the **Create notification** page, select **Choose a notification type**, and then choose **Create a new notification**. Alternatively, if you already have an existing SNS topic, you can choose **Associate existing SNS topic** to send status messages from this directory to that topic.
**Note**  
If you choose **Create a new notification** but then use the same topic name for an SNS topic that already exists, Amazon SNS does not create a new topic, but just adds the new subscription information to the existing topic.  
If you choose **Associate existing SNS topic**, you will only be able to choose an SNS topic that is in the same Region as the directory.

1. Choose the **Recipient type** and enter the **Recipient** contact information. If you enter a phone number for SMS, use numbers only. Do not include dashes, spaces, or parentheses.

1. (Optional) Provide a name for your topic and an SNS display name. The display name is a short name up to 10 characters that is included in all SMS messages from this topic. When using the SMS option, the display name is required. 
**Note**  
If you are logged in using an IAM user or role that has only the [DirectoryServiceFullAccess](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/role_ds_full_access.html) managed policy, your topic name must start with “DirectoryMonitoring”. If you’d like to further customize your topic name you’ll need additional privileges for SNS.

1. Choose **Create**.

If you want to designate additional SNS subscribers, such as an additional email address, Amazon SQS queues or AWS Lambda, you can do this from the [Amazon SNS console](https://console.aws.amazon.com//sns/v3/home.).

**To remove directory status messages from a topic**

1. Sign in to the AWS Management Console and open the [Directory Service console](https://console.aws.amazon.com/directoryservicev2/).

1.  On the **Directories** page, choose your directory ID.

1. Select the **Maintenance** tab.

1. In the **Directory monitoring** section, select an SNS topic name in the list, choose **Actions**, and then select **Remove**.

1. Choose **Remove**.

This removes your directory as a publisher to the selected SNS topic. If you want to delete the entire topic, you can do this from the [Amazon SNS console](https://console.aws.amazon.com/sns/v3/home.).

**Note**  
Before deleting an Amazon SNS topic using the SNS console, you should ensure that a directory is not sending status messages to that topic.   
If you delete an Amazon SNS topic using the SNS console, this change will not immediately be reflected within the Directory Services console. You would only be notified the next time a directory publishes a notification to the deleted topic, in which case you would see an updated status on the directory’s **Monitoring** tab indicating the topic could not be found.  
Therefore, to avoid missing important directory status messages, before deleting any topic that receives messages from Directory Service, associate your directory with a different Amazon SNS topic. 

# Access to AWS applications and services from AD Connector
<a name="ad_connector_manage_apps_services"></a>

You can allow your AD Connector access to AWS applications and services for your connected Active Directory. Some of the supported AWS applications and services include:
+ Amazon Chime
+ Amazon WorkSpaces
+ IAM Identity Center
+ AWS Management Console

There are no third-party applications that work with AD Connector.

**Topics**
+ [Application compatibility policy for AD Connector](ad_connector_app_compatibility.md)
+ [Enabling access to AWS applications and services from AD Connector](ad_connector_enable_apps_services.md)

# Application compatibility policy for AD Connector
<a name="ad_connector_app_compatibility"></a>

As an alternative to AWS Directory Service for Microsoft Active Directory ([AWS Managed Microsoft AD](directory_microsoft_ad.md)), AD Connector is an Active Directory proxy for AWS created applications and services only. You configure the proxy to use a specified Active Directory domain. When the application must look up a user or group in Active Directory, AD Connector proxies the request to the directory. Similarly, when a user logs in to the application, AD Connector proxies the authentication request to the directory. There are no third-party applications that work with AD Connector.

The following is a list of compatible AWS applications and services:
+ Amazon Chime - For detailed instructions, see [Connect to your Active Directory](https://docs.aws.amazon.com/chime/latest/ag/active_directory.html).
+ Amazon Connect - For more information, see [How Amazon Connect works](https://docs.aws.amazon.com/connect/latest/adminguide/what-is-amazon-connect.html#amazon-connect-fundamentals).
+ Amazon EC2 for Windows or Linux – You can use the seamless Active Directory domain join feature of Amazon EC2 Windows or Linux to join your instance to your self-managed Active Directory (on-premises). Once joined, the instance communicates directly with your Active Directory and bypasses AD Connector. For more information, see [Ways to join an Amazon EC2 instance to your Active Directory](ad_connector_join_instance.md).
+ AWS Management Console – You can use AD Connector to authenticate AWS Management Console users with their Active Directory credentials without setting up SAML infrastructure. For more information, see [Enabling AWS Management Console access with AWS Managed Microsoft AD credentials](ms_ad_management_console_access.md).
+ Quick - For more information, see [Managing user accounts in Quick Enterprise Edition](https://docs.aws.amazon.com/quicksight/latest/user/managing-users-enterprise.html).
+ AWS IAM Identity Center - For detailed instructions, see [Connect IAM Identity Center to an on-premises Active Directory](https://docs.aws.amazon.com/singlesignon/latest/userguide/connectawsad.html).
+ AWS Transfer Family - For detailed instructions, see [Working with Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/transfer/latest/userguide/directory-services-users.html).
+ AWS Client VPN - For detailed instructions, see [Client authentication and authorization](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/authentication-authorization.html).
+ WorkDocs - For detailed instructions, see [Connecting to your on-premises directory with AD Connector](https://docs.aws.amazon.com/workdocs/latest/adminguide/connect_directory_connector.html).
+ Amazon WorkMail - For detailed instructions, see [Integrate Amazon WorkMail with an existing directory (standard setup)](https://docs.aws.amazon.com/workmail/latest/adminguide/premises_directory.html).
+ WorkSpaces - For detailed instructions, see [Launch a WorkSpace using AD Connector](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspace-ad-connector.html). 

**Note**  
Amazon RDS is compatible with AWS Managed Microsoft AD only, and is not compatible with AD Connector. For more information, see the AWS Managed Microsoft AD section in the [Directory Service FAQs](https://aws.amazon.com/directoryservice/faqs/#microsoft-ad) page.

# Enabling access to AWS applications and services from AD Connector
<a name="ad_connector_enable_apps_services"></a>

Users can authorize AD Connector to give AWS applications and services, such as Amazon WorkSpaces, access to your Active Directory. The following AWS applications and services can be enabled or disabled to work with AD Connector.


| AWS application / service | More information... | 
| --- | --- | 
| Amazon Chime | For more information, see the [Connecting to Active Directory](https://docs.aws.amazon.com/chime/latest/ag/active_directory.html). | 
| Amazon Connect | For more information, see the [Amazon Connect Administration Guide](https://docs.aws.amazon.com/connect/latest/adminguide/what-is-amazon-connect.html). | 
| Amazon WorkDocs | For more information, see the [Getting started with Amazon WorkDocs](https://docs.aws.amazon.com/workdocs/latest/adminguide/getting_started.html). | 
| Amazon WorkMail |  For more information, see the [ Creating an organization](https://docs.aws.amazon.com/workmail/latest/adminguide/add_new_organization.html).  | 
| Amazon WorkSpaces |  You can create a Simple AD, AWS Managed Microsoft AD, or AD Connector directly from WorkSpaces. Simply launch **Advanced Setup** when creating your Workspace. For more information, see the [Amazon WorkSpaces Administration Guide](https://docs.aws.amazon.com/workspaces/latest/adminguide/).  | 
| AWS Client VPN | For more information, see the [AWS Client VPN User Guide](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/). | 
| AWS IAM Identity Center | For more information, see the [AWS IAM Identity Center User Guide](https://docs.aws.amazon.com/singlesignon/latest/userguide/). | 
| AWS Management Console | For more information, see [Enabling AWS Management Console access with AWS Managed Microsoft AD credentials](ms_ad_management_console_access.md). | 
| AWS Transfer Family | For more information, see the [AWS Transfer Family User Guide](https://docs.aws.amazon.com/transfer/latest/userguide/what-is-aws-transfer-family.html). | 

Once enabled, you manage access to your directories in the console of the application or service that you want to give access to your directory. To find the AWS applications and services links described above in the Directory Service console, perform the following steps.

**To display the applications and services for a directory**

1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, choose **Directories**.

1. On the **Directories** page, choose your directory ID.

1. On the **Directory details** page, select the **Application management** tab.

1. Review the list under the **AWS apps & services** section.

For more information about how to authorize or deauthorize AWS applications and services using Directory Service, see [Authorization for AWS applications and services using Directory Service](ad_manage_apps_services_authorization.md).

# Ways to join an Amazon EC2 instance to your Active Directory
<a name="ad_connector_join_instance"></a>

AD Connector is a directory gateway with which you can redirect directory requests to your on-premises Microsoft Active Directory without caching any information in the cloud. Here's more information on how you can join an Amazon EC2 to an Active Directory domain:
+ You can seamlessly join an Amazon EC2 instance to your Active Directory domain when the instance is launched. For more information on joining an EC2 Windows instance to an AWS Managed Microsoft AD, see [Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD Active Directory](launching_instance.md).
+ If you need to manually join an EC2 instance to your Active Directory domain, you must launch the instance in the proper AWS Region and security group or subnet, then join the instance to the Active Directory domain.
+ To be able to connect remotely to these instances, you must have IP connectivity to the instances from the network you are connecting from. In most cases, this requires that an internet gateway be attached to your Amazon VPC and that the instance has a public IP address. For more information about connecting to the internet using an internet gateway see [Connect to the internet using an internet gateway](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_Internet_Gateway.html) in the Amazon VPC User Guide.

**Note**  
Once you join an instance to your self-managed Active Directory (on-premises), the instance communicates directly with your Active Directory and bypasses AD Connector.

# AD Connector quotas
<a name="ad_connector_limits"></a>

The following are the default quotas for AD Connector. Each quota is per Region unless otherwise noted.


**AD Connector quotas**  

| Resource | Default quota | 
| --- | --- | 
| AD Connector directories | 10 | 
| Maximum number of registered certificate authority (CA) certificates per directory | 5 | 

# Troubleshooting AD Connector
<a name="ad_connector_troubleshooting"></a>

The following can help you troubleshoot some common issues you might encounter when creating or using your AD Connector.

**Topics**
+ [Creation issues](#ad_connector_creation_issues)
+ [Connectivity issues](#ad_connector_connectivity_issues)
+ [Authentication issues](#ad_connector_auth_issues)
+ [Maintenance issues](#ad_connector_maintenance_issues)
+ [I cannot delete my AD Connector](#delete_ad_connector)
+ [General tools for investigating AD Connector issuers](#ad_connector_troubleshooting_tools)

## Creation issues
<a name="ad_connector_creation_issues"></a>

**The following are common creation issues for AD Connector**
+ [I receive an "AZ Constrained" error when I create a directory](#contrained_az2)
+ [I receive a "Connectivity issues detected" error when I try to create AD Connector](#ad_creation_connectivity_issues)

### I receive an "AZ Constrained" error when I create a directory
<a name="contrained_az2"></a>

Some AWS accounts created before 2012 might have access to Availability Zones in the US East (N. Virginia), US West (N. California), or Asia Pacific (Tokyo) Regions that do not support Directory Service directories. If you receive an error such as this when creating a Active Directory, choose a subnet in a different Availability Zone and try to create the directory again.

### I receive a "Connectivity issues detected" error when I try to create AD Connector
<a name="ad_creation_connectivity_issues"></a>

If you receive the "Connectivity issue detected" error when trying to create an AD Connector, the error could be due to port availability or AD Connector password complexity. You can test your AD Connector's connection to see whether the following ports are available:
+ 53 (DNS)
+ 88 (Kerberos)
+ 389 (LDAP)

 To test your connection, see [Test your AD Connector](ad_connector_getting_started.md#connect_verification). The connection test should be performed on the instance joined to both subnets that the AD Connector's IP addresses are associated to.

If the connection test is successful and the instance joins the domain, then check your AD Connector's password. AD Connector must meet AWS password complexity requirements. For more information, see Service account in [AD Connector prerequisites](ad_connector_getting_started.md#prereq_connector).

If your AD Connector does not meet these requirements, recreate your AD Connector with a password that complies with these requirements.

### I receive "An internal service error has been encountered while connecting the directory. Please retry the operation." error when I create an AD Connector
<a name="internal_svc_error"></a>

This error usually occurs when the AD Connector fails to create and can't connect to a valid domain controller for your self-managed Active Directory domain. 

**Note**  
As a [best practice](ad_connector_best_practices.md#ad_connector_config_onprem), if your self-managed network has Active Directory Sites defined, you must ensure the following:  
The VPC subnets where your AD Connector resides are defined in an Active Directory Site.
No conflicts exist between your VPC subnets and the subnets in your other sites.

AD Connector uses the Active Directory Site whose subnet IP address ranges are close to those in the VPC that contain the AD Connector to discover your AD domain controllers. If you have a site whose subnets have the same IP address ranges as those in your VPC, AD Connector will discover the domain controllers in that site. The domain controller may not physically be close to the Region your AD Connector resides in. 
+ Inconsistencies in DNS SRV records (These records use the following syntax: `_ldap._tcp.<DnsDomainName>` and `_kerberos._tcp.<DnsDomainName>`) created in customer managed Active Directory domain. This can occur when AD Connector couldn't find and connect to a valid domain controller based on these SRV records. 
+ Networking issues between AD Connector and customer managed AD such as firewall devices. 

You can use [network packet capture](https://techcommunity.microsoft.com/blog/iis-support-blog/capture-a-network-trace-without-installing-anything--capture-a-network-trace-of-/376503) on your domain controllers, DNS servers, and VPC flow logs of directory network interfaces to investigate this issue. Contact [AWS Support](https://docs.aws.amazon.com//awssupport/latest/user/case-management.html) for further assistance. 

## Connectivity issues
<a name="ad_connector_connectivity_issues"></a>

**The following are common connectivity issues for AD Connector**
+ [I receive a "Connectivity issues detected" error when I try to connect to my on-premises directory](#connectivity_issues_detected)
+ [I receive a "DNS unavailable" error when I try to connect to my on-premises directory](#dns_unavailable)
+ [I receive an "SRV record" error when I try to connect to my on-premises directory](#srv_record_not_found)

### I receive a "Connectivity issues detected" error when I try to connect to my on-premises directory
<a name="connectivity_issues_detected"></a>

You receive an error message similar to the following when connecting to your on-premises directory: Connectivity issues detected: LDAP unavailable (TCP port 389) for IP: *<IP address>* Kerberos/authentication unavailable (TCP port 88) for IP: *<IP address>* Please ensure that the listed ports are available and retry the operation.

AD Connector must be able to communicate with your on-premises domain controllers via TCP and UDP over the following ports. Verify that your security groups and on-premises firewalls allow TCP and UDP communication over these ports. For more information, see [AD Connector prerequisites](ad_connector_getting_started.md#prereq_connector).
+ 88 (Kerberos)
+ 389 (LDAP)

You may need additional TCP/UDP ports depending on your needs. See the following list for some of these ports. For more information about ports used by Active Directory, see [ How to configure a firewall for Active Directory domains and trusts](https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts) in Microsoft documentation.
+ 135 (RPC Endpoint Mapper)
+ 646 (LDAP SSL)
+ 3268 (LDAP GC)
+ 3269 (LDAP GC SSL)

### I receive a "DNS unavailable" error when I try to connect to my on-premises directory
<a name="dns_unavailable"></a>

You receive an error message similar to the following when connecting to your on-premises directory:

```
DNS unavailable (TCP port 53) for IP: <DNS IP address>
```

AD Connector must be able to communicate with your on-premises DNS servers via TCP and UDP over port 53. Verify that your security groups and on-premises firewalls allow TCP and UDP communication over this port. For more information, see [AD Connector prerequisites](ad_connector_getting_started.md#prereq_connector).

### I receive an "SRV record" error when I try to connect to my on-premises directory
<a name="srv_record_not_found"></a>

You receive an error message similar to one or more of the following when connecting to your on-premises directory:

```
SRV record for LDAP does not exist for IP: <DNS IP address> SRV record for Kerberos does not exist for IP: <DNS IP address>
```

AD Connector needs to obtain the `_ldap._tcp.<DnsDomainName>` and `_kerberos._tcp.<DnsDomainName>` SRV records when connecting to your directory. You will get this error if the service cannot obtain these records from the DNS servers that you specified when connecting to your directory. For more information about these SRV records, see [SRV record requirements](ad_connector_getting_started.md#srv_records).

## Authentication issues
<a name="ad_connector_auth_issues"></a>

**Here are some common authentication issues with AD Connector:**
+ [I receive a "Certificate Validation failed" error when I try to sign in to Amazon WorkSpaces with a smart card](#cert_validation_failure)
+ [I receive an "Invalid Credentials" error when the service account used by AD Connector attempts to authenticate](#invalid_creds)
+ [I receive a "Unable to Authenticate" error when using AWS applications to search for users or groups](#fails_when_searching)
+ [I receive an error about my directory credentials when I try to update the AD Connector service account](#error_with_ad_creds)
+ [Some of my users cannot authenticate with my directory](#kerberos_preauth2)

### I receive a "Certificate Validation failed" error when I try to sign in to Amazon WorkSpaces with a smart card
<a name="cert_validation_failure"></a>

You receive an error message similar to the following when you try to sign in to your WorkSpaces with a smart card: **ERROR**: Certificate Validation failed. Please try again by restarting your browser or application and make sure you select the correct certificate. The error occurs if the smart card's certificate is not properly stored on the client that uses the certificates. For more information on AD Connector and smart card requirements, see [Prerequisites](ad_connector_clientauth.md#prereqs-clientauth).

**Use the following procedures to troubleshoot the smart card's ability to store certificates in the user's certificate store:**

1. On the device that is having trouble accessing the certificates, access the Microsoft Management Console (MMC).
**Important**  
Before moving forward, create a copy of the smart card's certificate.

1. Navigate to the certificate store in the MMC. Delete the user's smart card certificate from the certificate store. For more information about viewing the certificate store in the MMC, see [How to: View certificates with the MMC snap-in](https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-view-certificates-with-the-mmc-snap-in) in Microsoft documentation.

1. Remove the smart card.

1. Reinsert the smart card so it can repopulate the smart card certificate in the user's certificate store.
**Warning**  
If the smart card is not repopulating the certificate to the user store then it cannot be used for WorkSpaces smart card authentication.

The AD Connector's Service account should have the following:
+ `my/spn` added to the Service Principle Name
+ Delegated for LDAP service

After the certificate is repopulated on the smart card, the on-premise domain controller should be checked to determine if they are blocked from User Principal Name (UPN) mapping for Subject Alternative Name. For more information about this change, see [ How to disable the Subject Alternative Name for UPN mapping ](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/disable-subject-alternative-name-upn-mapping) in Microsoft documentation.

**Use the following procedure to check your domain controller's registry key:**
+ In the **Registry Editor**, navigate to the following hive key

  **HKEY\$1LOCAL\$1MACHINE\$1SYSTEM\$1CurrentControlSet\$1Services\$1Kdc\$1UseSubjectAltName**

  1. Inspect the value of UseSubjectAltName:

    1. If the value is set to **0**, then **Subject Alternative Name** mapping is **disabled** and you must explicitly map a given certificate to only 1 user. If a certificate is mapped to multiple users and this value is 0, login with that certificate will fail.

    1. If the value is **not set or set to 1**, you must explicitly map a given certificate to only 1 user or use the **Subject Alternative Name** field for login.

       1. If the **Subject Alternative Name** field exists on the certificate, it will be prioritized.

       1. If the **Subject Alternative Name** field does not exist on the certificate and the certificate is explicitly mapped to more than one user, login with that certificate will fail.

**Note**  
If the registry key is set on the on-premise Domain Controllers then the AD Connector will not be able to locate the users in Active Directory and result in the above error message.

The Certificate Authority (CA) certificates should be uploaded to the AD Connector smart card certificate. The certificate should contain OCSP information. The following list additional requirements for the CA: 
+ The certificate should be in the Trusted Root Authority of the Domain Controller, the Certificate Authority Server, and the WorkSpaces.
+ Offline and Root CA certificates will not contain the OSCP information. These certificates contain information about their revocation.
+ If you are using a third-party CA certificate for smart card authentication, then the CA and intermediate certificates need to be published to the Active Directory NTAuth store. They must be installed in the trusted root authority for all domain controllers, certificate authority servers, and WorkSpaces.
  + You can use the follow command to publish certificates to the Active Directory NTAuth store:

    

    ```
    certutil -dspublish -f Third_Party_CA.cer NTAuthCA
    ```

For more information about publishing certificates to the NTAuth store, see [Import the issuing CA certificate into the Enterprise NTAuth store](https://docs.aws.amazon.com//whitepapers/latest/access-workspaces-with-access-cards/import-the-issuing-ca-certificate-into-the-enterprise-ntauth-store.html) in *Access Amazon WorkSpaces with Common Access Cards Installation Guide*.

**You can check to see if the user certificate or CA chain certificates are verified by OCSP by following this procedure:**

1. Export the smart card certificate to a location on the local machine like the C: drive.

1. Open a Command Line prompt and navigate to the location where the exported smart card certificate is stored.

1. Enter the following command:

   ```
   certutil -URL Certficate_name.cer
   ```

1. A pop-up window should appear following the command. Select the **OCSP option** on the right corner and select **Retrieve**. The status should return as verified.

For more information about the certutil command, see [certutil](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil) in Microsoft documentation

### I receive an "Invalid Credentials" error when the service account used by AD Connector attempts to authenticate
<a name="invalid_creds"></a>

This can occur if the hard drive on your domain controller runs out of space. Ensure that your domain controller's hard drives are not full.

### I receive "An error has occurred" or "An unexpected error" when I try to update the AD Connector service account
<a name="error_unexpected_error"></a>

 The following errors or symptoms occur while searching users in AWS Enterprise Applications such as [Amazon WorkSpaces Console Launch Wizard](https://docs.aws.amazon.com//workspaces/latest/adminguide/launch-workspace-ad-connector.html#create-workspace-ad-connector):
+ An Error Has Occurred. If you continue to experience an issue contact the AWS Support Team on the community forums and via AWS Premium Support.
+ An Error Has Occurred. Your directory needs a credential update. Please update the directory credentials.

 If you try to update your AD Connector service account credentials in AD Connector, you might receive the following errors messages:
+ Unexpected error. An unexpected error occurred.
+ An error occurred. There was an error with the service account/password combination. Please try again.

The AD Connector directory's service account resides in the customer managed Active Directory. The account is used as an identity to perform queries and operations on the customer managed Active Directory domain through the AD Connector on behalf of AWS Enterprise Applications. AD Connector uses Kerberos and LDAP to perform these operations.

**The following list explains what these error messages mean:**
+ There could be an issue with the time synchronization and Kerberos. AD Connector sends Kerberos authentication requests to Active Directory. These requests are time sensitive and if the requests are delayed, they will fail. Ensure that there is no time-sync issues between any of the customer managed domain controllers. To resolve this issue, see [ Recommendation - Configure the Root PDC with an Authoritative Time Source and Avoid Widespread Time Skew](https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/configure-the-root-pdc-with-an-authoritative-time-source-and-avoid-widespread-time-skew) in Microsoft documentation. For more information about time service and synchronization, see the following:
  +  [How the Windows Time Service Works](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/how-the-windows-time-service-works)
  + [Maximum tolerance for computer clock synchronization](https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization)
  + [Windows Time service tools and settings](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings?tabs=config)
+ An intermediate network device, with a network [MTU](https://support.microsoft.com/en-us/topic/the-default-mtu-sizes-for-different-network-topologies-b25262c5-d90f-456d-7647-e09192eeeef4) restriction, such as Firewall or VPN hardware configurations, between the AD Connector and customer managed domain controllers, can cause this error due to [network fragmentation](https://en.wikipedia.org/wiki/IP_fragmentation).
  + To verify the MTU restriction, you can perform a [Ping test](https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/mtu-size-matters/1025286) between your customer managed domain controller and an Amazon EC2 instance that is launched in one of your directory subnets that is connected via AD Connector. The frame size should be no larger than the default size of 1500 Bytes
  + The ping test will help you to understand whether the frame size is more than 1500 bytes (also known as Jumbo frames) and they are able to reach the AD Connector VPC and subnet without the need of fragmentation. Further verify with your network team and ensure that Jumbo frames are allowed on the intermediate network devices. 
+ You may face this issue, if [client-side LDAPS](ad_connector_ldap_client_side.md) is enabled on AD Connector, and the certificates are expired. Ensure both server side certificate and CA certificate are valid, haven't expired, and meets the requirements as per the [LDAPs documentation](ad_connector_ldap_client_side.md#prereqs-ldap-client-side).
+ If [Virtual List View Support](https://learn.microsoft.com/en-us/windows/win32/controls/use-virtual-list-view-controls) is disabled in customer managed Active Directory domain, then AWS Applications will not be able to search users because AD Connector uses VLV search in LDAP queries. Virtual List View Support is disabled when the DisableVLVSupport is set to non-zero value. Ensure the [Virtual List View (VLV) Support](https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-analyzer/cc540446(v=exchg.80)?redirectedfrom=MSDN) is enabled in Active Directory using the following steps:

  1.  Login to the Domain Controller as the schema master role owner using an account with Schema Admin credentials.

  1. Select **Start **and then **Run**, and enter **Adsiedit.msc**.

  1.  In the ADSI Edit tool, Connect to **Configuration Partition**, and expand the **Configuration[DomainController] **node.

  1. Expand the** CN=Configuration,DC=DomainName **container.

  1.  Expand the **CN=Services** object.

  1.  Expand the **CN=Windows NT** object.

  1. Select the** CN=Directory Service** object. Select **Properties**.

  1. In the Attributes list, select **msds-Other-Settings**. Select** Edit**.

  1.  In the Values list, select any instance of **DisableVLVSupport=x** where x is not equal to **0**, and select **Remove**.

  1.  After removing, enter **DisableVLVSupport=0**. Select **Add**.

  1. Select **OK**. You can close the ADSI Edit tool. The following image shows the Multi-valued String Editor dialog box in the ADSI Edit window:  
![\[ADSI Edit dialog box with Multi-valued String editor and DisableVLVSupport=0 highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/DisableVLVSupport.png)
**Note**  
In large Active Directory infrastructure with more than 100,000 users, you might only be able to search specific users. However, if you try to list all the users (For example, **Show All Users in WorkSpaces Launch Wizard**) at once, it might result in the same error even if VLV Support is enabled. AD Connector requires the results to be sorted for attribute "CN" using Subtree Index. The Subtree Index is the type of index which prepares the domain controllers for performing a Virtual List View (LDAP) search operation that allows AD Connector to complete a sorted search. This index improves the VLV search and prevents the use of the temporary database table called [MaxTempTableSize](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/view-set-ldap-policy-using-ntdsutil). The size of this table can vary, but by default the maximum number of entries is 10000 (the MaxTempTableSize setting of the Default Query Policy). Increasing the MaxTempTableSize is less efficient than using the Subtree Indexing. To avoid these errors in large AD environments, it is advised to use Subtree Indexing. 

You can enable the Subtree index by modifying the [searchflags](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/mcm-active-directory-indexing-for-the-masses/ba-p/255867) attribute on the attribute definition, in the Active Directory schema, with a value of 65 (0x41), using ADSEdit as per the following steps:

1. Login to the Domain Controller as the schema master role owner using an account with Schema Admin credentials. 

1.  Select **Start** and **Run**, enter **Adsiedit.msc**.

1. In the ADSI Edit tool, connect to** Schema Partition**. 

1. Expand the **CN=Schema,CN=Configuration,DC=DomainName** container.

1. Locate the "**Common-Name**" attribute and right-click and select **Properties**.

1. Locate the **searchFlags **attribute and change its value to **65 (0x41)** for enabling SubTree indexing along with normal Index.

   The following image shows the CN=Common-Name properties dialog box in the ADSI Edit window:  
![\[ADSI Edit dialog box open with searchFlags attribute highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/SUBTREE_INDEX.png)

1. Select **OK**. You can close the ADSI Edit tool.

1. For the confirmation, you should be able to see an event ID 1137 ( Source : Active Directory\$1DomainServices), which indicates that the AD has successfully created the new index for the specified attribute.

For more information, see [Microsoft documentation](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/mcm-active-directory-indexing-for-the-masses/ba-p/255867). 

### I receive a "Unable to Authenticate" error when using AWS applications to search for users or groups
<a name="fails_when_searching"></a>

You may experience errors when searching for users or logging into AWS applications, such as WorkSpaces or Quick, even while the AD Connector status was active. If the AD Connector's service account's password has been changed or is expired, AD Connector can no longer query the Active Directory domain. Contact your AD Administrator and verify the following: 
+ Check the AD Connector service account password has not expired
+ Checked the AD Connector service account does not have the option **User must change password at next logon** enabled. 
+ Check the AD Connector service account is not locked.
+ If you're not sure whether the password is expired or changed, you can reset the service account password and also [update](ad_connector_update_creds.md) the same password in AD Connector.

### I receive an error about my directory credentials when I try to update the AD Connector service account
<a name="error_with_ad_creds"></a>

You receive an error message similar to one or more of the following when trying to update the AD Connector service account:

Message:An Error Has Occurred Your directory needs a credential update. Please update the directory credentials. An Error Has Occurred Your directory needs a credential update. Please update the directory credentials following Update your AD Connector Service Account Credentials Message: An Error Has Occurred Your request has a problem. Please see the following details. There was an error with the service account/password combination

There could be an issue with the time synchronization and Kerberos. AD Connector sends Kerberos authentication requests to Active Directory. These requests are time sensitive and if the requests are delayed, they will fail. To resolve this issue, see [Recommendation - Configure the Root PDC with an Authoritative Time Source and Avoid Widespread Time Skew](https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/configure-the-root-pdc-with-an-authoritative-time-source-and-avoid-widespread-time-skew) in Microsoft documentation. For more information about time service and synchronization, see below:
+ [How the Windows Time Service Works](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/how-the-windows-time-service-works)
+ [Maximum tolerance for computer clock synchronization](https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization)
+ [Windows Time service tools and settings](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings?tabs=config)

### Some of my users cannot authenticate with my directory
<a name="kerberos_preauth2"></a>

Your user accounts must have Kerberos preauthentication enabled. This is the default setting for new user accounts, but it should not be modified. For more information about this setting, go to [Preauthentication](http://technet.microsoft.com/en-us/library/cc961961.aspx) on Microsoft TechNet.

## Maintenance issues
<a name="ad_connector_maintenance_issues"></a>

**The following are common maintenance issues for AD Connector**
+ My directory is stuck in the "Requested" state
+ Seamless domain join for Amazon EC2 instances stopped working

### My directory is stuck in the "Requested" state
<a name="troubleshoot_stuck_in_requested"></a>

If you have a directory that has been in the "Requested" state for more than five minutes, try deleting the directory and recreating it. If this problem persists, contact [AWS Support](https://aws.amazon.com/contact-us/).

### Seamless domain join for Amazon EC2 instances stopped working
<a name="seamless_stops"></a>

If seamless domain join for EC2 instances was working and then stopped while the AD Connector was active, the credentials for your AD Connector service account may have expired. Expired credentials can prevent AD Connector from creating computer objects in your Active Directory. 

**To resolve this issue, update the service account passwords in the following order so that the passwords match:**

1. Update the password for the service account in your Active Directory.

1. Update the password for the service account in your AD Connector in Directory Service. For more information, see [Updating your AD Connector service account credentials in AWS Management Console](ad_connector_update_creds.md).

**Important**  
Updating the password only in Directory Service does not push the password change to your existing on-premises Active Directory so it is important to do it in the order shown in the previous procedure.

## I cannot delete my AD Connector
<a name="delete_ad_connector"></a>

If your AD Connector switches to an inoperable state, you no longer have access to your domain controllers. We block the deletion of an AD Connector when there are still applications linked to it because one of those applications may still be using the directory. For a list of applications you need to disable in order to delete your AD Connector, see [Deleting your AD Connector](ad_connector_delete.md). If you still can't delete your AD Connector, you can request help through [AWS Support](https://aws.amazon.com/contact-us/).

## General tools for investigating AD Connector issuers
<a name="ad_connector_troubleshooting_tools"></a>

The following tools can be used to troubleshoot various AD Connector issues related to creation, authentication, and connectivity:

**DirectoryServicePortTest tool**  
The [DirectoryServicePortTest](samples/DirectoryServicePortTest.zip) testing tool can be helpful when troubleshooting connectivity issues between AD Connector and customer managed Active Directory or DNS servers. For more information on how to use the tool, see [Test your AD Connector](ad_connector_getting_started.md#connect_verification).

**Packet capture tool**  
You can use the built-in Windows package capture utility ([netsh](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj129382(v=ws.11))) to investigate and troubleshoot potential network or Active Directory communication (ldap and kerberos) issue. For more information, see [Capture a Network Trace without installing anything](https://techcommunity.microsoft.com/t5/iis-support-blog/capture-a-network-trace-without-installing-anything-amp-capture/ba-p/376503).

**VPC Flow logs**  
To better understand what requests are being received and sent from AD Connector, you can configure [VPC flow logs](https://docs.aws.amazon.com//vpc/latest/userguide/working-with-flow-logs.html) for the directory network interfaces. You can identify all network interfaces reserved for use with Directory Service by the description: `AWS created network interface for directory your-directory-id`.   
A simple use case is during AD Connector creation with a customer managed Active Directory domain with a large number of domain controllers. You can use VPC flow logs and filter by the Kerberos port (88) to find out what domain controllers in the customer managed Active Directory are being contacted for authentication. 