NTLM 認証とは、ネットワーク認証方式の一つです。
Active Directory のドメイン環境では、ユーザーやコンピューターなどのリソースを一元管理できますが、その際の認証方式の基盤は Kerberos 認証や NTLM 認証などで実現されています。基本的には Kerberos 認証が優先して利用されますが、Kerberos 認証が利用できない場合などに代替として NTLM 認証も利用されています。
今回は、NTLM 認証の基本的な仕組みについて紹介したいと思います。
NTML 認証とは
NTLM 認証とは、ネットワーク認証方式の１つです。従来の LM 認証に代わり、Windows NT 3.1 で導入された認証方式となります。NTLM 認証のバージョンとして、NTLMv1 と NTLMv2 があります。
Active Directory のドメイン環境における認証基盤として、Kerberos 認証と NTLM 認証が主に利用されています。基本的には Kerberos 認証の方がセキュアな認証方式であるため、Kerberos 認証が優先して利用されます。しかしながら、認証を必要とするアプリケーションが Kerberos 認証に対応していない等、何らかの理由で Kerberos 認証が利用できない場合の代替として、NTLM 認証が利用されます。
Kerberos 認証の基本的な仕組みについては、以下の記事でも紹介しています。
Kerberos 認証とは、ネットワーク認証方式の一つです。 Active Directory のドメイン環境では、ユーザーやコンピューターなどのリソースを一元管理できますが、その際の認証方式の基盤は Kerberos 認証で実現されていま[…]
NTLM 認証の仕組みは、チャレンジ・レスポンス認証と同様の仕組みとなります。チャレンジ・レスポンス認証とは、チャレンジと呼ばれるランダムな文字列を利用した認証方式です。チャレンジ・レスポンス認証における認証フローにおける通信では、実際のパスワードそのものは送受信しないため、悪意がある第三者が盗聴してもパスワードを割り出すことはできません。
チャレンジ・レスポンス認証とは
チャンレンジ・レスポンス認証とは、パスワードなどの認証情報を直接やり取りせずに認証を行えるネットワーク認証方式の一つです。
チャレンジ・レスポンス認証では、クライアントが ID を指定して認証要求を送信する(①)と、サーバーは「チャレンジ」と呼ばれる乱数を元に生成したランダムな文字列を送信(②)します。この「チャレンジ」は、認証の度に異なる文字列を送信しています。クライアントは、サーバーから「チャレンジ」のデータを受け取ると、チャレンジのデータを加工して「レスポンス」を応答(③)します。「レスポンス」を受け取ったサーバーは、レスポンスが正規のクライアントから加工されたものかを確認して、問題がなければ認証が成功となります。
チャンレンジ・レスポンス認証でやり取りされる「チャンレンジ」と「レスポンス」の情報は、パスワードのような認証情報ではありません。そのため、悪意のある第三者がインターネットを盗聴して、チャレンジやレスポンスの情報を入手したとしても、そこからパスワードなどの認証情報を割り出すことはできません。
ただし、悪意のある第三者がチャレンジ・レスポンス認証での通信を盗聴して、レスポンスの情報をそのまま送信して、本人になりすますリプレイアタック(反射攻撃/replay attack)が行われるリスクがあります。しかし、認証ごとに不規則に変化する「チャレンジ」が利用されるため、リプレイアタックの攻撃についても耐性があります。
一般的に、チャレンジ・レスポンス認証には、以下の３通りの認証方法があります。
- 共通鍵を使った認証
- 証明書による認証
- ダイジェスト認証
チャレンジ・レスポンス認証の各認証方法の詳細は以下の通りです。
共通鍵を使った認証
クライアントとサーバーで共有している共通鍵で、チャレンジを暗号化して認証を行います。この時に使用される共通鍵は、クライアントとサーバーで共有されているパスワードです。
クライアントが認証を要求すると、サーバーは乱数を元に生成したチャレンジを送信します。クライアントはチャンレジを受け取ると、パスワードを共通鍵として、チャレンジの文字列を暗号化します。この暗号化したデータがレスポンスです。クライアントは、このレスポンスをサーバーに認証情報として送信します。サーバーは自身が保持しているクライアントのパスワードを利用して、レスポンスのデータを復号します。復号したデータが、送信したチャレンジと一致していれば認証は成功となります。
証明書による認証
クライアントの証明書を利用して、チャレンジを暗号化して認証を行います。この時に使用される証明書は、サーバーにも共有されており、証明書に紐づいている公開鍵を利用できます。
クライアントが認証を要求すると、サーバーは乱数を元に生成したチャレンジを送信します。クライアントはチャレンジを受け取ると、証明書に紐づく秘密鍵で、チャレンジの文字列を暗号化します。この暗号化したデータがレスポンスです。クライアントは、このレスポンスをサーバーに認証情報として送信します。サーバーはクライアントの証明書に紐づいている公開鍵を利用して、レスポンスのデータを復号します。復号したデータが、送信したチャレンジと一致していれば認証は成功となります。
ダイジェスト認証
ダイジェスト(ハッシュ関数)の技術を利用して、チャレンジのデータを元にハッシュ値を算出して認証を行います。ダイジェストを利用する認証方式では、クライアントとサーバーで共有しているパスワードも利用します。
クライアントが認証を要求すると、サーバーは乱数を元に生成したチャレンジを送信します。クライアントは乱数を受け取ると、チャレンジの文字列とパスワードをかけあわせて、そのデータのダイジェスト(ハッシュ値)を算出します。このダイジェストがレスポンスです。クライアントは、このレスポンスをサーバーに認証情報として送信します。サーバーはレスポンスを受領すると、サーバー自身もサーバーは自身が保持しているクライアントのパスワードとチャレンジをかけあわせてダイジェストを算出し、レスポンスのデータと一致するかを確認します。一致していれば、認証は成功となります。
NTLM 認証
NTLM 認証では、共通鍵の仕組みと類似した認証方式を採択しています。
クライアントが認証を要求すると、サーバーは乱数を元に生成したチャレンジを送信します。クライアントはチャンレジを受け取ると、パスワードのハッシュ値を算出し、ハッシュ値を鍵として、チャレンジの文字列を暗号化します。この暗号化したデータがレスポンスです。クライアントは、このレスポンスをサーバーに認証情報として送信します。サーバーは自身が保持しているクライアントのパスワードのハッシュ値を算出し、算出ｈしたハッシュ値を鍵としてレスポンスのデータを復号します。復号したデータが、送信したチャレンジと一致していれば認証は成功となります。
NTLM 認証の流れ
NTLM 認証では、サービスを提供するサーバーとサービスを利用するクライアント同士で認証を試行する動作となります。ドメイン環境では、ユーザーのパスワードなどの認証情報はドメイン コントローラーが保持しているため、認証情報はドメイン コントローラーに転送されて、ドメイン コントローラー上で認証の処理が行われる動作となります。
NTLM 認証のフローは、以下の通り、[A] ～ [F] のフローで行われます。
[A] NTLM ネゴシエート
クライアントは、サービスを提供しているサーバーに NTLM 認証の要求を送信します。
[B] Challenge 送信
サーバーは乱数を算出して、「チャレンジ」と呼ばれるデータをクライアントに送信します。
[C] NTLM 認証情報の提示
クライアントはアカウントのパスワードのハッシュ値を鍵として、サーバーから送信されてきたチャレンジを暗号化します。この暗号化したデータは、「レスポンス」と呼ばれます。クライアントは認証情報として、「レスポンス」をサーバーに応答します。
[D] 認証要求の転送
ドメイン環境でドメイン アカウントで認証する場合、パスワードのハッシュ値などの認証情報はドメイン コントローラーで管理されています。接続先となるリソース サーバーには、ドメイン アカウントの認証情報は管理されていないため、レスポンスを応答されても認証を検証することはできません。
そのため、サーバーはクライアントからの認証要求を、ドメイン コントローラーへ転送する必要があります。リソース サーバーは「ユーザー名」、クライアントへ送信した「チャレンジ」、クライアントから応答された「レスポンス」を転送します。
[E] 認証結果の応答
リソース サーバーから転送されてきたデータを受信したドメイン コントローラーは、認証対象のユーザーのパスワードのハッシュ値を使って、チャレンジを暗号化します。暗号化したデータを、リソースから転送されてきたレスポンスと比較して、値が一致していれば、正しいユーザーであると判断して認証は成功します。値が一致していない場合は、不正なユーザーであると判断して認証は失敗します。
ドメイン コントローラで認証した結果を、リソース サーバーへ送信します。
[F] 認証結果の送信
リソース サーバーはドメイン コントローラーから送信されてきた認証結果を受信したら、クライアントへも認証結果を転送します。
NTLM 認証で利用されるポート
NTLM 認証で利用される通信ポートは、以下の通りとなります。
- クライアント – リソース サーバー間：サービスが利用するプロトコルのポート
- リソース サーバー – ドメイン コントローラー間：TCP の一時ポート
クライアントとリソース サーバー間での NTLM 認証の通信は、リソース サーバーが提供するサービスが利用するプロトコルのポートが利用されます。例えば、ファイル サーバーの共有フォルダへ通信する場合は、TCP 139 ポートもしくは TCP 445 ポートが利用されます。この例の場合、上手の [A][B][C][F] の通信は、TCP 139 ポートもしくは TCP 445 ポートが利用されます。
リソース サーバーとドメイン コントローラー間での NTLM 認証の通信には、TCP の一時ポートが利用されます。TCP の一時ポートで利用されるのは、49152 ～ 65535 のいずれかのポートが利用されます。
NTLM 認証の認証先
NTLM 認証では、クライアントは認証要求をリソース サーバーに送信しますが、リソース サーバーは認証情報を保持しないため、ドメイン コントローラーへ認証要求を転送する動作となります。リソース サーバーが所属しているドメイン環境に、複数のドメイン コントローラーが存在している場合は、認証要求の転送先は、リソース サーバーがセキュア チャネルの確立先となるドメイン コントローラーとなります。
例えば、DC01 ～ DC04 の４台のドメイン コントローラーが構築されているドメイン環境において、リソース サーバーは DC02 のドメイン コントローラーとセキュア チャネルを確立されていると想定します。その場合、そのリソース サーバーはクライアントから NTLM 認証の要求を受けると、DC02 のドメイン コントローラーへ認証要求を転送します。
NTLM 認証の転送先のドメイン コントローラーを確認したい場合は、リソース サーバーにて nltest /sc_query コマンドを実行します。nltest /sc_query は、セキュア チャネルの確立先のドメイン コントローラーを確認するためのコマンドです。
■ セキュア チャネルを確認するコマンド
C:\>nltest /sc_query:test01.local
フラグ: 10 HAS_IP
信頼された DC 名 \\TEST01DC01.test01.local
信頼された DC 接続状態 Status = 0 0x0 NERR_Success
コマンドは正常に完了しました
C:\>
ポチップ
