ユーザーが NFS 経由で Azure NetApp Files ボリュームにアクセスしようとすると、要求は数値 ID で送信されます。 既定では、Azure NetApp Files では NFS ユーザーの拡張グループ メンバーシップがサポートされます (標準の 16 グループの制限を超えるため)。 その結果、Azure NetApp Files は、RPC パケットでグループ メンバーシップを渡すのではなく、その数値 ID を取得してライトウェイト ディレクトリ アクセス プロトコル (LDAP) で検索し、ユーザーのグループ メンバーシップを解決しようとします。 この動作により、その数値 ID を LDAP でユーザーに解決できない場合、検索は失敗し、アクセスは拒否されます。 この拒否は、要求元のユーザーがボリュームまたはデータ構造にアクセスする権限を持っている場合でも発生します。
Active Directory 接続で LDAP を使用してローカル NFS ユーザーを許可するオプションは、拡張グループ機能を無効にすることで、NFS 要求に対する LDAP 参照を無効にすることを目的としています。 Azure NetApp Files 内での "ローカル ユーザーの作成または管理" は提供されません。
[LDAP でローカル NFS ユーザーを許可する] オプションが有効になっている場合、数値 ID は Azure NetApp Files に渡され、LDAP 検索は行われません。 これにより、以下で説明するように、さまざまなシナリオに対してさまざまな動作が作成されます。
UNIX セキュリティ スタイル のボリュームを含む NFSv3
数値 ID をユーザー名に変換する必要はありません。 [LDAP でローカル NFS ユーザーを許可する] オプションは、ボリュームへのアクセスには影響しません。 これは、NFS クライアントでのユーザーまたはグループの所有権 (名前変換) の表示方法に影響を与える可能性があります。 たとえば、数値 ID 1001 が LDAP では user1 であるが、NFS クライアントのローカル passwd ファイルでは user2 である場合、クライアントでは、数値 ID が 1001 のときにそのファイルの所有者として "user2" が表示されます。
UNIX セキュリティ スタイルのボリュームを含む NFSv4.1
数値 ID をユーザー名に変換する必要はありません。 既定では、NFSv4.1 は認証に名前文字列 (user@CONTOSO.COM) を使用します。 ただし、Azure NetApp Files では NFSV4.1 での数値 ID の使用がサポートされています。つまり、NFSv4.1 要求は数値 ID を持つ NFS サーバーに届きます。 Azure NetApp Files ボリュームのローカル ファイルまたは LDAP などのネーム サービスに数値 ID からユーザー名への変換が存在しない場合は、数値がクライアントに表示されます。 数値 ID がユーザー名に変換される場合は、名前の文字列が使用されます。 名前の文字列が一致しない場合、クライアントはその名前を、クライアントの idmapd.conf ファイルで指定された匿名ユーザーに置き換えます。 [LDAP でローカル NFS ユーザーを許可する] オプションを有効にしても、NFSv4.1 アクセスには影響しません。 Azure NetApp Files が数値 ID をローカル NFS ユーザー データベース内のユーザー名に解決できない限り、アクセスは標準の NFSv3 動作にフォールバックします。 Azure NetApp Files には、一部のクライアントで問題になる可能性がある一連の既定の UNIX ユーザーがあり、ドメイン ID 文字列が一致しない場合は "nobody" ユーザーにスカッシュします。
- ローカル ユーザーには、root (0)、pcuser (65534)、nobody (65535) が含まれます。
- ローカル グループには、root (0)、daemon (1)、pcuser (65534)、nobody (65535) が含まれます。
最も一般的には、NFSv4.1 ドメイン ID が正しく構成されていない場合、NFSv4.1 クライアント マウントでルートが正しく表示されないことがあります。 NFSv4.1 ID ドメインの詳細については、「Azure NetApp Files の NFSv4.1 ID ドメインの構成」を参照してください。
NFSv4.1 ACL は、名前文字列または数値 ID を使用して構成できます。 数値 ID を使用する場合、名前変換は必要ありません。 名前文字列を使用する場合は、適切な ACL 解決のために名前変換が必要になります。 NFSv4.1 ACL を使用する場合、[LDAP でローカル NFS ユーザーを許可する] を有効にすると、ACL の構成によっては、NFSv4.1 ACL の動作が正しくなくなる可能性があります。
デュアル プロトコル構成の NTFS セキュリティ スタイル ボリュームを使用した NFS (NFSv3 および NFSv4.1)
UNIX セキュリティ スタイルのボリュームでは、UNIX スタイルのパーミッション（モード ビットと NFSv4.1 ACL）が利用されます。 これらの種類のボリュームの場合、NFS では、上記のシナリオに応じて、数値 ID または名前文字列を利用する UNIX スタイルの認証のみが利用されます。
ただし、NTFS セキュリティ スタイルのボリュームでは、NTFS スタイルのアクセス許可を使用します。 これらのアクセス許可は、Windows ユーザーとグループを使用して割り当てられます。 NFS ユーザーが NTFS スタイルのアクセス許可を持つボリュームにアクセスしようとすると、適切なアクセス制御を確保するために UNIX から Windows への名前マッピングが行われる必要があります。 このシナリオでは、NFS 数値 ID は引き続き Azure NetApp Files NFS ボリュームに渡されますが、初期認証用に Windows ユーザー名にマップできるように、数値 ID を UNIX ユーザー名に変換する必要があります。 たとえば、数値 ID 1001 が、Windows ユーザー "user1" へのアクセスを許可する NTFS セキュリティ スタイルのアクセス許可を持つ NFS マウントへのアクセスを試行する場合、LDAP で 1001 を "user1" ユーザー名に解決して、期待されるアクセス権を取得する必要があります。 数値 ID が "1001" のユーザーが LDAP に存在しない場合、または LDAP が正しく構成されていない場合、UNIX から Windows への名前マッピングが 1001@contoso.com で試行を完了します。 ほとんどの場合、その名前のユーザーは存在しません。 その結果、認証が失敗し、アクセスが拒否されます。 同様に、数値 ID 1001 が間違ったユーザー名 (user2 など) に解決された場合、NFS 要求は間違った Windows ユーザーにマップされます (このシナリオでは、user1 に user2 へのアクセスが付与されています)。
[LDAP でローカル NFS ユーザーを許可する] を有効にすると、数値 ID からユーザー名への LDAP 変換がすべて無効になります。 このアクションにより、NTFS セキュリティ スタイルのボリュームへのアクセスが実質的に中断されます。 そのため、NTFS セキュリティ スタイルのボリュームでは、このオプションを使用しないことをお勧めします。