# Secure your AWS Managed Microsoft AD
You can use password policies, features like multi-factor authentication (MFA), and settings to secure your AWS Managed Microsoft AD. Ways you can secure your directory include:
+ [Understand how the password policies in Active Directory works](ms_ad_password_policies.md) so they can be applied to AWS Managed Microsoft AD users. You can also delegate which user can manage your AWS Managed Microsoft AD password policies.
+ [Enable MFA](ms_ad_mfa.md) which increases your AWS Managed Microsoft AD security.
+ [>Enable Lightweight Directory Access Protocol over Secure Socket Layer (SSL)/Transport Layer Security (TLS) (LDAPS)](ms_ad_ldap.md) so that communications over LDAP are encrypted and improves security.
+ [Manage your AWS Managed Microsoft AD compliance](ms_ad_compliance.md) with standards like Federal Risk and Authorization Management Program (FedRAMP) and Payment Card Industry (PCI) Data Security Standard (DSS).
+ [Enhance your AWS Managed Microsoft AD network security configuration>](ms_ad_network_security.md) by modifying AWS Security Group to meet your environment needs.
+ [Edit your AWS Managed Microsoft AD directory security settings](ms_ad_directory_settings.md) like Certificate Base Authentication, Secure Channel Cipher and Protocol to meet your needs.
+ [Set up AWS Private Certificate Authority Connector for AD](ms_ad_pca_connector.md) so you can issue and manage certificates for your AWS Managed Microsoft AD with AWS Private CA.
# Understanding AWS Managed Microsoft AD password policies
AWS Managed Microsoft AD enables you to define and assign different password and account lockout policies (also referred to as [fine-grained password policies](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements--level-100-#fine_grained_pswd_policy_mgmt)) for groups of users you manage in your AWS Managed Microsoft AD domain. When you create an AWS Managed Microsoft AD directory, a default domain policy is created and applied to the Active Directory. This policy includes the following settings:
****
| Policy | Setting |
| --- | --- |
| Enforce password history | 24 passwords remembered |
| Maximum password age | 42 days \$1 |
| Minimum password age | 1 day |
| Minimum password length | 7 characters |
| Password must meet complexity requirements | Enabled |
| Store passwords using reversible encryption | Disabled |
**Note**
\$1 The 42 day maximum password age includes the admin password.
For example, you can assign a less strict policy setting for employees that have access to low sensitivity information only. For senior managers who regularly access confidential information you can apply more strict settings.
The following resources provide more information on Microsoft Active Directory fine-grained password policies and security policies:
+ [Configure security policy settings](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/how-to-configure-security-policy-settings)
+ [Password complexity requirements](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements)
+ [Password complexity security considerations](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements#security-considerations)
AWS provides a set of fine-grained password policies in AWS Managed Microsoft AD that you can configure and assign to your groups. To configure the policies, you can use standard Microsoft policy tools such as [Active Directory Administrative Center](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/active-directory-administrative-center). To get started with the Microsoft policy tools, see [Installing Active Directory Administration Tools for AWS Managed Microsoft AD](ms_ad_install_ad_tools.md).
## How password policies are applied
There are differences in how the fine-grained password policies are applied depending on whether the password was reset or changed. Domain users can change their own password. An Active Directory administrator or user with the necessary permissions can [ reset users passwords](ms_ad_manage_users_groups_reset_password.md). See the following chart for more information.
****
| Policy | Password Reset | Password Change |
| --- | --- | --- |
| Enforce password history | ![\[No\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/icon-no.png) No | ![\[Yes\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/icon-yes.png) Yes |
| Maximum password age | ![\[Yes\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/icon-yes.png) Yes | ![\[Yes\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/icon-yes.png) Yes |
| Minimum password age | ![\[No\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/icon-no.png) No | ![\[Yes\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/icon-yes.png) Yes |
| Minimum password length | ![\[Yes\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/icon-yes.png) Yes | ![\[Yes\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/icon-yes.png) Yes |
| Password must meet complexity requirements | ![\[Yes\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/icon-yes.png) Yes | ![\[Yes\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/icon-yes.png) Yes |
These differences have security implications. For example, whenever a user's password is reset, the enforce password history and minimum password age policies are not enforced. For more information, see Microsoft documentation on the security considerations related to [enforce password history](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/enforce-password-history#security-considerations) and [minimum password age](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/minimum-password-age#security-considerations) policies.
## Supported policy settings
AWS Managed Microsoft AD includes five fine-grained policies with a non-editable precedence value. The policies have a number of properties you can configure to enforce the strength of passwords, and account lock-out actions in the event of login failures. You can assign the policies to zero or more Active Directory groups. If an end-user is a member of multiple groups and receives more than one password policy, Active Directory enforces the policy with the lowest precedence value.
### AWS pre-defined password policies
The following table lists the five policies included in your AWS Managed Microsoft AD directory and their assigned precedence value. For more information, see [Precedence](#precedence).
****
| Policy name | Precedence |
| --- | --- |
| CustomerPSO-01 | 10 |
| CustomerPSO-02 | 20 |
| CustomerPSO-03 | 30 |
| CustomerPSO-04 | 40 |
| CustomerPSO-05 | 50 |
#### Password policy properties
You may edit the following properties in your password policies to conform to the compliance standards that meet your business needs.
+ Policy name
+ [Enforce password history](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/enforce-password-history)
+ [Minimum password length](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/minimum-password-length)
+ [Minimum password age](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/minimum-password-age)
+ [Maximum password age](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/maximum-password-age)
+ [Store passwords using reversible encryption](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption)
+ [Password must meet complexity requirements](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements)
You cannot modify the precedence values for these policies. For more details about how these settings affect password enforcement, see [AD DS: Fine-grained password policies](https://technet.microsoft.com/en-us/library/cc770394(v=ws.10).aspx) on the *Microsoft TechNet* website. For general information about these policies, see [Password policy](https://technet.microsoft.com/en-us/library/hh994572(v=ws.11).aspx) on the *Microsoft TechNet* website.
### Account lockout policies
You may also modify the following properties of your password policies to specify if and how Active Directory should lockout an account after login failures:
+ Number of failed logon attempts allowed
+ Account lockout duration
+ Reset failed logon attempts after some duration
For general information about these policies, see [Account lockout policy](https://technet.microsoft.com/en-us/library/hh994563(v=ws.11).aspx) on the *Microsoft TechNet* website.
### Precedence
Policies with a lower precedence value have higher priority. You assign password policies to Active Directory security groups. While you should apply a single policy to a security group, a single user may receive more than one password policy. For example, suppose `jsmith` is a member of the HR group and also a member of the MANAGERS group. If you assign **CustomerPSO-05** (which has a precedence of 50) to the HR group, and **CustomerPSO-04** (which has a precedence of 40) to MANAGERS, **CustomerPSO-04** has the higher priority and Active Directory applies that policy to `jsmith`.
If you assign multiple policies to a user or group, Active Directory determines the resultant policy as follows:
1. A policy you assign directly to the user object applies.
1. If no policy is assigned directly to the user object, the policy with the lowest precedence value of all policies received by the user as a result of group membership applies.
For additional details, see [AD DS: Fine-grained password policies](https://technet.microsoft.com/en-us/library/cc770394(v=ws.10).aspx) on the *Microsoft TechNet* website.
**Topics**
+ [How password policies are applied](#how_password_policies_applied)
+ [Supported policy settings](#supportedpolicysettings)
+ [Assigning password policies to your AWS Managed Microsoft AD users](assignpasswordpolicies.md)
+ [Delegating who can manage your AWS Managed Microsoft AD password policies](delegatepasswordpolicies.md)
**Related AWS Security blog article**
+ [How to configure even stronger password policies to help meet your security standards by using Directory Service for AWS Managed Microsoft AD](https://aws.amazon.com/blogs/security/how-to-configure-even-stronger-password-policies-to-help-meet-your-security-standards-by-using-aws-directory-service-for-microsoft-active-directory/)
# Assigning password policies to your AWS Managed Microsoft AD users
User accounts that are a member of the **AWS Delegated Fine Grained Password Policy Administrators** security group can use the following procedure to assign policies to users and security groups.
**To assign password policies to your users**
1. Launch [Active Directory administrative center (ADAC)](https://technet.microsoft.com/en-us/library/dd560651.aspx) from any managed EC2 instance that you joined to your AWS Managed Microsoft AD domain.
1. Switch to the **Tree View** and navigate to **System\$1Password Settings Container**.
1. Double click on the fine-grained policy you want to edit. Click **Add** to edit the policy properties, and add users or security groups to the policy. For more information about the default fine-grained policies provided with AWS Managed Microsoft AD, see [AWS pre-defined password policies](ms_ad_password_policies.md#supportedpwdpolicies).
1. To verify the password policy has been applied, run the following PowerShell command:
```
[Get-ADUserResultantPasswordPolicy](https://docs.microsoft.com/en-us/powershell/module/activedirectory/get-aduserresultantpasswordpolicy?view=windowsserver2022-ps) -Identity 'username'
```
**Note**
Avoid using the `net user` command as its results could be inaccurate.
If you do not configure any of the five password policies in your AWS Managed Microsoft AD directory, Active Directory uses the default domain group policy. For additional details on using **Password Settings Container**, see this [Microsoft blog post](https://blogs.technet.microsoft.com/canitpro/2013/05/29/step-by-step-enabling-and-using-fine-grained-password-policies-in-ad/).
# Delegating who can manage your AWS Managed Microsoft AD password policies
You can delegate permissions to manage password policies to specific user accounts you created in your AWS Managed Microsoft AD by adding the accounts to the **AWS Delegated Fine Grained Password Policy Administrators** security group. When an account becomes a member of this group, the account has permissions to edit and configure any of the password policies listed [previously](ms_ad_password_policies.md#supportedpwdpolicies).
**To delegate who can manage password policies**
1. Launch [Active Directory administrative center (ADAC)](https://technet.microsoft.com/en-us/library/dd560651.aspx) from any managed EC2 instance that you joined to your AWS Managed Microsoft AD domain.
1. Switch to the **Tree View** and navigate to the **AWS Delegated Groups** OU. For more information about this OU, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md).
1. Find the **AWS Delegated Fine Grained Password Policy Administrators** user group. Add any users or groups from your domain to this group.
# Enabling multi-factor authentication for AWS Managed Microsoft AD
You can enable multi-factor authentication (MFA) for your AWS Managed Microsoft AD directory to increase security when your users specify their AD credentials to access Supported Amazon Enterprise applications. When you enable MFA, your users enter their username and password (first factor) as usual, and they must also enter an authentication code (the second factor) they obtain from your virtual or hardware MFA solution. These factors together provide additional security by preventing access to your Amazon Enterprise applications, unless users supply valid user credentials and a valid MFA code.
To enable MFA, you must have an MFA solution that is a [Remote authentication dial-in user service](https://en.wikipedia.org/wiki/RADIUS) (RADIUS) server, or you must have an MFA plugin to a RADIUS server already implemented in your on-premises infrastructure. Your MFA solution should implement One Time Passcodes (OTP) that users obtain from a hardware device or from software running on a device such as a cell phone.
RADIUS is an industry-standard client/server protocol that provides authentication, authorization, and accounting management to enable users to connect to network services. AWS Managed Microsoft AD includes a RADIUS client that connects to the RADIUS server upon which you have implemented your MFA solution. Your RADIUS server validates the username and OTP code. If your RADIUS server successfully validates the user, AWS Managed Microsoft AD then authenticates the user against Active Directory. Upon successful Active Directory authentication, users can then access the AWS application. Communication between the AWS Managed Microsoft AD RADIUS client and your RADIUS server require you to configure AWS security groups that enable communication over port 1812.
You can enable multi-factor authentication for your AWS Managed Microsoft AD directory by performing the following procedure. For more information about how to configure your RADIUS server to work with Directory Service and MFA, see [Multi-factor authentication prerequisites](ms_ad_getting_started.md#prereq_mfa_ad).
## Considerations
The following are some considerations for multi-factor authentication for your AWS Managed Microsoft AD:
+ Multi-factor authentication is not available for Simple AD. However, MFA can be enabled for your AD Connector directory. For more information, see [Enabling multi-factor authentication for AD Connector](ad_connector_mfa.md).
+ MFA is a Regional feature of AWS Managed Microsoft AD. If you are using [Multi-Region replication](ms_ad_configure_multi_region_replication.md), you will only be able to use MFA in the Primary Region of your AWS Managed Microsoft AD.
+ If you intend to use AWS Managed Microsoft AD for external communications, we recommend you configure a Network Address Translation (NAT) Internet Gateway or Internet Gateway outside of the AWS network for these communications.
+ If you wish to support external communications between your AWS Managed Microsoft AD and your RADIUS server hosted on the AWS network, please contact [Support](https://console.aws.amazon.com/support/home#/).
+ All Amazon Enterprise IT applications including WorkSpaces, WorkDocs, Amazon WorkMail, Amazon Quick, and access to AWS IAM Identity Center and AWS Management Console are supported when using AWS Managed Microsoft AD and AD Connector with MFA. These AWS applications using MFA are not supported in multi-regions.
For more information, see[How to enable multi-factor authentication for AWS services by using AWS Managed Microsoft AD and on-premises credentials](https://aws.amazon.com/blogs/security/how-to-enable-multi-factor-authentication-for-amazon-workspaces-and-amazon-quicksight-by-using-microsoft-ad-and-on-premises-credentials/).
+ For information about how to configure basic user access to Amazon Enterprise applications, AWS Single Sign-On and the AWS Management Console using Directory Service, see [Access to AWS applications and services from your AWS Managed Microsoft AD](ms_ad_manage_apps_services.md) and [Enabling AWS Management Console access with AWS Managed Microsoft AD credentials](ms_ad_management_console_access.md).
+ See the following this AWS Security Blog post to learn how to enable MFA for Amazon WorkSpaces users on your AWS Managed Microsoft AD, [How to enable multi-factor authentication for AWS services by using AWS Managed Microsoft AD and on-premises credentials](https://aws.amazon.com/blogs/security/how-to-enable-multi-factor-authentication-for-amazon-workspaces-and-amazon-quicksight-by-using-microsoft-ad-and-on-premises-credentials/)
## Enable multi-factor authentication for AWS Managed Microsoft AD
The following procedure shows you how to enable multi-factor authentication for AWS Managed Microsoft AD.
1. Identify the IP address of your RADIUS MFA server and your AWS Managed Microsoft AD directory.
1. Edit your Virtual Private Cloud (VPC) security groups to enable communications over port 1812 between your AWS Managed Microsoft AD IP end points and your RADIUS MFA server.
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 AWS Managed Microsoft AD directory.
1. On the **Directory details** page, do one of the following:
+ If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to enable MFA, and then choose the **Networking & security** tab. For more information, see [Primary vs additional Regions](multi-region-global-primary-additional.md).
+ If you do not have any Regions showing under **Multi-Region replication**, choose 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. Amazon Enterprise applications and services are only supported in the Primary Region if Multi-Region replication is configured for your AWS Managed Microsoft AD. 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 user name and password. Alternatively, you must use a solution that performs MFA out-of-band such as push notification or authenticator one-time passwords (OTP) 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, users must 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.
We recommend configuring your RADIUS server timeout to 20 seconds or less. If the timeout exceeds 20 seconds, the system cannot retry with another RADIUS server and may result in a timeout failure.
**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**.
# Enable Secure LDAP or LDAPS
Lightweight Directory Access Protocol (LDAP) is a standard communications protocol used to read and write data to and from Active Directory. Some applications use LDAP to add, remove, or search users and groups in Active Directory or to transport credentials for authenticating users in Active Directory. Every LDAP communication includes a client (such as an application) and a server (such as Active Directory).
By default, communications over LDAP are not encrypted. This makes it possible for a malicious user to use network monitoring software to view data packets over the wire. This is why many corporate security policies typically require that organizations encrypt all LDAP communication.
To mitigate this form of data exposure, AWS Managed Microsoft AD provides an option: You can enable LDAP over Secure Sockets Layer (SSL)/Transport Layer Security (TLS), also known as LDAPS. With LDAPS, you can improve security across the wire. You can also meet compliance requirements by encrypting all communications between your LDAP-enabled applications and AWS Managed Microsoft AD.
AWS Managed Microsoft AD provides support for LDAPS in the following deployment scenarios:
+ **Server-side LDAPS** encrypts LDAP communications between your commercial or homegrown LDAP-aware applications (acting as LDAP clients) and AWS Managed Microsoft AD (acting as an LDAP server). For more information, see [Enabling server-side LDAPS using AWS Managed Microsoft AD](ms_ad_ldap_server_side.md).
+ **Client-side LDAPS** encrypts LDAP communications between AWS applications such as WorkSpaces (acting as LDAP clients) and your self-managed (on-premises) Active Directory (acting as LDAP server). For more information, see [Enabling client-side LDAPS using AWS Managed Microsoft AD](ms_ad_ldap_client_side.md).
For more information on best practices regarding securing your implementation of Microsoft Active Directory Certificate Services, see [Microsoft documentation](https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-prevent-users-request-certificate).
**Topics**
+ [Enabling server-side LDAPS using AWS Managed Microsoft AD](ms_ad_ldap_server_side.md)
+ [Enabling client-side LDAPS using AWS Managed Microsoft AD](ms_ad_ldap_client_side.md)
# Enabling server-side LDAPS using AWS Managed Microsoft AD
Server-side Lightweight Directory Access Protocol Secure Sockets Layer (SSL)/Transport Layer Security (TLS) (LDAPS) support encrypts LDAP communications between your commercial or homegrown LDAP-aware applications and your AWS Managed Microsoft AD directory. This helps to improve security across the wire and meet compliance requirements using the Secure Sockets Layer (SSL) cryptographic protocol.
## Enable server-side LDAPS using AWS Private Certificate Authority
For detailed instructions on how to set up and configure server-side LDAPS and your certificate authority (CA) server using AWS Private CA, see [Set up AWS Private CA Connector for AD for AWS Managed Microsoft AD](ms_ad_pca_connector.md).
## Enable server-side LDAPS using Microsoft CA
For detailed instructions on how to set up and configure server-side LDAPS and your certificate authority (CA) server, see [How to Enable Server-Side LDAPS for Your AWS Managed Microsoft AD Directory](https://aws.amazon.com/blogs/security/how-to-enable-ldaps-for-your-aws-microsoft-ad-directory/) on the AWS Security Blog.
You must do most of the setup from the Amazon EC2 instance that you use to manage your AWS Managed Microsoft AD domain controllers. The following steps guide you through enabling LDAPS for your domain in the AWS Cloud.
If you would like to use automation to setup your PKI Infrastructure, you can use the [Microsoft Public Key Infrastructure on AWS QuickStart Guide](https://aws.amazon.com/quickstart/architecture/microsoft-pki/). Specifically you will want to follow the instructions in the guide to load the template for [Deploy MicrosoftPKI into an existing VPC on AWS](https://aws-quickstart.github.io/quickstart-microsoft-pki/#_deployment_steps). Once you load the template, be sure to choose **`AWSManaged`** when you get to the **Active Directory Domain Services Type** option. If you used the QuickStart guide, you can jump directly to [Step 3: Create a certificate template](#createcustomcert).
**Topics**
+ [Step 1: Delegate who can enable LDAPS](#grantpermsldaps)
+ [Step 2: Set up your certificate authority](#setupca)
+ [Step 3: Create a certificate template](#createcustomcert)
+ [Step 4: Add security group rules](#addgrouprules)
### Step 1: Delegate who can enable LDAPS
To enable server-side LDAPS, you must be a member of the Admins or AWS Delegated Enterprise Certificate Authority Administrators group in your AWS Managed Microsoft AD directory. Alternatively, you can be the default administrative user (Admin account). If you prefer, you can have a user other than the Admin account setup LDAPS. In that case, add that user to the Admins or AWS Delegated Enterprise Certificate Authority Administrators group in your AWS Managed Microsoft AD directory.
### Step 2: Set up your certificate authority
Before you can enable server-side LDAPS, you must create a certificate. This certificate must be issued by a Microsoft Enterprise CA server that is joined to your AWS Managed Microsoft AD domain. Once created, the certificate must be installed on each of your domain controllers in that domain. This certificate lets the LDAP service on the domain controllers listen for and automatically accept SSL connections from LDAP clients.
**Note**
Server-side LDAPS with AWS Managed Microsoft AD does not support certificates that are issued by a standalone CA. It also does not support certificates issued by a third-party certification authority.
Depending on your business need, you have the following options for setting up or connecting to a CA in your domain:
+ **Create a subordinate Microsoft Enterprise CA** – (Recommended) With this option, you can deploy a subordinate Microsoft Enterprise CA server in the AWS Cloud. The server can use Amazon EC2 so that it works with your existing root Microsoft CA. For more information about how to set up a subordinate Microsoft Enterprise CA, see **Step 4: Add a Microsoft Enterprise CA to your AWS Microsoft AD directory** in [How to Enable Server-Side LDAPS for Your AWS Managed Microsoft AD Directory](https://aws.amazon.com/blogs/security/how-to-enable-ldaps-for-your-aws-microsoft-ad-directory/).
+ **Create a root Microsoft Enterprise CA** – With this option, you can create a root Microsoft Enterprise CA in the AWS Cloud using Amazon EC2 and join it to your AWS Managed Microsoft AD domain. This root CA can issue the certificate to your domain controllers. For more information about setting up a new root CA, see **Step 3: Install and configure an offline CA** in [How to Enable Server-Side LDAPS for Your AWS Managed Microsoft AD Directory](https://aws.amazon.com/blogs/security/how-to-enable-ldaps-for-your-aws-microsoft-ad-directory/).
For more information about how to join your EC2 instance to the domain, see [Ways to join an Amazon EC2 instance to your AWS Managed Microsoft AD](ms_ad_join_instance.md).
### Step 3: Create a certificate template
After your Enterprise CA has been set up, you can configure the Kerberos Authentication certificate template.
**To create a certificate template**
1. Launch **Microsoft Windows Server Manager**. Select **Tools > Certification Authority**.
1. In the **Certificate Authority** window, expand the **Certificate Authority** tree in the left pane. Right-click **Certificate Templates**, and choose **Manage**.
1. In the** Certificate Templates Console** window, right-click **Kerberos Authentication** and choose **Duplicate Template**.
1. The **Properties of New Template** window will pop up.
1. In the** Properties of New Template** window, go to the **Compatibility** tab, and then do the following:
1. Change **Certification Authority** to the OS that matches your CA.
1. If a **Resulting changes** window pops up, select **OK**.
1. Change **Certification recipient** to **Windows 10 / Windows Server 2016**.
**Note**
AWS Managed Microsoft AD is powered by Windows Server 2019.
1. If a **Resulting changes** windows pops up, select **OK**.
1. Click the **General **tab and change the **Template display name** to **LDAPOverSSL** or any other name you would prefer.
1. Click the **Security **tab, and choose **Domain Controllers** in the **Group or user names** section. In the **Permissions for Domain Controllers** section, verify that the **Allow** check boxes for **Read**, **Enroll**, and **Autoenroll** are checked.
1. Choose **OK** to create the **LDAPOverSSL** (or the name you specified above) certificate template. Close the **Certificate Templates Console** window.
1. In the **Certificate Authority** window, right-click **Certificate Templates**, and choose **New > Certificate Template to Issue**.
1. In the **Enable Certificate Templates** window, choose **LDAPOverSSL** (or the name you specified above), and then choose **OK**.
### Step 4: Add security group rules
In the final step, you must open the Amazon EC2 console and add security group rules. These rules allow your domain controllers to connect to your Enterprise CA to request a certificate. To do this, you add inbound rules so that your Enterprise CA can accept incoming traffic from your domain controllers. Then you add outbound rules to allow traffic from your domain controllers to the Enterprise CA.
Once both rules have been configured, your domain controllers request a certificate from your Enterprise CA automatically and enable LDAPS for your directory. The LDAP service on your domain controllers is now ready to accept LDAPS connections.
**To configure security group rules**
1. Navigate to your Amazon EC2 console at [https://console.aws.amazon.com/ec2](https://console.aws.amazon.com/ec2) and sign in with administrator credentials.
1. In the left pane, choose **Security Groups** under **Network & Security**.
1. In the main pane, choose the AWS security group for your CA.
1. Choose the **Inbound** tab, and then choose **Edit**.
1. In the **Edit inbound rules** dialog box, do the following:
+ Choose **Add Rule**.
+ Choose **All traffic** for **Type** and **Custom** for **Source**.
+ Enter AWS security group (for example, `sg-123456789`) for your directory in the box next to **Source**.
+ Choose **Save**.
1. Now choose the AWS security group of your AWS Managed Microsoft AD directory. Choose the **Outbound** tab and then choose **Edit**.
1. In the **Edit outbound rules** dialog box, do the following:
+ Choose **Add Rule**.
+ Choose **All traffic** for **Type** and **Custom** for **Destination**.
+ Enter the AWS security group for your CA in the box next to **Destination**.
+ Choose **Save**.
You can test the LDAPS connection to the AWS Managed Microsoft AD directory using the LDP tool. The LDP tool comes with the Active Directory Administrative Tools. For more information, see [Installing Active Directory Administration Tools for AWS Managed Microsoft AD](ms_ad_install_ad_tools.md).
**Note**
Before you test the LDAPS connection, you must wait up to 30 minutes for the subordinate CA to issue a certificate to your domain controllers.
For additional details about server-side LDAPS and to see an example use case on how to set it up, see [How to Enable Server-Side LDAPS for Your AWS Managed Microsoft AD Directory](https://aws.amazon.com/blogs/security/how-to-enable-ldaps-for-your-aws-microsoft-ad-directory/) on the AWS Security Blog.
# Enabling client-side LDAPS using AWS Managed Microsoft AD
Client-side Lightweight Directory Access Protocol Secure Sockets Layer (SSL)/Transport Layer Security (TLS) (LDAPS) support in AWS Managed Microsoft AD encrypts communications between self-managed (on-premises) 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.
## Prerequisites
Before you enable client-side LDAPS, you need to meet the following requirements.
**Topics**
+ [Create a trust relationship between your AWS Managed Microsoft AD and self-managed Microsoft Active Directory](#trust_relationship_MAD_and_self_managed)
+ [Deploy server certificates in Active Directory](#ldap_client_side_deploy_server_certs)
+ [Certificate Authority certificate requirements](#ldap_client_side_get_certs_ready)
+ [Networking requirements](#ldap_client_side_considerations_enabling)
### Create a trust relationship between your AWS Managed Microsoft AD and self-managed Microsoft Active Directory
First, you need to establish a trust relationship between your AWS Managed Microsoft AD and self-managed Microsoft Active Directory to enable client-side LDAPS. For more information, see [Creating a trust relationship between your AWS Managed Microsoft AD and self-managed AD](ms_ad_setup_trust.md).
### Deploy server certificates in Active Directory
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.
### Certificate Authority certificate requirements
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:
+ Enterprise Certification Authority (CA) is required to enable client-side LDAPS. You can use either Active Directory Certificate Service, a third-party commercial certificate authority, or [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html). For more information about Microsoft Enterprise Certificate Authority, see [Microsoft documentation](https://learn.microsoft.com/en-us/previous-versions/tn-archive/cc875810(v=technet.10)?redirectedfrom=MSDN).
+ 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 AWS Managed Microsoft AD directory.
+ Certificates using the RSASSA-PSS signature algorithm are not supported.
+ CA certificates that chain to every server certificate in every trusted domain must be registered.
### Networking requirements
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 AWS Managed Microsoft AD (outbound) and self-managed Active Directory (inbound). Leave open LDAP port 389 between AWS Managed Microsoft AD and self-managed Active Directory.
## Enable client-side LDAPS
To enable client-side LDAPS, you import your certificate authority (CA) certificate into AWS Managed Microsoft AD, 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.
**Note**
Client-Side LDAPS is a Regional feature of AWS Managed Microsoft AD. If you are using [Multi-Region replication](ms_ad_configure_multi_region_replication.md), the following procedures must be applied separately in each Region. For more information, see [Global vs Regional features](multi-region-global-region-features.md).
**Topics**
+ [Step 1: Register a certificate in Directory Service](#ms_ad_registercert)
+ [Step 2: Check registration status](#ms_ad_check-registration-status)
+ [Step 3: Enable client-side LDAPS](#ms_ad_enableclientsideldapssteps)
+ [Step 4: Check LDAPS status](#ms_ad_check-ldaps-status)
### Step 1: Register a certificate in Directory Service
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, do one of the following:
+ If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to register your certificate, and then choose the **Networking & security** tab. For more information, see [Primary vs additional Regions](multi-region-global-primary-additional.md).
+ If you do not have any Regions showing under **Multi-Region replication**, 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
```
### Step 2: Check registration status
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
```
### Step 3: Enable client-side LDAPS
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
```
### Step 4: Check LDAPS status
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
```
## Manage client-side LDAPS
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
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, do one of the following:
+ If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to view the certificate, and then choose the **Networking & security** tab. For more information, see [Primary vs additional Regions](multi-region-global-primary-additional.md).
+ If you do not have any Regions showing under **Multi-Region replication**, 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
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, do one of the following:
+ If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to deregister a certificate, and then choose the **Networking & security** tab. For more information, see [Primary vs additional Regions](multi-region-global-primary-additional.md).
+ If you do not have any Regions showing under **Multi-Region replication**, 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
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, do one of the following:
+ If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to disable client-side LDAPS, and then choose the **Networking & security** tab. For more information, see [Primary vs additional Regions](multi-region-global-primary-additional.md).
+ If you do not have any Regions showing under **Multi-Region replication**, 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
```
## Certificate enrollment issues
The process to enroll your AWS Managed Microsoft AD domain controllers with the CA certificates can take up to 30 minutes. If you experience issues with the certificate enrollment and want to restart your AWS Managed Microsoft AD domain controllers, you can contact Support. To create a support case, see [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
# Manage compliance for AWS Managed Microsoft AD
You can use AWS Managed Microsoft AD to support your Active Directory–aware applications, in the AWS Cloud, that are subject to the following compliance requirements. However, your applications will not adhere to compliance requirements if you use Simple AD.
## Supported compliance standards
AWS Managed Microsoft AD has undergone auditing for the following standards and is eligible for use as part of solutions for which you need to obtain compliance certification.
****
| | |
| --- |--- |
| ![\[FedRamp Logo\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/FedRAMP.png) | AWS Managed Microsoft AD meets Federal Risk and Authorization Management Program (FedRAMP) security requirements and has received a FedRAMP Joint Authorization Board (JAB) Provisional Authority to Operate (P-ATO) at the FedRAMP Moderate and High Baseline. For more information about FedRAMP, see [FedRAMP compliance](https://aws.amazon.com/compliance/fedramp/). |
| ![\[PCI Logo\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/PCI.png) | AWS Managed Microsoft AD has an Attestation of Compliance for Payment Card Industry (PCI) Data Security Standard (DSS) version 3.2 at Service Provider Level 1. Customers who use AWS products and services to store, process, or transmit cardholder data can use AWS Managed Microsoft AD as they manage their own PCI DSS compliance certification. For more information about PCI DSS, including how to request a copy of the AWS PCI Compliance Package, see [PCI DSS level 1](http://aws.amazon.com/compliance/pci-dss-level-1-faqs/). Importantly, you must configure fine-grained password policies in AWS Managed Microsoft AD to be consistent with PCI DSS version 3.2 standards. For details on which policies must be enforced, see the section below titled Enable PCI Compliance for Your AWS Managed Microsoft AD Directory. |
| ![\[HIPPA Logo\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/HIPAA.jpg) | AWS has expanded its Health Insurance Portability and Accountability Act (HIPAA) compliance program to include AWS Managed Microsoft AD as a [HIPAA eligible service](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/). If you have an executed Business Associate Agreement (BAA) with AWS, you can use AWS Managed Microsoft AD to help build your HIPAA-compliant applications. AWS offers a [HIPAA-focused whitepaper](https://docs.aws.amazon.com/pdfs/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.pdf) for customers who are interested in learning more about how they can leverage AWS for the processing and storage of health information. For more information, see [HIPAA compliance](https://aws.amazon.com/compliance/hipaa-compliance/). |
## Shared responsibility
Security, including FedRAMP, HIPAA and PCI compliance, is a [shared responsibility](https://aws.amazon.com/compliance/shared-responsibility-model/). It is important to understand that AWS Managed Microsoft AD compliance status does not automatically apply to applications that you run in the AWS Cloud. You need to ensure that your use of AWS services complies with the standards.
For a complete list of all the various AWS compliance programs that AWS Managed Microsoft AD supports, see [AWS services in scope by compliance program](https://aws.amazon.com/compliance/services-in-scope/).
## Enable PCI compliance for your AWS Managed Microsoft AD directory
To enable PCI compliance for your AWS Managed Microsoft AD directory, you must configure fine-grained password policies as specified in the PCI DSS Attestation of Compliance (AOC) and Responsibility Summary document provided by AWS Artifact.
For more information about using fine-grained password policies, see [Understanding AWS Managed Microsoft AD password policies](ms_ad_password_policies.md).
# Enhancing your AWS Managed Microsoft AD network security configuration
The AWS Security Group that is provisioned for the AWS Managed Microsoft AD directory is configured with the minimum inbound network ports required to support all known use cases for your AWS Managed Microsoft AD directory. For more information on the provisioned AWS Security Group, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md).
To further enhance the network security of your AWS Managed Microsoft AD directory, you can modify the AWS Security Group based on the following common scenarios.
**Customer domain controllers CIDR** - This CIDR block is where your domain on-premises domain controllers reside.
**Customer client CIDR** - This CIDR block is where your clients such as computers or users authenticate to your AWS Managed Microsoft AD. Your AWS Managed Microsoft AD domain controllers also reside in this CIDR block.
**Topics**
+ [AWS applications only support](#aws_apps_support)
+ [AWS applications only with trust support](#aws_apps_trust_support)
+ [AWS applications and native Active Directory workload support](#aws_apps_native_ad_support)
+ [AWS applications and native Active Directory workload support with trust support](#aws_apps_native_ad_trust_support)
## AWS applications only support
All user accounts are provisioned only in your AWS Managed Microsoft AD to be used with supported AWS applications, such as the following:
+ Amazon Chime
+ Amazon Connect
+ Quick
+ AWS IAM Identity Center
+ WorkDocs
+ Amazon WorkMail
+ AWS Client VPN
+ AWS Management Console
You can use the following AWS Security Group configuration to block all non-essential traffic to your AWS Managed Microsoft AD domain controllers.
**Note**
The following are not compatible with this AWS Security Group configuration:
Amazon EC2 instances
Amazon FSx
Amazon RDS for MySQL
Amazon RDS for Oracle
Amazon RDS for PostgreSQL
Amazon RDS for SQL Server
WorkSpaces
Active Directory trusts
Domain joined clients or servers
**Inbound Rules**
None.
**Outbound Rules**
None.
## AWS applications only with trust support
All user accounts are provisioned in your AWS Managed Microsoft AD or trusted Active Directory to be used with supported AWS applications, such as the following:
+ Amazon Chime
+ Amazon Connect
+ Quick
+ AWS IAM Identity Center
+ WorkDocs
+ Amazon WorkMail
+ Amazon WorkSpaces
+ AWS Client VPN
+ AWS Management Console
You can modify the provisioned AWS Security Group configuration to block all non-essential traffic to your AWS Managed Microsoft AD domain controllers.
**Note**
The following are not compatible with this AWS Security Group configuration:
Amazon EC2 instances
Amazon FSx
Amazon RDS for MySQL
Amazon RDS for Oracle
Amazon RDS for PostgreSQL
Amazon RDS for SQL Server
WorkSpaces
Active Directory trusts
Domain joined clients or servers
This configuration requires you to ensure the "customer domain controllers CIDR" network is secure.
TCP 445 is used for trust creation only and can be removed after the trust has been established.
TCP 636 is only required when LDAP over SSL is in use.
**Inbound Rules**
****
| Protocol | Port range | Source | Type of traffic | Active Directory usage |
| --- | --- | --- | --- | --- |
| TCP & UDP | 53 | Customer domain controllers CIDR | DNS | User and computer authentication, name resolution, trusts |
| TCP & UDP | 88 | Customer domain controllers CIDR | Kerberos | User and computer authentication, forest level trusts |
| TCP & UDP | 389 | Customer domain controllers CIDR | LDAP | Directory, replication, user and computer authentication group policy, trusts |
| TCP & UDP | 464 | Customer domain controllers CIDR | Kerberos change / set password | Replication, user and computer authentication, trusts |
| TCP | 445 | Customer domain controllers CIDR | SMB / CIFS | Replication, user and computer authentication, group policy trusts |
| TCP | 135 | Customer domain controllers CIDR | Replication | RPC, EPM |
| TCP | 636 | Customer domain controllers CIDR | LDAP SSL | Directory, replication, user and computer authentication group policy, trusts |
| TCP | 49152 - 65535 | Customer domain controllers CIDR | RPC | Replication, user and computer authentication, group policy, trusts |
| TCP | 3268 - 3269 | Customer domain controllers CIDR | LDAP GC & LDAP GC SSL | Directory, replication, user and computer authentication group policy, trusts |
| UDP | 123 | Customer domain controllers CIDR | Windows Time | Windows Time, trusts |
**Outbound Rules**
****
| Protocol | Port range | Source | Type of traffic | Active Directory usage |
| --- | --- | --- | --- | --- |
| All | All | Customer domain controllers CIDR | All traffic | |
## AWS applications and native Active Directory workload support
User accounts are provisioned only in your AWS Managed Microsoft AD to be used with supported AWS applications, such as the following:
+ Amazon Chime
+ Amazon Connect
+ Amazon EC2 instances
+ Amazon FSx
+ Quick
+ Amazon RDS for MySQL
+ Amazon RDS for Oracle
+ Amazon RDS for PostgreSQL
+ Amazon RDS for SQL Server
+ AWS IAM Identity Center
+ WorkDocs
+ Amazon WorkMail
+ WorkSpaces
+ AWS Client VPN
+ AWS Management Console
You can modify the provisioned AWS Security Group configuration to block all non-essential traffic to your AWS Managed Microsoft AD domain controllers.
**Note**
Active Directory trusts cannot be created and maintained between your AWS Managed Microsoft AD directory and customer domain controllers CIDR.
It requires you to ensure the "customer client CIDR" network is secure.
TCP 636 is only required when LDAP over SSL is in use.
If you want to use an Enterprise CA with this configuration you will need to create an outbound rule "TCP, 443, CA CIDR".
**Inbound Rules**
****
| Protocol | Port range | Source | Type of traffic | Active Directory usage |
| --- | --- | --- | --- | --- |
| TCP & UDP | 53 | Customer client CIDR | DNS | User and computer authentication, name resolution, trusts |
| TCP & UDP | 88 | Customer client CIDR | Kerberos | User and computer authentication, forest level trusts |
| TCP & UDP | 389 | Customer client CIDR | LDAP | Directory, replication, user and computer authentication group policy, trusts |
| TCP & UDP | 445 | Customer client CIDR | SMB / CIFS | Replication, user and computer authentication, group policy trusts |
| TCP & UDP | 464 | Customer client CIDR | Kerberos change / set password | Replication, user and computer authentication, trusts |
| TCP | 135 | Customer client CIDR | Replication | RPC, EPM |
| TCP | 636 | Customer client CIDR | LDAP SSL | Directory, replication, user and computer authentication group policy, trusts |
| TCP | 49152 - 65535 | Customer client CIDR | RPC | Replication, user and computer authentication, group policy, trusts |
| TCP | 3268 - 3269 | Customer client CIDR | LDAP GC & LDAP GC SSL | Directory, replication, user and computer authentication group policy, trusts |
| TCP | 9389 | Customer client CIDR | SOAP | AD DS web services |
| UDP | 123 | Customer client CIDR | Windows Time | Windows Time, trusts |
| UDP | 138 | Customer client CIDR | DFSN & NetLogon | DFS, group policy |
**Outbound Rules**
None.
## AWS applications and native Active Directory workload support with trust support
All user accounts are provisioned in your AWS Managed Microsoft AD or trusted Active Directory to be used with supported AWS applications, such as the following:
+ Amazon Chime
+ Amazon Connect
+ Amazon EC2 instances
+ Amazon FSx
+ Quick
+ Amazon RDS for MySQL
+ Amazon RDS for Oracle
+ Amazon RDS for PostgreSQL
+ Amazon RDS for SQL Server
+ AWS IAM Identity Center
+ WorkDocs
+ Amazon WorkMail
+ WorkSpaces
+ AWS Client VPN
+ AWS Management Console
You can modify the provisioned AWS Security Group configuration to block all non-essential traffic to your AWS Managed Microsoft AD domain controllers.
**Note**
It requires you to ensure the "customer domain controllers CIDR" and "customer client CIDR" networks are secure.
TCP 445 with the "customer domain controllers CIDR" is used for trust creation only and can be removed after the trust has been established.
TCP 445 with the "customer client CIDR" should be left open as it is required for Group Policy processing.
TCP 636 is only required when LDAP over SSL is in use.
If you want to use an Enterprise CA with this configuration you will need to create an outbound rule "TCP, 443, CA CIDR".
**Inbound Rules**
****
| Protocol | Port range | Source | Type of traffic | Active Directory usage |
| --- | --- | --- | --- | --- |
| TCP & UDP | 53 | Customer domain controllers CIDR | DNS | User and computer authentication, name resolution, trusts |
| TCP & UDP | 88 | Customer domain controllers CIDR | Kerberos | User and computer authentication, forest level trusts |
| TCP & UDP | 389 | Customer domain controllers CIDR | LDAP | Directory, replication, user and computer authentication group policy, trusts |
| TCP & UDP | 464 | Customer domain controllers CIDR | Kerberos change / set password | Replication, user and computer authentication, trusts |
| TCP | 445 | Customer domain controllers CIDR | SMB / CIFS | Replication, user and computer authentication, group policy trusts |
| TCP | 135 | Customer domain controllers CIDR | Replication | RPC, EPM |
| TCP | 636 | Customer domain controllers CIDR | LDAP SSL | Directory, replication, user and computer authentication group policy, trusts |
| TCP | 49152 - 65535 | Customer domain controllers CIDR | RPC | Replication, user and computer authentication, group policy, trusts |
| TCP | 3268 - 3269 | Customer domain controllers CIDR | LDAP GC & LDAP GC SSL | Directory, replication, user and computer authentication group policy, trusts |
| UDP | 123 | Customer domain controllers CIDR | Windows Time | Windows Time, trusts |
| TCP & UDP | 53 | Customer domain controllers CIDR | DNS | User and computer authentication, name resolution, trusts |
| TCP & UDP | 88 | Customer domain controllers CIDR | Kerberos | User and computer authentication, forest level trusts |
| TCP & UDP | 389 | Customer domain controllers CIDR | LDAP | Directory, replication, user and computer authentication group policy, trusts |
| TCP & UDP | 445 | Customer domain controllers CIDR | SMB / CIFS | Replication, user and computer authentication, group policy trusts |
| TCP & UDP | 464 | Customer domain controllers CIDR | Kerberos change / set password | Replication, user and computer authentication, trusts |
| TCP | 135 | Customer domain controllers CIDR | Replication | RPC, EPM |
| TCP | 636 | Customer domain controllers CIDR | LDAP SSL | Directory, replication, user and computer authentication group policy, trusts |
| TCP | 49152 - 65535 | Customer domain controllers CIDR | RPC | Replication, user and computer authentication, group policy, trusts |
| TCP | 3268 - 3269 | Customer domain controllers CIDR | LDAP GC & LDAP GC SSL | Directory, replication, user and computer authentication group policy, trusts |
| TCP | 9389 | Customer domain controllers CIDR | SOAP | AD DS web services |
| UDP | 123 | Customer domain controllers CIDR | Windows Time | Windows Time, trusts |
| UDP | 138 | Customer domain controllers CIDR | DFSN & NetLogon | DFS, group policy |
**Outbound Rules**
****
| Protocol | Port range | Source | Type of traffic | Active Directory usage |
| --- | --- | --- | --- | --- |
| All | All | Customer domain controllers CIDR | All traffic | |
# Editing AWS Managed Microsoft AD directory security settings
You can configure fine-grained directory settings for your AWS Managed Microsoft AD to meet your compliance and security requirements without any increase in operational workload. In directory settings, you can update secure channel configuration for protocols and ciphers used in your directory. For example, you have the flexibility to disable individual legacy ciphers, such as RC4 or DES, and protocols, such as SSL 2.0/3.0 and TLS 1.0/1.1. AWS Managed Microsoft AD then deploys the configuration to all domain controllers in your directory, manages domain controller reboots, and maintains this configuration as you scale out or deploy additional AWS Regions. For all available settings, see [List of directory security settings](#list-ds-settings).
## Edit directory security settings
You can configure and edit settings for any of your directories.
**To edit directory settings**
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 **Networking & security**, find **Directory settings**, and then choose **Edit settings**.
1. In **Edit settings**, change the **Value** for the settings that you want to edit. When you edit a setting, its status changes from **Default** to **Ready to Update**. If you have edited the setting previously, its status changes from **Updated** to **Ready to Update**. Then, choose **Review**.
1. In **Review and update settings**, see **Directory settings** and make sure that the new values are all correct. If you want to make any other changes to your settings, choose **Edit settings**. When you're satisfied with your changes and ready to implement the new values, choose **Update settings**. Then, you're taken back to the directory ID page.
**Note**
Under **Directory settings**, you can view the **Status** of your updated settings. While settings are implemented, the **Status** displays **Updating**. You cannot edit other settings while a setting displays **Updating** under **Status**. The **Status** displays **Updated** if the setting successfully updates with your edit. The **Status** displays **Failed** if the setting fails to update with your edit.
## Failed directory security settings
If an error occurs during a settings update, the **Status** displays as **Failed**. In a failed status, the settings do not update to the new values, and the original values remain implemented. You can retry updating these settings or revert them to their previous values.
**To resolve failed updated settings**
+ Under **Directory settings**, choose **Resolve failed settings**. Then, do one of the following:
+ To revert your settings back to their original value before the failure state, choose **Revert failed settings**. Then, choose **Revert** in the pop-up modal.
+ To retry updating your directory settings, choose **Retry failed settings**. If you want to make additional changes to your directory settings before retrying the failed updates, choose **Continue editing**. On **Review and retry failed updates**, choose **Update settings**.
## List of directory security settings
The following list shows the type, setting name, API name, potential values, and setting description for all available directory security settings.
TLS 1.2 and AES 256/256 are the default directory security settings if all other security settings are disabled. They cannot be disabled.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_directory_settings.html)
# Enable Public Key Cryptography for Initial Authentication (PKINIT) for your AWS Managed Microsoft AD users
AWS Managed Microsoft AD directories use strong certificate binding by default, which requires explicit mapping between certificates and AD objects. The following mappings are considered strong for AWS Managed Microsoft AD:
+ `altSecurityIdentities` Issuer and Serial Number
+ `altSecurityIdentities` Subject Key Identifier
+ `altSecurityIdentities` SHA1 Hash of Public Key
These attributes enable strong certificate mapping, which provides better security for certificate based authentication by requiring explicit certificate-to-user relationships defined in Active Directory. This helps prevent certificate-based privilege escalation attacks
You can use this procedure to configure strong certificate bindings to help you prevent privilege escalation attacks while maintaining certificate authentication functionality.
For more information, see [Microsoft KB5014754: Certificate-based authentication changes on Windows domain controllers](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16)
## Prerequisites
+ An AWS Managed Microsoft AD directory with certificate authority configured
+ Administrative access to your Active Directory environment
+ PowerShell with Active Directory module installed
+ The certificate you want to map to the AD object
## Map AltSecurityIdentity attribute
1. Choose one of the following `AltSecurityIdentity` mapping methods based on your certificate information:
+ **SHA1 hash** – Uses the SHA1 hash of the certificate's public key
For SHA1 hash mapping, extract the certificate hash and apply it to the user object:
```
$Username = 'YourUsername'
$cert = certutil -dump "YourCertificate.cer"
$certHash = ($cert | Select-String -Pattern "(sha1):*" |
Select-String -Pattern "Cert").ToString().TrimStart('Cert Hash(sha1): ').Replace(' ','')
Set-ADUser -Identity $Username -Add @{'altSecurityIdentities'="X509:$CertHash"}
```
+ **Issuer and Serial Number** – Uses the certificate's issuer name and serial number
For Issuer and Serial Number mapping, use the certificate's issuer and serial number:
```
$Username = 'YourUsername'
$IssuerName = 'YourCertificateIssuer'
$SerialNumber = 'YourCertificateSerialNumber'
Set-ADUser -Identity $Username -Add @{'altSecurityIdentities'="X509:$IssuerName$SerialNumber"}
```
+ **Subject Key Identifier** – Uses the certificate's subject key identifier extension
For Subject Key Identifier mapping, use the certificate's subject key identifier:
```
$Username = 'YourUsername'
$SubjectKeyIdentifier = 'YourSubjectKeyIdentifier'
Set-ADUser -Identity $Username -Add @{'altSecurityIdentities'="X509:$SubjectKeyIdentifier"}
```
1. Verify the mapping was applied successfully:
```
Get-ADUser -Identity $Username -Properties altSecurityIdentities |
Select-Object -ExpandProperty altSecurityIdentities
```
1. Wait for Active Directory replication to complete (typically 15-30 seconds) before testing certificate authentication.
## Example: Bulk certificate mapping the AltSecurityIdentity attribute
The following example demonstrates how to map `AltSecurityIdentity` attribute for multiple user certificates from a certificate authority:
```
$CertificateTemplateName = 'User'
$Now = $((Get-Date).ToString($(Get-culture).DateTimeFormat.ShortDatePattern))
$Restrict = "Disposition=20,NotAfter>=$Now,Certificate Template=$CertificateTemplateName"
$Out = "SerialNumber,Certificate Hash,User Principal Name,RequesterName,CommonName,CertificateTemplate,NotBefore,NotAfter"
$Certs = certutil -view -restrict $Restrict -out $Out csv | ConvertFrom-CSV
$UserSha1HashMapping = @{}
ForEach ($Cert in $Certs) {
$UPN = $Cert.'User Principal Name'
$Username, $Domain = $UPN.Split('@')
$CertificateThumbprint = ($Cert.'Certificate Hash').Replace(' ','')
$AdUserObject = Get-ADUser -Identity $Username
If ($AdUserObject -And $AdUserObject.Count -gt 1) {
Write-Output "Unable to map user: $Username, multiple user objects found"
Continue
}
If ($AdUserObject) {
If ($UserSha1HashMapping.Keys -Contains $Username) {
$UserSha1HashMapping[$Username] += $CertificateThumbprint
} Else {
$UserSha1HashMapping[$Username] = @($CertificateThumbprint)
}
}
}
ForEach ($User in $UserSha1HashMapping.Keys) {
Write-Output "Mapping altSecurityIdentity for $User"
$UserObject = Get-ADUser -Identity $User | Get-ADObject -Properties 'altSecurityIdentities'
$altSecurityIdentities = $UserObject.altSecurityIdentities
ForEach ($thumbprint in $UserSha1HashMapping[$User]) {
$SHA1PUKEY = "X509:$thumbprint"
If ($altSecurityIdentities -Contains $SHA1PUKEY) {
Write-Output "Skipping $thumbprint, already mapped."
Continue
}
Write-Output "Adding $thumbprint to $User as altSecurityIdentity"
Set-ADUser -Identity $User -Add @{'altSecurityIdentities'=$SHA1PUKEY}
}
}
```
## Next steps
+ Test certificate-based authentication with your mapped certificates
+ Configure your applications to use the mapped certificates for authentication
+ [Monitor your AWS Managed Microsoft AD](ms_ad_monitor.md) for authentication events
# Set up AWS Private CA Connector for AD for AWS Managed Microsoft AD
You can integrate your AWS Managed Microsoft AD with [AWS Private Certificate Authority (CA)](https://docs.aws.amazon.com/privateca/latest/userguide/connector-for-ad.html) to issue and manage certificates for your Active Directory domain controllers, domain joined users, groups, and machines. AWS Private CA Connector for Active Directory allows you to use a fully managed AWS Private CA drop-in replacement for your self-managed enterprise CAs without the need to deploy, patch, or update local agents or proxy servers.
You can set up AWS Private CA integration with your directory through the Directory Service console, the AWS Private CA Connector for Active Directory 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 set up the Private CA integration through the AWS Private CA Connector for Active Directory console, see [Creating a connector template](https://docs.aws.amazon.com/privateca/latest/userguide/create-ad-template.html). See the following steps on how to set up this integration from the Directory Service console.
## Setting up AWS Private CA Connector for AD
**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).
## Viewing AWS Private CA Connector for AD
**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).
The following table shows the different statuses for domain controller certificate enrollment for AWS Managed Microsoft AD with AWS Private CA.
| DC enrollment status | Description | Action required |
| --- | --- | --- |
| Enabled | Domain controller certificates are successfully enrolled to your directory. | No action required. |
| Failed | Domain controller certificate enrollment enablement or disablement failed for your directory. | If your enablement action fails, retry by turning off domain controller certificates and then turning on again. If your disablement action fails, retry by turning on domain controller certificates and then turning off again. If retry fails, contact AWS Support. |
| Impaired | Domain controllers have network connectivity issues communicating with AWS Private CA endpoints. | Check AWS Private CA VPC endpoint and S3 bucket policies to allow network connectivity with your directory. For more information, see [Troubleshoot AWS Private Certificate Authority exception messages](https://docs.aws.amazon.com/privateca/latest/userguide/PCATsExceptions.html) and [Troubleshoot AWS Private CA certificate revocation issues](https://docs.aws.amazon.com/privateca/latest/userguide/troubleshoot-certificate-revocation.html). |
| Disabled | Domain controller certificate enrollment is successfully turned off for your directory. | No action required. |
| Disabling | Domain controller certificate enrollment disablement is in progress. | No action required. |
| Enabling | Domain controller certificate enrollment enablement is in progress. | No action required. |
## Configuring AD Policies
AWS Private CA Connector for AD must be configured so AWS Managed Microsoft AD domain controllers and objects can request and receive certificates. Configure your group policy object ([GPO](https://learn.microsoft.com/previous-versions/windows/desktop/policy/group-policy-objects)) so AWS Private CA can issue certificates to AWS Managed Microsoft AD objects.
### Configuring Active Directory policies for domain controllers
**Turn on Active Directory policies for domain controllers**
1. Open the **Network & Security** tab.
1. Choose **AWS Private CA Connectors**.
1. Choose a connector linked to the AWS Private CA subject that issues domain controller certificates to your directory.
1. Choose **Actions**, **Enable domain controller certificates**.
**Important**
Configure a valid domain controller template before you turn on domain controller certificates to avoid delayed updates.
After you turn on domain controller certificate enrollment, your directory's domain controllers request and receive certificates from AWS Private CA Connector for AD.
To change your issuing AWS Private CA for domain controller certificates, first connect the new AWS Private CA to your directory using a new AWS Private CA Connector for AD. Before you turn on certificate enrollment on the new AWS Private CA, turn off certificate enrollment on the existing one:
**Turn off domain controller certificates**
1. Open the **Network & Security** tab.
1. Choose **AWS Private CA Connectors**.
1. Choose a connector linked to the AWS Private CA subject that issues domain controller certificates to your directory.
1. Choose **Actions**, **Disable domain controller certificates**.
### Configuring Active Directory policies for domain joined users, computers and machines
**Configure group policy objects**
1. Connect to the AWS Managed Microsoft AD admin instance and open [Server Manager](https://learn.microsoft.com/windows-server/administration/server-manager/server-manager) from the **Start** menu.
1. Under **Tools**, choose **Group Policy Management**.
1. Under **Forest and Domains**, find your subdomain organizational unit (OU) (for example, `corp` is your subdomain organizational unit if you followed the procedures outlined in [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory)) and right-click on your subdomain OU. Choose **Create a GPO in this domain, and link it here** and enter PCA GPO for the name. Choose **OK**.
1. The newly created GPO appears following your subdomain name. Right-click on `PCA GPO` and choose **Edit**. If a dialog box opens with an alert message stating This is a link and that changes are globally propagated, acknowledge the message by choosing **OK** to continue. The **Group Policy Management Editor** window opens.
1. In the **Group Policy Management Editor** window, go to **Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies** (choose the folder).
1. Under **Object Type**, choose **Certificate Services Client - Certificate Enrollment Policy**.
1. In the **Certificate Services Client - Certificate Enrollment Policy** window, change **Configuration Model** to **Enabled**.
1. Confirm that **Active Directory Enrollment Policy** is selected and **Enabled**. Choose **Add**.
1. The **Certificate Enrollment Policy Server** dialog box opens. Enter the certificate enrollment policy server endpoint that you generated when you created your connector in the **Enter enrollment server policy URI** field. Leave the **Authentication Type** as **Windows** integrated.
1. Choose **Validate**. After validation succeeds, choose **Add**.
1. Return to **Certificate Services Client - Certificate Enrollment Policy** dialog box and select the box beside the newly created connector to make sure that the connector is the default enrollment policy.
1. Choose **Active Directory Enrollment Policy** and choose **Remove**.
1. In the confirmation dialog box, choose **Yes** to delete the LDAP-based authentication.
1. Choose **Apply** and then **OK** in the **Certificate Services Client - Certificate Enrollment Policy** window. Then close the window.
1. Under **Object Type** for the **Public Key Policies folder, choose Certificate Services Client - Auto-Enrollment.**
1. Change the **Configuration Model** option to **Enabled**.
1. Confirm that **Renew expired certificates** and **Update Certificates** options are both selected. Leave the other settings as they are.
1. Choose **Apply**, then **OK**, and close the dialog box.
Next, configure the Public Key Policies for user configuration by repeating steps 6-17 in the **User Configuration > Policies > Windows Settings > Security Settings > Public Key Policies** section.
After you finish configuring GPOs and Public Key Policies, objects in the domain request certificates from AWS Private CA Connector for AD and receive certificates issued by AWS Private CA.
## Confirming AWS Private CA issued a certificate
The process to update AWS Private CA to issue certificates for your AWS Managed Microsoft AD can take up to 8 hours.
You can do one of the following:
+ You can wait this period of time.
+ You can restart the AWS Managed Microsoft AD domain joined machines that were configured to receive certificates from the AWS Private CA. Then you can confirm the AWS Private CA has issued certificates to members of your AWS Managed Microsoft AD domain by following the procedure in [Microsoft documentation](https://learn.microsoft.com/dotnet/framework/wcf/feature-details/how-to-view-certificates-with-the-mmc-snap-in).
+ You can use the following PowerShell command to update the certificates for your AWS Managed Microsoft AD:
```
certutil -pulse
```