このページでは、Google Cloud NetApp Volumes が Active Directory と統合されて、サーバー メッセージ ブロック（SMB）ボリュームとネットワーク ファイル システム（NFS）ボリュームの ID と認証を提供する方法について説明します。この統合を理解することで、ファイル共有への安全なアクセスを構成できます。
統合について
Google Cloud NetApp Volumes は Active Directory と統合して、SMB や NFS などのファイル共有プロトコル用のディレクトリ サービスを提供します。Active Directory は、Lightweight Directory Access Protocol（LDAP）、Domain Name System（DNS）、Kerberos などのサービスを通じて、認証、ID ルックアップ、セキュリティ プリンシパルのマッピングを処理します。
Active Directory ポリシーは、NetApp Volumes が Active Directory に接続する方法を指定します。ストレージ プール構成では、これらのポリシーを使用して、その中に作成するボリュームの Active Directory 設定を定義します。
Active Directory ポリシーはリージョン固有であり、リージョンごとに最大 5 つのポリシーを構成できます。
セキュリティ プリンシパルを使用するファイル共有プロトコル（SMB（CIFS）、拡張グループを使用した NFSv3、NFSv4 など）は、ユーザー ID 情報を提供する外部ディレクトリ サービスに依存しています。NetApp Volumes は、ディレクトリ サービスに Active Directory を使用します。Active Directory は次のサービスを提供します。
LDAP サーバー: ユーザー、グループ、マシンなどのオブジェクトを検索します。
DNS サーバー: ホスト名を解決し、Active Directory ドメイン コントローラの検出を行います。
Kerberos サーバー: 認証を実行します。
詳細については、 Google Cloudで Active Directory を実行するためのベスト プラクティスをご覧ください。
Active Directory のユースケース
NetApp Volumes は、次のユースケースで Active Directory を使用します。
SMB ドメイン サービスと認証を提供する: Active Directory は SMB の中央ドメイン サービスとして機能します。NetApp Volumes は、ユーザーとグループの認証と ID 検索にこれを使用します。NetApp Volumes はメンバーとしてドメインに参加しますが、ワークグループ モードでの SMB はサポートしていません。
NFSv3 の拡張グループ サポートを提供します: 拡張グループ サポートを備えた NFSv3 の場合、Active Directory は、ユーザー、グループ、マシン アカウントなどのオブジェクトの検索に必要な LDAP サーバーを提供します。
具体的には、ユーザー ID とグループ ID のルックアップには
RFC2307bis準拠の LDAP サーバーが必要です。LDAP サポートは、プールの作成時にストレージ プールで有効になります。
拡張グループ サポートは、NFS 呼び出しで NFS クライアントから送信されたすべてのグループ ID を無視します。代わりに、リクエストのユーザー ID を取得し、ファイル権限チェックのために、指定されたユーザー ID のすべてのグループ ID を LDAP サーバーから検索します。
詳細については、LDAP
RFC2307bisPOSIX 属性を管理するをご覧ください。NFSv4.x のセキュリティ プリンシパルをユーザー ID とグループ ID にマッピングする: NetApp Volumes は、Active Directory を使用して、NFSv4.x のセキュリティ プリンシパルをユーザー ID とグループ ID にマッピングします。
NFSv4.x では、ユーザー ID とグループ ID ではなく、プリンシパルベースの認証モデルが使用されます。このモデルでは、RFC 7530 のセキュリティに関する考慮事項で説明されているように、セキュリティ プリンシパルが
user@dns_domain形式でユーザーを識別します。NFSv4.x プロトコルを使用してボリュームにアクセスするときに、セキュリティ プリンシパルをユーザー ID とグループ ID にマッピングするには、NetApp Volumes にRFC2307bis準拠の LDAP サーバーが必要です。NetApp Volumes は Active Directory LDAP サーバーのみをサポートしています。LDAP サポートは、プールの作成時にストレージ プールで有効になります。セキュリティ プリンシパルを使用するには、次の要件を満たす必要があります。
NFS クライアントとサーバーは同じ LDAP ソースに接続する必要があります。
NFS クライアントで
idmapd.confファイルを構成する必要があります。idmapd.confファイルの構成方法の詳細については、libnfsidmap用のidmapd.confファイルの構成方法に関する Ubuntu のドキュメントをご覧ください。
dns_domainは Active Directory ドメイン名、userは Active Directory ユーザー名です。これらの値は、LDAP POSIX 属性を設定するときに使用します。NFSv4.1 に数値 ID を使用する: ID マッピングなしで NFSv4.1 を使用し、NFSv3 と同様にユーザー ID とグループ ID のみを使用するには、数値 ID を使用してセキュリティ プリンシパルを無視します。NetApp Volumes は数値 ID をサポートしています。ID マッピングが構成されていない場合、NFS クライアントはデフォルトで数値 ID を使用します。
NFSv4.x の Kerberos 認証を提供する: NFSv4.x で Kerberos を使用する場合は、セキュリティ プリンシパル検索用の LDAP サーバーとして Active Directory を使用する必要があります。Kerberos プリンシパルは、セキュリティ ID として使用されます。Kerberos 鍵配布センターは Active Directory を使用します。
NFSv4.x で Kerberos を使用するには、次の手順も完了する必要があります。
Kerberos 設定を含む Active Directory ポリシーをプールに適用します。
ストレージ プールを作成するときに、ストレージ プールで LDAP サポートを有効にします。
Active Directory マシン アカウントを作成するために必要な権限
Active Directory を使用するには、NetApp ボリュームで 1 つ以上の仮想ファイル サーバーをパソコン アカウントとしてドメインに参加させる必要があります。ドメインに参加するには、コンピュータをドメインに参加させる権限を持つドメイン ユーザーの認証情報を指定する必要があります。デフォルトでは、Domain Admins グループのメンバーのみがコンピュータをドメインに参加させることができますが、Active Directory には、ドメイン全体または組織部門（OU）レベルで個々のユーザーまたはグループに必要な権限を委任する機能があります。
NetApp Volumes の場合は、専用のドメイン サービス アカウントを作成することをおすすめします。新しいコンピュータを特定の OU に参加させるために必要な権限のみを委任します。Domain User または Domain Guest グループのメンバーシップを持つユーザーを作成したら、次の手順に沿って必要な権限を委任します。
Active Directory ドメインのドメイン管理者としてシステムにログインします。
MMC の [Active Directory ユーザーとコンピュータ] スナップインを開きます。
メニューバーから [表示] を選択し、[高度な機能] が有効になっていることを確認します。
[詳細設定] が有効になっている場合は、チェックマークが表示されます。
タスクペインで、ドメインノードを開きます。
変更する OU を見つけて右クリックし、コンテキスト メニューから [プロパティ] を選択します。
[OU のプロパティ] ウィンドウで、[セキュリティ] タブを選択します。
[セキュリティ] で、[詳細設定] をクリックし、[追加] をクリックします。
[Permission Entry] ダイアログで、次の手順を完了します。
[プリンシパルを選択] をクリックします。
サービス アカウントまたはグループの名前を入力し、[OK] をクリックします。
[適用対象:] で、[このオブジェクトとすべての子孫オブジェクト] を選択します。
次の権限が選択されていることを確認します。
権限を変更する
コンピュータ オブジェクトを作成する
コンピュータ オブジェクトを削除する
[適用] チェックボックスをオンにして、[OK] をクリックします。
[Active Directory ユーザーとコンピュータ] MMC スナップインを閉じます。
サービス アカウントが委任されたら、ユーザー名とパスワードを Active Directory ポリシーの認証情報として指定できます。
セキュリティを強化するため、マシン アカウント オブジェクトのクエリと作成時に Active Directory ドメインに渡されるユーザー名とパスワードには、Kerberos 暗号化が使用されます。
Active Directory ドメイン コントローラ
NetApp Volumes をドメインに接続するために、サービスは DNS ベースの検出を使用して、使用可能なドメイン コントローラのリストを特定します。
サービスは次の手順で、使用するドメイン コントローラを検索します。
Active Directory サイトの検出: NetApp Volumes は、Active Directory ポリシーで指定された DNS サーバー IP に LDAP ping を使用して、Active Directory サイトのサブネット情報を取得します。CIDR のリストと、それらの CIDR に割り当てられている Active Directory サイトのリストを返します。
Get-ADReplicationSubnet -Filter * | Select-Object Name,Siteサイト名を定義する: ボリュームの IP アドレスが定義されたサブネットのいずれかと一致する場合、関連付けられたサイト名が使用されます。小さいサブネットの一致は、大きいサブネットの一致よりも優先されます。ボリュームの IP アドレスが不明な場合は、NFS プロトコル タイプで一時ボリュームを手動で作成し、使用されている
/28CIDR を特定します。Active Directory でサイト名が定義されていない場合は、Active Directory ポリシーで構成されたサイト名が使用されます。サイト名が構成されていない場合、スタンダード、プレミアム、エクストリームのサービスレベルでは
Default-First-Site-Nameサイトが使用されます。Flex サービスレベルがDefault-First-Site-Nameサイトを使用しようとすると、失敗し、代わりに完全なドメイン コントローラ検出が使用されます。Active Directory サイト パラメータの変更は、Flex サービスレベルのストレージ プールでは無視されます。ドメイン コントローラの検出: 必要な情報をすべて取得すると、サービスは次の DNS クエリを使用して、潜在的なドメイン コントローラを特定します。
nslookup -type=srv _ldap._tcp.<site_name>._sites.dc._msdcs.<domain-name> <dns-server>ドメイン全体の検出では、サービスは次の DNS クエリを使用します。
nslookup -type=srv _ldap._tcp.dc._msdcs.<domain-name> <dns-server>ドメイン コントローラのリストの生成: ドメイン コントローラのリストが生成されます。NetApp Volumes は、すべての可用性を常にモニタリングします。利用可能なドメイン コントローラの中から、ドメインへの参加とルックアップ用に 1 つを選択します。選択したドメイン コントローラが使用できなくなった場合は、[使用可能] リストの別のドメイン コントローラが自動的に使用されます。選択したドメイン コントローラが、指定した DNS サーバーであるとは限りません。
サービスで使用できるドメイン コントローラを 1 つ以上指定する必要があります。ドメイン コントローラの可用性を高めるために、複数のドメイン コントローラをおすすめします。NetApp Volumes とドメイン コントローラ間にルーティングされたネットワーク パスがあり、ドメイン コントローラのファイアウォール ルールで NetApp Volumes の接続が許可されていることを確認します。
詳細については、Active Directory の設計に関する考慮事項とベスト プラクティスをご覧ください。
Active Directory ドメイン コントローラのトポロジ
Active Directory ドメイン コントローラに正常に接続すると、次のファイル共有プロトコルを使用できます。
SMB
拡張グループを使用した NFSv3
セキュリティ プリンシパルと Kerberos を使用した NFSv4
次のシナリオでは、考えられるトポロジについて説明します。これらのシナリオでは、NetApp Volumes で使用されるドメイン コントローラに焦点を当てています。同じドメインの他のドメイン コントローラについては、必要な場合にのみ説明します。冗長性と可用性を確保するために、少なくとも 2 つのドメイン コントローラをデプロイすることをおすすめします。
| トポロジ | 説明 |
|---|---|
| 1 つのリージョン内の Active Directory ドメイン コントローラとボリューム | このシナリオは、ドメイン コントローラがボリュームと同じリージョンにある最もシンプルなデプロイ戦略です。 |
| 別のリージョンにある Active Directory ドメイン コントローラとボリューム | ボリュームとは異なるリージョンのドメイン コントローラを使用できます。この構成は、認証とファイル アクセスのパフォーマンスに悪影響を及ぼす可能性があります。 |
| AD サイトを使用する複数のリージョンの Active Directory ドメイン コントローラ | 複数のリージョンでボリュームを使用する場合は、各リージョンに少なくとも 1 つのドメイン コントローラを配置することをおすすめします。サービスはドメイン コントローラを自動的に選択しますが、Active Directory サイトを使用してドメイン コントローラの選択を管理することをおすすめします。 |
| オンプレミス ネットワーク内の Active Directory ドメイン コントローラ | VPN 経由でオンプレミスのドメイン コントローラを使用できますが、エンドユーザー認証とファイル アクセスのパフォーマンスに悪影響を及ぼす可能性があります。ネットワーク パスに追加の Virtual Private Cloud ピアリング ホップを追加しないでください。VPC ピアリングには、推移的ルーティングの制限が適用されます。トラフィックは、NetApp Volumes がすでに使用している VPC ピアリング ホップを超えてルーティングされません。 |
| 別の VPC ネットワーク内の Active Directory ドメイン コントローラ | Google Cloud VPC ピアリングでは推移的ルーティングが許可されないため、ドメイン コントローラを別の VPC に配置することはできません。または、VPN を使用して VPC を接続するか、Active Directory ドメイン コントローラをホストする共有 VPC ネットワークに NetApp ボリュームをアタッチすることもできます。NetApp ボリュームを共有 VPC ネットワークに接続する場合、この構成は上記のシナリオのいずれかと似ています。 |