その他のNASインフラストラクチャサービスの依存関係(KDC、LDAP、およびDNS)
NAS共有にGoogle Cloud NetApp Volumeを使用している場合、適切に機能するために外部の依存関係が必要になることがあります。これらの依存関係は、特定の状況下で有効になっています。次の表に、さまざまな設定オプションと、必要な依存関係を示します。
設定 | 必須の依存関係です |
---|---|
NFSv3のみ |
なし |
NFSv3 Kerberosのみ |
Windows Active Directory:* KDC * DNS * LDAP |
NFSv4.1のみ |
クライアントIDマッピング設定(/etc/idmap.conf) |
NFSv4.1 Kerberosのみ |
|
SMBのみ |
Active Directory:* KDC * DNS |
マルチプロトコルのNAS(NFSおよびSMB) |
|
マシンアカウントオブジェクトのKerberos keytabのローテーション/パスワードがリセットされます
SMBマシンアカウントの場合、Google Cloud NetApp VolumesはSMBマシンアカウントのパスワードを定期的にリセットするようにスケジュールします。これらのパスワードはKerberos暗号化を使用してリセットされ、毎週日曜日の午後11時から午前1時までのランダムな時刻にスケジュールされます。これらのパスワードリセットにより、Kerberosキーのバージョンが変更され、Google Cloud NetApp Volumesシステムに保存されているキータブがローテーションされ、Google Cloud NetApp Volumeで実行されているSMBサーバのセキュリティレベルが向上します。マシンアカウントのパスワードはランダム化され、管理者には知られていません。
NFS Kerberosマシンアカウントの場合、パスワードのリセットは、新しいkeytabが作成され、KDCと交換されたときにのみ行われます。現時点では、これをGoogle Cloud NetApp Volumeで行うことはできません。
LDAPおよびKerberosで使用するネットワークポート
LDAPおよびKerberosを使用する場合は、これらのサービスで使用されているネットワークポートを確認する必要があります。Google Cloud NetApp Volumeで使用されているポートの一覧は、で "セキュリティに関する考慮事項に関するGoogle Cloud NetApp Volumesのドキュメント"確認できます。
LDAP
Google Cloud NetApp VolumeはLDAPクライアントとして機能し、UNIX IDのユーザおよびグループ検索に標準のLDAP検索クエリを使用します。Google Cloud NetApp Volumeで提供される標準のデフォルトユーザ以外のユーザとグループを使用する場合は、LDAPが必要です。また、ユーザプリンシパル(user1@domain.comなど)でNFS Kerberosを使用する場合も、LDAPが必要です。現在、Microsoft Active Directoryを使用するLDAPのみがサポートされています。
Active DirectoryをUNIX LDAPサーバとして使用するには、UNIX IDに使用するユーザおよびグループに、必要なUNIX属性を設定する必要があります。Google Cloud NetApp Volumesは、に基づいて属性を照会するデフォルトのLDAPスキーマテンプレートを使用します。 "RFC-2307 -bis"このため、次の表に、ユーザとグループにデータを入力するために最低限必要なActive Directory属性と、それぞれの属性がどのような目的で使用されているかを示します。
Active DirectoryでのLDAP属性の設定の詳細については、を参照してください "デュアルプロトコルアクセスの管理"
属性 | 機能 |
---|---|
UID * |
UNIXユーザ名を指定します |
uidNumber * |
UNIXユーザの数値IDを指定します |
gidNumber * |
UNIXユーザのプライマリグループの数値IDを指定します |
objectclass * |
使用するオブジェクトのタイプを指定します。Google Cloud NetApp Volumeでは、オブジェクトクラスのリストに「user」を含める必要があります(ほとんどのActive Directory環境にデフォルトで含まれています)。 |
名前 |
アカウントに関する一般的な情報(実際の名前、電話番号など、「gecos」とも呼ばれる) |
unixUserPassword |
これを設定する必要はありません。NAS認証のUNIX ID検索では使用されません。設定すると、設定されたunixUserPasswordの値がプレーンテキストになります。 |
unixHomeDirectory |
ユーザがLinuxクライアントからLDAPに照らして認証する場合のUNIXホームディレクトリへのパスを定義します。UNIXホームディレクトリの機能にLDAPを使用する場合は、このオプションを設定します。 |
loginShellの略 |
ユーザがLDAPに対して認証を行うときに、Linuxクライアントのbash/profileシェルへのパスを定義します。 |
*は、Google Cloud NetApp Volumeが適切に機能するために必要な属性です。残りの属性はクライアント側でのみ使用します。
属性 | 機能 |
---|---|
CN * |
UNIXグループ名を指定します。LDAPでActive Directoryを使用する場合は、オブジェクトの作成時に設定されますが、あとで変更することもできます。この名前を他のオブジェクトと同じにすることはできません。たとえば、user1という名前のUNIXユーザがLinuxクライアント上のuser1という名前のグループに属している場合、Windowsでは、同じcn属性を持つ2つのオブジェクトは許可されません。この問題を回避するには、Windowsユーザの名前を一意の名前(user1-unixなど)に変更します。Google Cloud NetApp VolumesのLDAPでは、UNIXユーザ名にuid属性が使用されます。 |
gidNumber * |
UNIXグループの数値IDを指定します。 |
objectclass * |
使用するオブジェクトのタイプを指定します。Google Cloud NetApp Volumeでは、グループをオブジェクトクラスのリストに含める必要があります(この属性は、ほとんどのActive Directory環境にデフォルトで含まれています)。 |
memberUid |
UNIXグループのメンバーであるUNIXユーザを指定します。Google Cloud NetApp VolumesのActive Directory LDAPでは、このフィールドは必要ありません。Google Cloud NetApp VolumesのLDAPスキーマでは、グループメンバーシップにMemberフィールドが使用されます。 |
メンバー* |
グループメンバーシップ/セカンダリUNIXグループに必要です。このフィールドには、WindowsユーザをWindowsグループに追加します。ただし、WindowsグループにUNIX属性が入力されていない場合、UNIXユーザのグループメンバーシップリストには含まれません。NFSで使用できる必要があるグループは、次の表に示す必要なUNIXグループ属性を設定する必要があります。 |
*は、Google Cloud NetApp Volumeが適切に機能するために必要な属性です。残りの属性はクライアント側でのみ使用します。
LDAPバインド情報
LDAPでユーザを照会するには、Google Cloud NetApp VolumeがLDAPサービスにバインド(ログイン)する必要があります。このログインには読み取り専用権限があり、LDAP UNIX属性を照会してディレクトリを検索するために使用されます。現在のところ、LDAPバインドはSMBマシンアカウントを使用した場合にのみ可能です。
LDAPは、インスタンスに対してのみ有効にし NetApp Volumes-Performance
、NFSv3、NFSv4.1、またはデュアルプロトコルボリュームで使用できます。LDAP対応ボリュームを導入するには、Google Cloud NetApp Volumeボリュームと同じリージョンにActive Directory接続が確立されている必要があります。
LDAPを有効にすると、特定の状況で次のような状況が発生します。
-
Google Cloud NetApp VolumesプロジェクトにNFSv3またはNFSv4.1のみを使用する場合は、Active Directoryドメインコントローラに新しいマシンアカウントが作成され、Google Cloud NetApp VolumeのLDAPクライアントがマシンアカウントのクレデンシャルを使用してActive Directoryにバインドされます。NFSボリューム用のSMB共有は作成されず、非表示のデフォルトの管理共有(セクションを参照"「デフォルトの非表示共有」")では共有ACLが削除されます。
-
Google Cloud NetApp Volumesプロジェクトにデュアルプロトコルボリュームが使用されている場合は、SMBアクセス用に作成された1つのマシンアカウントだけが、Google Cloud NetApp Volume内のLDAPクライアントをActive Directoryにバインドするために使用されます。追加のマシンアカウントは作成されません。
-
専用のSMBボリュームを個別に作成する場合(LDAPを使用するNFSボリュームの有効化前と無効化後)、LDAPバインド用マシンアカウントはSMBマシンアカウントと共有されます。
-
NFS Kerberosも有効になっている場合は、2つのマシンアカウントが作成されます。1つはSMB共有またはLDAPバインド用、もう1つはNFS Kerberos認証用です。
LDAPクエリ
LDAPバインドは暗号化されますが、LDAPクエリは共通のLDAPポート389を使用してプレーンテキストでワイヤ経由で渡されます。この既知のポートは、現在Google Cloud NetApp Volumeでは変更できません。その結果、ネットワーク内のパケットスニファにアクセスできるユーザは、ユーザ名、グループ名、数値ID、およびグループメンバーシップを確認できます。
ただし、Google Cloud VMは他のVMのユニキャストトラフィックをスニファできません。LDAPトラフィックにアクティブに参加している(バインド可能な)VMのみが、LDAPサーバからのトラフィックを表示できます。Google Cloud NetApp Volumeでのパケットスニッフィングの詳細については、次のセクションを参照してください。"「パケットのスニッフィング/トレースに関する考慮事項」"
LDAPクライアント設定のデフォルト
Google Cloud NetApp VolumeインスタンスでLDAPを有効にすると、デフォルトで特定の設定の詳細を使用してLDAPクライアント設定が作成されます。Google Cloud NetApp Volumeに適用されない(サポートされていない)オプションや設定できないオプションもあります。
LDAPクライアントオプション | 機能 | デフォルト値 | 変更は可能ですか? |
---|---|---|---|
LDAPサーバリスト |
クエリに使用するLDAPサーバ名またはIPアドレスを設定します。Google Cloud NetApp Volumeには使用されません。代わりに、Active Directoryドメインを使用してLDAPサーバを定義します。 |
未設定 |
いいえ |
Active Directoryドメイン |
LDAPクエリに使用するActive Directoryドメインを設定します。Google Cloud NetApp Volumesは、DNS内のLDAPのSRVレコードを利用して、ドメイン内のLDAPサーバを検索します。 |
Active Directory接続で指定されているActive Directoryドメインに設定します。 |
いいえ |
優先されるActive Directoryサーバ |
LDAPで使用する優先Active Directoryサーバを設定します。Google Cloud NetApp Volumeではサポートされていません。代わりに、Active Directoryサイトを使用してLDAPサーバの選択を制御します。 |
未設定。 |
いいえ |
SMBサーバクレデンシャルを使用してバインド |
SMBマシンアカウントを使用してLDAPにバインドします。現時点では、Google Cloud NetApp VolumeでサポートされているLDAPのバインド方法は唯一です。 |
正しいです |
いいえ |
スキーマテンプレート |
LDAPクエリに使用するスキーマテンプレート。 |
MS-AD-BIS を参照してください |
いいえ |
LDAPサーバポート |
LDAPクエリに使用するポート番号。Google Cloud NetApp Volumeは現在、標準のLDAPポート389のみを使用します。LDAPS /ポート636は、現在サポートされていません。 |
389 |
いいえ |
LDAPSが有効になっています |
LDAP over Secure Sockets Layer(SSL)をクエリおよびバインドに使用するかどうかを制御します。現在、Google Cloud NetApp Volumeではサポートされていません。 |
いいえ |
いいえ |
クエリタイムアウト(秒) |
クエリがタイムアウトしました。クエリに指定した値よりも長い時間がかかると、クエリが失敗します。 |
3. |
いいえ |
最小バインド認証レベル |
サポートされる最小バインドレベルを指定します。Google Cloud NetApp VolumeではLDAPバインドにマシンアカウントが使用され、Active Directoryではデフォルトで匿名バインドがサポートされないため、このオプションはセキュリティ上有効ではありません。 |
匿名 |
いいえ |
バインド DN |
シンプルバインドが使用されている場合にバインドに使用されるユーザ/識別名(DN)。Google Cloud NetApp Volumeでは、LDAPバインドにマシンアカウントが使用され、シンプルバインド認証は現在サポートされていません。 |
未設定 |
いいえ |
ベースDN |
LDAP検索に使用するベースDN。 |
Active Directory接続に使用するWindowsドメイン(DN形式)(DC=domain、DC=local) |
いいえ |
ベースの検索範囲 |
ベースDN検索の検索範囲。値には、base、onelevel、subtreeのいずれかを指定できます。Google Cloud NetApp Volumeではサブツリー検索のみがサポートされます。 |
サブツリー |
いいえ |
ユーザDN |
ユーザがLDAPクエリの検索を開始するDNを定義します。現時点ではGoogle Cloud NetApp Volumeではサポートされていないため、すべてのユーザ検索はベースDNから開始されます。 |
未設定 |
いいえ |
ユーザの検索範囲 |
ユーザDN検索の検索範囲。値には、base、onelevel、subtreeのいずれかを指定できます。Google Cloud NetApp Volumeでは、ユーザの検索範囲の設定はサポートされていません。 |
サブツリー |
いいえ |
グループDN |
グループ検索でLDAPクエリが開始されるDNを定義します。現時点ではGoogle Cloud NetApp Volumeではサポートされていないため、すべてのグループ検索はベースDNから開始されます。 |
未設定 |
いいえ |
グループの検索範囲 |
グループDN検索の検索範囲。値には、base、onelevel、subtreeのいずれかを指定できます。Google Cloud NetApp Volumeでは、グループの検索範囲の設定はサポートされていません。 |
サブツリー |
いいえ |
ネットグループDN |
ネットグループ検索でLDAPクエリの開始に使用するDNを定義します。現時点ではGoogle Cloud NetApp Volumeではサポートされていないため、ネットグループ検索はすべてベースDNから開始されます。 |
未設定 |
いいえ |
ネットグループ検索範囲 |
ネットグループDN検索の検索範囲。値には、base、onelevel、subtreeのいずれかを指定できます。Google Cloud NetApp Volumeでは、ネットグループの検索範囲の設定はサポートされていません。 |
サブツリー |
いいえ |
LDAPでstart_tlsを使用します |
Start TLSを使用して、証明書ベースのLDAP接続をポート389経由で行います。現在、Google Cloud NetApp Volumeではサポートされていません。 |
いいえ |
いいえ |
ホスト単位のネットグループ検索を有効にします |
ネットグループをすべてのメンバーの一覧に展開するのではなく、ホスト名によるネットグループ検索を有効にします。現在、Google Cloud NetApp Volumeではサポートされていません。 |
いいえ |
いいえ |
ホスト単位のネットグループDN |
ホスト単位のネットグループ検索がLDAPクエリを開始するDNを定義します。ホスト単位のネットグループは、現在Google Cloud NetApp Volumeではサポートされていません。 |
未設定 |
いいえ |
ホスト単位のネットグループ検索範囲 |
ホスト単位のネットグループDN検索の検索範囲。値には、base、onelevel、subtreeのいずれかを指定できます。ホスト単位のネットグループは、現在Google Cloud NetApp Volumeではサポートされていません。 |
サブツリー |
いいえ |
クライアントセッションのセキュリティ |
LDAPで使用されるセッションセキュリティのレベルを定義します(sign、seal、none)。LDAP署名はNetApp Volumes-Performanceでサポートされます(Active Directoryから要求された場合)。NetApp Volumes-SWではLDAP署名がサポートされません。どちらのタイプのサービスでも、現時点ではシーリングはサポートされていません。 |
なし |
いいえ |
LDAPリファーラルキャッシュ |
複数のLDAPサーバを使用している場合、リファーラル追跡を使用すると、クライアントが最初のサーバでエントリが見つからなかったときに、リスト内の他のLDAPサーバを参照することができます。現時点では、Google Cloud NetApp Volumeではサポートされていません。 |
いいえ |
いいえ |
グループメンバーシップフィルタ |
LDAPサーバからグループメンバーシップを検索するときに使用するカスタムのLDAP検索フィルタを提供します。現時点では、Google Cloud NetApp Volumeではサポートされていません。 |
未設定 |
いいえ |
LDAPを使用した非対称ネームマッピング
Google Cloud NetApp Volumeはデフォルトで、同一のユーザ名を持つWindowsユーザとUNIXユーザを特別な設定なしで双方向にマッピングします。Google Cloud NetApp Volumeが有効なUNIXユーザ(LDAPを使用)を検出できるかぎり、1:1のネームマッピングが行われます。たとえば、Windowsユーザが使用されている場合 johnsmith
、Google Cloud NetApp VolumeがLDAPでという名前のUNIXユーザを検出できる `johnsmith`と、そのユーザのネームマッピングが成功し、で作成されたすべてのファイルやフォルダに `johnsmith`正しいユーザ所有権が表示され、使用中のNASプロトコルに関係なく、影響を受けるすべてのACLが `johnsmith`適用されます。これは対称ネームマッピングと呼ばれます。
非対称ネームマッピングは、WindowsのユーザIDとUNIXのユーザIDが一致しない場合に使用します。たとえば、WindowsユーザのUNIX IDがの `jsmith`場合、 `johnsmith`Google Cloud NetApp Volumeにはその違いを確認する方法が必要です。Google Cloud NetApp Volumeでは現在静的なネームマッピングルールの作成がサポートされていないため、ファイルやフォルダの適切な所有権と想定される権限を確保するためには、LDAPを使用してWindows IDとUNIX IDの両方についてユーザのIDを検索する必要があります。
デフォルトでは、Google Cloud NetApp Volumeはネームマップデータベースのインスタンスのns-switchに含まれてい `LDAP`ます。そのため、非対称名にLDAPを使用してネームマッピング機能を提供するには、一部のユーザ/グループ属性を変更してGoogle Cloud NetApp Volumeの検索内容を反映するだけで済みます。
次の表に、非対称ネームマッピング機能のためにLDAPに入力する必要がある属性を示します。ほとんどの場合、Active Directoryはすでに設定されています。
Google Cloud NetApp Volumes属性 | 機能 | Google Cloud NetApp Volumeがネームマッピングに使用する値 |
---|---|---|
WindowsからUNIX objectClass |
使用するオブジェクトのタイプを指定します。(ユーザ、グループ、posixAccountなど) |
userを含める必要があります(必要に応じて、他の値を複数含めることもできます)。 |
WindowsからUNIXへの属性 |
作成時にWindowsユーザ名を定義します。Google Cloud NetApp Volumeでは、WindowsからUNIXへの検索にこれを使用します。 |
ここでは変更は必要ありません。sAMAccountNameはWindowsログイン名と同じです。 |
UID |
UNIXユーザ名を定義します。 |
必要なUNIXユーザ名。 |
Google Cloud NetApp Volumeでは現在、LDAP検索でドメインプレフィックスが使用されていないため、複数のドメインのLDAP環境でLDAPネームマップ検索が正しく機能しません。
次の例は、Windows名が「asymmetric」で、UNIX名が「unix-user」で、SMBとNFSの両方からファイルを書き込む際の動作を示しています。
次の図に、LDAP属性がWindowsサーバからどのように見えているかを示します。
NFSクライアントからは、UNIX名を照会できますが、Windows名は照会できません。
# id unix-user uid=1207(unix-user) gid=1220(sharedgroup) groups=1220(sharedgroup) # id asymmetric id: asymmetric: no such user
ファイルがNFSから「unix-user」として書き込まれると、NFSクライアントから次のような結果になります。
sh-4.2$ pwd /mnt/home/ntfssh-4.2$ touch unix-user-file sh-4.2$ ls -la | grep unix-user -rwx------ 1 unix-user sharedgroup 0 Feb 28 12:37 unix-user-nfs sh-4.2$ id uid=1207(unix-user) gid=1220(sharedgroup) groups=1220(sharedgroup)
Windowsクライアントでは、ファイルの所有者が適切なWindowsユーザに設定されていることを確認できます。
PS C:\ > Get-Acl \\demo\home\ntfs\unix-user-nfs | select Owner Owner ----- NTAP\asymmetric
逆に、WindowsユーザがSMBクライアントから「asymmetric」で作成したファイルの場合、次のテキストに示すように、適切なUNIX所有者が表示されます。
SMB:
PS Z:\ntfs> echo TEXT > asymmetric-user-smb.txt
NFS :
sh-4.2$ ls -la | grep asymmetric-user-smb.txt -rwx------ 1 unix-user sharedgroup 14 Feb 28 12:43 asymmetric-user-smb.txt sh-4.2$ cat asymmetric-user-smb.txt TEXT
LDAPチャネルバインド
Windows Active Directoryドメインコントローラの脆弱性により、 "マイクロソフトセキュリティアドバイザリADV190023" DCによるLDAPバインドの許可方法を変更します。
Google Cloud NetApp Volumeの影響は、他のLDAPクライアントと同じです。Google Cloud NetApp Volumeは現在チャネルバインディングをサポートしていません。Google Cloud NetApp Volumeでは、ネゴシエーションを通じてデフォルトでLDAP署名がサポートされるため、LDAPチャネルバインディングは問題になりません。チャネルバインドを有効にした状態でLDAPへのバインドに問題がある場合は、ADV190023の修正手順に従って、Google Cloud NetApp VolumeからのLDAPバインドを成功させるようにします。
DNS
Active DirectoryとKerberosはどちらも、ホスト名からIP / IPを経由したホスト名解決で、DNSに依存します。DNSでは、ポート53を開く必要があります。Google Cloud NetApp Volumeでは、DNSレコードに変更は加えられておらず、ネットワークインターフェイスでの使用も現在サポートされていません "動的DNS"。
Active Directory DNSを設定して、DNSレコードを更新できるサーバを制限できます。詳細については、を参照してください "Windows DNSを保護"。
Googleプロジェクト内のリソースは、既定ではGoogle Cloud DNSを使用しますが、Active Directory DNSには接続されていません。クラウドDNSを使用するクライアントは、Google Cloud NetApp Volumeから返されたUNCパスを解決できません。Active Directoryドメインに参加しているWindowsクライアントは、Active Directory DNSを使用するように設定され、このようなUNCパスを解決できます。
クライアントをActive Directoryに参加させるには、Active Directory DNSを使用するようにそのDNS設定を構成する必要があります。必要に応じて、Active Directory DNSに要求を転送するようにCloud DNSを設定することができます。を参照してください "クライアントでSMB NetBIOS名を解決できないのはなぜですか?"を参照してください。
Google Cloud NetApp Volumeは現在DNSSECをサポートしておらず、DNSクエリはプレーンテキストで実行されます。 |
ファイルアクセスの監査
現時点では、Google Cloud NetApp Volumeではサポートされていません。
アンチウイルスによる保護
クライアントからNAS共有へのGoogle Cloud NetApp Volumeでウィルススキャンを実行する必要があります。現在、Google Cloud NetApp Volumeにはウィルス対策機能が標準で統合されていません。