[Amazon FSx for NetApp ONTAP] マルチプロトコルで同じファイルにアクセスできるように設定してみた

同じファイルにマルチプロトコルでアクセスできて便利
2022.11.09

NFSからもSMBからも同じファイルにアクセスできるようにしたいな

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

皆さんはNFSからもSMBからも同じファイルにアクセスできるようにしたいなと思ったことはありますか? 私はあります。

普段はWindowsから操作するけど、たまにLinuxからも操作したいといった場面はあると思います。

Amazon Fsx for NetApp ONTAP(以降FSx for ONTAP)では、そのようなマルチプロトコルのワークロードに対応しています。

今まで、LinuxからWindowsのファイル共有にアクセスする際はsmbclientを使ってSMBでマウントしていたと思いますが、FSx for ONTAPではNFSでマウントすることができます。また、WindowsからNFSのファイルサーバーにSMBでマウントすることも可能です。

各OSがネイティブにサポートしているプロトコルでアクセスできるのはありがたいですね。

以下AWS公式ブログを参考に私も試してみたので、紹介します。

いきなりまとめ

  • マルチプロトコルでアクセスできるようにするためにはネームマッピングが必要
    • NFSクライアントとなるLinuxをドメイン参加させる必要がある
  • セキュリティスタイルで許可されているなプロトコルによるファイルやディレクトリの権限の編集はできないので注意が必要
  • 文字コードやファイルロックなどにも気をつけよう

ONTAPのマルチプロトコルアクセスの仕組み

まず、ONTAPのマルチプロトコルアクセスの仕組みを確認してみます。

マルチプロトコルアクセスを支える要素は大きく2つあります。

  1. ネームマッピング
  2. セキュリティスタイル

ネームマッピングとはLinuxのユーザーをWindowsのユーザーに紐づける、また、その逆を行う処理のことです。

ネームマッピングを行うことでLDAPなどのIDプロバイダーの認証情報を使って、NFSとSMBどちらも同じ認証情報でアクセスすることが可能になります。

Data ONTAPでは、ネーム マッピングを使用して、CIFS IDをUNIX IDに、Kerberos IDをUNIX IDに、UNIX IDをCIFS IDにマッピングします。この情報は、NFSクライアントからの接続かCIFSクライアントからの接続かに関係なく、ユーザ クレデンシャルを取得して適切なファイル アクセスを提供するために必要になります。

通常、ネーム マッピングは、Data ONTAPがマルチプロトコル対応であり、同じデータへのCIFSクライアントとNFSクライアントのアクセスをサポートすることが理由で必要となります。FlexVolを備えたStorage Virtual Machine(SVM)に格納されているデータでは、UNIXまたはNTFS形式のアクセス権が使用されます。クライアントが許可されるには、クレデンシャルがセキュリティ形式と一致する必要があります。次のシナリオを考えてみましょう。

CIFSクライアントがUNIX形式のアクセス権を使用するデータにアクセスしようとする場合、UNIX形式のアクセス権に対してCIFSクレデンシャルを使用することはできないため、Data ONTAPではクライアントを直接許可できません。クライアント要求を適切に許可するには、Data ONTAPではまず、CIFSクレデンシャルを適切なUNIXクレデンシャルにマッピングし、UNIXクレデンシャルを使用してUNIX形式のアクセス権と比較できるようにする必要があります。

NFSクライアントがNTFS形式のアクセス権を使用するデータにアクセスしようとする場合、NTFS形式のアクセス権に対してUNIXクレデンシャルを使用することはできないため、Data ONTAPではクライアントを直接許可できません。クライアント要求を適切に許可するには、Data ONTAPではまず、UNIXクレデンシャルを適切なNTFSクレデンシャルにマッピングし、NTFSクレデンシャルを使用してNTFS形式のアクセス権と比較できるようにする必要があります。

ネーム マッピングの使用方法

セキュリティスタイルはボリュームまたはqtreeのアクセス制御方法を指定する仕組みです。

FSx for ONTAPで設定できるセキュリティスタイルは以下の3つです。

  1. UNIX
  2. NTFS
  3. MIXED

各セキュリティスタイルのアクセス制御方法は以下の通りです。

セキュリティスタイル アクセス許可を変更できるクライアント アクセス制御方法 有効になるセキュリティスタイル ファイルにアクセスできるクライアント
UNIX NFS NFSv3モード ビット UNIX NFSとSMB
UNIX NFS NFSv4.x ACL UNIX NFSとSMB
NTFS SMB NTFS ACL NTFS NFSとSMB
MIXED NFSまたはSMB NFSv3モード ビット UNIX NFSとSMB
MIXED NFSまたはSMB NFSv4.x ACL UNIX NFSとSMB
MIXED NFSまたはSMB NTFS ACL NTFS NFSとSMB

参考 : セキュリティ形式とその影響とは

これだけを見るとMIXEDが最も柔軟性がありそうですが、ファイルやフォルダごとにNTFS ACLやNFS ACLが混在してしまうためMIXEDは非推奨です。

As a best practice, NetApp does not recommend a mixed security style unless your application has a direct requirement.

Multiprotocol NAS in NetApp ONTAP Overview and Best Practices P.26 | TR-4887 | NetApp

また、ボリュームのセキュリティスタイルを変更する場合、既存のファイルの権限は変更後のセキュリティスタイルのアクセス制御方式を無視するようです。手動でそのファイルのアクセス制御方式を変更しなければならないように見えるので注意が必要です。

UNIX

ユーザのUIDとGID、およびファイルまたはディレクトリのUNIX形式の権限ビットにより、ユーザのアクセスが決まります。ストレージ システムでは、NFS要求とCIFS要求のアクセスを判断するために同じ方法を使用します。

qtreeまたはボリュームのセキュリティ形式をNTFSからUNIXに変更した場合、ストレージ システムはqtreeまたはボリュームでNTFSセキュリティ形式を使用したときに確立されたWindows NTアクセス権を無視します。

NTFS

CIFS要求の場合、Windows NTアクセス権によりユーザのアクセスが決まります。NFS要求の場合、ストレージ システムは少なくともWindows NTアクセス権と同程度に制約的な一連のUNIX形式の権限ビットを生成して格納します。

ストレージ システムは、UNIX形式の権限ビットによってユーザのアクセスが許可される場合のみ、NFSアクセスを許可します。

qtreeまたはボリュームのセキュリティ形式をUNIXからNTFSに変更した場合、変更前に作成したファイルにWindows NTアクセス権は含まれません。これらのファイルについて、ストレージ システムはUNIX形式の権限ビットのみを使用してアクセスを判断します。

mixed

qtreeまたはボリュームに、UNIXセキュリティ形式を使用するファイルとNTFSセキュリティ形式を使用するファイルが含まれます。ファイルのセキュリティ形式は、権限の最後の設定がCIFSから行われたか、NFSから行われたかに依存します。

たとえば、ファイルで現在UNIXセキュリティ形式を使用していて、そのファイルにCIFSユーザがset-ACL要求を送信した場合、ファイルのセキュリティ形式はNTFSに変更されます。ファイルで現在NTFSセキュリティ形式を使用していて、そのファイルにNFSユーザがset-permission要求を送信した場合、ファイルのセキュリティ形式はUNIXに変更されます。

マルチプロトコルの認証・認可の全体の流れは以下の通りです。

When a NAS client requests access to a volume in ONTAP, a series of things happen behind the scenes to provide the most transparent experience to the end user.

This process is controlled by how ONTAP is configured, but general concepts still apply:

  1. A NAS client makes a NAS connection to the ONTAP storage VM.
  2. The NAS client passes user identity information to ONTAP.
  3. ONTAP checks to make sure the NAS client/user has access to the NAS share.
  4. ONTAP takes that user and maps it to a valid user that ONTAP can find in its name services.
  5. ONTAP uses that user to compare against the file-level permissions in the system.
  6. Those permissions control the level of access the user has.

In Figure 1, user1 authenticates to a share in an ONTAP storage virtual machine (SVM) through either SMB or NFS. ONTAP finds the user in LDAP and Active Directory and maps the user 1:1. After that happens, the user is verified as user1 and gets user1’s access. In this instance, they get full control on their own folder, read access to user2’s folder, and no access to the HR folder. This is all based on the ACLs specified in the file system.

(機械翻訳結果)

NASクライアントがONTAP内のボリュームへのアクセスを要求すると、エンドユーザに最も透過的なエクスペリエンスを提供するために、一連のことがバックグラウンドで行われます。

このプロセスは、ONTAPの構成方法によって制御されますが、一般的なコンセプトはそのまま適用されます。

  1. NASクライアントは、ONTAPストレージVMにNAS接続を行う。
  2. NAS クライアントは、ユーザー ID 情報を ONTAP に渡す。
  3. ONTAP は、NAS クライアント/ユーザーが NAS 共有へのアクセス権を持っていることを確認する。
  4. ONTAPはそのユーザーを受け取り、ONTAPがネームサービスで見つけることができる有効なユーザーにマッピングする。
  5. ONTAPは、そのユーザーを使用して、システムのファイルレベルの許可と比較します。
  6. これらのパーミッションは、ユーザーが持つアクセスレベルを制御します。

図1では、user1がSMBまたはNFSを介してONTAPストレージ仮想マシン(SVM)内の共有に認証されます。ONTAPはLDAPとActive Directoryでユーザーを見つけ、ユーザーを1:1にマッピングします。それが終わると、ユーザーはuser1として検証され、user1のアクセスを取得します。 この例では、自分のフォルダに対するフルコントロール、user2のフォルダに対する読み取りアクセス、HRフォルダに対するアクセス権を取得します。これはすべて、ファイルシステムで指定されたACLに基づいています。

Multiprotocol NAS in NetApp ONTAP Overview and Best Practices P.7 | TR-4887 | NetApp

Multiprotocol NAS basic operations.

セキュリティスタイルとネームマッピングの方向性のまとめは以下の通りです。

プロトコル セキュリティスタイル ネームマッピングの方向 適用される権限
CIFS/SMB UNIX WindowsからUNIX UNIX
(モードビットとNFSv4.x ACL)
CIFS/SMB NTFS WindowsからUNIX NTFS ACL
(共有にアクセスするWindows SIDに基づく)
CIFS/SMB MIXED WindowsからUNIX 有効なセキュリティスタイルによる
NFSv3 UNIX なし UNIX
(モードビットとNFSv4.x ACL)
NFSv4 UNIX 数値IDからUNIXユーザー名 UNIX
(モードビットとNFSv4.x ACL)
NFS NTFS UNIXからWindows NTFS ACL
(マッピングされたWindowsユーザーのSIDに基づく)
NFS MIXED 有効なセキュリティスタイルによる 有効なセキュリティスタイルによる

参考 : Multiprotocol NAS in NetApp ONTAP Overview and Best Practices P.27 | TR-4887 | NetApp

検証環境

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

マルチプロトコルの検証環境構成図

AD DCからSMBで、Amazon Linux 2のEC2インスタンスからNFSでFSx for ONTAP上のファイルにアクセスします。IDプロバイダーはADを使用します。

また、ファイルのアクセス制御方法はNTFS ACLを使用したいので、ボリュームのセキュリティスタイルはNTFSで、ネームマッピングの方向はUNIXからWindowsにします。

AD DCについては以下記事の検証で使用したものを流用します。

FSx for ONTAPファイルシステム、SVM、ボリュームも作成済みです。SVMとボリュームの設定は以下の通りです。

# SVM
$ aws fsx describe-storage-virtual-machines 
{
    "StorageVirtualMachines": [
        {
            "ActiveDirectoryConfiguration": {
                "NetBiosName": "SVM",
                "SelfManagedActiveDirectoryConfiguration": {
                    "DomainName": "corp.non-97.net",
                    "OrganizationalUnitDistinguishedName": "OU=FSxForONTAP,DC=corp,DC=non-97,DC=net",
                    "UserName": "FSxServiceAccount",
                    "DnsIps": [
                        "10.0.1.10"
                    ]
                }
            },
            "CreationTime": "2022-11-07T04:41:27.292000+00:00",
            "Endpoints": {
                "Iscsi": {
                    "DNSName": "iscsi.svm-0f4b6a2594cb63bca.fs-077661cf86cfc0f8d.fsx.us-east-1.amazonaws.com",
                    "IpAddresses": [
                        "10.0.1.88",
                        "10.0.1.104"
                    ]
                },
                "Management": {
                    "DNSName": "svm-0f4b6a2594cb63bca.fs-077661cf86cfc0f8d.fsx.us-east-1.amazonaws.com",
                    "IpAddresses": [
                        "10.0.1.84"
                    ]
                },
                "Nfs": {
                    "DNSName": "svm-0f4b6a2594cb63bca.fs-077661cf86cfc0f8d.fsx.us-east-1.amazonaws.com",
                    "IpAddresses": [
                        "10.0.1.84"
                    ]
                },
                "Smb": {
                    "DNSName": "SVM.corp.non-97.net",
                    "IpAddresses": [
                        "10.0.1.84"
                    ]
                }
            },
            "FileSystemId": "fs-077661cf86cfc0f8d",
            "Lifecycle": "CREATED",
            "Name": "svm",
            "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:storage-virtual-machine/fs-077661cf86cfc0f8d/svm-0f4b6a2594cb63bca",
            "StorageVirtualMachineId": "svm-0f4b6a2594cb63bca",
            "Subtype": "DEFAULT",
            "UUID": "7ef493ac-5e56-11ed-af09-6777b496f57e"
        }
    ]
}

# ボリューム
$ aws fsx describe-volumes 
{
    "Volumes": [
        {
            "CreationTime": "2022-11-07T04:42:08+00:00",
            "FileSystemId": "fs-077661cf86cfc0f8d",
            "Lifecycle": "CREATED",
            "Name": "svm_root",
            "OntapConfiguration": {
                "FlexCacheEndpointType": "NONE",
                "JunctionPath": "/",
                "SecurityStyle": "NTFS",
                "SizeInMegabytes": 1024,
                "StorageEfficiencyEnabled": false,
                "StorageVirtualMachineId": "svm-0f4b6a2594cb63bca",
                "StorageVirtualMachineRoot": true,
                "TieringPolicy": {
                    "Name": "NONE"
                },
                "UUID": "89583b2c-5e56-11ed-af09-6777b496f57e",
                "OntapVolumeType": "RW"
            },
            "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-077661cf86cfc0f8d/fsvol-076db347c8d1942ef",
            "VolumeId": "fsvol-076db347c8d1942ef",
            "VolumeType": "ONTAP"
        },
        {
            "CreationTime": "2022-11-07T04:47:45.453000+00:00",
            "FileSystemId": "fs-077661cf86cfc0f8d",
            "Lifecycle": "CREATED",
            "Name": "vol1",
            "OntapConfiguration": {
                "FlexCacheEndpointType": "NONE",
                "JunctionPath": "/vol1",
                "SizeInMegabytes": 1024,
                "StorageEfficiencyEnabled": true,
                "StorageVirtualMachineId": "svm-0f4b6a2594cb63bca",
                "StorageVirtualMachineRoot": false,
                "TieringPolicy": {
                    "Name": "NONE"
                },
                "UUID": "5a8dece8-5e57-11ed-af09-6777b496f57e",
                "OntapVolumeType": "RW"
            },
            "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-077661cf86cfc0f8d/fsvol-0fee37309cc3318f1",
            "VolumeId": "fsvol-0fee37309cc3318f1",
            "VolumeType": "ONTAP"
        }
    ]
}

先述の通り、ボリュームのセキュリティスタイルはNTFSです。

FsxId077661cf86cfc0f8d::> volume show -fields security-style
vserver volume   security-style
------- -------- --------------
svm     svm_root ntfs
svm     vol1     ntfs
2 entries were displayed.

CIFSサーバーはドメインに参加しており、DNSの設定されています。

# CIFSサーバーがドメインに参加していることを確認
FsxId077661cf86cfc0f8d::> cifs show -instance

                                          Vserver: svm
                         CIFS Server NetBIOS Name: SVM
                    NetBIOS Domain/Workgroup Name: CORP
                      Fully Qualified Domain Name: CORP.NON-97.NET
                              Organizational Unit: OU=FSxForONTAP,DC=corp,DC=non-97,DC=net
Default Site Used by LIFs Without Site Membership:
                                   Workgroup Name: -
                             Authentication Style: domain
                CIFS Server Administrative Status: up
                          CIFS Server Description:
                          List of NetBIOS Aliases: -

# DNSの設定確認
FsxId077661cf86cfc0f8d::> name-service dns show
  (vserver services name-service dns show)
                                                    Name
Vserver         Domains                             Servers
--------------- ----------------------------------- ----------------
svm             corp.non-97.net                     10.0.1.10

ドメインユーザーの作成

それでは、CIFSファイル共有にNFSクライアントからアクセスするときに使用するドメインユーザーを作成します。

# パラメーターの指定
> $userName = 'user01'
> $uidNumber = '5001'
> $gidNumber = '6001'

# ドメインユーザーの作成
> New-ADUser `
  -Name "$userName" `
  -UserPrincipalName "$userName@corp.non-97.net" `
  -Accountpassword (Read-Host -AsSecureString "AccountPassword") `
  -Path "CN=Users,DC=corp,DC=non-97,DC=net" `
  -PasswordNeverExpires $True `
  -OtherAttributes `
    @{'uid'="$userName"; `
      'uidNumber'="$uidNumber"; `
      'gidNumber'="$gidNumber"} `
  -Enabled $True
AccountPassword: ********************************

# ユーザーが作成されたことを確認
> Get-ADUser -Filter 'Name -eq "user01"' -SearchBase "CN=Users,DC=corp,DC=non-97,DC=net"


DistinguishedName : CN=user01,CN=Users,DC=corp,DC=non-97,DC=net
Enabled           : True
GivenName         :
Name              : user01
ObjectClass       : user
ObjectGUID        : 0b1f6505-46bf-468c-85a5-fc075420699c
SamAccountName    : user01
SID               : S-1-5-21-38571244-2121234638-1230449559-1114
Surname           :
UserPrincipalName : user01@corp.non-97.net

Amazon Linux 2のEC2インスタンスからNFSでアクセスするときにマッピングするUIDとGIDを指定しています。各IDは5000以降を指定することが推奨されているようなので、UIDは5001、GIDは6001を指定しました。

予約範囲は今後増える可能性があるため、新規ユーザーおよびグループには、5000 以降の ID を割り当てることを推奨します。

18.2. 予約ユーザーおよびグループ ID の設定 Red Hat Enterprise Linux 9 | Red Hat Customer Portal

今回はGIDが6001のセキュリティグループおよび、Linuxのローカルグループを作成していないので、必要があれば作成してください。

また、ログインシェル(loginshell)やホームディレクトリ(unixHomeDirectory)はSSSDの設定ファイル(/etc/sssd/sssd.conf)で設定されているので、デフォルトで良ければ指定は不要です。

ネームマッピングの設定

次にFSx for ONTAPでネームマッピングの設定をします。

まず、name-service ldap client createでLDAPクライアントの設定を作成します。

# LDAPクライアントの設定が存在しないことを確認
FsxId077661cf86cfc0f8d::> name-service ldap client show
  (vserver services name-service ldap client show)
This table is currently empty.

# LDAPクライアントの設定を作成
# corp.non-97.net の CN=Users,DC=corp,DC=non-97,DC=net 配下を参照する
FsxId077661cf86cfc0f8d::> name-service ldap client create -vserver svm -client-config corp.non-97.net -ad-domain corp.non-97.net -base-dn "CN=Users,DC=corp,DC=non-97,DC=net" -schema AD-IDMU
  (vserver services name-service ldap client create)

# LDAPクライアントの設定が作成されたことを確認
FsxId077661cf86cfc0f8d::> name-service ldap client show
  (vserver services name-service ldap client show)
        Client        LDAP            Active Directory              Minimum
Vserver Configuration Servers         Domain            Schema      Bind Level
------- ------------- --------------- ----------------- ----------- ----------
svm     corp.non-97.net               corp.non-97.net   AD-IDMU     sasl
                      -
# LDAPクライアントの設定の詳細を確認
FsxId077661cf86cfc0f8d::> name-service ldap client show -instance
  (vserver services name-service ldap client show)

                                  Vserver: svm
                Client Configuration Name: corp.non-97.net
                         LDAP Server List: -
            (DEPRECATED)-LDAP Server List: -
                  Active Directory Domain: corp.non-97.net
       Preferred Active Directory Servers: -
Bind Using the Vserver's CIFS Credentials: true
                          Schema Template: AD-IDMU
                         LDAP Server Port: 389
                      Query Timeout (sec): 3
        Minimum Bind Authentication Level: sasl
                           Bind DN (User): -
                                  Base DN: CN=Users,DC=corp,DC=non-97,DC=net
                        Base Search Scope: subtree
               Vserver Owns Configuration: true
      Use start-tls Over LDAP Connections: false
                  Client Session Security: none
                    LDAP Referral Chasing: false
                         Is LDAPS Enabled: false
                      Try Channel Binding: true

参照先のADの機能レベルはWindows Server 2016なので、スキーマはAD-IDMUにしました。

環境で使用する LDAP スキーマが ONTAP のデフォルトと異なる場合は、 LDAP クライアント設定を作成する前に、 ONTAP 用の新しい LDAP クライアントスキーマを作成する必要があります。

ほとんどの LDAP サーバでは、 ONTAP が提供する次のデフォルトスキーマを使用できます。

  • MS-AD-BIS (ほとんどの Windows Server 2012 以降の AD サーバで推奨されるスキーマ)
  • AD-IDMU ( Windows Server 2008 、 Windows Server 2012 、およびそれ以降の AD サーバ)
  • AD-SFU ( Windows Server 2003 以前の AD サーバ)
  • RFC-2307 ( UNIX LDAP サーバ)

新しい LDAP クライアントスキーマを作成します

次に、name-service ldap createで作成したLDAPクライアントの設定をSVMに関連付けます。

# LDAPクライアントの設定が関連づいているSVMがないことを確認
FsxId077661cf86cfc0f8d::> name-service ldap show
  (vserver services name-service ldap show)
This table is currently empty.

# LDAPクライアントの設定をSVMに関連付ける
# LDAPクライアントの設定作成時に指定した client config の名前を指定
FsxId077661cf86cfc0f8d::> name-service ldap create -vserver svm -client-config corp.non-97.net
  (vserver services name-service ldap create)

Warning: "LDAP" is not present as a name service source in any of the name service databases, however, a valid LDAP configuration was found for Vserver "svm". Either configure "LDAP" as a name service source using the "vserver services name-service ns-switch" command or remove the "LDAP" configuration from the Vserver "svm" using the "vserver services name-service ldap delete" command.

# LDAPクライアントの設定がSVMに関連づいていることを確認
FsxId077661cf86cfc0f8d::> name-service ldap show
  (vserver services name-service ldap show)
               Client
Vserver        Configuration
-------------- -------------
svm            corp.non-97.net

LDAPはどのネームサービスデータベースのソースとして使用されていないと警告されましたね。案内されている通り、name-service ns-switch modifyでネームサービスのソースとしてLDAPを追加します。

# 現在のネームサービススイッチの設定を確認
FsxId077661cf86cfc0f8d::> name-service ns-switch show
  (vserver services name-service ns-switch show)
                               Source
Vserver         Database       Order
--------------- ------------   ---------
svm             hosts          files,
                               dns
svm             group          files
svm             passwd         files
svm             netgroup       files
svm             namemap        files
5 entries were displayed.

# ローカルのファイルまたはLDAPを使ってユーザーとグループの情報を取得できるように変更
FsxId077661cf86cfc0f8d::> name-service ns-switch modify -vserver svm -database passwd,group -sources files,ldap
  (vserver services name-service ns-switch modify)
2 entries were modified.

# 変更内容を確認
FsxId077661cf86cfc0f8d::> name-service ns-switch show
  (vserver services name-service ns-switch show)
                               Source
Vserver         Database       Order
--------------- ------------   ---------
svm             hosts          files,
                               dns
svm             group          files,
                               ldap
svm             passwd         files,
                               ldap
svm             netgroup       files
svm             namemap        files
5 entries were displayed.

これでONTAPがローカルのファイルまたはLDAPを使ってユーザーとグループの情報を取得できるようになりました。

ネームサービススイッチの詳細は以下NetApp公式ドキュメントが分かりやすいです。

次に、Linuxのユーザー名をNetBIOSドメイン名形式(domain\user name)で同じユーザー名に関連付けるように、ネームマッピングをname-mapping createで設定します。

# 現在のネームマッピングの確認
FsxId077661cf86cfc0f8d::> name-mapping show
  (vserver name-mapping show)
This table is currently empty.

# ネームマッピングの作成
# UNIXからWindowsへの方向のネームマッピングを作成
# 例) user を corp\user に変換
FsxId077661cf86cfc0f8d::> name-mapping create -vserver svm -direction unix-win -position 1 -pattern (.+) -replacement corp\\\1
  (vserver name-mapping modify)

# 作成したネームマッピングの確認
FsxId077661cf86cfc0f8d::> name-mapping show
  (vserver name-mapping show)

Vserver:   svm
Direction: unix-win
Position Hostname         IP Address/Mask
-------- ---------------- ----------------
1       -                 -                   Pattern: (.+)
                                          Replacement: corp\\\1

# ネームマッピングの詳細確認
FsxId077661cf86cfc0f8d::> name-mapping show -instance
  (vserver name-mapping show)

                    Vserver: svm
                  Direction: unix-win
                   Position: 1
                    Pattern: (.+)
                Replacement: corp\\\1
IP Address with Subnet Mask: -
                   Hostname: -

なお、NetBIOSドメイン名を-replacementで指定する必要があるので、corp.non-97.net\\\1のようにFQDNで指定しても、NFS接続時に正常にアクセスできないので注意してください。

CIFSファイル共有の作成

CIFSファイル共有を作成します。

LinuxはNFSでボリュームを指定してマウントできます。Windowsもc$からでなく、ボリュームを直接マウントできるようにしてあげます。

# 現在のCIFSファイル共有の確認
FsxId077661cf86cfc0f8d::> cifs share show
Vserver        Share         Path              Properties Comment  ACL
-------------- ------------- ----------------- ---------- -------- -----------
svm            c$            /                 oplocks    -        BUILTIN\Administrators / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions
svm            ipc$          /                 browsable  -        -
2 entries were displayed.

# /vol1 のCIFSファイル共有を作成
FsxId077661cf86cfc0f8d::> cifs share create -share-name vol1-share -path /vol1 -vserver svm

# CIFSファイル共有が追加されたことを確認
FsxId077661cf86cfc0f8d::> 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            vol1-share    /vol1             oplocks    -        Everyone / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions
3 entries were displayed.

Amazon Linux 2のEC2インスタンスのドメイン参加

必要なパッケージのインストール

FSx for ONTAP側の設定が完了したので、NFSクライアントとなるAmazon Linux 2のEC2インスタンスをドメイン参加させて、ドメインユーザーでFSx for ONTAPのボリュームをマウントできることを確認します。

Amazon Linux 2のEC2インスタンスのドメイン参加は以下AWS公式ドキュメントを参考に行います。

まず、インストールされているパッケージをアップデートします。

$ sudo yum update -y
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Resolving Dependencies
--> Running transaction check
.
.
(中略)
.
.
Installed:
  kernel.x86_64 0:5.10.147-133.644.amzn2

Updated:
  cloud-init.noarch 0:19.3-46.amzn2            ec2-net-utils.noarch 0:1.7.2-1.amzn2            glibc.x86_64 0:2.26-61.amzn2                   glibc-all-langpacks.x86_64 0:2.26-61.amzn2    glibc-common.x86_64 0:2.26-61.amzn2
  glibc-locale-source.x86_64 0:2.26-61.amzn2   glibc-minimal-langpack.x86_64 0:2.26-61.amzn2   kernel-tools.x86_64 0:5.10.147-133.644.amzn2   libcrypt.x86_64 0:2.26-61.amzn2               tzdata.noarch 0:2022e-1.amzn2.0.1
  vim-common.x86_64 2:9.0.475-1.amzn2.0.1      vim-data.noarch 2:9.0.475-1.amzn2.0.1           vim-enhanced.x86_64 2:9.0.475-1.amzn2.0.1      vim-filesystem.noarch 2:9.0.475-1.amzn2.0.1   vim-minimal.x86_64 2:9.0.475-1.amzn2.0.1

Complete!

カーネルといくつかのパッケージがアップデートされました。

次にSSSDなど必要なパッケージをインストールします。

SSSDの説明やLinuxのドメイン参加の仕組みは以下Red Hatの公式ドキュメントが参考になります。

$ sudo yum install sssd realmd krb5-workstation samba-common-tools -y
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Resolving Dependencies
--> Running transaction check
.
.
(中略)
.
.
Dependencies Resolved

========================================================================================================================================================================================================================================
 Package                                                     Arch                                            Version                                                          Repository                                           Size
========================================================================================================================================================================================================================================
Installing:
 krb5-workstation                                            x86_64                                          1.15.1-37.amzn2.2.4                                              amzn2-core                                          816 k
 realmd                                                      x86_64                                          0.16.1-9.amzn2.0.1                                               amzn2-core                                          208 k
 samba-common-tools                                          x86_64                                          4.10.16-18.amzn2.0.1                                             amzn2-core                                          463 k
 sssd                                                        x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          149 k
Installing for dependencies:
 avahi-libs                                                  x86_64                                          0.6.31-20.amzn2                                                  amzn2-core                                           61 k
 c-ares                                                      x86_64                                          1.10.0-3.amzn2.0.2                                               amzn2-core                                           78 k
 cups-libs                                                   x86_64                                          1:1.6.3-51.amzn2                                                 amzn2-core                                          356 k
 cyrus-sasl-gssapi                                           x86_64                                          2.1.26-24.amzn2                                                  amzn2-core                                           42 k
 gnutls                                                      x86_64                                          3.3.29-9.amzn2.0.1                                               amzn2-core                                          661 k
 http-parser                                                 x86_64                                          2.9.4-6.amzn2                                                    amzn2-core                                           37 k
 libdhash                                                    x86_64                                          0.5.0-29.amzn2                                                   amzn2-core                                           28 k
 libipa_hbac                                                 x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          157 k
 libkadm5                                                    x86_64                                          1.15.1-37.amzn2.2.4                                              amzn2-core                                          179 k
 libldb                                                      x86_64                                          1.5.4-2.amzn2                                                    amzn2-core                                          147 k
 libsmbclient                                                x86_64                                          4.10.16-18.amzn2.0.1                                             amzn2-core                                          146 k
 libsss_autofs                                               x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          159 k
 libsss_certmap                                              x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          190 k
 libsss_sudo                                                 x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          157 k
 libtalloc                                                   x86_64                                          2.1.16-1.amzn2                                                   amzn2-core                                           42 k
 libtdb                                                      x86_64                                          1.3.18-1.amzn2                                                   amzn2-core                                           48 k
 libtevent                                                   x86_64                                          0.9.39-1.amzn2                                                   amzn2-core                                           40 k
 libwbclient                                                 x86_64                                          4.10.16-18.amzn2.0.1                                             amzn2-core                                          116 k
 mozjs17                                                     x86_64                                          17.0.0-20.amzn2.0.1                                              amzn2-core                                          1.4 M
 oddjob                                                      x86_64                                          0.31.5-4.amzn2.0.1                                               amzn2-core                                           71 k
 oddjob-mkhomedir                                            x86_64                                          0.31.5-4.amzn2.0.1                                               amzn2-core                                           40 k
 polkit                                                      x86_64                                          0.112-26.amzn2.1                                                 amzn2-core                                          170 k
 polkit-pkla-compat                                          x86_64                                          0.1-4.amzn2.0.2                                                  amzn2-core                                           39 k
 pyldb                                                       x86_64                                          1.5.4-2.amzn2                                                    amzn2-core                                           49 k
 pytalloc                                                    x86_64                                          2.1.16-1.amzn2                                                   amzn2-core                                           18 k
 python-sssdconfig                                           noarch                                          1.16.5-10.amzn2.10                                               amzn2-core                                          180 k
 python-tdb                                                  x86_64                                          1.3.18-1.amzn2                                                   amzn2-core                                           20 k
 samba-client-libs                                           x86_64                                          4.10.16-18.amzn2.0.1                                             amzn2-core                                          4.9 M
 samba-common                                                noarch                                          4.10.16-18.amzn2.0.1                                             amzn2-core                                          216 k
 samba-common-libs                                           x86_64                                          4.10.16-18.amzn2.0.1                                             amzn2-core                                          182 k
 samba-libs                                                  x86_64                                          4.10.16-18.amzn2.0.1                                             amzn2-core                                          269 k
 sssd-ad                                                     x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          305 k
 sssd-common                                                 x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          1.5 M
 sssd-common-pac                                             x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          223 k
 sssd-ipa                                                    x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          387 k
 sssd-krb5                                                   x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          191 k
 sssd-krb5-common                                            x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          226 k
 sssd-ldap                                                   x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          285 k
 sssd-proxy                                                  x86_64                                          1.16.5-10.amzn2.10                                               amzn2-core                                          185 k
 trousers                                                    x86_64                                          0.3.14-2.amzn2.0.2                                               amzn2-core                                          294 k

Transaction Summary
========================================================================================================================================================================================================================================
Install  4 Packages (+40 Dependent packages)

Total download size: 15 M
Installed size: 41 M
.
.
(中略)
.
.
Installed:
  krb5-workstation.x86_64 0:1.15.1-37.amzn2.2.4                  realmd.x86_64 0:0.16.1-9.amzn2.0.1                  samba-common-tools.x86_64 0:4.10.16-18.amzn2.0.1                  sssd.x86_64 0:1.16.5-10.amzn2.10

Dependency Installed:
  avahi-libs.x86_64 0:0.6.31-20.amzn2                     c-ares.x86_64 0:1.10.0-3.amzn2.0.2                         cups-libs.x86_64 1:1.6.3-51.amzn2                      cyrus-sasl-gssapi.x86_64 0:2.1.26-24.amzn2
  gnutls.x86_64 0:3.3.29-9.amzn2.0.1                      http-parser.x86_64 0:2.9.4-6.amzn2                         libdhash.x86_64 0:0.5.0-29.amzn2                       libipa_hbac.x86_64 0:1.16.5-10.amzn2.10
  libkadm5.x86_64 0:1.15.1-37.amzn2.2.4                   libldb.x86_64 0:1.5.4-2.amzn2                              libsmbclient.x86_64 0:4.10.16-18.amzn2.0.1             libsss_autofs.x86_64 0:1.16.5-10.amzn2.10
  libsss_certmap.x86_64 0:1.16.5-10.amzn2.10              libsss_sudo.x86_64 0:1.16.5-10.amzn2.10                    libtalloc.x86_64 0:2.1.16-1.amzn2                      libtdb.x86_64 0:1.3.18-1.amzn2
  libtevent.x86_64 0:0.9.39-1.amzn2                       libwbclient.x86_64 0:4.10.16-18.amzn2.0.1                  mozjs17.x86_64 0:17.0.0-20.amzn2.0.1                   oddjob.x86_64 0:0.31.5-4.amzn2.0.1
  oddjob-mkhomedir.x86_64 0:0.31.5-4.amzn2.0.1            polkit.x86_64 0:0.112-26.amzn2.1                           polkit-pkla-compat.x86_64 0:0.1-4.amzn2.0.2            pyldb.x86_64 0:1.5.4-2.amzn2
  pytalloc.x86_64 0:2.1.16-1.amzn2                        python-sssdconfig.noarch 0:1.16.5-10.amzn2.10              python-tdb.x86_64 0:1.3.18-1.amzn2                     samba-client-libs.x86_64 0:4.10.16-18.amzn2.0.1
  samba-common.noarch 0:4.10.16-18.amzn2.0.1              samba-common-libs.x86_64 0:4.10.16-18.amzn2.0.1            samba-libs.x86_64 0:4.10.16-18.amzn2.0.1               sssd-ad.x86_64 0:1.16.5-10.amzn2.10
  sssd-common.x86_64 0:1.16.5-10.amzn2.10                 sssd-common-pac.x86_64 0:1.16.5-10.amzn2.10                sssd-ipa.x86_64 0:1.16.5-10.amzn2.10                   sssd-krb5.x86_64 0:1.16.5-10.amzn2.10
  sssd-krb5-common.x86_64 0:1.16.5-10.amzn2.10            sssd-ldap.x86_64 0:1.16.5-10.amzn2.10                      sssd-proxy.x86_64 0:1.16.5-10.amzn2.10                 trousers.x86_64 0:0.3.14-2.amzn2.0.2

Complete!

ドメイン参加

次に、ドメインに参加です。

realm joinでドメイン参加しようとしてみます。

$ sudo realm join -U administrator@corp.non-97.net corp.non-97.net --verbose
 * Resolving: _ldap._tcp.corp.non-97.net
 * Resolving: corp.non-97.net
 * No results: corp.non-97.net
realm: No such realm found

はい、参加したいドメインであるcorp.non-97.netが名前解決できなくて失敗しました。

DNSサーバーは以下のようにRoute 53 Resolverを向いており、Route 53 Resolver Outbound Endpointも用意していないので当然ですね。

$ cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
search ec2.internal
options timeout:2 attempts:5
nameserver 10.0.1.2

以下AWSのFAQを参考にDNSサーバーにAD DCを指定します。

# 現在のDHCPクライアントの設定確認
$ sudo cat /etc/dhcp/dhclient.conf
timeout 300;

# Enable the DHCPv6 Client FQDN Option in our DHCPv6 requests:
also request dhcp6.fqdn;

# Fill in the Client FQDN Option flags field. The EC2 DHCPv6 server
# will override our settings if they don't match what it supports, so
# the exact value here does not matter, but this is configured to
# match what it would set:
send fqdn.server-update true;
send fqdn.no-client-update false;

# DHCPクライアントの設定を変更
$ sudo vi /etc/dhcp/dhclient.conf

# 設定変更箇所を確認
$ sudo cat /etc/dhcp/dhclient.conf
timeout 300;

# Enable the DHCPv6 Client FQDN Option in our DHCPv6 requests:
also request dhcp6.fqdn;

# Fill in the Client FQDN Option flags field. The EC2 DHCPv6 server
# will override our settings if they don't match what it supports, so
# the exact value here does not matter, but this is configured to
# match what it would set:
send fqdn.server-update true;
send fqdn.no-client-update false;

supersede domain-name-servers 10.0.1.10;
supersede domain-search “corp.non-97.net”;

# OSを再起動
$ sudo systemctl reboot
Terminated

再起動後、DNSサーバーがAD DCのIPアドレスになっていることを確認します。

$ cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
search ec2.internal
nameserver 10.0.1.10

再度ドメインに参加しようとしてみます。

$ sudo realm join -U administrator@corp.non-97.net corp.non-97.net --verbose
 * Resolving: _ldap._tcp.corp.non-97.net
 * Performing LDAP DSE lookup on: 10.0.1.10
 * Successfully discovered: corp.non-97.net
Password for administrator@corp.non-97.net:
 * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
 * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.FGSIV1 -U administrator@corp.non-97.net ads join corp.non-97.net
Enter administrator@corp.non-97.net's password: (何も入力しない)
Using short domain name -- CORP
Joined 'IP-10-0-1-24' to dns domain 'corp.non-97.net'
DNS update failed: NT_STATUS_UNSUCCESSFUL
 * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.FGSIV1 -U administrator@corp.non-97.net ads keytab create
Enter administrator@corp.non-97.net's password:
 * /usr/bin/systemctl enable sssd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/sssd.service to /usr/lib/systemd/system/sssd.service.
 * /usr/bin/systemctl restart sssd.service
 * /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service
 * Successfully enrolled machine in realm

ドメインに参加できたようです。途中DNS update failed: NT_STATUS_UNSUCCESSFULとDNSの動的更新のエラーが出力されています。今回はDNSの動的更新は不要なので、このままスルーします。

ドメインに参加できたことをrealm listでも確認しておきます。

$ sudo realm list
corp.non-97.net
  type: kerberos
  realm-name: CORP.NON-97.NET
  domain-name: corp.non-97.net
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %U@corp.non-97.net
  login-policy: allow-realm-logins

ドメインユーザーがSSHできるように設定

ドメインユーザーがSSHできるように、SSHの設定を変更してパスワード認証を有効化します。

# 現在の設定を確認
$ sudo cat /etc/ssh/sshd_config
#       $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

#AuthorizedPrincipalsFile none


# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several
# problems.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

# override default of no subsystems
Subsystem sftp  /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys %u %f
AuthorizedKeysCommandUser ec2-instance-connect

# 設定を変更
$ sudo vi /etc/ssh/sshd_config

# 変更箇所を確認
$ sudo cat /etc/ssh/sshd_config
#       $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.
.
.
(中略)
.
.
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes
.
.
(中略)
.
.
AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys %u %f
AuthorizedKeysCommandUser ec2-instance-connect

# SSHのサービスを再起動
$ sudo systemctl restart sshd.service

SSHの設定変更とサービス再起動後、ドメインユーザーの認証情報で自身にSSHします。

$ ssh -l administrator@corp.non-97.net localhost
administrator@corp.non-97.net@localhost's password:
Creating home directory for administrator@corp.non-97.net.

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/

# 現在のユーザー名を確認
[administrator@corp.non-97.net@ip-10-0-1-24 ~]$ whoami
administrator@corp.non-97.net

# ログインシェルの確認
[administrator@corp.non-97.net@ip-10-0-1-24 ~]$ echo $SHELL
/bin/bash

ドメインのAdministratorユーザーで接続できました。

ドメインユーザーにsudoできるように設定

デフォルトでは以下のようにドメインのAdministratorであってもsudoできません。

[administrator@corp.non-97.net@ip-10-0-1-24 ~]$ sudo -i

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for administrator@corp.non-97.net:
Sorry, try again.
[sudo] password for administrator@corp.non-97.net:
administrator@corp.non-97.net is not in the sudoers file.  This incident will be reported.

/etc/sudoersを更新して、ドメインのAdministratorとuser01が任意の場所で、任意のユーザーで、任意のコマンドを叩けられるようにしておきます。

# sudo できるユーザーを編集
$ sudo visudo

# 設定内容を確認
$ sudo tail /etc/sudoers
## Allows members of the users group to shutdown this system
# %users  localhost=/sbin/shutdown -h now

## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d


administrator@corp.non-97.net ALL=(ALL:ALL) ALL
user01@corp.non-97.net ALL=(ALL:ALL) ALL

設定後、ドメインユーザーがsudo -iでrootユーザーにスイッチできることを確認します。

$ ssh -l administrator@corp.non-97.net localhost
administrator@corp.non-97.net@localhost's password:
Last login: Mon Nov  7 06:02:58 2022 from localhost

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/

# rootユーザーにスイッチ
[administrator@corp.non-97.net@ip-10-0-1-24 ~]$ sudo -i
[sudo] password for administrator@corp.non-97.net:

# rootユーザーであることを確認
[root@ip-10-0-1-24 ~]# whoami
root

ネームマッピングの設定

ここで、Amazon Linux 2のEC2インスタンス上からドメインユーザーのUIDとGIDを確認してみましょう。

# ドメインのAdministratorのID
$ id administrator@corp.non-97.net
uid=1573000500(administrator@corp.non-97.net) gid=1573000513(domain users@corp.non-97.net) groups=1573000513(domain users@corp.non-97.net),1573000519(enterprise admins@corp.non-97.net),1573000520(group policy creator owners@corp.non-97.net),1573000512(domain admins@corp.non-97.net),1573000572(denied rodc password replication group@corp.non-97.net),1573000518(schema admins@corp.non-97.net)

# ドメインのuser01のID
$ id user01@corp.non-97.net
uid=1573001114(user01@corp.non-97.net) gid=1573000513(domain users@corp.non-97.net) groups=1573000513(domain users@corp.non-97.net)

ドメインのuser01のUID、GID共にドメインユーザー作成時に指定した値ではないですね。

この状態でFSx for ONTAPのボリュームをマウントして、マウントポイント配下を確認しようとしても権限不足で失敗します。

# マウントポイントの作成
$ sudo mkdir /mnt/fsx

# FSx for ONTAPのボリュームをマウント
$ sudo mount -t nfs svm-0f4b6a2594cb63bca.fs-077661cf86cfc0f8d.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsx

# マウントされていることを確認
$ df -ht nfs
Filesystem                                                                    Size  Used Avail Use% Mounted on
svm-0f4b6a2594cb63bca.fs-077661cf86cfc0f8d.fsx.us-east-1.amazonaws.com:/vol1  973M  320K  973M   1% /mnt/fsx

# ドメインのuser01で自身にSSH
$ ssh -l user01@corp.non-97.net localhost
user01@corp.non-97.net@localhost\'s password:

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/

# ドメインのuser01であることを確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ whoami
user01@corp.non-97.net

# 現在のディレクトリを確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ pwd
/home/user01@corp.non-97.net

# ログインシェルの確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ echo $SHELL
/bin/bash

# マウントポイント配下を確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ ls -l /mnt/fsx/
ls: cannot open directory /mnt/fsx/: Permission denied

rootユーザーでも拒否されます。

# rootユーザーにスイッチ
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ sudo -i

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for user01@corp.non-97.net:

# rootユーザーであることを確認
[root@ip-10-0-1-24 ~]# whoami
root

# rootのidを確認
[root@ip-10-0-1-24 ~]# id
uid=0(root) gid=0(root) groups=0(root)

# マウントポイント配下を確認
[root@ip-10-0-1-24 ~]# ls -l /mnt/fsx/
ls: cannot open directory /mnt/fsx/: Permission denied

# マウントポイントの情報を確認
[root@ip-10-0-1-24 ~]# ls -ld /mnt/fsx/
drwxrwxrwx 2 root root 4096 Nov  7 04:47 /mnt/fsx/

# 書き込みしようとしても拒否される
[root@ip-10-0-1-24 ~]# echo "/mnt/fsx/root-user-file" > /mnt/fsx/root-user-file
-bash: /mnt/fsx/root-user-file: Permission denied

これはSSSDのデフォルトの設定だと、ADのobjectSIDからUIDとGIDの値を自動でマッピングするためです。

By default, the AD provider will map UID and GID values from the objectSID parameter in Active Directory. For details on this, see the "ID MAPPING" section below. If you want to disable ID mapping and instead rely on POSIX attributes defined in Active Directory, you should set

ldap_id_mapping = False

. . (中略) . .

Id Mapping

The ID-mapping feature allows SSSD to act as a client of Active Directory without requiring administrators to extend user attributes to support POSIX attributes for user and group identifiers.

NOTE: When ID-mapping is enabled, the uidNumber and gidNumber attributes are ignored. This is to avoid the possibility of conflicts between automatically-assigned and manually-assigned values. If you need to use manually-assigned values, ALL values must be manually-assigned.

sssd-ad(5): config file for SSSD - Linux man page

自分がドメインユーザーに設定したUID、GIDを使用するように/etc/sssd/sssd.confldap_id_mappingfalseに変更します。

# 現在の設定を確認
$ sudo cat /etc/sssd/sssd.conf

[sssd]
domains = corp.non-97.net
config_file_version = 2
services = nss, pam

[domain/corp.non-97.net]
ad_domain = corp.non-97.net
krb5_realm = CORP.NON-97.NET
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad

# ldap_id_mapping を false に変更
$ sudo sed -i 's/ldap_id_mapping = True/ldap_id_mapping = False/I' /etc/sssd/sssd.conf

# 変更後の設定を確認
$ sudo cat /etc/sssd/sssd.conf

[sssd]
domains = corp.non-97.net
config_file_version = 2
services = nss, pam

[domain/corp.non-97.net]
ad_domain = corp.non-97.net
krb5_realm = CORP.NON-97.NET
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad

# キャッシュをクリアし、すべてのレコードを更新
# sudo ルールを除くキャッシュされたエントリーをすべて無効にする
$ sudo sss_cache -E

# SSSDのサービス再起動
$ sudo systemctl restart sssd.service

設定変更後、ドメインのuser01でSSHします。

$ ssh -l user01@corp.non-97.net localhost
user01@corp.non-97.net@localhost's password:

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
/usr/bin/id: cannot find name for group ID 6001

# UID、GIDが自身が設定した値になったことを確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ id
uid=5001(user01@corp.non-97.net) gid=6001 groups=6001,1573000513

# ドメインのuser01であることを確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ whoami
user01@corp.non-97.net

UID、GIDが自身が設定した値になったことを確認できました。なお、AD上にもAmazon Linux 2のEC2インスタンスのローカル上にもGIDが6001のグループはないので、そんなものはないと怒られていますね。

この状態でマウントポイント配下を確認をしてみます。

# マウントポイント配下を確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ ls -l /mnt/fsx/
total 0

# マウントポイントの情報を確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ ls -ld /mnt/fsx/
drwxrwxrwx 2 root root 4096 Nov  7 06:50 /mnt/fsx/

拒否されずに表示できましたね。

なお、rootユーザーでは引き続きマウントポイント配下を確認することはできません。

# rootユーザーにスイッチ
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ sudo -i
[sudo] password for user01@corp.non-97.net:

# rootユーザーのIDを確認
[root@ip-10-0-1-24 ~]# id
uid=0(root) gid=0(root) groups=0(root)

# マウントポイントの情報を確認
[root@ip-10-0-1-24 ~]# ls -ld /mnt/fsx/
drwxrwxrwx 2 root root 4096 Nov  7 06:50 /mnt/fsx/

# マウントポイント配下を確認
[root@ip-10-0-1-24 ~]# ls -l /mnt/fsx/
ls: cannot open directory /mnt/fsx/: Permission denied

また、ドメインのAdministratorにはUIDとGIDを指定していなかったため、SSHしようとするとエラーになります。

# ドメインのAdministratorでSSH
$ ssh -l administrator@corp.non-97.net localhost
administrator@corp.non-97.net@localhost's password:
Permission denied, please try again.

# ドメインのAdministratorのUIDとGIDを確認
$ id administrator@corp.non-97.net
id: administrator@corp.non-97.net: no such user

今回は行いませんが、現在ADの全ユーザーがこのEC2インスタンスにログインできます。そのため、本番運用する場合は/etc/sssd/sssd.confad_access_filterrealm permitでログインできるユーザーを制御することをオススメします。

動作確認

NFSクライアントから作成したファイルの確認

NFSクライアントからドメインユーザーの認証情報を使って、CIFSファイル共有のボリュームにアクセスできることを確認できました。

次に、NFSクライアントからファイルの追加ができることを確認します。

# ファイルの追加
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ echo user01-test > /mnt/fsx/user01-test

# ファイルが追加されたことを確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ ls -l /mnt/fsx/
total 0
-rwxrwxrwx 1 user01@corp.non-97.net 6001 12 Nov  7 06:53 user01-test

# UIDとGIDを表示
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ ls -ln /mnt/fsx/
total 0
-rwxrwxrwx 1 5001 6001 12 Nov  7 06:53 user01-test

# 追加したファイルが読み込めるか確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ cat /mnt/fsx/user01-test
user01-test

ファイルの書き込みもできましたね。書き込んだファイルの所有者とグループはuser01のUIDとGIDとなっています。

権限は777となっていますが、Everyoneでフルコントロールという訳ではありません。マウントしているボリュームのセキュリティスタイルはNTFSにしているので、NTFS ACLによってアクセス許可が行われます。

NTFS - ファイルシステムが Windows 管理者によって管理され、大多数のユーザーが SMB クライアントであり、データにアクセスするアプリケーションが Windows ユーザーをサービスアカウントとして使用する場合は、このセキュリティスタイルを選択します。ボリュームへの Windows アクセスが必要な場合は、NTFS セキュリティスタイルの使用をお勧めします。NTFS セキュリティスタイルでアクセス許可を変更できるのは Windows クライアントのみです。ファイルおよびディレクトリで使用されるアクセス許可の種類は NTFS ACL です。

FSx for ONTAP ボリュームの管理 - FSx for ONTAP

NetAppのドキュメント内にも「アプリケーションによってはACLまたはモードビットが正しいかで振る舞いが左右される」とあるため注意が必要です。

Displaying NTFS permissions from NFS clients

When using NTFS security style volumes or qtrees, NFS clients display the mode bits or NFSv4 ACLs for the object as having wide open permissions (777) by default. This can be problematic for users and storage administrators for two primary reasons:

  • Applications might depend on the ACLs or mode bits displaying properly for functionality.
  • Users who see the mode bits as open might become alarmed, which can result in support tickets and cycles spent on troubleshooting.

Even though an ACL or mode bit shows 777 in NTFS security style volumes, it does not mean that the object allows everyone full access. In ONTAP, NTFS security style volumes control access based on NTFS security and ACLs. Therefore, an NFS client must have a valid UNIX user that maps to a valid Windows user in order to access the volume at all (authentication). After the initial authentication, the mapped user is then used to determine access based on the granular NTFS ACLs.

Multiprotocol NAS in NetApp ONTAP Overview and Best Practices P.90 | TR-4887 | NetApp

次に、AD DCのZドライブにSMBでCIFSファイル共有をマウントして、作成されたファイルを確認してみます。

# CIFSファイル共有をZドライブにマウント
> net use Z: \\SVM.CORP.NON-97.NET\vol1-share
The command completed successfully.

# NFSクライアントから作成したファイルがあるか確認
> ls Z:\


    Directory: Z:\


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         11/6/2022   8:53 PM             12 user01-test


# NFSクライアントから作成したファイルの中身を確認
> cat Z:\user01-test
user01-test

NFSクライアントから作成したファイルをSMBクライアント上で確認することができました。

次に、作成したファイルの権限を変更してみましょう。

現在はEveryoneでフルコントロールになっています。

Linuxから作成したファイルのNTFSのACL

これをドメインのuser01の読み込みと実行を拒否するようにNTFSのACLを変更します。

Linuxから作成したファイルのNTFSのACLを編集

NFSクライアントからファイルの権限を確認します。

[user01@corp.non-97.net@ip-10-0-1-24 ~]$ ls -l /mnt/fsx/
total 0
-rwx-w--w- 1 user01@corp.non-97.net 6001 12 Nov  7 06:53 user01-test

グループとその他から読み込みと実行の権限が削除されました。

試しにchmod777に権限を変えようとしてみます。

[user01@corp.non-97.net@ip-10-0-1-24 ~]$ chmod 777 /mnt/fsx/user01-test
chmod: changing permissions of ‘/mnt/fsx/user01-test’: Operation not permitted

# sudoで再チャレンジ
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ sudo chmod 777 /mnt/fsx/user01-test
[sudo] password for user01@corp.non-97.net:
chmod: cannot access ‘/mnt/fsx/user01-test’: Permission denied

権限の変更に失敗しました。

権限の変更に失敗する理由もボリュームのセキュリティスタイルがNTFSであるためです。先述の通り、セキュリティスタイルがNTFSである場合はNTFS ACLを使用します。それに関係して、UNIXクライアントはNFS経由でACLを変更することはできません。

セキュリティスタイル 制限事項
UNIX - Windows クライアントはUNIX 属性にマップされる SMB を介してのみ UNIX 権限属性を設定できます (読
み取り/書き込み/実⾏のみ。特別な権限はありません)。
- NFSv4.x ACLには、GUIまたはONTAP CLI管理がありません。
- ファイルまたはフォルダーに NFSv4.x ACL がある場合、Windows GUI はそれらを表⽰できません。
NTFS - UNIX クライアントはNFS を介して属性を設定できません。
- NFS オプション-ntacl-display-permissive-permsが無効になっている場合 (デフォルトは無効)、ACL を表⽰す
ると、NFS クライアントはおおよその権限のみを表⽰します。
MIXED - Windows クライアントと UNIX クライアントの両⽅が属性を設定できます。
- 1 つのオブジェクトに適⽤できる ACL のスタイルは 1 つだけです。
- UNIX スタイルの ACL を適⽤すると、NTFS スタイルの ACL が削除されます。
- NTFS スタイルの ACL を適⽤すると、UNIX スタイルの ACL が削除されます。
- ACL の変更に最後に使⽤されたプロトコルによって、ファイルの有効なセキュリティスタイルが決まります。

抜粋 : Multiprotocol NAS in NetApp ONTAP Overview and Best Practices P.26 | TR-4887 | NetApp

そのボリュームへ主にアクセスするプロトコルや、管理したい方法でボリュームのセキュリティスタイルを決定することが大切なのが分かりますね。

その後、SMBクライアントからNTFS ACLを元に戻すと、以下のようにLinuxからも権限が元に戻ったことを確認できました。

[user01@corp.non-97.net@ip-10-0-1-24 ~]$ ls -l /mnt/fsx/
total 0
-rwxrwxrwx 1 user01@corp.non-97.net 6001 12 Nov  7 06:53 user01-test

SMBクライアントから作成したファイルの確認

最後にSMBクライアントから作成したファイルを確認してみます。

まず、FSx for ONTAPのCIFSファイル共有をマウントしているZドライブ上にメモ帳でファイル(notepad-text.txt)を作成します。その後、PowerShellからもファイルを作成します。

# ファイルの作成
> echo "text" > Z:\powershell-text.txt

# 作成したファイルの確認
> ls Z:\


    Directory: Z:\


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         11/7/2022   8:59 PM              4 notepad-text.txt
-a----         11/7/2022   8:58 PM             14 powershell-text.txt

こちらのファイルをNFSクライアントから確認してみます。

# ファイルが存在することを確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ ls -l /mnt/fsx/
total 0
-rwxrwxrwx 1 root bin  4 Nov  8 06:59 notepad-text.txt
-rwxrwxrwx 1 root bin 14 Nov  8 06:58 powershell-text.txt

# メモ帳で作成したファイルの中身を表示できるか確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ cat /mnt/fsx/notepad-text.txt
text

# PowerShellで作成したファイルの中身を表示できるか確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ cat /mnt/fsx/powershell-text.txt
��text

所有者がrootでグループがbinのファイルを確認できました。ファイルの中身も表示できていますが、PowerShellで作成したファイルは先頭が文字化けしていますね。

ファイルサイズも確かに違いそうなので、odでファイルを8進数でダンプします。

[user01@corp.non-97.net@ip-10-0-1-24 ~]$ od /mnt/fsx/notepad-text.txt
0000000 062564 072170 005015
0000006

[user01@corp.non-97.net@ip-10-0-1-24 ~]$ od /mnt/fsx/powershell-text.txt
0000000 177377 000164 000145 000170 000164 000015 000012
0000016

同じtextという文字列を保存していますが、中身は全く異なりますね。

恐らく文字コードの差だと推測します。実際に確認してみます。

# メモ帳で作成したファイルの文字コード
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ file /mnt/fsx/notepad-text.txt
/mnt/fsx/notepad-text.txt: ASCII text, with CRLF line terminators

# PowerShellで作成したファイルの文字コード
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ file /mnt/fsx/powershell-text.txt
/mnt/fsx/powershell-text.txt: Little-endian UTF-16 Unicode text, with CR line terminators

メモ帳で作成したファイルの文字コードはASCIIで、先頭が文字化けしたPowerShellで作成したファイルの文字コードはUTF-16LEでした。

調べてみると、PowerShellでOut-Fileやリダイレクトでファイルに出力したファイルはUTF-16LEのようです。

Out-Fileとリダイレクト演算子>を使用して >> UTF-16LE を作成します。これは特に異なりますSet-ContentAdd-Content。

文字エンコードについて - PowerShell | Microsoft Learn

試しにOut-fileの文字コードにUTF-8を指定してみて、文字化けするか確認してみます。

# PowerShellで文字コードにUTF-8を指定してファイルを作成
> echo "text" | Out-file -Encoding utf8 Z:\powershell-text_utf-8.txt

NFSクライアントから作成したファイルの中身を表示して、文字化けしていないか確認します。

# 文字コードがUTF-8か確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ file /mnt/fsx/powershell-text_utf-8.txt
/mnt/fsx/powershell-text_utf-8.txt: UTF-8 Unicode (with BOM) text, with CRLF line terminators

# バイナリを確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ od /mnt/fsx/powershell-text_utf-8.txt
0000000 135757 072277 074145 006564 000012
0000011

# 先頭が文字化けせずに表示できるか確認
[user01@corp.non-97.net@ip-10-0-1-24 ~]$ cat /mnt/fsx/powershell-text_utf-8.txt
text

文字化けしていないですね。やはりUTF-16LEであることが原因のようです。マルチプロトコルである場合に限りませんが文字コードには気をつける必要がありますね。

同じファイルにマルチプロトコルでアクセスできて便利

Amazon FSx for NetApp ONTAPを使って同じファイルに対してマルチプロトコルにアクセスできるように設定してみました。

マルチプロトコルでアクセスできると、異種OS間のファイルのやりとりが簡単にできるようになります。業務的にもありがたいですね。

なお、今回は検証しませんでしたがファイルロックも注意する必要があります。本番運用でマルチプロトコルでアクセスできるようにする際にはここも意識しましょう。

クライアントが NFS クライアントである場合、ロックは任意に設定します。クライアントが SMB クライアントである場合、ロックは必須となります。

NFS ファイルと SMB ファイルのロックの違いのため、 SMB アプリケーションですでに開いているファイルに NFS クライアントからアクセスすると、エラーになる場合があります。

NFS クライアントが SMB アプリケーションによってロックされたファイルにアクセスすると、次のいずれかの状態になります。

  • mixed 形式または NTFS 形式のボリューム原因では 'rm ' rmdir' ' および 'm v などのファイル操作操作を行うと 'NFS アプリケーションが失敗することがあります
  • NFS の読み取りと書き込みの処理は、 SMB の読み取り拒否および書き込み拒否のオープンモードによってそれぞれ拒否されます。
  • また、ファイルの書き込み対象となる範囲が、排他的な SMB バイトロックでロックされている場合も、 NFS の書き込みの処理はエラーになります。

UNIX セキュリティ形式のボリュームでは、 NFS のリンク解除および名前変更の処理で SMB のロック状態が無視され、ファイルへのアクセスが許可されます。UNIX セキュリティ形式のボリュームでのその他すべての NFS 処理では、 SMB のロック状態が考慮されます。

プロトコル間のファイルロックについて

ファイルロックの詳細はMultiprotocol NAS in NetApp ONTAP Overview and Best PracticesのP.33 Advanced multiprotocol concepts にも記載があるので併せてご確認ください。

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

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