FSx for NetApp ONTAP (FSxN): Multiprotocol access WITHOUT Active Directory integration.

Introduction In many AWS environments, users need to access the same Amazon FSx for NetApp ONTAP (FSxN) volume via both NFS (Linux) and SMB (Windows). While Active Directory (AD) is the standard for identity management, certain use cases require a setup without an AD domain.

This guide explains how to configure the NTFS Security Style for multiprotocol access using local users and manual name mapping.

1. Prerequisites

For the purpose of this example, the following configurations were applied during the FSxN setup process:

• Volume name = vol1
• Volume style = FLEXVOL
• Junction path = /vol1
• Tiering policy name = NONE
• Tiering policy cooling period (days) = '-’
• Security style = NTFS

Security Groups:

Before configuring ONTAP, ensure your Network Security Groups allow more than just port 2049. For a successful mount and locking behavior, the following ports must be open between your clients and the FSx for ONTAP floating IP/SVM interface:

• TCP/UDP 111: RPC Bind
• TCP/UDP 635: Mountd
• TCP/UDP 2049: NFS
• TCP/UDP 4045 & 4046: NLM/NSM (Locking/Status)
• TCP 445: SMB
• TCP 22: SSH ('fsxadmin' and 'vsadmin' access)

Enabling the 'vsadmin' account on the SVM:

By default, the 'vsadmin' account is locked in ONTAP. To perform configurations directly on the SVM without having to manage "SVM" or "FSx" scopes constantly, you should first unlock the 'vsadmin' account. This is done at the Cluster level (File System) via the 'fsxadmin' account.

• SSH via ‘fsxadmin’ by the DNS name ‘management.fs-123.fsx.Region.amazonaws.com’: ssh fsxadmin@management.fs-123.fsx.Region.amazonaws.com
• Unlocking the 'vsadmin' user on SVM 'svm1': security login unlock -vserver svm1 -username vsadmin

Once 'vsadmin' is enabled, you can SSH into 'svm1' instead of the Cluster level (File System) via the 'fsxadmin' from the Linux server. All following commands in this guide are executed directly via this SVM connection.

Note: Ensure that TCP 22 (SSH) is allowed in your Security Groups for the duration of the configuration. It is recommended to restrict or remove this access once the setup is complete.

UNIX Users "Linux/ec2-user" in the Name Service:

To establish a consistent identity foundation within the SVM, you must first create a local UNIX user. This is a critical prerequisite for successful multiprotocol name mapping, ensuring that the system can resolve identities even if the primary access is later performed via SMB/CIFS.

In this scenario, first identify the UID (User ID) and GID (Group ID) of the existing "ec2-user" on the Linux client to mirror them on the SVM.

[ec2-user@ip-10-0-xx-xx ~]$ id
uid=1000(ec2-user) gid=1000(ec2-user) groups=1000(ec2-user),4(adm),10(wheel),190(systemd-journal) context=system_u:system_r:unconfined_service_t:s0

Result:

• Username: ec2-user
• User ID (UID): 1000
• Primary Group ID (GID): 1000

2. Creating the Local User Environment

Since we are not using AD, we must create local users directly on the Storage Virtual Machine (SVM).

Step 2a: Connecting as 'vsadmin' to the SVM

Since SSH (TCP 22) has been permitted in the Security Group and the 'vsadmin' account has been unlocked on 'svm1' as described above, you can now connect to the SVM via SSH as follows:

ssh vsadmin@svm-123.fs-123.fsx.Region.amazonaws.com

Step 2b: Create a local UNIX user and group

vserver services name-service unix-user create -user ec2-user -id 1000 -primary-gid 1000
vserver services name-service unix-user show

Syntax:: vserver services name-service unix-user create -user <username> -id <numeric_id> -primary-gid <primary_group_id>

The output confirms that the "ec2-user" was provisioned on the SVM with the designated UID and GID, ensuring identity alignment between the storage and the Linux client.

Step 2c: Creating a CIFS Service with Share Name ‘vol1’

In this configuration, a corresponding CIFS/SMB share is created on the volume using the share name ‘vol1’ and the workgroup ‘showcase’. vserver cifs create -cifs-server vol1 -workgroup showcase

Note: A notification regarding SMBv1 will be displayed; this can be safely ignored.

Step 2d: Creating CIFS Share ‘svm1’ with Path ‘/vol1’’: cifs share create -share-name svm1 -path /vol1 -share-properties oplocks,browsable,changenotify,show-previous-versions

Verifying the CIFS Service/Server Status: vserver cifs show

Verifying the CIFS Share Status: vserver cifs share show -share-name svm1

Note: In this example, 'vol1' refers to the NetApp volume and CIFS server name "cifs-server", while 'svm1' is used as the SMB share name.

Step 2e: Create a local SMB "Windows user": vserver cifs users-and-groups local-user create -user-name ec2-user

3. Name Mapping: Hardening CIFS User Access

For ONTAP to understand that the Linux "ec2-user" and the Windows "ec2-user" are the same entity, we need bidirectional Name Mapping.

• UNIX to Windows: Maps the incoming NFS user to a Windows identity to check NTFS permissions.
• Windows to UNIX: Ensures that when a Windows user creates a file, it shows correct ownership in a Linux ls -l output.

Commands:

Step 3a: Viewing CIFS User Permissions: vserver cifs share access-control show -share svm1

Step 3b: Add CIFS user "ec2-user" and remove "Everyone"

First, grant "Full_Control" permissions to the user "ec2-user": vserver cifs share access-control create -share svm1 -user-or-group ec2-user -permission Full_Control

Verify the CIFS user permissions again: vserver cifs share access-control show -share svm1

Now, remove the ‘Everyone’ group to finalize the hardening process: vserver cifs share access-control delete -share svm1 -user-or-group Everyone

Verify the CIFS user permissions after hardening process: vserver cifs share access-control show -share svm1

Note: You can now connect to the share from a Windows EC2 instance using the local Windows 'ec2-user'. Once connected, you can manage permissions directly through Windows Explorer, as demonstrated in the test shown in the screenshot below.

4. Configuring the NFS Service

Step 4a: NFS Status Check

Before configuring the NFS service and its permissions, the current configuration can be verified as follows: vserver nfs show

It can be observed here that no 'Default User' is configured for NFS access. While this is an optional setting when accessing an NTFS volume (or an ONTAP volume with the 'NTFS' security style), this showcase employs a different approach.

The SVM is configured to support both NFSv3 and NFSv4/4.1. This requires a precise understanding of how identities are transferred between the two versions:

• NFSv3 NFSv3 is "simpler" and blindly trusts the UID/GID (User ID/Group ID) sent by the client. Consequently, the mapping occurs entirely on the client side.
• NFSv4.x, by contrast, utilizes string-based mapping (e.g., user@domain.com). This requires both the client and the storage system to use the same ID Domain Name to ensure identities are resolved correctly.

In an Active Directory context, this leads to distinct behaviors: while NFSv3 simply passes through the numerical ID, v4 requires a name match. Without proper configuration (e.g., the idmapd daemon), this often results in failed resolutions and "nobody" mappings.

Note: This showcase focuses exclusively on NFSv3, as the ONTAP system is being used without an Active Directory context. Therefore, the following sections will only address NFSv3.

Step 4b: Displaying Current NFS Export Policies: vserver export-policy rule show -instance

Note: As shown here, the ‘default’ policy currently allows all NFS access, whereas access is restricted to ‘RO’ (Read-Only) in the policy for the root volume.

Step 4c: Displaying Volume to NFS Export Policy Assignments: volume show -volume vol1 -fields policy

Note: It can be seen here that the NFS policy ‘default’ is currently assigned to volume ‘vol1’.

Step 4d: The following command can be used to verify the Junction Path ↔ NFS Export Policy mapping:

volume show -volume vol1 -fields junction-path, policy

Note: The junction path is also currently mapped to the 'default' NFS policy

Step 5 Hardening NFS Access

Having already hardened CIFS access, I will now restrict NFS access. To achieve this, I have created a new NFS policy, assigned it to the volume, and restricted access specifically to the Linux server's IP address. Depending on the client's operating model, this might be viewed as an additional management burden, as it adds a secondary security layer in ONTAP on top of the AWS Security Groups. However, for security reasons, this remains my clear recommendation!

Step 5a: Creating an NFS Export Policy

Access to ONTAP via NFS is managed through NFS Export Policies. In the following example, I have created a policy and subsequently granted access to the source ‘Linux Server IP’. As a general rule, a granular list of IP addresses and subnets authorized for NFS access should be provided here. This configuration operates independently of AWS Security Group Inbound Rules and the "NFS" rules contained within them.

Create a new NFS Export Policy named ‘vol1’: vserver export-policy create -policyname nfs_vol1

Step 5b: Adding a Rule to the Previously Created NFS Policy ‘vol1’

After creating the policy, we now add a specific rule to limit access to the Linux server at IP 10.0.0.25 (Amazon Linux EC2 IP in my example).

vserver export-policy rule create -policyname nfs_vol1 -clientmatch 10.0.0.25 -rorule sys -rwrule sys -superuser sys -protocol nfs3,nfs4

Step 5c: Assigning the ‘nfs_vol1’ Policy to Volume ‘vol1’

To ensure the NFS policy and its new rule take effect on volume ‘vol1’, it must be assigned to the volume as follows (note that only one policy can be assigned per volume).

volume modify -volume vol1 -policy nfs_vol1

Step 5d: Verifying the ‘nfs_vol1’ ↔ ‘vol1’ Policy Assignment

To ensure that the volume is now strictly accessible only via your new policy, you can verify the configuration as follows: volume show -volume vol1 -fields policy

Step 6 User-Mapping local ONTAP User (NFS+CIFS-User)

In this test, the mapping between the Windows/CIFS user ‘ec2-user’ and the Linux/NFS user ‘ec2-user’ functions without an explicit mapping rule due to ONTAP’s "Default Mapping" mechanism. When a UNIX user (UID 1000) accesses the system, ONTAP automatically associates them if a local UNIX user and a local Windows user share the exact same name. Since I previously created the ‘ec2-user’ in ONTAP with the same UID ‘1000’ used on the Linux client, the mapping worked automatically.

I verified this as follows, even though it was already evident since I was able to write to the ‘test.txt’ file from both sides without errors and to check the permission: vserver security file-directory show -path /vol1/test.txt

Step 6a: "Cross-Check"

To verify the hardening via a cross-check, I performed the following test on the Linux server: sudo -u root touch /mnt/vol1/forbidden.txt

Note: The expected result was achieved, the "root" user did not have the required permissions to create or read files on the drive - only the user "ec2-user" was authorized.

Why did it work?

Before the explicit mapping was established, ONTAP relied on the "Default UNIX User" or automatic name-based mapping:

• Automatic Mapping: Since both the Linux and CIFS users were named "ec2-user", ONTAP performed an implicit link between them.
• Export Policy: The NFS export policy was previously set to "superuser=any", which handled access differently than the hardened setup.

The "Tricky" SID: Without explicit mapping, ONTAP may have treated the user as an object that possessed rights within the NTFS ACL by coincidence (e.g., via the "Authenticated Users" group).

To move away from this reliance on "chance" and to enforce explicit rather than implicit mapping, the following steps must be completed:

Step 6b Mapping to a Specific Local CIFS User

Since there is no central authority (Active Directory) to resolve names within the 'showcase' workgroup, the SVM acts as a standalone system. Consequently, users must be explicitly "mapped" to ensure that—regardless of whether they access data via NFS or SMB—they are associated with the same identity.

vserver name-mapping create -direction unix-win -position 1 -pattern ec2-user -replacement ec2-user

Note: Pay close attention to the correct spelling; please refer to the example in the screenshot.

In the previous example, a UNIX → Windows mapping was established. It is now equally necessary to implement the corresponding Windows → UNIX user mapping:

vserver name-mapping create -direction win-unix -position 1 -pattern ec2-user -replacement ec2-user

Note: Pay close attention to the correct spelling; please refer to the example in the screenshot.

Why is the Windows-to-UNIX direction important now?

While the previous step defined UNIX → Windows mapping (enabling the Linux user to write to the volume), implementing the reverse Windows → UNIX mapping is essential for the following reasons:

• Displaying File Ownership: When running a command like ls -l on the Linux server, ONTAP must translate the Windows SID attached to the file back into a UNIX name. Without this mapping, the owner might only be displayed as a generic ID or as nobody.
• Permission Validation: When Windows applications or services act on behalf of a user, this mapping allows ONTAP to immediately identify the corresponding local UNIX user and apply the correct permissions.

Step 6c Verifying that the mapping was created correctly: vserver name-mapping show

Step 6d Confirming NTFS Permissions for ‘vol1’

To double-check the NTFS permissions directly at the SVM level for ‘vol1’, execute the following command: vserver security file-directory show -path /vol1. The outcome should be as follows:

Owner:

• BUILTIN\Administrators – Ownership of the directory is held by the Administrators group.

DACL:

• NT AUTHORITY\Authenticated Users: read only (0x1200a9)
• VOL1\ec2-user: Full Control (0x1f01ff)

Step 6e Security Cross-Check on EC2 filesystem:

Attempts to modify permissions via an NFS/UNIX user were successfully blocked. This confirms that the "NTFS" Security Style is enforcing permission management via Windows ACLs. Should you require the ability to modify permissions from both protocols, the volume would need to be set to "MIXED" mode (this is generally NOT recommended and can lead to corrupted or broken file permissions).

Result: NFS permission changes were successfully blocked, while all authorized functional tests passed.

PS: For those looking for similar approaches but with Active Directory (AD) integration, I highly recommend checking out this blog post:

• Enabling multiprotocol workloads with Amazon FSx for NetApp ONTAP