内容

はじめに

用語

知識と要件

Kerberosネットワークフロー

WSAでのKerberos認証のフロー

SPNの目的は何ですか。

Active Directoryサーバの設定

SPNコマンドを使用したKerberosのトラブルシューティング

SPNコマンドと出力の例

シナリオ1: SPNが見つかりません

シナリオ2: SPNが見つかりました

WSAでのKerberosのトラブルシューティング

その他の情報と参考資料

はじめに

このドキュメントでは、チケットを使用してWebサイトおよびシングルサインオンシステムのIDを安全に検証するKerberosプロトコルについて説明します。

用語

WSA

Web セキュリティ アプライアンス

CLI を使う場合：

コマンドライン インターフェイス

[AD]

Active Directory

SPN

サービスプリンシパル名

KDC

Kerberosキー配布センター

TGT

認証チケット

TG

チケット認可サービス

HA

ハイ アベイラビリティ

VRRP

仮想ルータ冗長プロトコル

鯉

共通アドレス冗長プロトコル

知識と要件

- Active Directoryと認証。

- WSAの認証とレルム

Kerberosネットワークフロー

Kerberized環境での認証の基本的な手順を次に示します。

1. クライアントは、Key Distribution Center(KDC)にTicket Granting Ticket(TGT)を要求します。

2. KDCは、クライアントマシンのユーザクレデンシャルを検証し、暗号化されたTGTとセッションキーを返します。

3. TGTは、チケット認可サービス(TGS)の秘密鍵で暗号化されます。

4. クライアントはTGTを保存し、有効期限が切れると自動的に新しいTGTを要求します。

サービスまたはリソースにアクセスする場合：

1. クライアントは、目的のリソースのサービスプリンシパル名(SPN)とともにTGTをTGSに送信します。

2. KDCはTGTを検証し、ユーザークライアントマシンのアクセス権を確認します。

3. TGSはクライアントにサービス固有のセッションキーを送信します。

4. クライアントは、アクセスを証明するためにサービスにセッションキーを提供し、サービスはアクセスを許可します。

WSAでのKerberos認証のフロー

1. クライアントはWSAを介したwww.google.comへのアクセスを要求します。

2. WSAはHTTP 407ステータスで応答し、認証を求めます。

3. クライアントは、ドメイン参加中に取得したTGTを使用して、HTTP/wsa.domain.comサービスのADサーバからのサービスチケットを要求します。

4. ADサーバはクライアントを検証し、サービスチケットを発行します。成功してWSAのSPN（サービスプリンシパル名）が見つかった場合、次のステップに進みます。

5. クライアントはこのチケットをWSAに送信します。

6. WSAがチケットを復号化し、認証を確認します。

7. 認証に成功すると、WSAはポリシーを確認します。

8. トランザクションが許可されると、WSAはHTTP 200 OK応答をクライアントに送信します。

SPNの目的は何ですか。

サービスプリンシパル名(SPN)は、Kerberos認証のサービスインスタンスを一意に識別します。サービスインスタンスをサービスアカウントにリンクするため、クライアントはアカウント名がなくてもサービスの認証を要求できます。ADやOpen LDAPなどのキー配布センター(KDC)実装の各アカウントには、SPNがあります。SPNはサービスを厳密に識別しますが、サービスがクライアントとしても機能するシナリオでクライアント名(UPN)を参照するために誤って使用されることがあります。

Kerberosでは、サービスプリンシパル名(SPN)によって、ネットワーク内のサービスインスタンスが一意に識別されます。クライアントが特定のサービスの認証を要求できる。SPNはサービスインスタンスをそのアカウントにリンクし、Kerberosがそのサービスへのアクセス要求を正しく認証および承認できるようにします。

Active Directoryサーバの設定

- 新しいユーザーアカウントを作成するか、使用する既存のユーザーアカウントを選択します

- 選択したユーザーアカウントに対して使用するSPNを登録します

- 重複したSPNが登録されていないことを確認します

ヒント:WSAがロードバランサの背後にある場合と、トラフィックマネージャ/トラフィックシェーパの背後にある場合では、Kerberosにどのような違いがありますか。HA仮想ホスト名のSPNをユーザアカウントに関連付ける代わりに、HTTPトラフィックリダイレクトデバイス（例：LoadBalancerまたはTraffic Manager）のSPNをADのユーザアカウントに関連付けます。

SPNコマンドを使用したKerberosのトラブルシューティング

以下は、Kerberos環境でサービスプリンシパル名(SPN)を管理するのに役立つ'setspn'コマンドの一覧です。これらのコマンドは通常、Windows環境で管理者特権を持つコマンドラインインターフェイスから実行されます。

特定のアカウントのSPNを一覧表示します：

setspn -L <ユーザー/コンピューターアカウント名>

指定したアカウントに登録されているすべてのSPNを一覧表示します。

アカウントにSPNを追加します：

setspn -A <SPN> <ユーザー/コンピューターアカウント名>

指定されたSPNを指定されたアカウントに追加します。

アカウントからSPNを削除します：

setspn -D <SPN> <ユーザー/コンピューターアカウント名>

指定されたSPNを指定されたアカウントから削除します。

SPNがすでに登録されているかどうかを確認します。

setspn -Q <SPN>

指定したSPNがドメインに既に登録されているかどうかを確認します。

ドメイン内のすべてのSPNを一覧表示します

setspn -L <ユーザー/コンピューターアカウント>

ドメインのすべてのSPNを一覧表示します。

コンピューターアカウントのSPNを設定します：

setspn -S <SPN> <User/ComputerAccountName>

コンピューターアカウントにSPNを追加し、重複したエントリがないようにします。

特定のアカウントのSPNをリセットします：

setspn -R <ユーザー/コンピューターのアカウント名>

指定されたアカウントのSPNをリセットし、重複するSPNの問題を解決するのに役立ちます。

SPNコマンドと出力の例

次に例を示します。

ユーザ/コンピュータアカウント：vrrpserviceuser

SPN:http/WsaHostname.comまたはhttp/proxyha.localdomain

- SPNが既にユーザーアカウントに関連付けられているかどうかを確認してください：

setspn -q <SPN>

setspn -q http/proxyha.localdomain

シナリオ1: SPNが見つかりません

シナリオ2: SPNが見つかりました

- SPNを有効なユーザー/コンピューターアカウントに関連付けます：

構文： setspn -s <SPN> <ユーザー/コンピューターアカウント>

例：setspn -s http/proxyha.localdomain vrrpserviceuser

- すでに関連付けられているSPNの削除

ユーザー/コンピューターアカウント：

構文： setspn -d <SPN> <ユーザー/コンピューターアカウント>

例：setspn -d http/proxyha.localdomain pod1234-wsa0

後で障害が発生する可能性があるため、HA仮想ホスト名に重複するSPNがないことを確認します。

使用するコマンド：setspn -x

その結果、Kerberosサービスチケットがクライアントに提供されず、Kerberos認証が失敗します。

注意：重複が見つかった場合は、setspn -dコマンドを使用して重複を削除してください

- アカウントに関連付けられたすべてのSPNを一覧表示します：

構文： setspn -l <ユーザー/コンピューターアカウント>

例：setspn -l vrrpserviceuser

WSAでのKerberosのトラブルシューティング

Kerberos認証の問題のトラブルシューティング時にTACが入手する必要がある情報

- 現在の構成の詳細

- 認証ログ（デバッグモードまたはトレースモードが望ましい）

- 取得されたパケットキャプチャ（適切なフィルタを使用）:

イクライアントデバイス

(b) WSA

- %m個のカスタム形式指定子が有効なアクセスログです。これは、特定のトランザクションに使用された認証メカニズムを示す必要があります。

ヒント：認証の詳細を確認するには、動作しているプロキシまたは動作していないプロキシのアクセスログに次のカスタムフィールドを追加して、詳細を確認してください

WSA GUIで、> System administration > Log subscription > Access logs > Custom fields > Add this string for authentication issuesの順に移動します。

サーバIPアドレス= %k、クライアントIPアドレス= %a、Auth-Mech = %m、Auth_Type= %m、Auth_group= %g、Authenticated_Username= %A、日付= %L、Transaction_ID= %I認証応答= %:<a、認証合計= %:>a;

ユーザ認証の詳細に関するWSAアクセスログスナップショット

- よくあるエラーの例に、「Server not found in Kerberos database」で失敗するWeb要求があります。

curl -vx proxyha.localdomain:3128 —proxy-negotiate -u:http://www.google.com/

* プロキシproxyha.localdomainポート3128 (#0)に接続しようとしています。

* proxyha.localdomain(10.8.96.30)ポート3128(#0)に接続

< HTTP/1.1 407プロキシ認証が必要

<経由：1.1 pod1234-wsa02.localdomain:80(Cisco-WSA/10.1.2-003)

<コンテンツタイプ： text/html

gss_init_sec_context()が失敗しました： : Kerberosデータベースにサーバが見つかりません

<プロキシ認証：ネゴシエート

<接続：閉じる

* HTTP/1.1プロキシ接続セットが閉じました！

この場合、エラーは、プロキシアドレス値proxyha.localdomainに対応するサービスプリンシパル名(SPN)がActive Directoryサーバに登録されていないことを示しています。この問題を解決するには、SPN http/proxyha.localdomainがAD DCに登録され、適切なサービスアカウントに追加されていることを確認する必要があります。

- kerberosの実装に関するベストプラクティスは、次のハイパーリンクで説明されています。

セキュアなWebアプライアンスのベストプラクティス

その他の情報と参考資料