Using Amazon FSx for Windows File Server with Azure ADDS domain

Customers are using Amazon FSx for Windows File Server for a variety of use cases that need shared file storage that is accessible over the industry-standard Server Message Block (SMB) protocol, and that is integrated with Microsoft Active Directory. You can use Amazon FSx with any Microsoft Active Directory that is hosting your user identities, no matter where it is, be it on-premises or in the cloud, self-managed or fully managed. In this blog, we talk about how you can use Amazon FSx when your user identities are hosted on an Azure Active Directory Domain Services (ADDS) domain.

Active Directory is the Microsoft directory service used to store information about objects on the network and make this information easy for administrators and users to find and use. These objects typically include shared resources such as file servers and network user and computer accounts. Amazon FSx gives administrators the flexibility and control of the Active Directory environment they want their file systems to join such as using Amazon FSx with AWS Directory Service for Microsoft Active Directory and Using Amazon FSx for Windows File Server with an on-premises Active Directory, where you can apply set controls and delegate administrative functions.

If you have your user identities in an Active Directory hosted on ADDS, you can use Amazon FSx for Windows File Server with that Active Directory without the need to migrate or sync the identities to AWS. In this blog, I demonstrate how to join Amazon FSx to an existing ADDS, with an example in a lab environment. Your existing ADDS identities can leverage this share to access stored files and you can use your Azure AD users to authenticate against Amazon FSx for Windows File Server file shares. You do not need to deploy and setup an Active Directory environment on AWS or sync your user identities to AWS, it’s a simple plug and play to your existing ADDS. Note that Amazon FSx for Windows File Server does not support Azure Active Directory (AAD). AAD is a cloud-native authentication directory, which can contain users and groups only, which does not support Kerberos authentication and group policies.

Solution prerequisites

• In AWS
  • Amazon Virtual Private Cloud (Amazon VPC) for connectivity to Azure Virtual Network (Vnet).
  • Amazon FSx for Windows File Server for the file systems.
  • AWS Identity and Access Management (IAM) user/role with appropriate permissions to create Transit Gateways or VPN connections e.t.c.
  • Amazon Elastic Compute Cloud (Amazon EC2) instance for testing purpose.
• In Azure
  • Virtual Network Gateways for Site-to-Site VPN connection to AWS.
  • Local Network Gateways for VPN connection to AWS.
  • Azure AD Domain Services DNS IP addresses for joining the Amazon File Server to the domain.

For example, I use these IP ranges (note that the Amazon VPC CIDR and Azure CIDR cannot overlap):

Amazon VPC CIDR: 172.25.0.0/16

Existing Azure Vnet CIDR: 192.168.0.0/16

Solution overview:

This solution has steps in AWS and Azure that must be completed sequentially to properly work. Some components require you to complete steps in Azure before AWS, and vice versa.

The following steps are completed on Azure:

1. In your existing Resource Group and Virtual Network, create a Gateway Subnet.
2. Create a Virtual Network Gateway (VNG).
3. Create a Local Network Gateway (LNG).
4. Create VPN Connections.

The following steps are completed on AWS:

1. In your existing Amazon Virtual Private Cloud (VPC), create a Customer Gateway.
2. Create a Virtual Private Gateway (VPG).
3. Create site-to-site VPN connection.
4. Create a Dynamic Host Configuration Protocol (DHCP) options set.
5. Join an EC2 instance to Azure Active Directory Domain Services Domain to create OU structure for the file system.
6. Launch Amazon FSx in Azure Active Directory Domain Services Domain.

Create Gateway Subnet – (Azure, step 1)

Create a Gateway Subnet in your Vnet. Microsoft recommends to use /28 or /27 for gateway subnet.

Create Virtual Network Gateway (VNG) – (Azure, step 2)

To create your VNG in Azure, select your existing Virtual Network, then choose Route-based for VPN type and Create new for Public IP address. Leave others as default.

This takes an average of 30 minutes to complete. Once completed, take note of the Public IP address created as it is required to create the Customer Gateway on AWS.

Create a Customer Gateway, Virtual Private Gateway, and site-to-site VPN connection – (AWS, steps 1-3)

1. Access your VPC from the AWS Management Console.
2. Create a Customer Gateway; you need the Public IP address on Azure’s VNG for this.

3. Create a Virtual Private Gateway (VPG) – select Amazon default ASN.
4. Attach the VPG to your Amazon VPC by selecting the virtual private gateway that you created, and then choose Actions, Attach to VPC.
5. Create site-to-site VPN connection to Azure. Choose the previously created Customer Gateway and Virtual Private Gateway. For Routing Options, choose Static, then provide the Vnet CIDR in Azure as the Static IP Prefixes.

6. Once available, click on Site-to-Site VPN Connections and download the configuration, which include information on the VPN tunnels that establish site-to-site connection. On this screen, make sure you choose Generic as the Vendor option.

Use the downloaded configuration to create Local Network Gateway and Connections in Azure (the following steps). The configuration file contains lots of information, but we’re mostly interested in the Pre-Shared Key and VPGs for both VPN tunnels. See the following sample:

Create local network gateways – (Azure, step 3)

Create 2 Local Network Gateways, one for each tunnel of your Amazon VPN. You need information from the previously downloaded configuration to create LNGs and Connections in Azure. The IP address is also from the previously downloaded configuration. In the Address space, put the CIDRs of AWS Production VPCs, you can add additional IP addresses later. Follow the same procedure to create the 2^nd Local Network Gateway, this time with the second tunnel’s configuration.

Create VPN Connections – (Azure, step 4)

Once the deployment of Local Network Gateways (LNG) completes, you now have to create Connections in each of the LNG.

• Click on the first LNG, click Connections and click on Add.
• Give the connection a Name, choose the Virtual network gateway you created earlier.
• Choose Site-to-site (IPsec) as Connection type
• Use the Pre-shared key of tunnel 1 from the downloaded config file in Shared key (PSK). Ensure the pre-shared key you copy is for the exact tunnel you created with your LNG.
• Choose IKEv2 for IKE Protocol. Though AWS config file says IKEv1, if you go with v1, the connection in Azure will not be established.
• Click on Ok to create the connection. Repeat these steps for the 2nd connection.
• Once created, wait for the status to change to Connected. The tunnel end of AWS should show as UP.

Connections to the VNG and respective LNGs:

The connections show as Connected for the site-to-site VPN in Azure:

The tunnels show as UP for VPN connection on AWS:

Next, create Routes on the Amazon VPC Route Table. Here I create a route for the Azure network 192.168.0.0/16, pointing to the Virtual Gateway in the Amazon VPC.

Create a DHCP Options set in AWS – (AWS, step 4)

Get the DNS IP addresses from your existing Azure Active Director Domain Services. Use the 2 IP addresses and DNS name to create a DHCP options set in AWS, then associate this with the Amazon VPC. Note that changing your Amazon VPC DHCP options set may impact other services that depend on this.

Now let’s test connectivity to Azure from Amazon VPC. You must launch an Amazon EC2 (Windows) instance in this Amazon VPC and join to the Azure Active Directory domain which will act as our management instance for that domain. If everything is correctly configured, you should be able to resolve the Azure Active Directory Domain name from an EC2 instance within that VPC.

Let’s join the EC2 instance to the Azure Active Directory Domain Services domain. Please note that for new Azure Active Directory Domain Services deployments, you must enable Azure AD Domain Services password hash synchronization for your on-premise users if you have not done this already. For cloud-native user accounts such as those created directly in Azure Active Directory, you will have to reset the passwords for the hashes to sync to Azure AD Domain Services. This process for doing so is beyond the scope of this blog – you can find more information here: Enable user accounts for Azure AD DS and Enable password synchronization in Azure AD DS.

1. Launch an EC2 instance in same Amazon VPC and region.
2. Ensure you have reset the user’s password in Azure.
3. Add the user account to Azure Active Directory DC Administrators’ group in Azure Active Directory.
4. Join the EC2 instance to ADDS {ds.awslab.com} domain.

Configure OU structure for your Amazon FSx File Systems – (AWS, step 5)

1. Install RSAT tools to manage the OU and other domain policies.
2. Create an OU for Amazon FSx and Group.

Launch Amazon FSx in Azure Active Directory Domain Services Domain – (AWS, step 6)

Now that you have an OU for your file servers and a service account, proceed to create an Amazon FSx file system joined to your Active Directory:

1. The Fully qualified domain name is your ADDS domain name, and the DNS server IP addresses are from the ADDS domain, which is also what you used to create the DHCP options set. Service account username and Service account password are the user account that you have added to Azure Active Directory DC Administrators’ group. The OUis the one created in the previous step.
2. For the Delegated file system administrators group, you have to specify a group natively created either in Azure Active Directory or within Azure Active Directory Domain Services (specifying a group synced with Azure AD Connect from on-premises does not work). If you do not specify a group, Amazon FSx defaults to Domain Admin group in Azure Active Directory Domain Services which is not managed by you. Refer here for more information on group management in Azure Active Directory Domain Services.

3. If creation is successful, you should see its state as Available on the console and the Amazon FSx computer objects should be in the specified OU.

Amazon FSx computer objects in the specified OU:

4. Now mount the file system and access the share. Don’t forget to open the security group attached to your file systems to allow local traffic to the EC2 instance or your Amazon VPC subnet (complete list of FSx for Windows File Server port requirements).

Access the file share:

5. This time test with remote management on PowerShell. Note, the user running this must be a member of the group specified during Amazon FSx file system creation. See this documentation for more information.

Cleaning up:

It’s time to remove the resources you’ve deployed to avoid incurring future charges.

Amazon FSx file system

From the Amazon FSx console, select the file system that you created in Amazon FSx. Click on the Actions menu, then Delete file system. Choose not to create a final backup, and type the file system ID to confirm deletion. Finally, click on Delete file system (again). 

Amazon EC2

From the Amazon EC2 console, select the EC2 instance you launched to join the ADDS domain. Choose Actions, then Instance state, then finally terminate.

Amazon VPC

From the Amazon VPC console,

1. Click on DHCP Options Set, and choose the Options Set you created. Click on Actions, then click Delete DHCP options set. Type delete and click Delete DHCP options set
2. Now, let’s clean the other VPC resources. Click on the Site-to-Site VPN Connections and select the VPN connection you created. Then, choose Actions followed by Delete – click on Delete again to confirm.
3. Click on Virtual Private Gateways. Select the VPG created in this lab then choose Actions. Afterward, choose Detach from VPC, then Yes followed by Detach. Next, choose Actions and Delete Virtual Private Gateway followed by Yes and Delete.
4. Now, click on Customer Gateways. Select the Customer Gateway you created above then choose Actions. Click on Yes then
5. Finally, select the VPC created for this demo. Click Actions, Delete VPC, then Delete VPC This removes all subnets, gateways, endpoints, network interfaces, security groups, and route tables created inside this Amazon VPC.

Summary

In this post, I demonstrated how to join an Amazon FSx for Windows File Server to an Azure Active Directory Domain Services managed domain. I successfully established communication between an Amazon VPC and an Azure Virtual Network. Afterwards, I authenticated a file share using an Azure Active Directory user, without needing to sync user credentials to AWS. Through this solution, users in Azure can use the features and benefits of Amazon FSx file shares without needing to worry about compliance or the administrative overhead of migrating or syncing user identities to AWS.

Thanks for reading this blog post! I look forward to sharing more blogs on how you can easily leverage Amazon FSx for Windows File Server to help optimize your business applications. If you have any questions or comments, please do not hesitate to leave them in the comments section.