エクスプローラーで共有フォルダを開くとき、ブラウザで社内サイトを開くとき、リモートデスクトップでつなぐとき。どの場面でも、Windowsは裏で認証をしています。ただ、エクスプローラーやブラウザが自分でKerberosやNTLMを組み立てているわけではありません。認証そのものは、Windowsの中の決まった部品が引き受けています。この記事では、その部品であるLSASS、SSPI、SSP、Negotiateが、それぞれ何をしているのかを見ていきます。
- LSASS（LSA）が何をしているプロセスなのか
- SSPIとSSPの関係と、アプリが認証を頼むときの流れ
- NegotiateがKerberosとNTLMを選ぶしくみと、LSASSを守る機能
全体像：共通の窓口と、方式ごとの担当者
Windowsの認証の部品は、大きく3つの層に分かれています。いちばん上がアプリ、その下にSSPI（Security Support Provider Interface）という共通の窓口があり、さらにその下で、SSP（Security Support Provider）と呼ばれる認証方式ごとの担当者が実際の処理をします。SSPは、LSASS（lsass.exe）というプロセスの中で動いています。
役所の窓口にたとえると分かりやすいかもしれません。利用者（アプリ）は、どの手続きでも同じ窓口（SSPI）に書類を出します。窓口の奥には手続きごとの担当者（SSP）がいて、書類の中身を作ったり確かめたりするのはその担当者です。利用者は担当者の細かい仕事を知らなくても、窓口に出すだけで手続きを終えられます。
| 部品 | 役割 |
|---|---|
| LSASS （lsass.exe） | LSA（Local Security Authority）の処理を担うプロセス。サインインの確認、アクセストークンの作成、ローカルのセキュリティポリシーの管理、SIDと名前の変換などを行う |
| SSPI | アプリが認証を頼むための共通のAPI。どの認証方式を使う場合も、アプリは同じ関数を呼べばよい |
| SSP | 認証方式ごとの実装。Kerberos、NTLM、TLS（Schannel）などがある |
| Negotiate | SSPの1つ。KerberosとNTLMのどちらを使うかを選ぶ役 |
SSPIは、標準のGSS-API（RFC 2743）に相当するWindowsのしくみです。そのためWindowsのKerberosは、Linuxなど他のOSのKerberosともやり取りできます。
サインインの流れと、関わる部品
まずは、PCの前でサインインするときの流れです。画面を出す部品と、本人かどうかを判断する部品は分かれています。
| 部品 | やること |
|---|---|
| Winlogon | サインイン、サインアウト、画面のロックなどを管理する。Ctrl+Alt+Delの受け付けもここ |
| LogonUI | サインイン画面を表示する |
| 資格情報プロバイダー | パスワード、PIN、スマートカードなど、入力の種類ごとに用意された部品。入力を集めてLSAに渡すだけで、正しいかどうかは判断しない |
| LSASS | 受け取った入力を認証パッケージに渡し、結果をもとにアクセストークンを作る |
| 認証パッケージ | 入力が正しいかを実際に確かめる部品。ドメインのアカウントならKerberos、ローカルアカウントならMSV1_0（NTLMの実装でもある）が、DCやSAMに照らし合わせる |
認証に成功すると、LSASSはユーザーのSIDやグループのSIDを入れたアクセストークンを作ります。このトークンを持ったエクスプローラー（explorer.exe）が起動し、そこから開いたプログラムにもトークンのコピーが付きます。
ノートPCを社外に持ち出したときのように、DCに届かない場面でもドメインのアカウントでサインインできることがあります。これは、以前のサインインで保存しておいた情報（キャッシュされた資格情報）を使って、LSASSがPCの中だけで確認しているためです。
LSASSの中では、ほかにもいくつかの部品が動いています。SAMを読み書きする部品（samsrv.dll）や、DCとの安全な通り道（セキュアチャネル）を作るNetlogon（netlogon.dll）もLSASSの中にいます。ドメインに参加したPCでNTLMの認証をするときは、このNetlogonを通してDCに確認を頼みます。
LSASSは資格情報をメモリに持っている
一度サインインすれば、共有フォルダやメール、社内サイトにパスワードを入れ直さずにアクセスできます。これはシングルサインオン（SSO）と呼ばれ、LSASSがサインイン中のユーザーの資格情報をメモリに持っていることで成り立っています。
| LSASSが持つことのある情報 | 使い道 |
|---|---|
| Kerberosのチケット （TGT、サービスチケット） | Kerberosで別のサーバにアクセスするとき |
| NTハッシュ | NTLMで認証するとき（パスワードから計算した値） |
| 元に戻せる形で暗号化したパスワード | 平文のパスワードを必要とする方式のため |
便利な反面、LSASSのメモリは攻撃者に狙われやすい場所でもあります。管理者権限を取った攻撃者がLSASSのメモリを読み出せば、そこにあるハッシュやチケットを使って、パスワードを知らないまま別のサーバに入れてしまいます（Pass-the-Hash、Pass-the-Ticketと呼ばれる攻撃です）。このあと紹介するLSA保護とCredential Guardは、この問題への対策です。
SSPIとSSP：アプリは認証データを運ぶだけ
ネットワーク越しの認証では、アプリはSSPIの関数を呼んで「認証データ」を受け取り、それを自分の通信に入れて相手に送ります。相手側のアプリも、受け取ったデータをそのままSSPIに渡します。データの中身を作ったり確かめたりするのはSSPで、アプリは中身を知りません。
エクスプローラーでファイルサーバの共有フォルダを開く場面を例に、どの部品が何をしているかを図にしました。左がPC、右がファイルサーバで、それぞれ「アプリ」「SSPI」「SSP（LSASSの中）」の3つに分けています。
| 部品 | 図の中でやっていること |
|---|---|
| アプリ （エクスプローラー、SMBサーバ） | SSPIの関数を呼ぶ（①⑤⑨）。受け取った認証データを、SMBの通信に入れて相手に運ぶ（④⑧）。最後に、できたトークンでなりすましてファイルを開く（⑩） |
| SSPI | アプリの呼び出しを、担当のSSPに取り次ぐ。図の●の位置。自分では認証の処理をしない |
| SSP （LSASSの中） | PC側では、NegotiateがKerberosを選び、Kerberosの担当がDCからチケットをもらって認証データを作る（②）。サーバ側では、Kerberosの担当がチケットを確かめて本人を確認し、LSASSがアクセストークンを作る（⑥） |
アプリが知っているのは「どの関数を呼ぶか」と「データをどこに入れて運ぶか」だけです。チケットの中身や暗号の処理は、すべてLSASSの中のSSPが受け持っています。
認証データを運ぶ場所は、プロトコルごとに決まっています。たとえばファイル共有（SMB）ならSession Setupというやり取りの中、Webサイト（HTTP）ならAuthorizationヘッダーの中です。運び方が違っても、中身を作るのは同じSSPです。だから、新しいアプリを作るときにKerberosを一から実装する必要はありません。
⑥で作られたトークンを使って、サーバのアプリは「なりすまし（偽装）」をします（⑩）。これで、ファイルを開くなどの処理がクライアントのユーザーの権限で行われ、そのユーザーのACLの判定が効くようになります。
Windowsに最初から入っているおもなSSPは次のとおりです。
| SSP | ファイル | 使われる場面 |
|---|---|---|
| Kerberos | kerberos.dll | ドメインの中での認証。ドメイン環境でいちばん優先される方式 |
| NTLM | msv1_0.dll | Kerberosが使えないとき。ワークグループのPC同士など |
| Negotiate | lsasrv.dll | KerberosとNTLMのどちらを使うかを選ぶ |
| Schannel | schannel.dll | TLS（HTTPSなど）で、証明書を使って認証と暗号化をする |
| CredSSP | credssp.dll | リモートデスクトップなどで、資格情報を接続先に渡す |
| Digest | wdigest.dll | HTTPのダイジェスト認証など |
このほかに、NegoExts（negoexts.dll）やPKU2U（pku2u.dll）といったSSPもあります。
Negotiate：KerberosかNTLMかを選ぶ
アプリがSSPIを呼ぶときは、使うSSPを名前で指定します。ここで「Negotiate」を指定すると、NegotiateがKerberosとNTLMのどちらを使うかを決めてくれます。Negotiateは、標準のSPNEGO（RFC 4178）にもとづいたしくみです。
Negotiateは、基本的にKerberosを選びます。NTLMに切り替わるのは、どちらかのコンピュータがKerberosを使えないときや、アプリがKerberosに必要な情報（接続先のSPNなど）を渡さなかったときです。
よくあるのが、IPアドレスで接続するケースです。SPNはふつう「cifs/fs01.corp.example.com」のようにホスト名で登録されているため、IPアドレスで開くと、Windowsは既定ではKerberosを試さず、NTLMを使います。Windows 10とWindows Server 2016以降では、クライアントの設定（TryIPSPN）とSPNの登録をすればIPアドレスでもKerberosを使えますが、ふだんはホスト名（できればFQDN）で接続するのが基本です。
Microsoftは、アプリからKerberosやNTLMを直接指定せず、Negotiateを使うように勧めています。NTLMを直接指定したアプリは、Kerberosが使える環境でもNTLMで認証してしまうからです。NTLMは非推奨になっていて、NTLMv1はWindows 11 バージョン24H2とWindows Server 2025で削除されました。
サーバのセキュリティログに記録されるイベントID 4624（ログオン成功）には、「Logon Process（ログオン プロセス）」と「Authentication Package（認証パッケージ）」という項目があります。ここを見ると、そのログオンでKerberosとNTLMのどちらが使われたかが分かります。NTLMのときは「Package Name (NTLM only)」にNTLMのバージョンが入ります。
LSASSを守るしくみ
LSASSのメモリが狙われる問題に対して、Windowsには2つの対策があります。LSA保護（LSA protection）とCredential Guardです。どちらか片方ではなく、組み合わせて使えます。
| LSA保護 | Credential Guard | |
|---|---|---|
| 守り方 | LSASSを「保護されたプロセス」として動かし、ほかのプロセスからのメモリの読み出しやコードの注入を止める。読み込めるプラグインはMicrosoftの署名があるものだけになる | 仮想化ベースのセキュリティ（VBS）で隔離したLSAIso.exeに、NTLMハッシュやKerberosのTGTを置く。OSのほかの部分からは中身を読めない |
| 既定の状態 | Windows 11 バージョン22H2以降の新規インストールで、組織に参加していてHVCIに対応したPCでは既定で有効。最近のWindows 11では、アップグレードしたPCも評価期間のあとで有効になる | Windows 11 バージョン22H2以降とWindows Server 2025で、ライセンスとハードウェアの条件を満たし、明示的に無効にしていないデバイスでは既定で有効（Windows Server 2025はドメイン参加済みでDC以外） |
| 気をつけること | 署名のないスマートカードドライバーやパスワードフィルターなどは読み込めなくなる | NTLMv1、MS-CHAPv2、WDigest、CredSSPではサインイン時の資格情報によるSSOが使えなくなる。Kerberosの制約なし委任も使えない |
Credential Guardを有効にしても、Kerberosを使うファイル共有やリモートデスクトップはそのまま使えます。影響が出るのは、古い方式に頼っているシステムです。よく話題になるのは、PEAP-MSCHAPv2を使うWi-FiやVPNで、Credential Guardが有効になってから毎回パスワードを聞かれるようになった、というケースです。証明書を使うEAP-TLSなどに移るのが勧められています。
Credential Guardが守るのは、ドメインのアカウントの資格情報です。ローカルアカウントやMicrosoftアカウント、キーロガーで盗まれるパスワード、DCのADデータベースは守れません。また、管理者権限を取った攻撃者は、秘密を取り出せなくても、そのPCの上でユーザーの権限を使うことはできます。管理者用のPCを分けるといった運用と組み合わせて使うものです。
確認に使うコマンド
ここまでの部品の状態は、次のコマンドで確かめられます。
PC（コマンドプロンプト）：今のサインインで持っているKerberosのチケットを表示する
klist
PC（コマンドプロンプト・管理者）：このPCのログオンセッションの一覧を表示する
klist sessions
PC（コマンドプロンプト）：Kerberosのチケットを削除する（次のアクセスで取り直す）
klist purge
サーバ（PowerShell・管理者）：最近のログオン成功イベント（4624）を表示する
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5 | Format-List TimeCreated, Message
PC（PowerShell）：動いているVBSの機能を表示する（1 が含まれていればCredential Guardが動作中）
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
LSA保護が有効かどうかは、イベントビューアーの Windows ログ ›› システム で確かめます。ソースが「Wininit」、イベントIDが12のイベントに「LSASS.exe was started as a protected process with level: 4」と記録されていれば、LSASSは保護されたプロセスとして起動しています。Credential Guardは、msinfo32（システム情報）の「システムの要約」にある、仮想化ベースのセキュリティで実行中のサービスの欄でも確認できます。
まとめ
| 部品 | ひとことで |
|---|---|
| LSASS | サインインの確認、アクセストークンの作成、資格情報の保持を担うプロセス |
| 資格情報プロバイダー | パスワードやPINの入力を集めるだけ。判断はしない |
| SSPI | アプリが認証を頼むための共通の窓口 |
| SSP | Kerberos、NTLM、Schannelなど、方式ごとの担当者 |
| Negotiate | 基本はKerberos、使えないときだけNTLMを選ぶ |
| LSA保護 | LSASSのメモリの読み出しやコードの注入を止める |
| Credential Guard | NTLMハッシュやTGTをVBSで隔離した場所に置く |
アプリはSSPIに認証を頼み、LSASSの中のSSPが方式ごとの処理をする。この分担を知っておくと、「なぜかNTLMになっている」「Credential Guardを有効にしたらWi-Fiがつながらない」といったトラブルのとき、どの部品で何が起きているのかを考えやすくなります。
- Security Support Provider Interface Architecture（Microsoft Learn）
- Credentials processes in Windows authentication（Microsoft Learn）
- Authentication Packages（Microsoft Learn）
- MSV1_0 Authentication Package（Microsoft Learn）
- Microsoft Negotiate（Microsoft Learn）
- Kerberos clients allow IPv4 and IPv6 address hostnames in SPNs（Microsoft Learn）
- Resources for deprecated features：NTLM（Microsoft Learn）
- Configure added LSA protection（Microsoft Learn）
- Advanced credential protection（Windows security book）（Microsoft Learn）
- Credential Guard overview（Microsoft Learn）
- How Credential Guard works（Microsoft Learn）
- Considerations and known issues when using Credential Guard（Microsoft Learn）
- klist（Microsoft Learn）
- RFC 2743：Generic Security Service Application Program Interface Version 2, Update 1
- RFC 4178：The Simple and Protected GSS-API Negotiation Mechanism（SPNEGO）
コメント