ちょっと話題の記事

[Amazon FSx for NetApp ONTAP] マルチプロトコルアクセスをActive DirectoryやLDAPを使わずに設定してみた

気軽にNFSとSMBのマルチプロトコルアクセスを実現できる

のんピ

2023.09.26

マルチプロトコルアクセスを実装したいけどActive Directoryがないぞ

こんにちは、のんピ(@non____97)です。

皆さんはActive Directory(以降AD)やLDAPがない環境において、Aamzon FSx for NetApp ONTAP(以降FSxN)のマルチプロトコルアクセスを行いたいなと思ったことはありますか? 私はあります。

以前、以下記事でFSxN上の同じファイルに対してNFSとSMBの複数のプロトコルでアクセスできることを紹介しました。

マルチプロトコルアクセスを実現する際はユーザーマッピングが必要となります。

上述の記事ではNFSクライアントのLinuxマシンをドメイン参加し、ADユーザーにネームマッピングさせてNTFS ACLが効くことを確認しました。

ネームマッピングについては以下NetApp公式ドキュメントやKBに詳細に書かれています。

それでは、ADやLDAPが存在しない場合はマルチプロトコルアクセスは実装できないのでしょうか。

そんなことはなく、手動でネームマッピングを行えば対応可能です。NetApp公式ドキュメントのマルチプロトコルの設定ワークフローにもConfigure LDAP, if necessaryと必要があればと記載あありました。

cifs_nfs_multiprotocol

抜粋 : マルチプロトコルの設定ワークフロー

実際にADを使わずにマルチプロトコルアクセスの設定をやってみたので紹介します。

いきなりまとめ

  • ADやLDAPを使わずともNFSとSMBのマルチプロトコルアクセスは実現できる
    • ネームマッピングを使って、アクセスしてきたユーザーのIDをセキュリティスタイルで設定した形式のユーザーに関連づける
    • UNIXローカルユーザーやSMBローカルユーザーをFSxN上で作成する必要がある
  • NFSv4でマウントする場合はrootユーザーのネームマッピングが必要

検証環境

検証環境は以下の通りです。

[Amazon FSx for NetApp ONTAP] マルチプロトコルアクセスをActive DirectoryやLDAPを使わずに設定してみた検証環境構成図

Amazon Linux 2023からはNFSで、Windows Server 2022からはSMBでFSxN上のボリュームをマウントします。

FSxNは以下の通り作成しました。NFSv4 ACLでファイルへのアクセス許可をしている事例をあまり見たことがないので、ボリュームのセキュリティスタイルは全てNTFSにして、NTFS ACLでアクセス許可をするようにします。

ファイルシステムの詳細

やってみた

SMBサーバーの作成

それではSMBで接続できるように、SMBサーバーを作成します。

ONTAP CLIでFSxNに接続して、smb-serverというSMBサーバーを作成します。作成するSMBサーバーはドメインに参加させない = ワークグループです。

::> cifs create -vserver svm -cifs-server smb-server -workgroup WORKGROUP

Notice: SMB1 protocol version is obsolete and considered insecure. Therefore it is deprecated and disabled on this CIFS server. Support for SMB1 might be
removed in a future release. If required, use the (privilege: advanced) "vserver cifs options modify -vserver svm -smb1-enabled true" to enable it.

::> cifs show
            Server          Status    Domain/Workgroup Authentication
Vserver     Name            Admin     Name             Style
----------- --------------- --------- ---------------- --------------
svm         SMB-SERVER      up        WORKGROUP        workgroup

shareというファイル共有を作成します。

::> cifs share create -vserver svm -share-name share -path /vol1

::> cifs share show
Vserver        Share         Path              Properties Comment  ACL
-------------- ------------- ----------------- ---------- -------- -----------
svm            c$            /                 oplocks    -        BUILTIN\Administrators / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions
svm            ipc$          /                 browsable  -        -
svm            share         /vol1             oplocks    -        Everyone / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions

作成したファイル共有のACLはEveryoneでFull Controlになっていますね。

SMBローカルユーザーの作成

SMBでアクセスする際に使用するローカルユーザーsmb-userを作成します。

::> cifs users-and-groups local-user create -vserver svm -user-name smb-user -is-account-disabled false

Enter the password:
Confirm the password:

::> cifs users-and-groups local-user show
Vserver      User Name                   Full Name            Description
------------ --------------------------- -------------------- -------------
svm          SMB-SERVER\Administrator                         Built-in administrator account
svm          SMB-SERVER\smb-user         -                    -
2 entries were displayed.

ファイル共有のパス/vol1のDACLを確認します。

::> vserver security file-directory show -vserver svm -path /vol1

                Vserver: svm
              File Path: /vol1
      File Inode Number: 64
         Security Style: ntfs
        Effective Style: ntfs
         DOS Attributes: 10
 DOS Attributes in Text: ----D---
Expanded Dos Attributes: -
           UNIX User Id: 0
          UNIX Group Id: 0
         UNIX Mode Bits: 777
 UNIX Mode Bits in Text: rwxrwxrwx
                   ACLs: NTFS Security Descriptor
                         Control:0x8004
                         Owner:BUILTIN\Administrators
                         Group:BUILTIN\Administrators
                         DACL - ACEs
                           ALLOW-Everyone-0x1f01ff
                           ALLOW-Everyone-0x10000000-OI|CI|IO

こちらもEveryoneで許可されているようです。

UNIXのuidやgidは0で、モードビットは777です。NFSで接続できるのでしょうか。

SMBで接続できるか確認

SMBで接続できるか確認します。

> net use Z: \\svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com\share
The password is invalid for \\svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com\share.

Enter the user name for 'svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com': SMB-SERVER\smb-user
Enter the password for svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:
The command completed successfully.

> Get-PSDrive -PSProvider FileSystem

Name           Used (GB)     Free (GB) Provider      Root                                               CurrentLocation
----           ---------     --------- --------      ----                                               ---------------
C                  15.99         14.00 FileSystem    C:\                                            Users\Administrator
Z                   0.00          0.95 FileSystem    \\svm-0812f060a936b7661.fs-08ab9...

Zドライブにマウントできました。

Zドライブ配下の表示や書き込みができるか確認します。

> dir Z:\

> echo test > Z:\test.txt

> dir Z:\


    Directory: Z:\


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         9/26/2023  12:06 AM             14 test.txt


> cat Z:\test.txt
test

問題なくできますね。

NFSで接続できるか確認

NFSで接続できるか確認します。

$ sudo mkdir -p /mnt/fsxn/vol1

$ sudo mount -t nfs svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/vol1
Created symlink /run/systemd/system/remote-fs.target.wants/rpc-statd.service → /usr/lib/systemd/system/rpc-statd.service.

$ df -hT
Filesystem                                                                   Type      Size  Used Avail Use% Mounted on
devtmpfs                                                                     devtmpfs  4.0M     0  4.0M   0% /dev
tmpfs                                                                        tmpfs     204M     0  204M   0% /dev/shm
tmpfs                                                                        tmpfs      82M  452K   82M   1% /run
/dev/nvme0n1p1                                                               xfs       8.0G  1.6G  6.5G  20% /
tmpfs                                                                        tmpfs     204M     0  204M   0% /tmp
/dev/nvme0n1p128                                                             vfat       10M  1.3M  8.7M  13% /boot/efi
tmpfs                                                                        tmpfs      41M     0   41M   0% /run/user/0
svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1 nfs       973M  320K  973M   1% /mnt/fsxn/vol1

マウントできました。ただし、NFSv4ではなく、NFSv3のようですね。

明示的にNFSv4を指定してマウントします。

$ sudo umount /mnt/fsxn/vol1

$ sudo mount -t nfs4 svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/vol1
mount.nfs4: access denied by server while mounting svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1

NFSv4によるマウントは弾かれてしまいます。

もちろん、FSxN側でNFSv4は有効になっています。

::> nfs show

Vserver: svm

        General Access:  true
                    v3:  enabled
                  v4.0:  enabled
                   4.1:  enabled
                   UDP:  enabled
                   TCP:  enabled
                  RDMA:  enabled
  Default Windows User:  -
 Default Windows Group:  -

早速暗雲が立ち込めてきました。

NFSv3ではマウントできるので、マウントポイント配下を参照できるか確認してみます。

$ sudo mount -t nfs svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/vol1

$ df -hT -t nfs
Filesystem                                                                   Type  Size  Used Avail Use% Mounted on
svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1 nfs   973M  320K  973M   1% /mnt/fsxn/vol1

$ ls -l /mnt/fsxn/vol1
ls: cannot open directory '/mnt/fsxn/vol1': Permission denied

$ sudo ls -l /mnt/fsxn/vol1
ls: cannot open directory '/mnt/fsxn/vol1': Permission denied

$ sudo ls -ld /mnt/fsxn/vol1
drwxrwxrwx. 2 root root 4096 Sep 25 23:03 /mnt/fsxn/vol1

sudoしてもアクセスできませんでした。これはモードビット上では777ですが、セキュリティスタイルをNTLMにしている関係でNTLM ACLで制御されるためです。

そのため、NTLM ACLで許可されているユーザーにネームマッピングをする必要があります。

ネームマッピング

ネームマッピングをしていきます。

ネームマッピングをする前にFSxN上に存在するUNIXユーザーとグループ一覧を確認します。

::> name-service unix-user show
  (vserver services name-service unix-user show)
               User            User   Group  Full
Vserver        Name            ID     ID     Name
-------------- --------------- ------ ------ --------------------------------
svm            nobody          65535  65535
svm            pcuser          65534  65534
svm            root            0      1
3 entries were displayed.

::> name-service unix-group show
  (vserver services name-service unix-group show)
Vserver        Name                ID
-------------- ------------------- ----------
svm            daemon              1
svm            nobody              65535
svm            pcuser              65534
svm            root                0
4 entries were displayed.

こちらに存在するユーザーを使ってネームマッピングを行います。今回はrootを使いましょう。

実際にネームマッピングをします。先述の記事ではADユーザーにマッピングするために正規表現を使っていましたが、今回はUNIXのrootをSMBのSMB-SERVER\\smb-userに1対1でマッピングさせます。

::> name-mapping show
  (vserver name-mapping show)
This table is currently empty.

::> name-mapping create -vserver svm -direction unix-win -position 1 -pattern root -replacement SMB-SERVER\\smb-user
  (vserver name-mapping create)

::> name-mapping show
  (vserver name-mapping show)

Vserver:   svm
Direction: unix-win
Position Hostname         IP Address/Mask
-------- ---------------- ----------------
1       -                 -                   Pattern: root
                                          Replacement: SMB-SERVER\\smb-user

::> name-mapping show -instance
  (vserver name-mapping show)

                    Vserver: svm
                  Direction: unix-win
                   Position: 1
                    Pattern: root
                Replacement: SMB-SERVER\\smb-user
IP Address with Subnet Mask: -
                   Hostname: -

ネームマッピングできました。必要に応じてIPアドレスやホスト名でネームマッピング対象を制限すると良いでしょう。

NFSで接続できるか確認 (2回目)

ネームマッピング後にNFSで接続できるか再度確認します。

$ sudo ls -l /mnt/fsxn/vol1
total 0
-rwxrwxrwx. 1 nobody nobody 14 Sep 26 00:06 test.txt

$ sudo cat /mnt/fsxn/vol1/test.txt
��test

$ whoami
ec2-user

$ ls -l /mnt/fsxn/vol1
ls: cannot open directory '/mnt/fsxn/vol1': Permission denied

sudoをしてrootユーザーでアクセスする際はマウントポイント配下のファイルを表示できました。一方で、ネームマッピングをしていないec2-userではファイルの一覧は表示できませんでした。

先頭が文字化けしているのはPowershellのデフォルトの文字コードがUTF-16LEだからです。

rootユーザーで書き込みができるかも確認しておきます。

$ echo test2 | sudo tee /mnt/fsxn/vol1/test2.txt
test2

$ sudo ls -l /mnt/fsxn/vol1/
total 0
-rwxrwxrwx. 1 nobody nobody 14 Sep 26 00:06 test.txt
-rwxrwxrwx. 1 root   root    6 Sep 26 00:21 test2.txt

$ sudo cat /mnt/fsxn/vol1/test2.txt
test2

書き込みできました。

NFSクライアントで書き込んだファイルをSMBクライアントから確認します。

> dir Z:\


    Directory: Z:\


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         9/26/2023  12:06 AM             14 test.txt
-a----         9/26/2023  12:21 AM              6 test2.txt


> cat Z:\test2.txt
test2

問題なく表示できますね。

NFSクライアントで作成したtest2.txtの所有者を確認すると、ネームマッピング先のSMB-SERVER\smb-userでした。

test3.txtのプロパティ

rootユーザー以外のユーザーをネームマッピングする

rootユーザー以外のユーザーをネームマッピングしてみましょう。

まず、FSxN上にネームマッピング元のユーザーやグループを作成せずにネームマッピングをして、アクセスできるか確認してみます。

ec2-userをSMB-SERVER\smb-userにマッピングします。

FsxId08ab94040e16d1cc2::> name-mapping create -vserver svm -direction unix-win -position 2 -pattern ec2-user -replacement SMB-SERVER\\smb-user
  (vserver name-mapping create)

::> name-mapping show
  (vserver name-mapping show)

Vserver:   svm
Direction: unix-win
Position Hostname         IP Address/Mask
-------- ---------------- ----------------
1       -                 -                   Pattern: root
                                          Replacement: SMB-SERVER\\smb-user
2       -                 -                   Pattern: ec2-user
                                          Replacement: SMB-SERVER\\smb-user
2 entries were displayed.

ec2-userでファイルの参照や書き込みができるか確認します。

$ whoami
ec2-user

$ ls -l /mnt/fsxn/vol1/
total 0
-rwxrwxrwx. 1 nobody nobody 14 Sep 26 00:06 test.txt
-rwxrwxrwx. 1 root   root    6 Sep 26 00:21 test2.txt

$ cat /mnt/fsxn/vol1/test.txt
cat: /mnt/fsxn/vol1/test.txt: Permission denied

$ cat /mnt/fsxn/vol1/test2.txt
cat: /mnt/fsxn/vol1/test2.txt: Permission denied

$ echo test3 > /mnt/fsxn/vol1/test3.txt
bash: /mnt/fsxn/vol1/test3.txt: Permission denied

マウントポイント配下の一覧を表示することはできましたが、ファイルの中身を参照したり書き込みはできませんでした。

FSxN上に対応したユーザーが必要そうですね。

FSxN上でec2-userというユーザーとグループを作成します。

::> name-service unix-group create -vserver svm -name ec2-user -id 1000
  (vserver services name-service unix-group create)

::> name-service unix-user create -vserver svm -user ec2-user -id 1000 -primary-gid 1000
  (vserver services name-service unix-user create)

::> name-service unix-group show
  (vserver services name-service unix-group show)
Vserver        Name                ID
-------------- ------------------- ----------
svm            daemon              1
svm            ec2-user            1000
svm            nobody              65535
svm            pcuser              65534
svm            root                0
5 entries were displayed.

::> name-service unix-user show
  (vserver services name-service unix-user show)
               User            User   Group  Full
Vserver        Name            ID     ID     Name
-------------- --------------- ------ ------ --------------------------------
svm            ec2-user        1000   1000
svm            nobody          65535  65535
svm            pcuser          65534  65534
svm            root            0      1
4 entries were displayed.

作成後、ec2-userでファイルの参照や書き込みができるか確認します

$ cat /mnt/fsxn/vol1/test.txt
��test

$ cat /mnt/fsxn/vol1/test2.txt
test2

$ echo test3 > /mnt/fsxn/vol1/test3.txt

$ ls -l /mnt/fsxn/vol1/
total 0
-rwxrwxrwx. 1 nobody   nobody   14 Sep 26 00:06 test.txt
-rwxrwxrwx. 1 root     root      6 Sep 26 00:21 test2.txt
-rwxrwxrwx. 1 ec2-user ec2-user  6 Sep 26 00:39 test3.txt

$ cat /mnt/fsxn/vol1/test3.txt
test3

ユーザーやグループ作成前にできなかったファイルの中身の参照や書き込みができるようになりました。

ネームマッピング後はNFSv4でもアクセスできる件

EC2インスタンスの再起動をしたため、再度マウントしようとしたところNFSv4でマウントできていることを確認しました。

$ df -hT -t nfs4
Filesystem                                                                   Type  Size  Used Avail Use% Mounted on
svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1 nfs4  973M  320K  973M   1% /mnt/fsxn/vol1

本当にネームマッピングが起因でNFSv4をマウントできるようになったのか確認します。

rootユーザーのネームマッピングを削除します。

::> name-mapping delete -direction unix-win -position 1
  (vserver name-mapping delete)

::> name-mapping show
  (vserver name-mapping show)

Vserver:   svm
Direction: unix-win
Position Hostname         IP Address/Mask
-------- ---------------- ----------------
2       -                 -                   Pattern: ec2-user
                                          Replacement: SMB-SERVER\\smb-user

NFSでマウントしてみます。

$ sudo mount -t nfs -v svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/vol1
mount.nfs: timeout set for Tue Sep 26 04:16:00 2023
mount.nfs: trying text-based options 'vers=4.2,addr=10.0.8.20,clientaddr=10.0.0.21'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=10.0.8.20,clientaddr=10.0.0.21'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'vers=4,addr=10.0.8.20,clientaddr=10.0.0.21'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'addr=10.0.8.20'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.0.8.20 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.0.8.20 prog 100005 vers 3 prot UDP port 635
mount.nfs: mount(2): Device or resource busy
mount.nfs: access denied by server while mounting svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1

NFSv4でマウントしようとしたところ失敗して、NFSv3でマウントしたことが分かります。

rootユーザーのネームマッピングを追加します。

::> name-mapping create -vserver svm -direction unix-win -position 1 -pattern root -replacement SMB-SERVER\\smb-user
  (vserver name-mapping create)

::> name-mapping show
  (vserver name-mapping show)

Vserver:   svm
Direction: unix-win
Position Hostname         IP Address/Mask
-------- ---------------- ----------------
1       -                 -                   Pattern: root
                                          Replacement: SMB-SERVER\\smb-user
2       -                 -                   Pattern: ec2-user
                                          Replacement: SMB-SERVER\\smb-user
2 entries were displayed.

NFSv4でマウントできるか確認します。

$ sudo umount /mnt/fsxn/vol1

sh-5.2$ sudo mount -t nfs -v svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/vol1
mount.nfs: timeout set for Tue Sep 26 04:20:11 2023
mount.nfs: trying text-based options 'vers=4.2,addr=10.0.8.20,clientaddr=10.0.0.21'

$ df -hT -t nfs4
Filesystem                                                                   Type  Size  Used Avail Use% Mounted on
svm-0812f060a936b7661.fs-08ab94040e16d1cc2.fsx.us-east-1.amazonaws.com:/vol1 nfs4  973M  384K  973M   1% /mnt/fsxn/vol1

NFSv4でマウントできました。

NFSv4でマウントする場合は、rootに対するネームマッピングを用意すると良いでしょう。

その場合、いずれのLinuxマシンでもrootユーザーであればマウントできてしまうので、ネームマッピングやエクスポートポリシーでIPアドレスを絞ったり、rootユーザー専用のSMBローカルユーザーを作成してあげてDACLを制御してあげると良いでしょう。

簡単にNFSとSMBのマルチプロトコルアクセスを実現できる

Amazon FSx for NetApp ONTAPにてマルチプロトコルアクセスをActive DirectoryやLDAPを使わずに設定してみました。

ネームマッピングやSMBローカルユーザーを作成・管理する手間はありますが、検証などで取り敢えずNFSとSMBのマルチプロトコルアクセスを実現したいという時に活躍しそうですね。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!

AWS

関連記事

[Amazon FSx for NetApp ONTAP] ファイル共有のACLでReadのみの明示的なDenyをONTAPが認識できるのか確認してみた

のんピ

2024.04.28

[Amazon FSx for NetApp ONTAP] SnapLockによるWORMを試してみた

のんピ

2024.04.17

[Amazon FSx for NetApp ONTAP] qtree と クォータ を使った書き込み制限をやってみる

のんピ

2024.04.12

[Amazon FSx for NetApp ONTAP] FabricPoolを利用している環境でデータを定期スキャンするシステムを導入する際の対応方法を考えてみた

のんピ

2024.04.10