# Working with Microsoft Active Directory in FSx for ONTAP Amazon FSx works with Microsoft Active Directory to integrate with your existing environments. Active Directory is the Microsoft directory service that's used to store information about objects on the network, and to help administrators and users to find and use this information. These objects typically include shared resources, such as file servers and network user and computer accounts. You can optionally join your FSx for ONTAP storage virtual machines (SVMs) to your Active Directory domain to provide user authentication and file- and folder-level access control. Server message block (SMB) clients can then use their existing user identities in Active Directory to authenticate themselves and access SVM volumes. Your users can use their existing identities to control access to individual files and folders. In addition, you can migrate your existing files and folders and their security access control list (ACL) configurations to Amazon FSx without any modifications. If the Microsoft Active Directory domain infrastructure is not available, you can configure a Server Message Block (SMB) server in a workgroup on an SVM as an alternative to joining an SVM to a Microsoft Active Directory. For more information, see [Setting up an SMB server in a workgroup](smb-server-workgroup-setup.md). When you join Amazon FSx for NetApp ONTAP to an Active Directory, you join the file system's SVMs to the Active Directory independently. This means that you can have a file system with some SVMs that are joined to an Active Directory, and other SVMs that are not. After an SVM is joined to an Active Directory, you can update the following Active Directory configuration properties: + DNS server IP addresses + Self-managed Active Directory service account username and password **Topics** + [Prerequisites for joining an SVM to a self-managed Microsoft AD](self-manage-prereqs.md) + [Best practices for working with Active Directory](self-managed-AD-best-practices.md) + [How joining SVMs to Microsoft Active Directory works](self-managed-AD-join.md) + [Managing SVM Active Directory configurations](manage-svm-ad-config.md) # Prerequisites for joining an SVM to a self-managed Microsoft AD Before you join an FSx for ONTAP SVM to a self-managed Microsoft AD domain, make sure that your Active Directory and network meet the requirements described in the following sections. **Topics** + [On-premises Active Directory requirements](#ontap-ad-on-prem-prereqs) + [Network configuration requirements](#ontap-ad-network-configs) + [Active Directory service account requirements](#ontap-ad-service-account-prereqs) ## On-premises Active Directory requirements Make sure that you already have an on-premises or other self-managed Microsoft AD that you can join the SVM to. This Active Directory should have the following configuration: + The Active Directory domain controller domain functional level is at Windows Server 2000 or higher. + The Active Directory uses a domain name that's not in the Single Label Domain (SLD) format. Amazon FSx doesn't support SLD domains. + If you have Active Directory sites defined, make sure that the subnets in the VPC that's associated with your FSx for ONTAP file system are defined in the same Active Directory sites, and that no conflicts exist between your VPC subnets and the subnets on your Active Directory sites. **Note** If you are using Directory Service, FSx for ONTAP doesn't support joining SVMs to the Simple Active Directory. ## Network configuration requirements Make sure that you have the following network configurations in place and associated information available to you. **Important** For an SVM to join Active Directory, you need to ensure that the ports documented in this topic allow traffic between all Active Directory Domain Controllers and both iSCSI IP addresses (iscsi\$11 and iscsi\$12 logical interfaces (LIFs)) on the SVM. + The DNS server and Active Directory domain controller IP addresses. + Connectivity between the Amazon VPC where you're creating the file system and your self-managed Active Directory using [Direct Connect](https://aws.amazon.com/directconnect/), [Site-to-Site VPN](https://aws.amazon.com/vpn/), or [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/). + The security group and the VPC Network ACLs for the subnets on which you're creating the file system must allow traffic on the ports and in the directions shown in the following diagram. ![\[Diagram showing FSx for ONTAP port configuration requirements for VPC security groups and network ACLs for the subnets that you're creating an FSx for ONTAP file system in.\]](http://docs.aws.amazon.com/fsx/latest/ONTAPGuide/images/ontap-port-requirements.png) The role of each port is described in the following table. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/ONTAPGuide/self-manage-prereqs.html) + These traffic rules should also be mirrored on the firewalls that apply to each of the Active Directory domain controllers, DNS servers, FSx clients, and FSx administrators. **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. ## Active Directory service account requirements Make sure that you have a service account in your self-managed Microsoft AD that has delegated permissions to join computers to the domain. A *service account* is a user account in your self-managed Active Directory that has been delegated certain tasks. At a minimum, the service account must be delegated the following permissions in the OU to which you're joining the SVM: + Ability to reset passwords + Ability to restrict accounts from reading and writing data + Ability to set the `msDS-SupportedEncryptionTypes` property on computer objects + Validated ability to write to the DNS hostname + Validated ability to write to the service principal name + Ability to create and delete computer objects + Validated ability to read and write Account Restrictions These represent the minimum set of permissions that are required to join computer objects to your Active Directory. For more information, see the 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). You can store your Active Directory service account credentials in AWS Secrets Manager (recommended) and provide Amazon FSx with a secret ARN to join your Active Directory, or you can provide plaintext credentials. To learn more about creating a service account with the correct permissions, see [Delegating permissions to your Amazon FSx service account](self-managed-AD-best-practices.md#connect_delegate_privileges). **Important** Amazon FSx requires a valid service account throughout the lifetime of your Amazon FSx file system. Amazon FSx must be able to fully manage the file system and perform tasks that require it to unjoin and rejoin resources to your Active Directory domain. These tasks include replacing a failed file system or SVM, or patching NetApp ONTAP software. Keep your Active Directory configuration information up to date with Amazon FSx, including the service account credentials. To learn more, see [Keeping your Active Directory configuration updated with Amazon FSx](self-managed-AD-best-practices.md#keep-ad-config-updated). If this is your first time using AWS and FSx for ONTAP, make sure that you complete the initial setup steps before starting your Active Directory integration. For more information, see [Setting up FSx for ONTAP](getting-started.md#setting-up). **Important** Don't move computer objects that Amazon FSx creates in the OU after your SVMs are created, or delete your Active Directory while your SVM is joined to it. Doing so will cause your SVMs to become misconfigured. # Best practices for working with Active Directory Here are some suggestions and guidelines that you should consider when joining Amazon FSx for NetApp ONTAP SVMs to your self-managed Microsoft Active Directory. Note that these are recommended as best practices, but not required. **Topics** + [Delegating permissions to your Amazon FSx service account](#connect_delegate_privileges) + [Keeping your Active Directory configuration updated with Amazon FSx](#keep-ad-config-updated) + [Using security groups to limit traffic within your VPC](#least-privilege-sg-rules) + [Creating outbound security group rules for your file system's network interface](#sg-rules-fsx-eni) + [Storing Active Directory credentials using AWS Secrets Manager](#bp-store-ad-creds-using-secret-manager) ## Delegating permissions to your Amazon FSx service account Make sure to configure the service account that you provide to Amazon FSx with the minimum permissions required. In addition, separate the Organizational Unit (OU) from other domain controller concerns. To join Amazon FSx SVMs to your domain, make sure that the service account has delegated permissions. Members of the **Domain Admins** group have sufficient permissions to perform this task. However, as a best practice, use a service account that only has the minimum permissions necessary to do this. The following procedure demonstrates how to delegate only the permissions necessary to join FSx for ONTAP SVMs to your domain. Perform this procedure on a machine that's joined to your directory and has the Active Directory User and Computers MMC snap-in installed. **To create a service account for your Microsoft Active Directory domain**Create a service account for the AD 1. Make sure that you're logged in as a domain administrator for your Microsoft 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 a specific user or a specific group for **Selected users and groups**, 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. Under **Show these permissions**, ensure that **General** and **Property-specific** are selected. 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** + **Write msDS-SupportedEncryptionTypes** 1. Choose **Next**, and then choose **Finish**. 1. Close the **Active Directory User and Computers** MMC snap-in. **Important** Don't move computer objects that Amazon FSx creates in the OU after your SVMs are created. Doing so will cause your SVMs to become misconfigured. ## Keeping your Active Directory configuration updated with Amazon FSx For uninterrupted availability of your Amazon FSx SVMs, update an SVM's self-managed Active Directory (AD) configuration when you change your self-managed AD setup. For example, suppose that your AD uses a time-based password reset policy. In this case, as soon as the password is reset, make sure to update the service account password with Amazon FSx. To do this, use the Amazon FSx console, Amazon FSx API, or AWS CLI. Similarly, if the DNS server IP addresses change for your Active Directory domain, as soon as the change occurs update the DNS server IP addresses with Amazon FSx. If there's an issue with the updated self-managed AD configuration, the SVM state switches to **Misconfigured**. This state shows an error message and a recommended action beside the SVM description in the console, API, and CLI. If an issue with your SVM's AD configuration occurs, be sure to take the recommended corrective action for the configuration properties. If the issue is resolved, verify that your SVM's state changes to **Created**. For more information, see [Updating existing SVM Active Directory configurations using the AWS Management Console, AWS CLI, and API](update-svm-ad-config.md) and [Modify an Active Directory configuration using the ONTAP CLI](manage-svm-ad-config-ontap-cli.md#using-ontap-cli-to-modify-ad). ## Using security groups to limit traffic within your VPC To limit network traffic in your virtual private cloud (VPC), you can implement the principle of least privilege in your VPC. In other words, you can limit permissions to the minimum ones necessary. To do this, use security group rules. To learn more, see [Amazon VPC security groups](limit-access-security-groups.md#fsx-vpc-security-groups). ## Creating outbound security group rules for your file system's network interface For greater security, consider configuring a security group with outbound traffic rules. These rules should allow outbound traffic only to your self-managed AD domains controllers or within the subnet or security group. Apply this security group to the VPC associated with your Amazon FSx file system's elastic network interface. To learn more, see [File System Access Control with Amazon VPC](limit-access-security-groups.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 SVM 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/*", "arn:aws:fsx:us-west-2:123456789012:storage-virtual-machine/fs-*/svm-*" ] } } } ``` 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/*", "arn:aws:fsx:us-west-2:123456789012:storage-virtual-machine/fs-*/svm-*" ] } } } ] } ``` 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 SVM 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/*\", \"arn:aws:fsx:$REGION:$ACCOUNT_ID:storage-virtual-machine/fs-*/svm-*\"] } } } ] }" --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-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 SVM 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-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 SVM 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/*\", \"arn:aws:fsx:$REGION:$ACCOUNT_ID:storage-virtual-machine/fs-*/svm-*\"] } } } ] }" 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. # How joining SVMs to Microsoft Active Directory works Your organization might manage identities and devices using an Active Directory, whether on-premises or in the cloud. With FSx for ONTAP, you can join your SVMs directly to your existing Active Directory domain in the following ways: + Joining new SVMs to an Active Directory at creation: + Using the **Standard create** option in Amazon FSx console to create a new FSx for ONTAP file system, you can join the default SVM to a self-managed Active Directory. For more information, see [To create a file system (console)](creating-file-systems.md#create-MAZ-file-system-console). + Using the Amazon FSx console, AWS CLI, or Amazon FSx API to create a new SVM on an existing FSx for ONTAP file system. For more information, see [Creating storage virtual machines (SVM)](creating-svms.md). + Joining existing SVMs to an Active Directory: + Using the AWS Management Console, AWS CLI, and API to join an SVM to an Active Directory, and to reattempt joining an SVM to an Active Directory if the initial attempt to join failed. You can also update some Active Directory configuration properties for SVMs that are already joined to an Active Directory. For more information, see [Managing SVM Active Directory configurations](manage-svm-ad-config.md). + Using the NetApp ONTAP CLI or REST API to join, reattempt joining, and unjoining SVM Active Directory configurations. For more information, see [Updating SVM Active Directory configurations using the NetApp CLI](manage-svm-ad-config-ontap-cli.md). **Important** Amazon FSx only registers DNS records for an SVM if you use Microsoft DNS as the default DNS service. If you use a third-party DNS, you must set up DNS entries manually for your Amazon FSx SVMs after you create them. If you use AWS Managed Microsoft AD, you must specify a group such as AWS Delegated FSx Administrators, AWS Delegated Administrators, or a custom group with delegated permissions to the OU. When you join an FSx for ONTAP SVM directly to a self-managed Active Directory, the SVM resides in the same Active Directory forest (the top-most 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. ## Information needed when joining an SVM to an Active Directory You have to provide the following information about your Active Directory when joining an SVM to an Active Directory, regardless of the API operation you choose: + The NetBIOS name of the Active Directory computer object to create for your SVM. This is the name of the SVM in Active Directory, which must be unique within your Active Directory. Don't use the NetBIOS name of the home domain. The NetBIOS name can't exceed 15 characters. + The fully qualified domain name (FQDN) of your Active Directory. The FQDN can't exceed 255 characters. **Note** The FQDN can't be in the Single Label Domain (SLD) format. Amazon FSx doesn't support SLD domains. + Up to three IP addresses of the DNS servers or domain hosts for your domain. The DNS server IP addresses and Active Directory domain controller IP addresses can be in any IP address range, except: + IP addresses that conflict with Amazon Web Services-owned IP addresses in that AWS Region. For a list of AWS IP addresses by Region, see the [AWS IP address ranges](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html). + IP addresses in the following CIDR block range: 198.19.0.0/16 + Credentials for an Active Directory service account that Amazon FSx uses to join the SVM 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-best-practices.md#bp-store-ad-creds-using-secret-manager). + **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. + (Optional) The Organizational Unit (OU) in the domain that you join the SVM to. **Note** If you join your SVM to an AWS Directory Service Active Directory, you must provide an OU that's within the default OU that Directory Service creates for the directory objects that are related to AWS. This is because the Directory Service doesn't provide access to your Active Directory's default `Computers` OU. For example, if your Active Directory domain is `example.com`, you can specify the following OU: `OU=Computers,OU=example,DC=example,DC=com`. + (Optional) The domain group that you are delegating authority to for performing administrative actions on your file system. For example, this domain group might manage Windows SMB file shares, 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. # Managing SVM Active Directory configurations This section describes how to use the AWS Management Console, AWS CLI, FSx API, and the ONTAP CLI to do the following: + Joining an existing SVM to an Active Directory + Modifying an existing SVM Active Directory configuration + Removing SVMs from an Active Directory To remove an SVM from an Active Directory, you must use the NetApp ONTAP CLI. **Topics** + [Joining SVMs to Active Directory using the AWS Management Console, AWS CLI and API](join-svm-to-ad.md) + [Updating existing SVM Active Directory configurations using the AWS Management Console, AWS CLI, and API](update-svm-ad-config.md) + [Updating SVM Active Directory configurations using the NetApp CLI](manage-svm-ad-config-ontap-cli.md) # Joining SVMs to Active Directory using the AWS Management Console, AWS CLI and API Use the following procedure to join an existing SVM to an Active Directory. In this procedure, the SVM is *not* already joined to an Active Directory. **To join an SVM to an Active Directory (AWS Management Console)** 1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/). 1. Choose the SVM that you want to join to an Active Directory: + In the left navigation pane, choose **File systems**, and then choose the ONTAP file system with the SVM that you want to update. + Choose the **Storage virtual machines** tab. –Or– + To display a list of all of the available SVMs, in the left navigation pane, expand **ONTAP** and choose **Storage virtual machines**. A list of all SVMs in your account in the AWS Region is displayed. Select the SVM that you want to join to an Active Directory from the list. 1. On the upper right of the SVM **Summary** panel, choose **Actions** > **Join/Update Active Directory**. The **Join SVM to an Active Directory** window appears. 1. Enter the following information for the Active Directory that you are joining the SVM to: + The **NetBIOS name** of the Active Directory computer object to create for your SVM. This is the name of the SVM in Active Directory, which must be unique within your Active Directory. Don't use the NetBIOS name of the home domain. The NetBIOS name can't exceed 15 characters. + The **fully qualified domain name (FQDN)** of your Active Directory. The domain name can't exceed 255 characters. + **DNS server IP addresses** – The IPv4 or IPv6 addresses of the DNS servers for your domain. + **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-best-practices.md#bp-store-ad-creds-using-secret-manager). + **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. + **Managed in Secrets Manager** (default) – Provide the ARN of an Secrets Manager secret that contains your service account credentials. The secret must contain the key-value pairs `CUSTOMER_MANAGED_ACTIVE_DIRECTORY_USERNAME` and `CUSTOMER_MANAGED_ACTIVE_DIRECTORY_PASSWORD`. + (Optional) **Organizational Unit (OU)** – The distinguished path name of the organizational unit you want to join your SVM to. + **Delegated file system administrators group** – The name of the group in your Active Directory that can administer your file system. If you are using AWS Managed Microsoft AD, you must specify a group such as AWS Delegated FSx Administrators, AWS Delegated Administrators, or a custom group with delegated permissions to the OU. If you are joining to a self-managed Active Directory, use the name of the group in your Active Directory. The default group is `Domain Admins`. 1. Choose **Join Active Directory** to join the SVM to the Active Directory using the configuration you provided. **To join an SVM to an Active Directory (AWS CLI)** + To join an FSx for ONTAP SVM to an Active Directory, use the [update-storage-virtual-machine](https://docs.aws.amazon.com/cli/latest/reference/fsx/update-storage-virtual-machine.html) CLI command (or the equivalent [UpdateStorageVirtualMachine](https://docs.aws.amazon.com/fsx/latest/APIReference/API_UpdateStorageVirtualMachine.html) API operation), as shown in the following example. ``` aws fsx update-storage-virtual-machine \ --storage-virtual-machine-id svm-abcdef0123456789a\ --active-directory-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"]}',NetBiosName=amznfsx12345 ``` After successfully creating the storage virtual machine, Amazon FSx returns its description in JSON format, as shown in the following example. ``` { "StorageVirtualMachine": { "ActiveDirectoryConfiguration": { "NetBiosName": "amznfsx12345", "SelfManagedActiveDirectoryConfiguration": { "UserName": "Admin", "DnsIps": [ "10.0.1.3", "10.0.91.97" ], "OrganizationalUnitDistinguishedName": "OU=Computers,OU=customer-ad,DC=customer-ad,DC=example,DC=com", "DomainName": "customer-ad.example.com" } } "CreationTime": 1625066825.306, "Endpoints": { "Management": { "DnsName": "svm-abcdef0123456789a.fs-0123456789abcdef0.fsx.us-east-1.amazonaws.com", "IpAddressses": ["198.19.0.4"] }, "Nfs": { "DnsName": "svm-abcdef0123456789a.fs-0123456789abcdef0.fsx.us-east-1.amazonaws.com", "IpAddressses": ["198.19.0.4"] }, "Smb": { "DnsName": "amznfsx12345", "IpAddressses": ["198.19.0.4"] }, "SmbWindowsInterVpc": { "IpAddressses": ["198.19.0.5", "198.19.0.6"] }, "Iscsi": { "DnsName": "iscsi.svm-abcdef0123456789a.fs-0123456789abcdef0.fsx.us-east-1.amazonaws.com", "IpAddressses": ["198.19.0.7", "198.19.0.8"] } }, "FileSystemId": "fs-0123456789abcdef0", "Lifecycle": "CREATED", "Name": "vol1", "ResourceARN": "arn:aws:fsx:us-east-1:123456789012:storage-virtual-machine/fs-0123456789abcdef0/svm-abcdef0123456789a", "StorageVirtualMachineId": "svm-abcdef0123456789a", "Subtype": "default", "Tags": [], } } ``` # Updating existing SVM Active Directory configurations using the AWS Management Console, AWS CLI, and API Use the following procedure to update the Active Directory configuration of an SVM that is already joined to an Active Directory. **To update an SVM Active Directory configuration (AWS Management Console)** 1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/). 1. Choose the SVM to update as follows: + In the left navigation pane, choose **File systems**, and then choose the ONTAP file system with the SVM you want to update. + Choose the **Storage virtual machines** tab. –Or– + To display a list of all of the SVMs available, in the left navigation pane, expand **ONTAP** and choose **Storage virtual machines**. Select the SVM that you want to update from the list. 1. On the SVM **Summary** panel, choose **Actions** > **Join/Update Active Directory**. The **Update SVM Active Directory configuration** window appears. 1. You can update the following Active Directory configuration properties in this window. + **DNS server IP addresses** – The IPv4 or IPv6 addresses of the DNS servers for your domain. + **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-best-practices.md#bp-store-ad-creds-using-secret-manager). + **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. 1. After you have entered your updates, choose **Update Active Directory** to make the changes. Use the following procedure to update the Active Directory configuration of an SVM that is already joined to an Active Directory. **To update an SVM Active Directory configuration (AWS CLI)** + To update an SVM's Active Directory configuration with the AWS CLI or API, use the [update-storage-virtual-machine](https://docs.aws.amazon.com/cli/latest/reference/fsx/update-storage-virtual-machine.html) CLI command (or the equivalent [UpdateStorageVirtualMachine](https://docs.aws.amazon.com/fsx/latest/APIReference/API_UpdateStorageVirtualMachine.html) API operation), as shown in the following example. ``` aws fsx update-storage-virtual-machine \ --storage-virtual-machine-id svm-abcdef0123456789a\ --active-directory-configuration \ SelfManagedActiveDirectoryConfiguration='{UserName="FSxService",\ Password="password", \ DnsIps=["10.0.1.18"]}' ``` # Updating SVM Active Directory configurations using the NetApp CLI You can use the NetApp ONTAP CLI to join and unjoin your SVM to an Active Directory, and to modify an existing SVM Active Directory configuration. ## Joining an SVM to an Active Directory using the ONTAP CLI You can join existing SVMs to an Active Directory using the ONTAP CLI, as described in the following procedure. You can do this even if your SVM is already joined to an Active Directory. 1. To access the ONTAP CLI, establish an SSH session on the management port of the Amazon FSx for NetApp ONTAP file system or SVM by running the following command. Replace `management_endpoint_ip` with the IP address of the file system's management port. ``` [~]$ ssh fsxadmin@management_endpoint_ip ``` For more information, see [Managing file systems with the ONTAP CLI](managing-resources-ontap-apps.md#fsxadmin-ontap-cli). 1. Create a DNS entry for your Active Directory by providing the full directory DNS name (`corp.example.com`) and at least one DNS server IP address. ``` ::>vserver services name-service dns create -vserver svm_name -domains corp.example.com -name-servers dns_ip_1, dns_ip_2 ``` To verify the connection to your DNS servers, run the following command. Replace *svm\$1name* with your own information. ``` FsxId0ae30e5b7f1a50b6a::>vserver services name-service dns check -vserver svm_name Name Server Vserver Name Server Status Status Details ------------- --------------- ------------ -------------------------- svm_name 172.31.14.245 up Response time (msec): 0 svm_name 172.31.25.207 up Response time (msec): 1 2 entries were displayed. ``` 1. To join your SVM to your Active Directory, run the following command. Note that you will must specify a `computer_name` that doesn't already exist in your Active Directory and provide the directory DNS name for `-domain`. For `-OU`, enter the OUs that you want the SVM to join, as well as the full DNS name in DC format. ``` ::>vserver cifs create -vserver svm_name -cifs-server computer_name -domain corp.example.com -OU OU=Computers,OU=example,DC=corp,DC=example,DC=com ``` To verify the status of your Active Directory connection, run the following command: ``` ::>vserver cifs check -vserver svm_name Vserver : svm_name Cifs NetBIOS Name : svm_netBIOS_name Cifs Status : Running Site : Default-First-Site-Name Node Name DC Server Name DC Server IP Status Status Details --------------- -------------- --------------- ------ -------------- FsxId0ae30e5b7f1a50b6a-01 corp.example.com 172.31.14.245 up Response time (msec): 5 FsxId0ae30e5b7f1a50b6a-02 corp.example.com 172.31.14.245 up Response time (msec): 20 2 entries were displayed. ``` 1. If you can't access shares after this join, determine whether the account you’re using to access the share has permissions. For example, if you're using the default `Admin` account (a delegated administrator) with an AWS managed Active Directory, you will must run the following command in ONTAP. The `netbios_domain` corresponds with your Active Directory’s domain name (for `corp.example.com`, the `netbios_domain` used here is `example`). ``` FsxId0123456789a::>vserver cifs users-and-groups local-group add-members -vserver svm_name -group-name BUILTIN\Administrators -member-names netbios_domain\admin ``` ## Modify an Active Directory configuration using the ONTAP CLI You can use the ONTAP CLI to modify an existing Active Directory configuration.
 1. To access the ONTAP CLI, establish an SSH session on the management port of the Amazon FSx for NetApp ONTAP file system or SVM by running the following command. Replace `management_endpoint_ip` with the IP address of the file system's management port. ``` [~]$ ssh fsxadmin@management_endpoint_ip ``` For more information, see [Managing file systems with the ONTAP CLI](managing-resources-ontap-apps.md#fsxadmin-ontap-cli). 1. Run the following command to temporarily bring down the SVM's CIFS server:
 ``` FsxId0123456789a::>vserver cifs modify -vserver svm_name -status-admin down ``` 1. If you need to modify the DNS entries of your Active Directory, run the following command:
 ``` ::>vserver services name-service dns modify -vserver svm_name -domains corp.example.com -name-servers dns_ip_1,dns_ip_2 ``` You can validate the connection status to your Active Directory's DNS servers using the `vserver services name-service dns check -vserver svm_name` command. ``` ::>vserver services name-service dns check -vserver svm_name Name Server Vserver Name Server Status Status Details ------------- --------------- ------------ -------------------------- svmciad dns_ip_1 up Response time (msec): 1 svmciad dns_ip_2 up Response time (msec): 1 2 entries were displayed. ``` 1. If you need to modify the Active Directory configuration itself, you can change existing fields by using the following command, replacing: + *computer\$1name*, if you want to modify the NetBIOS (machine account) name of the SVM. + *domain\$1name*, if you want to modify the name of the domain. This should correspond with the DNS domain entry noted in Step 3 of this section (`corp.example.com`). + `organizational_unit`, if you want to modify the OU (`OU=Computers,OU=example,DC=corp,DC=example,DC=com`). You will need to reenter the Active Directory credentials that you used to join this device to the Active Directory. ``` ::>vserver cifs modify -vserver svm_name -cifs-server computer_name -domain domain_name -OU organizational_unit ``` You can verify the connection status of your Active Directory connection using the `vserver cifs check -vserver svm_name` command. 1. When you finish modifying your Active Directory and DNS configuration, bring the CIFS server back up by running the following command: ``` ::>vserver cifs modify -vserver svm_name -status-admin up ``` ## Unjoin an Active Directory from your SVM using the NetApp ONTAP CLI The NetApp ONTAP CLI can also be used to unjoin your SVM from an Active Directory by following the steps below: 1. To access the ONTAP CLI, establish an SSH session on the management port of the Amazon FSx for NetApp ONTAP file system or SVM by running the following command. Replace `management_endpoint_ip` with the IP address of the file system's management port. ``` [~]$ ssh fsxadmin@management_endpoint_ip ``` For more information, see [Managing file systems with the ONTAP CLI](managing-resources-ontap-apps.md#fsxadmin-ontap-cli). 1. Delete the CIFS server that unjoined your device from the Active Directory by running the following command. For ONTAP to delete the machine account for your SVM, provide the credentials that you originally used to join the SVM to the Active Directory. 
 ``` FsxId0123456789a::>vserver cifs modify -vserver svm_name -status-admin down ``` 1. If you need to modify the DNS entries of your Active Directory, run the following command:
 ``` FsxId0123456789a::vserver cifs delete -vserver svm_name In order to delete an Active Directory machine account for the CIFS server, you must supply the name and password of a Windows account with sufficient privileges to remove computers from the "CORP.ADEXAMPLE.COM" domain. Enter the user name: user_name Enter the password: Warning: There are one or more shares associated with this CIFS server Do you really want to delete this CIFS server and all its shares? {y|n}: y ``` 1. Delete the DNS servers for your Active Directory by running the following command: ``` ::vserver services name-service dns delete -vserver svm_name ``` If you see a warning like the following—indicating that `dns` should be removed as an `ns-switch`—and you don't plan to rejoin this device to an Active Directory, you can remove the `ns-switch` entries. ``` Warning: "DNS" is present as one of the sources in one or more ns-switch databases but no valid DNS configuration was found for Vserver "svm_name". Remove "DNS" from ns-switch using the "vserver services name-service ns-switch" command. Configuring "DNS" as a source in the ns-switch setting when there is no valid configuration can cause protocol access issues. ``` 1. (Optional) Remove the `ns-switch` entries for `dns` by running the following command. Verify the source order, then remove the `dns` entry for the `hosts` database by modifying the `sources` so that they contain only the other sources listed. In this example, the only other source is `files`. ``` ::>vserver services name-service ns-switch show -vserver svm_name -database hosts Vserver: svm_name Name Service Switch Database: hosts Name Service Source Order: files, dns ``` ``` ::>vserver services name-service ns-switch modify -vserver svm_name -database hosts -sources files ``` 1. (Optional) Remove the `dns` entry by modifying the `sources` for the database host to include only `files`. ``` ::>vserver services name-service ns-switch modify -vserver svm_name -database hosts -sources files ```