次の方法で共有

Azure NetApp Files 内の Kerberos を理解する

  • [アーティクル]

Kerberos は、秘密鍵を使用してプリンシパルのアイデンティティを検証する認証プロトコルです。 秘密鍵は、プリンシパルのパスワードを取得し、それをクライアントとサーバーによって合意された暗号化方法 (AES など) を使用してハッシュ暗号化キー形式に変換することによって生成されます。 このドキュメントで使用される用語については、「Kerberos の用語」セクションを参照してください。

Windows Active Directory などのキー配布センター (KDC) は、Kerberos プリンシパルとそのハッシュ化されたパスワードのデータベースを保持します。 Kerberos では、秘密鍵が一意のアイデンティティの証明となります。 そのため、KDC を信頼することで、マウント時に NFS クライアント サービス プリンシパル名 (SPN) を NFS サーバー SPN に認証するなど、他のプリンシパルに対して任意のプリンシパルを認証することができます。 また、これを信頼することで、NAS マウント ポイントへのユーザー アクセスのために、NFS サーバー SPN に対してユーザー プリンシパルを認証することもできます。 Kerberos は、セキュリティ対策の強化として、ネットワーク経由で認証用のクリア テキスト パスワードを送信することはありません。

Azure NetApp Files では、SMB プロトコルと NFS プロトコルの両方に対してインフライト セキュリティを提供するための Kerberos の使用がサポートされています。

サポートされている暗号化の種類

Azure NetApp Files では、利用者が使用するオペレーティング モードとバージョンに応じて、特定の暗号化の種類を持つ NFS Kerberos がサポートされています。

クライアントで適切な暗号化の種類が使用されるようにするために、KDC (マシン アカウントなど) にあるオブジェクト プリンシパルで有効な暗号化の種類を制限することができます。また、多数のクライアント krb5.conf ファイルの管理が管理上の問題となる可能性があることから、可能な場合には、/etc/krb5.conf ファイルでグローバルに制限するのではなく、クライアントで手動で作成した keytab ファイルにあるオブジェクト プリンシパルで制限することもできます。 大規模なエンタープライズ環境では、KDC から Kerberos を一元的に管理する方がスケーラビリティが向上し、自動化が容易になり、クライアントがより強力な暗号化の種類 (それらがサポートされている場合) を使用することを強制できます。

Note

クライアントの krb5.conf ファイルでオプション allow_weak_crypto を false に設定することをお勧めします。 この設定により、Kerberos 通信での安全性の低い enctypes (DES や 3DES など) が防止されます。

次の表は、Azure NetApp Files の Kerberos (SMB と NFS の両方) でサポートされている暗号化の種類を示しています。

プロトコル サポートされている暗号化の種類
SMB
  • RC4-HMAC
  • AES-128
  • AES-256
NFS AES-256

サポートされている NFS Kerberos のセキュリティ モード

Kerberos には、暗号化の種類の概念に加えて、セキュリティと整合性チェックというレベルも存在します。 これらのセキュリティ モードは、使用中のセキュリティ モードに応じて、NFS トラフィックに対してエンドツーエンドの暗号化を提供することで、中間者攻撃を防ぐのに役立ちます。

Azure NetApp Files では、これらのセキュリティ モードは、NFS のボリュームに設定されたエクスポート ポリシー規則上で指定され、sec マウント オプションを使用して初期 NFS マウント中に定義されます。

例: # mount -o sec=krb5p

Note

SMB Kerberos の場合、Kerberos のセキュリティ モードは、共有上の SMB 暗号化設定、UNC セキュリティ強化、ドメイン コントローラー上の SMB 署名/シール ポリシーによって制御されます。

NFS Kerberos での使用に関しては、Azure NetApp Files では以下のセキュリティ モードがサポートされています。

[セキュリティ モード] 説明
krb5 "認証の暗号化のみ。"

ローカル UNIX ユーザー ID (UID) とグループ ID (GID) の代わりに Kerberos V5 名の文字列とユーザー プリンシパル名を使用してユーザーを認証します。
krb5i "認証の暗号化と暗号化された整合性チェック。"

ユーザー認証に Kerberos V5 を使用し、データの改ざんと中間者攻撃を防ぐために安全なチェックサムを使用して NFS 操作の整合性チェックも実行します。
krb5p "NFS 会話全体の暗号化。"

ユーザー認証と整合性チェックに Kerberos V5 を使用し、パケット スニッフィングを防ぐためにすべての NFS トラフィックの暗号化も行います。 この設定は最も安全ではありますが、パフォーマンスのオーバーヘッドも最も高くなります。

Kerberos の用語

このセクションでは、Kerberos プロセスを記述するときに使用される主要な用語を定義します。 このセクションは、ストレージ管理者にとってはなじみのない用語を明確にすることを手助けするためのものです。

任期 定義
キー配布センター (KDC) KDC とは、チケット保証サービス (TGS) と認証サービス (AS) を含む認証サーバーです。 KDC、AS、TGS という用語は同じ意味で使用されています。 Microsoft 環境では、Active Directory ドメイン コントローラーが KDC となります。
領域 (または Kerberos 領域) 領域 (または Kerberos 領域) では、任意の ASCII 文字列を使用できます。 標準は、ドメイン名を大文字で使用することです。たとえば、contoso.com は CONTOSO.COM という領域になります。 Kerberos 領域は、通常、クライアントとサーバー上の krb5.conf ファイル内で構成されます。

管理上、各 principal@REALM は一意である必要があります。 単一障害点を回避するために、各領域は、同じデータベース (プリンシパルとそのパスワード) を共有し、同じ KDC マスター キーを持つ複数の KDC を持つことができます。 Microsoft Windows Active Directory は、既定で 15 分ごとに実行される Active Directory レプリケーションを使用してネイティブにこれを行います。
プリンシパル プリンシパルという用語は、Kerberos データベース内のすべてのエンティティを指します。 ユーザー、コンピューター、サービスはすべて、Kerberos 認証に割り当てられたプリンシパルです。 すべてのプリンシパルは Kerberos データベース内で一意である必要があり、その識別名によって定義されます。 プリンシパルには、ユーザー プリンシパル名 (UPN) またはサービス プリンシパル名 (SPN) を指定できます。

プリンシパル名は、以下の 3 つの部分から成ります。
  • プライマリ - プライマリ部には、ユーザーまたは NFS サービスなどのサービスを指定できます。 これはまた、特別なサービス "ホスト" にすることもできます。これは、このサービス プリンシパルが複数のさまざまなネットワーク サービスを提供するように設定されていることを示します。
  • インスタンス - ユーザーの場合、この部分は省略可能です。 ユーザーは複数のプリンシパルを持つことができますが、各プリンシパルは KDC 内で一意である必要があります。 たとえば、Fred は、日常的に使用するプリンシパル (fred@contoso.com) と、sysadmin アカウント (admin-fred@contoso.com) などの特権を使用できるプリンシパルを持っている場合があります。 このインスタンスはサービス プリンシパルに必要であり、そのサービスを提供するホストの完全修飾ドメイン名 (FQDN) を指定します。
  • 領域 - Kerberos 領域は、Kerberos サーバー内に登録されている Kerberos プリンシパルのセットです。 慣例により、領域名は通常、DNS 名と同じですが、大文字に変換されます。 大文字は必須ではありませんが、この規則によって DNS 名と領域名を簡単に区別できます。
チケット チケットは、サービスのプリンシパルの ID を検証し、セッション キーを含む資格情報の一時的なセットです。 チケットには、サービス、アプリケーション チケット、または Ticket Granting Ticket (TGT) を指定できます。 チケットは、Kerberos 認証のためにクライアント、サーバー、KDC の間で交換されます。
秘密鍵 Kerberos は、対称キー システムを使用し、暗号化と暗号化解除の両方に秘密鍵が使用されます。 この秘密鍵は、プリンシパルの Kerberos パスワードから一方向ハッシュ関数を使用して生成されます。 KDC は各プリンシパルのパスワードを保存しているため、プリンシパルの秘密鍵を生成できます。 Kerberos サービスを要求するユーザーの場合、秘密鍵は通常、kinit プログラムに提示されるパスワードから作成されます。 サービスおよびデーモン プリンシパルは通常、パスワードを使用しません。代わりに、一方向ハッシュ関数の結果が keytab 内に保存されます。
keytab keytab には、プリンシパルとそれぞれの秘密鍵のリストが含まれています。 keytab 内の秘密鍵は、多くの場合、ランダムなパスワードを使用して作成され、主にサービスまたはデーモン プリンシパルで使用されます。

ネットワーク ポート情報

次の表は、Kerberos 通信でどのネットワーク ポートが使用されるかを示しています。 ネットワーク ファイアウォールが設定されている場合は、適切な Kerberos 機能を許可するために、これらのポートを開く必要があります。 これらのポートの詳細については、「IANA サービス名とトランスポート プロトコル ポート番号レジストリ」で確認できます。

Service ポート
Kerberos 88 (TCP/UDP)
kpasswd 464 (TCP/UDP)
ライトウェイト ディレクトリ アクセス プロトコル (LDAP) (名前マッピング用) 389 (TCP/UDP)
管理サーバー 749 (TCP/UDP)
グローバル カタログ (Windows ユーザー参照) 3268 (TCP/UDP)

Azure NetApp Files 内でのキャッシュの有効期間の値

次の表は、キャッシュ エントリが Azure NetApp Files ボリューム内に存在する時間を示しています。

キャッシュ キャッシュの有効期間
アイドル状態のネーム サーバー接続 60 秒
LDAP クエリのタイムアウト 10 秒
KDC のローカル DNS ホスト エントリの TTL 24 時間
Kerberos チケットの有効期間 KDC* またはクライアントによって指定されます
Windows Active Directory KDC の
*既定値は 10 時間
ユーザーの資格情報 24 時間
Kerberos タイム スキュー 5 分

Azure NetApp Files 内で適切に機能する Kerberos 環境の要件

Kerberos 認証は、適切な機能のために外部サービスに大きく依存しています。 Microsoft Active Directory では、多くの場合、これらのサービスのほとんどは 1 つのサーバー内に統合されます。 たとえば、Active Directory ドメイン コントローラーは、以下の Kerberos 依存関係にサービスを提供できます。

  • 時間同期サービス
  • DNS
  • Kerberos キー配布
  • パスワード サービス/シングル サインオン
  • ID サービス (LDAP など)

ネイティブ Microsoft Active Directory (Azure NetApp Files で現在サポートされている唯一の KDC の種類) を使用する場合、Azure NetApp Files 内の Kerberos の外部依存関係の大部分 (DNS、KDC、パスワード サービスなど) がカバーされます。 場合によっては、必要なサービスが Active Directory ドメイン (DNS など) の外部でホストされていることがあります。 このような場合は、必要なサービスが正しく構成されていることを確認することが重要です。

Azure NetApp Files には、NFS Kerberos が適切に機能するための固有の依存関係があります。 詳細については、続きをお読みください。

時間同期サービス

認証に Kerberos を使用する場合は、時間同期サービスが必須です。これは、Kerberos チケット メカニズムは、既定の 5 分の範囲内にあるクライアントとサーバー間のタイム スキューに依存しているためです。 クライアントまたはサーバーの時間設定がその 5 分の範囲を超えると、Kerberos 認証はタイム スキュー エラー (KRB_AP_ERR_SKEW) で失敗し、NAS 共有へのアクセスは拒否されます。 このタイムアウトは、攻撃者が KDC とクライアントの間でメッセージを傍受しておき、後にそれらのメッセージを再生して認証されたユーザーを偽装するという "リプレイ攻撃" を防ぐのに役立つセキュリティ機能です。 タイム スキューの制限は、このような種類の攻撃のリスクを最小限に抑えるのに役立ちます。

時間同期の問題に関する主な考慮事項:

詳細については、「コンピューターのクロック同期の最大許容値」を参照してください

ドメイン ネーム システム (DNS)

ドメイン ネーム システム (DNS) は、Kerberos においてセキュリティ機能として必須です。 ホスト名解決は、認証に使用される Kerberos サービス プリンシパルを作成するために使用されます。 このプロセスでは、Kerberos 認証を利用する共有に接続するために、ホスト名 (A/AAAA レコード) の前方参照が使用されます。 この前方参照はその後、Kerberos 認証要求で使用されるサービス プリンシパル名 (SPN) を作成するために使用されます。 KDC 内に既存の SPN が見つからない場合、Kerberos 認証は失敗します。

Windows SMB 環境では、バックアップの認証方法 (NTLM など) が試される場合があります。 ただし、多くの場合、セキュリティ上の理由から NTLM は無効になっており、それが原因で、Kerberos 認証に失敗すると共有へのアクセス エラーが発生することになります。 Windows イベント ビューアーは、多くの場合、エラーの根本原因 (重複/不足している SPN、DNS 参照エラー、NTLM エラーなど) をログに記録します。

DNS は、SPN 解決に加えて、LDAP、Kerberos KDC などのドメイン サービスのホスト名と IP アドレスを SRV レコード経由で解決するために頻繁に利用されます。 Azure NetApp Files の DNS (どの SRV レコードが必要なのかを含む) の詳細については、「Azure NetApp Files の DNS について」を参照してください。

Note

Kerberos アクセスに IP アドレスが使用される場合、その動作は使用中の NAS プロトコル (NFS または SMB) によって異なります。 詳細については、「Kerberos でアクセスするための IP アドレス」を参照してください。

LDAP

ライトウェイト ディレクトリ アクセス プロトコル (LDAP) は、バックエンド ID データベースを利用して NAS クライアントとサーバー向けの統合ネーム サービス ソースを提供し、参加しているすべてのデバイスがユーザーの信頼性、グループ メンバーシップ、数値 ID に同意できるようにします。これらは後にファイル アクセス許可のために使用されます。

Kerberos の場合、ユーザーおよびサービス プリンシパルは、LDAP データベースのエントリを使用して、プリンシパル アカウントの属性として保存されます。 Windows Active Directory は、既定でこれをサポートしています。 場合によっては (エイリアスやサービス プリンシパルを作成する場合など)、ユーザーとコンピューターで、サービス プリンシパル名の追加や変更が必要になります。 この要件は、Active Directory のユーザーとコンピューター Microsoft 管理コンソール (MMC) または PowerShell を使用して満たすことができます。 サービス プリンシパル名の管理の詳細については、「サービス プリンシパル名の管理」を参照してください。

Kerberos 認証のサービス プリンシパル名と数値 ID に加えて、LDAP は UNIX ユーザー ID とグループ ID に対しても使用できます。これらは、Azure NetApp Files での ID の名前マッピングに使用されるほか、SPN -> UNIX ユーザー名マッピングを介した NFS Kerberos マウントの初期認証にも使用されます。 詳細については、「NFS Kerberos が Azure NetApp Files 内でどのように動作するか」および「Azure NetApp Files の Kerberos を使用した LDAP のロール」を参照してください。

SMB Kerberos が Azure NetApp Files 内でどのように動作するか

SMB Kerberos は NFS Kerberos サービスとは別に動作します。これは、1 つの keytab 内のキー バージョン番号 (kvno) の変更が他のサービスに影響を与える可能性があるため、各プロトコル用に作成されたマシン アカウントは、keytab を共有できないためです。 この結果、NAS プロトコル内の当然の違いと同様に、Kerberos 用の SMB サービスと Kerberos 用の NFS のワークフローは、一部の領域で機能が異なります。

SMB サービスの初期構成

Azure NetApp Files の SMB サービスは、最初に Active Directory 接続を設定することで構成されます。この接続では、ドメイン サービスとの相互作用に不可欠な次のような要素を定義します。

  • プライマリ DNS サーバー (必須)
  • セカンダリ DNS
  • Active Directory DNS 名*
  • Active Directory サイト名 (DC 検出用) (必須)
  • SMB サーバー プレフィックス名
  • 組織単位 (マシン アカウントを Azure AD ドメインに格納する必要がある)
  • AES 暗号化の有効化/無効化
  • LDAP 署名の有効化/無効化
  • LDAP 構成
  • DC に対する SMB 暗号化
  • 特権ユーザー
  • OU アクセス許可を持つユーザーのユーザー名/パスワード認証情報

Note

1 つのアカウントで許可される Azure Active Directory (AD) 接続は 1 つだけです。 Azure AD 接続が作成されると、新しい Azure NetApp Files SMB ボリュームはすべてその Azure AD 接続構成を使用します。

SMB Kerberos マシン アカウント

Active Directory 内のマシン アカウントには、サービス プリンシパル名 (SPN) など、認証要求で使用するための関連情報が含まれています。 Azure NetApp Files で SMB ボリュームを作成する場合には、Kerberos (または有効な場合は NTLM) 認証を介して SMB 共有への安全なアクセスを提供するマシン アカウントを作成する操作の際に、Active Directory 接続構成が使用されます。

Azure NetApp Files の SMB ボリュームがサービス内の特定のバックエンド リソースにプロビジョニングされると、新しいマシン アカウントが作成されます。 以下に、SMB マシン アカウントが Azure NetApp Files ボリューム構成で作成または再利用される場合の各種のシナリオを示します。

シナリオ 結果
最初の新しい SMB ボリューム 新しい SMB マシン アカウント/DNS 名
最初の SMB ボリュームから短い期間に連続して作成された後続の SMB ボリューム 再利用される SMB マシン アカウント/DNS 名 (ほとんどの場合)。
最初の SMB ボリュームよりずっと後に作成された後続の SMB ボリューム サービスが、新しいマシン アカウントが必要かどうかを判断します。 複数のマシン アカウントが作成され、それによって複数の IP アドレス エンドポイントが作成される可能性があります。
最初のデュアル プロトコル ボリューム 新しい SMB マシン アカウント/DNS 名
最初のデュアル プロトコル ボリュームから短い期間に連続して作成された後続のデュアル プロトコル ボリューム 再利用される SMB マシン アカウント/DNS 名 (ほとんどの場合)
最初のデュアル プロトコル ボリュームよりずっと後に作成された後続のデュアル プロトコル ボリューム サービスが、新しいマシン アカウントが必要かどうかを判断します。 複数のマシン アカウントが作成され、それによって複数の IP アドレス エンドポイントが作成される可能性があります
デュアル プロトコル ボリュームの後に作成された最初の SMB ボリューム 新しい SMB マシン アカウント/DNS 名
SMB ボリュームの後に作成された最初のデュアル プロトコル ボリューム 新しい SMB マシン アカウント/DNS 名

Azure NetApp Files SMB (またはデュアル プロトコル) ボリューム用に作成された SMB マシン アカウントは、Active Directory によって適用される 15 文字の最大値に準拠する名前付け規則を使用します。 この名前は、[Azure AD 接続構成内で指定された SMB サーバー プレフィックス]-[一意の数値識別子] の構造を使用します。

たとえば、SMB サーバー プレフィックス "AZURE" を使用するように Azure AD 接続を構成した場合、Azure NetApp Files によって作成される SMB マシン アカウントは "AZURE-7806" のようになります。同じ名前が SMB 共有の UNC パス (たとえば、\AZURE-7806 など) で使用され、動的 DNS サービスが A/AAAA レコードの作成に使用する名前となります。

Note

"AZURE-7806" のような名前は覚えにくい場合があるため、Azure NetApp Files ボリュームの DNS エイリアスとして CNAME レコードを作成すると便利です。 詳細については、「SMB サーバー エイリアスの作成」を参照してください。

Azure NetApp Files 内の複数のマシン アカウント/DNS エントリの図。

場合によっては、複数の SMB またはデュアル プロトコル ボリュームを作成するときに、構成によって複数の異なる SMB マシン アカウントと DNS 名が発生してしまう可能性があります。

ボリューム間でユーザー アクセス用の単一の名前空間が必要な場合、1 つの CNAME エイリアスで指し示すことができるのは 1 つの A/AAAA ホスト レコードのみであるため、構成に問題が生じる可能性があります。また、複数の同一の A/AAAA レコード エイリアスを使用すると、異なる SMB マシン アカウント間でボリュームにアクセスする際のデータ アクセスが予測できなくなる可能性があります。これらの構成では DNS レコードの選択がラウンド ロビンで行われるため、DNS 参照でクライアントが選択したエンドポイントに想定されるボリュームが含まれる保証はありません。

このような制限に対処するため、Azure NetApp Files ボリュームは Microsoft 分散ファイル システム (DFS) 構成にターゲットとして参加できます。この構成では、複数の SMB ボリュームを単一の名前空間エントリ ポイントに関連付けることが可能です。

Azure NetApp Files の分散ファイル システムの図。

SMB Kerberos SPN 作成のワークフロー

次の図は、Azure NetApp Files SMB またはデュアル プロトコル ボリュームの作成時に SMB Kerberos SPN がどのように作成されるかを示しています。 SMB SPN は、ドメイン内の SMB マシン アカウント オブジェクトに関連付けられます。 この SPN は、[詳細] ビュー内の属性エディターを使用して、マシン アカウントのプロパティ経由で表示および管理できます。

Azure-SMB プロパティのスクリーンショット。

setspn コマンドを使用してプロパティを表示および管理することもできます。

`setspn` コマンドのスクリーンショット。

このプロセスは、通常の Windows クライアントがドメイン (DNS、LDAP、Kerberos、名前付きパイプ経由の RPC クエリ) に参加する場合と同じ手順に従います。

Kerberos マシン アカウントの図。

ほとんどの場合、日常的な管理タスクのために詳細な手順を深く理解することは必要ありませんが、この理解は Azure NetApp Files 内に SMB ボリュームを作成しようとしたときのエラーのトラブルシューティングに役立ちます。

詳細な手順

Azure NetApp Files 内に SMB マシン アカウントがどのように作成されるかの詳細な手順が必要な場合は、このリストを展開してください。

  • DNS 参照は、Kerberos KDC の SRV レコードの DNS 構成を使用して実行されます。 Azure NetApp Files は、要求内で以下の SRV レコードを使用します。

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (前のクエリで結果が返されない場合)

  • DNS 参照は、KDC の A/AAAA レコードの SRV クエリで返されるホスト名を使用して実行されます。

    • LDAP ping (LDAP バインドと RootDSE クエリ) が実行され、NetLogon の属性フィルターでクエリ (&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) を使用して、使用可能なレガシ NetLogon サーバーが検索されます。 (2008 より大きい) 新しい Windows ドメイン コントローラーのバージョンには、NtVer 値がありません。

  • ドメイン内の LDAP サーバーを検索するために、Azure NetApp Files によって、以下の SRV レコードを使用して DNS クエリが実行されます。

    • _ldap._tcp.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM

    Note

    これらのクエリは、同じ呼び出し内のプロセスのさまざまな部分で複数回発生します。 DNS の問題により、これらの呼び出しが遅くなったり、タイムアウトが発生したり、完全なエラーが発生したりする可能性があります。 - クエリがエントリを見つけられなかった場合、または見つかったエントリに接続できない場合、SMB ボリュームの作成は失敗します。 - DNS クエリが成功した場合、以降の手順が処理されます。

  • ICMP (ping) が送信され、DNS から返された IP アドレスが到達可能であることが確認されます。

  • ファイアウォール ポリシーによってネットワーク上で ping がブロックされている場合、ICMP 要求は失敗します。 代わりに、LDAP ping が使用されます。

  • 別の LDAP ping が実行され、NetLogon の属性フィルターでクエリ (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) を使用して、使用可能なレガシ NetLogon サーバーが検索されます。 (2008 より大きい) 新しい Windows ドメイン コントローラーのバージョンには、NtVer 値がありません。

  • AS-REQ 認証は、Active Directory 接続で構成されたユーザー名を使用して Azure NetApp Files サービスから送信されます。

  • DC は KRB5KDC_ERR_PREAUTH_REQUIRED で応答し、ユーザーのパスワードを安全に送信するようサービスに要求します。

  • 2 つ目の AS-REQ は、マシン アカウントの作成を続けるためにアクセスを KDC で認証する際に必要な事前認証データと共に送信されます 送信が成功した場合、Ticket Granting Ticket (TGT) がサービスに送信されます。

  • 送信が成功した場合、サービスによって TGS-REQ が送信され、AS-REP で受信した TGT を使用して KDC から CIFS サービス チケット (cifs/kdc.contoso.com) が要求されます。

  • CIFS サービス チケットを使用して新しい LDAP バインドが実行されます。 クエリは次の Azure NetApp Files から送信されます。

    • ドメインの ConfigurationNamingContext DN の RootDSE ベース検索
    • 属性 NETBIOSname のフィルター (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) を使用して ConfigurationNamingContext 用に取得された DN 内の CN=partitions の OneLevel 検索。
    • フィルター (|(objectClass=organizationalUnit)(objectClass=container)) を使用したベース検索は、Active Directory 接続構成で指定された OU に対して実行されます。 指定されていない場合、既定値 OU=Computers が使用されます。 これにより、コンテナーが存在するかどうかが確認されます。
    • アカウントが既に存在するかどうかを確認するために、サブツリー検索が、フィルター (sAMAccountName=ANF-XXXX$) を使用してドメインのベース DN 上で実行されます。
      • アカウントが存在する場合は、再利用されます。
    • アカウントが存在しない場合は、ユーザーに addRequest LDAP コマンドを使用してコンテナー内のオブジェクトを作成および変更するアクセス許可があれば、作成されます。 LDAP では、次の属性がアカウントに設定されます。
    属性 値
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • 上
    • 人物
    • OrganizationalPerson
    • User
    • Computer
    servicePrincipalName
    • HOST/ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    operatingSystem NetApp Release
    dnsHostName ANF-XXXX.CONTOSO.COM
    • addRequest が失敗した場合、ボリュームの作成は失敗します。 addRequest は、コンテナー オブジェクトの不適切なアクセス許可が原因で失敗する可能性があります。
    • addRequest が成功すると、フィルター (sAMAccountName=ANF-XXXX$) を使用する LDAP 検索が実行され、objectSid 属性が取得されます。
    • SMB2 "Negotiate protocol" 会話が実行され、KDC からサポートされている Kerberos mechTypes が取得されます。
    • CIFS SPN とサポートされている中で最も高い mechType を使用した SMB2 "Session setup" と IPC$ に対する "Tree connect" が実行されます。
    • SMB2 lsarpc ファイルが IPC$ 共有に作成されます。
    • DCERPC へのバインドが実行されます。 lsarpc ファイルが書き込まれた後、読み取られます。
    • その後、以下の LSA 要求が実行されます。

  • TGT を使用して TGS-REQ が実行され、krbtgt アカウントに関連付けられている kadmin/changepw SPN のチケットが取得されます。

  • KPASSWD 要求がサービスから KDC に対して行われ、マシン アカウントのパスワードが変更されます。

  • distinguishedName および isCriticalSystemObject 属性のフィルター (sAMAccountName=ANF-XXXX) を使用して LDAP クエリが実行されます。

  • アカウントの isCriticalSystemObject が false (既定値) の場合、取得された DN は属性 msDs-SupportedEncryptionTypes への modifyRequest を作成するために使用されます。 この値は 30 に設定され、この内訳は DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16) となります。

  • IPC$ に対する 2 つ目の "Negotiate protocol"/Kerberos ticket exchange/"Session setup"/"Tree connect" が実行されます。 SMB サーバーのマシン アカウント (ANF-XXXX$) が、Kerberos プリンシパルとして機能します。

  • NetLogon、NetrServer ReqChallenge/Authenticate2 通信が完了します。

  • IPC$ に対する 3 つ目の "Negotiate protocol:/Kerberos ticket exchange/"Session setup"/"Tree connect" が実行されます。SMB サーバーのマシン アカウント (ANF-XXXX$) が Kerberos プリンシパルとして使用されます。

  • アカウントの最終チェックとして、lsarpc および NetLogon 接続の両方が作成されます。

SMB 共有接続ワークフロー (Kerberos)

Azure NetApp Files ボリュームが Kerberos を使用してマウントされている場合、共有への安全なアクセスを用意するために、複数のセッション セットアップが要求される際には Kerberos チケット交換が使用されます。 ほとんどの場合、日常的な管理タスクのために詳細な手順を深く理解することは必要ありません。 この知識は、Azure NetApp Files で SMB ボリュームにアクセスしようとしたときのエラーのトラブルシューティングに役立ちます。

SMB 共有接続のワークフローの図。

Azure NetApp Files 内で SMB 共有がどのようにアクセスされるかを説明する手順が必要な場合は、このリストを展開してください。
  • クライアントは、Azure NetApp Files 内に表示されている UNC パスを使用して SMB 共有へのアクセスを試みます。 既定では、この UNC パスには SMB サーバー名 (ANF-XXXX など) が含まれます
  • ホスト名を IP アドレスにマップするために DNS のクエリが実行されます。
  • 最初の SMB2 「ネゴシエート プロトコル」のメッセージ交換が行われます
    • 要求がクライアントから送信され、サーバーでサポートされている SMB 言語と、要求元のクライアントのサポートする内容が含まれているかどうかを検出します
    • サーバーは、次のようなサポート内容で応答します。
      • セキュリティ モード (署名かどうか)
      • SMB のバージョン
      • サーバー GUID
      • サポートされる機能 (DFS、リース、大きな MTU、マルチチャネル、永続ハンドル、ディレクトリ リース、暗号化)
      • 最大トランザクション サイズ
      • 最大読み取り/書き込みサイズ
      • セキュリティ BLOB (Kerberos または NTLM)
  • 2 つ目の SMB2 「ネゴシエート プロトコル」のメッセージ交換が「事前認可」/ログインとして行われます
    • クライアントからの要求には次の内容が含まれます。
      • 事前認可ハッシュ
      • サポートされているセキュリティ モード (署名かどうか)
      • サポートされる機能 (DFS、リース、大きな MTU、マルチチャネル、永続ハンドル、ディレクトリ リース、暗号化)
      • クライアント GUID
      • サポートされている SMB 言語
    • 事前認可ハッシュが受け入れられた場合、サーバーは次の内容を含めて応答します。
      • セキュリティ モード (署名かどうか)
      • サポートされる機能 (DFS、リース、大きな MTU、マルチチャネル、永続ハンドル、ディレクトリ リース、暗号化)
      • 最大トランザクション サイズ
      • 最大読み取り/書き込みサイズ
      • セキュリティ BLOB (Kerberos または NTLM)
      • SMB 事前認可の整合性と暗号化機能
  • プロトコル ネゴシエーションが成功すると、「セッション セットアップ」要求が行われます。
    • セットアップでは、プロトコル ネゴシエーションからの事前認可ハッシュが使用されます。
    • セットアップにより、要求側のクライアントがサポートする次の内容が SMB サーバーに通知されます。
      • StructureSize
      • セッション バインド フラグ
      • セキュリティ モード (署名が有効/必須)
      • 機能
      • サポートされている Kerberos 暗号化の種類
  • 「セッションセットアップ」応答が送信されます。
    • SMB クレジットが付与されます。
    • セッション ID が確立されます。
    • セッション フラグが設定されます (ゲスト、null 値、暗号化)。
    • Kerberos 暗号化の種類が定義されます。
  • SMB 共有への接続のために、クライアントによって tree connect 要求が送信されます。
    • 共有フラグ/機能は、共有アクセス許可と共にサーバーから送信されます。
  • ioctl コマンド FSCTL_QUERY_NETWORK_INTERFACE_INFO が、SMB サーバーの IP アドレスを取得するために送信されます。
  • Azure NetApp Files の SMB サーバーは、ネットワーク情報を含むレポートを返します。次の情報が含まれます。 * IP アドレス * インターフェイス機能 (RSS オンまたはオフ) * RSS キュー数 * リンク速度
  • IPC$ 管理共有への接続のために、クライアントによって tree connect 要求が送信されます。
    • IPC$ 共有は、プログラム間の通信に不可欠な名前付きパイプを共有するリソースです。 IPC$ 共有は、コンピューターのリモート管理中、およびコンピューターの共有リソースを表示するときに使用されます。 IPC$ 共有の共有設定、共有プロパティ、ACL の変更を行うことはできません。 IPC$ 共有の名前変更または削除を行うこともできません。
  • srvsvc ファイルに対して DCERPC バインドが行われ、安全な接続が確立されます。
    • ファイルは、以前に取得した情報と共に書き込まれます。
  • Kerberos TGS-REQ は、SMB サービスのサービス チケット (ST) を取得するために、Windows クライアントによって KDC に発行されます。
  • NetShareGetInfo コマンド は SMB クライアントによってサーバーに対して実行され、応答が送信されます。
  • SMB サービス チケットが KDC から取得されます。
  • Azure NetApp Files は、共有へのアクセスを要求している Windows ユーザーを有効な UNIX ユーザーにマップしようとします。
    • Kerberos TGS 要求は、最初の SMB サーバーの作成から、SMB サーバーの keytab と共に格納された SMB サーバー Kerberos 資格情報を使用して行われ、LDAP サーバーのバインドに使用されます。
    • LDAP では、共有アクセスを要求する SMB ユーザーにマップされている UNIX ユーザーを検索します。 LDAP で UNIX ユーザーが存在しない場合は、Azure NetApp Files が名前のマッピングに既定の UNIX ユーザー pcuser を使用します (デュアル プロトコル ボリュームに書き込まれたファイル/フォルダーは、マップされた UNIX ユーザーを UNIX の所有者として使用します)。
  • 別のネゴシエート プロトコル/セッション要求/ツリー接続が実行されます。今度は、SMB サーバーの Kerberos SPN を使用して Active Directory DC の IPC$ 共有に接続します。
    • 名前付きパイプは、srvsvc を介して共有に確立されます。
    • 共有に対して NETLOGON セッションが確立され、Windows ユーザーが認証されます。
  • アクセス許可でユーザーに許可されている場合は、ボリュームに含まれるファイルとフォルダーが共有で一覧表示されます。

Note

Azure NetApp Files は、クライアントの Kerberos コンテキスト キャッシュにエントリを追加します。 これらのエントリは、Kerberos チケットの有効期間中はキャッシュに存在します (KDC によって設定され、Kerberos ポリシーで制御されます)。

SMB サーバー エイリアスの作成

Azure NetApp Files で [Azure AD 接続構成で指定された SMB サーバー プレフィックス]-[一意の数値識別子] の名前付け規則を使用して SMB サーバーを作成する場合。 (一意の数値識別子の詳細については、「SMB Kerberos マシン アカウント」を参照してください)。 この書式設定では、SMB サーバー名がわかりやすいものになりません。 たとえば、「SMB-7806」は「AZURE-FILESHARE」などに比べると覚えにくい名前になります。

このビヘイビアーにより、管理者は Azure NetApp Files ボリュームにわかりやすいエイリアス名を付けることができます。 これを行うには、DNS の正規名 (CNAME) がサーバー内の既存の DNS A/AAAA レコードに向くようにする必要があります。

CNAME が作成されて UNC パス要求で使用される (たとえば、\\SMB-7806 ではなく \\AZURE-FILESHARE) と、DNS は、Kerberos SPN の取得 (cifs/SMB-7806) で使用される適切な A/AAAA レコード (SMB-7806.contoso.com) に CNAME 要求 (AZURE-FILESHARE.contoso.com) をリダイレクトします。 これにより、エイリアス化された名前の使用時に、SMB 共有への Kerberos アクセスが許可されます。

DNS A/AAAA レコードが作成され (たとえば、AZURE-FILESHARE.contoso.com)、エイリアスとしての使用が試みられた場合、Kerberos 要求は失敗します。 このエラーが発生するのは、共有 (cifs/AZURE-FILESHARE) の認証に使用される構築済みの SPN が、SMB サーバー (cifs/SMB-7806) の Kerberos SPN と一致しないためです。 このエラーは、別の SPN が作成され、SMB サーバー マシン アカウント (cifs/AZURE-FILESHARE など) に追加された場合には緩和される場合があります。

Azure NetApp Files でサポートされている SMB サーバー機能

SMB 「ネゴシエート プロトコル」要求が行われると、特定の機能をサポートするために Azure NetApp Files SMB サーバーにクエリが実行されます。 次の表は、セッション セットアップ/ツリー接続の実行時にクエリを実行する機能と、Azure NetApp Files SMB ボリュームから返される応答を示しています。

SMB 機能 Azure NetApp Files によるサポートの有無
DFS ターゲット はい
リース はい
大きな MTU はい
SMB マルチチャネル はい
SMB 永続ハンドル はい
ディレクトリ リース いいえ
SMB 暗号化 有 (有効な場合)

Azure NetApp Files でサポートされている SMB 共有の機能とプロパティ

SMB 共有アクセスの際に「ツリー接続」要求が実行され、クライアントが Azure NetApp Files サーバーに対して、サポートされている SMB 共有の機能とプロパティに関するクエリを実行します。 次の表に、クエリが実行される共有機能と、パケット キャプチャに表示される Azure NetApp Files SMB ボリュームが返す応答を示します。

SMB 共有機能 Azure NetApp Files によるサポートの有無
継続的に使用可能 (CA) 有。特定のワークロードの場合* (有効な場合)
スケールアウト いいえ
クラスター いいえ
非対称 いいえ
所有者へのリダイレクト いいえ

* サポートされているワークロードについては、「既存の SMB ボリュームでの継続的可用性を有効にする」を参照してください。

次の表に、クエリが実行される共有プロパティと、Azure NetApp Files SMB ボリュームが返す応答を示します。

SMB 共有機能 Azure NetApp Files によるサポートの有無
DFS ターゲット はい
DFS ルート いいえ
排他的制限のオープン いいえ
強制共有削除 いいえ
名前空間のキャッシュの許可 いいえ
アクセス ベースの列挙 有 (有効な場合)
強制レベル II の便宜的ロック いいえ
ハッシュ V1 を有効にする いいえ
ハッシュ v2 を有効にする いいえ
必要な暗号化 有 (有効な場合)
ID リモート処理 いいえ
圧縮 I/O いいえ
分離トランスポート いいえ

NFS Kerberos が Azure NetApp Files 内でどのように動作するか

NFS Kerberos は SMB サービスとは別に動作します。これは、1 つの keytab 内のキー バージョン番号 (kvno) の変更が他のサービスに影響を与える可能性があるため、各プロトコル用に作成されたマシン アカウントは、keytab を共有できないためです。 この結果、Kerberos 用の SMB サービスと Kerberos 用の NFS のワークフローは、一部の領域で機能が異なります。

Kerberos 領域の初期構成

NFS Kerberos 領域は、Azure NetApp Files ポータルの [Active Directory 接続] ページで Kerberos 領域情報が入力された場合に構成されます。

Kerberos 領域の構成のスクリーンショット。

Azure AD サーバー名と KDC IP は、マシン アカウントの初回作成時に Azure AD KDC サービスに接続するために使用されます。 Azure NetApp Files サービスは、既存のドメイン情報を利用して領域構成の残り部分を入力します。 次に例を示します。

Kerberos Realm: CONTOSO.COM
KDC Vendor: Microsoft
KDC IP Address: x.x.x.x 
KDC Port: 88
Clock Skew: 5
Active Directory Server Name: dc1.contoso.com
Active Directory Server IP Address: x.x.x.x
Comment: -
Admin Server IP Address: x.x.x.x
Admin Server Port: 749
Password Server IP Address: x.x.x.x
Password Server Port: 464
Permitted Encryption Types: aes-256
-    Configured by Azure NetApp Files administrator in the portal
-    Automatically configured by the service using Active Directory connection information/system defaults

NFS Kerberos 領域が構成されると、構成で指定した KDC を使用してローカル ホスト エントリがサービスに追加されます。 領域が変更されると、サービスのローカル ホスト エントリも変更されます。

Kerberos 領域の構成のダイアグラム。

このローカル ホスト エントリは、領域構成で指定された KDC が停止し、DNS 経由で冗長 KDC に対してクエリを実行できなかった場合の「最後の手段」として機能します。

Note

メンテナンスのために Kerberos 領域の KDC を停止する必要がある場合 (サーバーのアップグレードや使用停止など) には、メンテナンスを行わない KDC の停止を回避するために、その KDC を使用する領域を構成することをおすすめします。

マシン アカウント/SPN の初期作成

Azure NetApp Files ボリュームで Kerberos が有効になっている場合、NFS-{SMB-server-name} という名前のマシン アカウント/プリンシパルが、Active Directory 接続の指定された OU (組織単位) 内のドメインに作成されます。 マシン アカウント名は、15 文字より後は切り捨てられます。

Note

ホスト名が 15 文字を超える Linux クライアントを Active Directory ドメインに追加すると、Kerberos マシン アカウントの SPN が切り捨てられます。 たとえば、MORE-THAN-FIFTEEN という名前の Linux クライアントには MORE-THAN-FIFT$ というマシン アカウント名があり、MORE-THAN-FIFT$@CONTOSO.COM の SPN になります。 DNS がクライアント ホスト名を参照すると、長い名前が検索され、SPN 要求 MORE-THAN-FIFTEEN@CONTOSO.COM) でその名前の使用が試みられます。 しかし、その SPN は存在しないため、クライアントは要求の keytab で次の SPN を使用しようとします (通常はホスト/ホスト名)。 Azure NetApp Files の NFS Kerberos では、ネイティブで機能するのはマシン アカウント名の SPN のみです。 その結果、Azure NetApp Files で NFS Kerberos に使用される Linux クライアント ホスト名が 15 文字を超えないようになります。 あるいは、ホスト/ホスト名 SPN を使用する場合には、ユーザー名「host」を使用して LDAP で UNIX ユーザーを構成します。この構成では、SPN の krb-unix 名マッピングを利用できます。

Azure NetApp Files では、NFS サービスの SPN (nfs/nfs-server-name.contoso.com@CONTOSO.COM) を使用して Kerberos キーブロック (または keytab エントリ) がサービスに追加されます。 サポートされている暗号化の種類ごとに 1 つずつ、複数のエントリが作成されます。 Azure NetApp Files では、NFS Kerberos 用に暗号化の種類として AES-256 のみがサポートされています。

ほとんどの場合、日常的な管理タスクのためにこれらの手順を深く理解することは必要ありませんが、この理解は Azure NetApp Files で NFS Kerberos ボリュームを作成しようとしたときのエラーのトラブルシューティングに役立ちます。

NFS Kerberos SPN 作成のワークフロー

次のダイアグラムは、Kerberos を有効にして Azure NetApp Files NFS またはデュアル プロトコル ボリュームの作成時に NFS SPN がどのように作成されるかを示しています。 ほとんどの場合、日常的な管理タスクのために詳細な手順を深く理解することは必要ありませんが、この理解は Azure NetApp Files で SMB ボリュームを作成しようとしたときのエラーのトラブルシューティングに役立ちます。

NFS Kerberos SPN 作成のワークフローのダイアグラム。

Azure NetApp Files で NFS Kerberos SPN がどのように作成されるかの詳細な手順が必要な場合は、このリストを展開してください。
  • Active Directory 接続で使用するために指定されたユーザー名を使用して、領域構成で指定された KDC に渡される管理者資格情報 - ユーザーには、指定された OU 内のオブジェクトを表示または作成するためのアクセス許可が必要です。
  • Azure NetApp Files の Active Directory 接続構成で指定された DNS サーバーには、Kerberos サービス レコード (SRV) の Azure NetApp Files が次の形式でクエリを実行します。
    • _kerberos.CONTOSO.COM に向けた URI クエリ
    • _kerberos-master._udp に向けた SRV クエリ。 CONTOSO.COM
    • _kerberos-master._tcp に向けた SRV クエリ。 CONTOSO.COM

Note

これらのクエリは、同じ呼び出し内のプロセスのさまざまな部分で複数回発生します。 DNS の問題により、これらの呼び出しが遅くなったり、完全なエラーが発生したりする可能性があります。 これらのレコードは、Active Directory のデプロイには既定では存在しないように見え、手動で作成する必要があります。

  • クエリでエントリが見つからない、見つかったエントリに接続できない、マスター KDC として使用できないなどのいずれかに該当する場合は、NFS Kerberos 領域構成で見つかった領域名を使用した A レコード クエリが、ポート 88 経由で KDC に接続するための最後の手段として使用されます。
  • NFS Kerberos の構成中に、DNS 参照に失敗した場合、指定された KDC の静的ホスト エントリがバックアップとしてローカル ホスト ファイルに追加されます。
  • 領域のキャッシュされた DNS エントリがある場合は、そのエントリが使用されます。 そのようなエントリがない場合は、ローカル ファイル エントリが使用されます。 キャッシュされた DNS エントリは、TIME to Live (TTL) が DNS レコード用に構成されている限り有効です。 ローカル ファイル エントリは、86,400 秒の TTL (24 時間) で構成されます。 Azure NetApp Files のホスト参照の ns スイッチ構成では、最初にファイルを使用し、次に DNS を使用します。 ローカル エントリが見つかると、それ以上クエリは実行されません。
  • Active Directory 接続の作成時に作成された SMB マシン アカウントは、ポート 389 経由で SASL/GSS を使用して Active Directory LDAP バインドの資格情報として使用され、目的の SPN またはマシン アカウント名の既存のエントリを検索します。 SPN またはマシン アカウント名が既に存在する場合は、エラーが送信されます。 SPN が LDAP クエリに存在しない場合は、Azure NetApp Files によって設定された次の属性のエントリを使用して、指定された OU でマシン アカウントが作成されます。
    • cn (NFS-MACHINE)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (top、person、organizationalPerson、user、computer)
    • servicePrincipalName (host/NFS-MACHINE、host/NFS-MACHINE.CONTOSO.COM、nfs/NFS-MACHINE、nfs/NFS-MACHINE.CONTOSO.COM)
    • userAccountControl (4096)
    • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
    • dnsHostName (NFS-MACHINE.CONTOSO.COM)
  • NFS Kerberos マシン アカウントのパスワードは、ポート 464 経由で NFS-MACHINE アカウントに設定されます。
  • NFS SPN の Kerberos キーブロック (keytab) は、Azure NetApp Files サービスに保存されます。
  • Azure NetApp Files サービスに静的な名前マッピング ルールが作成され、Kerberos の使用時に各 NFS Kerberos クライアントのルート ユーザーが確実にルートにマップされるようにします。
  • NFS 領域情報を使用して、krb5.conf ファイルがサービスの内部システムに追加されます。

NFS Kerberos のマウント

NFS 経由で Kerberos セキュリティ フレーバーを使用して Azure NetApp Files ボリュームをマウントすると、次のワークフローが実行されます。 Kerberos の詳細なアカウントについては、「Kerberos ネットワーク認証サービス (V5) の概要」を参照してください。

NFS Kerberos のマウントのワークフローのダイアグラム。

Azure NetApp Files で NFS Kerberos ボリュームがどのように作成されるかの詳細な手順が必要な場合は、このリストを展開してください。
  • クライアントは、Azure NetApp Files の NFS エクスポート パスへのマウントを試み、-o krb5 (または krb5i か krb5p) セキュリティ フレーバーを指定します。
  • DNS は、マウント コマンドの実行方法に応じて、A/AAAA レコードまたは PTR を介して Azure NetApp Files に対する NFS サービス プリンシパルの要求を作成するために使用されます。
  • クライアントは、クライアントの keytab にある CLIENT プリンシパル名を使用して、AS-REQ 呼び出しを介して KDC から TGT を取得します。
  • エクスポート パスは、ファイル システムに存在することを確認するためにチェックされます。
  • エクスポート ポリシールールがチェックされ、エクスポート パスへの Kerberos アクセスが許可されていることを確認します。<
  • NFS サービス チケットは、AP-REQ 呼び出しを介してクライアントによって KDC から要求されます。 Azure NetApp Files は、KDC から取得したクライアントから TGT を使用して、有効な暗号化の種類を持つ有効なエントリの keytab をチェックします。
  • TGT が有効な場合は、サービス チケットが発行されます。
  • クライアント SPN (たとえば、CLIENT$@CONTOSO.COM) は、Azure NetApp Files の名前マッピング ルールを介してルート ユーザーにマップされます。
  • ルート ユーザーには、ネーム サービス データベース (ファイルと LDAP) で存在またはグループ メンバーシップについてクエリが実行されます。
  • SMB サーバー マシン アカウントを使用した LDAP バインドが実行され、ルート ユーザーの LDAP 検索ができるようになります。
  • ルートは常に Azure NetApp Files に存在するため問題は発生しませんが、ルートに対する LDAP クエリが失敗する可能性はあります。 このようなエラーは無視できます。
  • NFS サービス チケットがクライアントに返され、マウントに成功します。 ルート ユーザーには、クライアントのマシン アカウント プリンシパルを使用した Kerberos マウントへのルート アクセスがあります (クライアントの klist -e コマンドを使用すると表示できます)。
  • Azure NetApp Files は、クライアントの Kerberos コンテキスト キャッシュにエントリを追加します。 これらのエントリは KDC によって設定され、Kerberos ポリシーによって制御される Kerberos チケットの有効期間中はキャッシュに存在します。
  • NFSv4.1 は定期的 (20 秒ごと) に Kerberos チケットの更新プログラムを「キープアライブ」として送信します。

ユーザー プリンシパルを使用した NFS Kerberos マウント アクセス

Azure NetApp Files の NFS Kerberos マウントにユーザー (マシン アカウント SPN を使用するルート ユーザー以外) がアクセスすると、次のワークフローが実行されます。

ユーザー プリンシパルを使用した NFS Kerberos マウント アクセスのダイアグラム。

Azure NetApp Files で非ルート ユーザーによって NFS Kerberos ボリュームがどのようにアクセスされるかの詳細な手順が必要な場合は、このリストを展開してください。
  • ユーザーは、ユーザー名/パスワード交換を使用するか、keytab ファイルを介して KDC にログインし、Azure NetApp Files ボリュームからサービス チケットを収集するために使用する AS-REQ 呼び出しを介して TGT を取得します。
  • クライアント マシンのエクスポート パスに対して Kerberos アクセスが許可されていることを確認するために、エクスポート ポリシー ルールがチェックされます
  • Azure NetApp Files では、キャッシュされた NFS サービス チケットがチェックされます。 存在しない場合は、AP-REQ 呼び出しを介して NFS サービス チケットが要求され、KDC から取得されたクライアントの TGT を使用して、有効な暗号化の種類を含む有効なエントリが keytab で確認されます
  • TGT が有効な場合は、サービス チケットが発行されます
  • ユーザーのユーザー プリンシパル名 (UPN) は、暗黙的なマッピングを通じてマップされます。 たとえば、UPN が user1@CONTOSO.COM である場合、サービスは user1 という名前の UNIX ユーザーについてクエリを実行します。 その UNIX ユーザーは Azure NetApp Files のローカル ファイル データベースには存在しないため、LDAP が使用されます。
  • SMB サーバー マシン アカウントを使用した LDAP バインドは、マップされたユーザーの LDAP 検索を許可しようとします。 Kerberos DNS レコード (_kerberos および _kerberos-master) に対して DNS SRV クエリが実行されます。 有効なレコードを使用できない場合、構成は領域構成にフォール バックされます。 これらの KDC DNS SRV クエリでは、サイトの範囲は指定されません。
  • 有効な LDAP サーバーについて、LDAP SRV レコードに対してクエリが実行されます。 これらの範囲は指定されます。
  • ユーザーが LDAP に存在しない、または LDAP に対してクエリが実行できない (サーバーがダウンしている、DNS 参照に失敗する、バインドが失敗する、LDAP 検索がタイムアウトする、ユーザーが存在しない) 場合、マッピングに失敗し、アクセスは拒否されます。
  • ユーザーが存在する場合は、グループ メンバーシップが収集されます。
  • マッピングに成功すると、NFS サービス チケットがクライアントに発行されます (klist -e コマンドで参照)。 アクセスは、エクスポート パスに対するファイルのアクセス許可に基づいて許可されます。

Azure NetApp Files での Kerberos を使用した LDAP のロール

Azure NetApp Files は、NFS Kerberos の LDAP に依存しています。 Azure NetApp Files の NFS Kerberos では、UNIX 名を受信ユーザー SPN にマッピングする際に Kerberos が必要です。 Azure NetApp Files ではローカル UNIX ユーザーの作成がサポートされていないため、名前のマッピングが要求されたときに UNIX ユーザーを参照するには LDAP が必要になります。

  • Azure AD 接続が作成されると、Active Directory ドメイン名を使用して、LDAP サーバーを検索するプロセスが指定されます。
  • LDAP サーバーが必要な場合、_ldap.domain.com が LDAP サーバーの SRV の検索に使用されます。
  • サーバーの一覧が検出されると、ポート 389 経由の接続に使用できる最適なサーバー (ping 応答時間に基づく) が LDAP サーバーとして使用されます。
  • GSS/Kerberos 経由で SMB マシン アカウントを使用して、LDAP バインドが試行されます。
  • キャッシュされた接続または Kerberos 資格情報がない場合は、Kerberos チケットの新しい要求が発行されます。 Azure NetApp Files のネーム サーバーにキャッシュされた接続は、60 秒間有効です。 アイドル状態が 60 秒を超える場合、接続キャッシュはクリアされます。
  • DNS は、SRV レコードを介して適切な Kerberos KDC を検索するために使用されます。
  • DNS クエリを介して KDC が見つからない場合は、SMB サービスの krb5.conf ファイルで指定された KDC が使用されます。
    • その KDC に到達できない場合、または Kerberos 要求を処理できない場合、LDAP バインドは失敗します。 名前の参照にも失敗します。 有効な認証が行われないため、マウントへのアクセスが拒否されます。
    • バインドに成功すると、ユーザーとその資格情報に対して LDAP クエリが実行されます。 検索時間が 10 秒を超えると、検索は失敗します。
  • 検索でユーザーが見つかると、マッピングが成功して Kerberos 経由でアクセス権が付与されます (チケットが有効か、有効期限が切れていない場合)。

Kerberos を使用したアクセスの IP アドレス

既定では、Kerberos 認証はホスト名から IP アドレスへの解決を利用して、Kerberos チケットを取得するために使用されるサービス プリンシパル名 (SPN) を作成します。 たとえば、\SMBVOLUME.CONTOSO.COM などの汎用名前付け規則パス (UNC) を使用して SMB 共有にアクセスすると、完全修飾ドメイン名 SMBVOLUME.CONTOSO.COM に対して DNS 要求が発行され、Azure NetApp Files ボリュームの IP アドレスが取得されます。 DNS エントリが存在しない場合 (または、存在するエントリが要求されたもの (エイリアス/CNAME など) と異なる場合)、適切な SPN を取得できず、Kerberos 要求は失敗します。 その結果、フォールバック認証方法 (New Technology LAN Manager など) が無効になっている場合は、ボリュームへのアクセスが許可されない可能性があります。

Azure NetApp Files の DNS エントリは、動的 DNS を使用して自動的に作成され、SMB サーバーの名前を使用して作成されます。 定義名のバリエーション/エイリアスについては、手動で DNS CNAME レコードを作成し、動的 DNS エントリに向ける必要があります。 詳細については、「Azure NetApp Files の DNS の理解」を参照してください。

NFSv4.1 Kerberos は、SPN を取得するために同様の方法で動作し、DNS ルックアップは認証プロセスに不可欠であり、Kerberos 領域の検出にも使用できます。

Azure NetApp Files ボリュームへのアクセス要求でホスト名ではなく IP アドレスが使用されている場合、Kerberos 要求の動作は使用しているプロトコルによって異なります。

IP アドレスと DNS 名を使用した SMB Kerberos のビヘイビアー

SMB を使用する場合、IP アドレス (たとえば、\\x.x.x.x) を使用して UNC パスを要求すると、既定では認証に NTLM を使用しようとします。 セキュリティ上の理由から NTLM が許可されていない環境では、IP アドレスを使用する SMB 要求で、既定では認証に Kerberos または NTLM を使用できません。 その結果、Azure NetApp Files ボリュームへのアクセスは拒否されます。 Windows の Windows 10 バージョン 1507 および Windows Server 2016 以降のリリースでは、この問題を回避するために、SMB 通信の SPN で IPv4 および IPv6 のホスト名をサポートするように Kerberos クライアントを構成できます。

IP アドレスと DNS 名を使用した NFSv4.1 Kerberos のビヘイビアー

NFSv4.1 を使用する場合、sec=[krb5/krb5i/krb5p] オプションのいずれかを使用する IP アドレスへのマウント要求では、PTR 経由の逆引き DNS 参照を使用して IP アドレスをホスト名に解決します。 その後、そのホスト名を使用して、Kerberos チケットを取得するための SPN を作成します。 Kerberos を使用した NFSv4.1 を使用する場合、マウントへのホスト名と IP アドレスの両方のアクセスをカバーするために、Azure NetApp Files ボリュームに A/AAAA と PTR が必要です。 Azure NetApp Files では、動的 DNS A/AAAA レコードが作成されます。 そのサブネットに逆引き DNS ゾーンが存在する場合は、PTR レコードも自動的に作成されます。 標準の Azure NetApp Files ホスト名規則から逸脱する場合は、DNS エイリアスに CNAME レコードを使用します。

詳細については、「Azure NetApp Files の DNS の理解」を参照してください