![[Amazon FSx for NetApp ONTAP] マルチプロトコルアクセスをActive DirectoryやLDAPを使わずに設定してみた](https://devio2023-media.developers.io/wp-content/uploads/2023/08/amazon-fsx-for-netapp-ontap.png)
[Amazon FSx for NetApp ONTAP] マルチプロトコルアクセスをActive DirectoryやLDAPを使わずに設定してみた
マルチプロトコルアクセスを実装したいけど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と必要があればと記載あありました。
抜粋 : マルチプロトコルの設定ワークフロー
実際にADを使わずにマルチプロトコルアクセスの設定をやってみたので紹介します。
いきなりまとめ
- ADやLDAPを使わずともNFSとSMBのマルチプロトコルアクセスは実現できる
- ネームマッピングを使って、アクセスしてきたユーザーのIDをセキュリティスタイルで設定した形式のユーザーに関連づける
- UNIXローカルユーザーやSMBローカルユーザーをFSxN上で作成する必要がある
- NFSv4でマウントする場合はrootユーザーのネームマッピングが必要
検証環境
検証環境は以下の通りです。
![[Amazon FSx for NetApp ONTAP] マルチプロトコルアクセスをActive DirectoryやLDAPを使わずに設定してみた検証環境構成図](https://devio2023-media.developers.io/wp-content/uploads/2023/09/37aa8e7d5fae00354ae18b07b4655ff2.png)
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でした。
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)でした!
