マルチプロトコル環境での名前マッピングについて

最後の更新
PDFとして保存

Views:: 1,269

Visibility:: Public

Votes:: 5

Category:: ontap-9

Specialty:: nas

Last Updated:

環境

ONTAP 9
NAS

回答

UNIXセキュリティ形式のリソースにアクセスするNFSクライアントでは、ネームマッピングはどのように機能しますか。

クライアントは、NFS処理のRPCヘッダーでUIDとGIDを送信します。
Filerは、NFS処理のRPCヘッダーで送信されたUIDおよびGIDに基づいてアクセスを許可または拒否します。

注: このプロセス中に行われるユーザーマッピングはありません。ONTAPクライアントがUNIXセキュリティ形式のリソースに対して処理を実行するために、受信ユーザをWindowsユーザにマッピングする必要はありません。

NFSクライアントがNTFSセキュリティ形式のリソースにアクセスしている場合、ネームマッピングはどのように機能しますか？

クライアントは、NFS処理のRPCヘッダーでUIDとGIDを送信します。
Filerは、「passwd」および「group」に対してns-switch（ネームサービス・スイッチ）で定義されているソースを使用して、UIDおよびGIDをそれぞれの名前に解決しようとします。
- ns-switch.confで定義されているソースを確認するには、次のコマンドを使用します（指定可能な値はfiles/ldap/nisです）。
  - Cluster01::> vserver services name-service ns-switch show -vserver SVM01
- ネームサービスにローカルの「files」を使用する場合は、SVMでユーザごとにローカルのUNIXユーザを作成する必要があります。
  - Cluster01::> vserver services unix-user create -user tsmith -id 4219 -primary-gid 100 -full-name "Tom Smith" -vserver SVM01
Filerは次に、解決された名前を有効なWindowsユーザに次の順序でマッピングしようとします。

明示的なname-mapping-filerは、定義されている明示的なネームマッピングルールを参照し、アクセスしようとしているUNIXユーザとFiler上に存在するすべての「unix-win」ルールを照合します。

明示的なネームマッピングルールを表示するには：
Cluster01::> vserver name-mapping show -vserver SVM01 -direction unix-win

ルールが一致した場合、Filerは、マッピングされたWindowsユーザをActive Directoryで検索し、そのユーザのクレデンシャルを取得しようとします。Windows名がグループの場合、このエラーはエラーであり、デフォルトユーザが設定されている場合は無視されます。

暗黙的なネームマッピング-明示的なルールが一致しない場合、FilerはUNIXユーザをWindowsユーザに暗黙的にマッピングしようとします。Filerは、ローカルCIFSユーザの一致を確認し、一致するものがない場合は次にADで確認します。

例： FilerはUNIXユーザ「User01」をWindowsユーザ「User01」にマッピングしようとします。
この場合も、FilerはActive DirectoryでマッピングされたWindowsユーザを検索し、そのユーザのクレデンシャルを取得しようとします。

デフォルトのWindowsユーザ-上記の両方の方法でエラーが発生した場合（たとえば、 FilerがマッピングされたWindowsユーザのクレデンシャルを取得できない場合）、FilerはUNIXユーザをNFSサーバ設定で定義された「デフォルトのWindowsユーザ」にマッピングします。

NFSサーバの設定を表示するには、次の手順を実行します。
Cluster01::> vserver nfs show -vserver SVM01 -fields default-win-user
注：このオプションはデフォルトでは空白です。

Filerは、Active Directoryから取得されたWindowsクレデンシャルに基づいて、UNIXユーザへのアクセスを許可または拒否します。

注：リソースがNTFSセキュリティ形式であるため、Windowsクレデンシャルでアクセスが許可または拒否されます。

CIFSクライアントがUNIXセキュリティ形式のリソースにアクセスする場合、ネームマッピングはどのように機能しますか。

ユーザはドメインに対してすでに認証されているため、Filerは、新しく作成されるCIFSセッションごとにユーザのクレデンシャルを作成する必要があります。
Filerは、次の順序でWindowsユーザをUNIXユーザにマッピングしようとします。

明示的なname-mapping-filerは、定義された明示的なネームマッピングルールを参照し、アクセスしようとしているWindowsユーザとFiler上に存在するすべての「win-unix」ルールを照合します。

明示的なネームマッピングルールを表示するには：
Cluster01::> vserver name-mapping show -vserver SVM01 -direction win-unix
ルールが一致した場合、Filerはns-switchで定義されたソースを介して、マッピングされたUNIXユーザのUIDとGIDの検索を試みます。

暗黙的なネームマッピング-明示的なルールが一致しない場合、FilerはUNIXユーザを暗黙的にWindowsユーザにマッピングしようとします。

例： Filerは、Windowsユーザ「DOMAIN\user01」
をUNIXユーザ「User01」に再度マッピングしようとします。Filerは、ns-switchで定義されたソースを介してUNIXユーザのUIDとGIDを検索しようとします。

[Default UNIX User]：上記の両方の方法でエラーが発生した場合（FilerがマッピングされたUNIXユーザのUIDとGIDを取得できない場合など）、FilerはWindowsユーザをCIFSサーバ・オプションで定義されている「Default UNIX User」にマッピングします。

CIFSサーバオプションを表示するには、次の手順を実行します。
Cluster01::> vserver cifs options show -vserver SVM01 -fields default-unix-user
注：このオプションは、デフォルトで「pcuser」（UID 65534）に設定されています。

Filerは、上記のいずれかの方法で取得されたマッピングされたUNIXユーザのUIDおよびGIDに基づいて、Windowsユーザへのアクセスを許可または拒否します。

注：リソースがUNIXセキュリティ形式に設定されているため、UNIXユーザのUIDとGIDに基づいてアクセスが許可または拒否されます。

CIFSクライアントがNTFSセキュリティ形式のリソースにアクセスする場合のネームマッピングの仕組み

ユーザはドメインに対してすでに認証されているため、Filerは、新しく作成されるCIFSセッションごとにユーザのクレデンシャルを作成する必要があります。
Filerは、次の順序でWindowsユーザをUNIXユーザにマッピングしようとします。

明示的なname-mapping-filerは、定義された明示的なネームマッピングルールを参照し、アクセスしようとしているWindowsユーザとFiler上に存在するすべての「win-unix」ルールを照合します。

明示的なネームマッピングルールを表示するには：

Cluster01::> vserver name-mapping show -vserver SVM01 -direction win-unix
ルールが一致した場合、Filerは、前述のns-switchで定義されたソースを介して、マッピングされたUNIXユーザのUIDとGIDを検索しようとします。

暗黙的なネームマッピング-明示的なルールが一致しない場合、FilerはUNIXユーザを暗黙的にWindowsユーザにマッピングしようとします。

デフォルトのUNIXユーザ-上記の両方の方法でエラーが発生した場合（たとえば、マッピングされたUNIXユーザのUIDとGIDをFilerが取得できない場合）、FilerはWindowsユーザをCIFSサーバ・オプションで定義されている「デフォルトのUNIXユーザ」にマッピングします。

Filerは、上記の方法で取得したWindowsクレデンシャルに基づいて、Windowsユーザへのアクセスを許可または拒否します。

追加情報

vserver name-mappingルールを作成して理解する方法
シナリオの例を次に示します。
- UID 1057がクライアントからONTAPに送信されます。
- ONTAPはUID 1057をUNIXユーザ「bob」に解決
- ONTAPはネームマッピングエントリをチェックします。
  - ONTAPがパターン「bob」のUNIXからWindowsへのネームマッピングエントリを検出した場合（「bob == domain\Robert」が検出された場合など）、UIDとADアカウントは接続時にリンクされるため、UID 1057でNFS接続が使用されている場合は、 NTFSセキュリティの場所へのファイルレベルのアクセスは、がリンクされているADアカウントに基づいて決定されます。
  - パターン「bob」のネームマッピングテーブルでエントリが見つからない場合、ONTAPは「bob == domain\bob」と見なし、「bob」という名前のアカウントのADをチェックします。
  - アカウントが見つかった場合は、ADアカウント「domain\bob」に基づいてUID 1057へのアクセスが許可されます。
  - 明示的なネームマッピングが見つからず、暗黙的なネームマッピングも失敗した場合は、NFSサーバの設定に「Default Windows user」というオプションがあります。これは、Bobとして解決されたUIDをフォールバックADアカウント（「domain\guest」など）にリンクする最後の試行となります。ただし、ONTAPでNFSアクセスにこの設定は必要ないため、通常は空白のままです。
- このプロセスは、CIFS / SMB接続が確立され、UNIXセキュリティ形式の場所へのアクセスが試行された場合にも発生します。
  - 唯一の違いは、「デフォルトUNIXユーザ」のCIFSサーバオプションに、ONTAPが検索できるUNIXアカウント（ローカルまたはNIS / LDAP）を設定する必要がある点です。
  - この要件は、ONTAPがUNIX上で実行され、ファイルレベルのアクセスを決定するためにマップされたUNIXアカウントという名前を使用しない場合でも、すべての接続がUNIX UIDを介してベースまたは追跡される必要があるという事実に関連しています。