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

  • [アーティクル]

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

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

  • Kerberos 関連のエラーは、別のサービスが失敗した症状です。 Kerberos プロトコルは、認証が行われるには、使用可能で適切に機能している必要がある多くのサービスに依存しています。

  • Kerberos 認証で問題が発生しているかどうかを判断するには、認証を提供するクライアント、ターゲット サーバー、またはドメイン コントローラー上の任意のサービス (Kerberos、kdc、LsaSrv、Netlogon など) からのエラーに関するシステム イベント ログをチェックします。 このようなエラーが存在する場合は、Kerberos プロトコルに関連するエラーも発生する可能性があります。

  • ターゲット サーバーのセキュリティ イベント ログに対するエラー監査では、ログオンエラーが発生したときに Kerberos プロトコルが使用されていたことが示される場合があります。

  • Kerberos プロトコルを検査する前に、次のサービスまたは条件が正しく機能していることを確認します。

    • ネットワーク インフラストラクチャが正常に機能しており、すべてのコンピューターとサービスが通信できます。
    • ドメイン コントローラーにアクセスできます。 コマンド nltest /dsgetdc:<Domain Name> /force /kdc (例: ) は、 nltest /dsgetdc:contoso.com /force /kdcクライアントまたはターゲット サーバーで実行できます。
    • ドメイン ネーム システム (DNS) が適切に構成され、ホスト名とサービスが適切に解決されます。
    • クロックはドメイン間で同期されます。
    • Windows Server のすべての重要な更新プログラムとセキュリティ更新プログラムがインストールされます。
    • Microsoft 以外のソフトウェアを含むすべてのソフトウェアが更新されます。
    • サーバー オペレーティング システムを実行している場合は、コンピューターが再起動されます。
    • 必要なサービスとサーバーを使用できます。 Kerberos 認証プロトコルでは、正常に動作するには、機能しているドメイン コントローラー、DNS インフラストラクチャ、およびネットワークが必要です。 Kerberos プロトコルのトラブルシューティングを開始する前に、これらのリソースにアクセスできることを確認します。

これらのすべての条件を調べたが、まだ認証の問題や Kerberos エラーが発生している場合は、解決策をさらに探す必要があります。 この問題は、Kerberos プロトコルの構成方法、または Kerberos プロトコルで動作する他のテクノロジがどのように構成されているかによって発生する可能性があります。

共通の問題と解決策

Kerberos 委任の問題

一般的なシナリオでは、偽装アカウントは、Web アプリケーションまたは Web サーバーのコンピューター アカウントに割り当てられたサービス アカウントです。 偽装されたアカウントは、Web アプリケーションを介してリソースへのアクセスを必要とするユーザー アカウントです。

Kerberos を使用した委任には、次の 3 種類があります。

  • 完全な委任 (制約のない委任)

    完全な委任はできるだけ避ける必要があります。 ユーザー (フロントエンド ユーザーとバックエンド ユーザー) は、異なるドメインと異なるフォレストに配置できます。

  • 制約付き委任 (Kerberos のみおよびプロトコルの移行)

    ユーザーはどのドメインまたはフォレストからでもかまいませんが、フロントエンド サービスとバックエンド サービスは同じドメインで実行する必要があります。

  • リソース ベースの制約付き委任 (RBCD)

    ユーザーは任意のドメインから、フロントエンド リソースとバックエンド リソースは任意のドメインまたはフォレストから取得できます。

最も一般的な Kerberos 委任のトラブルシューティング

  • サービス プリンシパル名が見つからないか、重複している
  • 名前解決エラーまたは誤った応答 (サーバーに対して指定された間違った IP アドレス)
  • 大きな Kerberos チケット (MaxTokenSize) と環境が正しく設定されていない
  • ファイアウォールまたはルーターによってブロックされているポート
  • サービス アカウントに適切な特権が与えられない (ユーザー権利の割り当て)
  • フロントエンドサービスまたはバックエンド サービスが同じドメイン内ではなく、制約付き委任のセットアップ

詳細については、以下を参照してください:

シングル サインオン (SSO) が壊れ、認証を 1 回要求する

次のようなシナリオを考えてみましょう。

  • Microsoft Edge やインターネット インフォメーション サービス (IIS) サーバーなどのクライアントおよびサーバー アプリケーション。 IIS サーバーは、Windows 認証 (ネゴシエート) で構成されています。
  • SMB クライアントや SMB サーバーなどのクライアントおよびサーバー アプリケーション。 既定では、SMB サーバーはネゴシエート セキュリティ サポート プロバイダー インターフェイス (SSPI) で構成されます。

ユーザーが Microsoft Edge を開き、内部 Web サイト http://webserver.contoso.comを参照します。 Web サイトは Negotiate で構成されており、この Web サイトでは認証を求められます。 ユーザーがユーザー名とパスワードを手動で入力すると、ユーザーは認証を受け、Web サイトは期待どおりに動作します。

注:

このシナリオは、クライアントとサーバーの例です。 トラブルシューティング手法は、統合Windows 認証で構成されているクライアントとサーバーで同じです。

統合Windows 認証は、ユーザー レベルまたはマシン レベルで破損しています。

トラブルシューティング方法

  • アプリケーションまたはマシン レベルで有効にできる統合認証設定のクライアント構成を確認します。 たとえば、すべての HTTP ベースのアプリケーションは、統合認証を実行しようとしたときに、信頼されたゾーン内にあるサイトを探します。

    すべての HTTP ベースのアプリケーションがインターネット エクスプローラー 構成に使用するinetcpl.cpl(インターネット オプション) を開き、Web サイトがローカル イントラネットとして構成されているかどうかを確認します。

  • アプリケーションには、統合Windows 認証を実行するための構成もあります。

    Microsoft Edge またはインターネット エクスプローラーには、統合 Windows 認証を有効にする設定があります。

  • アプリケーションの構成を確認し、クライアント コンピューターは、特定のサービス プリンシパル名 (SPN) の Kerberos チケットを取得できます。 この例では、SPN は です http/webserver.contoso.com。

    • SPN が見つかると、成功メッセージが表示されます。

      C:>klist get http/webserver.contoso.com
Current LogonId is 0:0x9bd1f
A ticket to http/webserver.contoso.com has been retrieved successfully.

    • SPN が見つからない場合のエラー メッセージ:

      C:>klist get http/webserver.contoso.com
klist failed with 0xc000018b/-1073741429: The SAM database on the Windows Server does not have a computer account for this workstation trust relationship.

    適切なユーザー、サービス、またはマシン アカウントに対応する SPN を特定して追加します。

  • SPN を取得できることを確認した場合は、次のコマンドを使用して、正しいアカウントに登録されているかどうかを確認できます。

    setspn -F -Q */webserver.contoso.com

認証 DC 検出に関する問題

統合Windows 認証で構成されたアプリケーション サーバーでは、ユーザー/コンピューターとサービスを認証するためにドメイン コントローラー (DC) が必要です。

認証プロセス中にドメイン コントローラーに接続できないと、エラー 1355 が発生します。

指定したドメインが存在しないか、接続できませんでした

統合Windows 認証で構成されたリソースにエラー 1355 でアクセスできない

注:

エラー メッセージはアプリケーションの観点から異なる場合がありますが、エラーの意味は、クライアントまたはサーバーがドメイン コントローラーを検出できないことです。

このようなエラー メッセージの例を次に示します。

  • ドメイン "Contoso" への参加中に、次のエラーが発生しました。
    指定したドメインが存在しないか、接続できませんでした。

  • ドメイン contoso.com のドメイン コントローラーが見つかりませんでした

  • ドメイン コントローラー 1355 に接続できませんでした

問題の上位の原因

  • クライアントでの DNS 構成の誤り

    コマンドを ipconfig /all 実行し、DNS サーバーの一覧を確認できます。

  • 信頼されたドメインまたはフォレスト内のドメイン コントローラーでの DNS 構成の誤り

  • クライアントとドメイン コントローラーの間でブロックされているネットワーク ポート

    DC 検出ポート: UDP 389 (UDP LDAP) と UDP 53 (DNS)

トラブルシューティングの手順

  1. コマンドを nslookup 実行して、DNS の構成ミスを特定します。
  2. クライアントとドメイン コントローラーの間で必要なポートを開きます。 詳細については、「 Active Directory ドメインと信頼のファイアウォールを構成する方法」を参照してください。

ログ分析テスト シナリオ

環境と構成

  • クライアント コンピューター

    Client1.contoso.com(Windows 11 マシン) がドメインContoso.comに参加します。

  • ユーザー John

    ユーザーがに属 Contoso.com し、クライアント コンピューターにサインインします。

  • クライアント コンピューター上のインターネット オプション

    すべての Web サイトは、ローカル イントラネット ゾーンの一部です。

    すべての Web サイトがローカル イントラネット ゾーンの一部であることを示す [インターネットのプロパティ] のスクリーンショット。

  • サーバー

    IISServer.contoso.com (Windows Server 2019) は ドメイン Contoso.comに参加します。

  • 認証の構成

    Windows 認証 は 有効です。

    Windows 認証が有効になっていることを示す [インターネット インフォメーション サービス マネージャー] ウィンドウのスクリーンショット。

  • 認証プロバイダー: ネゴシエート

    有効なプロバイダーは次のように設定されます。

    [有効なプロバイダー] に [ネゴシエート] が含まれていることを示す [プロバイダー] ウィンドウのスクリーンショット。

認証フロー

認証フローのスクリーンショット。

  1. に John サインインすると、 Client1.contoso.comMicrosoft Edge ブラウザーが開き、 に IISServer.contoso.com接続されます。
  2. クライアント コンピューターは、次の手順を実行します (上の図の手順 1)。
    1. DNS リゾルバーは、 IISServer.contoso.com この情報が既にキャッシュされているかどうかを確認するためにキャッシュします。
    2. DNS リゾルバーは、HOSTS ファイルで C:\Windows\System32\drivers\etc\Hosts にある のマッピングIISServer.contoso.comをチェックします。
    3. 優先 DNS サーバー (IP 構成設定で構成) に DNS クエリを送信します。これは、環境内のドメイン コントローラーでもあります。
  3. ドメイン コントローラーで実行されている DNS サービスは、構成されているゾーンを調べたり、ホスト A レコードを解決したり、IP アドレス IISServer.contoso.com で応答したりします (上の図の手順 2)。
  4. クライアント マシンは、TCP ポート 80 から への TCP 3 方向ハンドシェイクを IISServer.contoso.com実行します。
  5. クライアント マシンは、 に匿名 HTTP 要求を送信します IISServer.contoso.com。
  6. ポート 80 でリッスンしている IIS サーバーは、 から Client1.contoso.com要求を受け取り、IIS サーバーの認証構成を調び、認証構成として Negotiate を使用してクライアント コンピューターに HTTP 401 チャレンジ応答を送信します (上の図の手順 3)。
  7. で Client1.contoso.com 実行されている Microsoft Edge プロセスは、IIS サーバーが Negotiate で構成されていることを認識し、Web サイトがローカル イントラネット ゾーンの一部であるかどうかを確認します。 Web サイトがローカル イントラネット ゾーンにある場合、Microsoft Edge プロセスは LSASS.exe を呼び出して SPN HTTP\IISServer.contoso.com を使用して Kerberos チケットを取得します (上の図の手順 5)。
  8. ドメイン コントローラー (KDC サービス) は から Client1.contoso.com要求を受け取り、そのデータベースで SPN を検索し、この SPN HTTP\IISServer.contoso.com で構成されていることを確認 IISServer.contoso.com します。
  9. ドメイン コントローラーは、IIS サーバーのチケットを使用して TGS 応答で応答します (上の図の手順 6)。
  10. クライアント コンピューター上の Microsoft Edge プロセスは、ドメイン コントローラーによって発行された Kerberos TGS チケットを使用して、Kerberos アプリケーション プロトコル (AP) 要求を IIS Web サーバーに送信します。
  11. IIS プロセスは、Web サーバー 上のLSASS.exe を呼び出してチケットを復号化し、承認のために SessionID と Users グループ メンバーシップを持つトークンを作成します。
  12. IIS プロセスは、承認の決定を行い、ユーザーが AP 応答に接続できるように、 LSASS.exe からトークンへのハンドルを取得します。

ワークフローのネットワーク モニター分析

注:

以下のアクティビティを実行するには、ローカルの Administrators グループのユーザーである必要があります。

  1. クライアント コンピューターに Microsoft Network Monitor をインストールします (Client1.contoso.com)。

  2. 管理者特権のコマンド プロンプト ウィンドウ (cmd.exe) で次のコマンドを実行します。

    ipconfig /flushdns

  3. ネットワーク モニターを起動します。

  4. Microsoft Edge ブラウザーを開き、「」と入力します http://iisserver.contoso.com。

  5. ネットワーク トレース分析:

    1. ホスト A レコードのドメイン コントローラーに対する DNS クエリ: IISServer.contoso.com。

      3005    00:59:30.0738430    Client1.contoso.com    DCA.contoso.com    DNS    DNS:QueryId = 0x666A, QUERY (Standard query), Query  for iisserver.contoso.com of type Host Addr on class Internet

    2. ドメイン コントローラー上の DNS サービスからの DNS 応答。

      3006    00:59:30.0743438    DCA.contoso.com    Client1.contoso.com    DNS    DNS:QueryId = 0x666A, QUERY (Standard query), Response - Success, 192.168.2.104

    3. 上の Client1.contoso.com Microsoft Edge プロセスは、IIS Web サーバー IISServer.contoso.com (匿名接続) に接続します。

      3027    00:59:30.1609409    Client1.contoso.com    iisserver.contoso.com    HTTP    HTTP:Request, GET /
Host:  iisserver.contoso.com

    4. IIS サーバーは HTTP 応答 401: ネゴシエートと NTLM (IIS サーバーで実行された構成) で応答します。

      3028    00:59:30.1633647    iisserver.contoso.com    Client1.contoso.com    HTTP    HTTP:Response, HTTP/1.1, Status: Unauthorized, URL: /favicon.ico Using Multiple Authetication Methods, see frame details

WWWAuthenticate: Negotiate
WWWAuthenticate: NTLM

    5. からの Kerberos 要求Client1.contoso.comは、SPN を使用してドメイン コントローラーDCA.contoso.comに送信されます。 HTTP/iisserver.contoso.com

      3034    00:59:30.1834048    Client1.contoso.com    DCA.contoso.com    KerberosV5    KerberosV5:TGS Request Realm: CONTOSO.COM Sname: HTTP/iisserver.contoso.com

    6. ドメイン コントローラー DCA.contoso.com は、Kerberos チケットを使用して TGS 応答を持つ Kerberos 要求で応答します。

      3036    00:59:30.1848687    DCA.contoso.com    Client1.contoso.com    KerberosV5    KerberosV5:TGS Response Cname: John 
Ticket: Realm: CONTOSO.COM, Sname: HTTP/iisserver.contoso.com
Sname: HTTP/iisserver.contoso.com

    7. 現在、 Client1.contoso.com Microsoft Edge プロセスは、Kerberos AP 要求を使用して IIS サーバーに移動します。

      3040    00:59:30.1853262    Client1.contoso.com    iisserver.contoso.com    HTTP    HTTP:Request, GET /favicon.ico , Using GSS-API Authorization
Authorization: Negotiate
Authorization:  Negotiate YIIHGwYGKwYBBQUCoIIHDzCCBwugMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBtUEggbRYIIGzQYJKoZIhvcSAQICAQBugga8MIIGuKADAgEFoQMCAQ6iBwMFACAAAACjggTvYYIE6zCCBOegAwIBBaENGwtDT05UT1NPLkNPTaIoMCagAwIBAqEfMB0bBEhUVFAbF
SpnegoToken: 0x1
NegTokenInit: 
ApReq: KRB_AP_REQ (14)
Ticket: Realm: CONTOSO.COM, Sname: HTTP/iisserver.contoso.com

    8. IIS サーバーは、認証が完了したことを示す応答で応答します。

      3044    00:59:30.1875763    iisserver.contoso.com    Client1.contoso.com    HTTP    HTTP:Response, HTTP/1.1, Status: Not found, URL: / , Using GSS-API Authentication
WWWAuthenticate: Negotiate oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARuIF62dHj2/qKDRV5XjGKmyFl2/z6b9OHTCTKigAatXS1vZTVC1dMvtNniSN8GpXJspqNvEfbETSinF0ee7KLaprxNgTYwTrMVMnd95SoqBkm/FuY7WbTAuPvyRmUuBY3EKZEy
NegotiateAuthorization: 
GssAPI: 0x1
NegTokenResp: 
ApRep: KRB_AP_REP (15)

  6. コマンドを klist tickets 実行して、 のコマンド出力で Kerberos チケットを確認します Client1.contoso.com。

    Client: John @ CONTOSO.COM
Server: HTTP/iisserver.contoso.com @ CONTOSO.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/28/2022 0:59:30 (local)
End Time:   11/28/2022 10:58:56 (local)
Renew Time: 12/5/2022 0:58:56 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DCA.contoso.com

  7. 監査が表示されている IIS サーバーのイベント ID 4624 を Success 確認します。

  • 既定では、 Success または Failure 監査は、Windows のすべてのサーバー オペレーティング システムで有効になっています。 監査が有効になっているかどうかを確認するには、次のコマンドを実行します。

  • 監査が有効になっていない場合は、監査を有効にします。 次の一覧でログオン カテゴリを確認します。 確認できるように、ログオン サブカテゴリは で Success and Failure有効になっています。

    C:\>auditpol /get /Subcategory:"logon"
System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logon                                   Success and Failure

    でログオン Success and Failureを確認しない場合は、コマンドを実行して有効にします。

    C:\>auditpol /set /subcategory:"Logon" /Success:enable /Failure:enable
The command was successfully executed.

IISServer.contoso.com の成功セキュリティ イベント ID 4624 を確認する

次のフィールドを確認します。

  • Logon type: 3 (ネットワーク ログオン)
  • Security IDフィールド:New LogonContoso\John
  • Source Network Address: クライアント マシンの IP アドレス
  • Logon Process と Authentication Package: Kerberos
Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          11/28/2022 12:59:30 AM
Event ID:      4624
Task Category: Logon
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      IISServer.contoso.com
Description:
An account was successfully logged on.

Subject:
    Security ID:        NULL SID
    Account Name:        -
    Account Domain:        -
    Logon ID:        0x0

Logon Information:
    Logon Type:        3
    Restricted Admin Mode:    -
    Virtual Account:        No
    Elevated Token:        No

Impersonation Level:        Impersonation

New Logon:
    Security ID:        CONTOSO\John
    Account Name:        John
    Account Domain:        CONTOSO.COM
    Logon ID:        0x1B64449
    Linked Logon ID:        0x0
    Network Account Name:    -
    Network Account Domain:    -
    Logon GUID:        {<GUID>}

Process Information:
    Process ID:        0x0
    Process Name:        -

Network Information:
    Workstation Name:    -
    Source Network Address:    192.168.2.101
    Source Port:        52655

Detailed Authentication Information:
    Logon Process:        Kerberos
    Authentication Package:    Kerberos

認証ワークフローのトラブルシューティング

次のいずれかの方法を使用して、問題のトラブルシューティングを行います。

  • から IIS Web サーバー (IISServer.contoso.com) Client1.contoso.comの名前を解決できるかどうかを確認します。

  • 次のコマンドレットを使用して、DNS サーバーが正しい IIS サーバー IP アドレスに応答しているかどうかを確認します。

    PS C:\> Resolve-DnsName -Name IISServer.contoso.com

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
IISServer.contoso.com                          A      1200  Answer     192.168.2.104

  • 次のコマンドレットを使用して、クライアント コンピューターと IIS Web サーバー (IISServer.contoso.com) の間でネットワーク ポートが開かれているかどうかを確認します。

    PS C:\> Test-NetConnection -Port 80 IISServer.contoso.com                                                               

ComputerName     : IISServer.contoso.com
RemoteAddress    : 192.168.2.104
RemotePort       : 80
InterfaceAlias   : Ethernet 2
SourceAddress    : 192.168.2.101
TcpTestSucceeded : True

  • ドメイン コントローラーから Kerberos チケットを取得しているかどうかを確認します。

    1. Web サイトにアクセスしようとしているユーザーのコンテキストで、通常のコマンド プロンプト (管理者コマンド プロンプトではない) を開きます。

    2. klist purge コマンドを実行します。

    3. コマンドを klist get http/iisserver.contoso.com 次のように実行します。

      PS C:\> klist get http/iisserver.contoso.com

Current LogonId is 0:0xa8a98b
A ticket to http/iisserver.contoso.com has been retrieved successfully.

Cached Tickets: (2)

#0>     Client: John @ CONTOSO.COM
        Server: krbtgt/CONTOSO.COM @ CONTOSO.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 11/28/2022 1:28:11 (local)
        End Time:   11/28/2022 11:28:11 (local)
        Renew Time: 12/5/2022 1:28:11 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: DCA.contoso.com

#1>     Client: John @ CONTOSO.COM
        Server: http/iisserver.contoso.com @ CONTOSO.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 11/28/2022 1:28:11 (local)
        End Time:   11/28/2022 11:28:11 (local)
        Renew Time: 12/5/2022 1:28:11 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: DCA.contoso.com

      列に SPN http/IISServer.contoso.comCached Ticket (2) の Kerberos チケットが表示されます。

  • IIS Web サービスが既定の資格情報を使用して IIS サーバーで実行されているかどうかを確認します。

    Web サイトにアクセスしようとしているユーザーのコンテキストで、通常の PowerShell プロンプト (管理者の PowerShell プロンプトではない) を開きます。

    PS C:\> invoke-webrequest -Uri http://IIsserver.contoso.com -UseDefaultCredentials
PS C:\> invoke-webrequest -Uri http://IIsserver.contoso.com -UseDefaultCredentials


StatusCode        : 200
StatusDescription : OK
Content           : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
                    <html xmlns="http://www.w3.org/1999/xhtml">
                    <head>
                    <meta http-equiv="Content-Type" cont...
RawContent        : HTTP/1.1 200 OK
                    Persistent-Auth: true
                    Accept-Ranges: bytes
                    Content-Length: 703
                    Content-Type: text/html
                    Date: Mon, 28 Nov 2022 09:31:40 GMT
                    ETag: "3275ea8a1d91:0"
                    Last-Modified: Fri, 25 Nov 2022...

  • IIS サーバーのセキュリティ イベント ログを確認します。

    • 成功イベント ログ 4624
    • エラー イベント ログ 4625

  • 分離のプロセス: 以下のトラブルシューティング手順を使用して、IIS サーバー上の他のサービスが Kerberos 認証を処理できるかどうかを確認できます。

    前提条件:

    • IIS サーバーは、サーバー バージョンの Windows を実行している必要があります。

    • IIS サーバーには、SMB (ポート 445) などのサービス用に開かれたポートが必要です。

    • 新しい共有を作成するか、コンピューター上で既に共有されているいずれかのフォルダー (Software$など) で読み取りアクセス許可をユーザーJohnに付与します。

      1. Client1.contoso.comにサインインします。

      2. エクスプローラを開きます。

      3. 「\IISServer.contoso.com \Software$」と入力します。

      4. で [セキュリティ イベント] を IISServer.contoso.com 開き、イベント ID 4624 が表示されているかどうかを確認します。

      5. で通常のコマンド プロンプト Client1.contoso.com をユーザー Johnとして開きます。 コマンドを klist tickets 実行し、チケット CIFS/IISServer.contoso.comを確認します。

        #1>     Client: John @ CONTOSO.COM
        Server: cifs/iisserver.contoso.com @ CONTOSO.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 11/28/2022 1:40:22 (local)
        End Time:   11/28/2022 11:28:11 (local)
        Renew Time: 12/5/2022 1:28:11 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: DCA.contoso.com

      6. でネットワーク トレースを収集します Client1.contoso.com。 ネットワーク トレースを確認して、失敗したステップを確認して、手順をさらに絞り込んで問題のトラブルシューティングを行うことができます。