NTLM認証は、に送信されるパケットにおける必要がありますか。

はじめに

このドキュメントでは、NT LAN Manager（NTLM）認証について、パケットレベルで説明します。 

NTLM認証は、に送信されるパケットにおける必要がありますか。

この記事に続くパケットキャプチャは、https://supportforums.cisco.com/sites/default/files/attachments/document/ntlm_auth.zipからダウンロードできます。

クライアントIP:10.122.142.190

WSA IP:10.122.144.182

パケット番号と詳細

4：クライアントがプロキシに GET 要求を送信します。

7：プロキシが 407 を返します。認証が適切に行われていないため、プロキシがトラフィックを許可しないことを意味します。この応答のHTTPヘッダーを見ると、「Proxy-authenticate: NTLM」と表示されています。これは、クライアントに対し、許容される認証方式が NTLM であることを通知するものです。同様に、ヘッダー「Proxy-authenticate: Basic」が存在する場合、プロキシは基本的なクレデンシャルが受け入れ可能であることをクライアントに通知します。両方のヘッダーが存在する場合（一般的）、クライアントは、どちらの認証方式を使用するかを決定します。

注意すべき点の1つは、認証ヘッダーが「Proxy-authenticate:」であるということです。これは、キャプチャの接続で、明示的フォワードプロキシが使用されていることによります。これが透過的なプロキシ導入の場合、応答コードは407ではなく401になり、ヘッダーは「proxy-authenticate:」ではなく「www-authenticate:」になります。

8：プロキシがこの TCP ソケットで FIN を返します。これは正常かつ通常の動作です。

15：新しい TCP ソケットで、クライアントが別の GET 要求を実行します。今回は、GETにHTTPヘッダー「proxy-authorization:」が含まれていることに注意してください。このヘッダーにエンコードされた文字列は、ユーザ/ドメインに関する詳細を記述します。

[Proxy-Authorization] > [NTLMSSP] を展開すると、NTLM データで送信された、デコードされた情報が表示されます。NTLM メッセージタイプでは、それが「LMSSP_NEGOTIATE」であることがわかります。これは、NTLM の 3 ウェイハンドシェイクにおける最初の段階です。

17： プロキシが別の 407 を返します。別の「Proxy-authenticate」ヘッダーが存在します。今度は、NTLM チャレンジ文字列が含まれています。ヘッダーをさらに展開すると、NTLM メッセージ タイプが「NTLMSSP_CHALLENGE」となっていることがわかります。これは、NTLM の 3 ウェイハンドシェイクにおける 2 番目の段階です。

NTLM 認証では、Windows ドメイン コントローラがクライアントにチャレンジ文字列を送信します。次に、クライアントは、この手順でユーザのパスワードを使用するアルゴリズムを NTLM チャレンジに適用します。これにより、ドメイン コントローラは回線を介してパスワードを送信することなく、クライアントが正しいパスワードを知ってることを確認できます。この場合、基本認証のクレデンシャルよりも安全性が高くなります。基本認証では、パスワードがプレーンテキストで送信され、あらゆるスニファデバイスでそうしたパスワードを確認できるからです。

18：クライアントが最後の GET を送信します。この GET リクエストは、NTLM ネゴシエートおよび NTLM チャレンジが行われたのと同じ TCP ソケットに対して行われることに注意してください。これは、NTLM プロセスに非常に重要な点です。ハンドシェイク全体が同じ TCP ソケットで行われなければ、認証は無効になってしまうためです。

この GET リクエストで、クライアントは変更後の NTLM チャレンジ（NTLM 応答）をプロキシに送信します。これは、NTLM の 3 ウェイハンドシェイクにおける最後の段階です。

21：プロキシが HTTP 応答を返します。これは、プロキシがクレデンシャルを受け入れ、コンテンツの提供を決定したことを意味します。