監査イベントは、NTLMv2 ではなく NTLMv1 として認証パッケージを示します

  • [アーティクル]

この記事では、認証が実際に NTLMv2 を使用していたが、イベント ログで NTLMv1 を報告する問題について説明します。

適用対象: Windows Server 2012 R2
元の KB 番号: 2701704

概要

ドメイン内のすべてのマシンで 3 以上の lmcompatibilitylevel を使用して、クライアントに NTLMv2 のみを強制的に使用しています。 NTLM を強制するために IP アドレスによるネットワーク共有への接続をテストする際に、サーバーにログオンしたセキュリティ監査イベント (イベント ID 4624) で "認証パッケージ" がまだ NTLMv1 として一覧表示されているのを検出します。

たとえば、Windows Server 2008 R2 上のファイル共有に接続している Windows 7 クライアントでテストします。 ネットワーク トレースは、認証が実際には NTLMv2 を使用していたが、イベント ログに NTLMv1 を報告したことを示しました。

ログ名: セキュリティ
ソース: Microsoft-Windows-Security-Auditing
イベント ID: 4624
タスク カテゴリ: ログオン
レベル: 情報
キーワード: 監査の成功
説明:
アカウントが正常にログオンしました。
アカウント名: ユーザー
アカウント ドメイン: contoso
詳細情報:
ログオン プロセス: NtLmSsp
認証パッケージ: NTLM
転送されたサービス: -
パッケージ名 (NTLM のみ): NTLM V1
キーの長さ: 128

詳細

この結果につながる可能性がある既知のシナリオは 2 つあります。

  • シナリオ A: Windows Server 2003 ドメイン コントローラー

    ユーザーの資格情報を検証するドメイン コントローラーが 2003 ベースのサーバーである場合、この動作を再現できることを発見しました。 Windows Server 2003 には、イベント ログに "認証パッケージ" フィールドが含まれていなかったので、これは Windows Vista で追加された新機能でした。

    ドメイン コントローラーが Windows Server 2008 以降の場合、サーバーは認証パッケージが NTLMv2 として正しく表示されます。 認証プロトコルバージョンのレポートが重要な場合は、Windows Server 2008 以降のドメイン コントローラーを使用することをお勧めします。

    Windows Server 2003 は延長サポート フェーズにあり、サポートは 2015 年 7 月に廃止されます。 「 製品ライフサイクルを検索する」を参照してください。

  • シナリオ B: セキュリティ レベルのネゴシエーションでは、ベスト エフォートを意味する "レガシ" メソッドが使用されます

    このシナリオには、サード パーティのクライアントが含まれます。

    1. お客様には、NTLMv1 用に構成されたサード パーティの SMB クライアントがあります。

    2. ファイル サーバーは LmCompatiblityLevel=5 と最小 sesion セキュリティ NTLMv2 用に構成されており、DC は LmCompatiblityLevel=4 用に構成されています。

    3. サード パーティのクライアント上のユーザーが接続します。 SMB では、予期される名前フィールドと NegotiateFlags を使用して SMB セッション ネゴシエーションにセキュリティ BLOB が表示され、サーバーはネゴシエーションを拒否します。

      NegotiateFlags: 0x60000215 (NTLM v1128-bit encryption, , Sign)
NegotiateNTLM:                    (......................1.........) Requests usage of the NTLM v1 session security protocol.
NegotiateNTLM2:                   (............0...................) Does NOT request usage of the NTLM v1 using the extended session security.

    4. その後、サード パーティのクライアントは、セキュリティ BLOB (拡張セッション セキュリティを示す) を使用せずに再試行します。 この形式では、同じ既知の名前フィールドの一覧は表示されません。また、noNegotiateFlags もあります。 "ClientChallenge" のような一部のフィールドは、クライアントが NTLMv2 ハッシュ処理を実行しようとしていることを示している可能性があります。 ただし、NegotiateFlags がないため、これは DC で NTLMv2 認証要求として到着しません。

    5. サーバーは要求を認証する DC にパッケージを転送し、DC は NTLMv1 を使用しても問題ないため、要求を認証します。

    6. サーバーは成功したログオンを受け取り、DC で指定された NTLMv1 として監査します。

    拡張セッション セキュリティのないログオンの場合、サーバーには、クライアント フラグに基づいてログオン要求をブロックするオプションはありません。 DC に取得した最適なフラグを使用して要求を転送する必要があります。 返却時には、DC がログオン時に行う決定も受け入れる必要があります。 この場合、NTLMv2 のみを許可するようにリソース サーバーが構成されている場合でも、ログオンを受け入れ、NTLMv1 ログオンとしてログに記録します。