次の方法で共有

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

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

元の KB 番号: 2701704

まとめ

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

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

ログ名: セキュリティ
ソース: Microsoft-Windows-Security-Auditing
イベント ID: 4624
タスク カテゴリ: ログオン
レベル: Information
キーワード: 監査の成功
説明:
アカウントが正常にログオンしました。
アカウント名: ユーザー
アカウント ドメイン: 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 と最小セッション セキュリティ NTLMv2 用に構成され、DC は LmCompatiblityLevel=4 用に構成されます。

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

      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 ログオンとしてログに記録します。