# Using a self-managed Microsoft Active Directory
Using a self-managed Active Directory
If your organization manages identities and devices using a self-managed Active Directory on-premises or in the cloud, you can join an FSx for Windows File Server file system to your Active Directory domain at creation.
When you join your file system to your self-managed Active Directory, your FSx for Windows File Server file system resides in the same Active Directory forest (the top logical container in an Active Directory configuration that contains domains, users, and computers) and in the same Active Directory domain as your users and existing resources (including existing file servers).
**Note**
You can isolate your resources—including your Amazon FSx file systems—into a separate Active Directory forest from the one where your users reside. To do this, join your file system to an AWS Managed Microsoft Active Directory and establish a one-way forest trust relationship between an AWS Managed Microsoft Active Directory that you create and your existing self-managed Active Directory.
+ User name and password for a service account on your Active Directory domain, for Amazon FSx to use to join the file system to your Active Directory domain. You can provide these credentials as plaintext or store them in AWS Secrets Manager and provide the secret ARN (recommended).
+ (Optional) The Organizational Unit (OU) in your domain in which you want your file system to be joined.
+ (Optional) The domain group to which you want to delegate authority to perform administrative actions on your file system. For example, this domain group might manage Windows file shares, manage Access Control Lists (ACLs) on the file system's root folder, take ownership of files and folders, and so on. If you don’t specify this group, Amazon FSx delegates this authority to the Domain Admins group in your Active Directory domain by default.
**Note**
The domain group name you provide must be unique in your Active Directory. FSx for Windows File Server will not create the domain group under the following circumstances:
If a group already exists with the name you specify
If you do not specify a name, and a group named "Domain Admins" already exists in your Active Directory.
For more information, see [Joining an Amazon FSx file system to a self-managed Microsoft Active Directory domain](creating-joined-ad-file-systems.md).
**Topics**
+ [
## Prerequisites
](#self-manage-prereqs)
+ [
## Service account permissions
](#service-account-prereqs)
+ [
## Best practices when using a self-managed Active Directory
](#self-managed-AD-best-practices)
+ [
## Amazon FSx service account
](#self-managed-AD-service-account)
+ [
# Delegating permissions to the Amazon FSx service account or group
](assign-permissions-to-service-account.md)
+ [
# Validating your Active Directory configuration
](validate-ad-config.md)
+ [
# Joining an Amazon FSx file system to a self-managed Microsoft Active Directory domain
](creating-joined-ad-file-systems.md)
+ [
# Getting the correct file system IP addresses to use for manual DNS entries
](file-system-ip-addresses-for-dns.md)
+ [
# Updating a self-managed Active Directory configuration
](update-self-ad-config.md)
+ [
# Changing the Amazon FSx service account
](changing-ad-service-account.md)
+ [
# Monitoring self-managed Active Directory updates
](monitor-self-ad-update.md)
## Prerequisites
Before you join an FSx for Windows File Server file system to your self-managed Microsoft Active Directory domain, review the following prerequisites to help ensure that you can successfully join your Amazon FSx file system to your self-managed Active Directory.
### On-premises configurations
These are the prerequisites for your self-managed Microsoft Active Directory, either an on-premises or cloud-based, that you will join the Amazon FSx file system to.
+ The Active Directory domain controllers:
+ Must have a domain functional level at Windows Server 2008 R2 or higher.
+ Must be writable.
+ At least one of the reachable domain controllers must be a Global Catalog of the forest.
+ The DNS server must be able to resolve names as follows:
+ In the domain that you are joining the file system
+ In the root domain of the forest
+ The DNS server and Active Directory domain controller IP addresses must meet the following requirements, which vary depending on when your Amazon FSx file system was created:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/WindowsGuide/self-managed-AD.html)
If you need to access an FSx for Windows File Server file system that was created before December 17, 2020 using a non-private IP address range, you can create a new file system by restoring a backup of the file system. For more information, see [Restoring a backup to a new file system](how-to-restore-backups.md).
+ The domain name of your self-managed Active Directory must meet the following requirements:
+ The domain name isn't in Single Label Domain (SLD) format. Amazon FSx doesn't support SLD domains.
+ For Single-AZ 2 and all Multi-AZ file systems, the domain name cannot exceed 47 characters.
+ Any Active Directory sites that you have defined must meet the following prerequisites:
+ The subnets in the VPC that's associated with your file system must be defined in an Active Directory site.
+ There are no conflicts between the VPC subnets and any of the Active Directory site subnets.
Amazon FSx requires connectivity to the domain controllers or Active Directory sites you have defined in your Active Directory environment. Amazon FSx will ignore any domain controllers with TCP and UDP blocked on port 389. For the remaining domain controllers in your Active Directory, ensure that they meet the Amazon FSx connectivity requirements. Additionally, verify that any changes to your service account are propagated to all these domain controllers.
**Important**
Do not move computer objects that Amazon FSx creates in the OU after your file system is created. Doing so will cause your file system to become misconfigured.
You can validate your Active Directory configuration, including testing connectivity of multiple domain controllers, using the [Amazon FSx Active Directory Validation tool](validate-ad-config.md). To limit the number of domain controllers that require connectivity, you can also build a trust relationship between your on-premise domain controllers and AWS Managed Microsoft AD. For more information, see [Using a resource forest isolation model](fsx-aws-managed-ad.md#using-a-rfim).
**Important**
Amazon FSx only registers the DNS records for a file system if you are using Microsoft DNS as the default DNS service. If you are using a third-party DNS, you will need to manually set up DNS record entries for your file system after you create it.
### Network configurations
This section describes the network configuration requirements for joining a file system to your self-managed Active Directory. We strongly recommend that you use the [Amazon FSx Active Directory validation tool](validate-ad-config.md#test-ad-network-config) to test your network settings before attempting to join your file system to your self-managed Active Directory.
+ Ensure that your firewall rules will allow ICMP traffic between your Active Directory domain controllers and Amazon FSx.
+ Connectivity must be configured between the Amazon VPC where you want to create the file system and your self-managed Active Directory. You can set up this connectivity using [Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html), [AWS Virtual Private Network](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html), [VPC peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), or [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html).
+ The default VPC security group for your default Amazon VPC must be added to your file system using the Amazon FSx console. Ensure that the security group and the VPC Network ACLs for the subnets where you create your file system allow traffic on the ports and in the direction shown in the following diagram.
![\[FSx for Windows File Server port configuration requirements for VPC security groups and network ACLs for the subnets where the file system is created.\]](http://docs.aws.amazon.com/fsx/latest/WindowsGuide/images/Windows-port-requirements.png)
The following table identifies the protocol, ports, and its role.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/WindowsGuide/self-managed-AD.html)
These traffic rules need to also be mirrored on the firewalls that apply to each of the Active Directory domain controllers, DNS servers, FSx clients, and FSx administrators.
**Note**
If you're using VPC network ACLs, you must also allow outbound traffic on dynamic ports (49152-65535) from your file system.
**Important**
While Amazon VPC security groups require ports to be opened only in the direction that network traffic is initiated, most Windows firewalls and VPC network ACLs require ports to be open in both directions.
## Service account permissions
You need to have a service account in your self-managed Microsoft Active Directory with delegated permissions to join computer objects to your self-managed Active Directory domain. A *service account *is a user account in your self-managed Active Directory that has been delegated certain tasks.
The following is the minimum set of permissions that must be delegated to the Amazon FSx service account in the OU that you're joining the file system to.
+ If using *Delegate Control* in the Active Directory User and Computers MMC:
+ Reset passwords
+ Read and write Account Restrictions
+ Validated write to DNS host name
+ Validated write to service principal name
+ If using *Advanced Features* in the Active Directory User and Computers MMC:
+ Modify permissions
+ Create computer objects
+ Delete computer objects
For more information, see the Microsoft Windows Server documentation topic [ Error: Access is denied when non-administrator users who have been delegated control try to join computers to a domain controller](https://support.microsoft.com/en-us/help/932455/error-message-when-non-administrator-users-who-have-been-delegated-con).
For more information about setting the required permissions, see [Delegating permissions to the Amazon FSx service account or group](assign-permissions-to-service-account.md).
## Best practices when using a self-managed Active Directory
**Topics**
+ [
### Storing Active Directory credentials using AWS Secrets Manager
](#bp-store-ad-creds-using-secret-manager-windows)
We recommend that you follow these best practices when joining an Amazon FSx for Windows File Server file systems to your self-managed Microsoft Active Directory. These best practices will help you in maintaining continuous, uninterrupted availability of your file system.
**Use a separate service account for Amazon FSx**
Use a separate service account to delegate the [required privileges](#service-account-prereqs) for Amazon FSx to fully manage file systems that are joined to your self-managed Active Directory. We do not recommend using the **Domain Admins** for this purpose.
**Use an Active Directory group**
Use an Active Directory group to manage Active Directory permissions and configurations associated with the Amazon FSx service account.
**Segregate the Organizational Unit (OU)**
To make it easier to find and manage your Amazon FSx computer objects, we recommend that you segregate the Organizational Unit (OU) you use for your FSx for Windows File Server file systems from other domain controller concerns.
**Keep the Active Directory configuration up-to-date**
It is imperative that you keep your file system's Active Directory configuration up-to-date with any changes. For example, if your self-managed Active Directory uses a time-based password reset policy, as soon as the password is reset, make sure to update the service account password on your file system. For more information, see [Updating a self-managed Active Directory configuration](update-self-ad-config.md).
**Changing the Amazon FSx service account**
If you update your file system with a new service account, it must have the required permissions and privileges to join your Active Directory and have **Full control** permissions for the existing computer objects associated with the file system. For more information, see [Changing the Amazon FSx service account](changing-ad-service-account.md).
**Assign subnets to a single Microsoft Active Directory site**
If your Active Directory environment has a large number of domain controllers, use **Active Directory Sites and Services** to assign the subnets used by your Amazon FSx file systems to a single Active Directory site with the highest availability and reliability. Make sure that the VPC security group, VPC network ACL, Windows firewall rules on your DCs, and any other network routing controls you have in your Active Directory infrastructure allow communication from Amazon FSx on the required ports. This allows Windows to revert to other domain controllers if it can't use the assigned Active Directory site. For more information, see [File system access control with Amazon VPC](limit-access-security-groups.md).
**Use security group rules to limit traffic**
Use security group rules to implement the principle of least privilege in your virtual private cloud (VPC). You can limiting the type of inbound and outbound network traffic allowed for your file using VPC security group rules. For example, we recommend only allowing outbound traffic to your self-managed Active Directory domains controllers or to within the subnet or security group you are using. For more information, see [File system access control with Amazon VPC](limit-access-security-groups.md).
**Do not move computer objects created by Amazon FSx**
Do not move computer objects that Amazon FSx creates in the OU after your file system is created. Doing so will cause your file system to become misconfigured.
**Validate your Active Directory configuration**
Before attempting to join an FSx for Windows File Server file system to your Active Directory, we strongly recommend that you validate your Active Directory configuration using the [Amazon FSx Active Directory Validation tool](validate-ad-config.md).
### Storing Active Directory credentials using AWS Secrets Manager
You can use AWS Secrets Manager to securely store and manage your Microsoft Active Directory domain join service account credentials. This approach eliminates the need to store sensitive credentials in plaintext in application code or configuration files, strengthening your security posture.
You can also configure IAM policies to manage access to your secrets, and set up automatic rotation policies for your passwords.
#### Store Active Directory credentials in AWS Secrets Manager (Console)
##### Step 1: Create a KMS key
Create a KMS key to encrypt and decrypt your Active Directory credentials in Secrets Manager.
**To create a key**
**Note**
For **Encryption Key**, create a new key, don't use the AWS default KMS key. Be sure to create the AWS KMS key in the same Region that contains the file system that you want to join to your Active Directory.
1. Open the AWS KMS console at https://console.aws.amazon.com/kms.
1. Choose **Create key**.
1. For **Key Type**, choose **Symmetric**.
1. For **Key Usage**, choose **Encrypt and decrypt**.
1. For **Advanced options**, do the following:
1. For **Key material origin**, choose **KMS**.
1. For **Regionality**, choose **Single-Region key** and choose **Next**.
1. 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**, provide a tag for the KMS key and choose **Next**.
1. (Optional) For **Key administrators**, provide the IAM users and roles authorized to manage this key.
1. For **Key deletion**, keep the box selected for **Allow key administrators** to delete this key and choose **Next**.
1. (Optional) For **Key users**, provide the IAM users and roles authorized to use this key in cryptographic operations. Choose **Next**.
1. For **Key policy**, choose **Edit** and include the following to the policy **Statement** to allow Amazon FSx to use the KMS key and choose **Next**. Make sure to replace the *us-west-2* to the AWS Region where the file system is deployed and *123456789012* to your AWS account ID.
```
{
"Sid": "Allow FSx to use the KMS key",
"Version": "2012-10-17",
"Effect": "Allow",
"Principal": {
"Service": "fsx.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:us-west-2:123456789012:key/*",
"Condition": {
"StringEquals": {
"kms:ViaService": "secretsmanager.us-west-2.amazonaws.com",
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:fsx:us-west-2:123456789012:file-system/*"
}
}
}
```
1. Choose **Finish**.
**Note**
You can set more granular access control by modifying the `Resource` and `aws:SourceArn` fields to target specific secrets and file systems.
##### Step 2: Create an AWS Secrets Manager secret
**To create a secret**
1. Open the Secrets Manager console at [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).
1. Choose **Store a new secret**.
1. For **Secret type**, choose **Other type of secret**.
1. For **Key/value pairs**, do the following to add your two keys:
1. For the first key, enter `CUSTOMER_MANAGED_ACTIVE_DIRECTORY_USERNAME`.
1. For the value of the first key, enter only the username (without the domain prefix) of the AD user.
1. For the second key, enter `CUSTOMER_MANAGED_ACTIVE_DIRECTORY_PASSWORD`.
1. For the value of the second key, enter the password that you created for the AD user on your domain.
1. For **Encryption key**, enter the ARN of the KMS key that you created in a previous step and choose **Next**.
1. For **Secret name**, enter a descriptive name that helps you find your secret later.
1. (Optional) For **Description**, enter a description for the secret name.
1. For **Resource permission**, choose **Edit**.
Add the following policy to the permission policy to allow Amazon FSx to use the secret, then choose **Next**. Make sure to replace the *us-west-2* to the AWS Region where the file system is deployed and *123456789012* to your AWS account ID.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "fsx.amazonaws.com"
},
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:us-west-2:123456789012:secret:*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:fsx:us-west-2:123456789012:file-system/*"
}
}
}
]
}
```
**Note**
You can set more granular access control by modifying the `Resource` and `aws:SourceArn` fields to target specific secrets and file systems.
1. (Optional) You can configure Secrets Manager to rotate your credentials automatically. Choose **Next**.
1. Choose **Finish**.
#### Store Active Directory credentials in AWS Secrets Manager (CLI)
##### Step 1: Create a KMS key
Create a KMS key to encrypt and decrypt your Active Directory credentials in Secrets Manager.
To create a KMS key, use the AWS CLI command [create-key](https://docs.aws.amazon.com/cli/latest/reference/kms/create-key.html).
In this command, set the `--policy` parameter to specify the key policy that defines permissions for the KMS key. The policy must include the following:
+ The service principal for Amazon FSx, which is `fsx.amazonaws.com`.
+ Required KMS actions: `kms:Decrypt` and `kms:DescribeKey`.
+ Resource ARN pattern for your AWS Region and account.
+ Condition keys that restrict key usage:
+ `kms:ViaService` to ensure requests come through Secrets Manager.
+ `aws:SourceAccount` to limit to your account.
+ `aws:SourceArn` to restrict to specific Amazon FSx file systems.
The following example creates a symmetric encryption KMS key with a policy that allows Amazon FSx to use the key for decryption and key description operations. The command automatically retrieves your AWS account ID and Region, then configures the key policy with these values to ensure proper access controls between Amazon FSx, Secrets Manager, and the KMS key. Make sure your AWS CLI environment is in the same region as the file system that will join the Active Directory.
```
# Set region and get Account ID
REGION=${AWS_REGION:-$(aws configure get region)}
ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)
# Create Key
KMS_KEY_ARN=$(aws kms create-key --policy "{
\"Version\": \"2012-10-17\",
\"Statement\": [
{
\"Sid\": \"Enable IAM User Permissions\",
\"Effect\": \"Allow\",
\"Principal\": {
\"AWS\": \"arn:aws:iam::$ACCOUNT_ID:root\"
},
\"Action\": \"kms:*\",
\"Resource\": \"*\"
},
{
\"Sid\": \"Allow FSx to use the KMS key\",
\"Effect\": \"Allow\",
\"Principal\": {
\"Service\": \"fsx.amazonaws.com\"
},
\"Action\": [
\"kms:Decrypt\",
\"kms:DescribeKey\"
],
\"Resource\": \"*\",
\"Condition\": {
\"StringEquals\": {
\"kms:ViaService\": \"secretsmanager.$REGION.amazonaws.com\",
\"aws:SourceAccount\": \"$ACCOUNT_ID\"
},
\"ArnLike\": {
\"aws:SourceArn\": \"arn:aws:fsx:$REGION:$ACCOUNT_ID:file-system/*\"
}
}
}
]
}" --query 'KeyMetadata.Arn' --output text)
echo "KMS Key ARN: $KMS_KEY_ARN"
```
**Note**
You can set more granular access control by modifying the `Resource` and `aws:SourceArn` fields to target specific secrets and file systems.
##### Step 2: Create an AWS Secrets Manager secret
To create a secret for Amazon FSx to access your Active Directory, use the AWS CLI command [create-secret](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/create-secret.html) and set the following parameters:
+ `--name`: The identifier for your secret.
+ `--description`: A description of the secret's purpose.
+ `--kms-key-id`: The ARN of the KMS key you created in [Step 1](#create-kms-key-windows-cli) for encrypting the secret at rest.
+ `--secret-string`: A JSON string containing your AD credentials in the following format:
+ `CUSTOMER_MANAGED_ACTIVE_DIRECTORY_USERNAME`: Your AD service account username without the domain prefix, such as `svc-fsx`. **Don't** provide the domain prefix, such as `CORP\svc-fsx`.
+ `CUSTOMER_MANAGED_ACTIVE_DIRECTORY_PASSWORD`: Your AD service account password.
+ `--region`: The AWS Region where your Amazon FSx file system will be created. This defaults to your configured region if `AWS_REGION` is not set.
After creating the secret, attach a resource policy using the [put-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/logs/put-resource-policy.html) command, and set the following parameters:
+ `--secret-id`: The name or ARN of the secret to attach the policy to. The following example uses **FSxSecret** as the `--secret-id`.
+ `--region`: The same AWS Region as your secret.
+ `--resource-policy`: A JSON policy document that grants Amazon FSx permission to access the secret. The policy must include the following:
+ The service principal for Amazon FSx, which is **fsx.amazonaws.com**.
+ Required Secrets Manager actions: `secretsmanager:GetSecretValue` and `secretsmanager:DescribeSecret`.
+ Resource ARN pattern for your AWS Region and account.
+ The following condition keys that restrict access:
+ `aws:SourceAccount` to limit to your account.
+ `aws:SourceArn` to restrict to specific Amazon FSx file systems.
The following example creates a secret with the required format and attaches a resource policy that allows Amazon FSx to use the secret. This example automatically retrieves your AWS account ID and Region, then configures the resource policy with these values to ensure proper access controls between Amazon FSx and the secret.
Make sure to replace the `KMS_KEY_ARN` with the ARN from the key you created in [Step 1](#create-kms-key-windows-cli), `CUSTOMER_MANAGED_ACTIVE_DIRECTORY_USERNAME`, and `CUSTOMER_MANAGED_ACTIVE_DIRECTORY_PASSWORD` with your Active Directory service account credentials. Additionally, verify that your AWS CLI environment is configured for the same region as the file system that will join the Active Directory.
```
# Set region and get account ID
REGION=${AWS_REGION:-$(aws configure get region)}
ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)
# Replace with your KMS key ARN from Step 1
KMS_KEY_ARN="arn:aws:kms:us-east-2:123456789012:key/1234542f-d114-555b-9ade-fec3c9200d8e"
# Replace with your Active Directory credentials
AD_USERNAME="Your_Username"
AD_PASSWORD="Your_Password"
# Create the secret
SECRET_ARN=$(aws secretsmanager create-secret \
--name "FSxSecret" \
--description "Secret for FSx access" \
--kms-key-id "$KMS_KEY_ARN" \
--secret-string "{\"CUSTOMER_MANAGED_ACTIVE_DIRECTORY_USERNAME\":\"$AD_USERNAME\",\"CUSTOMER_MANAGED_ACTIVE_DIRECTORY_PASSWORD\":\"$AD_PASSWORD\"}" \
--region "$REGION" \
--query 'ARN' \
--output text)
echo "Secret created with ARN: $SECRET_ARN"
# Attach the resource policy with proper formatting
aws secretsmanager put-resource-policy \
--secret-id "FSxSecret" \
--region "$REGION" \
--resource-policy "{
\"Version\": \"2012-10-17\",
\"Statement\": [
{
\"Effect\": \"Allow\",
\"Principal\": {
\"Service\": \"fsx.amazonaws.com\"
},
\"Action\": [
\"secretsmanager:GetSecretValue\",
\"secretsmanager:DescribeSecret\"
],
\"Resource\": \"$SECRET_ARN\",
\"Condition\": {
\"StringEquals\": {
\"aws:SourceAccount\": \"$ACCOUNT_ID\"
},
\"ArnLike\": {
\"aws:SourceArn\": \"arn:aws:fsx:$REGION:$ACCOUNT_ID:file-system/*\"
}
}
}
]
}"
echo "Resource policy attached successfully"
```
**Note**
You can set more granular access control by modifying the `Resource` and `aws:SourceArn` fields to target specific secrets and file systems.
## Amazon FSx service account
Amazon FSx file systems that are joined to a self-managed Active Directory require a valid service account throughout their lifetime. Amazon FSx uses the service account to fully manage your file systems and perform administrative tasks that require unjoining and rejoining computer objects to your Active Directory domain. These tasks include replacing a failed file server and patching Microsoft Windows Server software. For Amazon FSx to perform these tasks, the Amazon FSx service account must have, at a minimum, the set of permissions that are described in [Service account permissions](#service-account-prereqs) delegated to it.
Although members of the **Domain Admins** group have sufficient privileges to perform these tasks, we strongly recommend that you use a separate service account to delegate the required privileges to Amazon FSx.
For more information about how to delegate privileges using either the **Delegate Control** or **Advanced Features** features in the **Active Directory User and Computers** MMC snap-in, see [Delegating permissions to the Amazon FSx service account or group](assign-permissions-to-service-account.md).
If you update your file system with a new service account, the new service account must have the required permissions and privileges to join your Active Directory and have **Full control** permissions for the existing computer objects associated with the file system. For more information, see [Changing the Amazon FSx service account](changing-ad-service-account.md).
We recommend storing your Active Directory service account credentials in AWS Secrets Manager for enhanced security. This eliminates the need to store sensitive credentials in plaintext and aligns with security best practices. For more information, see [Using a self-managed Microsoft Active Directory](#self-managed-AD).
# Delegating permissions to the Amazon FSx service account or group
Delegating privileges to Amazon FSx
The Amazon FSx service account or admin group must have the [privileges necessary](self-managed-AD.md#service-account-prereqs) for it to join FSx for Windows File Server file systems to your self-managed Active Directory domain. To delegate these permissions, you can use either **Delegate Control** or **Advanced Features** in the Active Directory User and Computers MMC snap-in, as described in the following procedures.
## To assign permissions using **Delegate Control**
**To assign permissions to a service account or group using **Delegate Control****
1. Log in to your system as a domain administrator for your Active Directory domain.
1. Open the **Active Directory User and Computers** MMC snap-in.
1. In the task pane, expand the domain node.
1. Locate and open the context (right-click) menu for the OU that you want to modify, and then choose **Delegate Control**.
1. On the **Delegation of Control Wizard** page, choose **Next**.
1. Choose **Add** to add the name of your Amazon FSx service account or group, and then choose **Next**.
1. On the **Tasks to Delegate** page, choose **Create a custom task to delegate**, and then choose **Next**.
1. Choose **Only the following objects in the folder**, and then choose **Computer objects**.
1. Choose **Create selected objects in this folder** and **Delete selected objects in this folder**. Then choose **Next**.
1. For **Permissions**, choose the following:
+ **Reset Password**
+ **Read and write Account Restrictions**
+ **Validated write to DNS host name**
+ **Validated write to service principal name**
1. Choose **Next**, and then choose **Finish**.
1. Close the **Active Directory User and Computers** MMC snap-in.
## To assign permissions using **Advanced Features**
1. Log in to your system as a domain administrator for your Active Directory domain.
1. Open the **Active Directory User and Computers** MMC snap-in.
1. Select **View** from the menu bar and ensure that **Advanced Features** is enabled (a check mark will appear next to it if the feature is enabled).
1. In the task pane, expand the domain node.
1. Locate and open (right-click) the context menu for the OU that you want to modify, and then choose **Properties**.
1. In the **OU Properties** pane, select the **Security** tab.
1. In the **Security** tab, select **Advanced**. Then select **Add**.
1. On the **Permission Entry** page, choose **Select a principal** and enter the name of your Amazon FSx service account or group. For **Applies to:**, choose **This Object and all Descendant Computer**. Ensure that the following are selected:
+ **Modify permissions**
+ **Create Computer Objects**
+ **Delete Computer Objects**
1. Select **Apply**, and then select **OK**.
1. Close the **Active Directory User and Computers** MMC snap-in.
# Validating your Active Directory configuration
Before you create an FSx for Windows File Server file system joined to your Active Directory, we recommend that you validate your Active Directory configuration using the Amazon FSx Active Directory Validation tool. Note that outbound internet connectivity is required to successfully validate the Active Directory configuration.
**To validate your Active Directory configuration**
1. Launch an Amazon EC2 Windows instance in the same subnet and with the same Amazon VPC security groups that you use for your FSx for Windows File Server file system. Ensure that your EC2 instance has the required `AmazonEC2ReadOnlyAccess` IAM permissions. You can validate EC2 instance role permissions using the IAM policy simulator. For more information, see [Testing IAM Policies with the IAM Policy Simulator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html) in the *IAM User Guide*.
1. Join your EC2 Windows instance to your Active Directory. For more information, see [Manually Join a Windows Instance](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_windows_instance.html) in the *AWS Directory Service Administration Guide*.
1. Connect to your EC2 instance. For more information, see [Connecting to Your Windows Instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/connecting_to_windows_instance.html) in the *Amazon EC2 User Guide*.
1. Open a Windows PowerShell window (using **Run as Administrator**) on the EC2 instance.
To test whether the required Active Directory module for Windows PowerShell is installed, use the following test command.
```
PS C:\> Import-Module ActiveDirectory
```
If above returns an error, install it using the following command.
```
PS C:\> Install-WindowsFeature RSAT-AD-PowerShell
```
1. Download the network validation tool using the following command.
```
PS C:\> Invoke-WebRequest "https://docs.aws.amazon.com/fsx/latest/WindowsGuide/samples/AmazonFSxADValidation.zip" -OutFile "AmazonFSxADValidation.zip"
```
1. Expand the zip file by using the following command.
```
PS C:\> Expand-Archive -Path "AmazonFSxADValidation.zip"
```
1. Add the `AmazonFSxADValidation` module to the current session.
```
PS C:\> Import-Module .\AmazonFSxADValidation
```
1. Set required parameters by substituting into the following command your:
+ Active Directory domain name (*DOMAINNAME.COM*)
+ Prepare the `$Credential` object for the service account password using one of the following options.
+ To generate the credential object interactively, use the following command.
```
$Credential = Get-Credential
```
+ To generate the credential object using an AWS Secrets Manager resource, use the following command.
```
$Secret = ConvertFrom-Json -InputObject (Get-SECSecretValue -SecretId $AdminSecret).SecretString
$Credential = (New-Object PSCredential($Secret.UserName,(ConvertTo-SecureString $Secret.Password -AsPlainText -Force)))
```
+ DNS server IP addresses (*IP\$1ADDRESS\$11*, *IP\$1ADDRESS\$12*)
+ Subnet ID(s) for subnets where you plan to create your Amazon FSx file system (*SUBNET\$11*, *SUBNET\$12*, for example, `subnet-04431191671ac0d19`).
```
PS C:\>
$FSxADValidationArgs = @{
# DNS root of ActiveDirectory domain
DomainDNSRoot = 'DOMAINNAME.COM'
# IP v4 addresses of DNS servers
DnsIpAddresses = @('IP_ADDRESS_1', 'IP_ADDRESS_2')
# Subnet IDs for Amazon FSx file server(s)
SubnetIds = @('SUBNET_1', 'SUBNET_2')
Credential = $Credential
}
```
1. (Optional) Set Organizational Unit, Delegated Administrators group, DomainControllersMaxCount, and enable service account permission validation by following instructions in the included `README.md` file prior to running the validation tool.
**Note**
The `Domain Admins` group has a different name if the operating system is not in English. For example, the group is named `Administrateurs du domaine` in the French OS version. If you don't specify a value, the default `Domain Admins` group name is used and the file system creation fails.
1. Run the validation tool by using this command.
```
PS C:\> $Result = Test-FSxADConfiguration @FSxADValidationArgs
```
1. The following is an example of a successful test result.
```
Test 1 - Validate EC2 Subnets ...
...
Test 17 - Validate 'Delete Computer Objects' permission ...
Test computer object amznfsxtestd53f deleted!
...
SUCCESS - All tests passed! Please proceed to creating an Amazon FSx file system. For your convenience, SelfManagedActiveDirectoryConfiguration of result can be used directly in CreateFileSystemWindowsConfiguration for New-FSXFileSystem
PS C:\AmazonFSxADValidation> $Result.Failures.Count
0
PS C:\AmazonFSxADValidation> $Result.Warnings.Count
0
```
The following is an example of a test result with errors.
```
Test 1 - Validate EC2 Subnets ...
...
Test 7 - Validate that provided EC2 Subnets belong to a single AD Site ...
Name DistinguishedName Site
---- ----------------- ----
10.0.0.0/19 CN=10.0.0.0/19,CN=Subnets,CN=Sites,CN=Configuration,DC=test-ad,DC=local CN=SiteB,CN=Sites,CN=Configu...
10.0.128.0/19 CN=10.0.128.0/19,CN=Subnets,CN=Sites,CN=Configuration,DC=test-ad,DC=local CN=Default-First-Site-Name,C...
10.0.64.0/19 CN=10.0.64.0/19,CN=Subnets,CN=Sites,CN=Configuration,DC=test-ad,DC=local CN=SiteB,CN=Sites,CN=Configu...
Best match for EC2 subnet subnet-092f4caca69e360e7 is AD site CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=te
st-ad,DC=local
Best match for EC2 subnet subnet-04431191671ac0d19 is AD site CN=SiteB,CN=Sites,CN=Configuration,DC=test-ad,DC=local
WARNING: EC2 subnets subnet-092f4caca69e360e7 subnet-04431191671ac0d19 matched to different AD sites! Make sure they
are in a single AD site.
...
9 of 16 tests skipped.
FAILURE - Tests failed. Please see error details below:
Name Value
---- -----
SubnetsInSeparateAdSites {subnet-04431191671ac0d19, subnet-092f4caca69e360e7}
Please address all errors and warnings above prior to re-running validation to confirm fix.
PS C:\AmazonFSxADValidation> $Result.Failures.Count
1
PS C:\AmazonFSxADValidation> $Result.Failures
Name Value
---- -----
SubnetsInSeparateAdSites {subnet-04431191671ac0d19, subnet-092f4caca69e360e7}
PS C:\AmazonFSxADValidation> $Result.Warnings.Count
0
```
If you receive warnings or errors when you run the validation tool, refer to the Troubleshooting guide included in the validation tool package (`TROUBLESHOOTING.md`) and [Troubleshooting Amazon FSx](troubleshooting.md).
# Joining an Amazon FSx file system to a self-managed Microsoft Active Directory domain
Join FSx to a self-managed Active Directory
When you create a new FSx for Windows File Server file system, you can configure Microsoft Active Directory integration so that it joins to your self-managed Microsoft Active Directory domain. To do this, provide the following information for your Microsoft Active Directory:
+ The fully qualified domain name (FQDN) of your on-premises Microsoft Active Directory directory.
**Note**
Amazon FSx currently does not support Single Label Domain (SLD) domains.
+ The IP addresses of the DNS servers for your domain.
+ Credentials for an Active Directory service account that Amazon FSx uses to join the file system to your domain. You can provide these as either:
+ **Option 1**: AWS Secrets Manager secret ARN - The secret containing the username and password for a service account on your Active Directory domain. For more information, see [Storing Active Directory credentials using AWS Secrets Manager](self-managed-AD.md#bp-store-ad-creds-using-secret-manager-windows).
+ **Option 2**: Plaintext credentials
+ **Service account username** – The user name of the service account in your existing Microsoft Active Directory. Don't include a domain prefix or suffix. For example, for `EXAMPLE\ADMIN`, use only `ADMIN`.
+ **Service account password** – The password for the service account.
Optionally, you can also specify the following:
+ A specific Organizational Unit (OU) within the domain that you want your Amazon FSx file system to join to.
+ The name of the domain group whose members are granted administrative privileges for the Amazon FSx file system. The domain group name you provide must be unique in your Active Directory.
After you specify this information, Amazon FSx joins your new file system to your self-managed Active Directory domain using the service account that you provided.
**Important**
Amazon FSx only registers DNS records for a file system if the Active Directory domain that you are joining it to is using Microsoft DNS as the default DNS. If you are using a third-party DNS, you will need to manually setup DNS entries for your Amazon FSx file systems after you create your file system. For more information on choosing the correct IP addresses to use for the file system, see [Getting the correct file system IP addresses to use for manual DNS entries](file-system-ip-addresses-for-dns.md).
## Before you begin
Make sure that you have completed the [Prerequisites](self-managed-AD.md#self-manage-prereqs) detailed in [Using a self-managed Microsoft Active Directory](self-managed-AD.md).
## To create an FSx for Windows File Server file system joined to a self-managed Active Directory (Console)
1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/).
1. On the dashboard, choose **Create file system** to start the file system creation wizard.
1. Choose **FSx for Windows File Server** and then choose **Next**. The **Create file system page appears.**
1. Provide a name for your file system. You can use a maximum of 256 Unicode letters, white space, and numbers, plus the special characters \$1 - = . \$1 : /
1. For **Storage capacity**, enter the storage capacity of your file system, in GiB. If you're using SSD storage, enter any whole number in the range of 32–65,536. If you're using HDD storage, enter any whole number in the range of 2,000–65,536. You can increase the amount of storage capacity as needed at any time after you create the file system. For more information, see [Managing storage capacity](managing-storage-configuration.md#managing-storage-capacity).
1. Keep **Throughput capacity** at its default setting. **Throughput capacity** is the sustained speed at which the file server that hosts your file system can serve data. The **Recommended throughput capacity** setting is based on the amount of storage capacity you choose. If you need more than the recommended throughput capacity, choose **Specify throughput capacity**, and then choose a value. For more information, see [FSx for Windows File Server performancePerformance](performance.md).
You can modify the throughput capacity as needed at any time after you create the file system. For more information, see [Managing throughput capacity](managing-throughput-capacity.md).
1. Choose the VPC that you want to associate with your file system. For the purposes of this getting started exercise, choose the same VPC as for your Directory Service directory and Amazon EC2 instance.
1. Choose any value for **Availability Zones** and **Subnet**.
1. For **VPC security groups**, the default security group for your default Amazon VPC is already added to your file system in the console. Please ensure that the security group and the VPC Network ACLs for the subnet(s) where you're creating your FSx file system allow traffic on the ports and in the directions shown in the following diagram.
![\[FSx for Windows File Server port configuration requirements for VPC security groups and network ACLs for the subnets where the file system is being created.\]](http://docs.aws.amazon.com/fsx/latest/WindowsGuide/images/Windows-port-requirements.png)
The following table identifies the role of each port.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/WindowsGuide/creating-joined-ad-file-systems.html)
**Important**
Allowing outbound traffic on TCP port 9389 is required for Single-AZ 2 and all Multi-AZ file system deployments.
**Note**
If you're using VPC network ACLs, you must also allow outbound traffic on dynamic ports (49152-65535) from your FSx file system.
+ Outbound rules to allow all traffic to the IP addresses associated with the DNS servers and domain controllers for your self-managed Microsoft Active Directory domain. For more information, see [Microsoft's documentation on configuring your firewall for Active Directory communication](https://support.microsoft.com/en-us/help/179442/how-to-configure-a-firewall-for-domains-and-trusts).
+ Ensure that these traffic rules are also mirrored on the firewalls that apply to each of the Active Directory domain controllers, DNS servers, FSx clients and FSx administrators.
**Note**
If you have Active Directory sites defined, you must ensure that the subnet(s) in the VPC associated with your Amazon FSx file system are defined in an Active Directory site, and that no conflicts exist between the subnet(s) in your VPC and the subnets in your other sites. You can view and change these settings using the Active Directory Sites and Services MMC snap-in.
**Important**
While Amazon VPC security groups require ports to be opened only in the direction that network traffic is initiated, most Windows firewalls and VPC network ACLs require ports to be open in both directions.
1. For **Windows authentication**, choose **Self-managed Microsoft Active Directory**.
1. Enter a value for **Fully qualified domain name** for the self-managed Microsoft Active Directory directory.
**Note**
Domain name must not be in the Single Label Domain (SLD) format. Amazon FSx currently does not support SLD domains.
**Important**
For Single-AZ 2 and all Multi-AZ file systems, the Active Directory domain name cannot exceed 47 characters.
1. Enter a value for **Organizational Unit** for the self-managed Microsoft Active Directory directory.
**Note**
Ensure that the service account you provided has permissions delegated to the OU that you specify here or to the default OU if you don’t specify one.
1. Enter at least one, and no more than two, values for **DNS Server IP Addresses** for the self-managed Microsoft Active Directory directory.
1. **Service account credentials** – Choose how to provide your service account credentials:
+ **Option 1**: AWS Secrets Manager secret ARN - The secret containing the username and password for a service account on your Active Directory domain. For more information, see [Storing Active Directory credentials using AWS Secrets Manager](self-managed-AD.md#bp-store-ad-creds-using-secret-manager-windows).
+ **Option 2**: Plaintext credentials
+ **Service account username** – The user name of the service account in your existing Microsoft Active Directory. Don't include a domain prefix or suffix. For example, for `EXAMPLE\ADMIN`, use only `ADMIN`.
+ **Service account password** – The password for the service account.
+ **Confirm password** – The password for the service account.
**Important**
DO NOT include a domain prefix (`corp.com\ServiceAcct`) or domain suffix (`ServiceAcct@corp.com`) when entering the **Service account username**.
DO NOT use the Distinguished Name (DN) when entering the **Service account username** (`CN=ServiceAcct,OU=example,DC=corp,DC=com`).
1. For **Delegated file system administrators group**, specify the `Domain Admins` group or a custom delegated file system administrators group (if you've created one). The group you specify should have the delegated authority to perform administrative tasks on your file system. If you don't provide a value, Amazon FSx uses the Builtin `Domain Admins` group. Note that Amazon FSx does not support having a `Delegated file system administrators group` (either the `Domain Admins` group or a custom group you specify) that is located in the Builtin container.
**Important**
If you do not provide a **Delegated file system administrators group**, by default Amazon FSx attempts to use the Builtin `Domain Admins` group in your Active Directory domain. If the name of this Builtin group has been changed or if you’re using a different group for domain administration, you must provide that name for the group here.
**Important**
DO NOT include a domain prefix (corp.com\$1FSxAdmins) or domain suffix (FSxAdmins@corp.com) when providing the group name parameter.
DO NOT use the Distinguished Name (DN) for the group. An example of a distinguished name is CN=FSxAdmins,OU=example,DC=corp,DC=com.
## To create an FSx for Windows File Server file system joined to a self-managed Active Directory (AWS CLI)
The following example creates an FSx for Windows File Server file system with a `SelfManagedActiveDirectoryConfiguration` in the `us-east-2` Availability Zone.
```
aws fsx --region us-east-2 \
create-file-system \
--file-system-type WINDOWS \
--storage-capacity 300 \
--security-group-ids security-group-id \
--subnet-ids subnet-id\
--windows-configuration SelfManagedActiveDirectoryConfiguration='{DomainName="corp.example.com", \
OrganizationalUnitDistinguishedName="OU=FileSystems,DC=corp,DC=example,DC=com",FileSystemAdministratorsGroup="FSxAdmins", \
UserName="FSxService",Password="password", \
DnsIps=["10.0.1.18"]}',ThroughputCapacity=8
```
**Important**
Do not move computer objects that Amazon FSx creates in the OU after your file system is created. Doing so will cause your file system to become misconfigured.
# Getting the correct file system IP addresses to use for manual DNS entries
Getting IP addresses for manual DNS entries
Amazon FSx only registers DNS records for a file system if you are using Microsoft DNS as the default DNS service. If you are using a third-party DNS, you will need to manually setup DNS entries for your Amazon FSx file systems. This section describes how to obtain the correct file system IP addresses to use if you have to manually add the file system to your DNS. Note that once a file system is created, its IP addresses don't change until the file system is deleted.
**How to obtain file system IP addresses to use for DNS A entries**
1. In the [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/), choose the file system that you want to obtain the IP address of to display the file system details page.
1. In the **Network & security** tab do one of the following:
+ For Single-AZ 1 file systems:
+ In the **Subnet** panel, choose the elastic network interface shown under **Network interface** to open the **Network Interfaces** page in the Amazon EC2 console.
+ The IP address for the Single-AZ 1 file system to use is shown in the **Primary private IPv4 IP** column.
+ For Single-AZ 2 or Multi-AZ file systems:
+ In the **Preferred subnet** panel, choose the elastic network interface shown under **Network interface** to open the **Network Interfaces** page in the Amazon EC2 console.
+ The IP address for the preferred subnet to use is shown in the **Secondary private IPv4 IP** column.
+ In the Amazon FSx **Standby subnet** panel, choose the elastic network interface shown under **Network interface** to open the **Network Interfaces** page in the Amazon EC2 console.
+ The IP address for the standby subnet to use is shown in the **Secondary private IPv4 IP** column.
**Note**
If you need to setup DNS entries for your Windows Remote PowerShell Endpoint for Single-AZ 2 or Multi-AZ file systems, you should use the **Primary private IPv4 address** for the elastic network interface for your **Preferred subnet**. For more information, see [Using the Amazon FSx CLI for PowerShell](administering-file-systems.md#remote-pwrshell).
# Updating a self-managed Active Directory configuration
Update self-managed Active Directory
To help ensure continuous, uninterrupted availability of your Amazon FSx file system, you must update the file system's Active Directory configuration when any of the following Active Directory properties change:
+ The DNS server IP addresses
+ The service account credentials of the self-managed Active Directory
When you update the self-managed Active Directory configuration for your Amazon FSx file system, your file system's state switches from **Available** to **Updating** while the update is applied. Verify that the state switches back to **Available** after the update has been applied – note that the update can take up to several minutes to complete. For more information, see [Monitoring self-managed Active Directory updates](monitor-self-ad-update.md).
If there's an issue with the updated self-managed Active Directory configuration, the file system state switches to **Misconfigured**. This state shows an error message and recommended corrective action beside the file system description in the console, API, and CLI. After taking the recommended corrective action, verify that your file system's state eventually changes to **Available**.
**Important**
If you update your file system with a new service account, ensure that the new service account has **Full control** permissions for the existing computer objects associated with the file system.
For information about troubleshooting possible issues related to self-managed Active Directory configurations, see [File system is in a misconfigured state](misconfigured-ad-config.md).
You can use the AWS Management Console, Amazon FSx API, or AWS CLI to update the service account credentials and the DNS server IP addresses of a file system's self-managed Active Directory configuration. You can track the progress of a self-managed Active Directory configuration update at any time using the AWS Management Console, CLI, and API. For more information, see [Monitoring self-managed Active Directory updates](monitor-self-ad-update.md).
**To update the self-managed Active Directory configuration (Console)**
1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/).
1. Navigate to **File systems**, and choose the Windows file system for which you want to update self-managed Active Directory configuration.
1. In the **Network & security** tab, then choose **Update** for the **DNS server IP addresses**, or for the service account username, depending on which Active Directory properties you are updating.
1. Enter the new DNS server IP addresses, or the new service account credentials (username and password) or secret ARN in the dialog that appears. You can use AWS Secrets Manager to store your credentials. For more information, see [Storing Active Directory credentials using AWS Secrets Manager](self-managed-AD.md#bp-store-ad-creds-using-secret-manager-windows).
1. Choose **Update** to initiate the Active Directory configuration update.
You can [monitor the update progress](monitor-self-ad-update.md) using the AWS Management Console or the AWS CLI.
**To update the self-managed Active Directory configuration (CLI)**
+ To update the self-managed Active Directory configuration of an FSx for Windows File Server file system, use the AWS CLI command [update-file-system](https://docs.aws.amazon.com/cli/latest/reference/fsx/update-file-system.html). Set the following parameters:
+ `--file-system-id` to the ID of the file system you are updating.
+ `UserName` the new username for the self-managed Active Directory service account.
+ `Password` the new password for the self-managed Active Directory service account.
+ `DomainJoinServiceAccountSecret` the AWS Secrets Manager secret containing the username and password for a service account on your Active Directory domain
**Note**
You can't provide both username/password and a domain join service account secret to connect to your Active Directory. Provide only one set of credentials.
+ `DnsIps` the IP addresses for the self-managed Active Directory DNS servers.
```
aws fsx update-file-system --file-system-id fs-0123456789abcdef0 \
--windows-configuration 'SelfManagedActiveDirectoryConfiguration={UserName=username,Password=password,\
DnsIps=[192.0.2.0,192.0.2.24]}'
```
If the update action is successful, the service sends back an HTTP 200 response. The `AdminstrativeActions` object in the response describes the request and its status.
# Changing the Amazon FSx service account
If you update your file system with a new service account, the new service account must have the required permissions and privileges to join your Active Directory and has **Full control** permissions for the existing computer objects associated with the file system. In addition, make sure that new service account is part of the trusted accounts with the enabled **Group Policy** setting **Domain controller: Allow computer account re-use during domain join**.
We strongly recommend using an Active Directory group to manage Active Directory permissions and configurations associated with service accounts.
When changing the service account for Amazon FSx, ensure that the service accounts have the following settings:
+ The new service account (or the Active Directory group it is a member of) has **Full control** permissions for the existing computer objects associated with the file system.
+ The new and previous service accounts (or the Active Directory group they are a member of) are part of the trusted accounts (or trusted Active Directory group) with the **Domain controller: Allow computer account re-use during domain join** Group Policy setting enabled on all domain controllers in the Active Directory.
If the service accounts do not meet these requirements, the following conditions could occur:
+ For Single-AZ file systems, the file system could become **[MISCONFIGURED\$1UNAVAILABLE](administering-file-systems.md#file-system-lifecycle-states)**.
+ For Multi-AZ file systems, the file system could become **[MISCONFIGURED](administering-file-systems.md#file-system-lifecycle-states)** and the RemotePowerShell endpoint name might change.
## Configuring a domain controller's Group Policy
The following [ Microsoft recommended procedure](https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8#bkmk_take_action) describes how to use the domain controller Group Policy to configure the allow list policy.
**To configure a domain controller's allow list policy**
1. Install the September 12, 2023 or later Microsoft Windows updates on all member computers and domain controllers in your self-managed Microsoft Active Directory.
1. In a new or existing group policy that applies to all domain controllers in your self-managed Active Directory, configure the following settings.
1. Navigate to **Computer Configuration>Policies>Windows Settings>Security Settings> Local Policies>Security Options**.
1. Double-click **Domain controller: Allow computer account re-use during domain join**.
1. Select **Define this policy setting and **.
1. Use the object picker to add users or groups of trusted computer account creators and owners to the **Allow** permission. (As a best practice, we highly recommend that you use groups for permissions.) **Do not add the user account that performs the domain join.**
**Warning**
Limit membership to the policy to trusted users and service accounts. Do not add authenticated users, everyone or other large groups to this policy. Instead, add specific trusted users and service accounts to groups and add those groups to the policy.
1. Wait for the Group Policy refresh interval or run **gpupdate /force** on all domain controllers.
1. Verify that the HKLM\$1System\$1CCS\$1Control\$1SAM – “ComputerAccountReuseAllowList” registry key is populated with the desired SDDL. **Do not manually edit the registry**.
1. Attempt to join a computer that has the September 12, 2023, or later updates installed. Ensure that one of the accounts listed in the policy owns the computer account. Also ensure that its registry does not have the **NetJoinLegacyAccountReuse** key enabled (set to 1). If the domain join fails, check the **`c:\windows\debug\netsetup.log`**.
# Monitoring self-managed Active Directory updates
You can monitor the progress of a self-managed Active Directory configuration update using the AWS Management Console, the API, or the AWS CLI, as described in the following procedures.
When you update your file system's self-managed Active Directory configuration, the file system's state switches from **Available** to **Updating** while the update is applied. Once the update is complete, the state switches back to **Available**. An Active Directory configuration update can take up to several minutes to complete.
## Monitoring updates in the console
In the **Updates** tab in the **File system details** window, you can view the 10 most recent updates for each update type.
![\[Console screen shot showing recent updates list.\]](http://docs.aws.amazon.com/fsx/latest/WindowsGuide/images/fs-updates-panel.png)
For self-managed Active Directory updates, you can view the following information.
****Update type****
Supported types are as follows:
+ DNS server IP address
+ Service account credentials
****Target value****
The desired value to update the file system property to. For **Service account credentials** updates, only the user name is shown, service account passwords are never included in this field.
****Status****
The current status of the update. For self-managed Active Directory updates, the possible values are as follows:
+ **Pending** – Amazon FSx has received the update request, but has not started processing it.
+ **In progress** – Amazon FSx is processing the update request.
+ **Completed** – The file system update completed successfully.
+ **Failed** – The file system update failed. Choose the question mark (**?**) to see details about the failure.
****Progress %****
Displays the progress of the file system update as percent complete.
****Request time****
The time that Amazon FSx received the update action request.
## Monitoring updates using the AWS CLI and API
You can view and monitor file system update requests that are in progress using the [describe-file-systems](https://docs.aws.amazon.com/cli/latest/reference/fsx/describe-file-systems.html) AWS CLI command and the [DescribeFileSystems](https://docs.aws.amazon.com/fsx/latest/APIReference/API_DescribeFileSystems.html) API action. The `AdministrativeActions` array lists the 10 most recent update actions for each administrative action type.
The following example shows an excerpt of the response of a **describe-file-systems** CLI command. The output shows two self-managed Active Directory file system updates.
```
{
"OwnerId": "111122223333",
.
.
.
"StorageCapacity": 1000,
"AdministrativeActions": [
{
"AdministrativeActionType": "FILE_SYSTEM_UPDATE",
"RequestTime": 1581694766.757,
"Status": "PENDING",
"TargetFileSystemValues": {
"WindowsConfiguration": {
"SelfManagedActiveDirectoryConfiguration": {
"UserName": "serviceUser",
}
}
}
},
{
"AdministrativeActionType": "FILE_SYSTEM_UPDATE",
"RequestTime": 1619032957.759,
"Status": "FAILED",
"TargetFileSystemValues": {
"WindowsConfiguration": {
"SelfManagedActiveDirectoryConfiguration": {
"DnsIps": [
"10.0.138.161"
]
}
}
},
"FailureDetails": {
"Message": "Failure details message."
}
}
],
.
.
.
```