In this section, we will setup and configure FSx for Windows filesystems in multiple availability zones within AWS’s infrastructure. These FSx filesystems are fully managed by AWS, all OS updates and maintenance tasks of the instances are dealt with by AWS with no end user intervention needed.
In order for FSx for Windows to function correctly and be able to integrate with windows permissions and delegations, we need to add the FSx File Systems to our active directory. This can be done through the Managed AD service, or most recently, it can be done with a self-managed active directory. This can be an on-premise Active Directory or an Active Directory we manage ourselves on EC2 instances.
When setting up a FSx for Windows File System, one of the options is for an active directory service account that can be used for the FSx instances to use to join and manage its connection to the domain. It is always important to ensure service accounts have the least amount of privilege (POLP) required. Below is a guide to setting up the correct POLP for the FSx service account. This is done through permission delegation.
On a computer or server with the domain administration tools installed, open Active Directory Users and Computer.
Choose an appropriate organisational unit for the service account, then right click and navigate to “New” -> “User”.
Navigate through the New User wizard and complete all of the details required, ensuring that the “user must change password on next login” is unselected, and for my test case, we will be setting the password to not expire.
The user will be created with only the basic “domain user” group that has no additional permissions assigned to it. We will now delegate the required permissions for FSx to the account for the domain. This is done through the “Active Directory Users and Computers” management console.
You may want to provide the user delegated access to the entire domain, in this scenario you would be able to configure the FSx settings to be placed in any OU container within your domain, or even leave the value to be blank. To delegate access to the full domain, you would, right click the top level of the domain (this should be the FQDN of the domain). Navigate to “All Tasks” and then select “Delegate Control”.
However in order to give the user the least amount of access required, we are going to only delegate control to the OU where we want the FSx instances to be placed, which is in the “Servers” OU. This does mean that when configuring FSx (in the next section) we need to specify the path to the servers OU, if we left it blank or specified another OU, it would fail to join the domain as our FSx user only has permission to this folder. To delegate access only to this OU, similar to the above “ALL” option, we simply right click the OU where we want to delegate access (our Servers OU) then navigate to “All Tasks” and then select “Delegate Control”.
In the delegation wizard, click next on the first welcome screen.
In the users and groups page of the wizard, click “add” and then search for and select the user we have created in the previous steps. Click “next” once the user has been selected.
Select “Create a custom task to delegate” (this will allow us to customise the permissions to meet our needs). Click “Next”
Select “Only the following objects in the folder” and then make sure “Computer objects” is ticked. Click on “Next”.
On the permissions page of the wizard, click the tick boxes beside “General” to allow us to select the permissions we need. Tick the following permissions and then click “Next” once they are selected.
- Reset Password
- Read and Write Account Restrictions
- Validated write to the DNS host name
- Validated write to the service principal name
The final page will give you a summary of the permissions we have setup and selected in the previous wizard pages. Confirm all of the above permissions have been selected and click “Next” to complete the permission setup/delegation.
Login to the AWS management console: https://console.aws.amazon.com/console/home?#
Ensure the region in which you want to launch your FSx Filesystems is selected in the top right, otherwise you may launch it in the wrong Region (and you will need to delete and start again).
In “Services” search for the “FSx” service, and then select the FSx service.
Once in the FSx service window, you may be provided with a welcome screen if you have not been into File Systems before, and if you do simply select the main window from the left menu. Once in the main service window, select “Create File System”.
We now get to select what version of FSx we would like to deploy. Select “FSx for Windows File Server” and click “Next”.
On the next page, you will be provided with multiple sections that need to be completed in order to launch your FSx file system.
Firstly, for “File System Details” you will need to provide:
- File System Name – (make it distinguishable),
ours will be:
- TE-FSx_AZB for the file system in availability zone B
- TE-FSx_AZC for the file system in availability zone C
- Capacity for your Storage – (this cannot be adjusted afterwards, please plan your storage systems accordingly)
- Throughput Capacity – (this cannot be adjusted afterwards, please select a throughput in MB/s that will meet your data access requirements)
The next section is around “Network & Security”, ensure these settings are correct as some cannot be changed at a later date:
- VPC – (Select the VPC you want to deploy your
filesystem into, this will determine the subnets available for the next
- I have selected our Testing Environment VPC where our domain controllers and subnets for each AZ have been setup.
- Subnet – (Select the subnet you want to place
the filesystem into). For our HA FSx setup, we are installing a file system
into multiple availability zones, one in B and one in C.
- TE-FSx_AZB in subnet TE-SN-B-1 (Availability Zone B)
- TE-FSx_AZC in subnet TE-SN-C-1 (Availability Zone C)
- VPC Security Groups – (Security groups that
control network access for the FSx instances)
- These security groups need to have access between client PC’s for file access and also any domain controllers for domain join functions.
- I have setup a single security group for both FSx setups (SG-TE-FSX). These security groups are referenced in our domain controllers and clients to allow appropriate access through security group referrals rather than IP targeting (this is more dynamic incase FSx instances change IP while being managed by AWS)
- SG should allow access between the two file systems as this will be needed for replication
For the “Windows Authentication” section, you must select whether you are using an AWS Managed Microsoft Active Directory or using a Self-Managed Microsoft Active Directory. This guide is for using a Self-Managed Active Directory.
Select “Self-managed Microsoft Active Directory”
You will need to provide the following details for the FSx File Systems to connect to your active directory domain.
- Fully Qualified Domain Name (FQDN) – (this
should be the FQDN of your domain)
- We will enter “testdomain.thecloudwolf.com”
- DNS server IP addresses – (enter DNS servers for
your domain, it is recommended to always have 2 for availability, however in
our test environment I only have one domain controller for this setup).
- 172.16.0.10 (TE-DC01)
- Service Account Username – (This is the service
user we created earlier that we delegated our custom permissions to)
- The service account I created earlier “fsx-service”
- Service account password and Confirm Password – (This is the password for the above account)
- Organisational Unit – (This is where the domain
computer accounts for the FSx instances will be placed, if the permissions were
delegated to the full domain, this can be left blank, or can be entered as any
OU within the domain structure, however if the user was delegated permissions
on a specific OU, then that OU must be entered).
- I am placing the FSx instances into the servers OU within the domain (our FSX.SERVICE account was granted permissions to this OU only for reason of least privilege).
- Delegated File System Administrators Group – (Enter
a group that you want to be granted administrator access to manage the
FileSystems, if this is left blank, it will be the domain admins group).
- Left Blank to allow Domain Admins to manage the File System
The last main settings section is on Encryption. This is to manage the encryption key that is used to encrypt all data on the FSx Filesystems at rest. You can allow it to use the default aws/fsx key, or can use another key that you have previsioned within AWS Key Management Service (KMS).
An optional section at the bottom is to make modifications to the maintenance and backup settings for your FSx filesystems. Although this is optional, this is worth reviewing and making sure the settings are correct and work together for all filesystems that are part of the HA solution From here you can change the maintenance window AWS can use to manage or maintain your filesystem and also the backup window for daily backups. As these are windows where some interruption may be expected, when making a HA FSx solution, you should ensure that all filesystems have different maintenance windows so that they do not have maintenance at the same time. You may also want to only backup one of the filesystems by entering a retention period of 0 (disables the auto backup) for one of the filesystems as they are a replica of each other, or have one with a longer retention period.
Once you have entered all required items, click “Next” in the bottom right to confirm your settings prior to creating your file systems.
You will be given a summary of all settings you have entered and also will list whether the values can be changed at a later date. If they cannot, it would be worth making sure that they are correct as you would need to delete and start again if you need to change them. Once you are happy with the settings, click “Create File System” in the bottom right.
You will be taken back to the main FSx service console window, where your new FSx Filesystem will be listed as “Creating”. This may take some time to complete while it provisions all of the services in the background. You will be able to view all of the details for the file system by clicking on its name.
If the creation fails, you will need to delete it and re-create it. IF this happens, check that SG’s are in place to allow access to your domain controllers, you have entered the details of the service account are correct, check you have delegated access to the OU you have entered or that domain and DNS entries are entered correctly for the domain join.
Below you can see I have finished setting up both File Systems, one in a subnet for AZ B and one for AZ C and both are listed as available.
If we open Active Directory Users and computers and navigate to the OU we selected for our filesystems, you can see that computer accounts have been created for the 2 FSx instances, along with DNS Entries on the domains DNS servers. These names and entries will match the DNS name of the filesystems as seen in their Network & Security detail sections, starting with “AMZNFSX”.
Once our filesystems are available and we have the DNS names (from the properties window of the FSx systems) we should be able to access both file systems directly in AZ B and C from our client PC (SG access has been allowed).
To access the root of the file systems, you can use the default share created (share), or use the default volume admin share (d$). For example we will be accessing the following internal only UNC paths:
If you are unable to reach the above UNC paths, check your routing into the subnets and out of the subnets whether you are accessing from on premise or from an EC2 instance, Security Group access, or check that the user you are using has permissions to the fileshare (you will need to access from a group you specified in the “Delegated File System Administrators Group” section of the FSx setup, by default this will be a member of “Domain Admins”. With this account you will be able to access, or grant further access to the file systems as you would with a normal file, folder or share.
From my client EC2 instance (TE-CLIENT) I am able to access both file systems located in different AZ’s. I could also map the file systems as a mapped drive.
Continue to Part 4, where we configure replication between our 2 filesystems located in multiple AWS Availability Zones.