![[Amazon FSx for NetApp ONTAP] マルチプロトコルで同じファイルにアクセスできるように設定してみた](https://devio2023-media.developers.io/wp-content/uploads/2022/08/amazon-fsx-for-netapp-ontap.png)
[Amazon FSx for NetApp ONTAP] マルチプロトコルで同じファイルにアクセスできるように設定してみた
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公式ブログを参考に私も試してみたので、紹介します。
いきなりまとめ
- マルチプロトコルでアクセスできるようにするためにはネームマッピングが必要
- Active Directoryで管理しているユーザーにマッピングする場合は、NFSクライアントとなるLinuxマシンをドメイン参加させる必要がある
- セキュリティスタイルで許可されていないプロトコルによるファイルやディレクトリの権限の編集はできないので注意が必要
- 文字コードやファイルロックなどにも気をつけよう
- マルチプロトコルアクセスのベストプラクティスも確認しよう
ONTAPのマルチプロトコルアクセスの仕組み
まず、ONTAPのマルチプロトコルアクセスの仕組みを確認してみます。
マルチプロトコルアクセスを支える要素は大きく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つです。
- UNIX
- NTFS
- 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:
- A NAS client makes a NAS connection to the ONTAP storage VM.
- The NAS client passes user identity information to ONTAP.
- ONTAP checks to make sure the NAS client/user has access to the NAS share.
- ONTAP takes that user and maps it to a valid user that ONTAP can find in its name services.
- ONTAP uses that user to compare against the file-level permissions in the system.
- 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の構成方法によって制御されますが、一般的なコンセプトはそのまま適用されます。
- NASクライアントは、ONTAPストレージVMにNAS接続を行う。
- NAS クライアントは、ユーザー ID 情報を ONTAP に渡す。
- ONTAP は、NAS クライアント/ユーザーが NAS 共有へのアクセス権を持っていることを確認する。
- ONTAPはそのユーザーを受け取り、ONTAPがネームサービスで見つけることができる有効なユーザーにマッピングする。
- ONTAPは、そのユーザーを使用して、システムのファイルレベルの許可と比較します。
- これらのパーミッションは、ユーザーが持つアクセスレベルを制御します。
図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
セキュリティスタイルとネームマッピングの方向性のまとめは以下の通りです。
| プロトコル | セキュリティスタイル | ネームマッピングの方向 | 適用される権限 |
|---|---|---|---|
| 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 サーバ）
次に、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.
自分がドメインユーザーに設定したUID、GIDを使用するように/etc/sssd/sssd.confのldap_id_mappingをfalseに変更します。
# 現在の設定を確認 $ 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.confのad_access_filterやrealm 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 です。
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でフルコントロールになっています。
これをドメインのuser01の読み込みと実行を拒否するように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
グループとその他から読み込みと実行の権限が削除されました。
試しにchmodで777に権限を変えようとしてみます。
[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。
試しに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)でした!
