# AWS Managed Microsoft AD *AWS Directory Service for Microsoft Active Directory*, also referred to as AWS Managed Microsoft AD, runs Microsoft Active Directory as a managed service powered by Windows Server 2019. It creates a highly available pair of domain controllers in your Amazon VPC across different Availability Zones, with AWS automatically managing host monitoring, recovery, data replication, snapshots, and software updates. This service enables you to run directory-aware workloads, manage users and groups, provide single sign-on, create and apply group policies, and securely connect to Amazon EC2 instances. Directory Service offers two Microsoft Active Directory solutions: *AWS Directory Service for Microsoft Active Directory* provides a fully managed Active Directory service in the AWS Cloud, while *AWS Managed Microsoft AD (Hybrid Edition)* extends your existing self-managed AD to AWS. *AWS Managed Microsoft AD (Standard Edition and Enterprise Edition)* create new managed AD domains to manage users, devices, and computers on AWS. These directories establish resource forests that create trust relationships with your existing AD domains on-premises, in AWS, or in multi-cloud environments. Users can access AWS resources with their existing credentials from your current AD domains. User identities stay in your existing AD domains while the resource forest manages your AWS resources, maintaining operational isolation between environments while providing seamless single sign-on. *AWS Managed Microsoft AD (Hybrid Edition)* connects your self-managed Active Directory with AWS Directory Service for Microsoft Active Directory, creating an integrated identity environment spanning both your infrastructure and the AWS Cloud. This solution extends your directory services to AWS without synchronizing user identities, establishes trust relationships between environments, and provides seamless access using existing credentials. With AWS Managed Microsoft AD, you can run directory-aware workloads in the AWS Cloud, including Microsoft SharePoint and custom .NET and SQL Server-based applications. You can also configure trust relationships between AWS Managed Microsoft AD and your existing self-managed Microsoft Active Directory, providing users and groups with access to resources in either domain using AWS IAM Identity Center. ## Which to choose You can choose between two AWS Directory Service services with the features and scalability that best meet your needs. The following table helps you determine which Directory Service option works best for your organization. **** | Use case | Recommended solution | | --- | --- | | Run directory-aware workloads, AWS applications, or Linux applications requiring LDAP support | *AWS Managed Microsoft AD (Standard Edition and Enterprise Edition)* create new managed AD domains to manage users, devices, and computers on AWS. These directories establish resource forests that create trust relationships with your existing AD domains on-premises, in AWS, or in multi-cloud environments. Users can access AWS resources with their existing credentials from your current AD domains. User identities stay in your existing AD domains while the resource forest manages your AWS resources, maintaining operational isolation between environments while providing seamless single sign-on. | | Extend existing Active Directory to AWS | *AWS Managed Microsoft AD (Hybrid Edition)* connects your self-managed Active Directory with AWS Directory Service for Microsoft Active Directory, creating an integrated identity environment spanning both your infrastructure and the AWS Cloud. This solution extends your directory services to AWS without synchronizing user identities, establishes trust relationships between environments, and provides seamless access using existing credentials. | ## Topics + [Getting started with AWS Managed Microsoft AD](ms_ad_getting_started.md) + [Understanding AWS Managed Microsoft AD (Hybrid Edition)](aws-hybrid-directory.md) # Understanding AWS Managed Microsoft AD (Hybrid Edition) AWS Managed Microsoft AD (Hybrid Edition) *AWS Managed Microsoft AD (Hybrid Edition)* allows you to extend your existing Active Directory to the AWS Cloud with AWS Managed Microsoft AD. This feature makes it easier to move your AD–dependent workloads to AWS, adopt AWS services, and increase your Active Directory redundancy. AWS will periodically run directory assessments on your hybrid directory which you can view in the Directory Service console. A hybrid directory in Directory Service connects your existing *Microsoft Active Directory* with *AWS Directory Service for Microsoft Active Directory* (AWS Managed Microsoft AD). This creates an integrated identity environment that spans on-premises, AWS, and multi-cloud infrastructure, allowing you to maintain a single source of identity while extending your directory services to AWS. A hybrid directory configuration provides several important capabilities: + Extension of self-managed AD to the AWS Cloud without needing to establish a trust relationship + Seamless authentication and authorization across environments using existing Active Directory credentials + Consistent user credentials and group memberships across both your AD environments + Centralized management of AD access policies and permissions **Topics** + [ # Hybrid directory prerequisites ](create_hybrid_directory_prereqs.md) + [ # Creating a hybrid directory ](hybrid_directory_create.md) + [ # Viewing and editing a hybrid directory ](hybrid_directory_view_and_edit.md) + [ # Deleting a hybrid directory ](hybrid_directory_delete.md) + [ # Directory assessments for hybrid directories ](hybrid_directory_assessment.md) + [ # Troubleshooting hybrid directory and directory assessment ](hybrid_directory_troubleshooting.md) # Hybrid directory prerequisites Hybrid directory extends your self-managed Active Directory to the AWS Cloud. Before creating a hybrid directory, ensure your environment meets these requirements: ## Microsoft Active Directory domain requirements Before creating a hybrid directory, ensure your self-managed AD environment and infrastructure meet the following requirements, and gather the necessary information. ### Domain requirements Your self-managed AD environment must meet the following requirements: + Uses a Windows Server 2012 R2 or 2016 functional level. + Uses standard domain controllers to be assessed for hybrid directory creation. Read-only domain controllers (RODC) can not be used for hybrid directory creation. + Has two domain controllers with all Active Directory services running. + The Primary Domain Controller (PDC) must be routable at all times. Specifically, the PDC Emulator and RID Master IPs of your self-managed AD must be in one of these categories: + Part of RFC1918 private IP address ranges (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) + Within your VPC CIDR range + Match the DNS IPs of your self-managed instances for the directory You can add additional IP routes for the directory after the hybrid directory is created. ### Required information Gather the following information about your self-managed AD: + Directory DNS name + Directory DNS IPs + Service account credentials with Administrator permissions to your self-managed AD + AWS Secret ARN for storing your service account credentials (see [AWS Secret ARN for hybrid directory](#aws_secret_arn_for_hybrid)) ### AWS Secret ARN for hybrid directory AWS Secret ARN for hybrid directory To configure a hybrid directory with your self-managed AD, you need to create a KMS key to encrypt your AWS secret and then create the secret itself. Both resources must be created in the same AWS account that contains the hybrid directory. #### Create a KMS key The KMS key is used to encrypt your AWS secret. **Important** For **Encryption Key**, don't use the AWS default KMS key. Be sure to create the AWS KMS key in the same AWS account that contains the hybrid directory you want to create to join with your self-managed AD. **To create an AWS KMS key** 1. In the AWS KMS console, choose **Create key**. 1. For **Key Type**, choose **Symmetric**. 1. For **Key Usage**, choose **Encrypt and decrypt**. 1. For **Advanced options**: 1. For **Key material origin**, choose **KMS**. 1. For **Regionality**, choose **Single-Region key** and choose **Next**. 1. For **Alias**, provide a name for the KMS key. 1. (Optional) For **Description**, provide a description of the KMS key. 1. (Optional) For **Tags**, add tags for the KMS key and choose **Next**. 1. For **Key administrators**, select an IAM user. 1. For **Key deletion**, keep the default selection for **Allow key administrators to delete this key** and choose **Next**. 1. For **Key users**, select the same IAM user from the previous step and choose **Next**. 1. Review the configuration. 1. For **Key policy**, add the following statement to the policy: 1. Choose **Finish**. #### Create an AWS secret Create a secret in Secrets Manager to store the credentials for your self-managed AD user account. **Important** Create the secret in the same AWS account that contains the hybrid directory you want to join with your self-managed AD. To create a secret + In Secrets Manager, choose **Store a new secret** + For **Secret type**, choose **Other type of secret** + For **Key/value pairs**, add your two keys: 1. Add the username key 1. For the first key, enter `customerAdAdminDomainUsername`. 1. For the value of the first key, enter only the username (without the domain prefix) of the AD user. Do not include the domain name as this causes instance creation to fail. 1. Add the password key 1. For the second key, enter `customerAdAdminDomainPassword`. 1. For the value of the second key, enter the password that you created for the AD user on your domain. ##### Complete the secret configuration 1. For **Encryption key**, select the KMS key that you created in [Create a KMS key](#create_kms_key_for_hybrid) and choose **Next**. 1. For **Secret name**, enter a description for the secret. 1. (Optional) For **Description**, enter a description for the secret. 1. Choose **Next**. 1. For **Configure rotation settings**, keep the default values and choose **Next**. 1. Review the settings for the secret and choose **Store**. 1. Choose the secret you created and copy the value for the **Secret ARN**. You will use this ARN in the next step to set up your self-managed Active Directory. ### Infrastructure requirements Prepare the following infrastructure components: + Two AWS Systems Manager nodes with administrator privileges for SSM agents + If your Active Directory is **self-managed outside of the AWS Cloud**, you will need two Systems Manager node for a hybrid and multicloud environment. For more information on how to provision these nodes, see [Setting up Systems Manager for hybrid and multicloud environments](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-hybrid-multicloud.html). + If your Active Directory is **self-managed within the AWS Cloud**, you will need two Systems Manager managed EC2 instances. For more information on how to provision these instances, see [Managing EC2 instances with Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html). ## Required Active Directory services Required Active Directory services Ensure the following services are running on your self-managed AD: + Active Directory Domain Services + Active Directory Web Service (ADWS) + COM\$1 Event System + Distributed File System Replication (DFSR) + Domain Name System (DNS) + DNS Server + Group Policy Client + Intersite Messaging + Remote Procedure Call (RPC) + Security Accounts Manager + Windows Time Server **Note** Hybrid directory requires both the UDP port 123 to be open and the Windows Time Server to be enabled and functional. We synchronize time with your domain controller to ensure hybrid directory replication works properly. ## Kerberos authentication requirements Kerberos 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](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms-ad-tutorial-setup-trust-prepare-onprem.html#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. ## Supported encryption types Supported encryption types hybrid directory supports the following encryption types when authenticating via Kerberos to your Active Directory domain controllers: + AES-256-HMAC ## Network port requirements Ports For AWS to extend your self-managed 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 + UDP 123 - Time server + TCP 135 - Remote Procedure Call + TCP/UDP 389 - LDAP + TCP 445 - SMB + TCP 636 - Only needed for environments with Lightweight Directory Access Protocol Secure (LDAPS) + TCP 49152-65535 - RPC randomly allocated high TCP ports + TCP 3268 and 3269 - Global Catalog + TCP 9389 Active Directory Web Services (ADWS) These are the minimum ports needed to create a hybrid directory. Your specific configuration may require additional ports be open. **Note** The DNS IPs provided for your Domain Controllers and FSMO Role holders must have the above ports open to the CIDRs for both subnets in the Amazon VPC. **Note** Hybrid directory requires both the UDP port 123 to be open and the Windows Time Server to be enabled and functional. We synchronize time with your domain controller to ensure hybrid directory replication works properly. ## AWS account permissions Permissions You will need permissions to the following actions in your AWS account: + ec2:AuthorizeSecurityGroupEgress + ec2:AuthorizeSecurityGroupIngress + ec2:CreateNetworkInterface + ec2:CreateSecurityGroup + ec2:DescribeNetworkInterfaces + ec2:DescribeSubnets + ec2:DescribeVpcs + ec2:CreateTags + ec2:CreateNetworkInterfacePermission + ssm:ListCommands + ssm:GetCommandInvocation + ssm:GetConnectionStatus + ssm:SendCommand + secretsmanager:DescribeSecret + secretsmanager:GetSecretValue + iam:GetRole + iam:CreateServiceLinkedRole ## Amazon VPC network requirements Amazon VPC A VPC with the following: + At least two subnets. Each of the subnets must be in a different Availability Zone + The VPC must have default tenancy You cannot create a hybrid directory in a VPC using addresses in the 198.18.0.0/15 address space. 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 the ETH0 network for your directory is `198.18.0.0/15`. For more information, see the following topics in the *Amazon VPC User Guide*: + [What is Amazon VPC?](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html) + [What is Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) + [VPCs and subnets](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#how-it-works-subnet) + [What is AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC-VPN.html) For more information about AWS Direct Connect, see the [What is AWS Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) ## AWS security group configuration Security group By default, AWS attaches a security group to allow network access to the AWS Systems Manager managed nodes in your VPC. You can optionally supply your own security group that allows network traffic to and from your self-managed domain controllers outside of your VPC. You can optionally supply your own security group that allows network traffic to and from your self-managed domain controllers outside of your VPC. If you are supply your own security group, then you need to: + Allowlist your VPC CIDR ranges and self-managed ranges. + Ensure these ranges don't overlap with [AWS reserved IP ranges](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) ## Directory assessments considerations Assessment limits The following are considerations when creating directory assessments and the number of assessments you can have in your AWS account: + A directory assessment is automatically created when you create a hybrid directory. There are two types of assessments: `CUSTOMER` and `SYSTEM`. Your AWS account has a limit of 100 `CUSTOMER` directory assessments. + If you attempt to create a hybrid directory and you already have 100 `CUSTOMER` directory assessments, you will encounter an error. Delete assessments to free up capacity before trying again. + You can request an increase to your `CUSTOMER` directory assessment quota by contacting Support or delete existing CUSTOMER directory assessments to free up capacity. # Creating a hybrid directory Before creating a hybrid directory, you must create and successfully pass a directory assessment that verifies connectivity and interoperability with your self-managed Active Directory ## Creating a hybrid directory with your self-managed AD Creating a hybrid directory Follow these steps to create a hybrid directory with your self-managed AD: **To create a hybrid directory** 1. Open the Directory Service console for your desired Region. 1. On the **Select directory type** page, choose **AWS Managed Microsoft AD**. 1. Under **Getting started with AWS Managed Microsoft AD**, select **Extend your AD domain with a hybrid directory – new** and then choose **Next**. This directs you to the **Create directory assessment** page. 1. Before you can create a hybrid directory, you must first create and successfully pass a directory assessment. To create a directory assessment, follow the steps in [Creating directory assessments](create_directory_assessment.md). Once you have successfully passed a directory assessment, you can continue with this procedure. 1. Once you have successfully passed a directory assessment, navigate to the **Directories** page. 1. On the **Directories** page, under **Trial hybrid directory assessments** choose an **Assessment ID** with a **Status** of `SUCCESS`. Then select **Create hybrid directory**, which directs you to the assessment details page 1. On the assessment details page confirm this action by selecting **Create hybrid directory**, which opens the **Create hybrid directory using assessment-id** page. 1. On the **Create hybrid directory using assessment-id** page, **Review the self-managed Active Directory information**. After confirming the information, select **Create hybrid directory**. After choosing **Create hybrid directory**, AWS runs another directory assessment based on this information to confirm that your self-managed AD configuration is still valid. If the directory assessment passes successfully, then we create the hybrid directory. 1. Choosing **Create hybrid directory** returns you to the **Directories** page. 1. A green banner will appear once the hybrid directory is created successfully. 1. A red banner will appear if the hybrid directory creation fails. Clean up hybrid directory creation failures by completing the following: 1. Delete the failed hybrid directory in the console. 1. Delete any remaining AWS Reserved OUs in your self-managed AD. **More information** + [Deleting a hybrid directory](hybrid_directory_delete.md) + [Troubleshooting](hybrid_directory_troubleshooting.md) # Viewing and editing a hybrid directory Use the following procedures to view or edit your hybrid directory. ## Viewing a hybrid directory You can view a hybrid directory in the Directory Service console. **To view detailed directory information** 1. In the [Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, choose **Directories**. 1. Choose the directory ID link for your directory. Information about the directory appears on the **Directory details** page. ### Self-managed Active Directory information This section provides information about your self-managed Active Directory that's joined with AWS infrastructure. + Directory type + Directory ID + Directory status + Networking details for your self-managed AD, such as: + VPC + Subnets + DNS addresses + Systems Manager managed nodes ### Hybrid directory tabs You can find the following information about your AWS Managed Microsoft AD: + On the **Share & share** tab, you can share your AWS Managed Microsoft AD with other AWS accounts and view the networking details for your domain controllers. + On the **Application management** tab, you can enable an application access URL for your AWS Managed Microsoft AD and enable AWS applications and services for your AWS Managed Microsoft AD. + On the **Maintenance** tab, you can enable SNS to receive notifications of your AWS Managed Microsoft AD status and review snapshots of your AWS Managed Microsoft AD. + For more information about the **Status** field, see [Understanding your AWS Managed Microsoft AD directory status](ms_ad_directory_status.md). ## Updating a hybrid directory You can update a hybrid directory in the Directory Service console to modify DNS settings or recover administrator account access. **To update hybrid directory information** 1. In the [Directory Service console](https://console.aws.amazon.com/directoryservicev2) navigation pane, choose **Directories**. 1. Choose the directory ID link for your directory to open the **Directory details** page. 1. Choose **Actions**, and then choose **Update hybrid directory information**. 1. On the **Update hybrid directory information** page, you can update your DNS settings or recover your administrator account. **Update DNS settings (optional)** Under **Self-managed Active Directory information**, you can change the following: 1. **Directory DNS Name** 1. **DNS IP Addresses** You can update both settings together or individually. At least one change is required for the update process. 1. **Recover hybrid directory administrator account** To recover your hybrid directory administrator account, we need temporary access to a user. This access is provided through a secret from Secrets Manager. We use these credentials only once during recovery and don't store them. If your hybrid directory administrator account exists, you don't need to update this secret, even if you updated your self-managed Active Directory administrator user. 1. **Admin credentials secret** – We create a hybrid directory administrator account when we create a hybrid directory. If you deleted this secret, enter your Secrets Manager secret for your self-managed AD administrator user. # Deleting a hybrid directory When you delete a hybrid directory, all directory data and snapshots are deleted and cannot be recovered. After the directory is deleted, all instances that were joined to the directory remain intact. However, you cannot use the directory credentials to log into these instances. You must log into these instances with a local user account. **To delete a directory** 1. In the [Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**. Ensure you are in the AWS Region where your hybrid directory 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 directory you intend to delete. Enabled AWS applications will prevent you from deleting your hybrid directory. 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 directory. 1. Disable AWS Management Console access. For more information, see [Disabling AWS Management Console access](https://docs.aws.amazon.com/ms_ad_management_console_access.xml). 1. 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*. 1. 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*. 1. In the navigation pane, choose **Directories**. 1. Select only the directory to be deleted and choose **Delete**. It takes several minutes for the directory to be deleted. When the directory has been deleted, it is removed from your directory list. 1. Manually delete any remaining domain controller objects, including any AWS Reserved OUs. You can delete the entire AWS Reserved directory to finish cleaning up your environment. # Directory assessments for hybrid directories Directory assessments A directory assessment examines your self-managed Active Directory environment to make sure it meets the requirements for creating a hybrid directory. This assessment verifies network connectivity, domain controller configuration, and required services to help identify and resolve potential issues before establishing a connection between your self-managed AD and Directory Service. There are two types of directory assessments: + *`CUSTOMER` assessments* – Initiated by you in the console when you begin setting up a hybrid directory. You can delete customer directory assessments, even while they're in progress. You can have up to 100 customer assessments. + *`SYSTEM` assessments* – Automatically created by AWS and run periodically after successful creation. You can't delete `SYSTEM` assessments. Directory assessments provide valuable information about your environment's readiness, including: + Connectivity between your self-managed AD and AWS + Availability of required services on your domain controllers + Configuration compatibility with AWS Directory Service requirements + Potential issues that might prevent successful hybrid directory creation A successful (passed) directory assessment is required before you can create a hybrid directory. If an assessment fails, you can view the detailed report to identify and address the issues before trying again. AWS deletes `SYSTEM` assessments after 30 days. **Topics** + [ # Creating directory assessments ](create_directory_assessment.md) + [ # Viewing directory assessments ](viewing_hybrid_dir_assessment.md) + [ # Deleting directory assessments ](deleting_hybrid_dir_assessment.md) # Creating directory assessments You can create a directory assessment as part of creating a hybrid directory, or you can create one manually. To create an assessment manually, open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). On the **Directories** page, under the **Directory assessments** section, choose **Create assessment**. **To create a directory assessment** 1. On the **Create directory assessment** page, for **Directory DNS name**, enter your self-managed Active Directory DNS name. 1. For **DNS IP Addresses**, enter two DNS IP addresses for your self-managed AD. 1. Hybrid directory requires a Amazon VPC with at least two subnets. If you don't already have these, you can create them. In the **Networking** section, provide the following: 1. For **VPC**, choose your VPC identifier. 1. For **Subnets**, choose the identifier for each of the two subnets. Each subnet must be in different Availability Zones. For more information, see [Amazon VPC network requirements](create_hybrid_directory_prereqs.md#hybrid-dir-prereqs-vpc). 1. For **Security group**, choose the security group identifier. By default, AWS attaches a security group to allow network access to the AWS Secrets Manager managed nodes in your Amazon VPC. You can optionally supply your own security group that allows network traffic to and from your self-managed domain controllers outside of your Amazon VPC. 1. In the **AWS Systems Manager nodes** section, choose two Systems Manager nodes or instances based on the following requirements: + If your Active Directory is **self-managed outside of the AWS Cloud**, you will need two Systems Manager node for a hybrid and multicloud environment. For more information on how to provision these nodes, see [Setting up Systems Manager for hybrid and multicloud environments](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-hybrid-multicloud.html). + If your Active Directory is **self-managed within the AWS Cloud**, you will need two Systems Manager managed EC2 instances. For more information on how to provision these instances, see [Managing EC2 instances with Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html). 1. Choose **Next** to open the **Review and create directory assessment** page. 1. On the **Review and create directory assessment** page, review the directory assessment information and make any necessary changes. When the information is correct, choose **Create assessment**. Creating the directory assessment takes around 30 minutes. You're returned to the Directories details page. A green banner appears when the directory assessment succeeds. **Warning** To create a hybrid directory, the directory assessment must enter a SUCCESS state. You can't create a hybrid directory without first successfully passing a directory assessment. # Viewing directory assessments You can view directory assessments in the AWS Management Console to review assessment results and manage your assessment reports. **To view a directory assessment** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. On the **Directories** page, under the **Trial hybrid directory assessments** section, choose the assessment you want to view. This opens the assessment details page. 1. On the assessment details page, you can choose: + **Download** to download the directory assessment report as a CSV file. + **Delete** to delete the directory assessment report. + **Create assessment** to create a new directory assessment. 1. From the assessment details page, you can view the following information: 1. Assessment information, such as the assessment ID, status, whether it was created by the customer or system, and when it was last updated. 1. Self-managed AD details such as the DNS name, VPC, and subnets. 1. AWS Systems Manager managed node information, such as IP address, assessment status, and the number of passed and failed assessment tests. 1. Assessment status for domain controllers. You can also review assessment test details by choosing the domain controllers. Error codes appear in the **Status** column for failed assessment tests. # Deleting directory assessments You can delete customer-created directory assessments in the AWS Management Console. You can't delete system-initiated assessments that AWS creates automatically. **To delete a customer directory assessment** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. On the **Directories** page, under the **Directory assessments** section, choose the customer assessment you want to delete. Alternatively, you can choose the checkbox beside the directory assessments you want to delete and then from the **Actions** menu, choose **Delete**. 1. You're directed to the **Assessments** details page. Choose **Actions** and then choose **Delete Assessment**. A **Delete directory assessment** dialog box appears. Choose **Delete**. # Troubleshooting hybrid directory and directory assessment Troubleshooting A directory assessment is required to create a hybrid directory. Assessment tests run on each domain controller. The assessment tests examines different areas and result in a Passed or Failed status. If your directory assessment fails, you can view the assessment tests of your domain controllers to identify what issues caused the failure. **Important** A hybrid directory can be created when the directory assessment's status is Passed with warning. We recommend you address the issue causing the warning prior to creating a hybrid directory **Topics** + [ ## Troubleshooting failed hybrid directory assessment ](#hybrid_directory_troubleshooting_steps) + [ # Directory Status Errors ](hybrid_directory_status_errors.md) + [ # Directory Assessment Error Messages ](da-error-msgs.md) + [ # Assessment Test error messages ](assessment_test_error-msgs.md) + [ # Assessment Test warning messages ](assessment_test_warning-msgs.md) ## Troubleshooting failed hybrid directory assessment You can troubleshoot a failed directory assessment from the **Directories** page in the AWS Management Console. 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. Under the **Directory assessments** section, select the failed hybrid directory assessment. 1. On the **Assessment Details** page, review the directory assessment and identify what test(s) failed. 1. The domain controller's assessment tests will have more information on what tests were successful or failed. The **Status** column provides more details on what caused the failed test. To view your domain controller's assessment tests, see [Viewing directory assessments](viewing_hybrid_dir_assessment.md). 1. Resolve the issues causing the failures on your self-managed Active Directory or AWS Managed Microsoft AD. See [Directory Assessment Error Messages](da-error-msgs.md) and [Assessment Test error messages](assessment_test_error-msgs.md) for more information. 1. Return to the failed assessment in the Directory Service console. Choose **Create assessment** in the red warning message. See [Creating a hybrid directory with your self-managed AD](hybrid_directory_create.md#creating_hybrid_directory) for more information on creating a directory assessment. # Directory Status Errors Directory Service directories can encounter various states that indicate different types of issues. Understanding these states helps you determine the appropriate troubleshooting steps. **Directory Status Types** | Status | Description | Action Required | | --- | --- | --- | | Active | Directory creation completed successfully and is operating normally. | No action required. | | Impaired | Directory was created successfully, but the domain controller encountered problems afterward. The system attempts automatic recovery. | Monitor the directory status. If the issue persists, contact AWS Support. | | Failed | Directory creation failed and is unrecoverable. | Delete the failed directory and create a new one. | | Inoperable (Hybrid AD only) | AWS detected a security issue and automatically isolated the directory for protection. The directory becomes completely unusable until restored. | Contact [AWS Support Center](https://console.aws.amazon.com/support/home#/) immediately. This status requires Support intervention to investigate and restore the directory. | # Directory Assessment Error Messages To create a hybrid directory, you need to a passed directory assessment. Directory assessments can fail for various reasons. The following table shows directory assessment error messages and how to resolve them. **Directory Assessment Error Messages & Resolutions** | Directory Assessment Error Message | Resolution | | --- | --- | | This assessment failed multiple tests on both managed instances. Investigate the failed tests by selecting each managed instance and resolving them in your on-premises directory. Then, create a new assessment. | One or more of the directory assessment tests failed for your self-managed AD. Review the [Assessment Test error messages](assessment_test_error-msgs.md) for more information on specific test failures and their resolutions. | | This assessment failed due to Internal Service Exception. Please retry by creating a new assessment or contact service for troubleshooting. | Try to create a new directory assessment. If you continue to experience this error, contact [Support](https://aws.amazon.com/premiumsupport/). | | This assessment failed due to missing permission to perform an action like `ec2:CreateSecurityGroup`, `ec2:DeleteSecurityGroup`, `ec2:CreateNetworkInterface`, `ec2:DeleteNetworkInterface`, `ec2:DescribeSubnets`, and `ec2:DescribeNetworkInterface`. | To create a directory assessment, your AWS account needs the necessary [AWS account permissions](create_hybrid_directory_prereqs.md#hybrid-dir-prereq-perms). | | This assessment failed due to missing permission to perform an action like `ssm:GetConnectionStatus`, `ssm:GetCommandInvocation`, `ssm:ListCommands`, `ssm:SendCommand`. | To create a directory assessment, you will need two Systems Manager nodes with the necessary [AWS account permissions](create_hybrid_directory_prereqs.md#hybrid-dir-prereq-perms). | | This assessment failed as you've reached the limit on the number of network interfaces that you can create. For more information, see [Amazon VPC quotas](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). | To create a directory assessment, you must create a network interface and security groups. There are limits to the number of VPC resources you can create however you can adjust some of these limits. For more information, see [Amazon VPC quotas](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). | | This assessment failed as you have reached the limit on the number of security groups that you can create, or assign to an instance. For more information, see [Amazon VPC quotas](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). | To create a directory assessment, you must create a network interface and security groups. There are limits to the number of VPC resources you can create however you can adjust some of these limits. For more information, see [Amazon VPC quotas](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.htmll). | | This assessment failed. Unable to connect to customer instances from AWS Systems Manager. | To create a directory assessment, you will need two AWS Systems Manager nodes that have a connected status. See [Troubleshooting SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html). | | This assessment failed multiple critical tests. Investigate the failed tests by selecting each managed instance and resolve them in your on-premises directory. Then, create a new assessment. | One or more of the directory assessment tests failed for your self-managed AD. Review the [Assessment Test error messages](assessment_test_error-msgs.md) for more information. | # Assessment Test error messages The following table describes error messages that can occur during assessment tests. These errors indicate blocking issues that must be resolved before proceeding with hybrid directory setup. | Test name | Short name | Error code | Error message | Description | Resolution | | --- | --- | --- | --- | --- | --- | | Active Directory Services Test | `testActiveDirectoryServices` | `AD_CRITICAL_SERVICES_NOT_RUNNING` | `Critical AD Services: [service_list] not running on hostname`. | Occurs if required AD services are not running in your self-managed AD. | Specific required AD services must be running in your self-managed AD. For more information, see [Required Active Directory services](create_hybrid_directory_prereqs.md#create_hybrid_directory_prereqs-ad-services). | | Active Directory Services Test | `testActiveDirectoryServices` | `DOMAIN_CONTROLLER_NOT_FOUND` | `No domain controllers found for testActiveDirectoryServices.` | `Occurs if your self-managed AD domain controllers could not be both detected and queried during AD service validation.` | Ensure your self-managed AD domain controllers are operational and can be reached. Verify network connectivity and DNS resolution for your self-managed AD domain controllers. | | AD Password Policy Test | `testPasswordPolicies` | `PASSWORD_POLICY_VIOLATIONS` | *`ErrorMessage`* | Occurs if your self-managed AD password policy does not satisfy AWS Managed Microsoft AD requirements. | Your self-managed AD password policy must satisfy the AWS Managed Microsoft AD password requirements. For more information, see [Understanding AWS Managed Microsoft AD password policies](https://docs.aws.amazon.com/irectoryservice/latest/admin-guide/ms_ad_password_policies.html). | | AWS Admin User Exist Test | `testAwsAdminUserExist` | `ADMINISTRATOR_ACCOUNT_MISSING` | `AWS Admin user not found or invalid.` | Occurs if the hybrid directory administrator user does not exist in the AWS Reserved OU on your self-managed AD. | Ensure the hybrid directory administrator user exists in the AWS Reserved OU on your self-managed AD. If the user is missing, verify the account was created correctly during the hybrid directory setup process. [Updating a hybrid directory](hybrid_directory_view_and_edit.md#editing_hybrid_dir). If your hybrid directory state is inoperable, contact [Support](https://console.aws.amazon.com/support/home#/). | | AWS Admin User SPN Test | `testNoSpnOnAwsAdminAccount` | `SPN_FOUND_ON_AWS_ADMIN` | `Found spnCount Service Principal Names (SPNs) set on AWS admin user Username. Please remove all SPNs from this account.` | Occurs if the hybrid directory administrator user has any SPNs configured on your self-managed AD. | Remove all Service Principal Names (SPNs) from the AWS hybrid directory administrator user account. The hybrid directory administrator user must not have any SPNs configured because they can interfere with hybrid directory authentication. | | AWS Domain Controller Not FSMO Owner Test | `testAwsDcNotFsmoOwner` | `AWS_DC_HOLDS_FSMO_ROLE` | `AWS Domain Controller owns FSMO roles: rolesList. Please remove these roles.` | Occurs if you have transferred FSMO roles (PDC Emulator, RID Master, or Infrastructure Master) from your self-managed AD to the hybrid directory domain controller. | Transfer all FSMO roles (PDC Emulator, RID Master, Infrastructure Master) back to your self-managed AD domain controllers before proceeding. For more information, see [Microsoft documentation on transferring FSMO roles](https://learn.microsoft.com/troubleshoot/windows-server/active-directory/view-transfer-fsmo-roles). | | AWS Reserved Group Membership Test | `testValidateAwsReservedGroupMembership` | `AWS_RESERVED_OU_NOT_FOUND` | `AWS Reserved OU not found.` | Occurs if the AWS Reserved OU on your self-managed AD doesn't exist. | The AWS Reserved OU must exist on your self-managed AD in order to validate group membership. Contact [Support](https://console.aws.amazon.com/support/home#/). | | AWS Reserved Group Membership Test | `testValidateAwsReservedGroupMembership` | `GROUP_MEMBERSHIP_MISMATCH` | `AWS Reserved OU Group [GroupNameA]: Missing User(s) [ Object1 ], [ Object2] and Extra user(s) [ Object3 ].` | Occurs if groups in the AWS Reserved OU on your self-managed AD contains unauthorized users. | Remove any unauthorized users from AWS Reserved OU groups on your self-managed AD. | | AWS Reserved OU ACLs Test | `testReservedOuAclsPermissions` | `RESERVED_OU_NON_COMPLIANT_AC` | `AWS Reserved OU ACLs permissions are invalid.` | Occurs if the AWS Reserved OU ACLs on your self-managed AD do not enforce read-only permissions for entities non-AWS and do not prevent unauthorized access to AWS-managed resources. | Review and correct the permissions on the AWS Reserved OU ACLs on your self-managed AD. Ensure that non-AWS entities have only have read permissions (`ListChildren`, `ReadProperty`, `ListObject`, `ReadControl`, `GenericRead`, `Synchronize`) and remove any excessive permissions. | | AWS Reserved OU GPO Associations Test | `testReservedOuGPOs` | `AWS_RESERVED_OU_NON_RESERVED_GPO_FOUND` | `Found non-AWS GPOs attached to the AWS Reserved OU: AWS Reserved OU (count unauthorized). Allowed GPOs: [allowedAwsGpos]. Domain Controllers OU (count unauthorized). Allowed GPOs: [allowedDcGpos]. Please, remove extra GPOs from the AWS Reserved OU.` | Occurs if the AWS Reserved OU and Domain Controllers OU on your self-managed AD are linked to unauthorized GPOs. | (Only AWS managed Group Policy Objects (GPOs) can be linked to these OUs. Remove any unauthorized GPOs linked to the AWS Reserved OU and Domain Controllers OU on your self-managed AD. | | AWS Reserved OU Resources Test | `testAwsReservedOUResources` | `AWS_RESERVED_OU_NOT_FOUND` | `The AWS Reserved OU does not exist. Please contact AWS Support.` | Occurs if the AWS Reserved OU does not exist in your self-managed AD which is required for AWS Managed Microsoft AD directory functionality. | The AWS Reserved OU must be automatically created during hybrid directory setup and should not be deleted. If this error persists, contact [Support](https://console.aws.amazon.com/support/home#/). | | AWS Reserved OU Resources Test | `testAwsReservedOUResources` | `AWS_RESERVED_OU_RESOURCES_MISMATCH` | `The following required resources are missing from AWS Reserved OU - Objects: missing objects, GPOs: missing GPOs. The following resources should not exist but were found in AWS Reserved OU: Objects: unexpected objects, GPOs: unexpected GPOs` | Occurs if the AWS Reserved OU created on your self-managed AD does not contain the required objects and GPOs for proper hybrid directory operation. | Ensure no one edits the AWS Reserved OU. It must contain the required AWS-managed resources. Remove any unauthorized objects or GPOs, and contact [Support](https://console.aws.amazon.com/support/home#/) if required resources are missing. | | AWS Reserved OU Test | `testCleanAwsReservedOU` | `AWS_RESERVED_RESOURCES_STILL_EXIST` | `AWS Reserved OU or AWS Reserved GPO still exists, please delete.` | Occurs if AWS Reserved resources found on your self-managed AD from a previous hybrid directory setup still exist. | Delete the existing failed hybrid directory from the console. Then delete any AWS Reserved OU and related GPOs from your self-managed AD before proceeding. | | Bridgehead Naming Context Test | `testBridgeheadNamingContext` | `NAMING_CONTEXT_INCONSISTENT` | *`failureDetails`* | Occurs if self-managed AD replication between sites using Bridgehead is not working as expected. It can also occur if the naming contexts are not synchronized between sites. | Your self-managed AD bridgehead site must be successful. You can diagnose further with: `repadmin /bridgeheads /verbose`. Address the issues from that assessment before continuing. | | Child Domain Test | `testChildDomain` | `CHILD_DOMAIN_NOT_SUPPORTED` | `Child Domains are not supported for Hybrid Directory.` | Occurs if your self-managed AD forest contains child domains, which are not supported with AWS Managed Microsoft AD directories. | AWS Managed Microsoft AD directories do not support child domains. You must use a single-domain forest for your self-managed AD. For more information, see [Microsoft Active Directory domain requirements](create_hybrid_directory_prereqs.md#create_hybrid_directory_prereqs-ad-domain). | | DcDiag Test | `testDcDiag` | `DCDIAG_TEST_FAILED` | `DCDiag test failed due to issue from [formatedFailedTests].` | Occurs if any Microsoft DCDiag tests fail on your self-managed AD. | AWS uses DCDiag to test your self-managed AD. If there are errors, you can not create a hybrid directory. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/troubleshoot-domain-controller-deployment#tools-and-commands-for-troubleshooting-domain-controller-configuration). | | DNS IP Match Test | `testDnsIpMatch` | `DNS_IP_MISMATCH` | `DNS IP address does not match expected IP addresses.` | Occurs if the provided DNS IP addresses of your self-managed AD does not match the DNS IP addresses on your self-managed AD domain controllers that are enabled with AWS Systems Manager. | Provide the correct DNS IP addresses. | | DNS Name Match Test | `testDnsNameMatch` | `DOMAIN_DNS_NAME_MISMATCH` | `DNS name does not match expected domain name.` | Occurs if the DNS name provided for your self-managed AD does not match the DNS name on your self-managed AD domain controllers enabled with AWS Systems Manager. | Provide the correct DNS name. | | DNS Records Test | `testDnsRecords` | `DNS_RECORD_MISSING` | `Unable to resolve the following DNS queries: [missingRecordsString`]. | Occurs if Windows DNS records are not set for type A, NS, SOA, and SRV and can be queried. | The DNS records for Address (A), Namespace (NS), State of Authority (SOA), and Service Record (SRV) must be set and can be queried. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/azure/dns/dns-zones-records). | | Domain Forest Functional Level Test | `testDomainForestFunctionalLevel` | `UNSUPPORTED_FUNCTIONAL_LEVEL` | `Detected unsupported domain functional level: DomainFunctionalLevel, we require minimum of MinimumDomainMode. Detected unsupported forest functional level: ForestFunctionalLevel, we require minimum of MinimumForestMode.` | Occurs if your self-managed AD domain and forest functional levels do not meet minimum requirements. | Your self-managed AD must use Windows 2012 R2 or 2016 functional level. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-deployment). | | Domain Health Tests | `testOnPremDcNumber` | `DC_NUMBER_BELOW_LIMIT` | `On-Prem DC count is lower than required number. DC count is NumberOfDc, AWS required number is DcMinimum.` | Occurs if your self-managed AD does not have the minimum required number of domain controllers. | Ensure your self-managed AD has at least two of domain controllers enabled with AWS Systems Manager. For more information, see [Microsoft Active Directory domain requirements](create_hybrid_directory_prereqs.md#create_hybrid_directory_prereqs-ad-domain). | | Existing Domain Test | `testDomainAlreadyJoined` | `DOMAIN_ALREADY_JOINED` | `Instance is already joined to a domain.` | Occurs if your self-managed AD domain is already joined to an existing hybrid directory. | Your self-managed AD domain is already joined to an existing hybrid directory. Each self-managed AD domain joined with a hybrid directory must be unique Create new self-managed AD domain or remove it from the hybrid directory configuration to which they are joined. | | FSMO Connectivity Test | `testFsmoConnectivity` | `FSMO_ROLE_HOLDER_NOT_ROUTABLE` | `(PDCEmulator Ip: 1.1.1.1, RIDMaster Ip: 1.1.1.1) is not in routable ranges: [2.2.0.0/16, 3.3.0.0/16, 4.4.0.0/16, 5.5.0.0/16, 6.6.0.0/16].` | Occurs if FSMO roles, PDC Emulator, and/or RID Master IPs on your self-managed AD are not routable. | The Primary Domain Controller (PDC) must be routable at all times. Specifically, the PDC Emulator and RID Master IPs of your self-managed AD. For more information, see [Microsoft Active Directory domain requirements](create_hybrid_directory_prereqs.md#create_hybrid_directory_prereqs-ad-domain). | | FSMO Connectivity Test | `testFsmoConnectivity` | `FSMO_ROLE_MISSING` | `FSMO role(s): [missingRolesString] missing or DNS Record not found.` | Occurs if your self-managed AD domain controllers can not access your FSMO roles. | Your Flexible Single Master Operation (FSMO) role in your self-managed AD must be connected to your self-managed AD domain controllers. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/fsmo-roles). | | IP Conflict Test | `testIpConflict` | `IP_RANGE_CONFLICT` | `Conflicting IP address detected: ipOverlaps` | Occurs if your self-managed AD IP Ranges overlap with AWS reserved ranges. | Your self-managed AD cannot use an IP address range that overlaps with Reserved AWS IP ranges. For more information, see [Microsoft Active Directory domain requirements](create_hybrid_directory_prereqs.md#create_hybrid_directory_prereqs-ad-domain). | | Kerberos Test | `testKerberos` | `KERBEROS_AUTHENTICATION_FAILED` | `Unable to get kerberos TGT.` | Occurs if Kerberos is not configured correctly and in use. | Kerberos must be enabled on your self-managed AD. For more information, see [Microsoft Documentation](https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview). | | LDAP Connectivity Test | `testLdapConnectivity` | `LDAP_TEST_FAILED` | `Unable to query LDAP with rootDSE call.` | Occurs if LDAP does not work. | Lightweight Directory Access Protocol (LDAP) must be enabled and functioning on your self-managed AD. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/lightweight-directory-access-protocol-ldap-api). | | Not Read Only Domain Controller For FSMO Test | `testNotRodcForFsmo` | `FSMO_FOUND_ON_RODC` | `FSMO Role Found on RODC` | Occurs if your self-managed AD domain controller FSMO role is RODC. | The domain controller for your self-managed AD must not use a Read-Only Domain Controller (RODC) Flexible Single Master Operation (FSMO) role. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/fsmo-roles). | | Read Only Domain Controller Password Replication Test | `testRodcPasswordReplication` | `RODC_REPLICATE_ADMIN_PASSWORD` | `ReadOnly Domain Controller password replication is not explicitly denied for following groups: [missingGroupsString].` | Occurs if the RODC has permission to replicate Admin passwords. | The RODC for your self-managed AD must be explicitly denied permission to replicate Admin passwords. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/rodc-replicates-passwords-grant-incorrect-permissions). | | Read Only Domain Controller Test | `testIsDCRodc` | `DC_READONLY_MODE` | `Provided Domain Controller is set to Read-Only mode.` | Occurs if your self-managed AD domain controllers are in ReadOnlyDC mode. | Your self-managed AD must be read-write domain controllers. For more information about domain controller types, see [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-special-identities-groups#enterprise-domain-controllers). | | Remote Port Connectivity Test | `testPortConnectivity` | `PORT_TEST_FAILED` | `Connection to TargetDestination failed for TCP ports [failed TCP ports]. UDP ports [failed UDP ports].` | Occurs if required ports on your AWS subnet and your self-managed AD domain controller are not open. | Ensure all required ports are open between your AWS subnet and your self-managed AD. See [Network port requirements](create_hybrid_directory_prereqs.md#create_hybrid_directory_prereqs-ports) for more information. | | Replication Test | `testReplication` | `REPLICATION_FAILED` | `Replication failed for [failedDSAsString].` | Occurs if your self-managed AD domain controllers replication failed. | Your self-managed AD domain controllers replication status must be successful. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/dfs-replication-overview). | | SMBV1 Test | `testSMBV1` | `INSECURE_SETTING_SMB` | `SMBv1 is enabled on the system.` | Occurs if self-managed AD is currently using SMBv1 for authentication. | SMBv1 is known to be unsafe and must be disabled on your self-managed AD. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server). | | SSM User Permissions Test | `testSSMUserPermissions` | `INSUFFICIENT_PERMISSIONS` | `Systems Manager user does not have required elevated privileges.` | Occurs if Windows user that is used by SSM has insufficient privileges. | You'll need Windows Administrator permissions for the AWS System Manager (SSM) agents on your self-managed AD. For more information, see [AWS account permissions](create_hybrid_directory_prereqs.md#hybrid-dir-prereq-perms). | | Sysvol Replication Test | `testSysvolReplication` | `DFSR_FAILURE_DETECTED` | `Failed DFSR event logs: failedLogsString.` | Occurs if your self-managed AD does not have the correct sysvol replication method(DFSR), and if any DCs failed during DFSR replication event. | Your self-managed AD sysvol replication method (DFSR) must be successful. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr). | | Top Level GPO Test | `testTopLevelEnforcedGPO` | `TOP_LEVEL_ENFORCED_GPO_FOUND` | `GroupPolicy cannot be set to Enforced at the Domain Root, Found GPOs: [GposEnforced] set as Enforced.` | Occurs if your self-managed AD has Top Level GPOs set as Enforced. | Ensure your self-managed AD domain Top Level group policy object (GPO) is not set to Enforced. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-processing). | | Trust Types Test | `testTrustTypes` | `INVALID_TRUST_TYPE` | `Invalid trust types detected: [InvalidTrustString], only Uplevel (Microsoft AD) is currently supported. ` | Occurs if your self-managed AD has unsupported trust types. | Uplevel is the only trust type supported with hybrid directory. Your self-managed AD cannot have the following trust types: DCE, MIT, Downlevel. For more information on trust types, see [Microsoft documentation](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/rodc-replicates-passwords-grant-incorrect-permissions). | | Valid Domain Controller Test | `testValidDC` | `COMPUTER_NOT_DC` | `Provided instance is not a domain controller.` | Occurs if your self-managed AD instances provided are not domain controllers or if they are already part of another hybrid directory. | Provide self-managed AD domain controllers that are unique to this hybrid directory. Retry with a new directory. Ensure that you have deleted the failed hybrid directory and any the AWS OU in your self-managed AD. | # Assessment Test warning messages The following table describes warning messages that can occur during assessment tests. These warnings represent recommendations for optimal configuration but do not prevent hybrid directory setup. | Test name | Short name | Warning code | Warning message | Description | Resolution | | --- | --- | --- | --- | --- | --- | | Domain Health Tests | `testDisabledStaleUserNumber` | `STALE_USERS_FOUND` | `StaleUserCount users were found to be stale, they have not logged in for StaleThresholdInDays days.` | Occurs if there are user accounts in your self-managed AD that have not logged in for an extended period and may be considered stale or inactive. | Clean up stale user accounts. | | Domain Controller Time Source Test | `testDCTimeSource` | `DC_BAD_TIMESOURCE` | `Time sources not properly configured for PDC, should using an authoritative source. Time sources not properly configured for dcHostName, should using PDC as source` | Occurs if self-managed AD has the correct time source setup and that there is no large time skewness when compared to a AWS time source. | Your primary domain controller (PDC) time server is directed to `169.254.169.123`. Your non-primary domain controllers should be pointed to the PDC as the source. For more information, see [Keeping time with Amazon Time Sync Service](https://aws.amazon.com/blogs/aws/keeping-time-with-amazon-time-sync-service/). | | Free Space Test | `testFreeSpace` | `DISK_SPACE_EXCEEDED` | `Supported service max capacity of 7 GB exceeded; SysVol + NTDS is currently using: 24 GB)` | Occurs if your self-managed AD Combined NTDS and Sysvol usage is above supported quota. | Your self-managed AD should have 24 GB of disk space for hybrid directories. | | FSMO Roles Test | `testFSMORoles` | `FSMO_ROLE_TEST_FAILED` | `PDC Emulator (dc1.example.com) is not among the provided domain controllers.` `RID Master (dc1.example.com) is not among the provided domain controllers.` | Occurs if FSMO roles (PDC Emulator and RID Master) are not among the two domain controllers provided when you create a hybrid directory. | Your hybrid directory should have both FSMO roles (PDC Emulator and RID Master) among the two domain controllers that you provide when you create a hybrid directory. For more information, see [How to view and transfer FSMO roles](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/view-transfer-fsmo-roles). | | S channel SSP Test | `testSchannelSSP` | `TLS_1_2_NOT_ENABLED` | `Disabled protocol DisabledProtocol is still enabled.` | Occurs if a self-managed AD does not use TLS1.2 and AES256 encryption. | Your self-managed AD must use TLS 1.2 and AES256 for hybrid directories. | | Disk Corruption Test | `testDiskCorruption` | `DISK_CORRUPT` | `Disk corruption detected on Drive.` | Occurs if there is disk corruption on your self-managed AD. | Your self-managed AD disks should not be corrupted. | | Domain Controller Specs Test | `testDcSpecs` | `INSUFFICIENT_RESOURCES` | `numAvailableCores cores detected when requiredCores cores recommended. gbAvailableRam GB ram detected when requiredRam GB recommended.` | Occurs if your self-managed AD domain controllers don't meet the required specifications. | Your self-managed AD domain controllers should have at least 7 GB RAM and 2 CPU cores for hybrid directory. | | Server Level Plugin Dll Test | `testServerLevelPluginDll` | `SERVER_LEVEL_PLUGIN_DLL_IS_SET` | `ServerLevelPluginDll registry configuration is not permitted.` | Occurs if ServerLevelPluginDll is set on your self-managed AD domain controllers. | Your self-managed AD domain controllers should not have ServerLevelPluginDII configured. | | Allow NT4 Crypto Test | `testAllowNT4Crypto` | `NT4_CRYPTO_NOT_ALLOWED` | `Registry key AllowNt4Crypto is not allowed.` | Occurs if self-managed AD allows NT4 Cryptography. | Your self-managed AD should not use NT4 Cryptography. For more information, see Microsoft documentation. | | Orphaned Admin Users Test | `testOrphanedAdminUsers` | `ORPHANED_ADMIN_USER_FOUND` | `OrphanedUsersCount Orphaned Admin Users Found: [OrphanedUserNames].` | Occurs if orphaned admin users exist in your self-managed AD. | Remove orphaned users on your self-managed AD before continuing. | | Privileged User Count Test | `testPrivilegedUserCount` | `DOMAIN_ADMIN_COUNT_EXCEEDED` | `Number of Domain Admins (daCount) exceeded allowance of (allowedDomainAdminCount).` | Occurs if the total count of your Built-in Admins, Domain Admins,and Enterprise Admins on your self-managed AD a is greater than 5. | Your self-managed AD environment should not have multiple privileged accounts. You should remove excessive admin accounts before continuing. | | Privileged User Count Test | `testPrivilegedUserCount` | `ENTERPRISE_ADMIN_COUNT_EXCEEDED` | `Number of Enterprise Admins (eaCount) exceeded allowance of (allowedEnterpriseAdminCount).` | Occurs if the total count of your Built-in Admins, Domain Admins,and Enterprise Admins on your self-managed AD a is greater than 5. | Your self-managed AD environment should not have multiple privileged accounts. You should remove excessive admin accounts before continuing. | | Privileged User Count Test | `testPrivilegedUserCount` | `BUILTIN_ADMIN_COUNT_EXCEEDED` | `Number of Built-in Admins (baCount) exceeded allowance of (allowedAdminCount).` | Occurs if the total count of your Built-in Admins, Domain Admins,and Enterprise Admins on your self-managed AD a is greater than 5. | Your self-managed AD environment should not have multiple privileged accounts. You should remove excessive admin accounts before continuing. | | NTLM Test | `testNTLM` | `INSECURE_SETTING_NTLM` | `NTLMv1 is enabled.` | Occurs if NTLMv1 is enabled for authentication on your self-managed AD. | NT LAN Manager version 1 (NTLMv1) has known security vulnerabilities and should not be used. Disable NTLMv1 on your self-managed AD. For more information, see [Microsoft documentation](https://support.microsoft.com/en-us/topic/security-guidance-for-ntlmv1-and-lm-network-authentication-da2168b6-4a31-0088-fb03-f081acde6e73). | | Tombstone Lifetime Test | `testTombstoneLifetime` | `TOMBSTONE_LIFETIME_ABOVE_LIMIT` | `Tombstone Lifetime is too long. DC Tombstone Lifetime is TombstoneLifeTime, AWS suggested number is TombstoneMaximum days.` | Occurs if the Tombstone lifetime on your self-managed AD is more than 180 days. | The Tombstone lifetime is the number of days before a deleted object is removed from AD. The Tombstone lifetime value for your self-managed AD should be 180 days or less. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1887de08-2a9e-4694-95e2-898cde411180). | # Getting started with AWS Managed Microsoft AD Getting started AWS Managed Microsoft AD creates a fully managed, Microsoft Active Directory in the AWS Cloud and is powered by Windows Server 2019 and operates at the 2012 R2 Forest and Domain functional levels. When you create a directory with AWS Managed Microsoft AD, Directory Service creates two domain controllers and adds the DNS service on your behalf. The domain controllers are created in different subnets in an Amazon VPC this redundancy helps ensure that your directory remains accessible even if a failure occurs. If you need more domain controllers, you can add them later. For more information, see [Deploying additional domain controllers for your AWS Managed Microsoft AD](ms_ad_deploy_additional_dcs.md). For a demo and overview of AWS Managed Microsoft AD, see the following YouTube video. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/MdkhobcciX8?si=o0HpdeTIDwK3YWla/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/MdkhobcciX8?si=o0HpdeTIDwK3YWla) **Topics** + [ ## Prerequisites for creating a AWS Managed Microsoft AD ](#ms_ad_getting_started_prereqs) + [ ## AWS IAM Identity Center prerequisites ](#prereq_aws_sso_ms_ad) + [ ## Multi-factor authentication prerequisites ](#prereq_mfa_ad) + [ ## Creating your AWS Managed Microsoft AD ](#ms_ad_getting_started_create_directory) + [ # What gets created with your AWS Managed Microsoft AD ](ms_ad_getting_started_what_gets_created.md) + [ # AWS Managed Microsoft AD Administrator account and group permissions ](ms_ad_getting_started_admin_account.md) ## Prerequisites for creating a AWS Managed Microsoft AD AWS Managed Microsoft AD prerequisites To create an AWS Managed Microsoft AD Active Directory, you need an Amazon 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 have default hardware tenancy. + You cannot create a AWS Managed Microsoft AD in a VPC using addresses in the 198.18.0.0/15 address space. If you need to integrate your AWS Managed Microsoft AD domain with an existing on-premises Active Directory domain, you must have the Forest and Domain functional levels for your on-premises domain set to Windows Server 2003 or higher. 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 198.18.0.0/15. For a tutorial on how to create the AWS environment and AWS Managed Microsoft AD, see [AWS Managed Microsoft AD test lab tutorials](ms_ad_tutorial_test_lab.md). ## AWS IAM Identity Center prerequisites If you plan to use IAM Identity Center with AWS Managed Microsoft AD, you need to ensure that the following are true: + Your AWS Managed Microsoft AD directory is set up in your AWS organization's management account. + Your instance of IAM Identity Center is in the same Region where your AWS Managed Microsoft AD directory 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 To support multi-factor authentication with your AWS Managed Microsoft AD directory, you must configure either your on-premises or cloud-based [Remote Authentication Dial-In User Service](https://en.wikipedia.org/wiki/RADIUS) (RADIUS) server in the following way so that it can accept requests from your AWS Managed Microsoft AD directory in AWS. 1. On your RADIUS server, create two RADIUS clients to represent both of the AWS Managed Microsoft AD domain controllers (DCs) in AWS. You must configure both clients using the following common parameters (your RADIUS server may vary): + **Address (DNS or IP)**: This is the DNS address for one of the AWS Managed Microsoft AD DCs. Both DNS addresses can be found in the AWS Directory Service Console on the **Details** page of the AWS Managed Microsoft AD directory in which you plan to use MFA. The DNS addresses displayed represent the IP addresses for both of the AWS Managed Microsoft AD DCs that are used by AWS. **Note** If your RADIUS server supports DNS addresses, you must create only one RADIUS client configuration. Otherwise, you must create one RADIUS client configuration for each AWS Managed Microsoft AD DC. + **Port number**: Configure the port number for which your RADIUS server accepts RADIUS client connections. The standard RADIUS port is 1812. + **Shared secret**: Type or generate a shared secret that the RADIUS server will use to connect with RADIUS clients. + **Protocol**: You might need to configure the authentication protocol between the AWS Managed Microsoft AD DCs and the RADIUS server. Supported protocols are PAP, CHAP MS-CHAPv1, and MS-CHAPv2. MS-CHAPv2 is recommended because it provides the strongest security of the three options. + **Application name**: This may be optional in some RADIUS servers and usually identifies the application in messages or reports. 1. Configure your existing network to allow inbound traffic from the RADIUS clients (AWS Managed Microsoft AD DCs DNS addresses, see Step 1) to your RADIUS server port. 1. Add a rule to the Amazon EC2 security group in your AWS Managed Microsoft AD domain that allows inbound traffic from the RADIUS server DNS address and port number defined previously. For more information, see [Adding rules to a security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) in the *EC2 User Guide*. For more information about using AWS Managed Microsoft AD with MFA, see [Enabling multi-factor authentication for AWS Managed Microsoft AD](ms_ad_mfa.md). ## Creating your AWS Managed Microsoft AD To create a new AWS Managed Microsoft AD Active Directory, perform the following steps. Before starting this procedure, make sure that you have completed the prerequisites identified in [Prerequisites for creating a AWS Managed Microsoft AD](#ms_ad_getting_started_prereqs). **To create an AWS Managed Microsoft AD** 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 **AWS Managed Microsoft AD**, and then choose **Next**. 1. On the **Enter directory information** page, provide the following information: **Edition** Choose from either the **Standard Edition** or **Enterprise Edition** of AWS Managed Microsoft AD. For more information about editions, see [AWS Directory Service for Microsoft Active Directory](what_is.md#microsoftad). **Directory DNS name** The fully qualified name for the directory, such as `corp.example.com`. If you plan on using Amazon Route 53 for DNS, the domain name of your AWS Managed Microsoft AD must be different than your Route 53 domain name. DNS resolution issues can occur if Route 53 and AWS Managed Microsoft AD share the same domain name. **Directory NetBIOS name** The short name for the directory, such as `CORP`. **Directory description** An optional description for the directory. This description can be changed after creating your AWS Managed Microsoft AD. **Admin password** The password for the directory administrator. The directory creation process creates an administrator account with the user name `Admin` and this password. You can change the Admin password after creating your AWS Managed Microsoft AD. The password cannot include the word "admin." The directory administrator password is case-sensitive and must be between 8 and 64 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 administrator password. **(Optional) User and group management** To enable AWS Managed Microsoft AD user and group management from the AWS Management Console, select **Manage user and group management in the AWS Management Console**. For more information on how to use user and group management, see [Manage AWS Managed Microsoft AD users and groups with the AWS Management Console, AWS CLI, or AWS Tools for PowerShell](ms_ad_manage_users_groups_procedures.md). 1. On the **Choose VPC and subnets** page, provide the following information, and then choose **Next**. **VPC** Select the VPC for the directory. **Network type** The Internet Protocol (IP) addressing system associated with your VPC and subnets. Select the CIDR block associated to your existing VPC. Resources in your subnet can be configured to use IPv4 only, IPv6 only, or both IPv4 and IPv6 (dual-stack). For more information, 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*. **Subnets** Select the subnets for the domain controllers. The two subnets must be in different Availability Zones. 1. On the **Review & create** page, review the directory information and make any necessary changes. When the information is correct, choose **Create directory**. Creating the directory takes 20 to 40 minutes. Once created, the **Status** value changes to **Active**. For more information on what is created with your AWS Managed Microsoft AD, see the following: + [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md) + [AWS Managed Microsoft AD Administrator account and group permissions](ms_ad_getting_started_admin_account.md) **Related AWS Security blog articles** + [How to delegate administration of your AWS Managed Microsoft AD directory to your on-premises Active Directory users](https://aws.amazon.com/blogs/security/how-to-delegate-administration-of-your-aws-managed-microsoft-ad-directory-to-your-on-premises-active-directory-users/) + [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/) + [How to increase the redundancy and performance of your Directory Service for AWS Managed Microsoft AD by adding Domain controllers](https://aws.amazon.com/blogs/security/how-to-increase-the-redundancy-and-performance-of-your-aws-directory-service-for-microsoft-ad-directory-by-adding-domain-controllers/) + [How to enable the use of remote desktops by deploying Microsoft remote desktop licensing manager on AWS Managed Microsoft AD](https://aws.amazon.com/blogs/security/how-to-enable-the-use-of-remote-desktops-by-deploying-microsoft-remote-desktop-licensing-manager-on-aws-microsoft-ad/) + [How to access the AWS Management Console using AWS Managed Microsoft AD and your on-premises credentials](https://aws.amazon.com/blogs/security/how-to-access-the-aws-management-console-using-aws-microsoft-ad-and-your-on-premises-credentials/) + [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/) + [How to easily log on to AWS services by using your on-premises Active Directory](https://aws.amazon.com/blogs/security/how-to-easily-log-on-to-aws-services-by-using-your-on-premises-active-directory/) # What gets created with your AWS Managed Microsoft AD When you create an Active Directory with AWS Managed Microsoft AD, Directory Service performs the following tasks on your behalf: + Automatically creates and associates an elastic network interface (ENI) with each of your domain controllers. Each of these ENIs are essential for connectivity between your VPC and Directory Service domain controllers 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*. The default DNS Server of the AWS Managed Microsoft AD Active Directory is the VPC DNS server at Classless Inter-Domain Routing (CIDR)\$12. For more information, see [Amazon DNS server](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#AmazonDNS) in *Amazon VPC User Guide*. **Note** Domain controllers are deployed across two Availability Zones in a region by default and connected to your Amazon VPC (VPC). Backups are automatically taken once per day, and the Amazon EBS (EBS) volumes are encrypted to ensure that data is secured at rest. Domain controllers that fail are automatically replaced in the same Availability Zone using the same IP address, and a full disaster recovery can be performed using the latest backup. + Provisions Active Directory within your VPC using two domain controllers for fault tolerance and high availability. More domain controllers can be provisioned for higher resiliency and performance after the directory has been successfully created and is [Active](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_directory_status.html). For more information, see [Deploying additional domain controllers for your AWS Managed Microsoft AD](ms_ad_deploy_additional_dcs.md). **Note** AWS does not allow the installation of monitoring agents on AWS Managed Microsoft AD domain controllers. + Creates an [AWS Security group](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) *sg-1234567890abcdef0* that establishes network rules for traffic in and out of your domain controllers. The default outbound rule permits all traffic to all IPv4 addresses. The default inbound rules allows only traffic through ports that are required by Active Directory from the primary IPv4 CIDR block associated with the VPC hosting for your AWS Managed Microsoft AD. For additional security, the ENIs that are created do not have Elastic IPs attached to them and you do not have permission to attach an Elastic IP to those ENIs. Therefore by default, the only inbound traffic that can communicate with your AWS Managed Microsoft AD is local VPC. You can change the security group rules to allow additional traffic sources, for example from other peered VPCs or CIDRs reachable via VPN. Use extreme caution if you attempt to change these rules as you may break your ability to communicate with your domain controllers. For more information, see [AWS Managed Microsoft AD best practices](ms_ad_best_practices.md) and [Enhancing your AWS Managed Microsoft AD network security configuration](ms_ad_network_security.md). You can use [prefix lists]() to manage your CIDR blocks within the security group rules. Prefix lists make it easier to manage and configure security groups and route tables. You can consolidate multiple CIDR blocks with the same port and protocols to scale your network traffic. + In a Windows environment, clients often communicate via [Server Message Block (SMB)](https://learn.microsoft.com/en-us/windows/win32/fileio/microsoft-smb-protocol-and-cifs-protocol-overview) or port 445. This protocol facilitates various actions like file and printer sharing and general network communication. You will see clients traffic on port 445 to management interfaces of your AWS Managed Microsoft AD domain controllers. This traffic occurs as SMB clients rely on DNS (port 53) and NetBIOS (port 138) name resolution to locate your AWS Managed Microsoft AD domain resources. These clients are directed to any available interface on the domain controllers when locating domain resources. This behavior is expected and often occurs in environments with multiple network adapters and where [SMB Multichannel](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn610980(v=ws.11)) allows clients to establish connections across different interfaces for enhanced performance and redundancy. The following AWS Security group rules are created by default: **Inbound Rules** **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html) **Outbound Rules** **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html) + For more information about the ports and protocols used by Active Directory, see [Service overview and network port requirements for Windows](https://learn.microsoft.com/en-US/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements#system-services-ports) in Microsoft documentation. + Creates a directory administrator account with the user name Admin and the specified password. This account is located under the Users OU (For example, Corp > Users). You use this account to manage your directory in the AWS Cloud. For more information, see [AWS Managed Microsoft AD Administrator account and group permissions](ms_ad_getting_started_admin_account.md). **Important** Be sure to save this password. Directory Service does not store this password, and it cannot be retrieved. However, you can reset a password from the Directory Service console or by using the [ResetUserPassword](https://docs.aws.amazon.com/directoryservice/latest/devguide/API_ResetUserPassword.html) API. + Creates the following three organizational units (OUs) under the domain root: **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html) + Creates the following groups in the AWS Delegated Groups OU: **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html) **Note** You can add to these AWS Delegated Groups. + Creates and applies the following Group Policy Objects (GPOs): **Note** You do not have permissions to delete, modify, or unlink these GPOs. This is by design as they are reserved for AWS use. You may link them to OUs that you control if needed. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html) If you would like to see the settings of each GPO, you can view them from a domain joined Windows instance with the [Group policy management console (GPMC)](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753298(v=ws.10)) enabled. + Creates the following default local accounts for AWS Managed Microsoft AD management: **Important** Be sure to save the admin password. Directory Service does not store this password, and it cannot be retrieved. However, you [can reset a password from the Directory Service console](ms_ad_manage_users_groups_reset_password.md) or by using the [ResetUserPassword](https://docs.aws.amazon.com/directoryservice/latest/devguide/API_ResetUserPassword.html) API. **Admin** The Admin is the directory administrator account created when the AWS Managed Microsoft AD is first created. You provide a password for this account when you create an AWS Managed Microsoft AD. This account is located under the Users OU (For example, Corp > Users). You use this account to manage your Active Directory in the AWS. For more information, see [AWS Managed Microsoft AD Administrator account and group permissions](ms_ad_getting_started_admin_account.md). **AWS*\$1*11111111111**** Any account name starting with AWS followed by an underscore and located in AWS Reserved OU is a service-managed account. This service-managed account is used by AWS to interact with the Active Directory. These accounts are created when AWS Directory Service Data is enabled and with each new AWS application authorized on Active Directory. These accounts are only accessible by AWS services. **krbtgt account** The krbtgt account plays an important role in the Kerberos ticket exchanges used by your AWS Managed Microsoft AD. The krbtgt account is a special account used for Kerberos ticket-granting ticket (TGT) encryption, and it plays a crucial role in the security of the Kerberos authentication protocol. For more information, see [Microsoft documentation](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn745899(v=ws.11)#krbtgt-account). AWS automatically rotates the krbtgt account password for your AWS Managed Microsoft AD twice every 90 days. There is a 24 hour waiting period between the two consecutive rotations every 90 days. For more information about the admin account and other accounts created by Active Directory, see [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts). # AWS Managed Microsoft AD Administrator account and group permissions Administrator account and group permissions When you create an AWS Directory Service for Microsoft Active Directory directory, AWS creates an organizational unit (OU) to store all AWS related groups and accounts. For more information about this OU, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). This includes the Admin account. The Admin account has permissions to perform the following common administrative activities for your OU: + Add, update, or delete users, groups, and computers. For more information, see [User and group management in AWS Managed Microsoft AD](ms_ad_manage_users_groups.md). + Add resources to your domain such as file or print servers, and then assign permissions for those resources to users and groups in your OU. + Create additional OUs and containers. + Delegate authority of additional OUs and containers. For more information, see [Delegating directory join privileges for AWS Managed Microsoft AD](directory_join_privileges.md). + Create and link group policies. + Restore deleted objects from the Active Directory Recycle Bin. + Run Active Directory and DNS PowerShell modules on the Active Directory Web Service. + Create and configure group Managed Service Accounts. For more information, see [Group Managed Service Accounts](ms_ad_key_concepts.md#ms_ad_key_concepts_gmsa). + Configure Kerberos constrained delegation. For more information, see [Kerberos constrained delegation](ms_ad_key_concepts.md#ms_ad_key_concepts_kerberos). The Admin account also has rights to perform the following domainwide activities: + Manage DNS configurations (add, remove, or update records, zones, and forwarders) + View DNS event logs + View security event logs Only the actions listed here are allowed for the Admin account. The Admin account also lacks permissions for any directory-related actions outside of your specific OU, such as on the parent OU. **Considerations** + AWS Domain Administrators have full administrative access to all domains hosted on AWS. See your agreement with AWS and the [AWS data protection FAQ](https://aws.amazon.com/compliance/data-privacy-faq/) for more information about how AWS handles content, including directory information, that you store on AWS systems. + We recommend that you do not delete or rename this account. If you no longer want to use the account, we recommend you set a long password (at most 64 random characters) and then disable the account. **Note** AWS has exclusive control of the Domain Administrator and Enterprise Administrator privileged users and groups. This allows AWS to perform operational management of your directory. ## Enterprise and domain administrator privileged accounts AWS automatically rotates the built-in Administrator password to a random password every 90 days. Anytime the built in Administrator password is requested for human use an AWS ticket is created and logged with the Directory Service team. Account credentials are encrypted and handled over secure channels. Also the Administrator account credentials can only be requested by the Directory Service management team. To perform operational management of your directory, AWS has exclusive control of accounts with Enterprise Administrator and Domain Administrator privileges. This includes exclusive control of the Active Directory administrator account. AWS protects this account by automating password management through the use of a password vault. During automated rotation of the administrator password, AWS creates a temporary user account and grants it Domain Administrator privileges. This temporary account is used as a back-up in the event of password rotation failure on the administrator account. After AWS successfully rotates the administrator password, AWS deletes the temporary administrator account. Normally AWS operates the directory entirely through automation. In the event that an automation process is unable to resolve an operational problem, AWS may need to have a support engineer sign in to your domain controller (DC) to perform diagnosis. In these rare cases, AWS implements a request/notification system to grant access. In this process, AWS automation creates a time-limited user account in your directory that has Domain Administrator permissions. AWS associates the user account with the engineer who is assigned to work on your directory. AWS records this association in our log system and provides the engineer with the credentials to use. All actions taken by the engineer are logged in the Windows event logs. When the allocated time elapses, automation deletes the user account. You can monitor administrative account actions by using the log forwarding feature of your directory. This feature enables you to forward the AD Security events to your CloudWatch system where you can implement monitoring solutions. For more information, see [Enabling Amazon CloudWatch Logs log forwarding for AWS Managed Microsoft AD](ms_ad_enable_log_forwarding.md). Security Event IDs 4624, 4672 and 4648 are all logged when someone logs onto a DC interactively. You can view each DC's Windows Security event log using the Event Viewer Microsoft Management Console (MMC) from a domain joined Windows computer. You can also [Enabling Amazon CloudWatch Logs log forwarding for AWS Managed Microsoft AD](ms_ad_enable_log_forwarding.md) to send all of the Security event logs to CloudWatch Logs in your account. You might occasionally see users created and deleted within the AWS Reserved OU. AWS is responsible for the management and security of all objects in this OU and any other OU or container where we have not delegated permissions for you to access and manage. You may see creations and deletions in that OU. This is because Directory Service uses automation to rotate the Domain Administrator password on a regular basis. When the password is rotated, a backup is created in the event that the rotation fails. Once the rotation is successful, the backup account is automatically deleted. Also in the rare event that interactive access is needed on the DCs for troubleshooting purposes, a temporary user account is created for an Directory Service engineer to use. Once an engineer has completed their work, the temporary user account will be deleted. Note that every time interactive credentials are requested for a directory, the Directory Service management team is notified. # Key concepts and best practices for AWS Managed Microsoft AD Key concepts and best practices You can get more out of your AWS Managed Microsoft AD by becoming familiar with key concepts and best practices. Key concepts help you understand how AWS Managed Microsoft AD works. Key concepts include learning more about Active Directory schema, patching schedule, and Group Managed Service Accounts. Active Directory schema includes elements like attributes, classes, and objects that make up AWS Managed Microsoft AD. AWS patches your AWS Managed Microsoft AD domain controllers with Microsoft updates on your behalf. You can also learn more about group Managed Service Accounts (gMSAs) and use them with your AWS Managed Microsoft AD. You can avoid problems with your AWS Managed Microsoft AD by considering best practices. Some of these best practices include: + When setting up your AWS Managed Microsoft AD, configuring the security groups to meet your needs, remember your administrator account ID and password, and enable conditional forwarder setting. + When using your AWS Managed Microsoft AD, don't alter the organizational unit AWS created when the directory is created, monitor performance with tools like Amazon CloudWatch and Amazon SNS, and use SMB 2.x clients. + When programming applications to work with AWS Managed Microsoft AD, use Windows DC locator service, load test changes before rolling them out to production environments, and use efficient LDAP queries to avoid significant CPU cycles in a domain controller. **Topics** + [ # AWS Managed Microsoft AD key concepts ](ms_ad_key_concepts.md) + [ # AWS Managed Microsoft AD best practices ](ms_ad_best_practices.md) # AWS Managed Microsoft AD key concepts Key concepts You will get more out of AWS Managed Microsoft AD if you become familiar with the following key concepts. **Topics** + [ ## Active Directory schema ](#ms_ad_key_concepts_schema) + [ ## Patching and maintenance for AWS Managed Microsoft AD ](#ms_ad_key_concepts_maintenance) + [ ## Group Managed Service Accounts ](#ms_ad_key_concepts_gmsa) + [ ## Kerberos constrained delegation ](#ms_ad_key_concepts_kerberos) ## Active Directory schema A schema is the definition of attributes and classes that are part of a distributed directory and is similar to fields and tables in a database. Schemas include a set of rules which determine the type and format of data that can be added or included in the database. The User class is one example of a *class* that is stored in the database. Some example of User class attributes can include the user's first name, last name, phone number, and so on. ### Schema elements Attributes, classes and objects are the basic elements that are used to build object definitions in the schema. The following provides details about schema elements that are important to know before you begin the process to extend your AWS Managed Microsoft AD schema. **Attributes** Each schema attribute, which is similar to a field in a database, has several properties that define the characteristics of the attribute. For example, the property used by LDAP clients to read and write the attribute is `LDAPDisplayName`. The `LDAPDisplayName` property must be unique across all attributes and classes. For a complete list of attribute characteristics, see [Characteristics of Attributes](https://msdn.microsoft.com/en-us/library/ms675578(v=vs.85).aspx) on the MSDN website. For additional guidance on how to create a new attribute, see [Defining a New Attribute](https://msdn.microsoft.com/en-us/library/ms675883(v=vs.85).aspx) on the MSDN website. **Classes** The classes are analogous to tables in a database and also have several properties to be defined. For example, the `objectClassCategory` defines the class category. For a complete list of class characteristics, see [Characteristics of Object Classes](https://msdn.microsoft.com/en-us/library/ms675579(v=vs.85).aspx) on the MSDN website. For more information about how to create a new class, see [Defining a New Class](https://msdn.microsoft.com/en-us/library/ms675884(v=vs.85).aspx) on the MSDN website. **Object identifier (OID)** Each class and attribute must have an OID that is unique for all of your objects. Software vendors must obtain their own OID to ensure uniqueness. Uniqueness avoids conflicts when the same attribute is used by more than one application for different purposes. To ensure uniqueness, you can obtain a root OID from an ISO Name Registration Authority. Alternatively, you can obtain a base OID from Microsoft. For more information about OIDs and how to obtain them, see [Object Identifiers](https://msdn.microsoft.com/en-us/library/ms677614(v=vs.85).aspx) on the MSDN website. **Schema linked attributes** Some attributes are linked between two classes with forward and back links. The best example is groups. When you look at a group it shows you the members of the group; if you look at a user you can see what groups it belongs to. When you add a user to a group, Active Directory creates a forward link to the group. Then Active Directory adds a back link from the group to the user. A unique link ID must be generated when creating an attribute that will be linked. For more information, see [Linked Attributes](https://msdn.microsoft.com/en-us/library/ms677270(v=vs.85).aspx) on the MSDN website. #### Related topics + [When to extend your AWS Managed Microsoft AD schema](ms_ad_schema_extensions.md#ms_ad_schema_when_to_extend) + [Tutorial: Extending your AWS Managed Microsoft AD schema](ms_ad_tutorial_extend_schema.md) ## Patching and maintenance for AWS Managed Microsoft AD Patching and maintenance AWS Directory Service for Microsoft Active Directory, also known as AWS DS for AWS Managed Microsoft AD, is actually Microsoft Active Directory Domain Services (AD DS), delivered as a managed service. The system uses Microsoft Windows Server 2019 for the domain controllers (DCs), and AWS adds software to the DCs for service management purposes. AWS updates (patches) DCs to add new functionality and keep the Microsoft Windows Server software current. During the patching process, your directory remains available for use. ### Ensuring availability By default each directory consists of two DCs, each installed in a different Availability Zone. At your option, you may add DCs to further increase availability. For critical environments needing high-availability and fault-tolerance, we recommend deploying additional DCs. AWS patches your DCs sequentially, during which time the DC that AWS is actively patching is unavailable. In the event that one or more of your DCs is temporarily out of service, AWS defers patching until your directory has at least two operational DCs. This lets you use the other operating DCs during the patch process, which typically takes 30 to 45 minutes per DC, although this time may vary. To ensure your applications can reach an operating DC in the event that one or more DCs is unavailable for any reason, including patching, your applications should use the Windows DC locator service and not use static DC addresses. ### Understanding the patching schedule To keep the Microsoft Windows Server software current on your DCs, AWS utilizes Microsoft updates. As Microsoft makes monthly rollup patches available for Windows Server, AWS makes a best effort to test and apply the rollup to all customer DCs within three calendar weeks. In addition, AWS reviews updates that Microsoft releases outside of the monthly rollup based on applicability to DCs and urgency. For security patches that Microsoft rates as *Critical* or *Important*, and that are relevant to DCs, AWS makes every effort to test and deploy the patch within five days. ## Group Managed Service Accounts With Windows Server 2012, Microsoft introduced a new method that administrators could use to manage service accounts called group Managed Service Accounts (gMSAs). Using gMSAs, service administrators no longer needed to manually manage password synchronization between service instances. Instead, an administrator could simply create a gMSA in Active Directory and then configure multiple service instances to use that single gMSA. To grant permissions so users in AWS Managed Microsoft AD can create a gMSA, you must add their accounts as a member of the *AWS Delegated Managed Service Account Administrators* security group. By default, the Admin account is a member of this group. For more information about gMSAs, see [Group Managed Service Accounts Overview](https://technet.microsoft.com/en-us/library/hh831782(v=ws.11).aspx) on the Microsoft TechNet website. **Related AWS Security Blog post** + [How AWS Managed Microsoft AD Helps to Simplify the Deployment and Improve the Security of Active Directory-Integrated .NET Applications](https://aws.amazon.com/blogs/security/how-aws-managed-microsoft-ad-helps-to-simplify-the-deployment-and-improve-the-security-of-active-directory-integrated-net-applications/) ## Kerberos constrained delegation Kerberos constrained delegation is a feature in Windows Server. This feature gives service administrators the ability to specify and enforce application trust boundaries by limiting the scope where application services can act on a user's behalf. This can be useful when you need to configure which front-end service accounts can delegate to their backend services. Kerberos constrained delegation also prevents your gMSA from connecting to any and all services on behalf of your Active Directory users, avoiding the potential for abuse by a rogue developer. For example, let's say user jsmith logs into an HR application. You want the SQL Server to apply jsmith's database permissions. However, by default SQL Server opens the database connection using the service account credentials that apply hr-app-service's permissions instead of jsmith's configured permissions. You must make it possible for the HR payroll application to access the SQL Server database using the jsmith's credentials. To do that, you enable Kerberos constrained delegation for the hr-app-service service account on your AWS Managed Microsoft AD directory in AWS. When jsmith logs on, Active Directory provides a Kerberos ticket that Windows automatically uses when jsmith attempts to access other services in the network. Kerberos delegation enables the hr-app-service account to reuse the jsmith Kerberos ticket when accessing the database, thus applying permissions specific to jsmith when opening the database connection. To grant permissions that allow users in AWS Managed Microsoft AD to configure Kerberos constrained delegation, you must add their accounts as a member of the *AWS Delegated Kerberos Delegation Administrators* security group. By default, the Admin account is a member of this group. For more information about Kerberos constrained delegation, see [Kerberos Constrained Delegation Overview](https://technet.microsoft.com/en-us/library/jj553400(v=ws.11).aspx) on the Microsoft TechNet website. [Resource-based constrained delegation](https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview#resource-based-constrained-delegation-across-domains) was introduced with Windows Server 2012. It provides the back-end service administrator the ability to configure constrained delegation for the service. # AWS Managed Microsoft AD best practices Best practices Here are some suggestions and guidelines you should consider to avoid problems and get the most out of AWS Managed Microsoft AD. **Topics** + [ ## Best practices for setting up an AWS Managed Microsoft AD ](#ms_ad_best_practices_set_up) + [ ## Best practices when using an AWS Managed Microsoft AD directory ](#ms_ad_bp_using_directory) + [ ## Best practices when programming your applications for an AWS Managed Microsoft AD ](#program_apps) ## Best practices for setting up an AWS Managed Microsoft AD Setting up your directory Here are some suggestions and guidelines for when you're setting up your AWS Managed Microsoft AD: **Topics** + [ ### Prerequisites ](#ms_ad_best_practices_prereq) + [ ### Creating your AWS Managed Microsoft AD ](#ms_ad_best_practices_create) ### Prerequisites Consider these guidelines before creating your directory. #### Verify you have the right directory type 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 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 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 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 domain controller [elastic network interfaces](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html). This security group blocks unnecessary traffic to the domain controller and allows traffic that is necessary for Active Directory communications. AWS configures the security group to open only the ports that are required for Active Directory communications. In the default configuration, the security group accepts traffic to these ports from AWS Managed Microsoft AD VPC IPv4 CIDR address. AWS attaches the security group to your domain controller interfaces that are accessible from within your peered or resized [VPCs](https://aws.amazon.com/vpc/). These interfaces are inaccessible from the internet even if you modify routing tables, change the network connections to your VPC, and configure the [NAT Gateway service](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html). As such, only instances and computers that have a network path into the VPC can access the directory. This simplifies setup by eliminating the requirement for you to configure specific address ranges. Instead, you configure routes and security groups into the VPC that permit traffic only from trusted instances and computers. ##### Modifying the directory security group If you want to increase the security of your directory security groups, you can modify them to accept traffic from a more restrictive list of IP addresses. For example, you could change the accepted addresses from your VPC IPv4 CIDR range to a CIDR range that is specific to a single subnet or computer. Similarly, you might choose to restrict the destination addresses to which your domain controllers can communicate. Make such changes only if you fully understand how security group filtering works. For more information, see [Amazon EC2 security groups for Linux instances](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 the domain controller 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 security groups, which your directory uses, with other EC2 instances that you create. However, AWS recommends against this practice. AWS may have reasons to modify the security group without notice to address functional or security needs of the managed directory. Such changes affect any instances with which you associate the directory security group. Furthermore, associating the directory security group with your EC2 instances creates a potential security risk for your EC2 instances. The directory security group accepts traffic on required Active Directory ports from AWS Managed Microsoft AD VPC IPv4 CIDR address. If you associate this Security Group with an EC2 instance that has a public IP address attached to the internet, then any computer on the internet can communicate with your EC2 instance on the opened ports. ### Creating your AWS Managed Microsoft AD Here are some suggestions to consider as you create your AWS Managed Microsoft AD. **Topics** + [ #### Remember your administrator ID and password ](#ms_ad_remember_pw) + [ #### Create a DHCP options set ](#bp_create_dhcp_options_set) + [ #### Enable Conditional Forwarder Setting ](#bp_conditional_forwarder_settings) + [ #### Deploy additional domain controllers ](#bp_create_additional_dcs) + [ #### Understand username restrictions for AWS applications ](#usernamerestrictions) #### Remember your administrator ID and password When you set up your directory, you provide a password for the administrator account. That account ID is *Admin* for AWS Managed Microsoft AD. Remember the password that you create for this account; otherwise you will not be able to add objects to your directory. #### Create a DHCP options set We recommend that you create a DHCP options set for your Directory Service directory and assign the DHCP options set to the VPC that your directory is in. That way any instances in that VPC can point to the specified domain, and DNS servers can resolve their domain names. For more information about DHCP options sets, see [Creating or changing a DHCP options set for AWS Managed Microsoft AD](dhcp_options_set.md). #### Enable Conditional Forwarder Setting The following conditional forward settings *Store this conditional forwarder in Active Directory, replicate as follows:* should be enabled. Enabling these settings will ensure the conditional forwarder setting is persistent when a node is replaced due to infrastructure failure or overload failure. Conditional forwarders should be created on one Domain Controller with the previous setting enabled. This will allow replication to other Domain Controllers. #### Deploy additional domain controllers By default, AWS creates two domain controllers that exist in separate Availability Zones. This provides fault resiliency during software patching and other events that may make one domain controller unreachable or unavailable. We recommend that you [deploy additional domain controllers](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_deploy_additional_dcs.html) to further increase resiliency and ensure scale-out performance in the event of a longer term event that affects access to a domain controller or an Availability Zone. For more information, see [Use the Windows DC locator service](#program_dc_locator). #### Understand username restrictions for AWS applications 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. ## Best practices when using an AWS Managed Microsoft AD directory Using your directory Here are some suggestions to keep in mind when using your AWS Managed Microsoft AD. **Topics** + [ ### Do not alter predefined users, groups and organizational units ](#predefined_groups) + [ ### Automatically join domains ](#auto_join_domains) + [ ### Set up trusts correctly ](#setup_trust_correctly) + [ ### Track your domain controller performance ](#bp_scale_dcs) + [ ### Carefully plan for schema extensions ](#manage_schema_extensions) + [ ### About load balancers ](#manage_load_balancer) + [ ### Make a backup of your instance ](#make_backups) + [ ### Set up SNS messaging ](#use_sns) + [ ### Apply directory service settings ](#ds-settings) + [ ### Remove Amazon Enterprise applications before deleting a directory ](#remove_rds) + [ ### Use SMB 2.x clients when accessing the SYSVOL and NETLOGON shares ](#use_smbv2) ### Do not alter predefined users, groups and organizational units When you use Directory Service to launch a directory, AWS creates an organizational unit (OU) that contains all your directory's objects. This OU, which has the NetBIOS name that you typed when you created your directory, is located in the domain root. The domain root is owned and managed by AWS. Several groups and an administrative user are also created. Do not move, delete or in any other way alter these predefined objects. Doing so can make your directory inaccessible by both yourself and AWS. For more information, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). ### Automatically join domains When launching a Windows instance that is to be part of an Directory Service domain, it is often easiest to join the domain as part of the instance creation process rather than manually adding the instance later. To automatically join a domain, simply select the correct directory for **Domain join directory** when launching a new instance. You can find details in [Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD Active Directory](launching_instance.md). ### Set up trusts correctly When setting up trust relationship between your AWS Managed Microsoft AD directory and another directory, keep in mind these guidelines: + The trust type must match on both sides (Forest or External) + Ensure the trust direction is setup correctly if using a one-way trust (Outgoing on trusting domain, Incoming on trusted domain) + Both fully qualified domain names (FQDNs) and NetBIOS names must be unique between forests / domains For more details and specific instructions on setting up a trust relationship, see [Creating a trust relationship between your AWS Managed Microsoft AD and self-managed AD](ms_ad_setup_trust.md). ### Track your domain controller performance To help optimize scaling decisions and improve directory resilience and performance, we recommend that you use CloudWatch metrics. For more information, see [Using CloudWatch to monitor the performance of your AWS Managed Microsoft AD domain controllers](ms_ad_monitor_dc_performance.md). For instructions on how to set up domain controller metrics using the CloudWatch console, see [How to automate AWS Managed Microsoft AD scaling based on utilization metrics](https://aws.amazon.com/blogs/security/how-to-automate-aws-managed-microsoft-ad-scaling-based-on-utilization-metrics/) in the AWS Security Blog. ### Carefully plan for schema extensions Thoughtfully apply schema extensions to index your directory for important and frequent queries. Use care to not over-index the directory as indexes consume directory space and rapidly changing indexed values can result in performance problems. To add indexes, you must create a Lightweight Directory Access Protocol (LDAP) Directory Interchange Format (LDIF) file and extend your schema change. For more information, see [Extend your AWS Managed Microsoft AD schema](ms_ad_schema_extensions.md). ### About load balancers Do not use a load balancer in front of the AWS Managed Microsoft AD end-points. Microsoft designed Active Directory (AD) for use with a domain controller (DC) discovery algorithm that finds the most responsive operational DC without external load balancing. External network load balancers inaccurately detect active DCs and can result in your application being sent to a DC that is coming up but not ready for use. For more information, see [Load balancers and Active Directory](https://social.technet.microsoft.com/wiki/contents/articles/33547.load-balancers-and-active-directory.aspx) on Microsoft TechNet which recommends fixing applications to use Active Directory correctly rather than implementing external load balancers. ### Make a backup of your instance If you decide to manually add an instance to an existing Directory Service domain, make a backup or take a snapshot of that instance first. This is particularly important when joining a Linux instance. Some of the procedures used to add an instance, if not performed correctly, can render your instance unreachable or unusable. For more information, see [Restoring your AWS Managed Microsoft AD with snapshots](ms_ad_snapshots.md). ### Set up SNS messaging With Amazon Simple Notification Service (Amazon SNS), you can receive email or text (SMS) messages when the status of your directory changes. You will be notified if your directory goes from an **Active** status to an **Impaired** or **Inoperable** status. You also receive a notification when the directory returns to an Active status. Also remember that if you have an SNS topic that receives messages from Directory Service, before deleting that topic from the Amazon SNS console, you should associate your directory with a different SNS topic. Otherwise you risk missing important directory status messages. For information about how to set up Amazon SNS, see [Enabling AWS Managed Microsoft AD directory status notifications with Amazon Simple Notification Service](ms_ad_enable_notifications.md). ### Apply directory service settings AWS Managed Microsoft AD allows you to tailor your security configuration to meet your compliance and security requirements. AWS Managed Microsoft AD deploys and maintains the configuration to all domain controllers in your directory, including when adding new regions or additional domain controllers. You can configure and apply these security settings for all your new and existing directories. You can do this in the console by following the steps in [Edit directory security settings](ms_ad_directory_settings.md#edit-ds-settings) or through the [UpdateSettings API](https://docs.aws.amazon.com//directoryservice/latest/devguide/API_UpdateSettings.html). For more information, see [Editing AWS Managed Microsoft AD directory security settings](ms_ad_directory_settings.md). ### Remove Amazon Enterprise applications before deleting a directory Before deleting a directory that is associated with one or more Amazon Enterprise Applications such as, WorkSpaces, Amazon WorkSpaces Application Manager, WorkDocs, Amazon WorkMail, AWS Management Console, or Amazon Relational Database Service (Amazon RDS), you must first remove each application. For more information how to remove these applications, see [Deleting your AWS Managed Microsoft AD](ms_ad_delete.md). ### Use SMB 2.x clients when accessing the SYSVOL and NETLOGON shares Client computers use Server Message Block (SMB) to access the SYSVOL and NETLOGON shares on AWS Managed Microsoft AD domain controllers for Group Policy, login scripts and other files. AWS Managed Microsoft AD only supports SMB version 2.0 (SMBv2) and newer. The SMBv2 and newer version protocols add a number of features that improve client performance and increase the security of your domain controllers and clients. This change follows recommendations by the [United States Computer Emergency Readiness Team](https://www.us-cert.gov/ncas/current-activity/2017/01/16/SMB-Security-Best-Practices) and [Microsoft](https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/) to disable SMBv1. **Important** If you currently use SMBv1 clients to access the SYSVOL and NETLOGON shares of your domain controller, you must update those clients to use SMBv2 or newer. Your directory will work correctly but your SMBv1 clients will fail to connect to the SYSVOL and NETLOGON shares of your AWS Managed Microsoft AD domain controllers, and will also be unable to process Group Policy. SMBv1 clients will work with any other SMBv1 compatible file servers that you have. However, AWS recommends that you update all of your SMB servers and clients to SMBv2 or newer. To learn more about disabling SMBv1 and updating it to newer SMB versions on your systems, see these postings on [Microsoft TechNet](https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/) and [Microsoft Documentation](https://learn.microsoft.com/en-US/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server). **Tracking SMBv1 Remote Connections** You can review the **Microsoft-Windows-SMBServer/Audit** Windows Event log remotely connecting to the AWS Managed Microsoft AD domain controller, any events in this log indicate SMBv1 connections. Below is an example of the information you might see in one of these logs: *SMB1 access* *Client Address: \$1\$1\$1.\$1\$1\$1.\$1\$1\$1.\$1\$1\$1* *Guidance:* *This event indicates that a client attempted to access the server using SMB1. To stop auditing SMB1 access, use the PowerShell cmdlet Set-SmbServerConfiguration.* ## Best practices when programming your applications for an AWS Managed Microsoft AD Programming your applications for your directory Before you program your applications to work with AWS Managed Microsoft AD, consider the following: **Topics** + [ ### Use the Windows DC locator service ](#program_dc_locator) + [ ### Load test before rolling out to production ](#program_load_test) + [ ### Use efficient LDAP queries ](#program_ldap_query) ### Use the Windows DC locator service When developing applications, use the Windows DC locator service or use the Dynamic DNS (DDNS) service of your AWS Managed Microsoft AD to locate domain controllers (DCs). Do not hard code applications with the address of a DC. The DC locator service helps ensure directory load is distributed and enables you to take advantage of horizontal scaling by adding domain controllers to your deployment. If you bind your application to a fixed DC and the DC undergoes patching or recovery, your application will lose access to the DC instead of using one of the remaining DCs. Furthermore, hard coding of the DC can result in hot spotting on a single DC. In severe cases, hot spotting may cause your DC to become unresponsive. Such cases may also cause AWS directory automation to flag the directory as impaired and may trigger recovery processes that replace the unresponsive DC. ### Load test before rolling out to production Be sure to do lab testing with objects and requests that are representative of your production workload to confirm that the directory scales to the load of your application. Should you require additional capacity, test with additional DCs while distributing requests between the DCs. For more information, see [Deploying additional domain controllers for your AWS Managed Microsoft AD](ms_ad_deploy_additional_dcs.md). ### Use efficient LDAP queries Broad LDAP queries to a domain controller across tens of thousands of objects can consume significant CPU cycles in a single DC, resulting in hot spotting. This may affect applications that share the same DC during the query. # Use cases for AWS Managed Microsoft AD Use cases With AWS Managed Microsoft AD, you can share a single directory for multiple use cases. For example, you can share a directory to authenticate and authorize access for .NET applications, [Amazon RDS for SQL Server](https://aws.amazon.com/rds/sqlserver/) with [Windows authentication](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.html) enabled, and [Amazon Chime](https://chime.aws/) for messaging and video conferencing. The following diagram shows some of the use cases for your AWS Managed Microsoft AD directory. These include the ability to grant your users access to external cloud applications and allow your on-premises Active Directory users to manage and have access to resources in the AWS Cloud. ![\[Use cases for your AWS Managed Microsoft AD directory like granting your users access to external cloud applications, allowing your on-premises Active Directory users to manage and have access to resources in the AWS Cloud.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/ms_ad_use_cases2.png) Use AWS Managed Microsoft AD for either of the following business use cases. **Topics** + [ # Use Case 1: Sign in to AWS applications and services with Active Directory credentials ](usecase1.md) + [ # Use Case 2: Manage Amazon EC2 instances ](usecase2.md) + [ # Use Case 3: Provide directory services to your Active Directory-aware workloads ](usecase3.md) + [ # Use Case 4: AWS IAM Identity Center to Office 365 and other cloud applications ](usecase4.md) + [ # Use Case 5: Extend your on-premises Active Directory to the AWS Cloud ](usecase5.md) + [ # Use Case 6: Share your directory to seamlessly join Amazon EC2 instances to a domain across AWS accounts ](usecase6.md) # Use Case 1: Sign in to AWS applications and services with Active Directory credentials You can enable multiple AWS applications and services such as [AWS Client VPN](https://aws.amazon.com/vpn/), [AWS Management Console](https://aws.amazon.com/console/), [AWS IAM Identity Center](https://aws.amazon.com/single-sign-on/), [Amazon Chime](https://aws.amazon.com/chime/), [Amazon Connect](https://aws.amazon.com/connect), [Amazon FSx](https://aws.amazon.com/fsx/windows/), [Quick](https://aws.amazon.com/quicksight/), [Amazon RDS for SQL Server](https://aws.amazon.com/rds/sqlserver/), [WorkDocs](https://aws.amazon.com/workdocs), [Amazon WorkMail](https://aws.amazon.com/workmail/), and [WorkSpaces](https://aws.amazon.com/workspaces/) to use your AWS Managed Microsoft AD directory. When you enable an AWS application or service in your directory, your users can access the application or service with their Active Directory credentials. For example, you can enable your users to [sign in to the AWS Management Console with their Active Directory credentials](https://aws.amazon.com/blogs/security/how-to-access-the-aws-management-console-using-aws-microsoft-ad-and-your-on-premises-credentials/). To do this, you enable the AWS Management Console as an application in your directory, and then assign your Active Directory users and groups to IAM roles. When your users sign in to the AWS Management Console, they assume an IAM role to manage AWS resources. This makes it easy for you to grant your users access to the AWS Management Console without needing to configure and manage a separate SAML infrastructure. To further enhance the end user experience you can enable [Single sign-on](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_single_sign_on.html) capabilities for WorkDocs, which provides your users the ability to access WorkDocs from a computer joined to the directory without having to enter their credentials separately. You can grant access to user accounts in your directory or in your on-premises Active Directory, so they can sign in to the AWS Management Console or through the AWS CLI using their existing credentials and permissions to manage AWS resources by assigning IAM roles directly to the existing user accounts. ## FSx for Windows File Server integration with AWS Managed Microsoft AD Integrating FSx for Windows File Server with AWS Managed Microsoft AD provides a fully managed native Microsoft Windows based Server Message Block (SMB) protocol file system that allows you to easily move your Windows-based applications and clients (that utilize shared file storage) to AWS. Although FSx for Windows File Server can be integrated with a self-managed Microsoft Active Directory, we do not discuss that scenario here. ### Common Amazon FSx use cases and resources This section provides a reference to resources on common FSx for Windows File Server integrations with AWS Managed Microsoft AD use cases. Each of the use cases in this section start with a basic AWS Managed Microsoft AD and FSx for Windows File Server configuration. For more information about how to create these configurations, see: + [Getting started with AWS Managed Microsoft AD](ms_ad_getting_started.md) + [Getting started with Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/getting-started.html) #### FSx for Windows File Server as persistent storage on Windows containers [Amazon Elastic Container Service (ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) supports Windows containers on container instances that are launched with the Amazon ECS-optimized Windows AMI. Windows container instances use their own version of the Amazon ECS container agent. On the Amazon ECS-optimized Windows AMI, the Amazon ECS container agent runs as a service on the host. Amazon ECS supports Active Directory authentication for Windows containers through a special kind of service account called a group Managed Service Account (gMSA). Because Windows containers cannot be domain-joined, you must configure a Windows container to run with gMSA. **Related Items** + [Using FSx for Windows File Server as persistent storage on Windows Containers](https://aws.amazon.com/blogs/containers/using-amazon-fsx-for-windows-file-server-as-persistent-storage-on-windows-containers/) + [Group Managed Service Accounts](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_key_concepts_gmsa.html) #### Amazon AppStream 2.0 support [Amazon AppStream 2.0](https://docs.aws.amazon.com/appstream2/latest/developerguide/what-is-appstream.html) is a fully managed application streaming service. It provides a range of solutions for users to save and access data through their applications. Amazon FSx with WorkSpaces Applications provides a personal persistent storage drive using Amazon FSx and can be configured to provide a shared folder to access common files. **Related Items** + [Walkthrough 4: Using Amazon FSx with Amazon AppStream 2.0](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/walkthrough04-fsx-with-appstream2.html) + [Using Amazon FSx with Amazon AppStream 2.0](https://aws.amazon.com/blogs/desktop-and-application-streaming/using-amazon-fsx-with-amazon-appstream-2-0/) + [Using Active Directory with WorkSpaces Applications](https://docs.aws.amazon.com/appstream2/latest/developerguide/active-directory.html) #### Microsoft SQL Server support FSx for Windows File Server can be used as a storage option for Microsoft SQL Server 2012 (starting with 2012 version 11.x) and newer system databases (including Master, Model, MSDB, and TempDB), and for Database Engine user databases. **Related Items** + [Install SQL Server with SMB fileshare storage](https://docs.microsoft.com/en-us/sql/database-engine/install-windows/install-sql-server-with-smb-fileshare-as-a-storage-option?view=sql-server-ver15) + [Simplify your Microsoft SQL Server high availability deployments using FSx for Windows File Server](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) + [Group Managed Service Accounts](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_key_concepts_gmsa.html) #### Home folders and roaming user profile support FSx for Windows File Server can be used to store data from Active Directory user home folders and My Documents in a central location. FSx for Windows File Server can also be used to store data from Roaming User Profiles. **Related items** + [Windows home directories made easy with Amazon FSx](https://aws.amazon.com/blogs/storage/windows-home-directories-and-file-shares-made-easy-with-amazon-fsx/) + [Deploying roaming user profiles](https://docs.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-roaming-user-profiles) + [Using FSx for Windows File Server with WorkSpaces](https://aws.amazon.com/blogs/desktop-and-application-streaming/using-amazon-fsx-for-windows-file-server-with-amazon-workspaces/) #### Networked file share support Networked file shares on an FSx for Windows File Server provide a managed and scalable file sharing solution. One use case is mapped drives for clients that can be created manually or via Group Policy. **Related items** + [Walkthrough 6: Scaling out performance with Shards](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/scale-out-performance.html) + [Drive mapping](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn581924(v%3Dws.11)) + [Using FSx for Windows File Server with WorkSpaces](https://aws.amazon.com/blogs/desktop-and-application-streaming/using-amazon-fsx-for-windows-file-server-with-amazon-workspaces/) #### Group policy software installation support Because the size and performance of the SYSVOL folder is limited, you should as a best practice, avoid storing data such as software installation files in that folder. As a possible solution to this, FSx for Windows File Server can be configured to store all software files that are installed using Group Policy. **Related items** + [Use Group Policy to remotely install software](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/use-group-policy-to-install-software) #### Windows Server Backup target support FSx for Windows File Server can be configured as a target drive in Windows Server Backup using the UNC file share. In this case, you would specify the UNC path to your FSx for Windows File Server instead of to the attached EBS volume. **Related Items** + [Perform a system state recovery of your server](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee849849(v=ws.10)#to-perform-a-system-state-recovery-of-your-server) Amazon FSx also supports AWS Managed Microsoft AD Directory Sharing. For more information, see: + [Share your AWS Managed Microsoft AD](ms_ad_directory_sharing.md) + [Using Amazon FSx with AWS Managed Microsoft AD in a different VPC or account](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shared-mad.html) ## Amazon RDS integration with AWS Managed Microsoft AD Amazon RDS supports external authentication of database users using Kerberos with Microsoft Active Directory. Kerberos is a network authentication protocol that uses tickets and symmetric-key cryptography to eliminate the need to transmit passwords over the network. Amazon RDS support for Kerberos and Active Directory provides the benefits of single sign-on and centralized authentication of database users so you can keep your user credentials in Active Directory. To get started with this use case you will first need to set up a basic AWS Managed Microsoft AD and Amazon RDS configuration. + [Getting started with AWS Managed Microsoft AD](ms_ad_getting_started.md) + [Getting started with Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.html) All of the use cases referenced below will start with a base AWS Managed Microsoft AD and Amazon RDS and cover how to integrate Amazon RDS with AWS Managed Microsoft AD. + [Using Windows authentication with an Amazon RDS for SQL Server DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.html) + [Using Kerberos authentication for MySQL ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-kerberos.html) + [Using Kerberos authentication with Amazon RDS for Oracle ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/oracle-kerberos.html) + [Using Kerberos authentication with Amazon RDS for PostgreSQL ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/postgresql-kerberos.html) Amazon RDS also supports AWS Managed Microsoft AD Directory Sharing. For more information, see: + [Share your AWS Managed Microsoft AD](ms_ad_directory_sharing.md) + [Joining your Amazon RDS DB instances across accounts to a single shared domain](https://aws.amazon.com/blogs/database/joining-your-amazon-rds-instances-across-accounts-to-a-single-shared-domain/) For more information about joining an Amazon RDS for SQL Server to your Active Directory, see [Join Amazon RDS for SQL Server to your self-managed Active Directory](https://aws.amazon.com/blogs//database/join-amazon-rds-for-sql-server-to-your-self-managed-active-directory/). ### .NET application using Amazon RDS for SQL Server with group Managed Service Accounts You can integrate Amazon RDS for SQL Server with a basic .NET application and group Managed Service Accounts (gMSAs). For more information, see [How AWS Managed Microsoft AD Helps to Simplify the Deployment and Improve the Security of Active Directory-Integrated .NET Applications ](https://aws.amazon.com/blogs/security/how-aws-managed-microsoft-ad-helps-to-simplify-the-deployment-and-improve-the-security-of-active-directory-integrated-net-applications/) # Use Case 2: Manage Amazon EC2 instances Using familiar Active Directory administration tools, you can apply Active Directory group policy objects (GPOs) to centrally manage your Amazon EC2 for Windows or Linux instances by [joining your instances to your AWS Managed Microsoft AD domain](https://docs.aws.amazon.com/en_us/directoryservice/latest/admin-guide/ms_ad_join_instance.html). In addition, your users can sign in to your instances with their Active Directory credentials. This eliminates the need to use individual instance credentials or distribute private key (PEM) files. This makes it easier for you to instantly grant or revoke access to users by using Active Directory user administration tools you already use. # Use Case 3: Provide directory services to your Active Directory-aware workloads AWS Managed Microsoft AD is an actual Microsoft Active Directory that enables you to run traditional Active Directory-aware workloads such as [Remote Desktop Licensing Manager](https://aws.amazon.com/blogs/security/how-to-enable-the-use-of-remote-desktops-by-deploying-microsoft-remote-desktop-licensing-manager-on-aws-microsoft-ad/) and [Microsoft SharePoint and Microsoft SQL Server Always On](https://forums.aws.amazon.com/ann.jspa?annID=4636) in the AWS Cloud. AWS Managed Microsoft AD also helps you to simplify and improve the security of Active Directory-integrated .NET applications by using [group Managed Service Accounts (gMSAs) and Kerberos constrained delegation (KCD)](https://aws.amazon.com/about-aws/whats-new/2017/05/simplify-migration-and-improve-security-of-active-directory-integrated-net-applications-by-using-aws-microsoft-ad/). # Use Case 4: AWS IAM Identity Center to Office 365 and other cloud applications You can use AWS Managed Microsoft AD to provide AWS IAM Identity Center services for cloud applications. You can use Microsoft Entra Connect (formerly known as Azure Active Directory Connect) to synchronize your users into Microsoft Entra (formerly known as Azure Active Directory (Azure AD)), and then use Active Directory Federation Services (AD FS) so that your users can access [Microsoft Office 365](https://aws.amazon.com/blogs/security/how-to-enable-your-users-to-access-office-365-with-aws-microsoft-active-directory-credentials/) and other SAML 2.0 cloud applications by using their Active Directory credentials. [Integrating AWS Managed Microsoft AD with IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) adds SAML capabilities to your AWS Managed Microsoft AD and / or your on-premises trusted domains. Once integrated your users can then use IAM Identity Center with services that support SAML, including the AWS Management Console and third-party cloud applications such as Office 365, Concur, and Salesforce without having to configure a SAML infrastructure. For a demonstration on the process of allowing your on-premises users to use IAM Identity Center, see the following YouTube video. **Note** AWS Single Sign-On was renamed to IAM Identity Center. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/nuPjljOVZmU/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/nuPjljOVZmU) # Use Case 5: Extend your on-premises Active Directory to the AWS Cloud If you already have an Active Directory infrastructure and want to use it when migrating Active Directory-aware workloads to the AWS Cloud, AWS Managed Microsoft AD can help. You can use [Active Directory trusts](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_trust.html) to connect AWS Managed Microsoft AD to your existing Active Directory. This means your users can access Active Directory-aware and AWS applications with their on-premises Active Directory credentials, without needing you to synchronize users, groups, or passwords. For example, your users can sign in to the AWS Management Console and Amazon WorkSpaces by using their existing Active Directory user names and passwords. Also, when you use Active Directory-aware applications such as SharePoint with AWS Managed Microsoft AD, your logged-in Windows users can access these applications without needing to enter credentials again. You can also migrate your on-premises Active Directory domain to AWS to be free of the operational burden of your Active Directory infrastructure using the [Active Directory Migration Toolkit (ADMT)](https://aws.amazon.com/blogs/security/how-to-migrate-your-on-premises-domain-to-aws-managed-microsoft-ad-using-admt/) along with the Password Export Service (PES) to perform the migration. # Use Case 6: Share your directory to seamlessly join Amazon EC2 instances to a domain across AWS accounts Sharing your directory across multiple AWS accounts enables you to manage AWS services such as [Amazon EC2](https://aws.amazon.com/ec2/) easily without the need to operate a directory for each account and each VPC. You can use your directory from any AWS account and from any [Amazon VPC](https://aws.amazon.com/vpc/) within an AWS Region. This capability makes it easier and more cost effective to manage directory-aware workloads with a single directory across accounts and VPCs. For example, you can now manage your [Windows workloads](https://aws.amazon.com/windows/) deployed in EC2 instances across multiple accounts and VPCs easily by using a single AWS Managed Microsoft AD directory. When you share your AWS Managed Microsoft AD directory with another AWS account, you can use the Amazon EC2 console or [AWS Systems Manager](https://aws.amazon.com/systems-manager/) to seamlessly join your instances from any Amazon VPC within the account and AWS Region. You can quickly deploy your directory-aware workloads on EC2 instances by eliminating the need to manually join your instances to a domain or to deploy directories in each account and VPC. For more information, see [Share your AWS Managed Microsoft AD](ms_ad_directory_sharing.md). # Maintain your AWS Managed Microsoft AD Maintain your directory You can use the AWS Management Console to maintain your AWS Managed Microsoft AD and complete day-to-day administrative tasks. Ways you can maintain your directory include: + [View your AWS Managed Microsoft AD directory details](ms_ad_view_directory_info.md) to learn your AWS Managed Microsoft AD directory type, directory ID, directory status, and networking details such as its Amazon VPC, subnets, and Availability zones. + [Restore your AWS Managed Microsoft AD with snapshots](ms_ad_snapshots.md). You can also create snapshot and delete snapshots. + [Deploy additional domain controllers](ms_ad_deploy_additional_dcs.md) to improve your AWS Managed Microsoft AD performance and availability. + [Upgrade your AWS Managed Microsoft AD](ms_ad_upgrade_edition.md) from Standard edition to Enterprise edition which supports more directory objects. + [Add alternate user principal name (UPN)](ms_ad_upn_suffixes.md) to improve the user login experience. + [Rename your AWS Managed Microsoft AD site name](ms_ad_rename_site.md) to improve AWS Managed Microsoft AD ability to find and authenticate your existing Active Directory users in your on-premises directory. + [Delete your AWS Managed Microsoft AD](ms_ad_delete.md) when you no longer need it. # Viewing AWS Managed Microsoft AD directory information Viewing directory information You can use the AWS Management Console to view your AWS Managed Microsoft AD directory details like: + Directory type + Directory ID + Directory status + Networking details for your AWS Managed Microsoft AD like: + Amazon VPC + Subnets + Availability zones + DNS addresses You can find the following information about your AWS Managed Microsoft AD: + Under the **Share & share** tab, you can share your AWS Managed Microsoft AD with other AWS accounts and learn the networking details for your domain controllers. + Under the **Application management** tab, you can enable an application access URL for your AWS Managed Microsoft AD and enable AWS applications and services for your AWS Managed Microsoft AD. + Under the **Maintenance** tab, you can enable Amazon Simple Notification Service to receive notifications of your AWS Managed Microsoft AD status and review snapshots of your AWS Managed Microsoft AD. + For more information about the **Status** field, see [Understanding your AWS Managed Microsoft AD directory status](ms_ad_directory_status.md). You can view AWS Managed Microsoft AD directory information using the AWS Management Console, AWS CLI, or PowerShell: ------ #### [ AWS Management Console ] **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. ![\[Directory Service Directory details page.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/ms_ad_directory_details.png) ------ #### [ AWS CLI ] **To view detailed directory information with the AWS CLI** + Open the AWS CLI. To view your AWS Managed Microsoft AD directory information, run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` aws ds describe-directories --directory-id d-1234567890 --output table ``` For more information, see [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/describe-directories.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/describe-directories.html). ------ #### [ PowerShell ] **To view detailed directory information with PowerShell** + Open PowerShell. To view your AWS Managed Microsoft AD directory information, run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` (Get-DSDirectory -DirectoryId d-1234567890 | ForEach-Object {$_, $_.RegionsInfo, $_.VpcSettings}) | Format-List * ``` For more information, see [https://docs.aws.amazon.com//powershell/latest/reference/items/Get-DSDirectory.html](https://docs.aws.amazon.com//powershell/latest/reference/items/Get-DSDirectory.html). ------ # Restoring your AWS Managed Microsoft AD with snapshots Restoring your directory with snapshots AWS Directory Service provides automated daily snapshots and the ability to take manual snapshots of data for your AWS Managed Microsoft AD Active Directory. These snapshots can be used to perform a point-in-time restore for your Active Directory. You are limited to five manual snapshots for each AWS Managed Microsoft AD Active Directory. If you have already reached this limit, you must delete one of your existing manual snapshots before you can create another. You cannot take snapshots of AD Connector directories. **Note** Snapshot is a global feature of AWS Managed Microsoft AD. If you are using [Configure Multi-Region replication for AWS Managed Microsoft AD](ms_ad_configure_multi_region_replication.md), the following procedures must be performed in the [Primary Region](multi-region-global-primary-additional.md#multi-region-primary). The changes will be applied across all replicated Regions automatically. For more information, see [Global vs Regional features](multi-region-global-region-features.md). **Topics** + [ ## Creating a snapshot of your directory ](#snapshot_create) + [ ## Restoring your directory from a snapshot ](#snapshot_restore) + [ ## Deleting a snapshot ](#snapshot_delete) ## Creating a snapshot of your directory A snapshot can be used to restore your directory to what it was at the point in time that the snapshot was taken. To create a manual snapshot of your directory, perform the following steps. **Note** You are limited to 5 manual snapshots for each directory. If you have already reached this limit, you must delete one of your existing manual snapshots before you can create another. Use the following procedure to create a manual snapshot of your AWS Managed Microsoft AD with the AWS Management Console, AWS CLI, or PowerShell: ------ #### [ AWS Management Console ] **To create a manual snapshot in the AWS Management Console** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**. 1. On the **Directories** page, choose your directory ID. 1. On the **Directory details** page, choose the **Maintenance** tab. 1. In the **Snapshots** section, choose **Actions**, and then select **Create snapshot**. 1. In the **Create directory snapshot** dialog box, provide a name for the snapshot, if desired. When ready, choose **Create**. ------ #### [ AWS CLI ] **To create a manual snapshot with AWS CLI** + Open the AWS CLI. To create a snapshot of your AWS Managed Microsoft AD, run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` aws ds create-snapshot --directory-id d-1234567890 --name ManualSnapshot ``` For more information, see [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/create-snapshot.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/create-snapshot.html). ------ #### [ PowerShell ] **To create a manual snapshot with PowerShell** + Open PowerShell. To create a snapshot of your AWS Managed Microsoft AD, run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` New-DSSnapshot -DirectoryId d-1234567890 -Name ManualSnapshot ``` For more information, see [https://docs.aws.amazon.com//powershell/latest/reference/items/New-DSSnapshot.html](https://docs.aws.amazon.com//powershell/latest/reference/items/New-DSSnapshot.html). ------ Depending on the size of your directory, it may take several minutes to create the snapshot. When the snapshot is ready, the **Status** value changes to `Completed`. ## Restoring your directory from a snapshot Restoring a directory from a snapshot is equivalent to moving the directory back in time. Directory snapshots are unique to the directory they were created from. A snapshot can only be restored to the directory from which it was created. In addition, the maximum supported age of a manual snapshot is 180 days. For more information, see [Useful shelf life of a system-state backup of Active Directory](https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/shelf-life-system-state-backup-ad) on the Microsoft website. **Warning** We recommend that you contact the [AWS Support Center](https://console.aws.amazon.com/support/home#/) before any snapshot restore; we may be able to help you avoid the need to do a snapshot restore. Any restore from snapshot can result in data loss as they are a point in time. It is important you understand that all of the DCs and DNS servers associated with the directory will be offline until the restore operation has been completed. Use the following procedure to restore your directory from a snapshot using the AWS Management Console, AWS CLI, or PowerShell: ------ #### [ AWS Management Console ] **To restore a directory from a snapshot in the AWS Management Console** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**. 1. On the **Directories** page, choose your directory ID. 1. On the **Directory details** page, choose the **Maintenance** tab. 1. In the **Snapshots** section, select a snapshot in the list, choose **Actions**, and then select **Restore snapshot**. 1. Review the information in the **Restore directory snapshot** dialog box, and choose **Restore**. ------ #### [ AWS CLI ] **To restore a directory from a snapshot with AWS CLI** 1. Open the AWS CLI. To list the snapshots for your AWS Managed Microsoft AD, run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` aws ds describe-snapshots --directory-id d-1234567890 \ --query '(sort_by(Snapshots[*].{ID:SnapshotId,Status:Status,Type:Type,StartTime:StartTime}, &StartTime))' \ --output table ``` 1. To restore your AWS Managed Microsoft AD from a snapshot, you can use the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/restore-from-snapshot.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/restore-from-snapshot.html) command. Ensure you replace the `snapshot-id` parameter with the snapshot ID you want to use to restore your AWS Managed Microsoft AD: ``` aws ds restore-from-snapshot --snapshot-id s-1234567890 ``` ------ #### [ PowerShell ] **To restore a directory from a snapshot with PowerShell** 1. Open PowerShell. To list the snapshots for your AWS Managed Microsoft AD, run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` Get-DSSnapshot -DirectoryId d-1234567890 | Sort-Object StartTime | Format-Table ``` 1. To restore your AWS Managed Microsoft AD from a snapshot, you can use the [https://docs.aws.amazon.com//powershell/latest/reference/items/Restore-DSFromSnapshot.html](https://docs.aws.amazon.com//powershell/latest/reference/items/Restore-DSFromSnapshot.html) command. Ensure you replace the `snapshot-id` parameter with the snapshot ID you want to use to restore your AWS Managed Microsoft AD: ``` Restore-DSFromSnapshot -SnapshotId s-1234567890 ``` ------ For an AWS Managed Microsoft AD directory, it can take from two to three hours for the directory to be restored. When it has been successfully restored, the **Status** value of the directory changes to `Active`. Any changes made to the directory after the snapshot date are overwritten. ## Deleting a snapshot Use the following procedure to delete a snapshot of your AWS Managed Microsoft AD with the AWS Management Console, AWS CLI, or PowerShell: ------ #### [ AWS Management Console ] **To delete a snapshot in the AWS Management Console** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**. 1. On the **Directories** page, choose your directory ID. 1. On the **Directory details** page, choose the **Maintenance** tab. 1. In the **Snapshots** section, choose **Actions**, and then select **Delete snapshot**. 1. Verify that you want to delete the snapshot, and then choose **Delete**. ------ #### [ AWS CLI ] **To delete a snapshot with AWS CLI** 1. Open the AWS CLI. To list the snapshots for your AWS Managed Microsoft AD, run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` aws ds describe-snapshots --directory-id d-1234567890 \ --query '(sort_by(Snapshots[*].{ID:SnapshotId,Status:Status,Type:Type,StartTime:StartTime}, &StartTime))' \ --output table ``` 1. To delete a snapshot of your AWS Managed Microsoft AD, you can use the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/delete-snapshot.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/delete-snapshot.html) command. Ensure you replace the `snapshot-id` parameter with the snapshot ID of the snapshot you want to delete: ``` aws ds delete-snapshot --snapshot-id s-1234567890 ``` ------ #### [ PowerShell ] **To delete a snapshot with PowerShell** 1. Open PowerShell. To list the snapshots for your AWS Managed Microsoft AD, run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` Get-DSSnapshot -DirectoryId d-1234567890 | Sort-Object StartTime | Format-Table ``` 1. To restore your AWS Managed Microsoft AD from a snapshot, you can use the [https://docs.aws.amazon.com//powershell/latest/reference/items/Remove-DSSnapshot.html](https://docs.aws.amazon.com//powershell/latest/reference/items/Remove-DSSnapshot.html) command. Ensure you replace the `snapshot-id` parameter with the snapshot ID of the snapshot you want to delete: ``` Remove-DSSnapshot -SnapshotId s-1234567890 ``` ------ # Deploying additional domain controllers for your AWS Managed Microsoft AD Deploying additional domain controllers Deploying additional domain controllers for your AWS Managed Microsoft AD increases the redundancy, which results in even greater resilience and higher availability. This also improves the performance of your directory by supporting a greater number of Active Directory requests. For example, you can now use AWS Managed Microsoft AD to support multiple .NET applications that are deployed on large fleets of Amazon EC2 and Amazon RDS for SQL Server instances. When you first create your directory, AWS Managed Microsoft AD deploys two domain controllers across multiple Availability Zones, which is required for highly availability purposes. Later, you can easily deploy additional domain controllers via the Directory Service console by just specifying the total number of domain controllers that you want. AWS Managed Microsoft AD distributes the additional domain controllers to the Availability Zones and Amazon VPC subnets on which your directory is running. For example, in the below illustration, DC-1 and DC-2 represent the two domain controllers that were originally created with your directory. The Directory Service console refers to these default domain controllers as **Required**. AWS Managed Microsoft AD intentionally locates each of these domain controllers in separate Availability Zones during the directory creation process. Later, you might decide to add two more domain controllers to help distribute the authentication load over peak login times. Both DC-3 and DC-4 represent the new domain controllers, which the console now refers to as **Additional**. As before, AWS Managed Microsoft AD again automatically places the new domain controllers in different Availability Zones to ensure your domain's high availability. ![\[Four domain controllers spread across two availability zones.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/ms_ad_additionaldcs.png) This process eliminates the need for you to manually configure directory data replication, automated daily snapshots, or monitoring for the additional domain controllers. It's also easier for you to migrate and run mission critical Active Directory–integrated workloads in the AWS Cloud without having to deploy and maintain your own Active Directory infrastructure. You can use either of the following tools to deploy or remove additional domain controllers to your AWS Managed Microsoft AD: + [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/update-number-of-domain-controllers.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/update-number-of-domain-controllers.html) AWS CLI command + [UpdateNumberOfDomainControllers](https://docs.aws.amazon.com/directoryservice/latest/devguide/API_UpdateNumberOfDomainControllers.html) API + [Adding or removing additional domain controllers with the AWS Management Console](#addremovedcs) **Note** Additional domain controllers 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). ## Adding or removing additional domain controllers with the AWS Management Console You can use the AWS Management Console to add or remove additional domain controllers to your AWS Managed Microsoft AD. ### Prerequisites Before adding or removing additional domain controllers to your AWS Managed Microsoft AD, here's more information about domain controller requirements: + After deploying additional domain controllers, you can reduce the number of domain controllers to two, which is the minimum required for fault-tolerance and high availability purposes. + The deleted domain controllers will be delete from the list of additional domain controllers. The primary and secondary domain controllers are required and can't be deleted. + If you have configured your AWS Managed Microsoft AD to enable LDAPS, any additional domain controllers you add will also have LDAPS enabled automatically. For more information, see [Enable Secure LDAP or LDAPS](ms_ad_ldap.md). ### Procedure Use the following procedure to deploy or remove additional domain controllers in your AWS Managed Microsoft AD with the AWS Management Console, AWS CLI, or PowerShell. ------ #### [ AWS Management Console ] **To add or remove additional domain controllers with the AWS Management Console** 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, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to add or remove domain controllers, and then choose the **Scale & share** 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 **Scale & share** tab. 1. In the **Domain controllers** section, choose **Edit**. 1. Specify the number of domain controllers to add or remove from your directory, and then choose **Modify**. 1. When AWS Managed Microsoft AD completes the deployment process, all domain controllers show **Active** status, and both the assigned Availability Zone and Amazon VPC subnets appear. New domain controllers are equally distributed across the Availability Zones and subnets where your directory is already deployed. ------ #### [ AWS CLI ] **To add or remove additional domain controllers with AWS CLI** 1. Open the AWS CLI. To check the current number of domain controllers, run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` aws ds describe-directories --directory-id d-1234567890 | grep DesiredNumberOfDomainControllers ``` 1. To add or remove domain controllers, you can use the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/update-number-of-domain-controllers.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/update-number-of-domain-controllers.html) command. For example, you can use the following command to set the total number of domain controllers to 4. Ensure you replace the Directory ID with your AWS Managed Microsoft AD Directory ID and the `desired-number` parameter with the number of domain controllers you want to deploy. ``` aws ds update-number-of-domain-controllers --directory-id d-1234567890 --desired-number 4 ``` ------ #### [ PowerShell ] **To add or remove additional domain controllers with PowerShell** 1. Open PowerShell. To check the current number of domain controllers, run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` Get-DSDirectory -DirectoryId d-1234567890 | Select-Object DesiredNumberOfDomainControllers ``` 1. To add or remove domain controllers, you can use the [https://docs.aws.amazon.com//powershell/latest/reference/items/Set-DSDomainControllerCount.html](https://docs.aws.amazon.com//powershell/latest/reference/items/Set-DSDomainControllerCount.html) command. For example, you can use the following command to set the total number of domain controllers to 4. Ensure you replace the Directory ID with your AWS Managed Microsoft AD Directory ID and the `DesiredNumber` parameter with the number of domain controllers you want to deploy. ``` Set-DSDomainControllerCount -DirectoryId d-1234567890 -DesiredNumber 4 ``` ------ **Related AWS Security Blog Article** + [How to increase the redundancy and performance of your Directory Service for AWS Managed Microsoft AD by adding domain controllers](https://aws.amazon.com/blogs/security/how-to-increase-the-redundancy-and-performance-of-your-aws-directory-service-for-microsoft-ad-directory-by-adding-domain-controllers/) # Upgrading your AWS Managed Microsoft AD You can upgrade your Standard edition AWS Managed Microsoft AD to Enterprise edition. The following outlines the differences between Standard and Enterprise editions: + **Standard Edition: **AWS Managed Microsoft AD (Standard Edition) is optimized to be a primary directory for small and midsize businesses with up to 5,000 employees. It provides you enough storage capacity to support up to 30,000\$1 directory objects, such as users, groups, and computers. + **Enterprise Edition: **AWS Managed Microsoft AD (Enterprise Edition) is designed to support enterprise organizations with up to 500,000\$1 directory objects. \$1 Upper limits are approximations. Your directory may support more or less directory objects depending on the size of your objects and the behavior and performance needs of your applications. To upgrade your Standard edition AWS Managed Microsoft AD to Enterprise edition, use [UpdateDirectorySetup](https://docs.aws.amazon.com/directoryservice/latest/devguide/API_UpdateDirectorySetup.html) from the API, [update-directory-setup](https://docs.aws.amazon.com/cli/latest/reference/ds/update-directory-setup.html) from the AWS CLI, or [Update-DSDirectorySetup](https://docs.aws.amazon.com/powershell/v5/reference/?page=Update-DSDirectorySetup.html) from AWS Tools for PowerShell. ------ #### [ API ] To upgrade your Standard edition AWS Managed Microsoft AD to Enterprise edition: ``` { "DirectoryId": "d-1234567890", "UpdateType": "SIZE", "DirectorySizeUpdateSettings": { "DirectorySize": "Large" } } ``` ------ #### [ AWS CLI ] To upgrade your Standard edition AWS Managed Microsoft AD to Enterprise edition: ``` aws ds update-directory-setup \ --directory-id d-1234567890 \ --update-type SIZE \ --directory-size-update-settings DirectorySize=Large ``` ------ #### [ PowerShell ] To upgrade your Standard edition AWS Managed Microsoft AD to Enterprise edition: ``` Update-DSDirectorySetup ` -DirectoryId d-9a676e4148 ` -UpdateType SIZE ` -DirectorySizeUpdateSettings_DirectorySize Large ``` ------ There are a few limitations to be aware of when upgrading your AWS Managed Microsoft AD. They are: + The upgrade will incur additional cost. See [Directory Service Pricing](https://aws.amazon.com/directoryservice/pricing/) for more information. + Once your Active Directory is upgraded, it can't be reverted back to its previous edition. + Previous snapshots can't be used to restore the Active Directory after it has been upgraded. + The upgrade process requires four to five hours. + During the upgrade process, the domain controllers of your AWS Managed Microsoft AD are upgraded one at a time. This can negatively impact your performance and can cause downtime during your maintenance window. + The upgrade process will change the hostname of each domain controller instance, but their IP addresses will remain the same. + If you are using LDAPS (Lightweight Directory Access Protocol over SSL), the domain controllers will need new certificates. # Updating directory network type 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 Before updating your directory network type, ensure the following requirements are met: + Your VPC and the associated subnets in which your directory currently exists 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 **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**. # Adding alternate UPN suffixes to your AWS Managed Microsoft AD Adding alternate UPN suffixes You can simplify the management of Active Directory (AD) login names and improve the user login experience by adding alternate user principal name (UPN) suffixes to your AWS Managed Microsoft AD directory. To do that, you must be logged on with the **Admin** account or with an account that is a member of the **AWS Delegated User Principal Name Suffix Administrators** group. For more information about this group, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). **To add alternate UPN suffixes** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Locate an Amazon EC2 instance that is joined to your AWS Managed Microsoft AD directory. Select the instance and then choose **Connect**. 1. In the **Server Manager** window, choose **Tools**. Then choose **Active Directory Domains and Trusts**. 1. In the left pane, right-click **Active Directory Domains and Trusts** and then choose **Properties** . 1. In the **UPN Suffixes** tab, type an alternative UPN suffix (such as **sales.example.com**). Choose **Add** and then choose **Apply**. 1. If you need to add additional alternative UPN suffixes, repeat step 5 until you have the UPN suffixes you require. # Renaming your AWS Managed Microsoft AD directory's site name Renaming your directory's site name You can rename your AWS Managed Microsoft AD directory's default site name so that it matches with your existing Microsoft Active Directory (AD) site names. This makes it faster for AWS Managed Microsoft AD to find and authenticate your existing AD users in your on-premises directory. The result is a better experience when users login to AWS resources such as [Amazon EC2](https://aws.amazon.com/ec2/) and [Amazon RDS for SQL Server](https://aws.amazon.com/rds/sqlserver/) instances that you have joined to your AWS Managed Microsoft AD directory. To do that, you must be logged in with the **Admin** account or with an account that is a member of the **AWS Delegated Sites and Services Administrators** group. For more information about this group, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). For additional benefits on renaming your site in relation to trusts, see [Domain Locator Across a Forest Trust](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689) on Microsoft's website. **To rename the AWS Managed Microsoft AD site name** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Locate an Amazon EC2 instance that is joined to your AWS Managed Microsoft AD directory. Select the instance and then choose **Connect**. 1. In the **Server Manager** window, choose **Tools**. Then choose **Active Directory Sites and Services**. 1. In the left pane, expand the **Sites** folder, right-click the site name (default is **Default-Site-Name**), and then choose **Rename**. 1. Type the new site name, and then choose **Enter**. # Deleting your AWS Managed Microsoft AD When a AWS Managed Microsoft AD, Simple AD, or hybrid directory is deleted, all of the directory data and snapshots are deleted and cannot be recovered. After the directory is deleted, all instances that are joined to the directory remain intact. You cannot, however, use your directory credentials to log in to these instances. You need to log in to these instances with a user account that is local to the instance. 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 a directory** 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 Active Directory 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 directory you intend to delete. Enabled AWS applications will prevent you for deleting your AWS Managed Microsoft AD or Simple AD. 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 directory. + 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 directory to be deleted and click **Delete**. It takes several minutes for the directory to be deleted. When the directory has been deleted, it is removed from your directory list. # Secure your AWS Managed Microsoft AD Secure your directory 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 Understanding 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 Assigning password policies to your 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 Delegating who can manage your 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 Enabling multi-factor authentication 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 Enable MFA 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 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 Enabling server-side LDAPS 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 Enabling client-side LDAPS 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 Manage compliance for your directory 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 Enhancing network security 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 Editing 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 Enable Public Key Cryptography for Initial Authentication (PKINIT) 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 Set up AWS Private CA Connector for 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 ``` # Monitor your AWS Managed Microsoft AD Monitor your directory You can get the most out of your AWS Managed Microsoft AD by learning more about the different AWS Managed Microsoft AD statuses and what they mean for your AWS Managed Microsoft AD. You can also use AWS services like Amazon Simple Notification Service and Amazon CloudWatch to monitor your AWS Managed Microsoft AD. Amazon Simple Notification Service can send you notifications of your AWS Managed Microsoft AD directory status. Amazon CloudWatch can monitor the performance of your AWS Managed Microsoft AD domain controllers. **Topics** + [ # Understanding your AWS Managed Microsoft AD directory status ](ms_ad_directory_status.md) + [ # Enabling AWS Managed Microsoft AD directory status notifications with Amazon Simple Notification Service ](ms_ad_enable_notifications.md) + [ # Understanding your AWS Managed Microsoft AD directory logs ](ms_ad_directory_logs.md) + [ # Enabling Amazon CloudWatch Logs log forwarding for AWS Managed Microsoft AD ](ms_ad_enable_log_forwarding.md) + [ # Using CloudWatch to monitor the performance of your AWS Managed Microsoft AD domain controllers ](ms_ad_monitor_dc_performance.md) + [ # Disabling Amazon CloudWatch log forwarding for AWS Managed Microsoft AD ](ms_ad_disable_log_forwarding_with_console.md) + [ # Monitoring DNS Server with Microsoft Event Viewer ](ms_ad_dns_event_viewer.md) # Understanding your AWS Managed Microsoft AD directory status Understanding your directory status 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). **Requested** A request to create your directory is currently pending. **RestoreFailed** Restoring the directory from a snapshot failed. Please retry the restore operation. If this continues, try a different snapshot, or contact the [AWS Support Center](https://console.aws.amazon.com/support/home#/). **Restoring** The directory is currently being restored from an automatic or manual snapshot. Restoring from a snapshot typically takes several minutes, depending on the size of the directory data in the snapshot. # Enabling AWS Managed Microsoft AD directory status notifications with Amazon Simple Notification Service Enabling directory status notifications with Amazon SNS 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 status](ms_ad_directory_status.md). You also receive a notification when the directory returns to an Active status. ## How It Works 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). **Note** Directory status notifications 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). ## Enabling Amazon SNS The following walks you through how you can enable Amazon SNS for your AWS Managed Microsoft AD: 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. 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 SNS messaging, and then choose the **Maintenance** 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 **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 would like to further customize your topic name you will 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.). ## Removing directory status messages from an Amazon SNS topic The following walks you through how you can remove your AWS Managed Microsoft AD directory status messages from an Amazon SNS 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. 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 remove status messages, and then choose the **Maintenance** 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 **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. ## Deleting an Amazon 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.). 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. For more information on how to delete an Amazon SNS topic, see [Deleting an Amazon SNS topic and subscription](https://docs.aws.amazon.com/sns/latest/dg/sns-delete-subscription-topic.html). # Understanding your AWS Managed Microsoft AD directory logs Understanding your directory logs Security logs from AWS Managed Microsoft AD domain controller instances are archived for a year. You can also configure your AWS Managed Microsoft AD directory to forward domain controller logs to Amazon CloudWatch Logs in near real time. For more information, see [Enabling Amazon CloudWatch Logs log forwarding for AWS Managed Microsoft AD](ms_ad_enable_log_forwarding.md). AWS logs the following events for compliance. **** | Monitoring category | Policy setting | Audit state | | --- | --- | --- | | Account Logon | Audit Credential Validation | Success, Failure | | | Audit Other Account Logon Events | Success, Failure | | | Audit Kerberos Authentication Service | Success, Failure | | Account Management | Audit Computer Account Management | Success, Failure | | | Audit Other Account Management Events | Success, Failure | | | Audit Security Group Management | Success, Failure | | | Audit User Account Management | Success, Failure | | Detailed Tracking | Audit DPAPI Activity | Success, Failure | | | Audit PNP Activity | Success | | | Audit Process Creation | Success, Failure | | DS Access | Audit Directory Service Access | Success, Failure | | | Audit Directory Service Changes | Success, Failure | | Logon/Logoff | Audit Account Lockout | Success, Failure | | | Audit Logoff | Success | | | Audit Logon | Success, Failure | | | Audit Other Logon/Logoff Events | Success, Failure | | | Audit Special Logon | Success, Failure | | Object Access | Audit Other Object Access Events | Success, Failure | | | Audit Removable Storage | Success, Failure | | | Audit Central Access Policy Staging | Success, Failure | | Policy Change | Audit Policy Change | Success, Failure | | | Audit Authentication Policy Change | Success, Failure | | | Audit Authorization Policy Change | Success, Failure | | | Audit MPSSVC Rule-Level Policy Change | Success | | | Audit Other Policy Change Events | Failure | | Privilege Use | Audit Sensitive Privilege Use | Success, Failure | | System | Audit IPsec Driver | Success, Failure | | | Audit Other System Events | Success, Failure | | | Audit Security State Change | Success, Failure | | | Audit Security System Extension | Success, Failure | | | Audit System Integrity | Success, Failure | # Enabling Amazon CloudWatch Logs log forwarding for AWS Managed Microsoft AD Enabling Amazon CloudWatch log forwarding You can use either the Directory Service console or APIs to forward domain controller security event logs to Amazon CloudWatch Logs for your AWS Managed Microsoft AD. This helps you to meet your security monitoring, audit, and log retention policy requirements by providing transparency of the security events in your directory. CloudWatch Logs can also forward these events to other AWS accounts, AWS services, or third party applications. This makes it easier for you to centrally monitor and configure alerts to detect and respond proactively to unusual activities in near real time. Once enabled, you can then use the CloudWatch Logs console to retrieve the data from the log group you specified when you enabled the service. This log group contains the security logs from your domain controllers. For more information about log groups and how to read their data, see [Working with log groups and log streams](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html) in the *Amazon CloudWatch Logs User Guide*. **Note** Log forwarding 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). Once enabled, the log forwarding capability will begin transmitting logs from your domain controllers to the specified CloudWatch log group. Any logs created before log forwarding is enabled will not be transferred to the CloudWatch log group. **Topics** + [ ## Using the AWS Management Console to enable Amazon CloudWatch Logs log forwarding ](#enable_log_forwarding_with_console) + [ ## Using the CLI or PowerShell to enable Amazon CloudWatch Logs log forwarding ](#enable_log_forwarding_with_cli) ## Using the AWS Management Console to enable Amazon CloudWatch Logs log forwarding Using the console to enable log forwarding You can enable Amazon CloudWatch Logs log forwarding for your AWS Managed Microsoft AD in the AWS Management Console. 1. In the [Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, choose **Directories**. 1. Choose the directory ID of the AWS Managed Microsoft AD directory that you want to share. 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 log forwarding, 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 **Log forwarding** section, choose **Enable**. 1. On the **Enable log forwarding to CloudWatch** dialog, choose either of the following options: 1. Select **Create a new CloudWatch log group**, under **CloudWatch Log group name**, specify a name that you can refer to in CloudWatch Logs. 1. Select **Choose an existing CloudWatch log group**, and under **Existing CloudWatch log groups**, select a log group from the menu. 1. Review the pricing information and link, and then choose **Enable**. ## Using the CLI or PowerShell to enable Amazon CloudWatch Logs log forwarding Using CLI or PowerShell to enable log forwarding Before you can use the [https://docs.aws.amazon.com/cli/latest/reference/ds/create-log-subscription.html](https://docs.aws.amazon.com/cli/latest/reference/ds/create-log-subscription.html) command, you must first create an Amazon CloudWatch log group and then create an IAM resource policy that will grant the necessary permission to that group. To enable log forwarding using the CLI or PowerShell, complete the following steps. ### Step 1: Create a log group in CloudWatch Logs Create a log group that will be used to receive the security logs from your domain controllers. We recommend pre-pending the name with `/aws/directoryservice/`, but that is not required. For example: ------ #### [ CLI Command ] ``` aws logs create-log-group --log-group-name '/aws/directoryservice/d-1111111111' ``` ------ #### [ PowerShell Command ] ``` New-CWLLogGroup -LogGroupName '/aws/directoryservice/d-1111111111' ``` ------ For instructions on how to create a CloudWatch Logs group, see [Create a log group in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#Create-Log-Group) in the *Amazon CloudWatch Logs User Guide*. ### Step 2: Create a CloudWatch Logs resource policy in IAM Create a CloudWatch Logs resource policy granting Directory Service rights to add logs into the new log group you created in Step 1. You can either specify the exact ARN to the log group to limit Directory Service's access to other log groups or use a wild card to include all log groups. The following sample policy uses the wild card method to identify that all log groups that start with `/aws/directoryservice/` for the AWS account where your directory resides will be included. You will need to save this policy to a text file (for example DSPolicy.json) on your local workstation as you will need to run it from the CLI. For example: ------ #### [ CLI Command ] ``` aws logs put-resource-policy --policy-name DSLogSubscription --policy-document file://DSPolicy.json ``` ------ #### [ PowerShell Command ] ``` $PolicyDocument = Get-Content .\DSPolicy.json –Raw ``` ``` Write-CWLResourcePolicy -PolicyName DSLogSubscription -PolicyDocument $PolicyDocument ``` ------ ### Step 3: Create an Directory Service log subscription In this final step, you can now proceed to enable log forwarding by creating the log subscription. For example: ------ #### [ CLI Command ] ``` aws ds create-log-subscription --directory-id 'd-1111111111' --log-group-name '/aws/directoryservice/d-1111111111' ``` ------ #### [ PowerShell Command ] ``` New-DSLogSubscription -DirectoryId 'd-1111111111' -LogGroupName '/aws/directoryservice/d-1111111111' ``` ------ # Using CloudWatch to monitor the performance of your AWS Managed Microsoft AD domain controllers Using CloudWatch to monitor your directory Directory Service integrates with Amazon CloudWatch to help provide you with important performance metrics for each domain controller in your Active Directory. This means that you can monitor domain controller performance counters, such as CPU and memory utilization. You can also configure alarms and initiate automated actions to respond to periods of high utilization. For example, you can configure an alarm for domain controller CPU utilization above 70 percent and create an SNS topic to notify you when this occurs. You can use this SNS topic to initiate automation, such as AWS Lambda functions, to increase the number of domain controllers to your Active Directory. For more information about monitoring your domain controllers, see [Determining when to add domain controllers with CloudWatch metrics](#scaledcs). There are fees associated with Amazon CloudWatch. For more information, see [CloudWatch billing and cost](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_billing.html). **Important** Domain controller performance metrics with CloudWatch is unavailable in the Canada West (Calgary) Region. To enable CloudWatch, see [Enabling Amazon CloudWatch Logs log forwarding for AWS Managed Microsoft AD](ms_ad_enable_log_forwarding.md). ## Finding domain controllers performance metrics in CloudWatch In the Amazon CloudWatch console, metrics for a given service are grouped first by the service's namespace. You can add metric filters that are subordinate to that namespace. Use the following procedure to locate the correct namespace and subordinate metric that is required to set up AWS Managed Microsoft AD domain controller metrics in CloudWatch. **To find domain controller metrics in the CloudWatch console** 1. Sign in to the AWS Management Console and open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. In the navigation pane, choose **Metrics**. 1. From the list of metrics, select the **Directory Service** namespace, and then from the list, select the **AWS Managed Microsoft AD** metric. For instructions on how to set up domain controller metrics using the CloudWatch console, see [How to automate AWS Managed Microsoft AD scaling based on utilization metrics](https://aws.amazon.com/blogs/security/how-to-automate-aws-managed-microsoft-ad-scaling-based-on-utilization-metrics/) in the AWS Security Blog. ## Determining when to add domain controllers with CloudWatch metrics Load balancing across all of your domain controllers is important for the resilience and performance of your Active Directory. To help you optimize the performance of your domain controllers in AWS Managed Microsoft AD, we recommend that you first monitor important metrics in CloudWatch to form a baseline. During this process, you analyze your Active Directory over time to identify your average and peak Active Directory utilization. After determining your baseline, you can monitor these metrics on a regular basis to help determine when to add a domain controller to your Active Directory. The following metrics are important to monitor on a regular basis. For a full list of available domain controller metrics in CloudWatch, see [AWS Managed Microsoft AD performance counters](#performance-counters). + Domain controller-specific metrics, such as: + Processor + Memory + Logical Disk + Network Interface + AWS Managed Microsoft AD directory-specific metrics, such as: + LDAP searches + Binds + DNS queries + Directory reads + Directory writes For instructions on how to set up domain controller metrics using the CloudWatch console, see [How to automate AWS Managed Microsoft AD scaling based on utilization metrics](https://aws.amazon.com/blogs/security/how-to-automate-aws-managed-microsoft-ad-scaling-based-on-utilization-metrics/) in the AWS Security Blog. For general information about metrics in CloudWatch, see [Using Amazon CloudWatch metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) in the *Amazon CloudWatch User Guide*. For general information about domain controller planning, see [Capacity planning for Active Directory Domain Services](https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services) on the Microsoft website. ## AWS Managed Microsoft AD performance counters The following table lists all performance counters available in Amazon CloudWatch for tracking domain controller and directory performance in AWS Managed Microsoft AD. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_monitor_dc_performance.html) # Disabling Amazon CloudWatch log forwarding for AWS Managed Microsoft AD Disabling Amazon CloudWatch log forwarding You can disable CloudWatch Logs log forwarding for your AWS Managed Microsoft AD in the AWS Management Console. For more information on log forwarding, see [Using CloudWatch to monitor the performance of your AWS Managed Microsoft AD domain controllers](ms_ad_monitor_dc_performance.md). 1. In the [Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, choose **Directories**. 1. Choose the directory ID of the AWS Managed Microsoft AD directory that you want to share. 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 log forwarding, 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 **Log forwarding** section, choose **Disable**. 1. Once you've read the information in the **Disable log forwarding** dialog, choose **Disable**. # Monitoring DNS Server with Microsoft Event Viewer You can audit your AWS Managed Microsoft AD DNS events, making it easier to identify and troubleshoot DNS issues. For example, if a DNS record is missing, you can use the DNS audit event log to help identify the root cause and fix the issue. You can also use DNS audit event logs to improve security by detecting and blocking requests from suspicious IP addresses. To do that, you must be logged on with the **Admin** account or with an account that is a member of the **AWS Domain Name System Administrators** group. For more information about this group, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). **To access Event Viewer for your AWS Managed Microsoft AD DNS** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the left navigation pane, choose **Instances**. 1. Locate an Amazon EC2 instance that is joined to your AWS Managed Microsoft AD directory. Select the instance and then choose **Connect**. 1. Once connected to the Amazon EC2 instance, open the **Start **menu and select the ** Windows Administrative Tools** folder. Within the **Administrative Tools** folder, select **Event Viewer**. 1. In the **Event Viewer** window, choose **Action ** and then choose **Connect to Another Computer**. 1. Select **Another computer**, type one of your AWS Managed Microsoft AD DNS servers name or IP address, and choose **OK**. 1. In the left pane, navigate to **Applications and Services Logs**>**Microsoft**>**Windows**>**DNS-Server**, and then select **Audit**. # Access to AWS applications and services from your AWS Managed Microsoft AD Access to AWS applications and services You can grant access to your AWS Managed Microsoft AD users to access AWS applications and services. Some of these AWS applications and services include: + Amazon Chime + Amazon EC2 + Quick + AWS Management Console + Amazon WorkSpaces You can also use access URLs and single sign-on with your AWS Managed Microsoft AD. **Topics** + [ # Application compatibility for AWS Managed Microsoft AD ](ms_ad_app_compatibility.md) + [ # Enabling access to AWS applications and services for your AWS Managed Microsoft AD ](ms_ad_enable_apps_services.md) + [ # Enabling AWS Management Console access with AWS Managed Microsoft AD credentials ](ms_ad_management_console_access.md) + [ # Creating an access URL for AWS Managed Microsoft AD ](ms_ad_create_access_url.md) + [ # Enabling single sign-on for AWS Managed Microsoft AD ](ms_ad_single_sign_on.md) # Application compatibility for AWS Managed Microsoft AD Application compatibility AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) is compatible with multiple AWS services and third-party applications. The following is a list of compatible AWS applications and services: + Amazon Chime + Amazon Connect + Amazon EC2 + Quick + Amazon RDS + WorkDocs + Amazon WorkMail + AWS Client VPN + AWS IAM Identity Center + AWS License Manager + AWS Management Console + FSx for Windows File Server + WorkSpaces For more information, see [Enabling access to AWS applications and services for your AWS Managed Microsoft AD](ms_ad_enable_apps_services.md). Due to the magnitude of custom and commercial off-the-shelf applications that use Active Directory, AWS does not and cannot perform formal or broad verification of third-party application compatibility with AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD). Although AWS works with customers in an attempt to overcome any potential application installation challenges they might encounter, we are unable to guarantee that any application is or will continue to be compatible with AWS Managed Microsoft AD. The following third-party applications are compatible with AWS Managed Microsoft AD: + Active Directory-Based Activation (ADBA) + Active Directory Certificate Services (AD CS): Enterprise Certificate Authority + Active Directory Federation Services (AD FS) + Active Directory Users and Computers (ADUC) + Application Server (.NET) + Microsoft Entra (formerly known as Azure Active Directory (Azure AD)) + Microsoft Entra Connect (formerly known as Azure Active Directory Connect) + Distributed File System Replication (DFSR) + Distributed File System Namespaces (DFSN) + Microsoft Remote Desktop Services Licensing Server + Microsoft SharePoint Server + Microsoft SQL Server (including SQL Server Always On Availability Groups) + Microsoft System Center Configuration Manager (SCCM) - The user deploying SCCM must be a member of the AWS Delegated System Management Administrators group. + Microsoft Windows and Windows Server OS + Office 365 Note that not all configurations of these applications may be supported. ## Compatibility guidelines Although applications may have configurations that are incompatible, application deployment configurations can often overcome incompatibility. The following describes the most common reasons for application incompatibility. Customers can use this information to investigate compatibility characteristics of a desired application and identify potential deployment changes. + **Domain administrator or other privileged permissions –** Some applications state that you must install them as the domain administrator. Because AWS must retain exclusive control of this permission level in order to deliver Active Directory as a managed service, you cannot act as the domain administrator to install such applications. However, you can often install such applications by delegating specific, less privileged, and AWS supported permissions to the person who performs the installation. For more details on the precise permissions that your application requires, ask your application provider. For more information about permissions that AWS allows you to delegate, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). + **Access to privileged Active Directory containers –** Within your directory, AWS Managed Microsoft AD provides an Organizational Unit (OU) over which you have full administrative control. You do not have create or write permissions and may have limited read permissions to containers that are higher in the Active Directory tree than your OU. Applications that create or access containers for which you have no permissions might not work. However, such applications often have an ability to use a container that you create in your OU as an alternative. Check with your application provider to find ways to create and use a container in your OU as an alternative. For more information on your OU, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). + **Schema changes during the install workflow –** Some Active Directory applications require changes to the default Active Directory schema, and they may attempt to install those changes as part of the application installation workflow. Due to the privileged nature of schema extensions, AWS makes this possible by importing Lightweight Directory Interchange Format (LDIF) files through the Directory Service console, CLI, or SDK only. Such applications often come with an LDIF file that you can apply to the directory through the Directory Service schema update process. For more information about how the LDIF import process works, see [Tutorial: Extending your AWS Managed Microsoft AD schema](ms_ad_tutorial_extend_schema.md). You can install the application in a way to bypass the schema installation during the installation process. ## Known incompatible applications The following lists commonly requested commercial off-the-shelf applications for which we have not found a configuration that works with AWS Managed Microsoft AD. AWS updates this list from time to time at its sole discretion as a courtesy to help you avoid unproductive efforts. AWS provide this information without warranty or claims regarding current or future compatibility. + Active Directory Certificate Services (AD CS): Certificate Enrollment Web Service + Active Directory Certificate Services (AD CS): Certificate Enrollment Policy Web Service + Microsoft Exchange Server + Microsoft Skype for Business Server # Enabling access to AWS applications and services for your AWS Managed Microsoft AD Enabling access to AWS applications and services Users can authorize AWS Managed Microsoft AD 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 AWS Managed Microsoft AD. | 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/related-services-amazon-connect.html#security-services). | | Amazon EC2 | For more information, see [Ways to join an Amazon EC2 instance to your AWS Managed Microsoft AD](ms_ad_join_instance.md). | | Amazon FSx for Windows File Server | For more information, see [Using Amazon FSx with AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/fsx-aws-managed-ad.html). | | Quick | For more information, see the [Using Active Directory with Quick Enterprise edition](https://docs.aws.amazon.com/quicksight/latest/user/aws-directory-service.html). | | Amazon Relational Database Service | For more information, see the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_enable_apps_services.html) | | Amazon WorkDocs | For more information, see the [Enable Amazon WorkDocs for AWS Managed Microsoft AD](https://docs.aws.amazon.com/workspaces/latest/adminguide/enable-workdocs-active-directory.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 [Register an existing Directory Service directory with WorkSpaces Personal](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html). | | AWS Client VPN | For more information, see the [Active Directory authentication in Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/ad.html). | | AWS IAM Identity Center | For more information, see the [Connect to a Microsoft AD directory](https://docs.aws.amazon.com/singlesignon/latest/userguide/connectawsad.html). | | AWS License Manager | For more information, see the [Manage user-based subscriptions in License Manager](https://docs.aws.amazon.com/license-manager/latest/userguide/user-based-subscriptions.html). | | 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 Private Certificate Authority | For more information, see [AWS Private CA Connector for Active Directory](https://docs.aws.amazon.com/privateca/latest/userguide/connector-for-ad.html). | | AWS Transfer Family | For more information, see the [Configuring an SFTP, FTPS, or FTP server endpoint](https://docs.aws.amazon.com/transfer/latest/userguide/sftp-for-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. ## Find AWS applications and services To find the AWS applications and services previously described in the Directory Service console, perform the following steps. 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). # Enabling AWS Management Console access with AWS Managed Microsoft AD credentials Enabling access to the AWS Management Console Directory Service allows you to grant members of your directory access to the AWS Management Console. By default, your directory members do not have access to any AWS resources. You assign IAM roles to your directory members to give them access to the various AWS services and resources. The IAM role defines the services, resources, and level of access that your directory members have. Before you can grant console access to your directory members, your directory must have an access URL. For more information about how to view directory details and get your access URL, see [Viewing AWS Managed Microsoft AD directory information](ms_ad_view_directory_info.md). For more information about how to create an access URL, see [Creating an access URL for AWS Managed Microsoft AD](ms_ad_create_access_url.md). For more information about how to create and assign IAM roles to your directory members, see [Granting AWS Managed Microsoft AD users and groups access to AWS resources with IAM roles](ms_ad_manage_roles.md). **Topics** + [ ## Enabling AWS Management Console access ](#console_enable) + [ ## Disabling AWS Management Console access ](#console_disable) + [ ## Setting AWS Management Console login session length ](#console_session) **Related AWS Security Blog Article** + [How to Access the AWS Management Console Using AWS Managed Microsoft AD and Your On-Premises Credentials](https://aws.amazon.com/blogs/security/how-to-access-the-aws-management-console-using-aws-microsoft-ad-and-your-on-premises-credentials/) **Related AWS re:Post Article** + [How can I grant access to the AWS Management Console for an on-premises Active Directory users?](https://repost.aws/knowledge-center/enable-active-directory-console-access) **Note** Access to the AWS Management Console 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). ## Enabling AWS Management Console access By default, console access is not enabled for any directory. To enable console access for your directory users and groups, perform the following steps: **To enable console access** 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, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to enable access to the AWS Management Console, and then choose the **Application management** 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 **Application management** tab. 1. Under the **AWS Management Console** section, choose **Enable**. Console access is now enabled for your directory. **Important** Before users can sign-in to the console with your access URL, you must first add your users to the IAM role. For general information about assigning users to IAM roles, see [Assigning users or groups to an existing IAM role](assign_role.md). After the IAM roles have been assigned, users can then access the console using your access URL. For example, if your directory access URL is `example-corp.awsapps.com`, the URL to access the console is `https://example-corp.awsapps.com/console/`. ## Disabling AWS Management Console access To disable AWS Management Console access for your AWS Managed Microsoft AD directory users and groups, perform the following steps: **To disable console access** 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, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to disable access to the AWS Management Console, and then choose the **Application management** 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 **Application management** tab. 1. Under the **AWS Management Console** section, choose **Disable**. Console access is now disabled for your directory. 1. If any IAM roles have been assigned to users or groups in the directory, the **Disable** button may be unavailable. In this case, you must remove all IAM role assignments for the directory before proceeding, including assignments for users or groups in your directory that have been deleted, which will show as **Deleted User** or **Deleted Group**. After all IAM role assignments have been removed, repeat the steps above. ## Setting AWS Management Console login session length Setting login session length By default, users have 1 hour to use their session after successfully signing in to the AWS Management Console before they are logged out. After that, users must sign in again to start the next 1 hour session before being logged off again. You can use the following procedure to change the length of time to up to 12 hours per session. **To set AWS Management Console login session length** 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, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to set the login session length, and then choose the **Application management** 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 **Application management** tab. 1. Under the **AWS apps & services** section, choose **AWS Management Console**. 1. In the **Manage Access to AWS Resource** dialog box, choose **Continue**. 1. In the **Assign users and groups to IAM roles** page, under **Set login session length**, edit the numbered value, and then choose **Save**. # Creating an access URL for AWS Managed Microsoft AD Creating an access URL An access URL is used with AWS applications and services, such as Amazon WorkDocs, to reach a login page that is associated with your directory. You can create an access URL for your directory by performing the following steps. **Considerations** + The URL must be unique globally. + The access URL can only be configured from the Primary Region when using Multi-Region directories. + Once you create an application access URL for this directory, it cannot be changed. After an access URL is created, it cannot be used by others. If you delete your directory, the access URL is also deleted and can then be used by any other account. **To create an access URL** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**. 1. On the **Directories** page, choose your directory ID. 1. On the **Directory details** page, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the Primary Region and then choose the **Application management** 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 **Application management** tab. 1. In the **Application access URL** section, if an access URL has not been assigned to the directory, the **Create** button is displayed. Enter a directory alias and choose **Create**. If an **Entity Already Exists** error is returned, the specified directory alias has already been allocated. Choose another alias and repeat this procedure. Your access URL is displayed in the format **.awsapps.com. By default, this URL will take you to the sign-in page for WorkDocs. # Enabling single sign-on for AWS Managed Microsoft AD Enabling single sign-on AWS Directory Service provides the ability to allow your users to access WorkDocs from a computer joined to the directory without having to enter their credentials separately. Before you enable single sign-on, you need to take additional steps to enable your users web browsers to support single sign-on. Users may need to modify their web browser settings to enable single sign-on. **Note** Single sign-on only works when used on a computer that is joined to the Directory Service directory. It cannot be used on computers that are not joined to the directory. If your directory is an AD Connector directory and the AD Connector service account does not have the permission to add or remove its service principal name attribute, then for Steps 5 and 6 below, you have two options: 1. You can proceed and will be prompted for the username and password for a directory user that has this permission to add or remove the service principal name attribute on the AD Connector service account. These credentials are only used to enable single sign-on and are not stored by the service. The AD Connector service account permissions are not changed. 1. You can delegate permissions to allow the AD Connector service account to add or remove the service principal name attribute on itself, you can run the below PowerShell commands from a domain joined computer using an account that has permissions to modify the permissions on the AD Connector service account. The below command will give the AD Connector service account the ability to add and remove a service principal name attribute only for itself. ``` $AccountName = 'ConnectorAccountName' # DO NOT modify anything below this comment. # Getting Active Directory information. Import-Module 'ActiveDirectory' $RootDse = Get-ADRootDSE [System.GUID]$ServicePrincipalNameGuid = (Get-ADObject -SearchBase $RootDse.SchemaNamingContext -Filter { lDAPDisplayName -eq 'servicePrincipalName' } -Properties 'schemaIDGUID').schemaIDGUID # Getting AD Connector service account Information. $AccountProperties = Get-ADUser -Identity $AccountName $AclPath = $AccountProperties.DistinguishedName $AccountSid = New-Object -TypeName 'System.Security.Principal.SecurityIdentifier' $AccountProperties.SID.Value # Getting ACL settings for AD Connector service account. $ObjectAcl = Get-ACL -Path "AD:\$AclPath" # Setting ACL allowing the AD Connector service account the ability to add and remove a Service Principal Name (SPN) to itself $AddAccessRule = New-Object -TypeName 'System.DirectoryServices.ActiveDirectoryAccessRule' $AccountSid, 'WriteProperty', 'Allow', $ServicePrincipalNameGUID, 'None' $ObjectAcl.AddAccessRule($AddAccessRule) Set-ACL -AclObject $ObjectAcl -Path "AD:\$AclPath" ``` **To enable or disable single sign-on with WorkDocs** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**. 1. On the **Directories** page, choose your directory ID. 1. On the **Directory details** page, select the **Application management** tab. 1. In the **Application access URL** section, choose **Enable** to enable single sign-on for WorkDocs. If you do not see the **Enable** button, you may need to first create an Access URL before this option will be displayed. For more information about how to create an access URL, see [Creating an access URL for AWS Managed Microsoft AD](ms_ad_create_access_url.md). 1. In the **Enable Single Sign-On for this directory** dialog box, choose **Enable**. Single sign-on is enabled for the directory. 1. If you later want to disable single sign-on with WorkDocs, choose **Disable**, and then in the **Disable Single Sign-On for this directory** dialog box, choose **Disable** again. **Topics** + [ ## Single sign-on for IE and Chrome ](#ie_sso) + [ ## Single sign-on for Firefox ](#firefox_sso) ## Single sign-on for IE and Chrome IE/Chrome To allow Microsoft Internet Explorer (IE) and Google Chrome browsers to support single sign-on, the following tasks must be performed on the client computer: + Add your access URL (e.g., https://**.awsapps.com) to the list of approved sites for single sign-on. + Enable active scripting (JavaScript). + Allow automatic logon. + Enable integrated authentication. You or your users can perform these tasks manually, or you can change these settings using Group Policy settings. **Topics** + [ ### Manual update for single sign-on on Windows ](#ie_sso_manual_windows) + [ ### Manual update for single sign-on on OS X ](#chrome_sso_manual_mac) + [ ### Group policy settings for single sign-on ](#ie_sso_gpo) ### Manual update for single sign-on on Windows To manually enable single sign-on on a Windows computer, perform the following steps on the client computer. Some of these settings may already be set correctly. **To manually enable single sign-on for Internet Explorer and Chrome on Windows** 1. To open the **Internet Properties** dialog box, choose the **Start** menu, type `Internet Options` in the search box, and choose **Internet Options**. 1. Add your access URL to the list of approved sites for single sign-on by performing the following steps: 1. In the **Internet Properties** dialog box, select the **Security** tab. 1. Select **Local intranet** and choose **Sites**. 1. In the **Local intranet** dialog box, choose **Advanced**. 1. Add your access URL to the list of websites and choose **Close**. 1. In the **Local intranet** dialog box, choose **OK**. 1. To enable active scripting, perform the following steps: 1. In the **Security** tab of the **Internet Properties** dialog box, choose **Custom level**. 1. In the **Security Settings - Local Intranet Zone** dialog box, scroll down to **Scripting** and select **Enable** under **Active scripting**. 1. In the **Security Settings - Local Intranet Zone** dialog box, choose **OK**. 1. To enable automatic logon, perform the following steps: 1. In the **Security** tab of the **Internet Properties** dialog box, choose **Custom level**. 1. In the **Security Settings - Local Intranet Zone** dialog box, scroll down to **User Authentication** and select **Automatic logon only in Intranet zone** under **Logon**. 1. In the **Security Settings - Local Intranet Zone** dialog box, choose **OK**. 1. In the **Security Settings - Local Intranet Zone** dialog box, choose **OK**. 1. To enable integrated authentication, perform the following steps: 1. In the **Internet Properties** dialog box, select the **Advanced** tab. 1. Scroll down to **Security** and select **Enable Integrated Windows Authentication**. 1. In the **Internet Properties** dialog box, choose **OK**. 1. Close and re-open your browser to have these changes take effect. ### Manual update for single sign-on on OS X To manually enable single sign-on for Chrome on OS X, perform the following steps on the client computer. You will need administrator rights on your computer to complete these steps. **To manually enable single sign-on for Chrome on OS X** 1. Add your access URL to the [AuthServerAllowlist](https://chromeenterprise.google/policies/#AuthServerAllowlist) policy by running the following command: ``` defaults write com.google.Chrome AuthServerAllowlist "https://.awsapps.com" ``` 1. Open **System Preferences**, go to the **Profiles** panel, and delete the `Chrome Kerberos Configuration` profile. 1. Restart Chrome and open chrome://policy in Chrome to confirm that the new settings are in place. ### Group policy settings for single sign-on The domain administrator can implement Group Policy settings to make the single sign-on changes on client computers that are joined to the domain. **Note** If you manage the Chrome web browsers on the computers in your domain with Chrome policies, you must add your access URL to the [AuthServerAllowlist](https://chromeenterprise.google/policies/#AuthServerAllowlist) policy. For more information about setting Chrome policies, go to [Policy Settings in Chrome](https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md). **To enable single sign-on for Internet Explorer and Chrome using Group Policy settings** 1. Create a new Group Policy object by performing the following steps: 1. Open the Group Policy Management tool, navigate to your domain and select **Group Policy Objects**. 1. From the main menu, choose **Action** and select **New**. 1. In the **New GPO** dialog box, enter a descriptive name for the Group Policy object, such as `IAM Identity Center Policy`, and leave **Source Starter GPO** set to **(none)**. Click **OK**. 1. Add the access URL to the list of approved sites for single sign-on by performing the following steps: 1. In the Group Policy Management tool, navigate to your domain, select **Group Policy Objects**, open the context (right-click) menu for your IAM Identity Center policy, and choose **Edit**. 1. In the policy tree, navigate to **User Configuration** > **Preferences** > **Windows Settings**. 1. In the **Windows Settings** list, open the context (right-click) menu for **Registry** and choose **New registry item**. 1. In the **New Registry Properties** dialog box, enter the following settings and choose **OK**: **Action** `Update` **Hive** `HKEY_CURRENT_USER` **Path** `Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\awsapps.com\` The value for ** is derived from your access URL. If your access URL is `https://examplecorp.awsapps.com`, the alias is `examplecorp`, and the registry key will be `Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\awsapps.com\examplecorp`. **Value name** `https` **Value type** `REG_DWORD` **Value data** `1` 1. To enable active scripting, perform the following steps: 1. In the Group Policy Management tool, navigate to your domain, select **Group Policy Objects**, open the context (right-click) menu for your IAM Identity Center policy, and choose **Edit**. 1. In the policy tree, navigate to **Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **Internet Explorer** > **Internet Control Panel** > **Security Page** > **Intranet Zone**. 1. In the **Intranet Zone** list, open the context (right-click) menu for **Allow active scripting** and choose **Edit**. 1. In the **Allow active scripting** dialog box, enter the following settings and choose **OK**: + Select the **Enabled** radio button. + Under **Options** set **Allow active scripting** to **Enable**. 1. To enable automatic logon, perform the following steps: 1. In the Group Policy Management tool, navigate to your domain, select Group Policy Objects, open the context (right-click) menu for your SSO policy, and choose **Edit**. 1. In the policy tree, navigate to **Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **Internet Explorer** > **Internet Control Panel** > **Security Page** > **Intranet Zone**. 1. In the **Intranet Zone** list, open the context (right-click) menu for **Logon options** and choose **Edit**. 1. In the **Logon options** dialog box, enter the following settings and choose **OK**: + Select the **Enabled** radio button. + Under **Options** set **Logon options** to **Automatic logon only in Intranet zone**. 1. To enable integrated authentication, perform the following steps: 1. In the Group Policy Management tool, navigate to your domain, select **Group Policy Objects**, open the context (right-click) menu for your IAM Identity Center policy, and choose **Edit**. 1. In the policy tree, navigate to **User Configuration** > **Preferences** > **Windows Settings**. 1. In the **Windows Settings** list, open the context (right-click) menu for **Registry** and choose **New registry item**. 1. In the **New Registry Properties** dialog box, enter the following settings and choose **OK**: **Action** `Update` **Hive** `HKEY_CURRENT_USER` **Path** `Software\Microsoft\Windows\CurrentVersion\Internet Settings` **Value name** `EnableNegotiate` **Value type** `REG_DWORD` **Value data** `1` 1. Close the **Group Policy Management Editor** window if it is still open. 1. Assign the new policy to your domain by following these steps: 1. In the Group Policy Management tree, open the context (right-click) menu for your domain and choose **Link an Existing GPO**. 1. In the **Group Policy Objects** list, select your IAM Identity Center policy and choose **OK**. These changes will take effect after the next Group Policy update on the client, or the next time the user logs in. ## Single sign-on for Firefox Firefox To allow Mozilla Firefox browser to support single sign-on, add your access URL (e.g., https://**.awsapps.com) to the list of approved sites for single sign-on. This can be done manually, or automated with a script. **Topics** + [ ### Manual update for single sign-on ](#firefox_sso_manual) + [ ### Automatic update for single sign-on ](#firefox_sso_script) ### Manual update for single sign-on To manually add your access URL to the list of approved sites in Firefox, perform the following steps on the client computer. **To manually add your access URL to the list of approved sites in Firefox** 1. Open Firefox and open the `about:config` page. 1. Open the `network.negotiate-auth.trusted-uris` preference and add your access URL to the list of sites. Use a comma (,) to separate multiple entries. ### Automatic update for single sign-on As a domain administrator, you can use a script to add your access URL to the Firefox `network.negotiate-auth.trusted-uris` user preference on all computers on your network. For more information, go to [https://support.mozilla.org/en-US/questions/939037](https://support.mozilla.org/en-US/questions/939037). # Granting AWS Managed Microsoft AD users and groups access to AWS resources with IAM roles Granting access to AWS resources AWS Directory Service provides the ability to give your AWS Managed Microsoft AD users and groups access to AWS services and resources, such as access to the Amazon EC2 console. Similar to granting IAM users access to manage directories as described in [Identity-based policies (IAM policies)](IAM_Auth_Access_Overview.md#IAM_Auth_Access_ManagingAccess_IdentityBased), in order for users in your directory to have access to other AWS resources, such as Amazon EC2 you must assign IAM roles and policies to those users and groups. For more information, see [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) in the *IAM User Guide*. For information about how to grant users access to the AWS Management Console, see [Enabling AWS Management Console access with AWS Managed Microsoft AD credentials](ms_ad_management_console_access.md). **Topics** + [ # Creating a new IAM role ](create_role.md) + [ # Editing the trust relationship for an existing IAM role ](edit_trust.md) + [ # Assigning users or groups to an existing IAM role ](assign_role.md) + [ # Viewing users and groups assigned to a role ](view_role_details.md) + [ # Removing a user or group from an IAM role ](remove_role_users.md) + [ # Using AWS managed policies with Directory Service ](ms_ad_managed_policies.md) # Creating a new IAM role Creating a new role If you need to create a new IAM role for use with Directory Service, you must create it using the IAM console. Once the role has been created, you must then set up a trust relationship with that role before you can see that role in the Directory Service console. For more information, see [Editing the trust relationship for an existing IAM role](edit_trust.md). **Note** The user performing this task must have permission to perform the following IAM actions. For more information, see [Identity-based policies (IAM policies)](IAM_Auth_Access_Overview.md#IAM_Auth_Access_ManagingAccess_IdentityBased). iam:PassRole iam:GetRole iam:CreateRole iam:PutRolePolicy **To create a new role in the IAM console** 1. In the navigation pane of the IAM console, choose **Roles**. For more information, see [Creating a role (AWS Management Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*. 1. Choose **Create role**. 1. Under **Choose the service that will use this role**, choose **Directory Service**, and then choose **Next**. 1. Select the check box next to the policy (for example, **AmazonEC2FullAccess**) that you want to apply to your directory users, and then choose **Next**. 1. If necessary, add a tag to the role, and then choose **Next**. 1. Provide a **Role name** and optional **Description**, and then choose **Create role**. **Example: Create a role to enable AWS Management Console access** The following checklist provides an example of the tasks you must complete to create a new IAM role that will give specific AWS Managed Microsoft AD users access to the Amazon EC2 console. 1. Create a role with the IAM console using the procedure above. When prompted for a policy, choose **AmazonEC2FullAccess**. 1. Use the steps in [Editing the trust relationship for an existing IAM role](edit_trust.md) to edit the role you just created, and then add the required trust relationship information to the policy document. This step is necessary for the role to be visible immediately after you enable access to the AWS Management Console in the next step. 1. Follow the steps in [Enabling AWS Management Console access with AWS Managed Microsoft AD credentials](ms_ad_management_console_access.md) to configure general access to the AWS Management Console. 1. Follow the steps in [Assigning users or groups to an existing IAM role](assign_role.md) to add the users who need full access to EC2 resources to the new role. # Editing the trust relationship for an existing IAM role Editing the trust relationship for an existing role You can assign your existing IAM roles to your Directory Service users and groups. To do this, however, the role must have a trust relationship with Directory Service. When you use Directory Service to create a role using the procedure in [Creating a new IAM role](create_role.md), this trust relationship is automatically set. **Note** You only need to establish this trust relationship for IAM roles that are not created by Directory Service. **To establish a trust relationship for an existing IAM role to Directory Service** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane of the IAM console, under **Access management**, choose **Roles**. The console displays the roles for your account. 1. Choose the name of the role that you want to modify, and once on the role's page, select the **Trust relationships** tab. 1. Choose **Edit trust policy**. 1. Under **Edit trust policy**, paste the following, and then choose **Update policy**. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ds.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ You can also update this policy document using the AWS CLI. For more information, see [update-trust](https://docs.aws.amazon.com/cli/latest/reference/ds/update-trust.html) in the *AWS CLI Command Reference*. # Assigning users or groups to an existing IAM role Assigning users or groups to an existing role You can assign an existing IAM role to an AWS Managed Microsoft AD user or group. To do this, make sure you have completed the following. **Prerequisites** + [ Create an AWS Managed Microsoft AD](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_create_directory). + [Create an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_create.html) or [create a IAM group](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_groups_create.html). + [Create a role](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/create_role.html) that has a trust relationship with Directory Service. For existing IAM roles, you will need to [edit the trust relationship for an existing role](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/edit_trust.html). **Important** Access for AWS Managed Microsoft AD users in nested groups within your directory are not supported. Members of the parent group have console access, but members of child groups do not. **To assign AWS Managed Microsoft AD users or groups to an existing IAM role** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, under **Active Directory**, choose **Directories**. 1. On the **Directories** page, choose your directory ID. 1. On the **Directory details** page, do one of the following: 1. If you do not have any Regions showing under **Multi-Region replication**, choose the **Application management** tab. 1. If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to make your assignments, and then choose the **Application management** tab. For more information, see [Primary vs additional Regions](multi-region-global-primary-additional.md). 1. Scroll down to the **AWS Management Console** section, choose **Actions** and **Enable**. 1. Under the **Delegate console access** section, choose the IAM role name for the existing IAM role that you want to assign users to. 1. On the **Selected role** page, under **Manage users and groups for this role**, choose **Add**. 1. On the **Add users and groups to the role** page, under **Select Active Directory Forest**, choose either the AWS Managed Microsoft AD forest (this forest) or the on-premises forest (trusted forest), whichever contains where the accounts that need access to the AWS Management Console. For more information about how to set up a trusted forest, see [Tutorial: Create a trust relationship between your AWS Managed Microsoft AD and your self-managed Active Directory domain](ms_ad_tutorial_setup_trust.md). 1. Under **Specify which users or groups to add**, select either **Find by user** or **Find by group**, and then type the name of the user or group. In the list of possible matches, choose the user or group that you want to add. 1. Choose **Add** to finish assigning the users and groups to the role. # Viewing users and groups assigned to a role To view the AWS Managed Microsoft AD users and groups assigned to an IAM role, perform the following steps. **Prerequisites** + [ Create an AWS Managed Microsoft AD](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_create_directory). + [Create an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_create.html) or [create a IAM group](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_groups_create.html). + [Create a role](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/create_role.html) that has a trust relationship with Directory Service. For existing IAM roles, you will need to [edit the trust relationship for an existing role](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/edit_trust.html). + [Assign your users or groups to an existing IAM role](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/assign_role.html). **To view AWS Managed Microsoft AD users and group assigned to an IAM role** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, under **Active Directory**, choose **Directories**. 1. On the **Directories** page, choose your directory ID. 1. On the **Directory details** page, do one of the following: 1. If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to view your assignments, and then choose the **Application management** tab. For more information, see [Primary vs additional Regions](multi-region-global-primary-additional.md). 1. If you do not have any Regions showing under **Multi-Region replication**, choose the **Application management** tab. 1. Scroll down to the **AWS Management Console** section. The **Status** should be **Enabled**. If not, choose **Actions** and **Enable**. For more information, see [Enabling AWS Management Console access with AWS Managed Microsoft AD credentials](ms_ad_management_console_access.md). **Note** You won't see any groups or users if the AWS Management Console is disabled. 1. Under the **Delegate Console Access** section, select the hyperlink of the IAM role you want to view. Alternatively, you can select **View policy in IAM** to view the IAM policy in the IAM console. 1. On the **Selected role** page, under the **Manage users and groups for this role** section, you can view the users and groups assigned to the IAM role. # Removing a user or group from an IAM role Removing a user or group from a role To remove an AWS Managed Microsoft AD user or group from an IAM role, perform the following steps. **To remove a user or group from an IAM role** 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, do one of the following: 1. If you have multiple Regions showing under **Multi-Region replication**, select the Region where you want to remove your assignments, and then choose the **Application management** tab. For more information, see [Primary vs additional Regions](multi-region-global-primary-additional.md). 1. If you do not have any Regions showing under **Multi-Region replication**, choose the **Application management** tab. 1. Under the **AWS Management Console** section, choose the IAM role you want to remove users and groups from. 1. On the **Selected role** page, under **Manage users and groups for this role**, select the users or groups to remove the role from and choose **Remove**. The role is removed from the specified users and groups, but the role is not removed from your account. **Note** If you want to delete a role, see [Delete roles or instance profiles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html). # Using AWS managed policies with Directory Service Using AWS managed policies Directory Service provides the following AWS managed policies to give your users and groups access to AWS services and resources, such as access to the Amazon EC2 console. You must log in to the AWS Management Console before you can view these policies. + [Read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/ReadOnlyAccess) + [Power user access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/PowerUserAccess) + [Directory Service full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSDirectoryServiceFullAccess) + [Directory Service read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSDirectoryServiceReadOnlyAccess) + [AWS Directory Service Data full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSDirectoryServiceDataFullAccess) + [AWS Directory Service Data read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSDirectoryServiceDataReadOnlyAccess) + [Amazon Cloud Directory full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonCloudDirectoryFullAccess) + [Amazon Cloud Directory read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonCloudDirectoryReadOnlyAccess) + [Amazon EC2 full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2FullAccess) + [Amazon EC2 read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess) + [Amazon VPC full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonVPCFullAccess) + [Amazon VPC read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonVPCReadOnlyAccess) + [Amazon RDS full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonRDSFullAccess) + [Amazon RDS read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonRDSReadOnlyAccess) + [Amazon DynamoDB full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess) + [Amazon DynamoDB read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess) + [Amazon S3 full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonS3FullAccess) + [Amazon S3 read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess) + [AWS CloudTrail full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCloudTrailFullAccess) + [AWS CloudTrail read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCloudTrailReadOnlyAccess) + [Amazon CloudWatch full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/CloudWatchFullAccess) + [Amazon CloudWatch read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess) + [Amazon CloudWatch Logs full access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/CloudWatchLogsFullAccess) + [Amazon CloudWatch Logs read only access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/CloudWatchLogsReadOnlyAccess) For more information on how to create your own policies, see [Example policies for administering AWS resources](https://docs.aws.amazon.com/console/iam/example-policies) in the *IAM User Guide*. # Configure Multi-Region replication for AWS Managed Microsoft AD Configure Multi-Region replication Multi-Region replication can be used to automatically replicate your AWS Managed Microsoft AD directory data across multiple AWS Regions. This replication can improve performance for users and applications in disperse geographic locations. AWS Managed Microsoft AD uses native Active Directory replication to replicate your directory's data securely to the new Region. Multi-Region replication is only supported for the **Enterprise Edition** of AWS Managed Microsoft AD. You can use automated multi-Region replication in most Regions where AWS Managed Microsoft AD is available. **Note** Multi-Region replication is unavailable in the following opt-in Regions: Middle East (Bahrain) me-south-1 Middle East (UAE) me-central-1 For more information about opt-in Regions and how to enable them, see [Specify which AWS Regions your account can use](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) in the *AWS Account Management Guide*. **Important** You can only extend Multi-Region replication to additional Regions if your primary Region is an AWS default Region. If your primary Region is an opt-in Region, you cannot add additional Regions to your Multi-Region replication. Ensure that your directory was originally created in an AWS default Region before attempting to extend replication. ## How Multi-Region replication works How it works With the Multi-Region replication feature, AWS Managed Microsoft AD eliminates the undifferentiated heavy lifting of managing a global Active Directory infrastructure. When configured, AWS replicates all customer directory data including users, groups, group policies, and schema across multiple AWS Regions. Once a new Region has been added, the following operations automatically occur as shown in the illustration: + AWS Managed Microsoft AD creates two domain controllers in the selected VPC and deploys them to the new Region in the same AWS account. Your directory identifier (`directory_id`) remains the same across all Regions. You can add additional domain controllers later if you want. + AWS Managed Microsoft AD configures the networking connection between the primary Region and the new Region. + AWS Managed Microsoft AD creates a new Active Directory site and gives it the same name as the Region, such as us-east-1. You can also rename this later using the Active Directory Sites and Services tool. + AWS Managed Microsoft AD replicates all Active Directory objects and configurations to the new Region, including users, groups, group policies, Active Directory trusts, organizational units, and Active Directory schema. Active Directory site links are configured to use [Change Notification](https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/modify-default-intra-site-dc-replication-interval). With change notification between sites enabled, changes propagate to the remote site with the same frequency that they are propagated within the source site, including changes that warrant urgent replication. + If this is the first Region you've added, AWS Managed Microsoft AD makes all features multi-Region aware. For more information, see [Global vs Regional features](multi-region-global-region-features.md). ![\[Multi-region replication of a AWS Managed Microsoft AD Active Directory between a primary region and an additional region.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/multiregion.png) ### Active Directory sites Multi-Region replication supports multiple Active Directory sites (one Active Directory site per Region). When a new Region is added, it is given the same name as the Region—for example, us-east-1. You can also rename this later using Active Directory Sites and Services. ### AWS services AWS services such as Amazon RDS for SQL Server and Amazon FSx connect to the local instances of the global directory. This allows your users to sign in once to Active Directory-aware applications that run in AWS as well as AWS services like Amazon RDS for SQL Server in any AWS Region. To do so, users need credentials from AWS Managed Microsoft AD or on-premises Active Directory when you have a trust with your AWS Managed Microsoft AD. You can use the following AWS services with the multi-Region replication feature. + Amazon EC2 + Amazon FSx for Windows File Server + Amazon Relational Database Service for SQL Server + Amazon RDS for Oracle + Amazon RDS for MySQL + Amazon RDS for PostgreSQL + Amazon RDS for MariaDB + Amazon Aurora for MySQL + Amazon Aurora for PostgreSQL ### Failover In the event that all domain controllers in one Region are down, AWS Managed Microsoft AD recovers the domain controllers and replicates the directory data automatically. Meanwhile domain controllers in other Regions stay up and running. ## Benefits of multi-Region replication Benefits With multi-Region replication in AWS Managed Microsoft AD, Active Directory-aware applications use the directory locally for high performance and the multi-Region feature for resiliency. You can use multi-Region replication with Active Directory-aware applications like SharePoint and SQL Server Always On as well as AWS services like Amazon RDS for SQL Server and FSx for Windows File Server. The following are additional benefits of multi-Region replication. + It lets you deploy a single AWS Managed Microsoft AD instance globally, quickly, and eliminates the heavy lifting of self-managing a global Active Directory infrastructure. + It makes it easier and more cost-effective for you to deploy and manage Windows and Linux workloads in multiple AWS Regions. Automated multi-Region replication enables optimal performance in your global Active Directory-aware applications. All applications deployed in Windows or Linux instances use AWS Managed Microsoft AD locally in the Region, which enables responses to user requests from the closest Region possible. + It provides multi-Region resiliency. Deployed in the highly available AWS managed infrastructure, AWS Managed Microsoft AD handles automated software updates, monitoring, recovery, and the security of the underlying Active Directory infrastructure across all Regions. This allows you to focus on building your applications. **Topics** + [ ## How Multi-Region replication works ](#multi-region-how-it-works) + [ ## Benefits of multi-Region replication ](#multi-region-benefits) + [ # Global vs Regional features ](multi-region-global-region-features.md) + [ # Primary vs additional Regions ](multi-region-global-primary-additional.md) + [ # Adding a replicated Region for AWS Managed Microsoft AD ](multi-region-add-region.md) + [ # Deleting a replicated Region for AWS Managed Microsoft AD ](multi-region-delete-region.md) # Global vs Regional features When you add an AWS Region to your directory using multi-Region replication, Directory Service enhances the scope of all features so that they become Region-aware. These features are listed on various tabs of the details page that appears when you choose the ID of a directory in the Directory Service console. This means that all features are enabled, configured, or managed based on the Region that you select in the **Multi-Region replication** section of the console. Changes you make to features in each Region are either applied globally or per Region. Multi-Region replication is only supported for the **Enterprise Edition** of AWS Managed Microsoft AD. ## Global features Any changes that you make to global features while the [Primary Region](multi-region-global-primary-additional.md#multi-region-primary) is selected will be applied across all Regions. You can identify the features that are used globally on the **Directory details** page because they display **Applied to all replicated Regions** next to them. Alternatively, if you selected another Region in the list that is not the primary Region, you can identify the globally used features because they display **Inherited from primary Region**. ## Regional features Any changes that you make to a feature in an [Additional Region](multi-region-global-primary-additional.md#multi-region-additional) will be applied only to that Region. You can identify the features that are Regional on the **Directory details** page because they do ***not*** display **Applied to all replicated Regions** or **Inherited from primary Region** next to them. # Primary vs additional Regions With multi-Region replication, AWS Managed Microsoft AD uses the following two types of Regions to differentiate how global or Regional features should be applied across your directory. ## Primary Region The initial Region where you first created your directory is referred to as the *primary* Region. You can perform only global directory level operations such as creating Active Directory trusts and updating the AD schema from the primary Region. The primary Region can always be identified as the first Region showing at the top of the list in the **Multi-Region replication** section, and ends with **- Primary**. For example, **US East (N. Virginia) - Primary**. Any changes that you make to [Global features](multi-region-global-region-features.md#multi-region-global) while the primary Region is selected will be applied across all Regions. You can only add Regions while the primary Region is selected. For more information, see [Adding a replicated Region for AWS Managed Microsoft AD](multi-region-add-region.md). ## Additional Region Any Regions that you have added to your directory are referred to as *additional* Regions. Although some features can be managed globally for all Regions, others are managed individually per Region. To manage a feature for an additional Region (non-primary Region), you must first select the additional Region from the list in the **Multi-Region replication** section on the **Directory details** page. Then you can proceed to manage the feature. Any changes that you make to [Regional features](multi-region-global-region-features.md#multi-region-regional) while an additional Region is selected will be applied only to that Region. # Adding a replicated Region for AWS Managed Microsoft AD Adding a replicated Region When you add a Region using the [Configure Multi-Region replication for AWS Managed Microsoft AD](ms_ad_configure_multi_region_replication.md) feature, AWS Managed Microsoft AD creates two domain controllers in the selected AWS Region, Amazon Virtual Private Cloud (VPC), and subnet. AWS Managed Microsoft AD also creates the related security groups that enable Windows workloads to connect to your directory in the new Region. It also creates these resources using the same AWS account where your directory is already deployed. You do this by choosing the Region, specifying the VPC, and providing the configurations for the new Region. Multi-Region replication is only supported for the **Enterprise Edition** of AWS Managed Microsoft AD. ## Prerequisites Before you proceed with the steps to add a new replication Region, we recommend that you first review the following prerequisite tasks. + Verify that you have the necessary AWS Identity and Access Management (IAM) permissions, Amazon VPC setup, and the subnet setup in the new Region to which you want to replicate the directory. + If you want to use your existing on-premises Active Directory credentials to access and manage Active Directory-aware workloads in AWS, you must create an Active Directory trust between AWS Managed Microsoft AD and your on-premises AD infrastructure. For more information about trusts, see [Connect AWS Managed Microsoft AD to your existing Active Directory infrastructure](ms_ad_connect_existing_infrastructure.md). + If you have an existing trust relationship between your on-premises Active Directory and you want to add a replicated region, you need to verify you have the necessary Amazon VPC and subnet setup in the new Region to which you want to replicate the directory. You can also create a trust between your AWS Managed Microsoft AD and on-premise AD infrastructure, so you can use existing on-premises Active Directory credentials to manage AD-aware workloads. For more information, see [Connect AWS Managed Microsoft AD to your existing Active Directory infrastructure](ms_ad_connect_existing_infrastructure.md). ## Add a Region Use the following procedure to add a replicated Region for your AWS Managed Microsoft AD directory. **To add a replicated Region** 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, under **Multi-Region replication**, choose the **Primary** Region from the list, and then choose **Add Region**. **Note** You can only add Regions while the **Primary** Region is selected. For more information, see [Primary Region](multi-region-global-primary-additional.md#multi-region-primary). 1. On the **Add Region** page, under **Region**, choose the Region you want to add from the list. 1. Under **VPC**, choose the VPC to use for this Region. **Note** This VPC must not have a Classless Inter-Domain Routing (CIDR) that overlaps with a VPC used by this directory in another Region. 1. Under **Subnets**, choose the subnet to use for this Region. 1. Review the information under **Pricing**, and then choose **Add**. 1. When AWS Managed Microsoft AD completes the domain controller deployment process, the Region will display **Active** status. You can now make updates to this Region as needed. ## Next steps After you add your new Region, you should consider doing the following next steps: + Deploy additional domain controllers (up to 20) to your new Region as needed. The number of domain controllers when you add a new Region is 2 by default, which is the minimum required for fault-tolerance and high availability purposes. For more information, see [Adding or removing additional domain controllers with the AWS Management Console](ms_ad_deploy_additional_dcs.md#addremovedcs). **Note** When you add a replicated AWS Region to your AWS Managed Microsoft AD, two domain controllers are created by default, which is the minimum number of domain controllers required for fault-tolerance and high availability. + Share your directory with more AWS accounts per Region. Directory sharing configurations are not replicated from the primary Region automatically. For more information, see [Share your AWS Managed Microsoft AD](ms_ad_directory_sharing.md). **Note** Directory sharing configurations aren't automatically replicated in the primary AWS Region. + Enable log forwarding to retrieve your directory's security logs using Amazon CloudWatch Logs from the new Region. When you enable log forwarding, you must provide a log group name in each Region where you replicated your directory. For more information, see [Enabling Amazon CloudWatch Logs log forwarding for AWS Managed Microsoft AD](ms_ad_enable_log_forwarding.md). **Note** When you enable log forwarding, you must provide a name for the log group in each AWS Region where you replicated your directory. + Enable Amazon Simple Notification Service (Amazon SNS) monitoring for the new Region to track your directory health status per Region. For more information, see [Enabling AWS Managed Microsoft AD directory status notifications with Amazon Simple Notification Service](ms_ad_enable_notifications.md). # Deleting a replicated Region for AWS Managed Microsoft AD Deleting a replicated Region Use the following procedure to delete a Region for your AWS Managed Microsoft AD directory. Before you delete a Region, make sure it does not have either of the following: + Authorized applications attached to it. + Shared directories associated with it. **To delete a replicated Region** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, choose **Directories**. 1. From the navigation bar, choose the **Regions** selector and choose the region where your directory is stored. 1. On the **Directories** page, choose your directory ID. 1. On the **Directory details** page, under **Multi-Region replication** choose **Delete Region**. 1. In the **Delete Region** dialog box, review the information, and then enter in the Region name to confirm. Then choose **Delete**. **Note** You cannot make updates to the Region while it's being deleted. # Share your AWS Managed Microsoft AD Share your directory AWS Managed Microsoft AD integrates tightly with AWS Organizations to allow seamless directory sharing across multiple AWS accounts. You can share a single directory with other trusted AWS accounts within the same organization or share the directory with other AWS accounts that are outside your organization. You can also share your directory when your AWS account is not currently a member of an organization. ## Key directory sharing concepts Key concepts You will get more out of the directory sharing feature if you become familiar with the following key concepts. ![\[Two AWS Managed Microsoft AD with directory sharing, domain joins, and Amazon VPC peering.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/directory_sharing_concepts.png) ### Directory owner account A directory owner is the AWS account holder that owns the originating directory in the shared directory relationship. An administrator in this account initiates the directory sharing workflow by specifying which AWS accounts to share their directory with. Directory owners can see who they've shared a directory with using the **Scale & Share** tab for a given directory in the Directory Service console. ### Directory consumer account In a shared directory relationship, a directory consumer represents the AWS account to which the directory owner shared the directory with. Depending on the sharing method used, an administrator in this account may need to accept an invite sent from the directory owner before they can start using the shared directory. The directory sharing process creates a shared directory in the directory consumer account. This shared directory contains the metadata that enables the EC2 instance to seamlessly join the domain, which locates the originating directory in the directory owner account. Each shared directory in the directory consumer account has a unique identifier (**Shared directory ID**). ### Sharing methods AWS Managed Microsoft AD provides the following two directory sharing methods: + **AWS Organizations** – This method makes it easier to share the directory within your organization because you can browse and validate the directory consumer accounts. To use this option, your organization must have **All features** enabled, and your directory must be in the organization management account. This method of sharing simplifies your setup because it doesn't require the directory consumer accounts to accept your directory sharing request. In the console, this method is referred to as **Share this directory with AWS accounts inside your organization**. + **Handshake** – This method enables directory sharing when you aren't using AWS Organizations. The handshake method requires the directory consumer account to accept the directory sharing request. In the console, this method is referred to as **Share this directory with other AWS accounts**. ### Network connectivity Network connectivity is a prerequisite to use a directory sharing relationship across AWS accounts. AWS supports many solutions to connect your VPCs, some of these include [VPC peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html), and [VPN](https://docs.aws.amazon.com/vpc/latest/adminguide/Welcome.html). To get started, see [Tutorial: Sharing your AWS Managed Microsoft AD directory for seamless EC2 domain-join](ms_ad_tutorial_directory_sharing.md). ## Considerations The following are some considerations when using directory share with your AWS Managed Microsoft AD: **Pricing** + AWS charges an additional fee for directory sharing. The AWS account that is using the shared AWS Managed Microsoft AD is the account charged the sharing fees. To learn more, see the [Pricing](https://aws.amazon.com/directoryservice/pricing/) page on the Directory Service website. + Directory sharing makes AWS Managed Microsoft AD a more cost-effective way of integrating with Amazon EC2 in multiple accounts and VPCs. **Region availability** + Directory sharing is available in all [AWS regions where AWS Managed Microsoft AD](regions.md) is offered. + In the AWS China (Ningxia), this feature is available only when using [AWS Systems Manager](https://aws.amazon.com/systems-manager/) (SSM) to seamlessly join your Amazon EC2 instances. For more information about directory sharing and how to extend the reach of your AWS Managed Microsoft AD directory across AWS account boundaries, see the following topics. **Topics** + [ ## Key directory sharing concepts ](#ms_ad_directory_sharing_key_concepts) + [ ## Considerations ](#ms_ad_directory_sharing_considerations) + [ # Tutorial: Sharing your AWS Managed Microsoft AD directory for seamless EC2 domain-join ](ms_ad_tutorial_directory_sharing.md) + [ # Unsharing your directory ](ms_ad_directory_sharing_unshare.md) # Tutorial: Sharing your AWS Managed Microsoft AD directory for seamless EC2 domain-join Tutorial: Share your AWS Managed Microsoft AD directory This tutorial shows you how to share your AWS Managed Microsoft AD directory (the directory owner account) with another AWS account (the directory consumer account). Once the networking prerequisites have been completed, you will share a directory between two AWS accounts. Then you will learn how to seamlessly join an EC2 instance to a domain in the directory consumer account. We recommend that you first review directory sharing key concepts and use case content before you start work on this tutorial. For more information, see [Key directory sharing concepts](ms_ad_directory_sharing.md#ms_ad_directory_sharing_key_concepts). The process for sharing your directory differs depending on whether you share the directory with another AWS account in the same AWS organization or with an account that is outside of the AWS organization. For more information about how sharing works, see [Sharing methods](ms_ad_directory_sharing.md#sharing_methods). This workflow has four basic steps. ![\[Steps to share AWS Managed Microsoft AD: Set up your networking environment, share your directory, accept shared directory invite, and test seamlessly join an Amazon EC2 instance for Windows Server to a domain.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/directory_sharing_tutorial3.png) **[Step 1: Set up your networking environment](step1_setup_networking.md)** In the directory owner account, you set up all of the networking prerequisites necessary for the directory sharing process. **[Step 2: Share your directory](step2_share_directory.md)** While signed in with directory owner administrator credentials, you open the Directory Service console and start the share directory workflow, which sends an invitation to the directory consumer account. **[Step 3: Accept shared directory invite - Optional](step3_accept_invite.md)** While signed in with directory consumer administrator credentials, you open the Directory Service console and accept the directory sharing invite. **[Step 4: Test seamlessly joining an EC2 instance for Windows Server to a domain](step4_test_ec2_access.md)** Finally, as the directory consumer administrator, you attempt to join an EC2 instance to your domain and verify that it works. **Additional resources** + [Use case: Share your directory to seamlessly join Amazon EC2 instances to a domain across AWS accounts](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/usecase6.html) + [AWS Security Blog Article: How to Join Amazon EC2 Instances From Multiple Accounts and VPCs to a Single AWS Managed Microsoft AD Directory](https://aws.amazon.com/blogs/security/how-to-domain-join-amazon-ec2-instances-aws-managed-microsoft-ad-directory-multiple-accounts-vpcs/) # Step 1: Set up your networking environment You will need to establish an Amazon VPC peering connection to share your AWS Managed Microsoft AD directory (directory account owner) with another AWS account (directory consumer account). See the following procedures for steps to set up your networking environment for a shared AWS Managed Microsoft AD. ## Prerequisites Before you begin the steps in this tutorial, you must first do the following: + Create two new AWS accounts for testing purposes in the same Region. When you create an AWS account, it automatically creates a dedicated virtual private cloud (VPC) in each account. Take note of the VPC ID in each account. You will need this later. + [Create an AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + When creating a VPC peering connection, both the directory account owner and directory consumer account will need the necessary permissions to create and accept the peering connection. For more information, see [Example: Create a VPC peering connection](https://docs.aws.amazon.com//vpc/latest/peering/security-iam.html#vpc-peering-iam-create) and [Example: Accept a VPC peering connection](https://docs.aws.amazon.com//vpc/latest/peering/security-iam.html#vpc-peering-iam-accept). **Note** While there are many ways to connect Directory owner and Directory consumer account VPCs, this tutorial will use the VPC peering method. For additional VPC connectivity options, see [Network connectivity](ms_ad_directory_sharing.md#network_connectivity). ## Configure a VPC peering connection between the directory owner and the directory consumer account The VPC peering connection you will create is between the directory consumer and directory owner VPCs. Follow these steps to configure a VPC peering connection for connectivity with the directory consumer account. With this connection you can route traffic between both VPCs using private IP addresses. **To create a VPC peering connection between the directory owner and directory consumer account** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). Makes sure to sign in as a user with administrator credentials in the directory owner account with the necessary permissions to create a VPC peering connection. See [Prerequisites](#step1_setup_networking_prereqs) for more information. 1. In the navigation pane, choose **Peering Connections**. Then choose **Create Peering Connection**. 1. Configure the following information: + **Peering connection name tag**: Provide a name that clearly identifies this connection with the VPC in the directory consumer account. + **VPC (Requester)**: Select the VPC ID for the directory owner account. + Under **Select another VPC to peer with**, ensure that **My account** and **This region** are selected. + **VPC (Accepter)**: Select the VPC ID for the directory consumer account. 1. Choose **Create Peering Connection**. In the confirmation dialog box, choose **OK**. **To accept the peering request on behalf of the directory consumer account** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). Makes sure to sign in as a user with the necessary permissions to accept the peering request. See [Prerequisites](#step1_setup_networking_prereqs) for more information. 1. In the navigation pane, choose **Peering Connections**. 1. Select the pending VPC peering connection. (Its status is Pending Acceptance.) Choose **Actions**, **Accept Request**. 1. In the confirmation dialog, choose **Yes, Accept**. In the next confirmation dialog box, choose **Modify my route tables now** to go directly to the route tables page. Now that your VPC peering connection is active, you must add an entry to your VPC route table in the directory owner account. Doing so enables traffic to be directed to the VPC in the directory consumer account. **To add an entry to the VPC route table in the directory owner account** 1. While in the **Route Tables** section of the Amazon VPC console, select the route table for the directory owner VPC. 1. Choose the **Routes** tab, choose **Edit routes**, and then choose **Add route**. 1. In the **Destination** column, enter the CIDR block for the directory consumer VPC. 1. In the **Target** column, enter the VPC peering connection ID (such as **pcx-123456789abcde000**) for the peering connection that you created earlier in the directory owner account. 1. Choose **Save changes**. **To add an entry to the VPC route table in the directory consumer account** 1. While in the **Route Tables** section of the Amazon VPC console, select the route table for the directory consumer VPC. 1. Choose the **Routes** tab, choose **Edit routes**, and then choose **Add route**. 1. In the **Destination** column, enter the CIDR block for the directory owner VPC. 1. In the **Target** column, type in the VPC peering connection ID (such as **pcx-123456789abcde001**) for the peering connection that you created earlier in the directory consumer account. 1. Choose **Save changes**. Add Active Directory protocols and ports to the outbound rules for security groups in directory consumer VPCs. For more information, see [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) and [AWS Managed Microsoft AD prerequisites](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_prereqs.html). **Next Step** [Step 2: Share your directory](step2_share_directory.md) # Step 2: Share your directory Use the following procedures to begin the directory sharing workflow from within the directory owner account. **Note** Directory sharing 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). **To share your directory from the directory owner account** 1. Sign into the AWS Management Console with administrator credentials in the directory owner account and open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) at https://console.aws.amazon.com/directoryservicev2/. 1. In the navigation pane, choose **Directories**. 1. Choose the directory ID of the AWS Managed Microsoft AD directory that you want to share. 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 share your directory, and then choose the **Scale & share** 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 **Scale & share** tab. 1. In the **Shared directories** section, choose **Actions**, and then choose **Create new shared directory**. 1. On the **Choose which AWS accounts to share with** page, choose one of the following sharing methods depending on your business needs: 1. **Share this directory with AWS accounts inside your organization** – With this option you can select the AWS accounts you want to share your directory with from a list showing all the AWS accounts inside your AWS organization. You must enable trusted access with Directory Service before you share a directory. For more information, see [How to enable or disable trusted access](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html#orgs_how-to-enable-disable-trusted-access). **Note** To use this option, your organization must have **All features** enabled, and your directory must be in the organization management account. 1. Under **AWS accounts in your organization**, select the AWS accounts that you want to share the directory with and click **Add**. 1. Review the pricing details, and then choose **Share**. 1. Proceed to [Step 4](step4_test_ec2_access.md) in this guide. Because all AWS accounts are in the same organization, you do not need to follow Step 3. 1. **Share this directory with other AWS accounts** - With this option, you can share a directory with accounts inside or outside your AWS organization. You can also use this option when your directory is not a member of an AWS organization and you want to share with another AWS account. 1. In **AWS account ID(s)**, enter all the AWS account IDs that you want to share the directory with, and then click **Add**. 1. In **Send a note**, type a message to the administrator in the other AWS account. 1. Review the pricing details, and then choose **Share**. 1. Proceed to Step 3. **Next Step** [Step 3: Accept shared directory invite - Optional](step3_accept_invite.md) # Step 3: Accept shared directory invite - Optional If you chose the **Share this directory with other AWS accounts** (handshake method) option in the previous procedure, you should use this procedure to finish the shared directory workflow. If you chose the **Share this directory with AWS accounts inside your organization** option, skip this step and proceed to Step 4. **To accept the shared directory invite** 1. Sign into the AWS Management Console with administrator credentials in the directory consumer account and open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) at https://console.aws.amazon.com/directoryservicev2/. 1. In the navigation pane, choose **Directories shared with me**. 1. In the **Shared directory ID** column, choose the directory ID that is in the **Pending acceptance** state. 1. On the **Shared directory details** page, choose **Review**. 1. In the **Pending shared directory invitation** dialog, review the note, directory owner details, and information about pricing. If you agree, choose **Accept** to start using the directory. **Next Step** [Step 4: Test seamlessly joining an EC2 instance for Windows Server to a domain](step4_test_ec2_access.md) # Step 4: Test seamlessly joining an EC2 instance for Windows Server to a domain You can use either of the following two methods to test seamlessly joining an EC2 instance to a domain. ## Method 1: Test domain join using the Amazon EC2 console Use these steps in the directory consumer account. 1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation bar, choose the same AWS Region as the existing directory. 1. On the **EC2 Dashboard**, in the **Launch instance** section, choose **Launch instance**. 1. On the **Launch an instance** page, under the **Name and Tags** section, enter the name you would like to use for your Windows EC2 instance. 1. (Optional) Choose **Add additional tags** to add one or more tag key-value pairs to organize, track, or control access for this EC2 instance. 1. In the **Application and OS Image (Amazon Machine Image)** section, choose **Windows** in the **Quick Start** pane. You can change the Windows Amazon Machine Image (AMI) from the **Amazon Machine Image (AMI)** dropdown list. 1. In the **Instance type** section, choose the instance type you would like to use from **Instance type** dropdown list. 1. In the **Key pair (login)** section, you can either choose to create a new key pair or choose from an existing key pair. 1. To create a new key pair, choose **Create new key pair**. 1. Enter a name for the key pair and select an option for the **Key pair type** and **Private key file format**. 1. To save the private key in a format that can be used with OpenSSH, choose **.pem**. To save the private key in a format that can be used with PuTTY, choose **.ppk**. 1. Choose **create key pair**. 1. The private key file is automatically downloaded by your browser. Save the private key file in a safe place. **Important** This is the only chance for you to save the private key file. 1. On the **Launch an instance** page, under **Network settings** section, choose **Edit**. Choose the **VPC** that your directory was created in from the **VPC -* required*** dropdown list. 1. Choose one of the public subnets in your VPC from the **Subnet** dropdown list. The subnet you choose must have all external traffic routed to an internet gateway. If this is not the case, you won't be able to connect to the instance remotely. For more information on how to connect to a 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*. 1. Under **Auto-assign public IP**, choose **Enable**. For more information about public and private IP addressing, see [Amazon EC2 instance IP addressing](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-instance-addressing.html) in the *Amazon EC2 User Guide*. 1. For **Firewall (security groups)** settings, you can use the default settings or make changes to meet your needs. 1. For **Configure storage** settings, you can use the default settings or make changes to meet your needs. 1. Select **Advanced details** section, choose your domain from the **Domain join directory** dropdown list. **Note** After choosing the Domain join directory, you may see: ![\[An error message when selecting your Domain join directory. There is an error with your existing SSM document.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/SSM-Error-Message.png) This error occurs if the EC2 launch wizard identifies an existing SSM document with unexpected properties. You can do one of the following: If you previously edited the SSM document and the properties are expected, choose close and proceed to launch the EC2 instance with no changes. Select the delete the existing SSM document here link to delete the SSM document. This will allow for the creation of an SSM document with the correct properties. The SSM document will automatically be created when you launch the EC2 instance. 1. For **IAM instance profile**, you can select an existing IAM instance profile or create a new one. Select an IAM instance profile that has the AWS managed policies **AmazonSSMManagedInstanceCore** and **AmazonSSMDirectoryServiceAccess** attached to it from the **IAM instance profile** dropdown list. To create a new one, choose **Create new IAM profile** link, and then do the following: 1. Choose **Create role**. 1. Under **Select trusted entity**, choose **AWS service**. 1. Under **Use case**, choose **EC2**. 1. Under **Add permissions**, in the list of policies, select the **AmazonSSMManagedInstanceCore** and **AmazonSSMDirectoryServiceAccess** policies. To filter the list, type **SSM** in the search box. Choose **Next**. **Note** **AmazonSSMDirectoryServiceAccess** provides the permissions to join instances to an Active Directory managed by Directory Service. **AmazonSSMManagedInstanceCore** provides the minimum permissions necessary to use the AWS Systems Manager service. For more information about creating a role with these permissions, and for information about other permissions and policies you can assign to your IAM role, see [Create an IAM instance profile for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html) in the *AWS Systems Manager User Guide*. 1. On the **Name, review, and create** page, enter a **Role name**. You will need this role name to attach to the EC2 instance. 1. (Optional) You can provide a description of the IAM instance profile in the **Description** field. 1. Choose **Create role**. 1. Return to **Launch an instance** page and choose the refresh icon next to the **IAM instance profile**. Your new IAM instance profile should be visible in the **IAM instance profile** dropdown list. Choose the new profile and leave the rest of the settings with their default values. 1. Choose **Launch instance**. ## Method 2: Test domain join using AWS Systems Manager Use these steps in the directory consumer account. To complete this procedure, you will need some information about the directory owner account such as the Directory ID, directory name, and the DNS IP addresses. **Prerequisites** + Setup AWS Systems Manager. + For more information about Systems Manager, see [General setup for AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setting_up_prerequisites.html). + Instances you wish to join the AWS Managed Microsoft Active Directory domain must have an attached IAM role containing the **AmazonSSMManagedInstanceCore** and **AmazonSSMDirectoryServiceAccess** managed policies. + For more information about these managed policies and other policies you can attach to an IAM instance profile for Systems Manager, see [Create an IAM instance profile for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html) in the *AWS Systems Manager User Guide*. For information about managed policies, see [AWS Managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. For more information on using Systems Manager to join EC2 instances to a AWS Managed Microsoft Active Directory domain, see [ How do I use AWS Systems Manager to join a running EC2 Windows instance to my AWS Directory Service domain?](https://repost.aws/knowledge-center/ec2-systems-manager-dx-domain#). 1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. In the navigation pane, under **Node Management**, choose **Run Command**. 1. Choose **Run command**. 1. On the **Run a command** page, search for `AWS-JoinDirectoryServiceDomain`. When it is displayed in the search results, select the `AWS-JoinDirectoryServiceDomain` option. 1. Scroll down to the **Command parameters** section. You must provide the following parameters: **Note** You can locate the **Directory ID**, **directory name**, and **DNS IP addresses** by going back to the Directory Service console, selecting **Directories shared with me**, and selecting your directory. Your **Directory ID** can be found under the **Shared directory details** section. You can locate the values for **Directory name** and **DNS IP addresses** under the **Owner directory details** section. + For **Directory ID**, enter the name of the AWS Managed Microsoft Active Directory. + For **Directory Name**, enter the name of the AWS Managed Microsoft Active Directory (for the directory owner account). + For **DNS IP Addresses**, enter the IP addresses of the DNS servers in the AWS Managed Microsoft Active Directory (for the directory owner account). 1. For **Targets**, choose **Choose instances manually**, and then select the instances that you want to join the domain. 1. Leave the remainder of the form set to their default values, scroll down the page, and then choose **Run**. 1. The command status will change from **Pending** to **Success** once the instances have successfully joined the domain. You can view the command output by selecting the **Instance ID** of the instance that joined the domain and **View output**. After completing either of these steps, you should now be able to join your EC2 instance to the domain. Once you do that, you can then log into your instance using a Remote Desktop Protocol (RDP) client with the credentials from your AWS Managed Microsoft AD user account. # Unsharing your directory Use the following procedure to unshare an AWS Managed Microsoft AD directory. **To unshare your directory** 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 of the AWS Managed Microsoft AD directory that you want to unshare. 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 unshare your directory, and then choose the **Scale & share** 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 **Scale & share** tab. 1. In the **Shared directories** section, select the shared directory you want to unshare, choose **Actions**, and then choose **Unshare**. 1. In the **Unshare directory** dialog box, choose **Unshare**. **Additional resources** + [Use case: Share your directory to seamlessly join amazon EC2 instances to a domain across AWS accounts](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/usecase6.html) + [AWS security blog article: How to join Amazon EC2 instances from multiple accounts and VPCs to a single AWS Managed Microsoft AD directory](https://aws.amazon.com/blogs/security/how-to-domain-join-amazon-ec2-instances-aws-managed-microsoft-ad-directory-multiple-accounts-vpcs/) + [Joining your Amazon RDS DB instances across accounts to a single shared domain](https://aws.amazon.com/blogs/database/joining-your-amazon-rds-instances-across-accounts-to-a-single-shared-domain/) # Migrating Active Directory users to AWS Managed Microsoft AD Migrating Active Directory users to AWS Managed Microsoft AD You can use the Active Directory Migration Toolkit (ADMT) along with the Password Export Service (PES) to migrate users from your self-managed Active Directory to your AWS Managed Microsoft AD directory. This enables you to migrate Active Directory objects and encrypted passwords for your users more easily. For detailed instructions, see [How to migrate your on-premises domain to AWS Managed Microsoft AD using ADMT](https://aws.amazon.com/blogs/security/how-to-migrate-your-on-premises-domain-to-aws-managed-microsoft-ad-using-admt/) on the *AWS Security Blog*. # Connect AWS Managed Microsoft AD to your existing Active Directory infrastructure Connect your existing Active Directory infrastructure This section describes how to configure trust relationships between AWS Managed Microsoft AD and your existing Active Directory infrastructure. **Topics** + [ # Creating a trust relationship between your AWS Managed Microsoft AD and self-managed AD ](ms_ad_setup_trust.md) + [ # Adding IP routes when using public IP addresses with your AWS Managed Microsoft AD ](ms_ad_adding_routes.md) + [ # Tutorial: Create a trust relationship between your AWS Managed Microsoft AD and your self-managed Active Directory domain ](ms_ad_tutorial_setup_trust.md) + [ # Tutorial: Create a trust relationship between two AWS Managed Microsoft AD domains ](ms_ad_tutorial_setup_trust_between_2_managed_ad_domains.md) # Creating a trust relationship between your AWS Managed Microsoft AD and self-managed AD Creating a trust relationship You can configure one and two-way external and forest trust relationships between your AWS Directory Service for Microsoft Active Directory and self-managed (on-premises) directories, as well as between multiple AWS Managed Microsoft AD directories in the AWS cloud. AWS Managed Microsoft AD supports all three trust relationship directions: Incoming, Outgoing and Two-way (Bi-directional). For more information about trust relationship, see [ Everything you wanted to know about trusts with AWS Managed Microsoft AD](https://aws.amazon.com/blogs//security/everything-you-wanted-to-know-about-trusts-with-aws-managed-microsoft-ad/). **Note** When setting up trust relationships, you must ensure that your self-managed directory is and remains compatible with Directory Services. For more information on your responsibilities, please see our [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model). AWS Managed Microsoft AD supports both external and forest trusts. To walk through an example scenario showing how to create a forest trust, see [Tutorial: Create a trust relationship between your AWS Managed Microsoft AD and your self-managed Active Directory domain](ms_ad_tutorial_setup_trust.md). A two-way trust is required for AWS Enterprise Apps such as Amazon Chime, Amazon Connect, Quick, AWS IAM Identity Center, WorkDocs, Amazon WorkMail, Amazon WorkSpaces, and the AWS Management Console. AWS Managed Microsoft AD must be able to query the users and groups in your self-managed Active Directory. You can enable selective authentication so only the AWS application specific service account can query your self-managed Active Directory. For more information, see [Enhance security of your AWS app integration with AWS Managed Microsoft AD](https://aws.amazon.com//blogs/modernizing-with-aws/enhance-security-of-your-aws-app-integration-with-aws-managed-microsoft-ad/). Amazon EC2, Amazon RDS, and Amazon FSx will work with either a one-way or two-way trust. ## Prerequisites Creating the trust requires only a few steps, but you must first complete several prerequisite steps prior to setting up the trust. **Note** AWS Managed Microsoft AD does not support trust with [Single Label Domains](https://support.microsoft.com/en-us/help/2269810/microsoft-support-for-single-label-domains). ### Connect to VPC If you are creating a trust relationship with your self-managed directory, you must first connect your self-managed network to the Amazon VPC containing your AWS Managed Microsoft AD. The firewall for your self-managed and AWS Managed Microsoft AD networks must have the network ports open that are listed in [Windows Server 2008 and later versions ](https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts#windows-server-2008-and-later-versions) in Microsoft documentation. To use your NetBIOS name instead of your full domain name for authentication with your AWS applictions like Amazon WorkDocs or Amazon Quick, you must allow port 9389. For more information about Active Directory ports and protocols, see [Service overview and network port requirements for Windows](https://learn.microsoft.com/en-US/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements#system-services-ports) in Microsoft documentation. These are the minimum ports that are needed to be able to connect to your directory. Your specific configuration may require additional ports be open. ### Configure your VPC The VPC that contains your AWS Managed Microsoft AD must have the appropriate outbound and inbound rules. **To configure your VPC outbound rules** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/), on the **Directory Details** page, note your AWS Managed Microsoft AD directory ID. 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Choose **Security Groups**. 1. Search for your AWS Managed Microsoft AD directory ID. In the search results, select the item with the description "AWS created security group for *directory ID* directory controllers". **Note** The selected security group is a security group that is automatically created when you initially create your directory. 1. Go to the **Outbound Rules** tab of that security group. Select **Edit**, then **Add another rule**. For the new rule, enter the following values: + **Type**: All Traffic + **Protocol**: All + **Destination** determines the traffic that can leave your domain controllers and where it can go in your self-managed network. Specify a single IP address or an IP address range in CIDR notation (for example, 203.0.113.5/32). You can also specify the name or ID of another security group in the same Region. For more information, see [Understand your directory's AWS security group configuration and use](ms_ad_best_practices.md#understandsecuritygroup). 1. Select **Save**. ### Enable Kerberos pre-authentication Your user accounts must have Kerberos pre-authentication enabled. For more information about this setting, review [Preauthentication](http://technet.microsoft.com/en-us/library/cc961961.aspx) on Microsoft TechNet. ### Configure DNS conditional forwarders on your self-managed domain You must set up DNS conditional forwarders on your self-managed domain. Refer to [Assign a Conditional Forwarder for a Domain Name](https://technet.microsoft.com/en-us/library/cc794735.aspx) on Microsoft TechNet for details on conditional forwarders. To perform the following steps, you must have access to following Windows Server tools for your self-managed domain: + AD DS and AD LDS Tools + DNS **To configure conditional forwarders on your self-managed domain** 1. First you must get some information about your AWS Managed Microsoft AD. Sign into the AWS Management Console and open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. In the navigation pane, select **Directories**. 1. Choose the directory ID of your AWS Managed Microsoft AD. 1. Take note of the fully qualified domain name (FQDN) and the DNS addresses of your directory. 1. Now, return to your self-managed domain controller. Open Server Manager. 1. On the **Tools** menu, choose **DNS**. 1. In the console tree, expand the DNS server of the domain for which you are setting up the trust. 1. In the console tree, choose **Conditional Forwarders**. 1. On the **Action** menu, choose **New conditional forwarder**. 1. In **DNS domain**, type the fully qualified domain name (FQDN) of your AWS Managed Microsoft AD, which you noted earlier. 1. Choose **IP addresses of the primary servers** and type the DNS addresses of your AWS Managed Microsoft AD directory, which you noted earlier. After entering the DNS addresses, you might get a "timeout" or "unable to resolve" error. You can generally ignore these errors. 1. Select **Store this conditional forwarder in Active Directory and replicate as follows: All DNS servers in this domain**. Choose **OK**. ### Trust relationship password If you are creating a trust relationship with an existing domain, set up the trust relationship on that domain using Windows Server Administration tools. As you do so, note the trust password that you use. You will need to use this same password when setting up the trust relationship on the AWS Managed Microsoft AD. For more information, see [Managing Trusts](https://technet.microsoft.com/en-us/library/cc771568.aspx) on Microsoft TechNet. You are now ready to create the trust relationship on your AWS Managed Microsoft AD. ### NetBIOS and Domain Names The NetBIOS and domain names must be unique and cannot be the same to establish a trust relationship. ## Create, verify, or delete a trust relationship Create the trust relationship **Note** Trust relationships is a global feature of AWS Managed Microsoft AD. If you are using [Configure Multi-Region replication for AWS Managed Microsoft AD](ms_ad_configure_multi_region_replication.md), the following procedures must be performed in the [Primary Region](multi-region-global-primary-additional.md#multi-region-primary). The changes will be applied across all replicated Regions automatically. For more information, see [Global vs Regional features](multi-region-global-region-features.md). **To create a trust relationship with your AWS Managed Microsoft AD** 1. Open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. On the **Directories** page, choose your AWS Managed Microsoft AD ID. 1. On the **Directory details** page, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the primary Region, 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 **Trust relationships** section, choose **Actions**, and then select **Add trust relationship**. 1. On the **Add a trust relationship** page, provide the required information, including the trust type, fully qualified domain name (FQDN) of your trusted domain, the trust password and the trust direction. 1. (Optional) If you want to allow only authorized users to access resources in your AWS Managed Microsoft AD directory, you can optionally choose the **Selective authentication** check box. For general information about selective authentication, see [Security Considerations for Trusts](https://technet.microsoft.com/pt-pt/library/cc755321(v=ws.10).aspx) on Microsoft TechNet. 1. For **Conditional forwarder**, type the IP address of your self-managed DNS server. If you have previously created conditional forwarders, you can type the FQDN of your self-managed domain instead of a DNS IP address. 1. (Optional) Choose **Add another IP address** and type the IP address of an additional self-managed DNS server. You can repeat this step for each applicable DNS server address for a total of four addresses. 1. Choose **Add**. 1. If the DNS server or the network for your self-managed domain uses a public (non-RFC 1918) IP address space, go to the **IP routing** section, choose **Actions**, and then choose **Add route**. Type the IP address block of your DNS server or self-managed network using CIDR format, for example 203.0.113.0/24. This step is not necessary if both your DNS server and your self-managed network are using RFC 1918 IP address spaces. **Note** When using a public IP address space, make sure that you do not use any of the [AWS IP address ranges](https://ip-ranges.amazonaws.com/ip-ranges.json) as these cannot be used. 1. (Optional) We recommend that while you are on the **Add routes** page that you also select **Add routes to the security group for this directory's VPC**. This will configure the security groups as detailed above in the "Configure your VPC." These security rules impact an internal network interface that is not exposed publicly. If this option is not available, you will instead see a message indicating that you have already customized your security groups. You must set up the trust relationship on both domains. The relationships must be complementary. For example, if you create an outgoing trust on one domain, you must create an incoming trust on the other. If you are creating a trust relationship with an existing domain, set up the trust relationship on that domain using Windows Server Administration tools. You can create multiple trusts between your AWS Managed Microsoft AD and various Active Directory domains. However, only one trust relationship per pair can exist at a time. For example, if you have an existing, one-way trust in the "Incoming direction" and you then want to set up another trust relationship in the "Outgoing direction," you will need to delete the existing trust relationship, and create a new "Two-way" trust. **To verify an outgoing trust relationship** 1. Open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. On the **Directories** page, choose your AWS Managed Microsoft AD ID. 1. On the **Directory details** page, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the primary Region, 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 **Trust relationships** section, select the trust you want to verify, choose **Actions**, and then select **Verify trust relationship**. This process verifies only the outgoing direction of a two-way trust. AWS does not support verification of an incoming trusts. For more information on how to verify a trust to or from your self-managed Active Directory, refer to [Verify a Trust](https://technet.microsoft.com/en-us/library/cc753821.aspx) on Microsoft TechNet. **To delete an existing trust relationship** 1. Open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. On the **Directories** page, choose your AWS Managed Microsoft AD ID. 1. On the **Directory details** page, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the primary Region, 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 **Trust relationships** section, select the trust you want to delete, choose **Actions**, and then select **Delete trust relationship**. 1. Choose **Delete**. # Adding IP routes when using public IP addresses with your AWS Managed Microsoft AD Adding IP routes You can use AWS Directory Service for Microsoft Active Directory to take advantage of many powerful Active Directory features, including establishing trusts with other directories. However, if the DNS servers for the networks of the other directories use public (non-RFC 1918) IP addresses, you must specify those IP addresses as part of configuring the trust. Instructions for doing this can be found in [Creating a trust relationship between your AWS Managed Microsoft AD and self-managed AD](ms_ad_setup_trust.md). Similarly, you must also enter the IP address information when routing traffic from your AWS Managed Microsoft AD on AWS to a peer AWS VPC, if the VPC uses public IP ranges. When you add the IP addresses as described in [Creating a trust relationship between your AWS Managed Microsoft AD and self-managed AD](ms_ad_setup_trust.md), you have the option of selecting **Add routes to the security group for this directory's VPC**. This option should be selected unless you have previously customized your [security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) to allow the necessary traffic as shown below. For more information, see [Understand your directory's AWS security group configuration and use](ms_ad_best_practices.md#understandsecuritygroup). # Tutorial: Create a trust relationship between your AWS Managed Microsoft AD and your self-managed Active Directory domain This tutorial walks you through all the steps necessary to set up a trust relationship between AWS Directory Service for Microsoft Active Directory and your self-managed (on-premises) Microsoft Active Directory. Although creating the trust requires only a few steps, you must first complete the following prerequisite steps. **Topics** + [ # Prerequisites ](before_you_start.md) + [ # Step 1: Prepare your self-managed AD Domain ](ms_ad_tutorial_setup_trust_prepare_onprem.md) + [ # Step 2: Prepare your AWS Managed Microsoft AD ](ms_ad_tutorial_setup_trust_prepare_mad.md) + [ # Step 3: Create the trust relationship ](ms_ad_tutorial_setup_trust_create.md) **See Also** [Creating a trust relationship between your AWS Managed Microsoft AD and self-managed AD](ms_ad_setup_trust.md) # Prerequisites This tutorial assumes you already have the following: **Note** AWS Managed Microsoft AD does not support trust with [Single label domains](https://support.microsoft.com/en-us/help/2269810/microsoft-support-for-single-label-domains). + An AWS Managed Microsoft AD directory created on AWS. If you need help doing this, see [Getting started with AWS Managed Microsoft AD](ms_ad_getting_started.md). + An EC2 instance running Windows added to that AWS Managed Microsoft AD. If you need help doing this, see [Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD Active Directory](launching_instance.md). **Important** The admin account for your AWS Managed Microsoft AD must have administrative access to this instance. + The following Windows Server tools installed on that instance: + AD DS and AD LDS Tools + DNS If you need help doing this, see [Installing Active Directory Administration Tools for AWS Managed Microsoft AD](ms_ad_install_ad_tools.md). + A self-managed (on-premises) Microsoft Active Directory You must have administrative access to this directory. The same Windows Server tools as listed above must also be available for this directory. + An active connection between your self-managed network and the VPC containing your AWS Managed Microsoft AD. If you need help doing this, see [Amazon Virtual Private Cloud Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-vpc-connectivity-options.pdf). + A correctly set local security policy. Check `Local Security Policy > Local Policies > Security Options > Network access: Named Pipes that can be accessed anonymously` and ensure that it contains at least the following three named pipes: + netlogon + samr + lsarpc + The NetBIOS and domain names must be unique and cannot be the same to establish a trust relationship For more information about the prerequisites for creating a trust relationship, see [Creating a trust relationship between your AWS Managed Microsoft AD and self-managed AD](ms_ad_setup_trust.md). ## Tutorial configuration For this tutorial, we've already created a AWS Managed Microsoft AD and a self-managed domain. The self-managed network is connected to the AWS Managed Microsoft AD's VPC. Following are the properties of the two directories: ### AWS Managed Microsoft AD running on AWS + Domain name (FQDN): MyManagedAD.example.com + NetBIOS name: MyManagedAD + DNS Addresses: 10.0.10.246, 10.0.20.121 + VPC CIDR: 10.0.0.0/16 The AWS Managed Microsoft AD resides in VPC ID: vpc-12345678. ### Self-managed or AWS Managed Microsoft AD domain + Domain name (FQDN): corp.example.com + NetBIOS name: CORP + DNS Addresses: 172.16.10.153 + Self-managed CIDR: 172.16.0.0/16 **Next Step** [Step 1: Prepare your self-managed AD Domain](ms_ad_tutorial_setup_trust_prepare_onprem.md) # Step 1: Prepare your self-managed AD Domain First you need to complete several prerequisite steps on your self-managed (on-premises) domain. ## Configure your self-managed firewall You must configure your self-managed firewall so that the following ports are open to the CIDRs for all subnets used by the VPC that contains your AWS Managed Microsoft AD. In this tutorial, we allow both incoming and outgoing traffic from 10.0.0.0/16 (the CIDR block of our AWS Managed Microsoft AD's VPC) on the following ports: + TCP/UDP 53 - DNS + TCP/UDP 88 - Kerberos authentication + TCP/UDP 389 - Lightweight Directory Access Protocol (LDAP) + TCP 445 - Server Message Block (SMB) + TCP 9389 - Active Directory Web Services (ADWS) (*Optional* - This port needs to be open if you want to use your NetBIOS name instead of your full domain name for authentication with AWS applications like Amazon WorkDocs or Amazon Quick.) **Note** SMBv1 is no longer supported. These are the minimum ports that are needed to connect the VPC to the self-managed directory. Your specific configuration may require additional ports be open. ## Ensure that Kerberos pre-authentication is enabled User accounts in both directories must have Kerberos preauthentication enabled. This is the default, but let's check the properties of any random user to make sure nothing has changed. **To view user's Kerberos settings** 1. On your self-managed domain controller, open Server Manager. 1. On the **Tools** menu, choose **Active Directory Users and Computers**. 1. Choose the **Users** folder and open the context (right-click) menu. Select any random user account listed in the right pane. Choose **Properties**. 1. Choose the **Account** tab. In the **Account options** list, scroll down and ensure that **Do not require Kerberos preauthentication** is *not* checked. ![\[Corp User Properties dialog box with the account option do not require Kerberos preauthentication highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/kerberos_enabled.png) ## Configure DNS conditional forwarders for your self-managed domain You must set up DNS conditional forwarders on each domain. Before doing this on your self-managed domain, you will first get some information about your AWS Managed Microsoft AD. **To configure conditional forwarders on your self-managed domain** 1. Sign into the AWS Management Console and open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. In the navigation pane, select **Directories**. 1. Choose the directory ID of your AWS Managed Microsoft AD. 1. On the **Details** page, take note of the values in **Directory name** and the **DNS address** of your directory. 1. Now, return to your self-managed domain controller. Open Server Manager. 1. On the **Tools** menu, choose **DNS**. 1. In the console tree, expand the DNS server of the domain for which you are setting up the trust. Our server is WIN-5V70CN7VJ0.corp.example.com. 1. In the console tree, choose **Conditional Forwarders**. 1. On the **Action** menu, choose **New conditional forwarder**. 1. In **DNS domain**, type the fully qualified domain name (FQDN) of your AWS Managed Microsoft AD, which you noted earlier. In this example, the FQDN is MyManagedAD.example.com. 1. Choose **IP addresses of the primary servers** and type the DNS addresses of your AWS Managed Microsoft AD directory, which you noted earlier. In this example those are: 10.0.10.246, 10.0.20.121 After entering the DNS addresses, you might get a "timeout" or "unable to resolve" error. You can generally ignore these errors. ![\[New Conditional Forwarder dialog box with the IP addresses of the DNS servers highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/new_cond_forwarder_diag_box_2.png) 1. Select **Store this conditional forwarder in Active Directory, and replicate it as follows**. 1. Select **All DNS servers in this domain**, and then choose **OK**. **Next Step** [Step 2: Prepare your AWS Managed Microsoft AD](ms_ad_tutorial_setup_trust_prepare_mad.md) # Step 2: Prepare your AWS Managed Microsoft AD Now let's get your AWS Managed Microsoft AD ready for the trust relationship. Many of the following steps are almost identical to what you just completed for your self-managed domain. This time, however, you are working with your AWS Managed Microsoft AD. ## Configure your VPC subnets and security groups You must allow traffic from your self-managed network to the VPC containing your AWS Managed Microsoft AD. To do this, you will need to make sure that the ACLs associated with the subnets used to deploy your AWS Managed Microsoft AD and the security group rules configured on your domain controllers, both allow the requisite traffic to support trusts. Port requirements vary based on the version of Windows Server used by your domain controllers and the services or applications that will be leveraging the trust. For the purposes of this tutorial, you will need to open the following ports: **Inbound** + TCP/UDP 53 - DNS + TCP/UDP 88 - Kerberos authentication + UDP 123 - NTP + TCP 135 - RPC + TCP/UDP 389 - LDAP + TCP/UDP 445 - SMB + TCP/UDP 464 - Kerberos authentication + TCP 636 - LDAPS (LDAP over TLS/SSL) + TCP 3268-3269 - Global Catalog + TCP/UDP 49152-65535 - Ephemeral ports for RPC **Note** SMBv1 is no longer supported. **Outbound** + ALL **Note** These are the minimum ports that are needed to be able to connect the VPC and self-managed directory. Your specific configuration may require additional ports be open. **To configure your AWS Managed Microsoft AD domain controller outbound and inbound rules** 1. Return to the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). In the list of directories, take note the directory ID for your AWS Managed Microsoft AD directory. 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Security Groups**. 1. Use the search box to search for your AWS Managed Microsoft AD directory ID. In the search results, select the Security Group with the description **AWS created security group for *yourdirectoryID* directory controllers**. ![\[In the Amazon VPC Console, search results for the security group for the directory controllers are highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/security-group-search.png) 1. Go to the **Outbound Rules** tab for that security group. Choose **Edit outbound rules**, and then **Add rule**. For the new rule, enter the following values: + **Type**: ALL Traffic + **Protocol**: ALL + **Destination** determines the traffic that can leave your domain controllers and where it can go. Specify a single IP address or an IP address range in CIDR notation (for example, 203.0.113.5/32). You can also specify the name or ID of another security group in the same Region. For more information, see [Understand your directory's AWS security group configuration and use](ms_ad_best_practices.md#understandsecuritygroup). 1. Select **Save Rule**. ![\[In the Amazon VPC Console, edit the outbound rules for the directory controller security groups.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/editing-and-saving-rule.png) ## Ensure that Kerberos pre-authentication is enabled Now you want to confirm that users in your AWS Managed Microsoft AD also have Kerberos pre-authentication enabled. This is the same process you completed for your self-managed directory. This is the default, but let's check to make sure nothing has changed. **To view user kerberos settings** 1. Log in to an instance that is a member of your AWS Managed Microsoft AD directory using either the [AWS Managed Microsoft AD Administrator account and group permissions](ms_ad_getting_started_admin_account.md) for the domain or an account that has been delegated permissions to manage users in the domain. 1. If they are not already installed, install the Active Directory Users and Computers tool and the DNS tool. Learn how to install these tools in [Installing Active Directory Administration Tools for AWS Managed Microsoft AD](ms_ad_install_ad_tools.md). 1. Open Server Manager. On the **Tools** menu, choose **Active Directory Users and Computers**. 1. Choose the **Users** folder in your domain. Note that this is the **Users** folder under your NetBIOS name, not the **Users ** folder under the fully qualified domain name (FQDN). ![\[In the Active Directory Users and Computers dialog box, the Users folder is highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/correct_users_folder.png) 1. In the list of users, right-click on a user, and then choose **Properties**. 1. Choose the **Account** tab. In the **Account options** list, ensure that **Do not require Kerberos preauthentication** is *not* checked. **Next Step** [Step 3: Create the trust relationship](ms_ad_tutorial_setup_trust_create.md) # Step 3: Create the trust relationship Now that the preparation work is complete, the final steps are to create the trusts. First you create the trust on your self-managed domain, and then finally on your AWS Managed Microsoft AD. If you have any issues during the trust creation process, see [Trust creation status reasons](ms_ad_troubleshooting_trusts.md) for assistance. ## Configure the trust in your self-managed Active Directory In this tutorial, you configure a two-way forest trust. However, if you create a one-way forest trust, be aware that the trust directions on each of your domains must be complementary. For example, if you create a one-way, outgoing trust on your self-managed domain, you need to create a one-way, incoming trust on your AWS Managed Microsoft AD. **Note** AWS Managed Microsoft AD also supports external trusts. However, for the purposes of this tutorial, you will create a two-way forest trust. **To configure the trust in your self-managed Active Directory** 1. Open Server Manager and on the **Tools** menu, choose **Active Directory Domains and Trusts**. 1. Open the context (right-click) menu of your domain and choose **Properties**. 1. Choose the **Trusts** tab and choose **New trust**. Type the name of your AWS Managed Microsoft AD and choose **Next**. 1. Choose **Forest trust**. Choose **Next**. 1. Choose **Two-way**. Choose **Next**. 1. Choose **This domain only**. Choose **Next**. 1. Choose **Forest-wide authentication**. Choose **Next**. 1. Type a **Trust password**. Make sure to remember this password as you will need it when setting up the trust for your AWS Managed Microsoft AD. 1. In the next dialog box, confirm your settings and choose **Next**. Confirm that the trust was created successfully and again choose **Next**. 1. Choose **No, do not confirm the outgoing trust**. Choose **Next**. 1. Choose **No, do not confirm the incoming trust**. Choose **Next**. ## Configure the trust in your AWS Managed Microsoft AD directory Finally, you configure the forest trust relationship with your AWS Managed Microsoft AD directory. Because you created a two-way forest trust on the self-managed domain, you also create a two-way trust using your AWS Managed Microsoft AD directory. **Note** Trust relationships is a global feature of AWS Managed Microsoft AD. If you are using [Configure Multi-Region replication for AWS Managed Microsoft AD](ms_ad_configure_multi_region_replication.md), the following procedures must be performed in the [Primary Region](multi-region-global-primary-additional.md#multi-region-primary). The changes will be applied across all replicated Regions automatically. For more information, see [Global vs Regional features](multi-region-global-region-features.md). **To configure the trust in your AWS Managed Microsoft AD directory** 1. Return to the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. On the **Directories** page, choose your AWS Managed Microsoft AD ID. 1. On the **Directory details** page, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the primary Region, 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 **Trust relationships** section, choose **Actions**, and then select **Add trust relationship**. 1. On the **Add a trust relationship** page, specify the Trust type. In this case, we choose **Forest trust**. Type the FQDN of your self-managed domain (in this tutorial **corp.example.com**). Type the same trust password that you used when creating the trust on your self-managed domain. Specify the direction. In this case, we choose **Two-way**. 1. In the **Conditional forwarder** field, enter the IP address of your self-managed DNS server. In this example, enter 172.16.10.153. 1. (Optional) Choose **Add another IP address** and enter a second IP address for your self-managed DNS server. You can specify up to a total of four DNS servers. 1. Choose **Add**. Congratulations. You now have a trust relationship between your self-managed domain (corp.example.com) and your AWS Managed Microsoft AD (MyManagedAD.example.com). Only one relationship can be set up between these two domains. If for example, you want to change the trust direction to one-way, you would first need to delete this existing trust relationship and create a new one. For more information, including instructions about verifying or deleting trusts, see [Creating a trust relationship between your AWS Managed Microsoft AD and self-managed AD](ms_ad_setup_trust.md). # Tutorial: Create a trust relationship between two AWS Managed Microsoft AD domains Tutorial: Create a trust relationship between AWS Managed Microsoft AD domains This tutorial walks you through all the steps necessary to set up a trust relationship between two AWS Directory Service for Microsoft Active Directory domains. **Topics** + [ # Step 1: Prepare your AWS Managed Microsoft AD ](ms_ad_tutorial_setup_trust_prepare_mad_between_2_managed_ad_domains.md) + [ # Step 2: Create the trust relationship with another AWS Managed Microsoft AD domain ](ms_ad_tutorial_setup_trust_create_between_2_managed_ad_domains.md) **See Also** [Creating a trust relationship between your AWS Managed Microsoft AD and self-managed AD](ms_ad_setup_trust.md) # Step 1: Prepare your AWS Managed Microsoft AD In this section, you will get your AWS Managed Microsoft AD ready for the trust relationship with another AWS Managed Microsoft AD. Many of the following steps are almost identical to what you completed in [Tutorial: Create a trust relationship between your AWS Managed Microsoft AD and your self-managed Active Directory domain](ms_ad_tutorial_setup_trust.md). This time, however, you are configuring your AWS Managed Microsoft AD environments to work with each other. ## Configure your VPC subnets and security groups You must allow traffic from one AWS Managed Microsoft AD network to the VPC containing your other AWS Managed Microsoft AD. To do this, you will need to make sure that the ACLs associated with the subnets used to deploy your AWS Managed Microsoft AD and the security group rules configured on your domain controllers, both allow the requisite traffic to support trusts. Port requirements vary based on the version of Windows Server used by your domain controllers and the services or applications that will be leveraging the trust. For the purposes of this tutorial, you will need to open the following ports: **Inbound** + TCP/UDP 53 - DNS + TCP/UDP 88 - Kerberos authentication + UDP 123 - NTP + TCP 135 - RPC + TCP/UDP 389 - LDAP + TCP/UDP 445 - SMB **Note** SMBv1 is no longer supported. + TCP/UDP 464 - Kerberos authentication + TCP 636 - LDAPS (LDAP over TLS/SSL) + TCP 3268-3269 - Global Catalog + TCP/UDP 1024-65535 - Ephemeral ports for RPC **Outbound** + ALL **Note** These are the minimum ports that are needed to be able to connect the VPCs from both AWS Managed Microsoft AD's. Your specific configuration may require additional ports be open. For more information, see [How to configure a firewall for Active Directory domains and trusts](https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts) on Microsoft's website. **To configure your AWS Managed Microsoft AD domain controller outbound rules** **Note** Repeat steps 1-6 below for each directory. 1. Go to the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). In the list of directories, take note the directory ID for your AWS Managed Microsoft AD directory. 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Security Groups**. 1. Use the search box to search for your AWS Managed Microsoft AD directory ID. In the search results, select the item with the description **AWS created security group for *yourdirectoryID* directory controllers**. ![\[In the Amazon VPC Console, search results for the security group for the directory controllers are highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/security-group-search.png) 1. Go to the **Outbound Rules** tab for that security group. Choose **Edit**, and then **Add another rule**. For the new rule, enter the following values: + **Type**: ALL Traffic + **Protocol**: ALL + **Destination** determines the traffic that can leave your domain controllers and where it can go. Specify a single IP address or an IP address range in CIDR notation (for example, 203.0.113.5/32). You can also specify the name or ID of another security group in the same Region. For more information, see [Understand your directory's AWS security group configuration and use](ms_ad_best_practices.md#understandsecuritygroup). 1. Select **Save**. ![\[In the Amazon VPC Console, edit the outbound rules for the directory controller security groups.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/editing-and-saving-rule.png) ## Ensure that Kerberos pre-authentication is enabled Now you want to confirm that users in your AWS Managed Microsoft AD also have Kerberos pre-authentication enabled. This is the same process you completed for your on-premises directory. This is the default, but let's check to make sure nothing has changed. **To view user kerberos settings** 1. Log in to an instance that is a member of your AWS Managed Microsoft AD directory using either the [AWS Managed Microsoft AD Administrator account and group permissions](ms_ad_getting_started_admin_account.md) for the domain or an account that has been delegated permissions to manage users in the domain. 1. If they are not already installed, install the Active Directory Users and Computers tool and the DNS tool. Learn how to install these tools in [Installing Active Directory Administration Tools for AWS Managed Microsoft AD](ms_ad_install_ad_tools.md). 1. Open Server Manager. On the **Tools** menu, choose **Active Directory Users and Computers**. 1. Choose the **Users** folder in your domain. Note that this is the **Users** folder under your NetBIOS name, not the **Users ** folder under the fully qualified domain name (FQDN). ![\[In the Active Directory Users and Computers dialog box, the Users folder is highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/correct_users_folder.png) 1. In the list of users, right-click on a user, and then choose **Properties**. 1. Choose the **Account** tab. In the **Account options** list, ensure that **Do not require Kerberos preauthentication** is *not* checked. **Next Step** [Step 2: Create the trust relationship with another AWS Managed Microsoft AD domain](ms_ad_tutorial_setup_trust_create_between_2_managed_ad_domains.md) # Step 2: Create the trust relationship with another AWS Managed Microsoft AD domain Now that the preparation work is complete, the final steps are to create the trusts between your two AWS Managed Microsoft AD domains. If you have any issues during the trust creation process, see [Trust creation status reasons](ms_ad_troubleshooting_trusts.md) for assistance. ## Configure the trust in your first AWS Managed Microsoft AD domain In this tutorial, you configure a two-way forest trust. However, if you create a one-way forest trust, be aware that the trust directions on each of your domains must be complementary. For example, if you create a one-way, outgoing trust on this first domain, you need to create a one-way, incoming trust on your second AWS Managed Microsoft AD domain. **Note** AWS Managed Microsoft AD also supports external trusts. However, for the purposes of this tutorial, you will create a two-way forest trust. **To configure the trust in your first AWS Managed Microsoft AD domain** 1. Open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. On the **Directories** page, choose your first AWS Managed Microsoft AD ID. 1. On the **Directory details** page, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the primary Region, 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 **Trust relationships** section, choose **Actions**, and then select **Add trust relationship**. 1. On the **Add a trust relationship** page, Type the FQDN of your second AWS Managed Microsoft AD domain. Make sure to remember this password as you will need it when setting up the trust for your second AWS Managed Microsoft AD. Specify the direction. In this case, choose **Two-way**. 1. In the **Conditional forwarder** field, enter the IP address of your second AWS Managed Microsoft AD DNS server. 1. (Optional) Choose **Add another IP address** and enter a second IP address for your second AWS Managed Microsoft AD DNS server. You can specify up to a total of four DNS servers. 1. Choose **Add**. The trust will fail at this point which is expected until we create the other side of the trust. ## Configure the trust in your second AWS Managed Microsoft AD domain Now, you configure the forest trust relationship with your second AWS Managed Microsoft AD directory. Because you created a two-way forest trust on the first AWS Managed Microsoft AD domain, you also create a two-way trust using this AWS Managed Microsoft AD domain. **To configure the trust in your second AWS Managed Microsoft AD domain** 1. Return to the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. On the **Directories** page, choose your second AWS Managed Microsoft AD ID. 1. On the **Directory details** page, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the primary Region, 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 **Trust relationships** section, choose **Actions**, and then select **Add trust relationship**. 1. On the **Add a trust relationship** page, Type the FQDN of your first AWS Managed Microsoft AD domain. Type the same trust password that you used when creating the trust on your on-premises domain. Specify the direction. In this case, choose **Two-way**. 1. In the **Conditional forwarder** field, enter the IP address of your first AWS Managed Microsoft AD DNS server. 1. (Optional) Choose **Add another IP address** and enter a second IP address for your first AWS Managed Microsoft AD DNS server. You can specify up to a total of four DNS servers. 1. Choose **Add**. The trust should be verified shortly afterwards. 1. Now, go back to the trust you created in the first domain and verify the trust relationship again. Congratulations. You now have a trust relationship between your two AWS Managed Microsoft AD domains. Only one relationship can be set up between these two domains. If for example, you want to change the trust direction to one-way, you would first need to delete this existing trust relationship and create a new one. # Extend your AWS Managed Microsoft AD schema Extend your directory schema AWS Managed Microsoft AD uses schemas to organize and enforce how directory data is stored. The process of adding definitions to the schema is referred to as "extending the schema." Schema extensions make it possible for you to modify the schema of your AWS Managed Microsoft AD directory using a valid LDAP Data Interchange Format (LDIF) file. For more information about AD schemas and how to extend your schema, see the topics listed below. ## When to extend your AWS Managed Microsoft AD schema You can extend your AWS Managed Microsoft AD schema by adding new object classes and attributes. For example, you might do this if you have an application that requires changes to your schema in order to support single sign-on capabilities. You can also use schema extensions to enable support for applications that rely on specific Active Directory object classes and attributes. This can be especially useful in the case where you need to migrate corporate applications that are dependent on AWS Managed Microsoft AD, to the AWS cloud. Each attribute or class that is added to an existing Active Directory schema must be defined with a unique ID. That way when companies add extensions to the schema, they can be guaranteed to be unique and not to conflict with each other. These IDs are referred to as AD Object Identifiers (OIDs) and are stored in AWS Managed Microsoft AD. To get started, see [Tutorial: Extending your AWS Managed Microsoft AD schema](ms_ad_tutorial_extend_schema.md). ### Related topics + [Extend your AWS Managed Microsoft AD schema](#ms_ad_schema_extensions) + [Schema elements](ms_ad_key_concepts.md#ms_ad_schema_elements) **Topics** + [ ## When to extend your AWS Managed Microsoft AD schema ](#ms_ad_schema_when_to_extend) + [ # Tutorial: Extending your AWS Managed Microsoft AD schema ](ms_ad_tutorial_extend_schema.md) # Tutorial: Extending your AWS Managed Microsoft AD schema In this tutorial, you will learn how to extend the schema for your AWS Directory Service for Microsoft Active Directory directory, also known as AWS Managed Microsoft AD, by adding unique *attributes* and *classes* that meet your specific requirements. AWS Managed Microsoft AD schema extensions can only be uploaded and applied using a valid LDIF (Lightweight Directory Interchange Format) script file. Attributes (attributeSchema) define the fields in the database while classes (classSchema) define the tables in the database. For example, all of the user objects in Active Directory are defined by the schema class *User* while the individual properties of a user, such as email address or phone number, are each defined by an attribute. If you wanted to add a new property, such as Shoe-Size, you would define a new attribute, which would be of type *integer*. You could also define lower and upper limits like 1 to 20. Once the Shoe-Size attributeSchema object has been created, you would then alter the *User* classSchema object to contain that attribute. Attributes can be linked to multiple classes. Shoe-Size could also be added to the *Contact* class for example. For more information about Active Directory schemas, see [When to extend your AWS Managed Microsoft AD schema](ms_ad_schema_extensions.md#ms_ad_schema_when_to_extend). This workflow has three basic steps. ![\[Diagram showing the steps for the tutorial: 1 create a LDIF file, 2 import the LDIF file, and 3 verify schema changes.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/tutorialextendadschema.png) **[Step 1: Create your LDIF file](create.md)** First, you create an LDIF file and define the new attributes and any classes that the attributes should be added to. You use this file for the next phase of the workflow. **[Step 2: Import your LDIF file](import.md)** In this step, you use the AWS Directory Service console to import the LDIF file to your Microsoft Active Directory environment. **[Step 3: Verify if the schema extension was successful](verify.md)** Finally, as an administrator, you use an EC2 instance to verify that the new extensions appear in the Active Directory Schema Snap-in. # Step 1: Create your LDIF file An LDIF file is a standard plain text data interchange format for representing [LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) (Lightweight Directory Access Protocol) directory content and update requests. LDIF conveys directory content as a set of records, one record for each object (or entry). It also represents update requests, such as Add, Modify, Delete, and Rename, as a set of records, one record for each update request. The AWS Directory Service imports your LDIF file with the schema changes by running the `ldifde.exe` application on your AWS Managed Microsoft AD directory. Therefore, you will find it helpful to understand the LDIF script syntax. For more information, see [LDIF Scripts](https://msdn.microsoft.com/en-us/library/ms677268(v=vs.85).aspx). Several third-party LDIF tools can extract, clean-up, and update your schema updates. Regardless of which tool you use, it is important to understand that all identifiers used in your LDIF file must be unique. We highly recommend that you review the following concepts and tips prior to creating your LDIF file. + **Schema elements** – Learn about schema elements such as attributes, classes, object IDs, and linked attributes. For more information, see [Schema elements](ms_ad_key_concepts.md#ms_ad_schema_elements). + **Sequence of items** – Make sure that the order in which the items in your LDIF file are laid out follow the [Directory Information Tree (DIT)](https://en.wikipedia.org/wiki/Directory_information_tree) from the top down. The general rules for sequencing in an LDIF file include the following: + Separate items with a blank line. + List child items after their parent items. + Ensure that items such as attributes or object classes exist in the schema. If they are not present, you must add them to the schema before they can be used. For example, before you can assign an attribute to a class, the attribute must be created. + **Format of the DN** – For each new instruction in the LDIF file, define the distinguished name (DN) as the first line of the instruction. The DN identifies an Active Directory object within the Active Directory object's tree and must contain the domain components for your directory. For example, the domain components for the directory in this tutorial are `DC=example,DC=com`. The DN must include the Active Directory object's common name (CN). The first CN entry represents the attribute or class name. To extend the Active Directory schema, use `CN=Schema,CN=Configuration`. Remember that you cannot modify Active Directory object content. The general DN format follows. ``` dn: CN=[attribute or class name],CN=Schema,CN=Configuration,DC=[domain_name] ``` For this tutorial, the DN for the new Shoe-Size attribute would look like: ``` dn: CN=Shoe-Size,CN=Schema,CN=Configuration,DC=example,DC=com ``` + **Warnings** – Review the warnings below before you extend your schema. + Before you extend your Active Directory schema, it is important to review Microsoft's warnings on the impact of this operation. For more information, see [What You Must Know Before Extending the Schema](https://msdn.microsoft.com/en-us/library/ms677995(v=vs.85).aspx). + You cannot delete a schema attribute or class. Therefore, if you make a mistake and don't want to restore from backup, you can only disable the object. For more information, see [Disabling Existing Classes and Attributes](https://msdn.microsoft.com/en-us/library/ms675903(v=vs.85).aspx). + Changes to defaultSecurityDescriptor are not supported. To learn more about how LDIF files are constructed and see a sample LDIF file that can be used for testing AWS Managed Microsoft AD schema extensions, see the article [How to Extend your AWS Managed Microsoft AD Directory Schema](https://aws.amazon.com/blogs/security/how-to-add-more-application-support-to-your-microsoft-ad-directory-by-extending-the-schema/) on the AWS Security Blog. **Next Step** [Step 2: Import your LDIF file](import.md) # Step 2: Import your LDIF file You can extend your schema by importing an LDIF file from either the AWS Directory Service console or by using the API. For more information about how to do this with the schema extension APIs, see the [https://docs.aws.amazon.com/directoryservice/latest/devguide/](https://docs.aws.amazon.com/directoryservice/latest/devguide/). At this time, AWS does not support external applications, such as Microsoft Exchange, to perform schema updates directly. **Important** When you make an update to your AWS Managed Microsoft AD directory schema, the operation is not reversible. In other words, once you create a new class or attribute, Active Directory doesn't allow you to remove it. However, you can disable it. If you must delete the schema changes, one option is to restore the directory from a previous snapshot. Restoring a snapshot rolls both the schema and the directory data back to a previous point, not just the schema. Note, the maximum supported age of a snapshot is 180 days. For more information, see [Useful shelf life of a system-state backup of Active Directory](https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/shelf-life-system-state-backup-ad) on the Microsoft website. Before the update process begins, AWS Managed Microsoft AD takes a snapshot to preserve the current state of your directory. **Note** Schema extensions is a global feature of AWS Managed Microsoft AD. If you are using [Configure Multi-Region replication for AWS Managed Microsoft AD](ms_ad_configure_multi_region_replication.md), the following procedures must be performed in the [Primary Region](multi-region-global-primary-additional.md#multi-region-primary). The changes will be applied across all replicated Regions automatically. For more information, see [Global vs Regional features](multi-region-global-region-features.md). **To import your LDIF file** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, select **Directories**. 1. On the **Directories** page, choose your directory ID. 1. On the **Directory details** page, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the primary Region, and then choose the **Maintenance** 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 **Maintenance** tab. 1. In the **Schema extensions** section, choose **Actions**, and then select **Upload and update schema**. 1. In the dialog box, click **Browse**, select a valid LDIF file, type a description, and then choose **Update Schema**. **Important** Extending the schema is a critical operation. Don't apply any schema update in production environment without first testing it with your application in a development or test environment. ## How is the LDIF file applied After your LDIF file has been uploaded, AWS Managed Microsoft AD takes steps to protect your directory against errors as it applies the changes in the following order. 1. **Validates the LDIF file.** Since LDIF scripts can manipulate any object in the domain, AWS Managed Microsoft AD runs checks right after you upload to help ensure that the import operation will not fail. These include checks to ensure the following: + The objects to be updated are only held in the schema container + The DC (domain controllers) part matches the name of the domain where the LDIF script is running 1. **Takes a snapshot of your directory.** You can use the snapshot to restore your directory in case you encounter any problems with your application after updating the schema. 1. **Applies the changes to a single DC.** AWS Managed Microsoft AD isolates one of your DCs and applies the updates in the LDIF file to the isolated DC. It then selects one of your DCs to be the primary schema, removes that DC from directory replication, and applies your LDIF file using `Ldifde.exe`. 1. **Replication occurs to all DCs.** AWS Managed Microsoft AD adds the isolated DC back in to replication to complete the update. While this is all happening, your directory continues to provide the Active Directory service to your applications without disruption. **Next step** [Step 3: Verify if the schema extension was successful](verify.md) # Step 3: Verify if the schema extension was successful After you have finished the import process, it is important to verify that schema updates were applied to your directory. This is especially critical before you migrate or update any application that relies on the schema update. You can do this using a variety of different LDAP tools or by writing a test tool that issues the appropriate LDAP commands. This procedure uses the Active Directory Schema Snap-in and/or PowerShell to verify that the schema updates were applied. You must run these tools from a computer that is domain joined to your AWS Managed Microsoft AD. This can be a Windows server running in your on-premises network with access to your virtual private cloud (VPC) or through a virtual private network (VPN) connection. You can also run these tools on an Amazon EC2 Windows instance (see [How to launch a new EC2 instance with seamless domain join](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-join-aws-domain.html#join-domain-console)). **To verify using the Active Directory Schema Snap-in** 1. Install the Active Directory Schema Snap-In using the instructions on the [TechNet](https://technet.microsoft.com/en-us/library/cc732110.aspx) website. 1. Open the Microsoft Management Console (MMC) and expand the **AD Schema** tree for your directory. 1. Navigate through the **Classes** and **Attributes** folders until you find the schema changes that you made earlier. **To verify using PowerShell** 1. Open a PowerShell window. 1. Use the `Get-ADObject` cmdlet as shown below to verify the schema change. For example: `get-adobject -Identity 'CN=Shoe-Size,CN=Schema,CN=Configuration,DC=example,DC=com' -Properties *` **Optional step** [Add a value to the new attribute - Optional](addvalue.md) # Add a value to the new attribute - Optional Use this optional step when you have created a new attribute and want to add a new value to the attribute in your AWS Managed Microsoft AD directory. **To add a value to an attribute** 1. Open the PowerShell command line utility and set the new attribute with the following command. In this example, we will add a new EC2InstanceID value to the attribute for a specific computer. `PS C:\> set-adcomputer -Identity computer name -add @{example-EC2InstanceID = 'EC2 instance ID'}` 1. You can validate if the EC2InstanceID value was added to the computer object by running the following command: `PS C:\> get-adcomputer -Identity computer name –Property example-EC2InstanceID` # Related resources The following resource links are located on the Microsoft website and provide related information. + [Extending the Schema (Windows)](https://msdn.microsoft.com/en-us/library/ms676900(v=vs.85).aspx) + [Active Directory Schema (Windows)](https://msdn.microsoft.com/en-us/library/ms674984(v=vs.85).aspx) + [Active Directory Schema](https://technet.microsoft.com/en-us/library/cc961581.aspx) + [Windows Administration: Extending the Active Directory Schema](https://technet.microsoft.com/en-us/magazine/a39543ba-e561-4933-b590-0878885f44f5) + [Restrictions on Schema Extension (Windows)](https://msdn.microsoft.com/en-us/library/ms677924(v=vs.85).aspx) + [Ldifde](https://technet.microsoft.com/en-us/library/cc731033(v=ws.11).aspx) # Ways to join an Amazon EC2 instance to your AWS Managed Microsoft AD Ways to join an instance to your directory You can seamlessly join an Amazon EC2 instance to your Active Directory domain when the instance is launched. For more information, see [Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD Active Directory](launching_instance.md). You can also launch an EC2 instance and join it to an Active Directory domain directly from the Directory Service console with [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html). If you need to manually join an EC2 instance to your Active Directory domain, you must launch the instance in the proper Region and security group or subnet, then join the instance to the 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 VPC and that the instance has a public IP address. **Topics** + [ # Launching a directory administration instance in your AWS Managed Microsoft AD Active Directory ](console_instance.md) + [ # Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD Active Directory ](launching_instance.md) + [ # Joining an Amazon EC2 Linux instance to your AWS Managed Microsoft AD Active Directory ](joining_linux_instance.md) + [ # Joining an Amazon EC2 Mac instance to your AWS Managed Microsoft AD Active Directory ](join_mac_instance.md) + [ # Delegating directory join privileges for AWS Managed Microsoft AD ](directory_join_privileges.md) + [ # Creating or changing a DHCP options set for AWS Managed Microsoft AD ](dhcp_options_set.md) # Launching a directory administration instance in your AWS Managed Microsoft AD Active Directory Launching a directory administration instance This procedure launches an Amazon EC2 directory administration Windows instance in the AWS Management Console using AWS Systems Manager Automation to manage your directories. You can also accomplish this by running the automation [AWS-CreateDSManagementInstance](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-create-ds-management-instance.html) in the AWS Systems Manager Automation console directly. For more information, see the following links: + [Simplifying Active Directory domain join with AWS Systems Manager](https://aws.amazon.com/blogs//modernizing-with-aws/simplifying-active-directory-domain-join-with-aws-systems-manager-2/) + [How do I use AWS Systems Manager to join a running EC2 Windows instances to my Directory Service domain?](https://repost.aws/knowledge-center/ec2-systems-manager-dx-domain) ## Prerequisites The following prerequisites are required to complete this tutorial: + You will need to set up AWS Systems Manager. For more information, see [Setting up AWS Systems Manager](https://docs.aws.amazon.com//systems-manager/latest/userguide/systems-manager-setting-up-console.html). + You will need an [IAM instance profile role](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) that allows Systems Manager and AWS Managed Microsoft AD. + For more information on Systems Manager, see [Configure instance permissions required for Systems Manager](https://docs.aws.amazon.com//systems-manager/latest/userguide/setup-instance-permissions.html). + The IAM instance role needs the following AWS managed policies so your EC2 directory administration Windows instance can domain join your AWS Managed Microsoft AD: + **`AmazonSSMManagedInstanceCore`** + **`AmazonSSMDirectoryServiceAccess`** + The VPC connected to your AWS Managed Microsoft AD needs to allow access to public Directory Service endpoints. For more information, see [Prerequisites for creating a AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_prereqs). + You must have the following permissions enabled in your account to launch a directory administration EC2 instance from the console: + `ds:DescribeDirectories` + `ec2:AuthorizeSecurityGroupIngress` + `ec2:CreateSecurityGroup` + `ec2:CreateTags` + `ec2:DeleteSecurityGroup` + `ec2:DescribeInstances` + `ec2:DescribeInstanceStatus` + `ec2:DescribeKeyPairs` + `ec2:DescribeSecurityGroups` + `ec2:DescribeVpcs` + `ec2:RunInstances` + `ec2:TerminateInstances` + `iam:AddRoleToInstanceProfile` + `iam:AttachRolePolicy` + `iam:CreateInstanceProfile` + `iam:CreateRole` + `iam:DeleteInstanceProfile` + `iam:DeleteRole` + `iam:DetachRolePolicy` + `iam:GetInstanceProfile` + `iam:GetRole` + `iam:ListAttachedRolePolicies` + `iam:ListInstanceProfiles` + `iam:ListInstanceProfilesForRole` + `iam:PassRole` + `iam:RemoveRoleFromInstanceProfile` + `iam:TagInstanceProfile` + `iam:TagRole` + `ssm:CreateDocument` + `ssm:DeleteDocument` + `ssm:DescribeInstanceInformation` + `ssm:GetAutomationExecution` + `ssm:GetParameters` + `ssm:ListCommandInvocations` + `ssm:ListCommands` + `ssm:ListDocuments` + `ssm:SendCommand` + `ssm:StartAutomationExecution` + `ssm:GetDocument` ## Launching a directory administration EC2 instance in the AWS Management Console 1. Sign in to the [Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. Under **Active Directory**, choose **Directories**. 1. Choose the **Directory ID** of the directory where you want to launch a directory administration EC2 instance. 1. On the directory page, in the top right corner, choose **Actions**. 1. In the **Actions** dropdown list, choose **Launch directory administration EC2 instance**. 1. On the **Launch directory administration EC2 instance** page, under **Input parameters**, complete the fields. 1. (Optional) You can provide a key pair for the instance. From the **Key Pair Name - *optional*** dropdown list, select a key pair. 1. (Optional) Choose **View AWS CLI command** to see an example that you use in the AWS CLI to run this automation. 1. Choose **Submit**. 1. You're taken back to the directory page. A green flashbar displays at the top of your screen to indicate that you successfully began the launch. ## Viewing directory administration EC2 instance If you haven't launched any EC2 instances for a directory, a dash (**-**) displays under **Directory administration EC2 instance**. 1. Under **Active Directory**, choose **Directories** and select the directory you want to view. 1. Under **Directory details**, under **Directory administration EC2 instance**, choose one or all of your instances to view. 1. When you choose an instance, you're routed to the EC2 **Connect to instance** page to connect a remote desktop to your instance. # Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD Active Directory Joining a Windows instance You can launch and join an Amazon EC2 Windows instance to an AWS Managed Microsoft AD. Alternatively, you can manually join an existing EC2 Windows instance to an AWS Managed Microsoft AD. ------ #### [ Seamlessly join EC2 Windows instance ] This procedure seamlessly joins an Amazon EC2 Windows instance to your AWS Managed Microsoft AD. If you need to perform seamless domain join across multiple AWS accounts, see [Tutorial: Sharing your AWS Managed Microsoft AD directory for seamless EC2 domain-join](ms_ad_tutorial_directory_sharing.md). For more information about Amazon EC2, see [What is Amazon EC2?](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html). **Prerequisites** To seamlessly domain join an EC2 instance, you will need to complete the following: + Have an AWS Managed Microsoft AD. To learn more, see [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + You'll need the following IAM permissions to seamlessly join an EC2 Windows instance: + IAM Instance Profile with the following IAM permissions: + `AmazonSSMManagedInstanceCore` + `AmazonSSMDirectoryServiceAccess` + The user seamlessly domain joining the EC2 to the AWS Managed Microsoft AD needs the following IAM permissions: + Directory Service Permissions: + `"ds:DescribeDirectories"` + `"ds:CreateComputer"` + Amazon VPC Permissions: + `"ec2:DescribeVpcs"` + `"ec2:DescribeSubnets"` + `"ec2:DescribeNetworkInterfaces"` + `"ec2:CreateNetworkInterface"` + `"ec2:AttachNetworkInterface"` + EC2 Permissions: + `"ec2:DescribeInstances"` + `"ec2:DescribeImages"` + `"ec2:DescribeInstanceTypes"` + `"ec2:RunInstances"` + `"ec2:CreateTags"` + AWS Systems Manager Permissions: + `"ssm:DescribeInstanceInformation"` + `"ssm:SendCommand"` + `"ssm:GetCommandInvocation"` + `"ssm:CreateBatchAssociation"` When your AWS Managed Microsoft AD is created, a security group is created with inbound and outbound rules. To learn more about these rules and ports, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). To seamlessly domain join an EC2 Windows instance, your VPC where you're launching your instance should allow the same ports allowed in your AWS Managed Microsoft AD security group's inbound and outbound rules. + Depending on your network security and firewall settings, you could be required to allow additional outbound traffic. This traffic would be for HTTPS (port 443) to the following endpoints: **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html) + We recommend to use a DNS server that will resolve your AWS Managed Microsoft AD domain name. To do so, you can create a DHCP option set. See [Creating or changing a DHCP options set for AWS Managed Microsoft AD](dhcp_options_set.md) for more information. + If you choose not to create a DHCP option set, then your DNS servers will be static and configured to by your AWS Managed Microsoft AD. **To seamlessly join an Amazon EC2 Windows instance** 1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation bar, choose the same AWS Region as the existing directory. 1. On the **EC2 Dashboard**, in the **Launch instance** section, choose **Launch instance**. 1. On the **Launch an instance** page, under the **Name and Tags** section, enter the name you would like to use for your Windows EC2 instance. 1. (Optional) Choose **Add additional tags** to add one or more tag key-value pairs to organize, track, or control access for this EC2 instance. 1. In the **Application and OS Image (Amazon Machine Image)** section, choose **Windows** in the **Quick Start** pane. You can change the Windows Amazon Machine Image (AMI) from the **Amazon Machine Image (AMI)** dropdown list. 1. In the **Instance type** section, choose the instance type you would like to use from **Instance type** dropdown list. 1. In the **Key pair (login)** section, you can either choose to create a new key pair or choose from an existing key pair. 1. To create a new key pair, choose **Create new key pair**. 1. Enter a name for the key pair and select an option for the **Key pair type** and **Private key file format**. 1. To save the private key in a format that can be used with OpenSSH, choose **.pem**. To save the private key in a format that can be used with PuTTY, choose **.ppk**. 1. Choose **create key pair**. 1. The private key file is automatically downloaded by your browser. Save the private key file in a safe place. **Important** This is the only chance for you to save the private key file. 1. On the **Launch an instance** page, under **Network settings** section, choose **Edit**. Choose the **VPC** that your directory was created in from the **VPC -* required*** dropdown list. 1. Choose one of the public subnets in your VPC from the **Subnet** dropdown list. The subnet you choose must have all external traffic routed to an internet gateway. If this is not the case, you won't be able to connect to the instance remotely. For more information on how to connect to a 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*. 1. Under **Auto-assign public IP**, choose **Enable**. For more information about public and private IP addressing, see [Amazon EC2 instance IP addressing](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-instance-addressing.html) in the *Amazon EC2 User Guide*. 1. For **Firewall (security groups)** settings, you can use the default settings or make changes to meet your needs. 1. For **Configure storage** settings, you can use the default settings or make changes to meet your needs. 1. Select **Advanced details** section, choose your domain from the **Domain join directory** dropdown list. **Note** After choosing the Domain join directory, you may see: ![\[An error message when selecting your Domain join directory. There is an error with your existing SSM document.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/SSM-Error-Message.png) This error occurs if the EC2 launch wizard identifies an existing SSM document with unexpected properties. You can do one of the following: If you previously edited the SSM document and the properties are expected, choose close and proceed to launch the EC2 instance with no changes. Select the delete the existing SSM document here link to delete the SSM document. This will allow for the creation of an SSM document with the correct properties. The SSM document will automatically be created when you launch the EC2 instance. 1. For **IAM instance profile**, you can select an existing IAM instance profile or create a new one. Select an IAM instance profile that has the AWS managed policies **AmazonSSMManagedInstanceCore** and **AmazonSSMDirectoryServiceAccess** attached to it from the **IAM instance profile** dropdown list. To create a new one, choose **Create new IAM profile** link, and then do the following: 1. Choose **Create role**. 1. Under **Select trusted entity**, choose **AWS service**. 1. Under **Use case**, choose **EC2**. 1. Under **Add permissions**, in the list of policies, select the **AmazonSSMManagedInstanceCore** and **AmazonSSMDirectoryServiceAccess** policies. To filter the list, type **SSM** in the search box. Choose **Next**. **Note** **AmazonSSMDirectoryServiceAccess** provides the permissions to join instances to an Active Directory managed by Directory Service. **AmazonSSMManagedInstanceCore** provides the minimum permissions necessary to use the AWS Systems Manager service. For more information about creating a role with these permissions, and for information about other permissions and policies you can assign to your IAM role, see [Create an IAM instance profile for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html) in the *AWS Systems Manager User Guide*. 1. On the **Name, review, and create** page, enter a **Role name**. You will need this role name to attach to the EC2 instance. 1. (Optional) You can provide a description of the IAM instance profile in the **Description** field. 1. Choose **Create role**. 1. Return to **Launch an instance** page and choose the refresh icon next to the **IAM instance profile**. Your new IAM instance profile should be visible in the **IAM instance profile** dropdown list. Choose the new profile and leave the rest of the settings with their default values. 1. Choose **Launch instance**. ------ #### [ Manually join EC2 Windows instance ] To manually join an existing Amazon EC2 Windows instance to an AWS Managed Microsoft AD Active Directory, the instance must be launched using the parameters as specified in [Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD Active Directory](#launching_instance). You will need the IP addresses of the AWS Managed Microsoft AD DNS servers. This information can be found under **Directory Services** > **Directories** > the **Directory ID ** link for your directory > **Directory details** and **Networking & Security** sections. ![\[On the Directory Service console on the directory details page, the IP addresses of the Directory Service provided DNS servers are highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/directory_details_highlighted.png) **To join a Windows instance to an AWS Managed Microsoft AD Active Directory** 1. Connect to the instance using any Remote Desktop Protocol client. 1. Open the TCP/IPv4 properties dialog box on the instance. 1. Open **Network Connections**. **Tip** You can open **Network Connections** directly by running the following from a command prompt on the instance. ``` %SystemRoot%\system32\control.exe ncpa.cpl ``` 1. Open the context menu (right-click) for any enabled network connection and then choose **Properties**. 1. In the connection properties dialog box, open (double-click) **Internet Protocol Version 4**. 1. Select **Use the following DNS server addresses**, change the **Preferred DNS server** and **Alternate DNS server** addresses to the IP addresses of your AWS Managed Microsoft AD-provided DNS servers, and choose **OK**. ![\[The Internet Protocol Version 4 (TCP/IPv4) Properties dialog box with the preferred DNS server and alternative DNS server fields highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/dns_server_addresses.png) 1. Open the **System Properties** dialog box for the instance, select the **Computer Name** tab, and choose **Change**. **Tip** You can open the **System Properties** dialog box directly by running the following from a command prompt on the instance. ``` %SystemRoot%\system32\control.exe sysdm.cpl ``` 1. In the **Member of** field, select **Domain**, enter the fully qualified name of your AWS Managed Microsoft AD Active Directory, and choose **OK**. 1. When prompted for the name and password for the domain administrator, enter the username and password of an account that has domain join privileges. For more information about delegating these privileges, see [Delegating directory join privileges for AWS Managed Microsoft AD](directory_join_privileges.md). **Note** You can enter either the fully qualified name of your domain or the NetBIOS name, followed by a backslash (\$1), and then the username. The username would be **Admin**. For example, **corp.example.com\$1admin** or **corp\$1admin**. 1. After you receive the message welcoming you to the domain, restart the instance to have the changes take effect. Now that your instance has been joined to the AWS Managed Microsoft AD Active Directory domain, you can log into that instance remotely and install utilities to manage the directory, such as adding users and groups. The Active Directory Administration Tools can be used to create users and groups. For more information, see [Installing Active Directory Administration Tools for AWS Managed Microsoft AD](ms_ad_install_ad_tools.md). **Note** You can also use Amazon Route 53 to process DNS queries instead of manually changing the DNS addresses on your Amazon EC2 instances. For more information, see [Integrating your Directory Service's DNS resolution with Amazon Route 53 Resolver](https://aws.amazon.com/blogs//networking-and-content-delivery/integrating-your-directory-services-dns-resolution-with-amazon-route-53-resolvers/) and [ Forwarding outbound DNS queries to your network](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-outbound-queries). ------ # Joining an Amazon EC2 Linux instance to your AWS Managed Microsoft AD Active Directory Joining a Linux instance You can launch and join an EC2 Linux instance to your AWS Managed Microsoft AD in the AWS Management Console. You can also manually join EC2 Linux instance to your AWS Managed Microsoft AD. Tools like Winbind can also be used so you can domain join an EC2 Linux instance to your AWS Managed Microsoft AD. The following Linux instance distributions and versions are supported: + Amazon Linux AMI 2018.03.0 + Amazon Linux 2 (64-bit x86) + Red Hat Enterprise Linux 8 (HVM) (64-bit x86) + Ubuntu Server 18.04 LTS & Ubuntu Server 16.04 LTS + CentOS 7 x86-64 + SUSE Linux Enterprise Server 15 SP1 **Note** Distributions prior to Ubuntu 14 and Red Hat Enterprise Linux 7 and 8 do not support the seamless domain join feature. **Topics** + [ # Seamlessly joining an Amazon EC2 Linux instance to your AWS Managed Microsoft AD Active Directory ](seamlessly_join_linux_instance.md) + [ # Seamlessly joining an Amazon EC2 Linux instance to a shared AWS Managed Microsoft AD ](seamlessly_join_linux_to_shared_MAD.md) + [ # Manually joining an Amazon EC2 Linux instance to your AWS Managed Microsoft AD Active Directory ](join_linux_instance.md) + [ # Manually joining an Amazon EC2 Linux instance to your AWS Managed Microsoft AD Active Directory using Winbind ](join_linux_instance_winbind.md) # Seamlessly joining an Amazon EC2 Linux instance to your AWS Managed Microsoft AD Active Directory Seamlessly joining a Linux instance This procedure seamlessly joins an Amazon EC2 Linux instance to your AWS Managed Microsoft AD Active Directory. To complete this procedure, you will need to create an AWS Secrets Manager secret which can incur additional costs. For more information, see [AWS Secrets Manager Pricing](https://aws.amazon.com/secrets-manager/pricing/). If you need to perform seamless domain join across multiple AWS accounts, you can optionally choose to enable [Directory sharing](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_directory_sharing.html). The following Linux instance distributions and versions are supported: + Amazon Linux AMI 2018.03.0 + Amazon Linux 2 (64-bit x86) + Red Hat Enterprise Linux 8 (HVM) (64-bit x86) + Ubuntu Server 18.04 LTS & Ubuntu Server 16.04 LTS + CentOS 7 x86-64 + SUSE Linux Enterprise Server 15 SP1 **Note** Distributions prior to Ubuntu 14 and Red Hat Enterprise Linux 7 and 8 do not support the seamless domain join feature. For a demonstration on the process of seamlessly joining a Linux instance to your AWS Managed Microsoft AD Active Directory, see the following YouTube video. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/NNUtdVVZVxU?si=_0zOiXhUObcW0_Wo/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/NNUtdVVZVxU?si=_0zOiXhUObcW0_Wo) ## Prerequisites Before you can set up seamless domain join to an EC2 Linux instance, you need to complete the procedures in these sections. ### Networking prerequisites for seamless domain join To seamlessly domain join an EC2 Linux instance, you will need to complete the following: + You will need the following IAM permissions to seamlessly join an EC2 Linux instance: + Have an AWS Managed Microsoft AD. To learn more, see [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + You'll need the following IAM permissions to seamlessly join an EC2 Windows instance: + IAM Instance Profile with the following IAM permissions: + `AmazonSSMManagedInstanceCore` + `AmazonSSMDirectoryServiceAccess` + The user seamlessly domain joining the EC2 to the AWS Managed Microsoft AD needs the following IAM permissions: + Directory Service Permissions: + `"ds:DescribeDirectories"` + `"ds:CreateComputer"` + Amazon VPC Permissions: + `"ec2:DescribeVpcs"` + `"ec2:DescribeSubnets"` + `"ec2:DescribeNetworkInterfaces"` + `"ec2:CreateNetworkInterface"` + `"ec2:AttachNetworkInterface"` + EC2 Permissions: + `"ec2:DescribeInstances"` + `"ec2:DescribeImages"` + `"ec2:DescribeInstanceTypes"` + `"ec2:RunInstances"` + `"ec2:CreateTags"` + AWS Systems Manager Permissions: + `"ssm:DescribeInstanceInformation"` + `"ssm:SendCommand"` + `"ssm:GetCommandInvocation"` + `"ssm:CreateBatchAssociation"` + When your AWS Managed Microsoft AD is created, a security group is created with inbound and outbound rules. To learn more about these rules and ports, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). To seamlessly domain join an EC2 Linux instance, your VPC where you're launching your instance should allow the same ports allowed in your AWS Managed Microsoft AD security group's inbound and outbound rules. + Depending on your network security and firewall settings, you could be required to allow additional outbound traffic. This traffic would be for HTTPS (port 443) to the following endpoints: **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/seamlessly_join_linux_instance.html) + We recommend to use a DNS server that will resolve your AWS Managed Microsoft AD domain name. To do so, you can create a DHCP option set. See [Creating or changing a DHCP options set for AWS Managed Microsoft AD](dhcp_options_set.md) for more information. + If you choose not to create a DHCP option set, then your DNS servers will be static and configured to by your AWS Managed Microsoft AD. ### Select your seamless domain join service account You can seamlessly join Linux computers to your AWS Managed Microsoft AD Active Directory domain. To do that, you must use a user account with create computer account permissions to join the machines to the domain. Although members of the *AWS delegated administrators* or other groups might have sufficient privileges to join computers to the domain, we do not recommend using these. As a best practice, we recommend that you use a service account that has the minimum privileges necessary to join the computers to the domain. To delegate an account with the minimum privileges necessary to join the computers to the domain, you can run the following PowerShell commands. You must run these commands from a domain-joined Windows computer with the [Installing Active Directory Administration Tools for AWS Managed Microsoft AD](ms_ad_install_ad_tools.md) installed. In addition, you must use an account that has permission to modify the permissions on your Computers OU or container. The PowerShell command sets permissions allowing the service account to create computer objects in your domain's default computers container. ``` $AccountName = 'awsSeamlessDomain' # DO NOT modify anything below this comment. # Getting Active Directory information. Import-Module 'ActiveDirectory' $Domain = Get-ADDomain -ErrorAction Stop $BaseDn = $Domain.DistinguishedName $ComputersContainer = $Domain.ComputersContainer $SchemaNamingContext = Get-ADRootDSE | Select-Object -ExpandProperty 'schemaNamingContext' [System.GUID]$ServicePrincipalNameGuid = (Get-ADObject -SearchBase $SchemaNamingContext -Filter { lDAPDisplayName -eq 'Computer' } -Properties 'schemaIDGUID').schemaIDGUID # Getting Service account Information. $AccountProperties = Get-ADUser -Identity $AccountName $AccountSid = New-Object -TypeName 'System.Security.Principal.SecurityIdentifier' $AccountProperties.SID.Value # Getting ACL settings for the Computers container. $ObjectAcl = Get-ACL -Path "AD:\$ComputersContainer" # Setting ACL allowing the service account the ability to create child computer objects in the Computers container. $AddAccessRule = New-Object -TypeName 'System.DirectoryServices.ActiveDirectoryAccessRule' $AccountSid, 'CreateChild', 'Allow', $ServicePrincipalNameGUID, 'All' $ObjectAcl.AddAccessRule($AddAccessRule) Set-ACL -AclObject $ObjectAcl -Path "AD:\$ComputersContainer" ``` If you prefer using a graphical user interface (GUI) you can use the manual process that is described in [Delegate privileges to your service account](ad_connector_getting_started.md#connect_delegate_privileges). ### Create the secrets to store the domain service account You can use AWS Secrets Manager to store the domain service account. For more information, see [Create an AWS Secrets Manager secret](https://docs.aws.amazon.com//secretsmanager/latest/userguide/create_secret.html). **Note** There are fees associated with Secrets Manager. For more information see, [Pricing](https://docs.aws.amazon.com//secretsmanager/latest/userguide/intro.html#asm_pricing) in the *AWS Secrets Manager User Guide*. **To create secrets and store the domain service account information** 1. Sign in to the AWS Management Console and open the AWS Secrets Manager console at [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). 1. Choose **Store a new secret**. 1. On the **Store a new secret** page, do the following: 1. Under **Secret type**, choose **Other type of secrets**. 1. Under **Key/value pairs**, do the following: 1. In the first box, enter **awsSeamlessDomainUsername**. On the same row, in the next box, enter the username for your service account. For example, if you used the PowerShell command previously, the service account name would be **awsSeamlessDomain**. **Note** You must enter **awsSeamlessDomainUsername** exactly as it is. Make sure there are not any leading or ending spaces. Otherwise the domain join will fail. ![\[In the AWS Secrets Manager console on the choose a secret type page. Other type of secret is selected under secret type and awsSeamlessDomainUsername is entered as the key value.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/secrets_manager_1.png) 1. Choose **Add row**. 1. On the new row, in the first box, enter **awsSeamlessDomainPassword**. On the same row, in the next box, enter the password for your service account. **Note** You must enter **awsSeamlessDomainPassword** exactly as it is. Make sure there are not any leading or ending spaces. Otherwise the domain join will fail. 1. Under **Encryption key, ** leave the default value `aws/secretsmanager`. AWS Secrets Manager always encrypts the secret when you choose this option. You also may choose a key you created. 1. Choose **Next**. 1. Under **Secret name**, enter a secret name that includes your directory ID using the following format, replacing *d-xxxxxxxxx* with your directory ID: ``` aws/directory-services/d-xxxxxxxxx/seamless-domain-join ``` This will be used to retrieve secrets in the application. **Note** You must enter **aws/directory-services/*d-xxxxxxxxx*/seamless-domain-join** exactly as it is but replace *d-xxxxxxxxxx* with your directory ID. Make sure that there are no leading or ending spaces. Otherwise the domain join will fail. ![\[In the AWS Secrets Manager console on the configure secret page. The secret name is entered and highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/secrets_manager_2.png) 1. Leave everything else set to defaults, and then choose **Next**. 1. Under **Configure automatic rotation**, choose **Disable automatic rotation**, and then choose **Next**. You can turn on rotation for this secret after you store it. 1. Review the settings, and then choose **Store** to save your changes. The Secrets Manager console returns you to the list of secrets in your account with your new secret now included in the list. 1. Choose your newly created secret name from the list, and take note of the **Secret ARN** value. You will need it in the next section. ### Turn on rotation for the domain service account secret We recommend that you regularly rotate secrets to improve your security posture. **To turn on rotation for the domain service account secret** + Follow the instructions in [Set up automatic rotation for AWS Secrets Manager secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html) in the *AWS Secrets Manager User Guide*. For Step 5, use the rotation template [Microsoft Active Directory credentials](https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference_available-rotation-templates.html#template-AD-password) in the *AWS Secrets Manager User Guide*. For help, see [Troubleshoot AWS Secrets Manager rotation](https://docs.aws.amazon.com/secretsmanager/latest/userguide/troubleshoot_rotation.html) in the *AWS Secrets Manager User Guide*. ### Create the required IAM policy and role Use the following prerequisite steps to create a custom policy that allows read-only access to your Secrets Manager seamless domain join secret (which you created earlier), and to create a new LinuxEC2DomainJoin IAM role. #### Create the Secrets Manager IAM read policy You use the IAM console to create a policy that grants read-only access to your Secrets Manager secret. **To create the Secrets Manager IAM read policy** 1. Sign in to the AWS Management Console as a user that has permission to create IAM policies. Then open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, **Access Management**, choose **Policies**. 1. Choose **Create policy**. 1. Choose the **JSON** tab and copy the text from the following JSON policy document. Then paste it into the **JSON** text box. **Note** Make sure you replace the Region and Resource ARN with the actual Region and ARN of the secret that you created earlier. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": [ "arn:aws:secretsmanager:us-east-1:xxxxxxxxx:secret:aws/directory-services/d-xxxxxxxxx/seamless-domain-join" ] } ] } ``` 1. When you are finished, choose **Next**. The policy validator reports any syntax errors. For more information, see [Validating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_policy-validator.html). 1. On the **Review policy** page, enter a policy name, such as **SM-Secret-Linux-DJ-*d-xxxxxxxxxx*-Read**. Review the **Summary** section to see the permissions that your policy grants. Then choose **Create policy** to save your changes. The new policy appears in the list of managed policies and is now ready to attach to an identity. **Note** We recommend you create one policy per secret. Doing so ensures that instances only have access to the appropriate secret and minimizes the impact if an instance is compromised. #### Create the LinuxEC2DomainJoin role You use the IAM console to create the role that you will use to domain join your Linux EC2 instance. **To create the LinuxEC2DomainJoin role** 1. Sign in to the AWS Management Console as a user that has permission to create IAM policies. Then open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, under **Access Management**, choose **Roles**. 1. In the content pane, choose **Create role**. 1. Under **Select type of trusted entity**, choose **AWS service**. 1. Under **Use case**, choose **EC2**, and then choose **Next**. ![\[In the IAM console on the select trusted entity page. AWS service and EC2 are selected.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/iam-console-trusted-entity.png) 1. For **Filter policies**, do the following: 1. Enter **AmazonSSMManagedInstanceCore**. Then select the check box for that item in the list. 1. Enter **AmazonSSMDirectoryServiceAccess**. Then select the check box for that item in the list. 1. Enter **SM-Secret-Linux-DJ-*d-xxxxxxxxxx*-Read** (or the name of the policy that you created in the previous procedure). Then select the check box for that item in the list. 1. After adding the three policies listed above, select **Create role**. **Note** AmazonSSMDirectoryServiceAccess provides the permissions to join instances to an Active Directory managed by Directory Service. AmazonSSMManagedInstanceCore provides the minimum permissions necessary to use the AWS Systems Manager service. For more information about creating a role with these permissions, and for information about other permissions and policies you can assign to your IAM role, see [Create an IAM instance profile for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html) in the *AWS Systems Manager User Guide*. 1. Enter a name for your new role, such as **LinuxEC2DomainJoin** or another name that you prefer in the **Role name** field. 1. (Optional) For **Role description**, enter a description. 1. (Optional) Choose **Add new tag** under **Step 3: Add tags** to add tags. Tag key-value pairs are used to organize, track, or control access for this role. 1. Choose **Create role**. ## Seamlessly join your Linux instance **To seamlessly join your Linux instance** 1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. From the Region selector in the navigation bar, choose the same AWS Region as the existing directory. 1. On the **EC2 Dashboard**, in the **Launch instance** section, choose **Launch instance**. 1. On the **Launch an instance** page, under the **Name and Tags** section, enter the name you would like to use for your Linux EC2 instance. 1. *(Optional)* Choose **Add additional tags** to add one or more tag key-value pairs to organize, track, or control access for this EC2 instance. 1. In the **Application and OS Image (Amazon Machine Image)** section, choose a Linux AMI you wish to launch. **Note** The AMI used must have AWS Systems Manager (SSM Agent) version 2.3.1644.0 or higher. To check the installed SSM Agent version in your AMI by launching an instance from that AMI, see [Getting the currently installed SSM Agent version](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-get-version.html). If you need to upgrade the SSM Agent, see [Installing and configuring SSM Agent on EC2 instances for Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-install-ssm-agent.html). SSM uses the `aws:domainJoin` plugin when joining a Linux instance to a Active Directory domain. The plugin changes the hostname for the Linux instances to the format EC2AMAZ-*XXXXXXX*. For more information about `aws:domainJoin`, see [AWS Systems Manager command document plugin reference](https://docs.aws.amazon.com//systems-manager/latest/userguide/documents-command-ssm-plugin-reference.html#aws-domainJoin) in the *AWS Systems Manager User Guide*. 1. In the **Instance type** section, choose the instance type you would like to use from **Instance type** dropdown list. 1. In the **Key pair (login)** section, you can either choose to create a new key pair or choose from an existing key pair. To create a new key pair, choose **Create new key pair**. Enter a name for the key pair and select an option for the **Key pair type** and **Private key file format**. To save the private key in a format that can be used with OpenSSH, choose **.pem**. To save the private key in a format that can be used with PuTTY, choose **.ppk**. Choose **create key pair**. The private key file is automatically downloaded by your browser. Save the private key file in a safe place. **Important** This is the only chance for you to save the private key file. 1. On the **Launch an instance** page, under **Network settings** section, choose **Edit**. Choose the **VPC** that your directory was created in from the **VPC -* required*** dropdown list. 1. Choose one of the public subnets in your VPC from the **Subnet** dropdown list. The subnet you choose must have all external traffic routed to an internet gateway. If this is not the case, you won't be able to connect to the instance remotely. For more information on how to connect to a 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*. 1. Under **Auto-assign public IP**, choose **Enable**. For more information about public and private IP addressing, see [Amazon EC2 instance IP addressing](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-instance-addressing.html) in the *Amazon EC2 User Guide*. 1. For **Firewall (security groups)** settings, you can use the default settings or make changes to meet your needs. 1. For **Configure storage** settings, you can use the default settings or make changes to meet your needs. 1. Select **Advanced details** section, choose your domain from the **Domain join directory** dropdown list. **Note** After choosing the Domain join directory, you may see: ![\[An error message when selecting your Domain join directory. There is an error with your existing SSM document.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/SSM-Error-Message.png) This error occurs if the EC2 launch wizard identifies an existing SSM document with unexpected properties. You can do one of the following: If you previously edited the SSM document and the properties are expected, choose close and proceed to launch the EC2 instance with no changes. Select the delete the existing SSM document here link to delete the SSM document. This will allow for the creation of an SSM document with the correct properties. The SSM document will automatically be created when you launch the EC2 instance. 1. For **IAM instance profile**, choose the IAM role that you previously created in the prerequisites section **Step 2: Create the LinuxEC2DomainJoin role**. 1. Choose **Launch instance**. **Note** If you are performing a seamless domain join with SUSE Linux, a reboot is required before authentications will work. To reboot SUSE from the Linux terminal, type **sudo reboot**. # Seamlessly joining an Amazon EC2 Linux instance to a shared AWS Managed Microsoft AD Seamlessly joining a Linux instance to a shared Active Directory In this procedure, you will seamlessly join an Amazon EC2 Linux instance to a shared AWS Managed Microsoft AD. To do this, you will create an AWS Secrets Manager IAM read policy in the EC2 instance role in the account where you wish to launch the EC2 Linux instance. This will be referred to as `Account 2` in this procedure. This instance will be using the AWS Managed Microsoft AD that is being shared from the other account which is referred to as `Account 1`. ## Prerequisites Before you can seamlessly join an Amazon EC2 Linux instance to a shared AWS Managed Microsoft AD, you will need to complete the following: + Steps 1 through 3 in the tutorial, [Tutorial: Sharing your AWS Managed Microsoft AD directory for seamless EC2 domain-join](ms_ad_tutorial_directory_sharing.md). This tutorial walks you through setting up your network and sharing your AWS Managed Microsoft AD. + The procedure outlined in [Seamlessly joining an Amazon EC2 Linux instance to your AWS Managed Microsoft AD Active Directory](seamlessly_join_linux_instance.md). ## Step 1. Create LinuxEC2DomainJoin role in Account 2 Step 1. Create an IAM role In this step, you will use the IAM console to create the IAM role that you will use to domain join your EC2 Linux instance while signed in to `Account 2`. **Create the LinuxEC2DomainJoin role** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the left navigation pane, under **Access Management**, choose **Roles**. 1. On the **Roles** page, choose **Create role**. 1. Under **Select type of trusted entity**, choose **AWS service**. 1. Under **Use case**, choose **EC2**, and then choose **Next** 1. For **Filter policies**, do the following: 1. Enter `AmazonSSMManagedInstanceCore`. Then select the checkbox for that item in the list. 1. Enter `AmazonSSMDirectoryServiceAccess`. Then select the checkbox for that item in the list. 1. After adding these policies, select **Create role**. **Note** `AmazonSSMDirectoryServiceAccess` provides the permissions to join instances to an Active Directory managed by Directory Service. `AmazonSSMManagedInstanceCore` provides the minimum permissions necessary to use AWS Systems Manager. For more information about creating a role with these permissions, and for information about other permissions and policies you can assign to your IAM role, see [Configure instance permissions required for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-permissions.html) in the *AWS Systems Manager User Guide*. 1. Enter a name for your new role, such as `LinuxEC2DomainJoin` or another name that you prefer in the **Role name** field. 1. *(Optional)* For **Role description**, enter a description. 1. *(Optional)* Choose **Add new tag** under **Step 3: Add tags** to add tags. Tag key-value pairs are used to organize, track, or control access for this role. 1. Choose **Create role**. ## Step 2. Create cross account resource access to share AWS Secrets Manager secrets Step 2. Create cross account resource access The next section are additional requirements that need to be met to seamlessly join EC2 Linux instances with a shared AWS Managed Microsoft AD. These requirements include creating resource policies and attaching them to the appropriate services and resources. To allow users in an account to access AWS Secrets Manager secrets in another account, you must allow access in both a resource policy and identity policy. This type of access is called [cross account resource access](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html). This type of access is different than granting access to identities in the same account as the Secrets Manager secret. You must also allow the identity to use [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) (KMS) key that the secret is encrypted with. This permission is necessary as you can't use the AWS managed key (`aws/secretsmanager`) for cross-account access. Instead, you will encrypt your secret with a KMS key that you create, and then attach a key policy to it. To change the encryption key for a secret, see [Modify an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html). **Note** There are fees associated with AWS Secrets Manager, depending on which secret you use. For the current complete pricing list, see [AWS Secrets Manager Pricing](https://aws.amazon.com/secrets-manager/pricing/). You can use the AWS managed key `aws/secretsmanager` that Secrets Manager creates to encrypt your secrets for free. If you create your own KMS keys to encrypt your secrets, AWS charges you at the current AWS KMS rate. For more information, see [AWS Key Management Service Pricing](https://aws.amazon.com/kms/pricing/). The following steps allow you to create the resource policies to enable users to seamlessly join a EC2 Linux instance to a shared AWS Managed Microsoft AD. **Attach a resource policy to the secret in Account 1** 1. Open the Secrets Manager console at [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). 1. From the list of secrets, choose your **Secret** you created during the [Prerequisites](#seamlessly_join_linux_to_shared_MAD_prereqs). 1. On the **Secret's details page** under the **Overview** tab, scroll down to **Resource permissions**. 1. Select **Edit permissions**. 1. In the policy field, enter the following policy. The following policy allows **LinuxEC2DomainJoin** in `Account 2` to access the secret in `Account 1`. Replace the ARN value with the ARN value for your `Account 2`, `LinuxEC2DomainJoin` role you created in [Step 1](#seamlessly_join_linux_to_shared_MAD_step_1). To use this policy, see [Attach a permissions policy to an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-policies.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/LinuxEC2DomainJoin" }, "Action": "secretsmanager:GetSecretValue", "Resource": "*" } ] } ``` ------ **Add a statement to the key policy for the KMS key in Account 1** 1. Open the Secrets Manager console at [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). 1. In the left navigation pane, select **Customer managed keys**. 1. On the **Customer managed keys** page, select the key you created. 1. On the **Key Details** page, navigate to **Key policy**, and select **Edit**. 1. The following key policy statement allows `ApplicationRole` in `Account 2` to use the KMS key in `Account 1` to decrypt the secret in `Account 1`. To use this statement, add it to the key policy for your KMS key. For more information, see [Changing a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html). ``` { { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::Account2:role/ApplicationRole" }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" } ``` **Create an identity policy to the identity in Account 2** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the left navigation pane, under **Access management**, select **Policies**. 1. Select **Create Policy**. Choose **JSON** in the **Policy editor**. 1. The following policy allows `ApplicationRole` in `Account 2` to access the secret in `Account 1` and decrypt the secret value by using the encryption key which is also in `Account 1`. You can find the ARN for your secret in the Secrets Manager console on the **Secret Details** page under **Secret ARN**. Alternatively, you can call [describe-secret](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/describe-secret.html) to identify the secret's ARN. Replace the Resource ARN with the Resource ARN for the secret ARN and `Account 1`. To use this policy, see [Attach a permissions policy to an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-policies.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:secretName-AbCdEf" }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:Describekey" ], "Resource": "arn:aws:kms:us-east-1:111122223333:key/Your_Encryption_Key" } ] } ``` ------ 1. Select **Next** and then select **Save changes**. 1. Find and select the Role you created in `Account 2` in [Attach a resource policy to the secret in Account 1](#step1ResourcePolicy). 1. Under **Add permissions**, select **Attach policies**. 1. In the search bar, find the policy you created in [Add a statement to the key policy for the KMS key in Account 1](#step2KeyPolicy) and select the box to add the policy to the role. Then select **Add permissions**. ## Step 3. Seamlessly join your Linux instance Step 3. Seamlessly join Linux instance You can now use the following procedure to seamlessly join your EC2 Linux instance to your shared AWS Managed Microsoft AD. **To seamlessly join your Linux instance** 1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. From the Region selector in the navigation bar, choose the same AWS Region as the existing directory. 1. On the **EC2 Dashboard**, in the **Launch instance** section, choose **Launch instance**. 1. On the **Launch an instance** page, under the **Name and Tags** section, enter the name you would like to use for your Linux EC2 instance. 1. *(Optional)* Choose **Add additional tags** to add one or more tag key-value pairs to organize, track, or control access for this EC2 instance. 1. In the **Application and OS Image (Amazon Machine Image)** section, choose a Linux AMI you wish to launch. **Note** The AMI used must have AWS Systems Manager (SSM Agent) version 2.3.1644.0 or higher. To check the installed SSM Agent version in your AMI by launching an instance from that AMI, see [Getting the currently installed SSM Agent version](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-get-version.html). If you need to upgrade the SSM Agent, see [Installing and configuring SSM Agent on EC2 instances for Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-install-ssm-agent.html). SSM uses the `aws:domainJoin` plugin when joining a Linux instance to a Active Directory domain. The plugin changes the hostname for the Linux instances to the format EC2AMAZ-*XXXXXXX*. For more information about `aws:domainJoin`, see [AWS Systems Manager command document plugin reference](https://docs.aws.amazon.com//systems-manager/latest/userguide/documents-command-ssm-plugin-reference.html#aws-domainJoin) in the *AWS Systems Manager User Guide*. 1. In the **Instance type** section, choose the instance type you would like to use from **Instance type** dropdown list. 1. In the **Key pair (login)** section, you can either choose to create a new key pair or choose from an existing key pair. To create a new key pair, choose **Create new key pair**. Enter a name for the key pair and select an option for the **Key pair type** and **Private key file format**. To save the private key in a format that can be used with OpenSSH, choose **.pem**. To save the private key in a format that can be used with PuTTY, choose **.ppk**. Choose **create key pair**. The private key file is automatically downloaded by your browser. Save the private key file in a safe place. **Important** This is the only chance for you to save the private key file. 1. On the **Launch an instance** page, under **Network settings** section, choose **Edit**. Choose the **VPC** that your directory was created in from the **VPC -* required*** dropdown list. 1. Choose one of the public subnets in your VPC from the **Subnet** dropdown list. The subnet you choose must have all external traffic routed to an internet gateway. If this is not the case, you won't be able to connect to the instance remotely. For more information on how to connect to a 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*. 1. Under **Auto-assign public IP**, choose **Enable**. For more information about public and private IP addressing, see [Amazon EC2 instance IP addressing](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-instance-addressing.html) in the *Amazon EC2 User Guide*. 1. For **Firewall (security groups)** settings, you can use the default settings or make changes to meet your needs. 1. For **Configure storage** settings, you can use the default settings or make changes to meet your needs. 1. Select **Advanced details** section, choose your domain from the **Domain join directory** dropdown list. **Note** After choosing the Domain join directory, you may see: ![\[An error message when selecting your Domain join directory. There is an error with your existing SSM document.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/SSM-Error-Message.png) This error occurs if the EC2 launch wizard identifies an existing SSM document with unexpected properties. You can do one of the following: If you previously edited the SSM document and the properties are expected, choose close and proceed to launch the EC2 instance with no changes. Select the delete the existing SSM document here link to delete the SSM document. This will allow for the creation of an SSM document with the correct properties. The SSM document will automatically be created when you launch the EC2 instance. 1. For **IAM instance profile**, choose the IAM role that you previously created in the prerequisites section **Step 2: Create the LinuxEC2DomainJoin role**. 1. Choose **Launch instance**. **Note** If you are performing a seamless domain join with SUSE Linux, a reboot is required before authentications will work. To reboot SUSE from the Linux terminal, type **sudo reboot**. # Manually joining an Amazon EC2 Linux instance to your AWS Managed Microsoft AD Active Directory Manually joining a Linux instance In addition to Amazon EC2 Windows instances, you can also join certain Amazon EC2 Linux instances to your AWS Managed Microsoft AD Active Directory. The following Linux instance distributions and versions are supported: + Amazon Linux AMI 2018.03.0 + Amazon Linux 2 (64-bit x86) + Amazon Linux 2023 AMI + Red Hat Enterprise Linux 8 (HVM) (64-bit x86) + Ubuntu Server 18.04 LTS & Ubuntu Server 16.04 LTS + CentOS 7 x86-64 + SUSE Linux Enterprise Server 15 SP1 **Note** Other Linux distributions and versions may work but have not been tested. ## Join a Linux instance to your AWS Managed Microsoft AD Before you can join either an Amazon Linux, CentOS, Red Hat, or Ubuntu instance to your directory, the instance must first be launched as specified in [Seamlessly join your Linux instance](seamlessly_join_linux_instance.md#seamless-linux-join-instance). **Important** Some of the following procedures, if not performed correctly, can render your instance unreachable or unusable. Therefore, we strongly suggest you make a backup or take a snapshot of your instance before performing these procedures. **To join a Linux instance to your directory** Follow the steps for your specific Linux instance using one of the following tabs: ------ #### [ Amazon Linux ] 1. Connect to the instance using any SSH client. 1. Configure the Linux instance to use the DNS server IP addresses of the Directory Service-provided DNS servers. You can do this either by setting it up in the DHCP Options set attached to the VPC or by setting it manually on the instance. If you want to set it manually, see [How do I assign a static DNS server to a private Amazon EC2 instance](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/) in the AWS Knowledge Center for guidance on setting the persistent DNS server for your particular Linux distribution and version. 1. Make sure your Amazon Linux - 64bit instance is up to date. ``` sudo yum -y update ``` 1. Install the required Amazon Linux packages on your Linux instance. **Note** Some of these packages may already be installed. As you install the packages, you might be presented with several pop-up configuration screens. You can generally leave the fields in these screens blank. Amazon Linux ``` sudo yum install samba-common-tools realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation ``` **Note** For help with determining the Amazon Linux version you are using, see [Identifying Amazon Linux images](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html#amazon-linux-image-id) in the *Amazon EC2 User Guide for Linux Instances*. 1. Join the instance to the directory with the following command. ``` sudo realm join -U join_account@EXAMPLE.COM example.com --verbose ``` *join\$1account@EXAMPLE.COM* An account in the *example.com* domain that has domain join privileges. Enter the password for the account when prompted. For more information about delegating these privileges, see [Delegating directory join privileges for AWS Managed Microsoft AD](directory_join_privileges.md). *example.com* The fully qualified DNS name of your directory. ``` ... * Successfully enrolled machine in realm ``` 1. Set the SSH service to allow password authentication. 1. Open the `/etc/ssh/sshd_config` file in a text editor. ``` sudo vi /etc/ssh/sshd_config ``` 1. Set the `PasswordAuthentication` setting to `yes`. ``` PasswordAuthentication yes ``` 1. Restart the SSH service. ``` sudo systemctl restart sshd.service ``` Alternatively: ``` sudo service sshd restart ``` 1. After the instance has restarted, connect to it with any SSH client and add the AWS Delegated Administrators group to the sudoers list by performing the following steps: 1. Open the `sudoers` file with the following command: ``` sudo visudo ``` 1. Add the following to the bottom of the `sudoers` file and save it. ``` ## Add the "AWS Delegated Administrators" group from the example.com domain. %AWS\ Delegated\ Administrators@example.com ALL=(ALL:ALL) ALL ``` (The above example uses "\$1" to create the Linux space character.) ------ #### [ CentOS ] 1. Connect to the instance using any SSH client. 1. Configure the Linux instance to use the DNS server IP addresses of the Directory Service-provided DNS servers. You can do this either by setting it up in the DHCP Options set attached to the VPC or by setting it manually on the instance. If you want to set it manually, see [How do I assign a static DNS server to a private Amazon EC2 instance](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/) in the AWS Knowledge Center for guidance on setting the persistent DNS server for your particular Linux distribution and version. 1. Make sure your CentOS 7 instance is up to date. ``` sudo yum -y update ``` 1. Install the required CentOS 7 packages on your Linux instance. **Note** Some of these packages may already be installed. As you install the packages, you might be presented with several pop-up configuration screens. You can generally leave the fields in these screens blank. ``` sudo yum -y install sssd realmd krb5-workstation samba-common-tools ``` 1. Join the instance to the directory with the following command. ``` sudo realm join -U join_account@example.com example.com --verbose ``` *join\$1account@example.com* An account in the *example.com* domain that has domain join privileges. Enter the password for the account when prompted. For more information about delegating these privileges, see [Delegating directory join privileges for AWS Managed Microsoft AD](directory_join_privileges.md). *example.com* The fully qualified DNS name of your directory. ``` ... * Successfully enrolled machine in realm ``` 1. Set the SSH service to allow password authentication. 1. Open the `/etc/ssh/sshd_config` file in a text editor. ``` sudo vi /etc/ssh/sshd_config ``` 1. Set the `PasswordAuthentication` setting to `yes`. ``` PasswordAuthentication yes ``` 1. Restart the SSH service. ``` sudo systemctl restart sshd.service ``` Alternatively: ``` sudo service sshd restart ``` 1. After the instance has restarted, connect to it with any SSH client and add the AWS Delegated Administrators group to the sudoers list by performing the following steps: 1. Open the `sudoers` file with the following command: ``` sudo visudo ``` 1. Add the following to the bottom of the `sudoers` file and save it. ``` ## Add the "AWS Delegated Administrators" group from the example.com domain. %AWS\ Delegated\ Administrators@example.com ALL=(ALL:ALL) ALL ``` (The above example uses "\$1" to create the Linux space character.) ------ #### [ Red Hat ] 1. Connect to the instance using any SSH client. 1. Configure the Linux instance to use the DNS server IP addresses of the Directory Service-provided DNS servers. You can do this either by setting it up in the DHCP Options set attached to the VPC or by setting it manually on the instance. If you want to set it manually, see [How do I assign a static DNS server to a private Amazon EC2 instance](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/) in the AWS Knowledge Center for guidance on setting the persistent DNS server for your particular Linux distribution and version. 1. Make sure the Red Hat - 64bit instance is up to date. ``` sudo yum -y update ``` 1. Install the required Red Hat packages on your Linux instance. **Note** Some of these packages may already be installed. As you install the packages, you might be presented with several pop-up configuration screens. You can generally leave the fields in these screens blank. ``` sudo yum -y install sssd realmd krb5-workstation samba-common-tools ``` 1. Join the instance to the directory with the following command. ``` sudo realm join -v -U join_account example.com --install=/ ``` *join\$1account* The **sAMAccountName** for an account in the *example.com* domain that has domain join privileges. Enter the password for the account when prompted. For more information about delegating these privileges, see [Delegating directory join privileges for AWS Managed Microsoft AD](directory_join_privileges.md). *example.com* The fully qualified DNS name of your directory. ``` ... * Successfully enrolled machine in realm ``` 1. Set the SSH service to allow password authentication. 1. Open the `/etc/ssh/sshd_config` file in a text editor. ``` sudo vi /etc/ssh/sshd_config ``` 1. Set the `PasswordAuthentication` setting to `yes`. ``` PasswordAuthentication yes ``` 1. Restart the SSH service. ``` sudo systemctl restart sshd.service ``` Alternatively: ``` sudo service sshd restart ``` 1. After the instance has restarted, connect to it with any SSH client and add the AWS Delegated Administrators group to the sudoers list by performing the following steps: 1. Open the `sudoers` file with the following command: ``` sudo visudo ``` 1. Add the following to the bottom of the `sudoers` file and save it. ``` ## Add the "AWS Delegated Administrators" group from the example.com domain. %AWS\ Delegated\ Administrators@example.com ALL=(ALL:ALL) ALL ``` (The above example uses "\$1" to create the Linux space character.) ------ #### [ SUSE ] 1. Connect to the instance using any SSH client. 1. Configure the Linux instance to use the DNS server IP addresses of the Directory Service-provided DNS servers. You can do this either by setting it up in the DHCP Options set attached to the VPC or by setting it manually on the instance. If you want to set it manually, see [How do I assign a static DNS server to a private Amazon EC2 instance](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/) in the AWS Knowledge Center for guidance on setting the persistent DNS server for your particular Linux distribution and version. 1. Make sure your SUSE Linux 15 instance is up to date. 1. Connect the package repository. ``` sudo SUSEConnect -p PackageHub/15.1/x86_64 ``` 1. Update SUSE. ``` sudo zypper update -y ``` 1. Install the required SUSE Linux 15 packages on your Linux instance. **Note** Some of these packages may already be installed. As you install the packages, you might be presented with several pop-up configuration screens. You can generally leave the fields in these screens blank. ``` sudo zypper -n install realmd adcli sssd sssd-tools sssd-ad samba-client krb5-client ``` 1. Join the instance to the directory with the following command. ``` sudo realm join -U join_account example.com --verbose ``` *join\$1account* The sAMAccountName in the *example.com* domain that has domain join privileges. Enter the password for the account when prompted. For more information about delegating these privileges, see [Delegating directory join privileges for AWS Managed Microsoft AD](directory_join_privileges.md). *example.com* The fully-qualified DNS name of your directory. ``` … realm: Couldn't join realm: Enabling SSSD in nsswitch.conf and PAM failed. ``` Note that both of the following returns are expected. ``` ! Couldn't authenticate with keytab while discovering which salt to use: ! Enabling SSSD in nsswitch.conf and PAM failed. ``` 1. Manually enable **SSSD** in **PAM**. ``` sudo pam-config --add --sss ``` 1. Edit nsswitch.conf to enable SSSD in nsswitch.conf ``` sudo vi /etc/nsswitch.conf ``` ``` passwd: compat sss group: compat sss shadow: compat sss ``` 1. Add the following line to /etc/pam.d/common-session to auto create a home directory at initial login ``` sudo vi /etc/pam.d/common-session ``` ``` session optional pam_mkhomedir.so skel=/etc/skel umask=077 ``` 1. Reboot the instance to complete the domain joined process. ``` sudo reboot ``` 1. Reconnect to the instance using any SSH client to verify the domain join has completed successfully and finalize additional steps. 1. To confirm the instance has been enrolled on the domain ``` sudo realm list ``` ``` example.com type: kerberos realm-name: EXAMPLE.COM domain-name: example.com configured: kerberos-member server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: adcli required-package: samba-client login-formats: %U@example.com login-policy: allow-realm-logins ``` 1. To verify the status of SSSD daemon ``` systemctl status sssd ``` ``` sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2020-04-15 16:22:32 UTC; 3min 49s ago Main PID: 479 (sssd) Tasks: 4 CGroup: /system.slice/sssd.service ├─479 /usr/sbin/sssd -i --logger=files ├─505 /usr/lib/sssd/sssd_be --domain example.com --uid 0 --gid 0 --logger=files ├─548 /usr/lib/sssd/sssd_nss --uid 0 --gid 0 --logger=files └─549 /usr/lib/sssd/sssd_pam --uid 0 --gid 0 --logger=files ``` 1. To permit a user access via SSH and console ``` sudo realm permit join_account@example.com ``` To permit a domain group access via SSH and console ``` sudo realm permit -g 'AWS Delegated Administrators' ``` Or to permit all users access ``` sudo realm permit --all ``` 1. Set the SSH service to allow password authentication. 1. Open the `/etc/ssh/sshd_config` file in a text editor. ``` sudo vi /etc/ssh/sshd_config ``` 1. Set the `PasswordAuthentication` setting to `yes`. ``` PasswordAuthentication yes ``` 1. Restart the SSH service. ``` sudo systemctl restart sshd.service ``` Alternatively: ``` sudo service sshd restart ``` 1. 13. After the instance has restarted, connect to it with any SSH client and add the AWS Delegated Administrators group to the sudoers list by performing the following steps: 1. Open the sudoers file with the following command: ``` sudo visudo ``` 1. Add the following to the bottom of the sudoers file and save it. ``` ## Add the "Domain Admins" group from the awsad.com domain. %AWS\ Delegated\ Administrators@example.com ALL=(ALL) NOPASSWD: ALL ``` ------ #### [ Ubuntu ] 1. Connect to the instance using any SSH client. 1. Configure the Linux instance to use the DNS server IP addresses of the Directory Service-provided DNS servers. You can do this either by setting it up in the DHCP Options set attached to the VPC or by setting it manually on the instance. If you want to set it manually, see [How do I assign a static DNS server to a private Amazon EC2 instance](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/) in the AWS Knowledge Center for guidance on setting the persistent DNS server for your particular Linux distribution and version. 1. Make sure your Ubuntu - 64bit instance is up to date. ``` sudo apt-get update sudo apt-get -y upgrade ``` 1. Install the required Ubuntu packages on your Linux instance. **Note** Some of these packages may already be installed. As you install the packages, you might be presented with several pop-up configuration screens. You can generally leave the fields in these screens blank. ``` sudo apt-get -y install sssd realmd krb5-user samba-common packagekit adcli ``` 1. Disable Reverse DNS resolution and set the default realm to your domain's FQDN. Ubuntu Instances **must** be reverse-resolvable in DNS before the realm will work. Otherwise, you have to disable reverse DNS in /etc/krb5.conf as follows: ``` sudo vi /etc/krb5.conf ``` ``` [libdefaults] default_realm = EXAMPLE.COM rdns = false ``` 1. Join the instance to the directory with the following command. ``` sudo realm join -U join_account example.com --verbose ``` *join\$1account@example.com* The **sAMAccountName** for an account in the *example.com* domain that has domain join privileges. Enter the password for the account when prompted. For more information about delegating these privileges, see [Delegating directory join privileges for AWS Managed Microsoft AD](directory_join_privileges.md). *example.com* The fully qualified DNS name of your directory. ``` ... * Successfully enrolled machine in realm ``` 1. Set the SSH service to allow password authentication. 1. Open the `/etc/ssh/sshd_config` file in a text editor. ``` sudo vi /etc/ssh/sshd_config ``` 1. Set the `PasswordAuthentication` setting to `yes`. ``` PasswordAuthentication yes ``` 1. Restart the SSH service. ``` sudo systemctl restart sshd.service ``` Alternatively: ``` sudo service sshd restart ``` 1. After the instance has restarted, connect to it with any SSH client and add the AWS Delegated Administrators group to the sudoers list by performing the following steps: 1. Open the `sudoers` file with the following command: ``` sudo visudo ``` 1. Add the following to the bottom of the `sudoers` file and save it. ``` ## Add the "AWS Delegated Administrators" group from the example.com domain. %AWS\ Delegated\ Administrators@example.com ALL=(ALL:ALL) ALL ``` (The above example uses "\$1" to create the Linux space character.) ------ ## Restricting account login access Since all accounts are defined in Active Directory, by default, all the users in the directory can log in to the instance. You can allow only specific users to log in to the instance with **ad\$1access\$1filter** in **sssd.conf**. For example: ``` ad_access_filter = (memberOf=cn=admins,ou=Testou,dc=example,dc=com) ``` *memberOf* Indicates that users should only be allowed access to the instance if they are a member of a specific group. *cn* The common name of the group that should have access. In this example, the group name is *admins*. *ou* This is the organizational unit in which the above group is located. In this example, the OU is *Testou*. *dc* This is the domain component of your domain. In this example, *example*. *dc* This is an additional domain component. In this example, *com*. You must manually add **ad\$1access\$1filter** to your **/etc/sssd/sssd.conf**. Open the **/etc/sssd/sssd.conf** file in a text editor. ``` sudo vi /etc/sssd/sssd.conf ``` After you do this, your **sssd.conf** might look like this: ``` [sssd] domains = example.com config_file_version = 2 services = nss, pam [domain/example.com] ad_domain = example.com krb5_realm = EXAMPLE.COM realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad ad_access_filter = (memberOf=cn=admins,ou=Testou,dc=example,dc=com) ``` In order for the configuration to take effect, you need to restart the sssd service: ``` sudo systemctl restart sssd.service ``` Alternatively, you could use: ``` sudo service sssd restart ``` Since all accounts are defined in Active Directory, by default, all the users in the directory can log in to the instance. You can allow only specific users to log in to the instance with **ad\$1access\$1filter** in **sssd.conf**. For example: ``` ad_access_filter = (memberOf=cn=admins,ou=Testou,dc=example,dc=com) ``` *memberOf* Indicates that users should only be allowed access to the instance if they are a member of a specific group. *cn* The common name of the group that should have access. In this example, the group name is *admins*. *ou* This is the organizational unit in which the above group is located. In this example, the OU is *Testou*. *dc* This is the domain component of your domain. In this example, *example*. *dc* This is an additional domain component. In this example, *com*. You must manually add **ad\$1access\$1filter** to your **/etc/sssd/sssd.conf**. 1. Open the **/etc/sssd/sssd.conf** file in a text editor. ``` sudo vi /etc/sssd/sssd.conf ``` 1. After you do this, your **sssd.conf** might look like this: ``` [sssd] domains = example.com config_file_version = 2 services = nss, pam [domain/example.com] ad_domain = example.com krb5_realm = EXAMPLE.COM realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad ad_access_filter = (memberOf=cn=admins,ou=Testou,dc=example,dc=com) ``` 1. In order for the configuration to take effect, you need to restart the sssd service: ``` sudo systemctl restart sssd.service ``` Alternatively, you could use: ``` sudo service sssd restart ``` ## ID Mapping ID mapping can be performed by two methods to maintain a unified experience between UNIX/Linux User Identifier (UID) and Group Identifier (GID) and Windows and Active Directory Security Identifier (SID) identities. These methods are: 1. Centralized 1. Distributed **Note** Centralized user identity mapping in Active Directory requires Portable Operating System Interface or POSIX. **Centralized user identity mapping** Active Directory or another Lightweight Directory Access Protocol (LDAP) service provides UID and GID to the Linux users. In Active Directory, these identifiers are stored in the users' attributes if the POSIX extension is configured: + UID - The Linux username (String) + UID Number - The Linux User ID number (Integer) + GID Number - The Linux Group ID number (Integer) To configure a Linux instance to use the UID and GID from Active Directory, set `ldap_id_mapping = False` in the sssd.conf file. Before setting this value, verify you have added a UID, UID number and GID number to the users and groups in Active Directory. **Distributed user identity mapping** If Active Directory doesn't have the POSIX extension or if you choose not to centrally manage identity mapping, Linux can calculate the UID and GID values. Linux uses the user's unique Security Identifier (SID) to maintain consistency. To configure distributed user ID mapping, set `ldap_id_mapping = True` in the sssd.conf file. **Common issues** If you set `ldap_id_mapping = False`, sometimes starting the SSSD service will fail. The reason for this failure is due to changing UIDs not supported. We recommend you delete the SSSD cache whenever you change from ID mapping to POSIX attributes or from POSIX attributes to ID mapping. For further details about ID mapping and the ldap\$1id\$1mapping parameters, see the sssd-ldap(8) man page in the Linux command line. ## Connect to the Linux instance When a user connects to the instance using an SSH client, they are prompted for their username. The user can enter the username in either the `username@example.com` or `EXAMPLE\username` format. The response will appear similar to the following, depending on which Linux distribution you are using: **Amazon Linux, Red Hat Enterprise Linux, and CentOS Linux** ``` login as: johndoe@example.com johndoe@example.com's password: Last login: Thu Jun 25 16:26:28 2015 from XX.XX.XX.XX ``` **SUSE Linux** ``` SUSE Linux Enterprise Server 15 SP1 x86_64 (64-bit) As "root" (sudo or sudo -i) use the: - zypper command for package management - yast command for configuration management Management and Config: https://www.suse.com/suse-in-the-cloud-basics Documentation: https://www.suse.com/documentation/sles-15/ Forum: https://forums.suse.com/forumdisplay.php?93-SUSE-Public-Cloud Have a lot of fun... ``` **Ubuntu Linux** ``` login as: admin@example.com admin@example.com@10.24.34.0's password: Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-1057-aws x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage System information as of Sat Apr 18 22:03:35 UTC 2020 System load: 0.01 Processes: 102 Usage of /: 18.6% of 7.69GB Users logged in: 2 Memory usage: 16% IP address for eth0: 10.24.34.1 Swap usage: 0% ``` # Manually joining an Amazon EC2 Linux instance to your AWS Managed Microsoft AD Active Directory using Winbind Manually joining a Linux instance using Winbind You can use the Winbind service to manually join your Amazon EC2 Linux instances to an AWS Managed Microsoft AD Active Directory domain. This enables your existing on-premises Active Directory users to use their Active Directory credentials when accessing the Linux instances joined to your AWS Managed Microsoft AD Active Directory. The following Linux instance distributions and versions are supported: + Amazon Linux AMI 2018.03.0 + Amazon Linux 2 (64-bit x86) + Amazon Linux 2023 AMI + Red Hat Enterprise Linux 8 (HVM) (64-bit x86) + Ubuntu Server 18.04 LTS & Ubuntu Server 16.04 LTS + CentOS 7 x86-64 + SUSE Linux Enterprise Server 15 SP1 **Note** Other Linux distributions and versions may work but have not been tested. ## Join a Linux instance to your AWS Managed Microsoft AD Active Directory Join a Linux instance **Important** Some of the following procedures, if not performed correctly, can render your instance unreachable or unusable. Therefore, we strongly suggest you make a backup or take a snapshot of your instance before performing these procedures. **To join a Linux instance to your directory** Follow the steps for your specific Linux instance using one of the following tabs: ------ #### [ Amazon Linux/CENTOS/REDHAT ] 1. Connect to the instance using any SSH client. 1. Configure the Linux instance to use the DNS server IP addresses of the Directory Service-provided DNS servers. You can do this either by setting it up in the DHCP Options set attached to the VPC or by setting it manually on the instance. If you want to set it manually, see [How do I assign a static DNS server to a private Amazon EC2 instance](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/) in the AWS Knowledge Center for guidance on setting the persistent DNS server for your particular Linux distribution and version. 1. Make sure your Linux instance is up to date. ``` sudo yum -y update ``` 1. Install the required Samba / Winbind packages on your Linux instance. ``` sudo yum -y install authconfig samba samba-client samba-winbind samba-winbind-clients ``` 1. Make a backup of the main `smb.conf` file so you can revert back to it in case of any failure: ``` sudo cp /etc/samba/smb.conf /etc/samba/smb.bk ``` 1. Open the original configuration file [`/etc/samba/smb.conf`] in a text editor. ``` sudo vim /etc/samba/smb.conf ``` Fill in your Active Directory domain environment information as shown in the below example: ``` [global] workgroup = example security = ads realm = example.com idmap config * : rangesize = 1000000 idmap config * : range = 1000000-19999999 idmap config * : backend = autorid winbind enum users = no winbind enum groups = no template homedir = /home/%U@%D template shell = /bin/bash winbind use default domain = false ``` 1. Open the hosts file [`/etc/hosts`] in a text editor. ``` sudo vim /etc/hosts ``` Add your Linux instance private IP address as follows: ``` 10.x.x.x Linux_hostname.example.com Linux_hostname ``` **Note** If you did not specify your IP Address in the `/etc/hosts` file, you might receive the following DNS error while joining the instance to the domain.: `No DNS domain configured for linux-instance. Unable to perform DNS Update. DNS update failed: NT_STATUS_INVALID_PARAMETER` This error means that the join was successful but the [net ads] command was unable to register the DNS record in DNS. 1. Join the Linux instance to Active Directory using the net utility. ``` sudo net ads join -U join_account@example.com ``` *join\$1account@example.com* An account in the *example.com* domain that has domain join privileges. Enter the password for the account when prompted. For more information about delegating these privileges, see [Delegating directory join privileges for AWS Managed Microsoft AD](directory_join_privileges.md). *example.com* The fully qualified DNS name of your directory. ``` Enter join_account@example.com's password: Using short domain name -- example Joined 'IP-10-x-x-x' to dns domain 'example.com' ``` 1. Modify PAM Configuration file, Use the command below to add the necessary entries for winbind authentication: ``` sudo authconfig --enablewinbind --enablewinbindauth --enablemkhomedir --update ``` 1. Set the SSH service to allow password authentication by editing the `/etc/ssh/sshd_config` file.. 1. Open the `/etc/ssh/sshd_config` file in a text editor. ``` sudo vi /etc/ssh/sshd_config ``` 1. Set the `PasswordAuthentication` setting to `yes`. ``` PasswordAuthentication yes ``` 1. Restart the SSH service. ``` sudo systemctl restart sshd.service ``` Alternatively: ``` sudo service sshd restart ``` 1. After the instance has restarted, connect to it with any SSH client and add the root privileges for a domain user or group to the sudoers list by performing the following steps: 1. Open the `sudoers` file with the following command: ``` sudo visudo ``` 1. Add the required groups or users from your Trusting or Trusted domain as follows, and then save it. ``` ## Adding Domain Users/Groups. %domainname\\AWS\ Delegated\ Administrators ALL=(ALL:ALL) ALL %domainname\\groupname ALL=(ALL:ALL) ALL domainname\\username ALL=(ALL:ALL) ALL %Trusted_DomainName\\groupname ALL=(ALL:ALL) ALL Trusted_DomainName\\username ALL=(ALL:ALL) ALL ``` (The above example uses "\$1" to create the Linux space character.) ------ #### [ SUSE ] 1. Connect to the instance using any SSH client. 1. Configure the Linux instance to use the DNS server IP addresses of the Directory Service-provided DNS servers. You can do this either by setting it up in the DHCP Options set attached to the VPC or by setting it manually on the instance. If you want to set it manually, see [How do I assign a static DNS server to a private Amazon EC2 instance](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/) in the AWS Knowledge Center for guidance on setting the persistent DNS server for your particular Linux distribution and version. 1. Make sure your SUSE Linux 15 instance is up to date. 1. Connect the package repository. ``` sudo SUSEConnect -p PackageHub/15.1/x86_64 ``` 1. Update SUSE. ``` sudo zypper update -y ``` 1. Install the required Samba / Winbind packages on your Linux instance. ``` sudo zypper in -y samba samba-winbind ``` 1. Make a backup of the main `smb.conf` file so you can revert back to it in case of any failure: ``` sudo cp /etc/samba/smb.conf /etc/samba/smb.bk ``` 1. Open the original configuration file [`/etc/samba/smb.conf`] in a text editor. ``` sudo vim /etc/samba/smb.conf ``` Fill in your Active directory domain environment information as shown in the below example: ``` [global] workgroup = example security = ads realm = example.com idmap config * : rangesize = 1000000 idmap config * : range = 1000000-19999999 idmap config * : backend = autorid winbind enum users = no winbind enum groups = no template homedir = /home/%U@%D template shell = /bin/bash winbind use default domain = false ``` 1. Open the hosts file [`/etc/hosts`] in a text editor. ``` sudo vim /etc/hosts ``` Add your Linux instance private IP address as follows: ``` 10.x.x.x Linux_hostname.example.com Linux_hostname ``` **Note** If you did not specify your IP Address in the `/etc/hosts` file, you might receive the following DNS error while joining the instance to the domain.: `No DNS domain configured for linux-instance. Unable to perform DNS Update. DNS update failed: NT_STATUS_INVALID_PARAMETER` This error means that the join was successful but the [net ads] command was unable to register the DNS record in DNS. 1. Join the Linux instance to the directory with the following command. ``` sudo net ads join -U join_account@example.com ``` *join\$1account* The sAMAccountName in the *example.com* domain that has domain join privileges. Enter the password for the account when prompted. For more information about delegating these privileges, see [Delegating directory join privileges for AWS Managed Microsoft AD](directory_join_privileges.md). *example.com* The fully-qualified DNS name of your directory. ``` Enter join_account@example.com's password: Using short domain name -- example Joined 'IP-10-x-x-x' to dns domain 'example.com' ``` 1. Modify PAM Configuration file, Use the command below to add the necessary entries for Winbind authentication: ``` sudo pam-config --add --winbind --mkhomedir ``` 1. Open the Name Service Switch configuration file [`/etc/nsswitch.conf`] in a text editor. ``` vim /etc/nsswitch.conf ``` Add the Winbind directive as shown below. ``` passwd: files winbind shadow: files winbind group: files winbind ``` 1. Set the SSH service to allow password authentication by editing the `/etc/ssh/sshd_config` file.. 1. Open the `/etc/ssh/sshd_config` file in a text editor. ``` sudo vim /etc/ssh/sshd_config ``` 1. Set the `PasswordAuthentication` setting to `yes`. ``` PasswordAuthentication yes ``` 1. Restart the SSH service. ``` sudo systemctl restart sshd.service ``` Alternatively: ``` sudo service sshd restart ``` 1. After the instance has restarted, connect to it with any SSH client and add root privileges for a domain user or group, to the sudoers list by performing the following steps: 1. Open the `sudoers` file with the following command: ``` sudo visudo ``` 1. Add the required groups or users from your Trusting or Trusted domain as follows, and then save it. ``` ## Adding Domain Users/Groups. %domainname\\AWS\ Delegated\ Administrators ALL=(ALL:ALL) ALL %domainname\\groupname ALL=(ALL:ALL) ALL domainname\\username ALL=(ALL:ALL) ALL %Trusted_DomainName\\groupname ALL=(ALL:ALL) ALL Trusted_DomainName\\username ALL=(ALL:ALL) ALL ``` (The above example uses "\$1" to create the Linux space character.) ------ #### [ Ubuntu ] 1. Connect to the instance using any SSH client. 1. Configure the Linux instance to use the DNS server IP addresses of the Directory Service-provided DNS servers. You can do this either by setting it up in the DHCP Options set attached to the VPC or by setting it manually on the instance. If you want to set it manually, see [How do I assign a static DNS server to a private Amazon EC2 instance](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/) in the AWS Knowledge Center for guidance on setting the persistent DNS server for your particular Linux distribution and version. 1. Make sure your Linux instance is up to date. ``` sudo apt-get -y upgrade ``` 1. Install the required Samba / Winbind packages on your Linux instance. ``` sudo apt -y install samba winbind libnss-winbind libpam-winbind ``` 1. Make a backup of the main `smb.conf` file so you can revert back to it in case of any failure. ``` sudo cp /etc/samba/smb.conf /etc/samba/smb.bk ``` 1. Open the original configuration file [`/etc/samba/smb.conf`] in a text editor. ``` sudo vim /etc/samba/smb.conf ``` Fill in your Active directory domain environment information as shown in the below example: ``` [global] workgroup = example security = ads realm = example.com idmap config * : rangesize = 1000000 idmap config * : range = 1000000-19999999 idmap config * : backend = autorid winbind enum users = no winbind enum groups = no template homedir = /home/%U@%D template shell = /bin/bash winbind use default domain = false ``` 1. Open the hosts file [`/etc/hosts`] in a text editor. ``` sudo vim /etc/hosts ``` Add your Linux instance private IP address as follows: ``` 10.x.x.x Linux_hostname.example.com Linux_hostname ``` **Note** If you did not specify your IP Address in the `/etc/hosts` file, you might receive the following DNS error while joining the instance to the domain.: `No DNS domain configured for linux-instance. Unable to perform DNS Update. DNS update failed: NT_STATUS_INVALID_PARAMETER` This error means that the join was successful but the [net ads] command was unable to register the DNS record in DNS. 1. Join the Linux instance to Active Directory using the net utility. ``` sudo net ads join -U join_account@example.com ``` *join\$1account@example.com* An account in the *example.com* domain that has domain join privileges. Enter the password for the account when prompted. For more information about delegating these privileges, see [Delegating directory join privileges for AWS Managed Microsoft AD](directory_join_privileges.md). *example.com* The fully qualified DNS name of your directory. ``` Enter join_account@example.com's password: Using short domain name -- example Joined 'IP-10-x-x-x' to dns domain 'example.com' ``` 1. Modify PAM Configuration file, Use the command below to add the necessary entries for Winbind authentication: ``` sudo pam-auth-update --add --winbind --enable mkhomedir ``` 1. Open the Name Service Switch configuration file [`/etc/nsswitch.conf`] in a text editor. ``` vim /etc/nsswitch.conf ``` Add the Winbind directive as shown below. ``` passwd: compat winbind group: compat winbind shadow: compat winbind ``` 1. Set the SSH service to allow password authentication by editing the `/etc/ssh/sshd_config` file.. 1. Open the `/etc/ssh/sshd_config` file in a text editor. ``` sudo vim /etc/ssh/sshd_config ``` 1. Set the `PasswordAuthentication` setting to `yes`. ``` PasswordAuthentication yes ``` 1. Restart the SSH service. ``` sudo systemctl restart sshd.service ``` Alternatively: ``` sudo service sshd restart ``` 1. After the instance has restarted, connect to it with any SSH client and add root privileges for a domain user or group, to the sudoers list by performing the following steps: 1. Open the `sudoers` file with the following command: ``` sudo visudo ``` 1. Add the required groups or users from your Trusting or Trusted domain as follows, and then save it. ``` ## Adding Domain Users/Groups. %domainname\\AWS\ Delegated\ Administrators ALL=(ALL:ALL) ALL %domainname\\groupname ALL=(ALL:ALL) ALL domainname\\username ALL=(ALL:ALL) ALL %Trusted_DomainName\\groupname ALL=(ALL:ALL) ALL Trusted_DomainName\\username ALL=(ALL:ALL) ALL ``` (The above example uses "\$1" to create the Linux space character.) ------ ## Connect to the Linux instance When a user connects to the instance using an SSH client, they are prompted for their username. The user can enter the username in either the `username@example.com` or `EXAMPLE\username` format. The response will appear similar to the following, depending on which Linux distribution you are using: **Amazon Linux, Red Hat Enterprise Linux, and CentOS Linux** ``` login as: johndoe@example.com johndoe@example.com's password: Last login: Thu Jun 25 16:26:28 2015 from XX.XX.XX.XX ``` **SUSE Linux** ``` SUSE Linux Enterprise Server 15 SP1 x86_64 (64-bit) As "root" (sudo or sudo -i) use the: - zypper command for package management - yast command for configuration management Management and Config: https://www.suse.com/suse-in-the-cloud-basics Documentation: https://www.suse.com/documentation/sles-15/ Forum: https://forums.suse.com/forumdisplay.php?93-SUSE-Public-Cloud Have a lot of fun... ``` **Ubuntu Linux** ``` login as: admin@example.com admin@example.com@10.24.34.0's password: Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-1057-aws x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage System information as of Sat Apr 18 22:03:35 UTC 2020 System load: 0.01 Processes: 102 Usage of /: 18.6% of 7.69GB Users logged in: 2 Memory usage: 16% IP address for eth0: 10.24.34.1 Swap usage: 0% ``` # Joining an Amazon EC2 Mac instance to your AWS Managed Microsoft AD Active Directory Joining a Mac instance This procedure manually joins an Amazon EC2 Mac instance to your AWS Managed Microsoft AD Active Directory. ## Prerequisites + Amazon EC2 Mac instances require [Amazon EC2 Dedicated Hosts](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/dedicated-hosts-overview.html). You must allocate a dedicated host and launch an instance onto the host. For more information, see [Launch a Mac instance](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-mac-instances.html#mac-instance-launch) in *Amazon EC2 User Guide*. + We recommend creating a DHCP option set for your AWS Managed Microsoft AD Active Directory. This will allow any instances in your Amazon VPC to point to the specified domain and DNS servers to resolve their domain names. See [Creating or changing a DHCP options set for AWS Managed Microsoft AD](dhcp_options_set.md) for more information. **Note** Dedicated Host pricing varies by the payment option that you select. For more information, see [Pricing and Billing](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/dedicated-hosts-billing.html) in *Amazon EC2 User Guide*. ## Manually joining a Mac instance 1. Use the following SSH command to connect to your Mac instance. For more information about connecting to your Mac instance, see [Connect to your Mac instance.](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-mac-instances.html#connect-to-mac-instance) ``` ssh -i /path/key-pair-name.pem ec2-user@my-instance-public-dns-name ``` 1. After you connect to your Mac instance, create a password for the *ec2-user* account using the following command: ``` sudo passwd ec2-user ``` 1. When prompted at the command line, provide a password for the *ec2-user* account. You can update your operating system and software by following the procedure in [Update the operating system and software](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-mac-instances.html#mac-instance-updates) in *Amazon EC2 User Guide*. 1. Use the following *dsconfigad* command to join your Mac instance to the AWS Managed Microsoft AD Active Directory domain. Make sure to replace the domain name, computer name, and organizational unit with your AWS Managed Microsoft AD Active Directory domain information. For more information, see [Configuring domain access in Directory Utility on Mac](https://support.apple.com/guide/directory-utility/configure-domain-access-diru11f4f748/mac) on Apple website. **Warning** The computer name shouldn't contain a hyphen. Hyphens might prevent the bind to the AWS Managed Microsoft AD Active Directory. ``` sudo dsconfigad -add domainName -computer computerName -username Username -ou "Your-AWS-Delegated-Organizational-Unit" ``` The following example is what the command should look like when joining an administrative user on a Mac instance named **myec2mac01** to the **example.com** domain: ``` sudo dsconfigad -add example.com -computer myec2mac01 -username admin -ou "OU=Computers,OU=Example,DC=Example,DC=com" ``` 1. Use the following command to add the **AWS Delegated Administrators** to the administrative user on your Mac instance: ``` sudo dsconfigad -group "EXAMPLE\aws delegated administrators ``` 1. Use the following command to confirm the AWS Managed Microsoft AD Active Directory domain join was successful: ``` dsconfigad -show ``` You have successfully joined your Mac instance to your AWS Managed Microsoft AD Active Directory. You can now log in to your Mac instance using your AWS Managed Microsoft AD Active Directory credentials. When you first log in to your Mac instance, you should be provided with an option to log in as the "Other" user. At this point, you can use your Active Directory domain credentials to log in to the Mac instance. If you're not provided with "Other" on the log in screen after completing these steps, log in as ec2-user and then log out. To log in using the graphical user interface with a domain user, follow the steps in [Connect to your instance's graphical user interface (GUI)](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-mac-instances.html#mac-instance-vnc) in *Amazon EC2 User Guide*. # Delegating directory join privileges for AWS Managed Microsoft AD Delegating directory join privileges To join a computer to your AWS Managed Microsoft AD, you need an account that has privileges to join computers to the directory. With AWS Directory Service for Microsoft Active Directory, members of the **Admins** and **AWS Delegated Server Administrators** groups have these privileges. However, as a best practice, you should use an account that has only the minimum privileges necessary. The following procedure demonstrates how to create a new group called `Joiners` and delegate the privileges to this group that are needed to join computers to the directory. You must perform this procedure on a computer 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 join privileges for AWS Managed Microsoft AD** 1. Open **Active Directory User and Computers** and select the organizational unit (OU) that has your NetBIOS name in the navigation tree, then select the **Users** OU. **Important** When you launch a AWS Directory Service for Microsoft Active Directory, AWS creates an organizational unit (OU) that contains all your directory's objects. This OU, which has the NetBIOS name that you typed when you created your directory, is located in the domain root. The domain root is owned and managed by AWS. You cannot make changes to the domain root itself, therefore, you must create the **Joiners** group within the OU that has your NetBIOS name. 1. Open the context menu (right-click) for **Users**, choose **New**, and then choose **Group**. 1. In the **New Object - Group** box, type the following and choose **OK**. + For **Group name**, type **Joiners**. + For **Group scope**, choose **Global**. + For **Group type**, choose **Security**. 1. In the navigation tree, select the **Computers** container under your NetBIOS name. From the **Action** menu, choose **Delegate Control**. 1. On the **Delegation of Control Wizard** page, choose **Next**, and then choose **Add**. 1. In the **Select Users, Computers, or Groups** box, type `Joiners` and choose **OK**. If more than one object is found, select the `Joiners` group created above. Choose **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**. 1. Select **Create selected objects in this folder** and **Delete selected objects in this folder**. Then choose **Next**. ![\[Object type\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/aduc_directory_join_linux.png) 1. Select **Read** and **Write**, and then choose **Next**. ![\[Object type\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/aduc_directory_join_permissions.png) 1. Verify the information on the **Completing the Delegation of Control Wizard** page and choose **Finish**. 1. Create a user with a strong password and add that user to the `Joiners` group. This user must be in the **Users** container that is under your NetBIOS name. The user will then have sufficient privileges to connect instances to the directory. # Creating or changing a DHCP options set for AWS Managed Microsoft AD Creating or changing a DHCP options set AWS recommends that you create a DHCP options set for your Directory Service directory and assign the DHCP options set to the VPC that your directory is in. This allows any instances in that VPC to point to the specified domain and DNS servers to resolve their domain names. For more information about DHCP options sets, see [DHCP options sets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html) in the *Amazon VPC User Guide*. **To create a DHCP options set for your directory** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **DHCP Options Sets**, and then choose **Create DHCP options set**. 1. On the **Create DHCP options set** page, enter the following values for your directory: **Name** An optional tag for the options set. **Domain name** The fully qualified name of your directory, such as `corp.example.com`. **Domain name servers** The IP addresses of your AWS-provided directory's DNS servers. You can find these addresses by going to the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, selecting **Directories** and then choosing the correct directory ID. **NTP servers** Leave this field blank. **NetBIOS name servers** Leave this field blank. **NetBIOS node type** Leave this field blank. 1. Choose **Create DHCP options set**. The new set of DHCP options appears in your list of DHCP options. 1. Make a note of the ID of the new set of DHCP options (dopt-*xxxxxxxx*). You use it to associate the new options set with your VPC. **To change the DHCP options set associated with a VPC** After you create a set of DHCP options, you can't modify them. If you want your VPC to use a different set of DHCP options, you must create a new set and associate them with your VPC. You can also set up your VPC to use no DHCP options at all. 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Your VPCs**. 1. Select the VPC, and then choose **Actions**, **Edit VPC settings**. 1. For **DHCP options set**, select an options set or choose **No DHCP options set**, and then choose **Save**. To change the DHCP options set associated with a VPC using command line see the following: + **AWS CLI**: [associate-dhcp-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-dhcp-options.html) + **AWS Tools for Windows PowerShell**: [Register-EC2DhcpOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2DhcpOption.html) # User and group management in AWS Managed Microsoft AD User and group management You can manage users and groups in AWS Managed Microsoft AD. You create a user to represent a person or entity that can access your directory. You can also create a group to grant and deny permissions to more than one user at a time. You can add not only users to a group, but also groups to a group. When you add a user to a group, the user inherits the roles and permissions assigned to the group. When you add a group to a group, the groups share a parent-child relationship, where the child group inherits the roles and permissions assigned to the parent group. You can also copy a user's group memberships into another user. You can manage users and groups with [AWS Directory Service Data](ms_ad_getting_started_directory_service_data.md) using the following methods: + [AWS Management Console](#ms_ad_manage_users_groups_with_console) + [AWS CLI](#ms_ad_manage_users_groups_console_cli) + [AWS Directory Service Data API](https://docs.aws.amazon.com/directoryservicedata/latest/DirectoryServiceDataAPIReference/Welcome.html) + [AWS Tools for Windows PowerShell](https://docs.aws.amazon.com/powershell/latest/reference/items/DirectoryServiceData_cmdlets.html) For a demonstration of the AWS Directory Service Data CLI, see the following YouTube video. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/GJK567cuBu0?si=vb9KNV5JOWDXELSI/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/GJK567cuBu0?si=vb9KNV5JOWDXELSI) Alternatively, you can use a [domain-joined instance](#ms_ad_manage_users_groups_with_instance). ## Manage users and groups with the AWS Management Console AWS Management Console You can manage users and groups with the AWS Management Console with AWS Directory Service Data. Directory Service Data is an extension of Directory Service that provides you with the ability to perform built-in object management tasks. Some of these tasks include creating users and groups and adding users to groups as well as groups to a group. For more information, see [Manage AWS Managed Microsoft AD users and groups with the AWS Management Console](ms_ad_manage_users_groups_procedures.md). **Note** To use this feature, it must be enabled. For more information, see [Enable user and group management](ms_ad_users_groups_mgmt_enable_disable.md). You can only manage users and groups with the AWS Management Console from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). ## Manage users and groups with the AWS CLI AWS CLI You can manage users and groups with the AWS CLI through the [AWS Directory Service Data API](https://docs.aws.amazon.com/directoryservicedata/latest/DirectoryServiceDataAPIReference/Welcome.html). Directory Service Data is an extension of Directory Service that provides you with the ability to perform built-in object management tasks using the `ds-data` namespace. Some of these tasks include creating users and groups and adding users to groups as well as groups to a group. **Create a user with AWS Directory Service Data CLI** The following is an example AWS CLI command that uses the `ds-data` namespace to create a user. ``` aws ds-data create-user --directory-id d-1234567890 --sam-account-name "jane.doe" --region your-Primary-Region-name ``` **Note** To use this AWS CLI, it must be enabled. For more information, see [Enabling or disabling user and group management or AWS Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). You can only manage users and groups with the AWS Directory Service Data CLI from the primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like. [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies) For more information, see [Manage AWS Managed Microsoft AD users and groups with the AWS CLI](ms_ad_manage_users_groups_procedures.md). ## Manage users and groups with AWS Tools for PowerShell AWS Tools for PowerShell The [AWS Tools for PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-welcome.html) provides two separate modules for managing AWS Directory Service: `AWS.Tools.DirectoryService` (DS) and `AWS.Tools.DirectoryServiceData` (DSD). When working with AWS Directory Service, ensure you're using the appropriate module for your intended operation. + The `DirectoryService` module contains cmdlets for managing directory service configuration and administration, including cmdlets like `Enable-DSDirectoryDataAccess`, `Disable-DSDirectoryDataAccess`, and `Reset-DSUserPassword`. + The `DirectoryServiceData` module contains cmdlets for performing operations within a directory, specifically focused on user and group management. These DSD cmdlets include user management operations (`New-DSDUser`, `Get-DSDUser`, `Update-DSDUser`, and `Remove-DSDUser`), group management operations (`New-DSDGroup`, `Get-DSDGroup`, and `Update-DSDGroup`, `Remove-DSDGroup`), group membership management (`Add-DSDGroupMember`, and `Remove-DSDGroupMember`), and search functionality (`Search-DSDUser` and `Search-DSDGroup`). ## Manage users and groups with an on-premise instance or Amazon EC2 instance On-premises or Amazon EC2 instance If the AWS Directory Service Data doesn't support your use case, we recommend managing users and groups with an on-premise or EC2 instance. To create users and groups in an AWS Managed Microsoft AD, you can use any instance (from either on-premises or EC2) that has been joined to your AWS Managed Microsoft AD. You need to be logged in as a user that has privileges to create users and groups. You will also need to install the Active Directory Tools on your instance so you can add your users and groups with the Active Directory Users and Computers tool. + You can deploy a pre-configured EC2 instance with preinstalled Active Directory administrative tools from Directory Service management console. For more information, see [Launching a directory administration instance in your AWS Managed Microsoft AD Active Directory](console_instance.md). + If you need to deploy a self-managed EC2 instance with administrative tools and install the necessary tools, see [Step 3: Deploy an Amazon EC2 instance to manage your AWS Managed Microsoft AD Active Directory](microsoftadbasestep3.md). **Topics** + [ ## Manage users and groups with the AWS Management Console ](#ms_ad_manage_users_groups_with_console) + [ ## Manage users and groups with the AWS CLI ](#ms_ad_manage_users_groups_console_cli) + [ ## Manage users and groups with AWS Tools for PowerShell ](#ms_ad_manage_users_groups_pwershell) + [ ## Manage users and groups with an on-premise instance or Amazon EC2 instance ](#ms_ad_manage_users_groups_with_instance) + [ # Manage AWS Managed Microsoft AD users and groups with the AWS Management Console, AWS CLI, or AWS Tools for PowerShell ](ms_ad_manage_users_groups_procedures.md) + [ # Manage users and groups with an Amazon EC2 instance ](ms_ad_manage_users_groups_ec2.md) # Manage AWS Managed Microsoft AD users and groups with the AWS Management Console, AWS CLI, or AWS Tools for PowerShell Manage users and group with the console, CLI, or PowerShell You can use the AWS Management Console, AWS CLI, or AWS Tools for PowerShell to manage your AWS Managed Microsoft AD users and groups with [AWS Directory Service Data](ms_ad_getting_started_directory_service_data.md). The AWS Directory Service Data CLI uses the `ds-data` namespace. For more information on the AWS CLI, see [ Getting started with AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). For more information on AWS Tools for PowerShell, see [AWS Tools for PowerShell User Guide](https://docs.aws.amazon.com//powershell/latest/userguide/pstools-welcome.html). See the following procedures for more information on creating, viewing, updating, and deleting AWS Managed Microsoft AD users and groups. **Topics** + [ # Enabling or disabling user and group management or AWS Directory Service Data ](ms_ad_users_groups_mgmt_enable_disable.md) + [ # Creating an AWS Managed Microsoft AD user ](ms_ad_create_user.md) + [ # Viewing and updating an AWS Managed Microsoft AD user ](ms_ad_view_update_user.md) + [ # Deleting an AWS Managed Microsoft AD user ](ms_ad_delete_user.md) + [ # Disabling an AWS Managed Microsoft AD user ](ms_ad_disable_user.md) + [ # Resetting and enabling an AWS Managed Microsoft AD user's password ](ms_ad_reset_user_pswd.md) + [ # Creating an AWS Managed Microsoft AD group ](ms_ad_create_group.md) + [ # Viewing and updating an AWS Managed Microsoft AD group's details ](ms_ad_view_update_group.md) + [ # Deleting an AWS Managed Microsoft AD group ](ms_ad_delete_group.md) + [ # Adding and removing AWS Managed Microsoft AD members to groups and groups to groups ](ms_ad_add_remove_user_group.md) + [ # Copying an AWS Managed Microsoft AD group memberships in the AWS Management Console ](copy_group_membership.md) # Enabling or disabling user and group management or AWS Directory Service Data Enabling or disabling AWS Directory Service Data To use user and group management or AWS Directory Service Data, it must be enabled. Once enabled, you can manage users and groups from the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. **Important** You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). For a list of regions that support AWS Directory Service Data, see [Supported AWS Regions for Directory Service Data](regions.md#regions_directory_service_data). Access controls for AWS Directory Service Data are different than access controls for AWS services like Amazon WorkSpaces, Amazon Quick, and Amazon WorkMail. For more information, see [AWS application authorization with Directory Service Data](ad_manage_apps_services_authorization.md#ad_manage_apps_services_authorization_ADSD). ## Enabling AWS Directory Service Data Use the following procedure to enable user and group management or AWS Directory Service Data for an existing AWS Managed Microsoft AD with either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. ------ #### [ AWS Management Console ] You can enable user and group management with the AWS Management Console. **To enable user and group management** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. On the **Directory details** page, to enable user and group management, select **Enable**. 1. In the **Enable user and group management** dialog box, select **Enable**. ------ #### [ AWS CLI ] The following describes how to format a request that enables the AWS Directory Service Data CLI. You must include your Directory ID number in your request. **Note** The enable AWS Directory Service Data CLI commands use `aws ds`. **To enable AWS Directory Service Data CLI** + Open the AWS CLI, and run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` aws ds enable-directory-data-access --directory-id d-1234567890 ``` ------ #### [ AWS Tools for PowerShell ] **To enable Directory Service Data with Tools for PowerShell** + Open PowerShell, and run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` Enable-DSDirectoryDataAccess -DirectoryId d-1234567890 ``` ------ ## Disabling AWS Directory Service Data Use the following procedure to disable user and group management or AWS Directory Service Data for an existing AWS Managed Microsoft AD with either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. ------ #### [ AWS Management Console ] You can disable user and group management with the AWS Management Console. **To disable user and group management** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. On the **Directory details** page, to disable user and group management, select **Disable**. 1. In the **Disable user and group management** dialog box, select **Disable**. ------ #### [ AWS CLI ] The following describes how to format a request that disables the AWS Directory Service Data CLI. You must include your Directory ID number in your request. **Note** The disable AWS Directory Service Data CLI commands use `aws ds`. **To disable AWS Directory Service Data CLI** + Open the AWS CLI, and run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` aws ds disable-directory-data-access --directory-id d-1234567890 ``` ------ #### [ AWS Tools for PowerShell ] **To disable Directory Service Data with Tools for PowerShell** + Open PowerShell, and run the following command, replacing the Directory ID with your AWS Managed Microsoft AD Directory ID: ``` Disable-DSDirectoryDataAccess -DirectoryId d-123456789 ``` ------ # Creating an AWS Managed Microsoft AD user Creating a user Use the following procedure to create a new AWS Managed Microsoft AD user with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. **Before you begin either procedure, you need to complete the following:** + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). ------ #### [ AWS Management Console ] You can create a new AWS Managed Microsoft AD user account in the AWS Management Console. When you create a new user account, you specify the new user's details and determine whether to add the new user to a group or copy another user's group memberships into the new user. For more information, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Group type and group scope](ad_group_type_and_scope.md). **To create an AWS Managed Microsoft AD user with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. On the **Directory details** page, under the **Users** section, choose **Create users account**. 1. The **Specify user details** page opens. Under the **Required information** section, enter a user logon name and password. User logon names must meet the following conditions: + Must be a unique logon name + Can be up to 20 characters long + Can only contain alphanumeric characters + \$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/ + The password must adhere to your password policy requirements. Check with your AWS administrator for more information. **Warning** The user logon name cannot be changed after the user is created. 1. *(Optional)* Under the **Primary information** section, you can enter a first and last name for the user. You can also enter a display name and description for the user. 1. *(Optional)* Under the **Contact methods** section, you can enter an email address and telephone numbers for the user. 1. *(Optional)* Under the **Job-related information** section, you can enter a department, manager, office, and company for the user. 1. *(Optional)* Under the **Address** section, you can enter an address for the user. 1. *(Optional)* Under the **Account settings** section, you can enter notes, a preferred language, and service principal name for the user. For more information on user attributes, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Microsoft documentation](https://learn.microsoft.com/en-us/windows/win32/ad/user-object-attributes). 1. Choose **Next** once you've provided the user account details. 1. On the **Add users to groups - *optional*** page, you can add the user to a new group or to an existing group. You can also copy the group membership of an existing user to the new user. If you don't want to add a user to a group, choose **Next**. Move to Step 12 to continue this procedure. 1. *(Optional)* To create a new group, see [Create a AWS Managed Microsoft AD group](ms_ad_create_group.md). 1. *(Optional)* To add a new user to an existing group: 1. Select the group you want to add the new user to in the **Groups** section. To find groups, enter the group name in the search box. 1. *(Optional)* To copy the group membership of an existing user to a new user: 1. Choose the **Copy group membership from user** tab. To find a user with a group membership you want to copy, enter the user logon name in the search box under the **Users** section. 1. In the **Selected groups** section, select the groups the new user should become a member of. 1. Choose **Next** when you're ready to create the new user account. 1. On the **Review and create user** page, review all the choices you made. Choose **Create user**. 1. After the user is configured, you've taken to the new user's details page. A banner appears stating the user was successfully created. **Important** If you receive an error message telling you that you don't have permission to create a user, follow the instructions in the error message to request that your administrator grant you access. ------ #### [ AWS CLI ] The following describes how to format a request that creates a new AWS Managed Microsoft AD user account with the AWS Directory Service Data CLI. You must include your directory ID number and a user logon name in your request. You can also include other attributes, such as a user display name with the `DisplayName` attribute. For more information, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Group type and group scope](ad_group_type_and_scope.md). **To create an AWS Managed Microsoft AD user with AWS CLI** + Open the AWS CLI, and run the following command, replacing the Directory ID, username, and display name with your AWS Managed Microsoft AD Directory ID and desired credentials: ``` aws ds-data create-user \ --directory-id d-1234567890 \ --sam-account-name "jane.doe" \ --other-attributes '{ "DisplayName" : { "S": "jane.doe"}, "Department":{ "S": "Legal"} }‘ ``` ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that creates a new AWS Managed Microsoft AD user account with AWS Tools for PowerShell. You must include your directory ID number and a user logon name in your request. You can also include other attributes, such as a user display name with the `DisplayName` attribute. For more information, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Group type and group scope](ad_group_type_and_scope.md). **To create an AWS Managed Microsoft AD user with Tools for PowerShell** + Open PowerShell, and run the following command, replacing the Directory ID, username, and display name with your AWS Managed Microsoft AD Directory ID and desired credentials: ``` New-DSDUser ` -DirectoryId d-1234567890 ` -SAMAccountName "jane.doe" ` -OtherAttribute @{ DisplayName = [Amazon.DirectoryServiceData.Model.AttributeValue]@{S = 'jane.doe' } Department = [Amazon.DirectoryServiceData.Model.AttributeValue]@{S = 'Legal' } } ``` ------ # Viewing and updating an AWS Managed Microsoft AD user Viewing and updating a user Use the following procedure to view or update an AWS Managed Microsoft AD user's details with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. ## Viewing an AWS Managed Microsoft AD user's details Viewing a user's details You can view a user's details in the AWS Management Console or AWS CLI. The user's details includes profile and account information and group membership. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Creating an AWS Managed Microsoft AD user](ms_ad_create_user.md). ------ #### [ AWS Management Console ] You can view an AWS Managed Microsoft AD user's details in the AWS Management Console. **To view an AWS Managed Microsoft AD user's details and account details with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Users**. The tab shows a list of users in your directory. 1. Select a user. You're directed to the **User details** screen. The **User details** screen shows the following information: + Groups the user is a member of (group memberships) + Profile details (such as primary information like user logon name, first name, last name, etc.) + Account settings (such as account information like user principal name, service principal name, distinguished name, etc.) + Account status For more information on user attributes, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Microsoft documentation](https://learn.microsoft.com/en-us/windows/win32/ad/user-object-attributes). ------ #### [ AWS CLI ] With the AWS CLI, you can view a user's details, which includes profile and account information and group memberships. **To view an AWS Managed Microsoft AD user's profile and account details with the AWS CLI** The following describes how to view an AWS Managed Microsoft AD user's details with the AWS Directory Service Data CLI. + To view a user's details, open the AWS CLI, and run the following command, replacing the Directory ID and username with your AWS Managed Microsoft AD Directory ID and username: ``` aws ds-data describe-user --directory-id d-1234567890 --sam-account-name "jane.doe" ``` **To view a user's group memberships** The following describes how to view an AWS Managed Microsoft AD user's group membership with the AWS Directory Service Data CLI. + To view a user's group memberships, open the AWS CLI, and run the following command, replacing the Directory ID and username with your AWS Managed Microsoft AD Directory ID and username: ``` aws ds-data list-groups-for-member --directory-id d-1234567890 --sam-account-name "jane.doe" ``` For more information on user attributes, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Microsoft documentation](https://learn.microsoft.com/en-us/windows/win32/ad/user-object-attributes). ------ #### [ AWS Tools for PowerShell ] With Tools for PowerShell, you can view a user's details, which includes profile and account information and group memberships. **To view an AWS Managed Microsoft AD user's profile and account details with Tools for PowerShell** The following describes how to view an AWS Managed Microsoft AD user's details with the Tools for PowerShell. + To view a user's details, open the PowerShell, and run the following command, replacing the Directory ID and username with your AWS Managed Microsoft AD Directory ID and username: ``` Get-DSDUser -DirectoryId d-1234567890 -SAMAccountName "jane.doe" ``` **To view a user's group memberships** The following describes how to view an AWS Managed Microsoft AD user's group membership with the Tools for PowerShell. + To view a user's group memberships, open the PowerShell, and run the following command, replacing the Directory ID and username with your AWS Managed Microsoft AD Directory ID and username: ``` (Get-DSDGroupsForMemberList -DirectoryId d-1234567890 -SAMAccountName "jane.doe").Groups ``` For more information on user attributes, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Microsoft documentation](https://learn.microsoft.com/en-us/windows/win32/ad/user-object-attributes). ------ ## Updating an AWS Managed Microsoft AD user's details Updating a user's details Use the following procedure to update an AWS Managed Microsoft AD user with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, AWS Tools for PowerShell. **Note** The minimum attribute length is 1. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Creating an AWS Managed Microsoft AD user](ms_ad_create_user.md). ------ #### [ AWS Management Console ] You can update an AWS Managed Microsoft AD user's details in the AWS Management Console. **To update an AWS Managed Microsoft AD user's details with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Users**. The tab shows a list of users in your directory. 1. Select a user. To find a user, enter the user logon name in the search box under the **Users** section. You're directed to the **User details** screen. 1. To edit groups the user is a member of, choose **Groups**. From this tab, you can add and remove the user from groups. For more information, see [Add an AWS Managed Microsoft AD member to a group](ms_ad_add_remove_user_group.md). 1. To edit the user's profile details, choose **Profile**, and then choose **Edit**. Or choose **Actions**, and then choose **Edit user**. Make and review your updates, and then choose **Save**. **Warning** The user logon name cannot be changed after the user is created. 1. To edit the user's account settings, choose **User account settings**. Or choose **Actions**, and then choose **Edit user**. Make and review your updates, and then choose **Save**. For more information on user attributes, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Microsoft documentation](https://learn.microsoft.com/en-us/windows/win32/ad/user-object-attributes). ------ #### [ AWS CLI ] The following describes how to format a request that updates an AWS Managed Microsoft AD user's details with AWS Directory Service Data CLI. When you update a user's account, you must include your directory ID number and user logon name. You also must include the update type and attribute you want to update in your request, such as a user last name with the `Surname` parameter. For more information, see [AWS Directory Service Data attributes](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_data_attributes.html). + To update a user's details, open the AWS CLI, and run the following command, replacing the Directory ID, username, user type, and attribute value with your AWS Managed Microsoft AD Directory ID, username, and desired user type and attribute value: ``` aws ds-data update-user --directory-id d-1234567890 --sam-account-name "jane.doe" --update-type "REPLACE" --surname "Doe" ``` **Note** When removing user attributes with [update-user](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds-data/update-user.html) CLI command, you must specify the attribute and the exact value to be removed. To determine user attributes, use [describe-user](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds-data/describe-user.html) command. For more information on user attributes, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Microsoft documentation](https://learn.microsoft.com/en-us/windows/win32/ad/user-object-attributes). ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that updates an AWS Managed Microsoft AD user's details with AWS Tools for PowerShell. When you update a user's account, you must include your directory ID number and user logon name. You also must include the update type and attribute you want to update in your request, such as a user last name with the `Surname` parameter. For more information, see [AWS Directory Service Data attributes](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_data_attributes.html). + To update a user's details, open the PowerShell, and run the following command, replacing the Directory ID, username, user type, and attribute value with your AWS Managed Microsoft AD Directory ID, username, and desired user type and attribute value: ``` Update-DSDUser -DirectoryId d-1234567890 -SAMAccountName "jane.doe" -UpdateType "REPLACE" -Surname "Doe" ``` For more information on user attributes, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Microsoft documentation](https://learn.microsoft.com/en-us/windows/win32/ad/user-object-attributes). ------ # Deleting an AWS Managed Microsoft AD user Deleting a user Use the following procedure to delete an AWS Managed Microsoft AD user with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, AWS Tools for PowerShell. **Important** When you delete a user's account from a directory, all information about the user is removed, including any permissions the user has to access their account and applications. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Creating an AWS Managed Microsoft AD user](ms_ad_create_user.md). ------ #### [ AWS Management Console ] You can delete an AWS Managed Microsoft AD user account in the AWS Management Console. **To delete an AWS Managed Microsoft AD user account with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Users**. The tab shows a list of users in your directory. 1. Choose the user whose account you want to delete. To find a user, enter the user logon name in the search box under the **Users** section. You're directed to the **User details** screen. 1. Choose **Actions**. Then choose **Delete user account** and **Delete user account** again. ------ #### [ AWS CLI ] The following describes how to format a request that deletes an AWS Managed Microsoft AD user's account with the AWS Directory Service Data CLI. **To delete an AWS Managed Microsoft AD user account with AWS CLI** + Open the AWS CLI, and run the following command, replacing the Directory ID and username with your AWS Managed Microsoft AD Directory ID and username: ``` aws ds-data delete-user --directory-id d-1234567890 --sam-account-name "jane.doe" ``` ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that deletes an AWS Managed Microsoft AD user's account with AWS Tools for PowerShell. **To delete an AWS Managed Microsoft AD user account with AWS Tools for PowerShell** + Open PowerShell, and run the following command, replacing the Directory ID and username with your AWS Managed Microsoft AD Directory ID and username: ``` Remove-DSDUser -DirectoryId d-1234567890 -SAMAccountName "jane.doe" ``` ------ # Disabling an AWS Managed Microsoft AD user Disabling a user Use the following procedure to disable an AWS Managed Microsoft AD user with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. **Important** When you disable a user's account, the user loses any permissions to access their account and applications. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Creating an AWS Managed Microsoft AD user](ms_ad_create_user.md). ------ #### [ AWS Management Console ] You can disable an AWS Managed Microsoft AD user account in the AWS Management Console. **To disable an AWS Managed Microsoft AD user account with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Users**. The tab shows a list of users in your directory. 1. Choose the user whose account you want to disable. You're directed to the **User details** screen. 1. Choose **Actions**. Then choose **Disable user account** and **Disable user account** again. **Note** To re-enable your user's account, you must reset the user's password. For more information, see [Resetting and enabling an AWS Managed Microsoft AD user's password](ms_ad_reset_user_pswd.md). ------ #### [ AWS CLI ] The following describes how to format a request that disables an AWS Managed Microsoft AD user account with the AWS Directory Service Data CLI. **To disable an AWS Managed Microsoft AD user account with the AWS CLI** + Open the AWS CLI, and run the following command, replacing the Directory ID and username with your AWS Managed Microsoft AD Directory ID and username: ``` aws ds-data disable-user --directory-id d-1234567890 --sam-account-name "jane.doe" ``` **Note** To re-enable your user account, you must reset the user's password. For more information, see [Resetting and enabling an AWS Managed Microsoft AD user's password](ms_ad_reset_user_pswd.md). ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that disables an AWS Managed Microsoft AD user account with AWS Tools for PowerShell. **To disable an AWS Managed Microsoft AD user account with AWS Tools for PowerShell** + Open PowerShell;, and run the following command, replacing the Directory ID and username with your AWS Managed Microsoft AD Directory ID and username: ``` Disable-DSDUser -DirectoryId d-1234567890 -SAMAccountName "jane.doe" ``` **Note** To re-enable your user account, you must reset the user's password. For more information, see [Resetting and enabling an AWS Managed Microsoft AD user's password](ms_ad_reset_user_pswd.md). ------ # Resetting and enabling an AWS Managed Microsoft AD user's password Resetting and enabling a user's password Use the following procedure to reset an AWS Managed Microsoft AD user's password to enable their account with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, AWS Tools for PowerShell. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Creating an AWS Managed Microsoft AD user](ms_ad_create_user.md). ------ #### [ AWS Management Console ] You can reset an AWS Managed Microsoft AD user's password to enable their account in the AWS Management Console. You can perform this task from either the **Directories** screen or **Directory details** screen. **Directories** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose **Actions**, and then choose **Reset user password and enable account**. 1. Under **User logon name**, enter the user logon name for the user whose password you want to reset. 1. Under **New password**, enter the user's new password. 1. Under **Confirm password**, enter user's new password again. 1. After you confirm the user's new password, choose **Reset password and enable account**. **Directory details** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Users**. The tab shows a list of users in your directory. 1. Select the user whose password you want to reset. 1. Choose **Actions**, and then choose **Reset user password and enable account**. 1. Under **New password**, enter the user's new password. 1. Under **Confirm password**, enter user's new password again. 1. After you confirm the user's new password, choose **Reset password and enable account**. ------ #### [ AWS CLI ] You can reset an AWS Managed Microsoft AD use's password to enable their account with the AWS Directory Service Data CLI. **Note** The reset user's password command uses `aws ds`. **To reset an AWS Managed Microsoft AD user's password with the AWS CLI** + To reset a user's password, open the AWS CLI, and run the following command, replacing the Directory ID, username, and password with your AWS Managed Microsoft AD Directory ID, username, and desired credentials: ``` aws ds reset-user-password --directory-id d-1234567890 --user-name "jane.doe" --new-password "your-password" ``` ------ #### [ AWS Tools for PowerShell ] You can reset an AWS Managed Microsoft AD use's password to enable their account with AWS Tools for PowerShell. **To reset an AWS Managed Microsoft AD user's password with AWS Tools for PowerShell** + To reset a user's password, open the PowerShell, and run the following command, replacing the Directory ID, username, and password with your AWS Managed Microsoft AD Directory ID, username, and desired credentials: ``` Reset-DSUserPassword -DirectoryId d-1234567890 -UserName "jane.doe" -NewPassword "your-password" ``` ------ # Creating an AWS Managed Microsoft AD group Creating a group Use the following procedure to create an AWS Managed Microsoft AD group with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). ------ #### [ AWS Management Console ] You can create a new AWS Managed Microsoft AD group in the AWS Management Console. When you create a new group, you specify the group's details and determine the [group's type and scope](ad_group_type_and_scope.md). You also have the option to add users and child groups to your new group or add your new group to a parent group. **To create an AWS Managed Microsoft AD group with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Group**. The tab shows a list of groups in your AWS Region. 1. Choose **Create group**. You're directed to a procedure where you finish creating your new group. 1. The **Specify group details** page opens. Enter a **Group name**. Group names must meet the following conditions: + Must be unique group name + Can be up to 64 characters long + Can only contain alphanumeric characters + \$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/ **Warning** The group name cannot be changed after the group is created. 1. Choose the **Group type** from one of the following: + **Security** + **Distribution** + To learn more, see [Group type](ad_group_type_and_scope.md#ad_group_type). 1. Choose the **Group scope** from one of the following: + **Domain local** + **Universal** + **Global** + You can turn on **Compare scopes** to display a chart of the similarities and differences between group scopes. To learn more, see [Group scope](ad_group_type_and_scope.md#ad_group_scope). 1. After providing the primary information and contact methods, choose **Next**. 1. The **Add users to group - *Optional*** page opens and you can add users to the new group. To find a user to add to the group, enter the user logon name in the search box under the **Users** section. Select the users you want to add to the group and choose **Next**. 1. The **Add child groups - *Optional*** page opens and you can add existing groups to the new group. The existing groups becomes child groups of the newly created group. When you add a child group to your group, your group becomes the parent group, and the child group inherits all of your group's roles and permissions. To find groups to add, enter the group name in the search box under the **Add child groups** section. Select the children groups you want to add to the new group and choose **Next**. 1. The **Add parent groups - *Optional*** page opens and you can add the new group to existing groups. The new group becomes the parent group of the existing groups. When you add your group to a parent group, your group becomes the child group and inherits all of the parent group's roles and permissions. To find groups to add, enter the group name in the search box under the **Add parent groups** section. Select the parent groups you want to add to the new group and choose **Next**. 1. On the **Review and create group** page, review your choices, and then choose **Create group**. ------ #### [ AWS CLI ] The following describes how to format a request that creates an AWS Managed Microsoft AD group with the AWS Directory Service Data CLI. When you create a new group, you must include your Directory ID number and a group name. You can also add other attributes, such as a group display name with the `DisplayName` attribute. For more information, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Group type and group scope](ad_group_type_and_scope.md). **To create an AWS Managed Microsoft AD group with the AWS CLI** + Open the AWS CLI, and run the following command, replacing the Directory ID, username and group display name with your AWS Managed Microsoft AD Directory ID, username, and desired group display name: ``` aws ds-data create-group \ --directory-id d-1234567890 \ --sam-account-name "your-group-name" \ --other-attributes '{ "DisplayName": { "S": "myGroupDisplayName"} "Description":{ "S": "myGroupDescription"} }' ``` ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that creates an AWS Managed Microsoft AD group with AWS Tools for PowerShell. When you create a new group, you must include your Directory ID number and a group name. You can also add other attributes, such as a group display name with the `DisplayName` attribute. For more information, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Group type and group scope](ad_group_type_and_scope.md). **To create an AWS Managed Microsoft AD group with AWS Tools for PowerShell** + Open PowerShell, and run the following command, replacing the Directory ID, username and group display name with your AWS Managed Microsoft AD Directory ID, username, and desired group display name: ``` New-DSDGroup ` -DirectoryId d-1234567890 ` -SAMAccountName "your-group-name" ` -OtherAttribute @{ DisplayName = [Amazon.DirectoryServiceData.Model.AttributeValue]@{S = 'myGroupDisplayName' } Description = [Amazon.DirectoryServiceData.Model.AttributeValue]@{S = 'myGroupDescription' } } ``` ------ # Viewing and updating an AWS Managed Microsoft AD group's details Viewing and updating a group Use the following procedure to view or update an AWS Managed Microsoft AD group's details with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. ## Viewing an AWS Managed Microsoft AD group's detail Viewing a group's detail You can view or update a group's details in the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Creating an AWS Managed Microsoft AD group](ms_ad_create_group.md). ------ #### [ AWS Management Console ] You can view an AWS Managed Microsoft AD group's details in the AWS Management Console. **To view AWS Managed Microsoft AD group's details with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Group**. The tab shows a list of groups in your AWS Region. 1. Choose a group. To find groups, enter the group name in the search box under the **Groups** section. You're directed to the **Group details** screen. The **Group details** screen shows the following information: + **Member** tab lists the users and child groups that are members of your group. + **Parent groups** tab lists the parent groups that your group is a member of. + **Properties** tab lists the group properties (such as primary information like group name, group display name, etc.). ------ #### [ AWS CLI ] You can view an AWS Managed Microsoft AD group's details with the AWS Directory Service Data CLI. **To view an AWS Managed Microsoft AD group's details with the AWS CLI** The following describes how to view an AWS Managed Microsoft AD group's details with the AWS CLI. + To view a group's details, open the AWS CLI, and run the following command, replacing the Directory ID and group name with your AWS Managed Microsoft AD Directory ID and group name: ``` aws ds-data describe-group --directory-id d-1234567890 --sam-account-name "your-group-name" ``` **To view an AWS Managed Microsoft AD group's group members with the AWS CLI** The following describes how to view an AWS Managed Microsoft AD group's members with the AWS CLI. + To view a group's details, open the AWS CLI, and run the following command, replacing the Directory ID and group name with your AWS Managed Microsoft AD Directory ID and group name: ``` aws ds-data list-group-members --directory-id d-1234567890 --sam-account-name "your-group-name" ``` ------ #### [ AWS Tools for PowerShell ] You can view an AWS Managed Microsoft AD group's details with AWS Tools for PowerShell. **To view an AWS Managed Microsoft AD group's details with AWS Tools for PowerShell** The following describes how to view an AWS Managed Microsoft AD group's details with the Tools for PowerShell. + To view a group's details, open the PowerShell, and run the following command, replacing the Directory ID and group name with your AWS Managed Microsoft AD Directory ID and group name: ``` Get-DSDGroup -DirectoryId d-1234567890 -SAMAccountName "your-group-name" ``` **To view an AWS Managed Microsoft AD group's group members with AWS Tools for PowerShell** The following describes how to view an AWS Managed Microsoft AD group's members with the Tools for PowerShell. + To view a group's details, open the PowerShell, and run the following command, replacing the Directory ID and group name with your AWS Managed Microsoft AD Directory ID and group name: ``` (Get-DSDGroupMemberList -DirectoryId d-1234567890 -SAMAccountName "your-group-name").Members ``` ------ ## Updating an AWS Managed Microsoft AD group's details Updating a group's details Use the following procedure to update an AWS Managed Microsoft AD group's details with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Creating an AWS Managed Microsoft AD group](ms_ad_create_group.md). ------ #### [ AWS Management Console ] You can update a group's details with the AWS Management Console. For more information, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Group type and group scope](ad_group_type_and_scope.md) **To update an AWS Managed Microsoft AD group's details with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Group**. The tab shows a list of groups in your AWS Region. 1. Choose a group. To find groups, enter the group name in the search box under the **Groups** section. You're directed to the **Group details** screen. 1. To edit users and child groups that are members of your group, choose **Members**. From this tab, you can add and remove users and child groups from your group. For more information, see [Adding and removing members to groups and groups to groups](ms_ad_add_remove_user_group.md). 1. To edit parent groups that your group is a member of, choose **Parent groups**. From this tab, you can add and remove your group from parent groups. For more information, see [Adding and removing members to groups and groups to groups](ms_ad_add_remove_user_group.md). 1. To edit your group properties, choose **Properties**, and then choose **Edit**. Or choose **Actions**, and then choose **Edit group**. Make and review your updates, and then choose **Save**. ------ #### [ AWS CLI ] The following describes how to format a request that updates an AWS Managed Microsoft AD group's details with the AWS Directory Service Data CLI. When you update a group, you must include your directory ID number and group name. You also must include the update type and attribute you want to update in your request, such as a group email address with the `EmailAddress` parameter. For more information, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Group type and group scope](ad_group_type_and_scope.md). + **To update an AWS Managed Microsoft AD group's details with the AWS CLI** To update a group's details, open the AWS CLI, and run the following command, replacing the Directory ID, group name, update type, and attribute with your AWS Managed Microsoft AD Directory ID, group name, and desired update type and attribute: ``` aws ds-data update-group --directory-id d-1234567890 --sam-account-name "your-group-name" --update-type "REPLACE" --group-scope "global" ``` ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that updates an AWS Managed Microsoft AD group's details with AWS Tools for PowerShell. When you update a group, you must include your directory ID number and group name. You also must include the update type and attribute you want to update in your request, such as a group email address with the `EmailAddress` parameter. For more information, see [AWS Directory Service Data attributes](ad_data_attributes.md) and [Group type and group scope](ad_group_type_and_scope.md). + **To update an AWS Managed Microsoft AD group's details with AWS Tools for PowerShell** To update a group's details, open the PowerShell, and run the following command, replacing the Directory ID, group name, update type, and attribute with your AWS Managed Microsoft AD Directory ID, group name, and desired update type and attribute: ``` Update-DSDGroup -DirectoryId d-1234567890 -SAMAccountName "your-group-name" -UpdateType "REPLACE" -GroupScope "global" ``` ------ # Deleting an AWS Managed Microsoft AD group Deleting a group Use the following procedure to delete an AWS Managed Microsoft AD group with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. **Important** When you delete a group, all information about the group is removed, including any permissions that group members inherit. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Create an AWS Managed Microsoft AD group](ms_ad_create_group.md). ------ #### [ AWS Management Console ] You can delete an AWS Managed Microsoft AD group in the AWS Management Console. **To delete an AWS Managed Microsoft AD group with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Group**. The tab shows a list of groups in your AWS Region. 1. Choose the group that you want to delete. To find groups, enter the group name in the search box under the **Groups** section. You're directed to the **Group details** screen. 1. Choose **Delete group**. A dialog box appears where you can choose **Confirm** to delete the group. ------ #### [ AWS CLI ] The following describes how to format a request that deletes an AWS Managed Microsoft AD group with the AWS Directory Service Data CLI. **To delete an AWS Managed Microsoft AD group with the AWS CLI** + Open the AWS CLI, and run the following command, replacing the Directory ID and group name with your AWS Managed Microsoft AD Directory ID and group name: ``` aws ds-data delete-group --directory-id d-1234567890 --sam-account-name "your-group-name" ``` ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that deletes an AWS Managed Microsoft AD group with the AWS Tools for PowerShell. **To delete an AWS Managed Microsoft AD group with the AWS Tools for PowerShell** + Open PowerShell, and run the following command, replacing the Directory ID and group name with your AWS Managed Microsoft AD Directory ID and group name: ``` Remove-DSDGroup -DirectoryId d-1234567890 -SAMAccountName "your-group-name" ``` ------ # Adding and removing AWS Managed Microsoft AD members to groups and groups to groups Adding and removing members to groups and groups to groups With the [AWS Directory Service Data API](https://docs.aws.amazon.com/directoryservicedata/latest/DirectoryServiceDataAPIReference/Welcome.html), a member can be a user, group, or computer. A user represents a person or entity that can access your directory. Groups allow you to grant and deny permissions to more than one user at a time. Use the following procedures to add or remove an AWS Managed Microsoft AD user to a group or group to another group with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. ## Adding a user to a group Use the following procedure to add an AWS Managed Microsoft AD user to a group with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. **Important** When you add an AWS Managed Microsoft AD user to a group, the user inherits the roles and permissions assigned to the group. These roles and permissions are part of the user's group memberships. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Create an AWS Managed Microsoft AD user](ms_ad_create_user.md). + [Create an AWS Managed Microsoft AD group](ms_ad_create_group.md). ------ #### [ AWS Management Console ] You can add an AWS Managed Microsoft AD member to a group with the AWS Management Console. **To add AWS Managed Microsoft AD user to a group with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Groups**. To find groups, enter the group name in the search box under the **Groups** section. The tab shows a list of groups in your AWS Region. 1. Choose a group. You're directed to the **Group details** screen. 1. Choose **Members**. The tab shows a list of users and child groups by member type in your group. 1. Under **Members** tab, Choose **Add member**. 1. Under **Members**, select the user you want to add to your group, and then choose **Add member to group**. To find members, enter the user logon name for users and group name for groups in the search box under the **Members** section. ------ #### [ AWS CLI ] The following describes how to format a request that adds an AWS Managed Microsoft AD member to a group with the AWS Directory Service Data CLI. **To add an AWS Managed Microsoft AD user to a group with the AWS CLI** + To add a user to a group, open the AWS CLI, and run the following command, replacing the Directory ID, group and member names with your AWS Managed Microsoft AD Directory ID and group and member names: ``` aws ds-data add-group-member --directory-id d-1234567890 --group-name "your-group-name" --member-name "jane.doe" ``` ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that adds an AWS Managed Microsoft AD member to a group with AWS Tools for PowerShell. **To add an AWS Managed Microsoft AD user to a group with AWS Tools for PowerShell** + To add a user to a group, open the PowerShell, and run the following command, replacing the Directory ID, group and member names with your AWS Managed Microsoft AD Directory ID and group and member names: ``` Add-DSDGroupMember -DirectoryId d-1234567890 -GroupName "your-group-name" -MemberName "jane.doe" ``` ------ ## Removing a user from a group With the [AWS Directory Service Data API](https://docs.aws.amazon.com/directoryservicedata/latest/DirectoryServiceDataAPIReference/Welcome.html), a member can be a user, group, or computer. A user represents a person or entity that can access your directory. Groups allow you to grant and deny permissions to more than one user at a time. Use the following procedure to remove an AWS Managed Microsoft AD user to a group with user and group management or AWS Directory Service Data in either the AWS Management Console, AWS CLI, or AWS Tools for PowerShell. **Important** When you remove an AWS Managed Microsoft AD user from a group, the user loses access to the roles and permissions assigned to the group. These roles and permissions are part of the group's memberships. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Create an AWS Managed Microsoft AD user](ms_ad_create_user.md). + [Create an AWS Managed Microsoft AD group](ms_ad_create_group.md). ------ #### [ AWS Management Console ] You can remove an AWS Managed Microsoft AD member from a group with the AWS Management Console. **To remove an AWS Managed Microsoft AD user from a group with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Groups**. The tab shows a list of groups in your AWS Region. 1. Choose a group. To find groups, enter the group name in the search box under the **Groups** section. You're directed to the **Group details** screen. 1. Choose **Members**. The tab shows a list of users and child groups by member type in your group. 1. Select the user you want to remove from your group, and then choose **Remove**. To find users, enter the user logon name in the search box under the **Members** section. 1. Confirm that you want to remove the user from your group, and then choose **Remove** again. ------ #### [ AWS CLI ] The following describes how to format a request that removes an AWS Managed Microsoft AD member from a group with the AWS Directory Service Data CLI. **To remove an AWS Managed Microsoft AD user from a group with AWS CLI** + To remove a user to a group, open the AWS CLI, and run the following command, replacing the Directory ID, group and member names with your AWS Managed Microsoft AD Directory ID, group and member names: ``` aws ds-data remove-group-member --directory-id d-1234567890 --group-name "your-group-name" --member-name "jane.doe" ``` ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that removes an AWS Managed Microsoft AD member from a group with AWS Tools for PowerShell. **To remove an AWS Managed Microsoft AD user from a group with AWS Tools for PowerShell** + To remove a user to a group, open the PowerShell, and run the following command, replacing the Directory ID, group and member names with your AWS Managed Microsoft AD Directory ID, group and member names: ``` Remove-DSDGroupMember -DirectoryId d-1234567890 -GroupName "your-group-name" -MemberName "jane.doe" ``` ------ ## Adding a group to a group When you add an AWS Managed Microsoft AD group to another group, the groups share a parent-child relationship. The child group gains access to the roles and permissions that are assigned to the parent group. You can add a child group to your group and your group to a parent group. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Create an AWS Managed Microsoft AD group](ms_ad_create_group.md). ------ #### [ AWS Management Console ] You can add an AWS Managed Microsoft AD group to a group with the AWS Management Console. **To add a child group to your group with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Groups**. The tab shows a list of groups in your AWS Region. 1. Choose a group. To find groups, enter the group name in the search box under the **Groups** section. You're directed to the **Group details** screen. 1. Choose **Members**. The tab shows a list of users and child groups by member type in your group. 1. Choose **Add member**. 1. Under **Members**, select the child group(s) you want to add to your group, and then choose **Add member to group**. **To add a parent group to a group with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Groups**. The tab shows a list of groups in your AWS Region. 1. Choose a group. To find groups, enter the group name in the search box under the **Groups** section. You're directed to the **Group details** screen. 1. Choose **Parent groups**. The tab shows a list of groups that your group is a member of. 1. Choose **Add parent groups**. 1. Under **Groups**, select the group(s) you want to add your group to, and then choose **Add parent groups** again. ------ #### [ AWS CLI ] The following describes how to format a request that adds an AWS Managed Microsoft AD group to a group with the AWS Directory Service Data CLI. **To add a child group to your group with the AWS CLI** + To add a child group to a parent group, open the AWS CLI, and run the following command, replacing the Directory ID, group and member names with your AWS Managed Microsoft AD Directory ID, group and member names: ``` aws ds-data add-group-member --directory-id d-1234567890 --group-name "parent-group-name" --member-name "child-group-name" ``` ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that adds an AWS Managed Microsoft AD group to a group with AWS Tools for PowerShell. **To add a child group to your group with AWS Tools for PowerShell** + To add a child group to a parent group, open the PowerShell, and run the following command, replacing the Directory ID, group and member names with your AWS Managed Microsoft AD Directory ID, group and member names: ``` Add-DSDGroupMember -DirectoryId d-1234567890 -GroupName "parent-group-name" -MemberName "child-group-name" ``` ------ ## Removing a group from a group When you remove an AWS Managed Microsoft AD group from another group, the groups no longer share a parent-child relationship. The child group loses access to the roles and permissions that are assigned to the parent group. You can remove a child group from your group and your group from a parent group. **Before you begin either procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Create an AWS Managed Microsoft AD group](ms_ad_create_group.md). ------ #### [ AWS Management Console ] You can remove an AWS Managed Microsoft AD group to a group with the AWS Management Console. **To remove a child group from your group with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Groups**. The tab shows a list of groups in your AWS Region. 1. Choose a group. You're directed to the **Group details** screen. To find groups, enter the group name in the search box under the **Groups** section. 1. Choose **Members**. The tab shows a list of users and child groups by member type in your group. 1. Select the child group(s) you want to remove from your group, and then choose **Remove**. 1. Confirm the child group(s) you want to remove from your group, and then choose **Remove** again. **To remove your group from a parent group with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Groups**. The tab shows a list of groups in your AWS Region. 1. Choose a group. You're directed to the **Group details** screen. To find groups, enter the group name in the search box under the **Groups** section. 1. Choose **Parent groups**. The tab shows a list of groups that your group is a member of. 1. Select the parent group you want to remove your group from, and then choose **Remove parent groups**. 1. Confirm the parent group you want to remove your group from, and then choose **Remove parent groups** again. ------ #### [ AWS CLI ] The following describes how to format a request that removes an AWS Managed Microsoft AD group to a group with the AWS Directory Service Data CLI. + **To remove a child group from a parent group with the AWS CLI** To add remove a child group from a parent group, open the AWS CLI, and run the following command, replacing the Directory ID, group and member names with your AWS Managed Microsoft AD Directory ID, group and member names: ``` aws ds-data remove-group-member --directory-id d-1234567890 --group-name "parent-group-name" --member-name "child-group-name" ``` ------ #### [ AWS Tools for PowerShell ] The following describes how to format a request that removes an AWS Managed Microsoft AD group to a group with AWS Tools for PowerShell. + **To remove a child group from a parent group with AWS Tools for PowerShell** To add remove a child group from a parent group, open the PowerShell, and run the following command, replacing the Directory ID, group and member names with your AWS Managed Microsoft AD Directory ID, group and member names: ``` Remove-DSDGroupMember -DirectoryId d-1234567890 -GroupName "parent-group-name" -MemberName "child-group-name" ``` ------ # Copying an AWS Managed Microsoft AD group memberships in the AWS Management Console Copying a group memberships in the console You can copy group memberships from one AWS Managed Microsoft AD user into another user in the AWS Management Console. Group memberships are the roles and permissions that a user inherits when you add them to a group. **Before you begin this procedure, you need to complete the following:** + [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + To use user and group management or AWS Directory Service Data CLI, it must be enabled. For more information, see [Enable user and group management or Directory Service Data](ms_ad_users_groups_mgmt_enable_disable.md). + You can only enable this feature from the Primary AWS Region for your directory. For more information, see [Primary vs additional Regions](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/multi-region-global-primary-additional.html). + You'll need the necessary IAM permissions to use AWS Directory Service Data. For more information, see [Directory Service API permissions: Actions, resources, and conditions reference](UsingWithDS_IAM_ResourcePermissions.md). To get started granting permissions to your users and workloads, you can use AWS managed policies like [AWS managed policy: AWSDirectoryServiceDataFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataFullAccess) or [AWS managed policy: AWSDirectoryServiceDataReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSDirectoryServiceDataReadOnlyAccess). For more information, see [Security best practices in IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies). + [Create an AWS Managed Microsoft AD group](ms_ad_create_group.md). **To copy AWS Managed Microsoft AD group memberships with the AWS Management Console** 1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. From the navigation pane, choose **Active Directory**, and then choose **Directories**. You're directed to the **Directories** screen where you can view a list of directories in your AWS Region. 1. Choose a directory. You're directed to the **Directory details** screen. 1. Choose **Groups**. The tab shows a list of groups in your AWS Region. 1. Choose the user whose account you want to copy their group membership. To find a user, enter the user logon name in the search box under the **Users** section. You're directed to the **User details** screen. 1. Choose **Copy all group memberships**. You're directed to a procedure where you can specify which groups you want to copy. 1. For **Verify groups to copy**, under **Groups to copy**, select the groups with roles and permissions you want to copy, and then choose **Next**. 1. For **Select destination account**, under **Account type**, choose **Existing user account** to copy group memberships into an existing user account. Alternatively, choose **New user account** to create a new user and copy group memberships into the new user account. To find a group, enter the group's name in the search box under the **Selected groups** section. 1. *(Optional)* If you choose **Existing user account**, select destination accounts where you want to copy the roles and permissions into, and then choose **Next**. 1. *(Optional)* If you choose **New user account**, complete the procedure, and then choose **Next**. For information about creating a user, see [Creating a user](ms_ad_create_user.md). 1. For **Review and copy group memberships**, review your choices, and then choose **Copy group membership**. # Manage users and groups with an Amazon EC2 instance This section includes procedures for managing users and groups with an Amazon EC2 instance that's joined to your AWS Managed Microsoft AD. We recommend managing users and groups with an Amazon EC2 instance if the Directory Service Data API doesn't support your use case. For more information, see the [AWS Directory Service Data API Reference](https://docs.aws.amazon.com/directoryservicedata/latest/DirectoryServiceDataAPIReference/Welcome.html). **Note** Before you complete any of the procedures in the following topics, you must install the Active Directory administration tools. For more information, see [Install the Active Directory administration tools](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html). **Topics** + [ # Installing Active Directory Administration Tools for AWS Managed Microsoft AD ](ms_ad_install_ad_tools.md) + [ # Creating an AWS Managed Microsoft AD user ](ms_ad_manage_users_groups_create_user.md) + [ # Delete a user's account with an Amazon EC2 instance ](ms_ad_manage_users_groups_delete_user.md) + [ # Resetting an AWS Managed Microsoft AD user password ](ms_ad_manage_users_groups_reset_password.md) + [ # Creating an AWS Managed Microsoft AD group ](ms_ad_manage_users_groups_create_group.md) + [ # Adding an AWS Managed Microsoft AD user to a group ](ms_ad_manage_users_groups_add_user_to_group.md) # Installing Active Directory Administration Tools for AWS Managed Microsoft AD Installing AD Administration Tools You can manage your AWS Managed Microsoft AD Active Directory using Active Directory Domain Services and Active Directory Lightweight Directory Services Tools. To use Active Directory Domain Services and Active Directory Lightweight Directory Services Tools, you will need to install them. The following procedures walks you through how you can install these tools on an Amazon EC2 Windows Server instance or with a PowerShell command. Alternatively, you can launch a directory administration EC2 instance which already has these tools installed. ------ #### [ EC2 Windows Server instance ] Before you can begin this procedure, complete the following: 1. Create an AWS Managed Microsoft AD Active Directory. For more information, see [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). 1. Launch and join an EC2 Windows Server instance to your AWS Managed Microsoft AD Active Directory. The EC2 instance needs the following policies to create users and groups: **AmazonSSMManagedInstanceCore** and **AmazonSSMDirectoryServiceAccess**. For more information, see [Launching a directory administration instance in your AWS Managed Microsoft AD Active Directory](console_instance.md) and [Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD Active Directory](launching_instance.md). 1. You will need the credentials for your Active Directory domain Administrator. These credentials were created when the AWS Managed Microsoft AD was created. If you followed the procedure in [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory), your Administrator username includes your NetBIOS name, **corp\$1admin**. **Installing Active Directory administration tools on a EC2 Windows Server instance** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the Amazon EC2 console, choose **Instances**, select the Windows Server instance, and then choose **Connect**. 1. In the **Connect to instance** page, choose **RDP client**. 1. In the **RDP client** tab, choose **Download Remote Desktop File**, then choose **Get Password** to retrieve your password. 1. In the **Get Windows password**, choose **Upload private key file**. Choose the .pem private key file associated with the Windows Server instance. After uploading the private key file, select **Decrypt password**. 1. In the **Windows Security** dialog box, copy your local administrator credentials for the Windows Server computer to sign in. The username can be in the following formats: ***NetBIOS-Name*\$1admin** or ***DNS-Name*\$1admin**. For example, **corp\$1admin** would be the username if you followed the procedure in [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). 1. Once signed in to the Windows Server instance, open **Server Manager** from the Start menu by choosing **Server Manager**. 1. In the **Server Manager Dashboard**, choose **Add roles and features**. 1. In the **Add Roles and Features Wizard** choose **Installation Type**, select **Role-based or feature-based installation**, and choose **Next**. 1. Under **Server Selection**, make sure the local server is selected, and choose **Features** in the left navigation pane. 1. In the **Features** tree, select and open **Remote Server Administration Tools**, **Role Administration Tools**, and **AD DS and AD LDS Tools**. With **AD DS and AD LDS Tools** selected, **Active Directory module for PowerShell**, **AD DS Tools**, and **AD LDS Snap-ins and Command-Line Tools** are selected. Scroll down and select **DNS Server Tools**, and then choose **Next**. ![\[Installing Microsoft AD Tools, the Add Roles and Features Wizard Features Tree with tools selected.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/ms-install-ad-tools.png) 1. Review the information and choose **Install**. When the feature installation is finished, the Active Directory Domain Services and Active Directory Lightweight Directory Services Tools are available from the Start menu in the **Administrative Tools** folder. ------ #### [ PowerShell ] You can install the Active Directory Administration Tools using PowerShell. For example, you can install the Active Directory remote administration tools from a PowerShell prompt using `Install-WindowsFeature RSAT-ADDS`. For more information, see [Install-WindowsFeature](https://docs.microsoft.com/en-us/powershell/module/servermanager/install-windowsfeature?view=winserver2012r2-ps) on the Microsoft website. ------ #### [ Directory administration instance ] You can launch a directory administration EC2 instance in the AWS Management Console that already has the Active Directory Domain Services and Active Directory Lightweight Directory Services Tools installed by following the procedures in [Launching a directory administration instance in your AWS Managed Microsoft AD Active Directory](console_instance.md). ------ # Creating an AWS Managed Microsoft AD user Creating a user You can create AWS Managed Microsoft AD users with the Active Directory Administration Tools and PowerShell. Before you can create user with the Active Directory Administration Tools, you will need to complete the procedure in [Installing Active Directory Administration Tools for AWS Managed Microsoft AD](ms_ad_install_ad_tools.md). ------ #### [ Active Directory Administration Tools ] Use the following procedure to create an AWS Managed Microsoft AD user with Active Directory Administration Tools. 1. Connect to the instance where the Active Directory Administration Tools were installed. 1. Open the Active Directory Users and Computers tool from the Windows Start menu. There is a shortcut to this tool found in the **Windows Administrative Tools** folder. **Tip** You can run the following from a command prompt on the instance to open the Active Directory Users and Computers tool box directly. ``` %SystemRoot%\system32\dsa.msc ``` 1. In the directory tree, select an OU under your directory's NetBIOS name OU where you want to store your user (for example, **corp\$1Users**). For more information about the OU structure used by directories in AWS, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). ![\[Active Directory Users and Computers tool showing example OU structure.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/create-security-groups-OU.png) 1. On the **Action** menu, choose **New**, and then choose **User** to open the new user wizard. 1. On the first page of the wizard, enter the values for the following fields, and then choose **Next**. + **First name** + **Last name** + **User logon name** 1. On the second page of the wizard, enter a temporary password in **Password** and **Confirm Password**. Make sure the **User must change password at next logon** option is selected. None of the other options should be selected. Choose **Next**. 1. On the third page of the wizard, verify that the new user information is correct and choose **Finish**. The new user will appear in the **Users** folder. ------ #### [ PowerShell ] Use the following procedure to create an AWS Managed Microsoft AD user with PowerShell. 1. Connect to the instance joined to your Active Directory domain as the Active Directory administrator. 1. Open PowerShell. 1. Type the following command replacing the username **jane.doe** with the username of the user you want to create. You will be prompted by PowerShell to provide a password for the new user. For more information on Active Directory password complexity requirements, see [Microsoft documentation](https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements). For more information on the New-ADUser command, see [Microsoft documentation](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-aduser?view=windowsserver2022-ps). ``` New-ADUser -Name "jane.doe" -Enabled $true -AccountPassword (Read-Host -AsSecureString 'Password') ``` ------ # Delete a user's account with an Amazon EC2 instance You can use the following procedure to delete a user with an Amazon EC2 instance that's joined to your AWS Managed Microsoft AD. **Note** Before you complete this procedure, you must install the Active Directory administration tools. For more information, see [Install the Active Directory administration tools](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html). **To delete a user** 1. Open the Active Directory Users and Computers tool. There is a shortcut to this tool in the **Windows Administrative Tools** folder. **Tip** You can run the following from a command prompt on the instance to open the Active Directory Users and Computers tool box directly. ``` %SystemRoot%\system32\dsa.msc ``` 1. In the directory tree, select the OU containing the user that you want to delete (for example, Corp\$1Users). 1. Select the user you wish to delete. On the **Action** menu, choose **Delete**. 1. A dialog box will appear prompting you to confirm you want to delete the user. Choose **Yes** to delete the user. Deleted users are stored temporarily in the AD Recycle Bin. For more information about the AD Recycle Bin, see [The AD Recycle Bin: Understanding, Implementing, Best Practices, and Troubleshooting](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/the-ad-recycle-bin-understanding-implementing-best-practices-and/ba-p/396944) in Microsoft's Ask the Directory Services Team blog. # Resetting an AWS Managed Microsoft AD user password Resetting a user password Users must adhere to password policies as defined in the Active Directory. Sometimes this can get the best of users, including the Active Directory administrator, and they forget their password. When this happens, you can quickly reset the user's password using Directory Service if the user resides AWS Managed Microsoft AD. You must be signed in as a user with the necessary permissions to reset passwords. For more information about permissions, see [Overview of managing access permissions to your Directory Service resources](IAM_Auth_Access_Overview.md). You can reset the password for any user in your Active Directory with the following exceptions: + You can reset the password for any user within the Organizational Unit (OU) that is based off of the NetBIOS name you used when you created your Active Directory. For example, if you followed the procedure in [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory) your NetBIOS name would be CORP and the users passwords you could reset would be members of Corp/Users OU. + You cannot reset the password of any user outside of the OU that is based off the NetBIOS name you used when you created your Active Directory. For example, you cannot reset the password for a user in **AWS Reserved OU**. For more information about the OU structure for AWS Managed Microsoft AD, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). For more information on how the password policies are applied when a password is reset in AWS Managed Microsoft AD, see [How password policies are applied](ms_ad_password_policies.md#how_password_policies_applied). **You can use any of the following tools to reset an AWS Managed Microsoft AD user password:** + AWS Management Console + AWS CLI + PowerShell ------ #### [ AWS Management Console ] Use the following procedure to reset an AWS Managed Microsoft AD user password with the AWS Management Console. 1. In the [Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, under **Active Directory**, choose **Directories**, and then select the Active Directory in the list where you want to reset a user password. 1. On the **Directory details** page, choose **Actions**, and then choose **Reset user password**. 1. In the **Reset user password** dialog, in **Username** type the username of the user whose password needs to change. 1. Type a password in **New password** and **Confirm password**, and then choose **Reset password**. ------ #### [ AWS CLI ] Use the following procedure to reset an AWS Managed Microsoft AD user password with the AWS CLI. 1. To install the AWS CLI, see [Install or update the latest version of the AWS CLI](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html). 1. Open the AWS CLI. 1. Type the following command and replace the Directory ID, username **jane.doe**, and password **P@ssw0rd** with your Active Directory Directory ID and desired credentials. See [reset-user-password](https://docs.aws.amazon.com/cli/latest/reference/ds/reset-user-password.html) in the *AWS CLI Command Reference* for more information. ``` aws ds reset-user-password --directory-id d-1234567890 --user-name "jane.doe" --new-password "P@ssw0rd" ``` ------ #### [ PowerShell ] Use the following procedure to reset an AWS Managed Microsoft AD user password with the PowerShell. 1. Connect to the instance joined to your Active Directory domain as the Active Directory administrator. 1. Open PowerShell. 1. Type the following command replacing the username **jane.doe**, the Directory ID, and password **P@ssw0rd** with your Active Directory Directory ID and desired credentials. See [Reset-DSUserPassword Cmdlet](https://docs.aws.amazon.com/powershell/latest/reference/items/Reset-DSUserPassword.html) for more information. ``` Reset-DSUserPassword -UserName "jane.doe" -DirectoryId d-1234567890 -NewPassword "P@ssw0rd" ``` ------ # Creating an AWS Managed Microsoft AD group Creating a group You can create groups in your AWS Managed Microsoft AD. Use the following procedure to create a security group with an Amazon EC2 instance that is joined to your AWS Managed Microsoft AD directory. Before you can create security groups, you need to complete the procedures in [Installing the Active Directory Administration Tools](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html). ------ #### [ Active Directory Administration Tools ] Use the following procedures to create an AWS Managed Microsoft AD group with Active Directory Administration Tools. **To create a group** 1. Connect to the instance where the Active Directory Administration Tools were installed. 1. Open the Active Directory Users and Computers tool. There is a shortcut to this tool in the **Administrative Tools** folder. **Tip** You can run the following from a command prompt on the instance to open the Active Directory Users and Computers tool box directly. ``` %SystemRoot%\system32\dsa.msc ``` 1. In the directory tree, select an OU under your directory's NetBIOS name OU where you want to store your group (for example, Corp\$1Users). For more information about the OU structure used by directories in AWS, see [What gets created with your AWS Managed Microsoft AD](ms_ad_getting_started_what_gets_created.md). ![\[Active Directory Users and Computers tool showing example OU structure.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/create-security-groups-OU.png) 1. On the **Action** menu, click **New**, and then click **Group** to open the new group wizard. 1. Type a name for the group in **Group name**, select a **Group scope** that meets your needs, and select **Security** for the **Group type**. For more information on Active Directory group scope and security groups, see [ Active Directory security groups](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups) in Microsoft Windows Server documentation. 1. Click **OK**. The new security group will appear in the **Users** folder. ------ #### [ PowerShell ] You can use PowerShell commands to create groups. For more information, see [New-ADGroup](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adgroup?view=windowsserver2022-ps) in Windows Server 2022 PowerShell documentation. ------ # Adding an AWS Managed Microsoft AD user to a group Adding a user to a group You can add AWS Managed Microsoft AD users to a group. Use the following procedure to add a user to a security group with an Amazon EC2 instance that is joined to your AWS Managed Microsoft AD directory. ------ #### [ Active Directory Administration Tools ] **To add a user to a group** 1. Connect to the instance where the Active Directory Administration Tools were installed. 1. Open the Active Directory Users and Computers tool. There is a shortcut to this tool in the **Administrative Tools** folder. **Tip** You can run the following from a command prompt on the instance to open the Active Directory Users and Computers tool box directly. ``` %SystemRoot%\system32\dsa.msc ``` 1. In the directory tree, select the OU under your directory's NetBIOS name OU where you stored your group, and select the group that you want to add a user as a member. ![\[Active Directory Users and Computers tool showing example OU structure.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/create-security-groups-OU.png) 1. On the **Action** menu, click **Properties** to open the properties dialog box for the group. 1. Select the **Members** tab and click **Add**. 1. For **Enter the object names to select**, type the username you want to add and click **OK**. The name will be displayed in the **Members** list. Click **OK** again to update the group membership. 1. Verify that the user is now a member of the group by selecting the user in the **Users** folder and clicking **Properties** in the **Action** menu to open the properties dialog box. Select the **Member Of** tab. You should see the name of the group in the list of groups that the user belongs to. ------ # AWS Directory Service Data Directory Service Data AWS Directory Service Data is an extension of AWS Directory Service. You can create, read, update, and Active Directory (AD) users, groups, and memberships from an AWS Directory Service for Microsoft Active Directory without deploying dedicated AD management instances on an Amazon EC2 instance. You can also perform built-in object management tasks across directories without any direct network connectivity. This simplifies provisioning and access management to achieve fully automated deployments. For more information, see the [AWS Directory Service Data API Reference ](https://docs.aws.amazon.com/directoryservicedata/latest/DirectoryServiceDataAPIReference/Welcome.html). Directory Service Data supports user and group write operations, like `CreateUser` and `CreateGroup`, within the AWS Managed Microsoft AD that's in your organizational unit (OU). Directory Service Data supports read operations, like `ListUsers` and `ListGroups`, on all users, groups, and group memberships within the AWS Managed Microsoft AD and across trusted realms. Directory Service Data supports adding and removing group members from groups in your OU and the AWS Delegated Groups OU, so you can delegate permissions by adding users to specific delegated group objects. For more information, see [User and group management in AWS Managed Microsoft AD](ms_ad_manage_users_groups.md). **Note** Directory Service Data is only available in your Primary Region. For more information, see [Primary vs additional Regions](multi-region-global-primary-additional.md). **Topics** + [ ## Replication and consistency ](#replication_consistency) + [ # AWS Directory Service Data attributes ](ad_data_attributes.md) + [ # Group type and group scope ](ad_group_type_and_scope.md) ## Replication and consistency The Directory Service Data API connects to your AWS Managed Microsoft AD domain controllers to perform operations on the underlying directory objects. Active Directory is an eventually consistent platform, and replication is continuously occurring between Directory Service directory domain controllers. By default, every Directory Service directory is created with two domain controllers. Directory Service Data attempts to maintain a consistent experience by utilizing the same domain controller across requests. In the event that a domain controller is unavailable, Directory Service Data switches to an alternative domain controller. During these events, you might notice eventual consistency across domain controllers while objects are replicated across domain controllers. Directory limits vary by AWS Managed Microsoft AD edition: + **Standard edition** – Supports 8 transactions per second for read operations and 4 TPS for write operations per directory. + **Enterprise edition** – Supports 16 transactions per second for read operations and 8 TPS for write operations per directory. **Note** There's a concurrency limit of 10 concurrent requests for both Standard and Enterprise editions. + **AWS account** – Supports a total of 100 transactions per second for Directory Service Data operations across all directories. # AWS Directory Service Data attributes This topic describes how to work with attributes in the [AWS Directory Service Data API Reference](https://docs.aws.amazon.com//directoryservicedata/latest/DirectoryServiceDataAPIReference/Welcome.html). ## Request Attributes The following attributes must be defined in the request body parameters. For an example of how to define these attributes, see [CreateGroup](https://docs.aws.amazon.com/directoryservicedata/latest/DirectoryServiceDataAPIReference/API_CreateGroup.html) in the *AWS Directory Service Data API Reference*. | Directory Service Data attribute name | LDAP display name | AWS Management Console | PowerShell alias | Access type | Object type | Attribute value | Searchable | | --- | --- | --- | --- | --- | --- | --- | --- | | [DistinguishedName](https://learn.microsoft.com/en-us/windows/win32/adschema/a-distinguishedname) | distinguishedName | Distinguished name | None | ReadOnly | User, Group | String | No | | [EmailAddress](https://learn.microsoft.com/en-us/windows/win32/adschema/a-mail) | mail | Email address | EmailAddress | Creatable | User | String | Yes | | Enabled | None | Enabled | Enabled | Mutable | User | Boolean | No | | [GivenName](https://learn.microsoft.com/en-us/windows/win32/adschema/a-givenname) | givenName | First Name | GivenName | Creatable | User | String | Yes | | [GroupScope](https://learn.microsoft.com/en-us/windows/win32/adschema/a-grouptype) | groupScope | Group scope | None | Creatable | Group | Enum | No | | [GroupType](https://learn.microsoft.com/en-us/windows/win32/adschema/a-grouptype) | groupType | Group type | None | Creatable | Group | Enum | No | | [SamAccountName](https://learn.microsoft.com/en-us/windows/win32/adschema/a-samaccountname) | sAMAccountName | User logon name | sAMAccountName | Creatable | User, Group | String | Yes | | [SID](https://learn.microsoft.com/en-us/windows/win32/adschema/a-objectsid) | objectSid | User / Group security identifier (SID) | SID | ReadOnly | User, Group | String | No | | [Surname](https://learn.microsoft.com/en-us/windows/win32/adschema/a-sn) | sn | Last name | Surname | Creatable | User | String | Yes | | [UserPrincipalName](https://learn.microsoft.com/en-us/windows/win32/adschema/a-userprincipalname) | userPrincipalName | User principal name | UserPrincipalName | ReadOnly | User | String | No | ## Other Attributes The following attributes must be defined in `OtherAttributes` and don't map to any request body parameters. When you define other attributes in your requests, you must specify the attribute name, data type, and the value for each attribute. For an example of how to define these attributes, see [CreateUser](https://docs.aws.amazon.com/directoryservicedata/latest/DirectoryServiceDataAPIReference/API_CreateUser.html) in the *AWS Directory Service Data API Reference*. **Note** The names of these attributes are case insensitive *when provided as inputs* and the equivalent of the LDAP display name. | Directory Service Data attribute name | LDAP display name | AWS Management Console | PowerShell alias | Access type | Object type | Attribute value | Searchable | | --- | --- | --- | --- | --- | --- | --- | --- | | [Assistant](https://learn.microsoft.com/en-us/windows/win32/adschema/a-assistant) | assistant | Assistant | None | ReadOnly | User | String | No | | [Cn](https://learn.microsoft.com/en-us/windows/win32/adschema/a-cn) | cn | Common Name | None | ReadOnly | User, Group | String | No | | [Co](https://learn.microsoft.com/en-us/windows/win32/adschema/a-co) | co | Country/region | Country | Mutable | User | String | No | | [Company](https://learn.microsoft.com/en-us/windows/win32/adschema/a-company) | company | Company | Company | Creatable | User | String | No | | [Department](https://learn.microsoft.com/en-us/windows/win32/adschema/a-department) | department | Department | Department | Creatable | User | String | No | | [Description](https://learn.microsoft.com/en-us/windows/win32/adschema/a-description) | description | Description | Description | Creatable | User, Group | String | No | | [DirectReports](https://learn.microsoft.com/en-us/windows/win32/adschema/a-directreports) | directReports | Direct reports | None | ReadOnly | User | String set | No | | [DisplayName](https://learn.microsoft.com/en-us/windows/win32/adschema/a-displayname) | displayName | Display name | DisplayName | Creatable | User, Group | String | Yes | | [FacsimileTelephoneNumber](https://learn.microsoft.com/en-us/windows/win32/adschema/a-facsimiletelephonenumber) | facsimileTelephoneNumber | Fax | Fax | Creatable | User, Group | String | No | | [HomePhone](https://learn.microsoft.com/en-us/windows/win32/adschema/a-homephone) | homePhone | Home phone number | HomePhone | Creatable | User | String | No | | [Info](https://learn.microsoft.com/en-us/windows/win32/adschema/a-info) | info | Notes | None | Mutable | User, Group | String | No | | [Initials](https://learn.microsoft.com/en-us/windows/win32/adschema/a-initials) | initials | Initials | Initials | Mutable | User | String | No | | [IpPhone](https://learn.microsoft.com/en-us/windows/win32/adschema/a-ipphone) | ipPhone | IP Phone | None | Mutable | User | String | No | | [L](https://learn.microsoft.com/en-us/windows/win32/adschema/a-l) | l | City | City | Creatable | User | String | Yes | | [Manager](https://learn.microsoft.com/en-us/windows/win32/adschema/a-manager) | manager | Manager | Manager | Mutable | User | String | No | | [Mail](https://learn.microsoft.com/en-us/windows/win32/adschema/a-mail) | mail | Email address | EmailAddress | Mutable | Group | String | Yes | | [Mobile](https://learn.microsoft.com/en-us/windows/win32/adschema/a-mobile) | mobile | Mobile phone number | MobilePhone | Mutable | User | String | No | | ObjectClass | objectClass | User / Group | None | ReadOnly | Group | String | No | | [ObjectGUID](https://learn.microsoft.com/en-us/windows/win32/adschema/a-objectguid) | objectGUID | Global unique identifier (GUID) | None | ReadOnly | User, Group | String | No | | [Pager](https://learn.microsoft.com/en-us/windows/win32/adschema/a-pager) | pager | Pager | None | Mutable | User | String | No | | [PhysicalDeliveryOfficeName](https://learn.microsoft.com/en-us/windows/win32/adschema/a-physicaldeliveryofficename) | physicalDeliveryOfficeName | Office | None | Creatable | User | String | Yes | | [PostalCode](https://learn.microsoft.com/en-us/windows/win32/adschema/a-postalcode) | postalCode | Zip/Postal code | PostalCode | Creatable | User | String | No | | [PreferredLanguage](https://learn.microsoft.com/en-us/windows/win32/adschema/a-preferredlanguage) | preferredLanguage | Preferred language | None | Mutable | User | String | No | | [ProxyAddresses](https://learn.microsoft.com/en-us/windows/win32/adschema/a-proxyaddresses) | proxyAddresses | Proxy address | None | ReadOnly | User, Group | Multi-valued string | Yes | | [ServicePrincipalName](https://learn.microsoft.com/en-us/windows/win32/adschema/a-serviceprincipalname) | servicePrincipalName | Service principal name | ServicePrincipalName | Mutable | User | Multi-valued string | No | | [St](https://learn.microsoft.com/en-us/windows/win32/adschema/a-st) | st | State/Province | State | Creatable | User | String | No | | [StreetAddress](https://learn.microsoft.com/en-us/windows/win32/adschema/a-street) | streetAddress | Street address | StreetAddress | Creatable | User | String | No | | [TelephoneNumber](https://learn.microsoft.com/en-us/windows/win32/adschema/a-telephonenumber) | telephoneNumber | Telephone number | OfficePhone | Creatable | User | String | No | | [Title](https://learn.microsoft.com/en-us/windows/win32/adschema/a-title) | title | Job title | Title | Mutable | User | String | No | | [WhenChanged](https://learn.microsoft.com/en-us/windows/win32/adschema/a-whenchanged) | whenChanged | Last updated | None | ReadOnly | User, Group | String | No | | [WWWHomePage](https://learn.microsoft.com/en-us/windows/win32/adschema/a-wwwhomepage) | wWWHomePage | Home page URL | wWWHomePage | Mutable | User, Group | String | No | # Group type and group scope Groups in AWS Managed Microsoft AD have both a group type and a group scope. See the following sections for more information on each. **Topics** + [ ## Group type ](#ad_group_type) + [ ## Group scope ](#ad_group_scope) ## Group type Group type determines which shared resources within the Active Directory the group members can access. There are two group types: + **Security** - You can assign permissions to these groups so that group members can access shared Active Directory resources. + **Distribution** - You can use this type to create email distribution lists. These group members cannot access Active Directory shared resources. There are no limitations when changing between group types. For more information about group types, see [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#how-active-directory-security-groups-work). ## Group scope Group scope determines how group members are defined with the domain tree or forest. There are three group scopes: + **Domain local** - to assign permissions to group members located in the same domain. + **Universal** - to assign permissions to group members located within any domain. + **Global** - to assign permissions to group members located within any domain or forest. There are limitations when changing a group scope. The following list and diagram outline these limitations. + Changing group scope from **Domain Local** to **Universal** - Yes + Unless the domain local group is a parent of another domain local group. + Changing group scope from **Universal** to **Domain Local** - Yes + Unless the universal group is a child group of another universal group. + Changing group scope from **Universal** to **Global** - Yes + Unless the universal group is a parent of another universal group. + Changing group scope from **Global** to **Universal** - Yes + Unless the global group is a child of another global group. For more information about group scopes, see [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#group-scope). ![\[Diagram showing three different group scopes (domain local, universal, and global) and how group scope impacts group membership.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/group_scope_membership.png) # Connecting your AWS Managed Microsoft AD to Microsoft Entra Connect Sync Connecting to Microsoft Entra Connect Sync This tutorial walks you through the necessary steps to install [https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) to sync your [https://learn.microsoft.com/en-us/entra/fundamentals/whatis](https://learn.microsoft.com/en-us/entra/fundamentals/whatis) to your AWS Managed Microsoft AD. In this tutorial, you do the following: 1. Create an AWS Managed Microsoft AD domain user. 1. Download Entra Connect Sync. 1. Use PowerShell to run a script to provision the appropriate permissions for the newly created user. 1. Install Entra Connect Sync. ## Prerequisites You will need the following to complete this tutorial: + An AWS Managed Microsoft AD. For more information, see [Creating your AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_create_directory). + An Amazon EC2 Windows Server instance joined to your AWS Managed Microsoft AD. For more information, see [Joining a Windows instance](launching_instance.md). + An EC2 Windows Server with Active Directory Administration Tools installed to manage your AWS Managed Microsoft AD. For more information, see [Installing Active Directory Administration Tools for AWS Managed Microsoft AD](ms_ad_install_ad_tools.md). ## Create an Active Directory domain user This tutorial assumes you already have an AWS Managed Microsoft AD as well as an EC2 Windows Server instance with Active Directory Administration Tools installed. For more information, see [Installing Active Directory Administration Tools for AWS Managed Microsoft AD](ms_ad_install_ad_tools.md). 1. Connect to the instance where the Active Directory Administration Tools were installed. 1. Create an AWS Managed Microsoft AD domain user. This user will become the Active Directory Directory Service (AD DS) Connector account for Entra Connect Sync. For detailed steps on this process, see [Creating an AWS Managed Microsoft AD user](ms_ad_manage_users_groups_create_user.md). ## Download Entra Connect Sync + Download Entra Connect Sync from [Microsoft website](https://www.microsoft.com/en-us/download/details.aspx?id=47594) onto the EC2 instance that is the AWS Managed Microsoft AD admin. **Warning** Do not open or run Entra Connect Sync at this point. The next steps will provision the necessary permissions for your domain user created in Step 1. ## Run PowerShell Script + [Open PowerShell as an Administrator](https://learn.microsoft.com/en-us/powershell/scripting/windows-powershell/starting-windows-powershell?view=powershell-7.4) and run the following script. While the script is running, you will be asked to enter the [sAMAccountName](https://learn.microsoft.com/en-us/windows/win32/ad/naming-properties#samaccountname) for the newly created domain user from Step 1. **Note** See the following for more information on running the script: You can save the script with the `ps1` extension to a folder like **temp**. Then, you can use the following PowerShell command to load the script: ``` import-module "c:\temp\entra.ps1" ``` After loading the script, you can use the following command to set the necessary permissions to run the script, replacing *Entra\$1Service\$1Account\$1Name* with your Entra service account name: ``` Set-EntraConnectSvcPerms -ServiceAccountName Entra_Service_Account_Name ``` ``` $modulePath = "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1" try { # Attempt to import the module Write-Host -ForegroundColor Green "Importing Module for Azure Entra Connect..." Import-Module $modulePath -ErrorAction Stop Write-Host -ForegroundColor Green "Success!" } catch { # Display the exception message Write-Host -ForegroundColor Red "An error occurred: $($_.Exception.Message)" } Function Set-EntraConnectSvcPerms { [CmdletBinding()] Param ( [String]$ServiceAccountName ) #Requires -Modules 'ActiveDirectory' -RunAsAdministrator Try { $Domain = Get-ADDomain -ErrorAction Stop } Catch [System.Exception] { Write-Output "Failed to get AD domain information $_" } $BaseDn = $Domain | Select-Object -ExpandProperty 'DistinguishedName' $Netbios = $Domain | Select-Object -ExpandProperty 'NetBIOSName' Try { $OUs = Get-ADOrganizationalUnit -SearchBase "OU=$Netbios,$BaseDn" -SearchScope 'Onelevel' -Filter * -ErrorAction Stop | Select-Object -ExpandProperty 'DistinguishedName' } Catch [System.Exception] { Write-Output "Failed to get OUs under OU=$Netbios,$BaseDn $_" } Try { $ADConnectorAccountDN = Get-ADUser -Identity $ServiceAccountName -ErrorAction Stop | Select-Object -ExpandProperty 'DistinguishedName' } Catch [System.Exception] { Write-Output "Failed to get service account DN $_" } Foreach ($OU in $OUs) { try { Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountDN $ADConnectorAccountDN -ADobjectDN $OU -Confirm:$false -ErrorAction Stop Write-Host "Permissions set successfully for $ADConnectorAccountDN and $OU" Set-ADSyncBasicReadPermissions -ADConnectorAccountDN $ADConnectorAccountDN -ADobjectDN $OU -Confirm:$false -ErrorAction Stop Write-Host "Basic read permissions set successfully for $ADConnectorAccountDN on OU $OU" } catch { Write-Host "An error occurred while setting permissions for $ADConnectorAccountDN on OU $OU : $_" } } } ``` ## Install Entra Connect Sync 1. Once the script has completed, you can run the downloaded Microsoft Entra Connect (formerly known as Azure Active Directory Connect) configuration file. 1. A Microsoft Azure Active Directory Connect window opens after running the configuration file from the previous step. On the **Express Settings** window, select **Customize**. ![\[Microsoft Azure Active Directory Connect window with customize button highlighted.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/express-settings.png) 1. On the **Install required components** window, select the **Use an existing service account** checkbox. In **SERVICE ACCOUNT NAME** and **SERVICE ACCOUNT PASSWORD**, enter the AD DS Connector account name and password for the user you created in Step 1. For example, if your AD DS Connector account name is `entra`, the account name would be `corp\entra`. Then select **Install**. ![\[Install required components window with use existing service account and domain account selected, and the service account name and password provided.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/install-required-components.png) 1. On the **User Sign-in** window, select one of the following options: 1. [Pass-through Authentication](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) - This option allows you to sign in to your Active Directory with your username and password. 1. **Do not configure** - This allows you to use federated sign in with Microsoft Entra (formerly known as Azure Active Directory (Azure AD)) or Office 365. Then select **Next**. 1. On the **Connect to Azure** window, enter your [Global Administrator](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#global-administrator) username and password for Entra ID and select **Next**. 1. On the **Connect your directories** window, choose **Active Directory** for **DIRECTORY TYPE**. Choose the forest for your AWS Managed Microsoft AD for **FOREST**. Then select **Add Directory**. 1. A pop-up box appears requesting your account options. Select **Use existing AD account**. Enter the AD DS Connector account username and password created in Step 1 and then select **OK**. Then select **Next**. ![\[AD forest account pop-up box with the use existing AD account selected and domain username and password provided.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/connect-to-your-directories.png) 1. On the **Azure AD Sign-in** window, select **Continue without matching all UPN suffixes to verified domains**, only if you do not have a verified vanity domain added to Entra ID. Then select **Next**. 1. On **Domain/OU filtering** window, select the options to suit your needs. For more information, see [Entra Connect Sync: Configure filtering](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-configure-filtering) in Microsoft documentation. Then select **Next**. 1. On the **Identifying Users, Filtering and Optional Features** window, keep the default values and select **Next**. 1. On the **Configure** window, review the configuration settings and select **Configure**. The installation for Entra Connect Sync will finalize and users will begin to synchronize with Microsoft Entra ID. # AWS Managed Microsoft AD test lab tutorials This section provides a series of guided tutorials to help you establish a test lab environment in AWS where you can experiment with AWS Managed Microsoft AD. **Topics** + [ # Tutorial: Setting up your base AWS Managed Microsoft AD test lab in AWS ](ms_ad_tutorial_test_lab_base.md) + [ # Tutorial: Creating a trust from AWS Managed Microsoft AD to a self-managed Active Directory installation on Amazon EC2 ](ms_ad_tutorial_test_lab_trust.md) # Tutorial: Setting up your base AWS Managed Microsoft AD test lab in AWS Tutorial: Set up your base AWS Managed Microsoft AD test lab This tutorial teaches you how to set up your AWS environment to prepare for a new AWS Managed Microsoft AD installation that uses a new Amazon EC2 instance running Windows Server 2019. It then teaches you to use typical Active Directory administration tools to manage your AWS Managed Microsoft AD environment from your EC2 Windows instance. By the time you complete the tutorial, you will have set up the network prerequisites and have configured a new AWS Managed Microsoft AD forest. As shown in the following illustration, the lab you create from this tutorial is the foundational component for hands-on learning about AWS Managed Microsoft AD. You can later add optional tutorials for more hands-on experience. This tutorial series is ideal for anyone who is new to AWS Managed Microsoft AD and wants a test lab for evaluation purposes. This tutorial takes approximately 1 hour to complete. ![\[Diagram showing tutorial steps: 1 set up your environment, 2 create your AWS Managed Microsoft AD, 3 deploy an Amazon EC2, and 4 test the lab.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/tutorialmicrosoftadbase.png) **[Step 1: Set up your AWS environment for AWS Managed Microsoft AD Active Directory](microsoftadbasestep1.md)** After you've completed your prerequisite tasks, you create and configure an Amazon VPC in your EC2 instance. **[Step 2: Create your AWS Managed Microsoft AD Active Directory](microsoftadbasestep2.md)** In this step, you set up AWS Managed Microsoft AD in AWS for the first time. **[Step 3: Deploy an Amazon EC2 instance to manage your AWS Managed Microsoft AD Active Directory](microsoftadbasestep3.md)** Here, you walk through the various post-deployment tasks necessary for client computers to connect to your new domain and set up a new Windows Server system in EC2. **[Step 4: Verify that the base test lab is operational](microsoftadbasestep4.md)** Finally, as an administrator, you verify that you can log in and connect to AWS Managed Microsoft AD from your Windows Server system in EC2. Once you've successfully tested that the lab is operational, you can continue to add other test lab guide modules. # Prerequisites If you plan to use only the UI steps in this tutorial to create your test lab, you can skip this prerequisites section and move on to Step 1. However, if you plan to use either AWS CLI commands or AWS Tools for Windows PowerShell modules to create your test lab environment, you must first configure the following: + **IAM user with the access and secret access key** – An IAM user with an access key is required if you want to use the AWS CLI or AWS Tools for Windows PowerShell modules. If you do not have an access key, see [Creating, modifying, and viewing access keys (AWS Management Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey). + **AWS Command Line Interface (optional)** – Download and [Install the AWS CLI on Windows](https://docs.aws.amazon.com/cli/latest/userguide/install-windows.html). Once installed, open the command prompt or PowerShell window, and then type `aws configure`. Note that you need the access key and secret key to complete the setup. See the first prerequisite for steps on how to do this. You will be prompted for the following: + AWS access key ID [None]: `AKIAIOSFODNN7EXAMPLE` + AWS secret access key [None]: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` + Default Region name [None]: `us-west-2` + Default output format [None]: `json` + **AWS Tools for Windows PowerShell** **(optional)** – Download and install the latest version of the AWS Tools for Windows PowerShell from [https://aws.amazon.com/powershell/](https://aws.amazon.com/powershell/), and then run the following command. Note that you need your access key and secret key to complete the setup. See the first prerequisite for the steps on how to do this. `Set-AWSCredentials -AccessKey {AKIAIOSFODNN7EXAMPLE} -SecretKey {wJalrXUtnFEMI/K7MDENG/ bPxRfiCYEXAMPLEKEY} -StoreAs {default}` # Step 1: Set up your AWS environment for AWS Managed Microsoft AD Active Directory Step 1: Set up your AWS environment for AWS Managed Microsoft AD Before you can create AWS Managed Microsoft AD in your AWS test lab, you first need to set up your Amazon EC2 key pair so that all login data is encrypted. ## Create a key pair If you already have a key pair, you can skip this step. For more information about Amazon EC2 key pairs, see [Create key pairs](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/create-key-pairs.html). **To create a key pair** 1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, under **Network & Security**, choose **Key Pairs**, and then choose **Create Key Pair**. 1. For **Key pair name**, type **AWS-DS-KP**. For **Key pair file format**, select **pem**, and then choose **Create**. 1. The private key file is automatically downloaded by your browser. The file name is the name you specified when you created your key pair with an extension of `.pem`. Save the private key file in a safe place. **Important** This is the only chance for you to save the private key file. You need to provide the name of your key pair when you launch an instance and the corresponding private key each time you decrypt the password for the instance. ## Create, configure, and peer two Amazon VPCs As shown in the following illustration, by the time you finish this multi-step process you will have created and configured two public VPCs, two public subnets per VPC, one Internet Gateway per VPC, and one VPC Peering connection between the VPCs. We chose to use public VPCs and subnets for the purpose of simplicity and cost. For production workloads, we recommend that you use private VPCs. For more information about improving VPC Security, see [Security in Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/security.html). ![\[Amazon VPC environment with subnets, and Internet Gateways to create an AWS Managed Microsoft AD Active Directory.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/tutorialmicrosoftadbase_vpclayout.png) All of the AWS CLI and PowerShell examples use the VPC information from below and are built in us-west-2. You may choose any [supported Region](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/regions.html) to build you environment in. For general information, see [What is Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html). **Step 1: Create two VPCs** In this step, you need to create two VPCs in the same account using the specified parameters in the following table. AWS Managed Microsoft AD supports the use of separate accounts with the [Share your AWS Managed Microsoft AD](ms_ad_directory_sharing.md) feature. The first VPC will be used for AWS Managed Microsoft AD. The second VPC will be used for resources that can be used later in [Tutorial: Creating a trust from AWS Managed Microsoft AD to a self-managed Active Directory installation on Amazon EC2](ms_ad_tutorial_test_lab_trust.md). **** | Managed Active Directory VPC information | On-premises VPC information | | --- | --- | | Name tag: AWS-DS-VPC01 IPv4 CIDR block: 10.0.0.0/16 IPv6 CIDR block: No IPv6 CIDR Block Tenancy: Default | Name tag: AWS-OnPrem-VPC01 IPv4 CIDR block: 10.100.0.0/16 IPv6 CIDR block: No IPv6 CIDR Block Tenancy: Default | For detailed instructions, see [Creating a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC). **Step 2: Create two subnets per VPC** After you have created the VPCs you will need to create two subnets per VPC using the specified parameters in the following table. For this test lab each subnet will be a /24. This will allows up to 256 addresses to be issued per subnet. Each subnet must be a in a separate AZ. Putting each subnet in a separate in AZ is one of the [Prerequisites for creating a AWS Managed Microsoft AD](ms_ad_getting_started.md#ms_ad_getting_started_prereqs). **** | AWS-DS-VPC01 subnet Information: | AWS-OnPrem-VPC01 subnet information | | --- | --- | | Name tag: AWS-DS-VPC01-Subnet01 VPC: vpc-xxxxxxxxxxxxxxxxx AWS-DS-VPC01 Availability Zone: us-west-2a IPv4 CIDR block: 10.0.0.0/24 | Name tag: AWS-OnPrem-VPC01-Subnet01 VPC: vpc-xxxxxxxxxxxxxxxxx AWS-OnPrem-VPC01 Availability Zone: us-west-2a IPv4 CIDR block: 10.100.0.0/24 | | Name tag: AWS-DS-VPC01-Subnet02 VPC: vpc-xxxxxxxxxxxxxxxxx AWS-DS-VPC01 Availability Zone: us-west-2b IPv4 CIDR block: 10.0.1.0/24 | Name tag: AWS-OnPrem-VPC01-Subnet02 VPC: vpc-xxxxxxxxxxxxxxxxx AWS-OnPrem-VPC01 Availability Zone: us-west-2b IPv4 CIDR block: 10.100.1.0/24 | For detailed instructions, see [Creating a subnet in your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet). **Step 3: Create and attach an Internet Gateway to your VPCs** Since we are using public VPCs you will need to create and attach an Internet gateway to your VPCs using the specified parameters in the following table. This will allow you to be able to connect to and manage your EC2 instances. **** | AWS-DS-VPC01 Internet Gateway information | AWS-OnPrem-VPC01 Internet Gateway information | | --- | --- | | Name tag: AWS-DS-VPC01-IGW VPC: vpc-xxxxxxxxxxxxxxxxx AWS-DS-VPC01 | Name tag: AWS-OnPrem-VPC01-IGW VPC: vpc-xxxxxxxxxxxxxxxxx AWS-OnPrem-VPC01 | For detailed instructions, see [Internet gateways](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html). **Step 4: Configure a VPC peering connection between AWS-DS-VPC01 and AWS-OnPrem-VPC01** Since you already created two VPCs earlier, you will need to network them together using VPC peering using the specified parameters in the following table. While there are many ways to connect your VPCs, this tutorial will use VPC Peering. AWS Managed Microsoft AD supports many solutions to connect your VPCs, some of these include [VPC peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html), and [VPN](https://docs.aws.amazon.com/vpc/latest/adminguide/Welcome.html). **** | | | --- | | Peering connection name tag: AWS-DS-VPC01&AWS-OnPrem-VPC01-Peer VPC (Requester): vpc-xxxxxxxxxxxxxxxxx AWS-DS-VPC01 Account: My Account Region: This Region VPC (Accepter): vpc-xxxxxxxxxxxxxxxxx AWS-OnPrem-VPC01 | For instructions on how to create a VPC Peering Connection with another VPC from with in your account, see [Creating a VPC peering connection with another VPC in your account](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html#create-vpc-peering-connection-local). **Step 5: Add two routes to each VPC's main route table** In order for the Internet Gateways and VPC Peering Connection created in the previous steps to be functional you will need to update the main route table of both VPCs using the specified parameters in the following table. You will be adding two routes; 0.0.0.0/0 which will route to all destinations not explicitly known to the route table and 10.0.0.0/16 or 10.100.0.0/16 which will route to each VPC over the VPC Peering Connection established above. You can easily find the correct route table for each VPC by filtering on the VPC name tag (AWS-DS-VPC01 or AWS-OnPrem-VPC01). **** | AWS-DS-VPC01 route 1 information | AWS-DS-VPC01 route 2 information | AWS-OnPrem-VPC01 route 1 Information | AWS-OnPrem-VPC01 route 2 Information | | --- | --- | --- | --- | | Destination: 0.0.0.0/0 Target: igw-xxxxxxxxxxxxxxxxx AWS-DS-VPC01-IGW | Destination: 10.100.0.0/16 Target: pcx-xxxxxxxxxxxxxxxxx AWS-DS-VPC01&AWS-OnPrem-VPC01-Peer | Destination: 0.0.0.0/0 Target: igw-xxxxxxxxxxxxxxxxx AWS-Onprem-VPC01 | Destination: 10.0.0.0/16 Target: pcx-xxxxxxxxxxxxxxxxx AWS-DS-VPC01&AWS-OnPrem-VPC01-Peer | For instructions on how to add routes to a VPC route table, see [Adding and removing routes from a route table](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes). ## Create security groups for Amazon EC2 instances By default, AWS Managed Microsoft AD creates a security group to manage traffic between its domain controllers. In this section, you will need to create 2 security groups (one for each VPC) which will be used to manage traffic within your VPC for your EC2 instances using the specified parameters in the following tables. You also add a rule that allows RDP (3389) inbound from anywhere and for all traffic types inbound from the local VPC. For more information, see [Amazon EC2 security groups for Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-network-security.html). **** | AWS-DS-VPC01 security group information: | | --- | | Security group name: AWS DS Test Lab Security Group Description: AWS DS Test Lab Security Group VPC: vpc-xxxxxxxxxxxxxxxxx AWS-DS-VPC01 | **Security Group Inbound Rules for AWS-DS-VPC01** **** | Type | Protocol | Port range | Source | Type of traffic | | --- | --- | --- | --- | --- | | Custom TCP Rule | TCP | 3389 | My IP | Remote Desktop | | All Traffic | All | All | 10.0.0.0/16 | All local VPC traffic | **Security Group Outbound Rules for AWS-DS-VPC01** **** | Type | Protocol | Port range | Destination | Type of traffic | | --- | --- | --- | --- | --- | | All Traffic | All | All | 0.0.0.0/0 | All traffic | **** | AWS-OnPrem-VPC01 security group information: | | --- | | Security group name: AWS OnPrem Test Lab Security Group. Description: AWS OnPrem Test Lab Security Group. VPC: vpc-xxxxxxxxxxxxxxxxx AWS-OnPrem-VPC01 | **Security Group Inbound Rules for AWS-OnPrem-VPC01** **** | Type | Protocol | Port range | Source | Type of traffic | | --- | --- | --- | --- | --- | | Custom TCP Rule | TCP | 3389 | My IP | Remote Desktop | | Custom TCP Rule | TCP | 53 | 10.0.0.0/16 | DNS | | Custom TCP Rule | TCP | 88 | 10.0.0.0/16 | Kerberos | | Custom TCP Rule | TCP | 389 | 10.0.0.0/16 | LDAP | | Custom TCP Rule | TCP | 464 | 10.0.0.0/16 | Kerberos change / set password | | Custom TCP Rule | TCP | 445 | 10.0.0.0/16 | SMB / CIFS | | Custom TCP Rule | TCP | 135 | 10.0.0.0/16 | Replication | | Custom TCP Rule | TCP | 636 | 10.0.0.0/16 | LDAP SSL | | Custom TCP Rule | TCP | 49152 - 65535 | 10.0.0.0/16 | RPC | | Custom TCP Rule | TCP | 3268 - 3269 | 10.0.0.0/16 | LDAP GC & LDAP GC SSL | | Custom UDP Rule | UDP | 53 | 10.0.0.0/16 | DNS | | Custom UDP Rule | UDP | 88 | 10.0.0.0/16 | Kerberos | | Custom UDP Rule | UDP | 123 | 10.0.0.0/16 | Windows Time | | Custom UDP Rule | UDP | 389 | 10.0.0.0/16 | LDAP | | Custom UDP Rule | UDP | 464 | 10.0.0.0/16 | Kerberos change / set password | | All Traffic | All | All | 10.100.0.0/16 | All local VPC traffic | **Security Group Outbound Rules for AWS-OnPrem-VPC01** **** | Type | Protocol | Port range | Destination | Type of traffic | | --- | --- | --- | --- | --- | | All Traffic | All | All | 0.0.0.0/0 | All traffic | For detailed instructions on how to create and add rules to your security groups, see [Working with security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#WorkingWithSecurityGroups). # Step 2: Create your AWS Managed Microsoft AD Active Directory Step 2: Create your AWS Managed Microsoft AD You can use three different methods to create your directory. You can use the AWS Management Console procedure (recommended for this tutorial) or you can use either the AWS CLI or AWS Tools for Windows PowerShell procedures to create your directory. **Method 1: To create your AWS Managed Microsoft AD directory (AWS Management Console)** 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 **AWS Managed Microsoft AD**, and then choose **Next**. 1. On the **Enter directory information** page, provide the following information, and then choose **Next**. + For **Edition**, select either **Standard Edition** or **Enterprise Edition**. For more information about editions, see [AWS Directory Service for Microsoft Active Directory](what_is.md#microsoftad). + For **Directory DNS name**, type **corp.example.com**. + For **Directory NetBIOS name**, type **corp**. + For **Directory description**, type **AWS DS Managed**. + For **Admin password**, type the password you want to use for this account and type the password again in **Confirm password**. This **Admin** account is automatically created during the directory creation process. The password cannot include the word *admin*. The directory administrator password is case sensitive and must be between 8 and 64 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[]:;"'<>,.?/) 1. On the **Choose VPC and subnets** page, provide the following information, and then choose **Next**. + For **VPC**, choose the option that begins with **AWS-DS-VPC01** and ends with **(10.0.0.0/16)**. + For **Subnets**, choose the **10.0.0.0/24** and **10.0.1.0/24** public subnets. 1. On the **Review & create** page, review the directory information and make any necessary changes. When the information is correct, choose **Create directory**. Creating the directory takes 20 to 40 minutes. Once created, the **Status** value changes to **Active**. **Method 2: To create your AWS Managed Microsoft AD (PowerShell) (Optional)** 1. Open PowerShell. 1. Type the following command. Make sure to use the values provided in Step 4 of the preceding AWS Management Console procedure. ``` New-DSMicrosoftAD -Name corp.example.com –ShortName corp –Password P@ssw0rd –Description "AWS DS Managed" - VpcSettings_VpcId vpc-xxxxxxxx -VpcSettings_SubnetId subnet-xxxxxxxx, subnet-xxxxxxxx ``` **Method 3: To create your AWS Managed Microsoft AD (AWS CLI) (Optional)** 1. Open the AWS CLI. 1. Type the following command. Make sure to use the values provided in Step 4 of the preceding AWS Management Console procedure. ``` aws ds create-microsoft-ad --name corp.example.com --short-name corp --password P@ssw0rd --description "AWS DS Managed" --vpc-settings VpcId= vpc-xxxxxxxx,SubnetIds= subnet-xxxxxxxx, subnet-xxxxxxxx ``` # Step 3: Deploy an Amazon EC2 instance to manage your AWS Managed Microsoft AD Active Directory Step 3: Deploy an EC2 instance to manage your AWS Managed Microsoft AD For this lab, we are using Amazon EC2 instances that have public IP addresses to make it easy to access the management instance from anywhere. In a production setting, you can use instances that are in a private VPC that are only accessible through a VPN or Direct Connect link. There is no requirement the instance have a public IP address. In this section, you walk through the various post-deployment tasks necessary for client computers to connect to your domain using the Windows Server on your new EC2 instance. You use the Windows Server in the next step to verify that the lab is operational. ## Optional: Create a DHCP options set in AWS-DS-VPC01 for your directory In this optional procedure, you set up a DHCP option scope so that EC2 instances in your VPC automatically use your AWS Managed Microsoft AD for DNS resolution. For more information, see [DHCP options sets](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html). **To create a DHCP options set for your directory** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **DHCP Options Sets**, and then choose **Create DHCP options set**. 1. On the **Create DHCP options set** page, provide the following values for your directory: + For **Name**, type **AWS DS DHCP**. + For **Domain name**, type **corp.example.com**. + For **Domain name servers**, type the IP addresses of your AWS provided directory's DNS servers. **Note** To find these addresses, go to the Directory Service **Directories** page, and then choose the applicable directory ID. On the **Details** page, identify and use the IPs that are displayed in **DNS address**. Alternatively, to find these addresses, go to the Directory Service **Directories** page, and choose the applicable directory ID. Then, choose **Scale & share**. Under **Domain controllers**, identify and use the IPs that are displayed in **IP address**. + Leave the settings blank for **NTP servers**, **NetBIOS name servers**, and **NetBIOS node type**. 1. Choose **Create DHCP options set**, and then choose **Close**. The new set of DHCP options appear in your list of DHCP options. 1. Make a note of the ID of the new set of DHCP options (**dopt-*xxxxxxxx***). You use it at the end of this procedure when you associate the new options set with your VPC. **Note** Seamless domain join works without having to configure a DHCP Options Set. 1. In the navigation pane, choose **Your VPCs**. 1. In the list of VPCs, select **AWS DS VPC**, choose **Actions**, and then choose **Edit DHCP options set**. 1. On the **Edit DHCP options set** page, select the options set that you recorded in Step 5, and then choose **Save**. ## Create a role to join Windows instances to your AWS Managed Microsoft AD domain Use this procedure to configure a role that joins an Amazon EC2 Windows instance to a domain. For more information, see [Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD Active Directory](launching_instance.md). **To configure EC2 to join Windows instances to your domain** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane of the IAM console, choose **Roles**, and then choose **Create role**. 1. Under **Select type of trusted entity**, choose **AWS service**. 1. Immediately under **Choose the service that will use this role**, choose **EC2**, and then choose **Next: Permissions**. 1. On the **Attached permissions policy** page, do the following: + Select the box next to the **AmazonSSMManagedInstanceCore** managed policy. This policy provides the minimum permissions necessary to use the Systems Manager service. + Select the box next to **AmazonSSMDirectoryServiceAccess** managed policy. The policy provides the permissions to join instances to an Active Directory managed by Directory Service. For information about these managed policies and other policies you can attach to an IAM instance profile for Systems Manager, see [Create an IAM instance profile for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html) in the *AWS Systems Manager User Guide*. For information about managed policies, see [AWS Managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. 1. Choose **Next: Tags**. 1. (Optional) Add one or more tag key-value pairs to organize, track, or control access for this role, and then choose **Next: Review**. 1. For **Role name**, enter a name for the role that describes that it is used to join instances to a domain, such as **EC2DomainJoin**. 1. (Optional) For **Role description**, enter a description. 1. Choose **Create role**. The system returns you to the **Roles** page. ## Create an Amazon EC2 instance and automatically join the directory In this procedure you set up a Windows Server system in a EC2 instance that can be used later to administer users, groups, and policies in Active Directory. **To create an EC2 instance and automatically join the directory** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Choose **Launch Instance**. 1. On the **Step 1** page, next to **Microsoft Windows Server 2019 Base - ami-*xxxxxxxxxxxxxxxxx*** choose **Select**. 1. On the **Step 2** page, select **t3.micro** (note, you can choose a larger instance type), and then choose **Next: Configure Instance Details**. 1. On the **Step 3** page, do the following: + For **Network**, choose the VPC that ends with **AWS-DS-VPC01** (for example, **vpc-*xxxxxxxxxxxxxxxxx* \$1 AWS-DS-VPC01**). + For **Subnet** choose **Public subnet 1**, which should be preconfigured for your preferred Availability Zone (for example, **subnet-*xxxxxxxxxxxxxxxxx* \$1 AWS-DS-VPC01-Subnet01 \$1 *us-west-2a***). + For **Auto-assign Public IP**, choose **Enable** (if the subnet setting is not set to enable by default). + For **Domain join directory**, choose **corp.example.com (d-*xxxxxxxxxx*)**. + For **IAM role** choose the name you gave your instance role in [Create a role to join Windows instances to your AWS Managed Microsoft AD domain](#configureec2), such as **EC2DomainJoin**. + Leave the rest of the settings at their defaults. + Choose **Next: Add Storage**. 1. On the **Step 4** page, leave the default settings, and then choose **Next: Add Tags**. 1. On the **Step 5** page, choose **Add Tag**. Under **Key** type **corp.example.com-mgmt** and then choose **Next: Configure Security Group**. 1. On the **Step 6** page, choose **Select an existing security group**, select **AWS DS Test Lab Security Group** (which you previously set up in the [Base tutorial](microsoftadbasestep1.md#createsecuritygroup)), and then choose **Review and Launch** to review your instance. 1. On the **Step 7** page, review the page, and then choose **Launch**. 1. On the **Select an existing key pair or create a new key pair** dialog box, do the following: + Choose **Choose an existing key pair**. + Under **Select a key pair**, choose **AWS-DS-KP**. + Select the **I acknowledge...** check box. + Choose **Launch Instances**. 1. Choose **View Instances** to return to the Amazon EC2 console and view the status of the deployment. ## Install the Active Directory tools on your EC2 instance You can choose from two methods to install the Active Directory Domain Management Tools on your EC2 instance. You can use the Server Manager UI (recommended for this tutorial) or PowerShell. **To install the Active Directory tools on your EC2 instance (Server Manager)** 1. In the Amazon EC2 console, choose **Instances**, select the instance you just created, and then choose **Connect**. 1. In the **Connect To Your Instance** dialog box, choose **Get Password** to retrieve your password if you haven't already, and then choose **Download Remote Desktop File**. 1. In the **Windows Security** dialog box, type your local administrator credentials for the Windows Server computer to log in (for example, **administrator**). 1. From the **Start** menu, choose **Server Manager**. 1. In the **Dashboard**, choose **Add Roles and Features**. 1. In the **Add Roles and Features Wizard**, choose **Next**. 1. On the **Select installation type** page, choose **Role-based or feature-based installation**, and then choose **Next**. 1. On the **Select destination server** page, make sure that the local server is selected, and then choose **Next**. 1. On the **Select server roles** page, choose **Next**. 1. On the **Select features** page, do the following: + Select the **Group Policy Management** check box. + Expand **Remote Server Administration Tools**, and then expand **Role Administration Tools**. + Select the **AD DS and AD LDS Tools** check box. + Select the **DNS Server Tools** check box. + Choose **Next**. 1. On the **Confirm installation selections** page, review the information, and then choose **Install**. When the feature installation is finished, the following new tools or snap-ins will be available in the Windows Administrative Tools folder in the Start menu. + Active Directory Administrative Center + Active Directory Domains and Trusts + Active Directory Module for PowerShell + Active Directory Sites and Services + Active Directory Users and Computers + ADSI Edit + DNS + Group Policy Management **To install the Active Directory tools on your EC2 instance (PowerShell) (Optional)** 1. Start PowerShell. 1. Type the following command. ``` Install-WindowsFeature -Name GPMC,RSAT-AD-PowerShell,RSAT-AD-AdminCenter,RSAT-ADDS-Tools,RSAT-DNS-Server ``` # Step 4: Verify that the base test lab is operational Use the following procedure to verify that the test lab has been set up successfully before adding on additional test lab guide modules. This procedure verifies that your Windows Server is configured appropriately, can connect to the corp.example.com domain, and be used to administer your AWS Managed Microsoft AD forest. **To verify that the test lab is operational** 1. Sign out of the EC2 instance where you were logged in as the local administrator. 1. Back in the Amazon EC2 console, choose **Instances** in the navigation pane. Then select the instance that you created. Choose **Connect**. 1. In the **Connect To Your Instance** dialog box, choose **Download Remote Desktop File**. 1. In the **Windows Security** dialog box, type your administrator credentials for the CORP domain to log in (for example, **corp\$1admin**). 1. Once you are logged in, in the **Start** menu, under **Windows Administrative Tools**, choose **Active Directory Users and Computers**. 1. You should see **corp.example.com** displayed with all the default OUs and accounts associated with a new domain. Under **Domain Controllers**, notice the names of the domain controllers that were automatically created when you created your AWS Managed Microsoft AD back in Step 2 of this tutorial. Congratulations\$1 Your AWS Managed Microsoft AD base test lab environment has now been configured. You are ready to begin adding the next test lab in the series. Next tutorial: [Tutorial: Creating a trust from AWS Managed Microsoft AD to a self-managed Active Directory installation on Amazon EC2](ms_ad_tutorial_test_lab_trust.md) # Tutorial: Creating a trust from AWS Managed Microsoft AD to a self-managed Active Directory installation on Amazon EC2 Tutorial: Create a trust from AWS Managed Microsoft AD to a self-managed AD install on EC2 In this tutorial, you learn how to create a trust between the AWS Directory Service for Microsoft Active Directory forest that you created in the [Base tutorial](ms_ad_tutorial_test_lab_base.md). You also learn to create a new native Active Directory forest on a Windows Server in Amazon EC2. As shown in the following illustration, the lab that you create from this tutorial is the second building block necessary when setting up a complete AWS Managed Microsoft AD test lab. You can use the test lab to test your pure cloud or hybrid cloud–based AWS solutions. You should only need to create this tutorial once. After that you can add optional tutorials when necessary for more experience. ![\[Steps to create a trust from a Microsoft Active Directory to a self-managed Active Directory: Set up your environment, create your Microsoft Active Directory, Deploy an Amazon EC2 instance, and test the lab.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/tutorialmicrosoftadtrust.png) **[Step 1: Set up your environment for trusts](microsoftadtruststep1.md)** Before you can establish trusts between a new Active Directory forest and the AWS Managed Microsoft AD forest that you created in the [Base tutorial](ms_ad_tutorial_test_lab_base.md), you need to prepare your Amazon EC2 environment. To do that, you first create a Windows Server 2019 server, promote that server to a domain controller, and then configure your VPC accordingly. **[Step 2: Create the trusts](microsoftadtruststep2.md)** In this step, you create a two-way forest trust relationship between your newly created Active Directory forest hosted in Amazon EC2 and your AWS Managed Microsoft AD forest in AWS. **[Step 3: Verify the trust](microsoftadtruststep3.md)** Finally, as an administrator, you use the Directory Service console to verify that the new trusts are operational. # Step 1: Set up your environment for trusts In this section, you set up your Amazon EC2 environment, deploy your new forest, and prepare your VPC for trusts with AWS. ![\[Amazon EC2 environment with Amazon VPC, subnets, and Internet Gateways to deploy a new forest and establish a trust relationship.\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/tutorialmicrosoftadbase_vpclayout.png) ## Create a Windows Server 2019 EC2 instance Use the following procedure to create a Windows Server 2019 member server in Amazon EC2. **To create a Windows Server 2019 EC2 instance** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the Amazon EC2 console, choose **Launch Instance**. 1. On the **Step 1** page, locate **Microsoft Windows Server 2019 Base - ami-*xxxxxxxxxxxxxxxxx*** in the list. Then choose **Select**. 1. On the **Step 2** page, select **t2.large**, and then choose **Next: Configure Instance Details**. 1. On the **Step 3** page, do the following: + For **Network**, select **vpc-*xxxxxxxxxxxxxxxxx* AWS-OnPrem-VPC01** (which you previously set up in the [Base tutorial](microsoftadbasestep1.md#createvpc)). + For **Subnet**, select **subnet-*xxxxxxxxxxxxxxxxx* \$1 AWS-OnPrem-VPC01-Subnet01 \$1 AWS-OnPrem-VPC01**. + For **Auto-assign Public IP** list, choose **Enable** (if the subnet setting is not set to **Enable** by default). + Leave the rest of the settings at their defaults. + Choose **Next: Add Storage**. 1. On the **Step 4** page, leave the default settings, and then choose **Next: Add Tags**. 1. On the **Step 5** page, choose **Add Tag**. Under **Key** type **example.local-DC01**, and then choose **Next: Configure Security Group**. 1. On the **Step 6** page, choose **Select an existing security group**, select **AWS On-Prem Test Lab Security Group** (which you previously set up in the [Base tutorial](microsoftadbasestep1.md#createsecuritygroup)), and then choose **Review and Launch** to review your instance. 1. On the **Step 7** page, review the page, and then choose **Launch**. 1. On the **Select an existing key pair or create a new key pair** dialog box, do the following: + Choose **Choose an existing key pair**. + Under **Select a key pair**, choose **AWS-DS-KP** (which you previously set up in the [Base tutorial](microsoftadbasestep1.md#createkeypair2)). + Select the **I acknowledge...** check box. + Choose **Launch Instances**. 1. Choose **View Instances** to return to the Amazon EC2 console and view the status of the deployment. ## Promote your server to a domain controller Before you can create trusts, you must build and deploy the first domain controller for a new forest. During this process you configure a new Active Directory forest, install DNS, and set this server to use the local DNS server for name resolution. You must reboot the server at the end of this procedure. **Note** If you want to create a domain controller in AWS that replicates with your on-premises network, you would first manually join the EC2 instance to your on-premises domain. After that you can promote the server to a domain controller. **To promote your server to a domain controller** 1. In the Amazon EC2 console, choose **Instances**, select the instance you just created, and then choose **Connect**. 1. In the **Connect To Your Instance** dialog box, choose **Download Remote Desktop File**. 1. In the **Windows Security** dialog box, type your local administrator credentials for the Windows Server computer to login (for example, **administrator**). If you do not yet have the local administrator password, go back to the Amazon EC2 console, right-click on the instance, and choose **Get Windows Password**. Navigate to your `AWS DS KP.pem` file or your personal `.pem` key, and then choose **Decrypt Password**. 1. From the **Start** menu, choose **Server Manager**. 1. In the **Dashboard**, choose **Add Roles and Features**. 1. In the **Add Roles and Features Wizard**, choose **Next**. 1. On the **Select installation type** page, choose **Role-based or feature-based installation**, and then choose **Next**. 1. On the **Select destination server** page, make sure that the local server is selected, and then choose **Next**. 1. On the **Select server roles** page, select **Active Directory Domain Services**. In the **Add Roles and Features Wizard** dialog box, verify that the **Include management tools (if applicable)** check box is selected. Choose **Add Features**, and then choose **Next**. 1. On the **Select features** page, choose **Next**. 1. On the **Active Directory Domain Services** page, choose **Next**. 1. On the **Confirm installation selections** page, choose **Install**. 1. Once the Active Directory binaries are installed, choose **Close**. 1. When Server Manager opens, look for a flag at the top next to the word **Manage**. When this flag turns yellow, the server is ready to be promoted. 1. Choose the yellow flag, and then choose **Promote this server to a domain controller**. 1. On the **Deployment Configuration** page, choose **Add a new forest**. In **Root domain name**, type **example.local**, and then choose **Next**. 1. On the **Domain Controller Options** page, do the following: + In both **Forest functional level** and **Domain functional level**, choose **Windows Server 2016**. + Under **Specify domain controller capabilities**, verify that both **DNS server** and **Global Catalog (GC)** are selected. + Type and then confirm a Directory Services Restore Mode (DSRM) password. Then choose **Next**. 1. On the **DNS Options** page, ignore the warning about delegation and choose **Next**. 1. On the **Additional options** page, make sure that **EXAMPLE** is listed as the NetBios domain name. 1. On the **Paths** page, leave the defaults, and then choose **Next**. 1. On **Review Options** page, choose **Next**. The server now checks to make sure all the prerequisites for the domain controller are satisfied. You may see some warnings displayed, but you can safely ignore them. 1. Choose **Install**. Once the installation is complete, the server reboots and then becomes a functional domain controller. ## Configure your VPC The following three procedures guide you through the steps to configure your VPC for connectivity with AWS. **To configure your VPC outbound rules** 1. In the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/), make a note of the AWS Managed Microsoft AD directory ID for corp.example.com that you previously created in the [Base tutorial](microsoftadbasestep2.md). 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Security Groups**. 1. Search for your AWS Managed Microsoft AD directory ID. In the search results, select the item with the description **AWS created security group for d-*xxxxxx* directory controllers**. **Note** This security group was automatically created when you initially created your directory. 1. Choose the **Outbound Rules** tab under that security group. Choose **Edit**, choose **Add another rule**, and then add the following values: + For **Type**, choose **All Traffic**. + For **Destination**, type **0.0.0.0/0**. + Leave the rest of the settings at their defaults. + Select **Save**. **To verify kerberos preauthentication is enabled** 1. On the **example.local** domain controller, open **Server Manager**. 1. On the **Tools** menu, choose **Active Directory Users and Computers**. 1. Navigate to the **Users** directory, right-click on any user and select **Properties**, and then choose the **Account** tab. In the **Account options** list, scroll down and ensure that **Do not require Kerberos preauthentication** is **not** selected. 1. Perform the same steps for the **corp.example.com** domain from the **corp.example.com-mgmt **instance. **To configure DNS conditional forwarders** **Note** A conditional forwarder is a DNS server on a network that is used to forward DNS queries according to the DNS domain name in the query. For example, a DNS server can be configured to forward all the queries it receives for names ending with widgets.example.com to the IP address of a specific DNS server or to the IP addresses of multiple DNS servers. 1. Open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. In the navigation pane, choose **Directories**. 1. Select the **directory ID** of your AWS Managed Microsoft AD. 1. Take note of the fully qualified domain name (FQDN), **corp.example.com**, and the DNS addresses of your directory. 1. Now, return to your **example.local** domain controller, and then open **Server Manager**. 1. On the **Tools** menu, choose **DNS**. 1. In the console tree, expand the DNS server of the domain for which you are setting up the trust, and navigate to **Conditional Forwarders**. 1. Right-click **Conditional Forwarders**, and then choose **New Conditional Forwarder**. 1. In DNS domain, type **corp.example.com**. 1. Under **IP addresses of the primary servers**, choose ****, type the first DNS address of your AWS Managed Microsoft AD directory (which you made note of in the previous procedure), and then press **Enter**. Do the same for the second DNS address. After typing the DNS addresses, you might get a "timeout" or "unable to resolve" error. You can generally ignore these errors. 1. Select the **Store this conditional forwarder in Active Directory, and replicate as follows** check box. In the drop-down menu, choose **All DNS servers in this Forest**, and then choose **OK**. # Step 2: Create the trusts In this section, you create two separate forest trusts. One trust is created from the Active Directory domain on your EC2 instance and the other from your AWS Managed Microsoft AD in AWS. ![\[Two way trust between corp.example.com and example.local\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/tutorialmicrosoftadtrust_twoway.png) **To create the trust from your EC2 domain to your AWS Managed Microsoft AD** 1. Log into **example.local**. 1. Open **Server Manager** and in the console tree choose **DNS**. Take note of the IPv4 address listed for the server. You will need this in the next procedure when you create a conditional forwarder from **corp.example.com** to the **example.local** directory. 1. In the **Tools** menu, choose **Active Directory Domains and Trusts**. 1. In the console tree, right-click **example.local** and then choose **Properties**. 1. On the **Trusts** tab, choose **New Trust**, and then choose **Next**. 1. On the **Trust Name** page, type **corp.example.com**, and then choose **Next**. 1. On the **Trust Type** page, choose **Forest trust**, and then choose **Next**. **Note** AWS Managed Microsoft AD also supports external trusts. However, for the purposes of this tutorial, you will create a two-way forest trust. 1. On the **Direction of Trust** page, choose **Two-way**, and then choose **Next**. **Note** If you decide later to try this with a one-way trust instead, ensure that the trust directions are setup correctly (Outgoing on trusting domain, Incoming on trusted domain). For general information, see [Understanding trust direction](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731404(v=ws.11)) on Microsoft's website. 1. On the **Sides of Trust** page, choose **This domain only**, and then choose **Next**. 1. On the **Outgoing Trust Authentication Level** page, choose **Forest-wide authentication**, and then choose **Next**. **Note** Although **Selective authentication** in an option, for the simplicity of this tutorial we recommend that you do not enable it here. When configured it restricts access over an external or forest trust to only those users in a trusted domain or forest who have been explicitly given authentication permissions to computer objects (resource computers) residing in the trusting domain or forest. For more information, see [Configuring selective authentication settings](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc816580(v=ws.10)). 1. On the **Trust Password** page, type the trust password twice, and then choose **Next**. You will use this same password in the next procedure. 1. On the **Trust Selections Complete** page, review the results, and then choose **Next**. 1. On the **Trust Creation Complete** page, review the results, and then choose **Next**. 1. On the **Confirm Outgoing Trust** page, choose **No, do not confirm the outgoing trust**. Then choose **Next** 1. On the **Confirm Incoming Trust** page, choose **No, do not confirm the incoming trust**. Then choose **Next** 1. On the **Completing the New Trust Wizard** page, choose **Finish**. **Note** Trust relationships is a global feature of AWS Managed Microsoft AD. If you are using [Configure Multi-Region replication for AWS Managed Microsoft AD](ms_ad_configure_multi_region_replication.md), the following procedures must be performed in the [Primary Region](multi-region-global-primary-additional.md#multi-region-primary). The changes will be applied across all replicated Regions automatically. For more information, see [Global vs Regional features](multi-region-global-region-features.md). **To create the trust from your AWS Managed Microsoft AD to your EC2 domain** 1. Open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. Choose the **corp.example.com** directory. 1. On the **Directory details** page, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the primary Region, 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 **Trust relationships** section, choose **Actions**, and then select **Add trust relationship**. 1. In the **Add a trust relationship** dialog box, do the following: + Under **Trust type** select **Forest trust**. **Note** Make sure that the **Trust type** you choose here matches the same trust type configured in the previous procedure (To create the trust from your EC2 domain to your AWS Managed Microsoft AD). + For **Existing or new remote domain name**, type **example.local**. + For **Trust password**, type the same password that you provided in the previous procedure. + Under **Trust direction**, select **Two-Way**. **Note** If you decide later to try this with a one-way trust instead, ensure that the trust directions are setup correctly (Outgoing on trusting domain, Incoming on trusted domain). For general information, see [Understanding trust direction](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731404(v=ws.11)) on Microsoft's website. Although **Selective authentication** in an option, for the simplicity of this tutorial we recommend that you do not enable it here. When configured it restricts access over an external or forest trust to only those users in a trusted domain or forest who have been explicitly given authentication permissions to computer objects (resource computers) residing in the trusting domain or forest. For more information, see [Configuring selective authentication settings](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc816580(v=ws.10)). + For **Conditional forwarder**, type the IP address of your DNS server in the **example.local** forest (which you noted in the previous procedure). **Note** A conditional forwarder is a DNS server on a network that is used to forward DNS queries according to the DNS domain name in the query. For example, a DNS server can be configured to forward all the queries it receives for names ending with widgets.example.com to the IP address of a specific DNS server or to the IP addresses of multiple DNS servers. 1. Choose **Add**. # Step 3: Verify the trust In this section, you test whether the trusts were set up successfully between AWS and Active Directory on Amazon EC2. **To verify the trust** 1. Open the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/). 1. Choose the **corp.example.com** directory. 1. On the **Directory details** page, do one of the following: + If you have multiple Regions showing under **Multi-Region replication**, select the primary Region, 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 **Trust relationships** section, select the trust relationship you just created. 1. Choose **Actions**, and then choose **Verify trust relationship**. Once the verification has completed, you should see **Verified** displayed under the **Status** column. Congratulations on completing this tutorial\$1 You now have a fully functional multiforest Active Directory environment from which you can begin testing various scenarios. Additional test lab tutorials are planned in 2018, so check back on occasion to see what's new. # AWS Managed Microsoft AD quotas Quotas The following are the default quotas for AWS Managed Microsoft AD. Each quota is per Region unless otherwise noted. **AWS Managed Microsoft AD quotas** | Resource | Default quota | | --- | --- | | AWS Managed Microsoft AD directories (Standard and Enterprise Editions) | 20 | | AWS Managed Microsoft AD directories (Hybrid Edition) | 5 | | Manual snapshots (Standard and Enterprise Editions) \$1 | 5 per AWS Managed Microsoft AD | | Manual snapshots age \$1\$1 | 180 days | | Maximum number of domain controllers per directory | 20 | | Shared domains per Standard Microsoft AD \$1\$1\$1 | 25 | | Shared domains per Enterprise Microsoft AD \$1\$1\$1 | 500 | | Shared domains per Hybrid Microsoft AD \$1\$1\$1 | 125 | | Maximum number of registered certificate authority (CA) certificates per directory | 5 | | Maximum number of total AWS Regions in a single AWS Managed Microsoft AD (Enterprise Edition) directory \$1\$1\$1\$1 | 5 | \$1 The manual snapshot quota cannot be changed. \$1\$1 The maximum supported age of a manual snapshot is 180 days and cannot be changed. This is due to the Tombstone-Lifetime attribute of deleted objects which defines the useful shelf life of a system-state backup of Active Directory. It is not possible to restore from a snapshot older than 180 days. For more information, see [Useful shelf life of a system-state backup of Active Directory](https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/shelf-life-system-state-backup-ad) on the Microsoft website. \$1\$1\$1 The shared domain default quota refers to the number of accounts that an individual directory can be shared to. \$1\$1\$1\$1 This includes 1 primary Region and up to 4 additional Regions. For more information, see [Primary vs additional Regions](multi-region-global-primary-additional.md). **Note** You cannot attach a public IP address to your AWS elastic network interface (ENI). For information regarding application design and load distribution, see [Best practices when programming your applications for an AWS Managed Microsoft AD](ms_ad_best_practices.md#program_apps). For storage and object quotas, see the **Comparison Table** on the [AWS Directory Service Pricing](https://aws.amazon.com/directoryservice/pricing/) page. # Troubleshooting AWS Managed Microsoft AD Troubleshooting The following can help you troubleshoot some common problems you might encounter when creating or using your AWS Managed Microsoft AD Active Directory. ## Problems with your AWS Managed Microsoft AD Some troubleshooting tasks can only be completed by Support. Here are some of the tasks: + Restarting your Directory Service-provided domain controllers. + [Upgrading your AWS Managed Microsoft AD](ms_ad_upgrade_edition.md). To create a support case, see [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html). ## Problems with Netlogon and secure channel communications As a mitigation against [CVE-2020-1472](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1472), Microsoft has released patching which modifies the way that Netlogon secure channel communications are processed by domain controllers. Since the introduction of these secure Netlogon changes, some Netlogon connections (servers, workstations, and trust validations) may not be accepted by your AWS Managed Microsoft AD. To verify if your issue is related to Netlogon or secure channel communications, search your Amazon CloudWatch Logs for event IDs 5827 (for device authentication related issues) or 5828 (for AD trust validation related issues). For information about CloudWatch in AWS Managed Microsoft AD, see [Enabling Amazon CloudWatch Logs log forwarding for AWS Managed Microsoft AD](ms_ad_enable_log_forwarding.md). For more information about the mitigation against CVE-2020-1472, see [How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472](https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-netlogon-secure-channel-connections-associated-with-cve-2020-1472-f7e8cc17-0309-1d6a-304e-5ba73cd1a11e) on Microsoft 's website. ## You receive a 'Response Status: 400 Bad Request' error when attempting to reset a user's password You receive an error message similar to the following when attempting to reset a user's password: `Response Status: 400 Bad Request` You may experience this issue when there are duplicate objects in your AWS Managed Microsoft AD Organizational Unit (OU) with identical user logon names. User logon names must be unique. See [Troubleshooting Directory Data problems](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb727059(v=technet.10)?redirectedfrom=MSDN) in Microsoft documentation for more information. ## Password recovery If a user forgets a password or is having trouble signing in to your AWS Managed Microsoft AD directory, you can reset their password using either the AWS Management Console, PowerShell or the AWS CLI. For more information, see [Resetting an AWS Managed Microsoft AD user password](ms_ad_manage_users_groups_reset_password.md). ## Additional resources The following resources can help you troubleshoot as you work with AWS. + **[AWS Knowledge Center](https://aws.amazon.com/premiumsupport/knowledge-center/)**–Find FAQs and links to other resources to help you troubleshoot issues. + **[AWS Support Center](https://console.aws.amazon.com/support/home#/)**–Get technical support. + **[AWS Premium Support Center](https://aws.amazon.com/premiumsupport/)**–Get premium technical support. The following resources can help you troubleshoot common Active Directory issues. + [Active Directory Documentation](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/active-directory-overview) + [AD DS Troubleshooting](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-ds-troubleshooting) **Topics** + [ ## Problems with your AWS Managed Microsoft AD ](#general_issues) + [ ## Problems with Netlogon and secure channel communications ](#ms_ad_tshoot_netlogon_issues) + [ ## You receive a 'Response Status: 400 Bad Request' error when attempting to reset a user's password ](#ms_ad_tshoot_reset_password) + [ ## Password recovery ](#ms_ad_tshoot_password_recovery) + [ ## Additional resources ](#troubleshoot_general_resources) + [ # Amazon EC2 Linux instance domain join errors ](ms_ad_troubleshooting_join_linux.md) + [ # AWS Managed Microsoft AD low available storage space ](ms_ad_troubleshooting_low_storage_space.md) + [ # Schema extension errors ](ms_ad_troubleshooting_schema.md) + [ # Trust creation status reasons ](ms_ad_troubleshooting_trusts.md) + [ # Troubleshooting AWS Managed Microsoft AD high CPU utilization ](ms_ad_troubleshooting_high_cpu.md) # Amazon EC2 Linux instance domain join errors The following can help you troubleshoot some error messages you might encounter when joining an Amazon EC2 Linux instance to your AWS Managed Microsoft AD directory. ## Linux instances unable to join domain or authenticate Ubuntu 14.04, 16.04, and 18.04 instances *must* be reverse-resolvable in the DNS before a realm can work with Microsoft Active Directory. Otherwise, you might encounter one of the following two scenarios: ### Scenario 1: Ubuntu instances that are not yet joined to a realm For Ubuntu instances that are attempting to join a realm, the `sudo realm join` command might not provide the required permissions to join the domain and might display the following error: \$1 Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Success) adcli: couldn't connect to EXAMPLE.COM domain: Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Success) \$1 Insufficient permissions to join the domain realm: Couldn't join realm: Insufficient permissions to join the domain ### Scenario 2: Ubuntu instances that are joined to a realm For Ubuntu instances that are already joined to a Microsoft Active Directory domain, attempts to SSH into the instance using the domain credentials might fail with following errors: \$1 ssh admin@EXAMPLE.COM@198.51.100 no such identity: /Users/username/.ssh/id\$1ed25519: No such file or directory admin@EXAMPLE.COM@198.51.100's password: Permission denied, please try again. admin@EXAMPLE.COM@198.51.100's password: If you log in to the instance with a public key and check `/var/log/auth.log`, you might see the following errors about being unable to find the user: May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.0 May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.0 user=admin@EXAMPLE.COM May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1sss(sshd:auth): received for user admin@EXAMPLE.COM: 10 (User not known to the underlying authentication module) May 12 01:02:14 ip-192-0-2-0 sshd[2251]: Failed password for invalid user admin@EXAMPLE.COM from 203.0.113.0 port 13344 ssh2 May 12 01:02:15 ip-192-0-2-0 sshd[2251]: Connection closed by 203.0.113.0 [preauth] However, `kinit` for the user still works. See this example: ubuntu@ip-192-0-2-0:\$1\$1 kinit admin@EXAMPLE.COM Password for admin@EXAMPLE.COM: ubuntu@ip-192-0-2-0:\$1\$1 klist Ticket cache: FILE:/tmp/krb5cc\$11000 Default principal: admin@EXAMPLE.COM ### Workaround The current recommended workaround for both of these scenarios is to disable reverse DNS in `/etc/krb5.conf` in the [libdefaults] section as shown below: ``` [libdefaults] default_realm = EXAMPLE.COM rdns = false ``` ## One-way trust authentication issue with seamless domain join If you have a one-way outgoing trust established between your AWS Managed Microsoft AD and your on-premises Active Directory, you might encounter an authentication issue when attempting to authenticate against the domain joined Linux instance using your trusted Active Directory credentials with Winbind. ### Errors Jul 31 00:00:00 EC2AMAZ-LSMWqT sshd[23832]: Failed password for user@corp.example.com from xxx.xxx.xxx.xxx port 18309 ssh2 Jul 31 00:05:00 EC2AMAZ-LSMWqT sshd[23832]: pam\$1winbind(sshd:auth): getting password (0x00000390) Jul 31 00:05:00 EC2AMAZ-LSMWqT sshd[23832]: pam\$1winbind(sshd:auth): pam\$1get\$1item returned a password Jul 31 00:05:00 EC2AMAZ-LSMWqT sshd[23832]: pam\$1winbind(sshd:auth): request wbcLogonUser failed: WBC\$1ERR\$1AUTH\$1ERROR, PAM error: PAM\$1SYSTEM\$1ERR (4), NTSTATUS: \$1\$1NT\$1STATUS\$1OBJECT\$1NAME\$1NOT\$1FOUND\$1\$1, Error message was: The object name is not found. Jul 31 00:05:00 EC2AMAZ-LSMWqT sshd[23832]: pam\$1winbind(sshd:auth): internal module error (retval = PAM\$1SYSTEM\$1ERR(4), user = 'CORP\$1user') ## Workaround To resolve this issue, you will need to comment out or remove a directive from the PAM module configuration file (`/etc/security/pam_winbind.conf`) using the following steps. 1. Open the `/etc/security/pam_winbind.conf` file in a text editor. ``` sudo vim /etc/security/pam_winbind.conf ``` 1. Comment out or remove the following directive **krb5\$1auth = yes**. ``` [global] cached_login = yes krb5_ccache_type = FILE #krb5_auth = yes ``` 1. Stop the Winbind service, and then start it again. ``` service winbind stop or systemctl stop winbind net cache flush service winbind start or systemctl start winbind ``` # AWS Managed Microsoft AD low available storage space Low available storage space When your AWS Managed Microsoft AD is impaired due to Active Directory having low available storage space, immediate action is required to return the directory to an active state. The two most common causes of this impairment are covered in the sections below: 1. [SYSVOL folder is storing more than essential group policy objects](#sysvol-folder-gpo) 1. [Active Directory database has filled the volume](#ad-db-filled-volume) For pricing information about AWS Managed Microsoft AD storage, see [Directory Service Pricing](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table). ## SYSVOL folder is storing more than essential group policy objects A common cause of this impairment is due to storing non-essential files for Group Policy processing in the SYSVOL folder. These non-essential files could be EXEs, MSIs, or any other file that is not essential for Group Policy to process. The essential objects for Group Policy to process are Group Policy Objects, Logon/off Scripts, and the [Central Store for Group Policy objects](https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/create-and-manage-central-store). Any non-essential files should be stored on a file server(s) other than your AWS Managed Microsoft AD domain controllers. If files for [Group Policy Software Installation](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/use-group-policy-to-install-software) are needed you should use a file server to store those installation files. If you would prefer to not self manage a file server, AWS provides a managed file server option, [Amazon FSx](https://aws.amazon.com/fsx/). To remove any unnecessary files you can access the SYSVOL share via it's universal naming convention (UNC) path. For example, if your domain's fully qualified domain name (FQDN) is example.com, the UNC path for the SYSVOL would be "\$1\$1example.local\$1SYSVOL\$1example.local\$1". Once you locate and remove objects that are not essential for Group Policy to process the directory, it should return to an Active state within 30 minutes. If after 30 minutes the directory is not active, please contact AWS Support. Storing only essential Group Policy files in your SYSVOL share will ensure that you will not impair your directory due to SYSVOL bloat. ## Active Directory database has filled the volume A common cause of this impairment is due to the Active Directory database filling the volume. To verify if this is the case, you can review the **total** count of objects in your directory. We bold the word **total** to ensure that you understand **deleted** objects still count towards the total number of objects in a directory. By default AWS Managed Microsoft AD keeps items in the AD Recycling Bin for 180 days before they become a Recycled-Object. Once an object becomes a Recycled-Object (tombstoned), it is retained for another 180 days before it is finally purged from the directory. So when an object is deleted it exists in the directory database for 360 day before it is purged. This is why the total number of objects need to be evaluated. For more details on AWS Managed Microsoft AD supported object counts, see [Directory Service Pricing](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table). To get the total number of objects in a directory that includes the deleted objects, you can run the following PowerShell command from a domain joined Windows instance. For steps how to setup a management instance, see [User and group management in AWS Managed Microsoft AD](ms_ad_manage_users_groups.md). ``` Get-ADObject -Filter * -IncludeDeletedObjects | Measure-Object -Property 'Count' | Select-Object -Property 'Count' ``` Below is an example output from the above command: ``` Count 10000 ``` If the total count is above the supported object count for your directory size listed in the note above, you have exceeded the capacity of your directory. Below are the options to resolve this impairment: 1. Cleanup AD 1. Delete any unwanted AD objects. 1. Remove any objects that are not wanted from the AD Recycling Bin. Note this is destructive and the only way to recover those deleted objects will be to perform a restore of the directory. 1. The following command will remove all deleted objects from the AD Recycling Bin. **Important** Use this command with extreme caution as this is a destructive command and the only way to recover those deleted objects will be to perform a restore of the directory. ``` $DomainInfo = Get-ADDomain $BaseDn = $DomainInfo.DistinguishedName $NetBios = $DomainInfo.NetBIOSName $ObjectsToRemove = Get-ADObject -Filter { isDeleted -eq $true } -IncludeDeletedObjects -SearchBase "CN=Deleted Objects,$BaseDn" -Properties 'LastKnownParent','DistinguishedName','msDS-LastKnownRDN' | Where-Object { ($_.LastKnownParent -Like "*OU=$NetBios,$BaseDn") -or ($_.LastKnownParent -Like '*\0ADEL:*') } ForEach ($ObjectToRemove in $ObjectsToRemove) { Remove-ADObject -Identity $ObjectToRemove.DistinguishedName -IncludeDeletedObjects } ``` 1. Open a case with AWS Support to request that Directory Service reclaims the free space. 1. If your directory type is Standard Edition Open a case with AWS Support requesting your directory be upgraded to Enterprise Edition. This will also increase the cost of your directory. For pricing information, see [Directory Service Pricing](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table). In AWS Managed Microsoft AD, members of the **AWS Delegated Deleted Object Lifetime Administrators** group have the ability to modify the `msDS-DeletedObjectLifetime` attribute which sets the amount of time in days that deleted objects are kept in the AD Recycling Bin before they become Recycled-Objects. **Note** This is an advanced topic. If configured inappropriately, it can result in data loss. We highly recommend that you first review [The AD Recycle Bin: Understanding, Implementing, Best Practices, and Troubleshooting](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/the-ad-recycle-bin-understanding-implementing-best-practices-and/ba-p/396944) to get a better understanding of these processes. The ability to change the `msDS-DeletedObjectLifetime` attribute value to a lower number can help ensure your object count does not exceed supported levels. The lowest valid value this attribute can be set to is 2 days. Once that value has exceeded you will no longer be able to recover the deleted object using the AD Recycling Bin. It will require restoring your directory from a snapshot to recover the object(s). For more information, see [Restoring your AWS Managed Microsoft AD with snapshots](ms_ad_snapshots.md). **Any restore from snapshot can result in data loss as they are a point in time.** To change Deleted Object Lifetime of your directory run the following command: **Note** If you run the command as is, it will set the Deleted Object Lifetime attribute value to 30 days. If you would like to make it longer or shorter replace "30" with whatever number you prefer. However, we recommend that you go no higher than the default number of 180. ``` $DeletedObjectLifetime = 30 $DomainInfo = Get-ADDomain $BaseDn = $DomainInfo.DistinguishedName Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,$BaseDn" -Partition "CN=Configuration,$BaseDn" -Replace:@{"msDS-DeletedObjectLifetime" = $DeletedObjectLifetime} ``` # Schema extension errors The following can help you troubleshoot some error messages you might encounter when extending the schema for your AWS Managed Microsoft AD directory. ## Referral **Error** *Add error on entry starting on line 1: Referral The server side error is: 0x202b A referral was returned from the server. The extended server error is: 0000202B: RefErr: DSID-0310082F, data 0, 1 access points \$1tref 1: ‘example.com' Number of Objects Modified: 0* **Troubleshooting** Ensure that all of the distinguished name fields have the correct domain name. In the example above, `DC=example,dc=com` should be replaced with the `DistinguishedName` shown by the cmdlet `Get-ADDomain`. ## Unable to read import file **Error** *Unable to read the import file. Number of Objects Modified: 0* **Troubleshooting** The imported LDIF file is empty (0 bytes). Ensure the correct file was uploaded. ## Syntax error **Error** *There is a syntax error in the input file Failed on line 21. The last token starts with 'q'. Number of Objects Modified: 0* **Troubleshooting** The text on line 21 is not formatted correctly. The first letter of the invalid text is `A`. Update line 21 with valid LDIF syntax. For more information about how to format the LDIF file, see [Step 1: Create your LDIF file](create.md). ## Attribute or value exists **Error** *Add error on entry starting on line 1: Attribute Or Value Exists The server side error is: 0x2083 The specified value already exists. The extended server error is: 00002083: AtrErr: DSID-03151830, \$11: \$1t0: 00002083: DSID-03151830, problem 1006 (ATT\$1OR\$1VALUE\$1EXISTS), data 0, Att 20019 (mayContain):len 4 Number of Objects Modified: 0* **Troubleshooting** The schema change has already been applied. ## No such attribute **Error** *Add error on entry starting on line 1: No Such Attribute The server side error is: 0x2085 The attribute value cannot be removed because it is not present on the object. The extended server error is: 00002085: AtrErr: DSID-03152367, \$11: \$1t0: 00002085: DSID-03152367, problem 1001 (NO\$1ATTRIBUTE\$1OR\$1VAL), data 0, Att 20019 (mayContain):len 4 Number of Objects Modified: 0* **Troubleshooting** The LDIF file is trying to remove an attribute from a class, but that attribute is currently not attached to the class. Schema change was probably already applied. **Error** *Add error on entry starting on line 41: No Such Attribute 0x57 The parameter is incorrect. The extended server error is: 0x208d Directory object not found. The extended server error is: "00000057: LdapErr: DSID-0C090D8A, comment: Error in attribute conversion operation, data 0, v2580" Number of Objects Modified: 0* **Troubleshooting** The attribute listed on line 41 is incorrect. Double-check the spelling. ## No such object **Error** *Add error on entry starting on line 1: No Such Object The server side error is: 0x208d Directory object not found. The extended server error is: 0000208D: NameErr: DSID-03100238, problem 2001 (NO\$1OBJECT), data 0, best match of: 'CN=Schema,CN=Configuration,DC=example,DC=com' Number of Objects Modified: 0* **Troubleshooting** The object referenced by the distinguished name (DN) does not exist. # Trust creation status reasons When trust creation fails for AWS Managed Microsoft AD, the status message contains additional information. The following can help you understand what those messages mean. ## Access is denied Access was denied when trying to create the trust. Either the trust password is incorrect or the remote domain's security settings do not allow a trust to be configured. For more information on trusts, see [Enhancing Trust Efficiency with Site Names and DCLocator](#enhancing-trust-site-names). To resolve this problem, try the following: + Verify that you are using the same trust password that you used when creating the corresponding trust on the remote domain. + Verify that your domain security settings allow for trust creation. + Verify that your local security policy is set correctly. Specifically check `Local Security Policy > Local Policies > Security Options > Network access: Named Pipes that can be accessed anonymously` and ensure that it contains at least the following three named pipes: + netlogon + samr + lsarpc + Verify that the above named pipes exist as the value(s) on the **NullSessionPipes** registry key which is in the registry path **HKLM\$1SYSTEM\$1CurrentControlSet\$1services\$1LanmanServer\$1Parameters**. These values must be inserted on separated rows. **Note** By default, `Network access: Named Pipes that can be accessed anonymously` is not set and will display `Not Defined`. This is normal, as the domain controller's effective default settings for `Network access: Named Pipes that can be accessed anonymously` is `netlogon`, `samr`, `lsarpc`. + Verify the following Server Message Block (SMB) Signing Setting in the *Default Domain Controllers Policy*. These settings can be found under **Computer Configuration** > **Windows Settings** > **Security Settings** > **Local Policies/Security Options**. They should match the following settings: + Microsoft network client: Digitally sign communications (always): Default: Enabled + Microsoft network server: Digitally sign communications (always): Enabled ### Enhancing Trust Efficiency with Site Names and DCLocator The First Site name like Default-First-Site-Name is not a requirement for establishing trust relationships between domains. However, aligning site names between domains can significantly improve the efficiency of the Domain Controller Locator (DCLocator) process. This alignment improves predicting and controlling the selection of domain controllers across the forest trusts. The DCLocator process is crucial for finding domain controllers across different domains and forests. For more information on the DCLocator process, see [Microsoft documentation](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/troubleshoot-domain-controller-location-issues). Efficient site configuration allows for quicker and more accurate domain controller location, which leads to better performance and reliability in cross-forest operations. For more information on how site names and DCLocator process interacts, see the following Microsoft articles: + [How Domain Controllers are Located Across Trusts](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-domain-controllers-are-located-across-trusts/ba-p/256180) + [Domain Locator Across Forests](https://techcommunity.microsoft.com/blog/askds/domain-locator-across-a-forest-trust/395689) ## The specified domain name does not exist or could not be contacted Domain does not exist To resolve this problem, ensure the security group settings for your domain and access control list (ACL) for your VPC are correct and you have accurately entered the information for your conditional forwarder. AWS configures the security group to open only the ports that are required for Active Directory communications. In the default configuration, the security group accepts traffic to these ports from any IP address. Outbound traffic is restricted to the Security group. You will need to update the outbound rule on the security group to allow traffic to your on premise network. For more information about security requirements, please see [Step 2: Prepare your AWS Managed Microsoft AD](ms_ad_tutorial_setup_trust_prepare_mad.md). ![\[Edit security group\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/edit_security_group.png) If the DNS servers for the networks of the other directories use public (non-RFC 1918) IP addresses, you will need add an IP route on the directory from the Directory Services Console to the DNS Servers. For more information, see [Create, verify, or delete a trust relationship](ms_ad_setup_trust.md#trust_steps) and [Prerequisites](ms_ad_setup_trust.md#trust_prereq). The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: + 10.0.0.0 - 10.255.255.255 (10/8 prefix) + 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) + 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) For more information, see [https://tools.ietf.org/html/rfc1918](https://tools.ietf.org/html/rfc1918). Verify that the **Default AD Site Name** for your AWS Managed Microsoft AD matches the **Default AD Site Name** in your on-premises infrastructure. The computer determines the site name using a domain of which the computer is a member, not the user's domain. Renaming the site to match the closest on-premises ensures the DC locator will use a domain controller from the closest site. If this does not solve the issue, it is possible that information from a previously created conditional forwarder has been cached, preventing the creation of a new trust. Wait several minutes, and then try creating the trust and conditional forwarder again. For more information about how this works, see [Domain Locator Across a Forest Trust](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689) on Microsoft website. ![\[Default first site name\]](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/images/default_first_site_name.png) ## The operation could not be performed on this domain Operation could not be performed To resolve this, ensure both domains / directories do not have overlapping NETBIOS name(s). If the domains / directories do have overlapping NETBIOS names, recreate one of them with a different NETBIOS name, and then try again. ## Trust creation is failing because of the error "Required and valid domain name" Trust creation failed DNS names can contain only alphabetical characters (A-Z), numeric characters (0-9), the minus sign (-), and a period (.). Period characters are allowed only when they are used to delimit the components of domain style names. Also, consider the following: + AWS Managed Microsoft AD does not support trusts with Single label domains. For more information, see [Microsoft support for Single Label Domains](https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/single-label-domains-support-policy). + According to RFC 1123 ([https://tools.ietf.org/html/rfc1123](https://tools.ietf.org/html/rfc1123)), the only characters that can be used in DNS labels are "A" to "Z", "a" to "z", "0" to "9", and a hyphen ("-"). A period [.] is also used in DNS names, but only between DNS labels and at the end of an FQDN. + According to RFC 952 ([https://tools.ietf.org/html/rfc952](https://tools.ietf.org/html/rfc952)), a "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". For more information, see [Complying with Name Restrictions for Hosts and Domains](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959336(v=technet.10)) on Microsoft website. ## General tools for testing trusts Trust troubleshooting tools The following are tools that can be used to troubleshoot various trust related issues. **AWS Systems Manager Automation troubleshooting tool** [Support Automation Workflows (SAW)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-support.html) leverage AWS Systems Manager Automation to provide you with a predefined runbook for Directory Service. The [AWSSupport-TroubleshootDirectoryTrust](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-awssupport-troubleshootdirectorytrust.html) runbook tool helps you diagnose common trust creation issues between AWS Managed Microsoft AD and an on-premises Microsoft Active Directory. **DirectoryServicePortTest tool** The [DirectoryServicePortTest](samples/DirectoryServicePortTest.zip) testing tool can be helpful when troubleshooting trust creation issues between AWS Managed Microsoft AD and on-premises Active Directory. For an example on how the tool can be used, see [Test your AD Connector](ad_connector_getting_started.md#connect_verification). **NETDOM and NLTEST tool** Administrators can use both the **Netdom** and **Nltest** command-line tools to find, display, create, remove and manage trusts. These tools communicate directly with the LSA authority on a domain controller. For an example on how to use these tools, see [Netdom](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc772217(v=ws.11)) and [NLTEST](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11)) on Microsoft website. **Packet capture tool** You can use the built-in Windows package capture utility to investigate and troubleshoot a potential network 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). # Troubleshooting AWS Managed Microsoft AD high CPU utilization High CPU utilization The following can help you troubleshoot high CPU issues on AWS Managed Microsoft AD domain controllers. ## Finding the root cause The first step in troubleshooting high CPU utilization is to analyze CloudWatch metrics to identify patterns that may explain the increased resource consumption. ### Step 1: Review Directory Service CloudWatch metrics Monitor your AWS Managed Microsoft AD performance using CloudWatch metrics to identify traffic patterns that correlate with high CPU usage. For detailed information on viewing and interpreting Directory Service metrics, see [Using CloudWatch to monitor the performance of your AWS Managed Microsoft AD domain controllers](ms_ad_monitor_dc_performance.md). Look for shifting patterns in the following key metrics that might explain the CPU increase: + **DNS queries per second** – Sudden spikes may indicate DNS resolution issues or misconfigured applications. + **Kerberos/NTLM authentications** – Higher authentication rates from user logons or service accounts. + **LDAP queries per second** – Increased LDAP traffic from applications or services. Compare current metrics with historical baselines to identify when the high CPU utilization began and correlate it with specific traffic increases. If no correlation is found in the metrics then the root cause is not an overwhelming increase in traffic. Instead the root cause is likely an inefficient LDAP query, skip to [Step 3: Capture detailed traffic analysis with Traffic Mirroring](#ms_ad_high_cpu_step3). ### Step 2: Identify source machines using VPC Flow Logs VPC Flow Logs provide an effective method to identify the source IP addresses of machines generating traffic to your domain controllers. For more information, see [Logging IP traffic using VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html). Use the destination port numbers to differentiate between services: + **Port 53** – DNS queries + **Port 88** – Kerberos authentication + **Port 123** – NTP clock synchronization + **Port 135, 49152-65535** – RPC + **Ports 389, 636, 3268, 3269** – LDAP queries (389 or 3268 for standard LDAP, 636 or 3269 for LDAPS) + **Port 445** – SMB file sharing (Group Policies) + **Port 464** – Kerberos password change + **Port 9389** – Active Directory Web Service To enable and analyze VPC Flow Logs: + Enable VPC Flow Logs for the subnets containing your domain controller ENIs. + Filter logs by destination ports to identify traffic patterns. + Organize by most packets and/or most bytes over the period of time. + Analyze source IP addresses to determine which machines are generating the most traffic. ### Step 3: Capture detailed traffic analysis with Traffic Mirroring VPC Flow Logs provide limited information about the actual content of requests. For more detailed analysis, consider Traffic Mirroring to capture full packet data. For more information, see [Get started using Traffic Mirroring to monitor network traffic](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-getting-started.html). This is particularly useful when you need to analyze: + LDAP filter complexity and efficiency + Specific DNS query patterns + Authentication request details Traffic Mirroring allows you to capture complete network packets sent to your domain controller instances, enabling deep analysis of the traffic causing high CPU utilization. ### Step 4: Investigate source applications and optimize traffic Once you've identified the source machines and traffic patterns, investigate the applications generating the traffic: + **Review application configurations** – Check if applications are making inefficient queries or excessive requests. Avoid hard coding the application to a single domain controller. + **Analyze LDAP queries** – Inefficient LDAP queries are the most common cause of high domain controller CPU. Look for complex filters that could benefit from attribute indexing. + **Examine DNS caching** – Verify that DNS client caching is enabled to reduce repetitive queries. + **Check authentication patterns** – Identify if service accounts are authenticating too frequently. ## Resolution strategies Based on your investigation, implement appropriate optimization strategies: ### Optimize applications + **Optimize LDAP queries** – Rewrite complex LDAP queries. Avoid setting the search base to the root of the domain and instead configure it to an OU where the objects you are searching for reside. Avoid using a search scope that performs subtree searches. Instead use a base or single level scope. Include the object class in your filter. For example, `(objectClass=user)` or `(objectClass=computer)`. Avoid using wildcards in the filter unless the attribute is indexed. Add an index if a wildcard scan is required. For more information, see [Extend your AWS Managed Microsoft AD schema](ms_ad_schema_extensions.md). Don't index everything as the indexing process also increases CPU utilization. ``` # Sample LDIF code to index the email attribute dn: CN=mail,CN=Schema,CN=Configuration,DC=yourdomain,DC=com changetype: modify replace: searchFlags searchFlags: 1 ``` + **Enable DNS client caching** – Configure clients to cache DNS responses locally to reduce server load. + **Implement connection pooling** – Configure applications to reuse LDAP connections rather than creating new ones for each query. ### Scale your directory infrastructure If traffic optimization doesn't resolve the high CPU utilization: + **Add more domain controllers** – Scale out by deploying additional domain controllers to distribute the load. For more information, see [Deploying additional domain controllers for your AWS Managed Microsoft AD](ms_ad_deploy_additional_dcs.md). + **Upgrade to Enterprise Edition** – If using Standard Edition, upgrade to Enterprise Edition for increased CPU capacity and performance. For more information, see [Upgrading your AWS Managed Microsoft AD](ms_ad_upgrade_edition.md). If already using Enterprise Edition, Contact [AWS Support](https://docs.aws.amazon.com//awssupport/latest/user/case-management.html) for increased capacity. For pricing information about AWS Managed Microsoft AD editions, see [Directory Service Pricing](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table).