次の方法で共有

Kerberos 認証のトラブルシューティング ガイダンス

このガイドでは、Kerberos 認証の問題をトラブルシューティングするときに従う基本的な概念について説明します。

Von Bedeutung

この記事では、一般的なガイダンスを提供します。 ここで説明する手順と例を、特定の構成に合わせて調整する必要がある場合があります。

トラブルシューティングのチェックリスト

Kerberos プロトコルは、いくつかのインフラストラクチャ コンポーネントとサービスに依存しています。 これらのコンポーネントまたはサービスのいずれかが使用できないか、機能していない場合は、認証の問題が発生する可能性があります。

1. イベントとログを確認する

イベント ログで問題の兆候を確認します。 イベント ビューアーを使用して、認証操作に関係するシステムのセキュリティ ログとシステム ログを確認します。

  • 認証クライアント
  • ターゲット サーバーまたはサービス
  • ドメイン コントローラー

特に、Kerberos 認証または依存しているサービスに関連する可能性のあるソースからのイベント (次のソースなど) を探します。

  • Kerberos
  • キー配布センター (KDC)
  • LSA (LsaSrv)
  • Netlogon

ターゲット サーバーで、セキュリティ ログでエラー監査を確認します。 このようなエラーは、認証エラーが発生したときに Kerberos プロトコルが使用されることを示している可能性があります。

一部のイベントまたはエラーは、特定の問題を示します。 影響を受けるコンピューターのいずれかが次のいずれかのイベントまたはエラーを記録した場合は、リンクを選択して、より詳細なトラブルシューティング情報を確認してください。

イベントまたはエラー トラブルシューティング情報
イベント ID 4、エラー KERB_AP_ERR_MODIFIED クライアントがサービス チケットの暗号化を解除できませんでした。 複数の問題によってこのエラーが発生する可能性があるため、関連するイベントを確認してください。 たとえば、この文字列は、クライアントとターゲット サーバーのクロックが同期されていないこと、または SPN が一意ではないことを意味する場合があります。 マルチドメイン環境では、サービス アカウント名がフォレスト (またはその他の信頼されたフォレスト) で一意ではない可能性があります。
詳細については、「 Kerberos クライアントがサーバーからKRB_AP_ERR_MODIFIEDエラーを受け取り 、 Kerberos がKDC_ERR_S_PRINCIPAL_UNKNOWNまたはKDC_ERR_PRINCIPAL_NOT_UNIQUEエラーを生成する」を参照してください。
イベント ID 4、エラー KERB_AP_ERR_SKEW コンピューターのクロックが同期されていることを確認する
イベント ID 14 信頼されたドメイン内のリソースにアクセスするときの "サポートされていない etype" エラー
イベント ID 16 またはイベント ID 27 Kerberos の DES が無効になっている場合、KDC イベント ID 16 または 27 がログに記録されます
Windows Server 2003 ドメイン コントローラーでのイベント ID 27 KDC エラー
エラー 1069 SPN が正しく設定されていないためにサービス ログオンが失敗する
イベント ID 5719、エラー 1311、またはエラー 1355 イベント ID 5719、エラー 1311、またはエラー 1355 - ドメイン コントローラーまたはドメインが見つかりません

修正方法がわかっている問題を確認した場合は、まずその問題を修正してから、続行する前にもう一度認証を試してください。

2. インフラストラクチャを確認する

--- クライアント アプリとターゲット サービスが同じコンピューター上にないことを確認します

既定では、クライアント アプリとターゲット サービスが 1 台のコンピューターにインストールされている場合、Kerberos は無効になります。 クライアント アプリケーションとターゲット サービスを別のコンピューターにインストールできない場合は、Windows で特定のセキュリティ関連の設定を変更する必要があります。 さらに、レジストリ キーを変更する必要がある場合もあります。 このシナリオに関連する問題とその影響を受ける特定の設定の詳細については、「 サーバーにローカルでアクセスしようとするとエラー メッセージが表示される」を参照してください。

変更を加えた場合は、続行する前にもう一度認証を試してください。

b。 クライアント コンピューター、ターゲット サーバー、およびリソース サーバーが適切なドメインに参加していることを確認します

必要に応じて、クライアント コンピューターまたはターゲット サーバーを適切なドメインに参加させます。 次に、もう一度認証を試みます。

注

このコンテキストでは、"適切なドメイン" は、1 つのフォレスト内または信頼関係を持つフォレストのセット内のドメインです。

c. ターゲット サーバーとそのサポート サービスの正常性を確認する

アプリケーションまたはフロントエンド サービス (Web サービスなど) とバックエンド サービス (SQL Server サービスなど) が実行されていることを確認します。

注

"サービスでエラー 1069 が生成されました: ログオンエラーが原因でサービスが開始されませんでした" のようなメッセージが表示される場合があります。このメッセージが表示される場合は、「 SPN が正しく設定されていないためにサービス ログオンが失敗する」を参照してください。

d. 正しいポートが使用可能であることを確認します

クライアント コンピューター、ドメイン コントローラー、およびターゲット サーバー間のすべてのファイアウォール (各コンピューターの Windows ファイアウォールを含む) を確認します。 次のポートでトラフィックが許可されていることを確認します。

注

この一覧では、 server:client ポート、サーバー ポート形式を使用します 。

  • DHCP: 67 (UDP)、67 (UDP)
  • DNS: 49152 -65535 (TCP、UDP)、53 (TCP、UDP)
  • 証明書ベースの認証を含む HTTPS: 443 (TCP)、443 (TCP)
  • Kerberos: 49152 -65535 (TCP、UDP)、88 (TCP、UDP)
  • Kerberos パスワードの変更: 49152 -65535 (TCP)、464 (TCP、UDP)
  • LDAP (DC ロケーターを含む): 49152 -65535 (TCP、UDP)、389 (TCP、UDP)
  • LDAP SSL: 49152 -65535 (TCP)、636 (TCP)
  • SMB: 49152 -65535 (TCP、UDP)、445 (TCP)
  • RPC エンドポイント マッパー: 49152 -65535 (TCP)、135 (TCP)
  • LSA、SAM、NetLogon 用 RPC: 49152 -65535 (TCP)、49152-65535 (TCP)
  • W32Time: 49152 -65535 (UDP)、123 (UDP)

ファイアウォール設定を変更する場合は、もう一度認証を試してください。

え ドメイン コントローラーが使用可能であることを確認する

クライアントがサービスまたはアプリケーション ("ターゲット サーバー" と呼ばれます) に接続しようとすると、認証、承認、委任を容易にするために、クライアントとターゲット サーバーの両方にドメイン コントローラーが必要です。

クライアント コンピューターで、管理者特権のコマンド プロンプト ウィンドウを開き、次のコマンドを実行します。

nltest /dsgetdc:<DomainName> /force /kdc

注

このコマンドでは、 <DomainName> は、クエリを実行するコンピューターのドメインの名前を表します。

nltest コマンドは、使用可能なドメイン コントローラーの一覧を取得します (ただし、一覧に使用可能なすべてのドメイン コントローラーが含まれていない場合があります)。 後の手順で使用するために、これらのドメイン コントローラーの完全修飾ドメイン名と IP アドレスを記録します。

クライアントまたはターゲット サーバーがドメイン コントローラーに接続できない場合は、次のようなメッセージが表示されます ("エラー 1355" というラベルが付いている場合があります)。

指定したドメインが存在しないか、またはアクセスできません。

このメッセージが表示される場合は、トラブルシューティングの詳細については、「 イベント ID 5719、エラー 1311、またはエラー 1355 - ドメイン コントローラーまたはドメインが見つかりません 」を参照してください。 それ以外の場合は、このチェックリストに進んでください。

f. クライアントとターゲット サーバーの間で DNS が動作していることを確認する

クライアント コンピューターで、管理コマンド プロンプト ウィンドウを開き、次のコマンドを実行します。

nslookup <TargetName>

注

このコマンドでは、 <TargetName> はターゲット サーバーの NetBIOS 名を表します。

nslookup コマンドでターゲット サーバー名が正しく解決された場合、DNS 構成は正しいです。 コマンドでターゲット サーバー名が解決されない場合は、次の手順に従ってクライアント コンピューターのネットワーク アダプターの構成を確認します。

  1. クライアント コンピューターで、次のコマンドを実行します。

    ipconfig /all

  2. コマンド出力で、使用中のネットワーク アダプターを決定します。 次のアダプター設定を確認します。

    • クライアント IP アドレス

    • サブネット マスク

    • デフォルト ゲートウェイ

    • 接続固有の DNS サフィックス

    • DNS サーバーの IP アドレス

      IP アドレスを記録し、どの DNS サーバーが優先され、どの DNS サーバーがセカンダリであるかを確認します。 この情報は、後のトラブルシューティングに役立ちます。

    これらの設定のいずれかが正しくない場合は、修正するか、DNS 管理者に問い合わせてください。 変更を加えた場合は、もう一度 nslookup <TargetName> 実行します。

それでも DNS が正しく機能しない場合は、次の手順に従います。

  1. クライアント コンピューターで次のコマンドを実行します。

    nslookup <ClientName> <DNSIPAddress>

    注

    このコマンドでは、 <ClientName> はクライアント コンピューターの NetBIOS 名を表し、 <DNSIPAddress> は、クライアントが使用するように構成されている DNS サーバーの IP アドレスを表します。 まず、前の手順で記録した優先 DNS サーバーの IP アドレスを使用します。 コマンドが機能しない場合は、クライアントのセカンダリ DNS サーバーの IP アドレスを使用して再試行してください。

    たとえば、クライアント コンピューターの名前が "client1" で、クライアントの優先 DNS サーバーの IP アドレスが 10.0.0.1 の場合は、次のコマンドを実行します。

    nslookup client1 10.0.0.1

  2. ターゲット サーバーから同じコマンドを実行します。 次のコマンドのようになります。

    nslookup <TargetName> <DNSIPAddress>

    注

    このコマンドでは、 <TargetName> はターゲット サーバーの NetBIOS 名を表し、 <DNSIPAddress> は、ターゲット サーバーが使用するように構成されている DNS サーバーの IP アドレスを表します。 まず、前の手順で記録した優先 DNS サーバーの IP アドレスを使用します。 コマンドを初めて実行しても機能しない場合は、ターゲット サーバーのセカンダリ DNS サーバーの IP アドレスを使用して再試行してください。

    たとえば、ターゲット サーバーの名前が "WebServer1" で、ターゲット サーバーの優先 DNS サーバーの IP アドレスが 10.0.0.1 の場合は、次のコマンドを実行します。

    nslookup WebServer1 10.0.0.1

    次の表は、 nslookup クエリの可能性のある結果とその影響をまとめたものです。

    ターゲット クエリ
    成功    		 ターゲット クエリ
    失敗
    クライアント クエリ
    成功    		 DNS の問題なし ターゲットまたは少なくとも 1 つの DNS サーバーに影響する問題
    クライアント クエリ
    失敗    		 クライアントまたは少なくとも 1 つの DNS サーバーに影響する問題 1 つ以上の DNS サーバーに影響する問題

クエリ結果に DNS の問題が示されている場合は、次の記事を参照してヘルプを参照してください。

DNS の問題を解決しても Kerberos の問題が残っている場合は、次のトラブルシューティング方法を試してください。

ジー コンピューターのクロックが同期されていることを確認する

クライアント コンピューターまたはターゲット サーバーは、将来使用するためにチケットをキャッシュできます。 ただし、各チケットには、有効期間 (TTL) を決定するタイムスタンプがあります。 ドメイン コントローラーで実行される Kerberos キー配布センター サービスは、タイムスタンプを設定します。

ドメイン コントローラーとクライアント コンピューターまたはターゲット サーバーの時間の差は、5 分未満にする必要があります。 通常、クロックが同期されていない場合、Windows はそれらを自動的に再同期できます。 アクションを実行する必要がある場合は、次の 2 つがあります。

  • クロックが48時間以上ずれている。
  • 同期外クロックでは、ドメイン内のドメイン コントローラーがタイム サーバーとして使用されたり、それらのドメイン コントローラーと同じタイム サーバーが使用されたりすることはありません。

この問題を解決するには、影響を受けるコンピューターでタイム サーバーのネットワークを再確認し、独自のクロックを再同期する必要があります。 これらのアクションを有効にするには、管理コマンド プロンプト ウィンドウを開き、次のコマンドを実行します。

w32tm /resync /computer:<Target> /rediscover

注

このコマンドでは、 <Target> は、構成するコンピューターを表します。 /rediscover オプションは、ネットワークで新しいタイム ソースまたは更新されたタイム ソースをチェックするようにコンピューターに指示します。

w32tm コマンドで使用できるオプションの詳細については、「Windows タイム サービス ツールと設定: W32Time のコマンド ライン パラメーター」を参照してください。

クロックを再同期する場合は、もう一度認証してみてください。

h. Windows Update の状態を確認する

すべてのドメイン コントローラー、クライアント コンピューター、およびターゲット サーバーに関連する Windows 更新プログラムがあることを確認します。

更新プログラムをインストールした場合は、影響を受けるコンピューターを再起動してから、もう一度認証を試してください。

一. アプリケーションの更新状態を確認する

クライアント コンピューターとターゲット サーバーで、クライアント アプリケーションとサーバー アプリケーションが最新であることを確認します。 更新プログラムをインストールする場合は、影響を受けるコンピューターを再起動してから、もう一度認証を試してください。

j. コンピューターを再起動する

クライアント コンピューター、ターゲット サーバー、またはドメイン コントローラーをまだ再起動していない場合は、ここで再起動します。 コンピューターの再起動後、もう一度認証を試してください。

インフラストラクチャで問題が解決しない場合は、さらに高度なトラブルシューティング手順に進んでください。

3. トレースデータとチケットデータを収集する

次の手順では、無料の ネットワーク モニター ツールを使用します。 クライアント コンピューターとターゲット サーバーの両方にツールをダウンロードしてインストールします。 ネットワーク モニターを使用してトレース データを収集し、Kerberos メッセージを識別する方法の例については、 ネットワーク キャプチャの Kerberos エラーを参照してください。

--- 同時にネットワーク トレースを収集する

クライアント コンピューターで、次の手順に従います。

  1. 次のいずれかのアクションを実行します。

    • クライアント コンピュータを再起動します。
    • トラブルシューティングに使用しているアカウントからサインアウトしてから、もう一度サインインします。
    • クライアント アプリケーションを閉じてから、もう一度開きます。

  2. トレースを開始します。 この手順を実行するには、以下のステップに従ってください。

    1. [ スタート] を選択し、「 netmon」と入力します。
    2. 検索結果で、 Microsoft Network Monitor 3.4 を右クリックし、[ 管理者として実行 ] を選択します ([ユーザー アカウント制御] ウィンドウで [ はい ] を選択します)。
    3. ネットワーク モニターで、[ スタート] を選択します。

  3. 管理コマンド プロンプト ウィンドウを開き、次のコマンドを順番に実行します。

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

ターゲット サーバーで、次の手順に従います。

  1. 管理者としてネットワーク モニターを開き、[開始] を選択 します。

  2. 管理コマンド プロンプト ウィンドウを開き、次のコマンドを順番に実行します。

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

あなたの問題を再現し、それからクライアント コンピューターとターゲット サーバーの両方でトレースを停止して保存してください。 これを行うには、ネットワーク モニターで [ 停止] を選択し、[ 名前を付けて保存] を選択します。

b。 チケット情報を記録する

問題を再現してトレースを停止したら、トレース データの記録中に生成された Kerberos チケットを確認します。 クライアント コンピューターとターゲット サーバーのコマンド プロンプトで、次のコマンドを実行します。

klist tickets

このコマンドを実行すると、チケットの一覧が生成されます。 この情報は、後のトラブルシューティング手順で使用できるように、別のアプリケーション (メモ帳など) にコピーできます。

4. Kerberos メッセージのトレース データを確認する

ネットワーク モニターを使用すると、キャプチャ ファイル内のデータを確認、フィルター処理、検索できます。 特に、"KerberosV5" を使用してラベル付けされたイベントを探します。これらのイベントは、状態情報を提供します。 また、接続されたドメイン コントローラーの名前または IP アドレスと、クライアントが到達しようとしたサービスのサービス プリンシパル名 (SPN) を一覧表示することもできます。

次のような文字列を含むイベントの説明は、一般的な Kerberos 関数の一部です。

  • KerberosV5:KRB_Error -KDC_ERR_PREAUTH_REQUIRED
  • KerberosV5:AS 要求
  • KerberosV5:AS 応答
  • KerberosV5:TGS 要求
  • KerberosV5:TGS 応答
  • KerberosV5:AP 要求
  • KerberosV5:AP 応答

注

また、ネットワーク モニターを使用して、HTTP GET 要求のチケット情報のトレース データを確認することもできます。 GET 要求にチケット情報がない場合、Kerberos 認証の使用に問題が発生しました。

次のような文字列を含むイベントの説明は、問題があることを意味します。 次の一覧には、最も一般的なエラーの一部が含まれています。 これらの文字列のいずれかが表示される場合は、後で使用するためにサーバー名、IP アドレス、および SPN をメモします。

  • KDC_ERR_PRINCIPAL_NOT_UNIQUEまたはKDC_ERR_S_PRINCIPAL_UNKNOWN。 要求された SPN は、複数のアカウントに関連付けられているか、どのアカウントにも関連付けられません。 どちらかの問題を解決する際は、Kerberos でKDC_ERR_S_PRINCIPAL_UNKNOWNまたはKDC_ERR_PRINCIPAL_NOT_UNIQUEエラーが発生に関する記事を参照してください。

  • KRB_AP_ERR_MODIFIED。 クライアントがサービス チケットの暗号化を解除できませんでした。 複数の問題によってこのエラーが発生する可能性があります。 トレース データで、KRB_AP_ERR_MODIFIEDに付随するその他のエラーを確認します。 1 で説明されているように、イベント ID 4 とその他の関連イベントのイベント ログを確認します 。イベントとログを確認します。

  • ERB_AP_ERR_SKEW。 クライアントとターゲット サーバーのクロックが同期されていません。詳細については、「 コンピューターのクロックが同期されていることを確認する」を参照してください。

  • KDC_ERR_ETYPE_NOTSUPP。 認証に関係する 1 つ以上のコンポーネントが、他のコンポーネントで無効になっている暗号化の種類を使用します。 1 で説明されているように、イベント ログで、関連するコンポーネントと暗号化の種類の詳細を確認します 。イベントとログを確認します。

一般的な問題と解決方法

HTTP 400 - 無効な要求 (要求ヘッダーが長すぎます) の問題

ユーザーが多数のグループ (たとえば、1,000 を超えるグループ) に属している場合、Kerberos は要求を正しく処理しないため、ユーザー アクセスを拒否する可能性があります。 この問題の詳細については、次の記事を参照してください。

サービスに関する問題

通常、サービスの問題には SPN とサービス アカウントが含まれます。 たとえば、SPN が正しくない、見つからない、正しくないアカウントで構成されている、または複数のアカウントで構成されている可能性があります。 この記事のトラブルシューティング チェックリスト a. この記事の前半で 同時にネットワーク トレースを収集 します。 SPN の一般的な問題を既に特定している場合は、次の記事を参照してください。

シングル サインオン (SSO) に関する問題

シングル サインオンは、ユーザーが 1 つの資格情報セットを使用して 1 つのイントラネット内の複数のシステムまたはアプリケーションにサインインできるようにする認証方法です。 正しく動作するには、ターゲット サービス (またはターゲット サービスのフロントエンド コンポーネント) とクライアントの両方に正しい設定が必要です。 これらの設定のトラブルシューティング方法については、「 Kerberos シングル サインオンの問題のトラブルシューティング」を参照してください。

委任の問題

ターゲット サービスに個別のフロントエンド コンポーネントとバックエンド コンポーネントがある場合、Kerberos はクライアント資格情報 (アクセス許可を含む) をサービス アカウントに委任できます。 簡単に言うと、クライアントはフロントエンド サービスにアクセスし、フロントエンド サービスはクライアントの代わりにバックエンド サービスにアクセスします。

Kerberos では、次の 3 種類の委任がサポートされています。

  • 制約のない委任。 クライアントがフロントエンド サービスにアクセスすると、フロントエンド サービスはクライアントの代わりに他のサービスにアクセスできます。 この構成は実装が最も簡単ですが、安全性も最も低くなります。 認証されたアカウントが対話できるサービスが制限されないため、制約のない委任はお勧めしません。
  • 制約付き委任。 フロントエンド サービスは、クライアントの代わりにアクセスできるサービスの一覧を保持します。
  • リソースベースの制約付き委任 (RBCD)。 バックエンド サービスは、クライアントの代わりにバックエンド サービスへのアクセスを要求できるフロントエンド サービスの許可リストを保持します。

注

CIFS と共に制約付き委任を使用するときに問題が発生した場合は、「CIFS の制約付き委任が失敗し、ACCESS_DENIEDエラーが発生する」を参照してください。

Von Bedeutung

  • フロントエンド サーバーとバックエンド サーバーの同じセットで、制約付き委任と RBCD を構成しないでください。

    制約付き委任と RBCD は異なる構成であり、相互に排他的です。 フロントエンド サービスがバックエンド サービスへのチケットを要求すると、KDC は最初にフロントエンド サービスで制約付き委任をチェックします。 制約付き委任がフロントエンド サービス用に構成されていない場合、KDC はリソースベースの制約付き委任についてバックエンド サービスをチェックします。 この順序のため、制約付き委任はリソース ベースの委任よりも優先されます。

  • 既定では、Microsoft Edge は制約のない委任をサポートしていません。 制約のない委任を使用している場合は、必要な構成の詳細については、 Microsoft Edge (Chromium) による Kerberos の制約のないダブルホップ認証 を参照してください。

  • 制約のない委任は、認証されたアカウントが対話できるサービスを制限しないため、お勧めしません。

サポートされているトポロジの種類

委任の種類によって、トポロジに異なる要件が設定されます。 次の表に、トポロジの 3 つの一般的な種類と、種類ごとにサポートされている委任の種類 (ある場合) を示します。

トポロジの種類 制約のない委任 制約付き委任 RBCD
すべてのサービスが 1 つのドメインに存在する サポートされています (推奨されません) サポートされています サポートされています
フロントエンド サービスとバックエンド サービスが異なるドメインに存在する サポートされています (推奨されません) サポートされていません サポートされています
フロントエンド サービスとバックエンド サービスが異なる (信頼された) フォレストに存在する サポートされています* (推奨されません) サポートされていません サポート*

* フロントエンド サービスのサービス アカウントが、信頼されたドメイン コントローラーを使用して信頼全体で認証できることを確認します。

特定の委任の種類のトラブルシューティング

委任の構成の詳細は、使用している委任の種類と、フロントエンド サービスが使用するアカウントの種類によって異なります。 委任の問題をさらにトラブルシューティングするには、必要に応じて次の記事を参照してください。

ログ分析テスト シナリオを使用した Kerberos 認証のトラブルシューティング

Kerberos の高度なテストとトラブルシューティングについては、「 ログ分析テスト シナリオを使用して Kerberos 認証をトラブルシューティングする」を参照してください。