SWAでのKerberos認証のトラブルシューティング

概要

このドキュメントでは、Kerberos認証の基本と、Secure Web Appliance(SWA)でのKerberos認証のトラブルシューティング手順について説明します。

用語

• SWA:Secure Web Appliance（セキュアWebアプライアンス）
• CLI：コマンドラインインターフェイス
• AD:Active Directory
• DC:Domain Controller（ドメインコントローラ）
• SPN：サービスプリンシパル名
• KDC:Kerberos Key Distribution Center
• TGT:Ticket Granting Ticket（認証チケット）
• TGS:Ticket Granting Service（チケット認可サービス）
• HA：ハイアベイラビリティ
• VRRP:Virtual Router Redundancy Protocol（仮想ルータ冗長プロトコル）
• CARP:Common Address Redundancy Protocol（共通アドレス冗長プロトコル）
• SPN：サービスプリンシパル名
• LDAP:Lightweight Directory Access Protocol（軽量ディレクトリアクセスプロトコル）

前提条件

要件

次の項目に関する知識があることが推奨されます。

• SWAでの認証とレルム
• Active DirectoryとKerberos認証

使用するコンポーネント

本書の内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

Kerberosネットワークフロー

図：Kerberosネットワークフローの例

Kerberized環境での認証の基本的な手順は次のとおりです。

1. クライアントはKDCにTGTを要求します。

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

3. TGTはTGS秘密キーで暗号化されます。

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

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

1. クライアントは、目的のリソースのSPNとともにTGTをTGSに送信します。
2. KDCはTGTを検証し、ユーザークライアントマシンのアクセス権を確認します。

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

SWAでのKerberos認証のフロー

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

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

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

4. ADサーバはクライアントを検証し、サービスチケットを発行します。成功してSWAのSPNが見つかった場合、次の手順に進みます。

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

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

7. 認証が成功すると、SWAによってポリシーが検証されます。

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

SPNの目的は何ですか。

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

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

Active Directoryサーバの設定

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

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

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

ヒント:ロードバランサまたはトラフィックマネージャ/トラフィックシェーパの背後にあるSWAを使用したKerberosの仕組みはどのように異なりますか。

• HA仮想ホスト名のSPNをユーザアカウントに関連付ける代わりに、HTTPトラフィックリダイレクトデバイス（たとえば、ロードバランサまたはトラフィックマネージャ）のSPNをADのユーザアカウントに関連付けます。

Kerberosの実装に関するベストプラクティスについては、次を参照してください。

• セキュアなWebアプライアンスのベストプラクティス 
• SWA接続用ファイアウォールポートの設定 

トラブルシューティング

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

次に、Kerberos環境でSPNを管理するための便利なsetspnコマンドのリストを示します。これらのコマンドは、通常、Windows環境で管理者権限を持つコマンドラインインターフェイス(CLI)から実行します。

setspn -L 

setspn -A  

setspn -D  

setspn -Q 

setspn -L 

setspn -S  

setspn -R 

SPNコマンドと出力の例

次に例を示します。

• ユーザ/コンピュータアカウント: vrrpserviceuser
• SPN:http/WsaHostname.comまたはhttp/proxyha.localdomain

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

setspn -q 

setspn -q http/proxyha.localdomain

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

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

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

setspn -s  

以下に、いくつかの例を示します。 

setspn -s http/proxyha.localdomain vrrpserviceuser 

• ユーザーまたはコンピューターアカウントに既に関連付けられているSPNを削除します：

setspn -d  

以下に、いくつかの例を示します。 

setspn -d http/proxyha.localdomain pod1234-wsa0

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

• 実行するコマンド

setspn –x

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

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

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

 setspn –l 

以下に、いくつかの例を示します。

setspn –l vrrpserviceuser

SWA上のKerberosのトラブルシューティング

Kerberos認証の問題をトラブルシューティングする際にシスコサポートが必要とする情報：

• 現在の構成の詳細
• 認証ログ（デバッグモードまたはトレースモードが望ましい）
• 取得されたパケットキャプチャ（適切なフィルタを使用）:
  • クライアントデバイス
  • SWA
•  %m個のカスタム形式指定子が有効になっているアクセスログ。これは、特定のトランザクションに使用された認証メカニズムを示す必要があります。
• 認証の詳細については、動作しているプロキシまたは動作していないプロキシのアクセスログにこれらのカスタムフィールドを追加して追加情報を取得するか、「アクセスログへのパラメータの追加」を参照してください。
• SWA GUIで、認証の問題について、System Administration > Log Subscription > Access Logs > Custom Fields > Add this stringの順に移動します。

server IP address = %k, Client IP address= %a, Auth-Mech = %m, Auth_Type= %m, Auth_group= %g, Authenticated_Username= %A, Date= %L, Transaction_ID= %I Auth response = %:a;

• ユーザ認証の詳細に関するSWAアクセスログ。
• Cisco SWAでは、認証されたユーザ名をDomain\username@authentication_realm:の形式で記録します。

• GUIからTest Authentication Realm Settingsを実行します。Network > Authenticationに移動し、Test Current Settingsセクションでレルムの名前をクリックします。
• Start Testをクリックします。

Kerberosデータベースにサーバが見つからない

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

curl -vx proxyha.local:3128 --proxy-negotiate -u: http://www.cisco.com/
* About to connect() to proxy proxyha.localdomain port 3128 (#0)
* Connected to proxyha.local (10.8.96.30) port 3128 (#0)
< HTTP/1.1 407 Proxy Authentication Required
< Via: 1.1 pod1234-wsa02.local:80 (Cisco-SWA/10.1.2-003)
< Content-Type: text/html
gss_init_sec_context() failed: : Server not found in Kerberos database
< Proxy-Authenticate: Negotiate
< Connection: close
* HTTP/1.1 proxy connection set close!

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

関連コンテンツ

• ゲストアクセスを許可するためのセキュアWebアプライアンスの設定 
• SWAでのActive Directory認証の設定 
• SWAでのKerberosシングルサインオン認証の設定 
• Secure Web Applianceでのトラフィックのバイパス