Kerberos や NTLM の話をしていると、LDAPS、リモートデスクトップの NLA、AD FS の HTTPS など、TLS がからむ場面によく出会います。TLS 自体はインターネット全体で使われている大きなテーマですが、この記事では範囲を絞り、Windows の認証のまわりで TLS がどこで、何のために使われているかを説明します。TLS のハンドシェイクや暗号スイートの細かいしくみには深入りせず、「TLS と Kerberos・NTLM がどう役割を分けているか」「どこで証明書が必要になるか」「つながらないときにどこを見るか」をまとめます。
- TLS と Kerberos・NTLM の役割分担（だれがだれを確かめるか）
- LDAP・HTTP・RDP・WinRM で、認証と TLS がどう組み合わさっているか
- 認証を TLS の通り道に結び付けるチャネルバインディングの考え方
- DC の証明書、Windows で TLS を受け持つ Schannel、つながらないときの調べ方
TLS と認証の役割分担
TLS（Transport Layer Security）は、2台のコンピュータのあいだに「安全な通り道」を作るしくみです。通り道の中身を暗号化して盗み見を防ぎ、書き換えに気づけるようにし、サーバの証明書を確かめてなりすましを防ぎます。いま使うバージョンは TLS 1.2 と TLS 1.3 です。
ここで大事なのは、TLS が確かめるのは、ふつうはサーバだけという点です。「接続してきたのがだれか」（ユーザーの認証）は、TLS の通り道の中で、Kerberos や NTLM、LDAP の簡易バインドなどが別に行います。Windows の認証で TLS が出てくる場面は、たいていこの「外側が TLS、内側が認証」の二重の形になっています。
だれがだれを確かめるか
内側の認証方式によって、TLS の役割の大きさが変わります。
Kerberos は、ユーザーだけでなくサーバも確かめられます（相互認証）。サービスチケットはサーバの鍵で暗号化されているので、本物のサーバでなければ中身を読めないからです。一方、NTLM はユーザーを確かめるだけで、サーバが本物かは確かめません。LDAP の簡易バインドは、ユーザー名とパスワードをそのまま送る方式なので、TLS がなければパスワードが通信路に流れてしまいます。
つまり、NTLM や簡易バインドを使う場面ほど、外側の TLS（サーバの証明書の確認と暗号化）が重要になります。Kerberos と NTLM の違いは「Kerberos認証とは？」「NTLM認証とは？」の記事で説明しています。
LDAP と TLS
まず、バインドとは
LDAP の話では「バインド（bind）」という言葉がよく出てきます。バインドは、LDAP でつないだあと最初に行う「名乗る」操作です。クライアントは「私は user01 です」という名前と、本人であることの証明（パスワードや Kerberos のチケットなど）を DC に送ります。DC が確かめると、その接続はそれ以降 user01 として扱われ、検索や書き換えは user01 の権限の範囲で行われます。
図書館の受付で利用者カードを見せてから本を借りるのに似ています。カードを見せないと（名乗らないと）、できることはごく一部に限られます。AD でも、名乗らずに（匿名で）できるのは、RootDSE（DC の基本情報）の読み取りなどに限られます。
名乗り方（バインドの種類）は、次のとおりです。
| バインドの種類 | 本人である証明 | 特徴 |
|---|---|---|
| 匿名 | なし（名前もパスワードも空） | AD では RootDSE の読み取りなど、ごく一部だけ |
| 簡易バインド（simple bind） | 名前（DN など）とパスワード | パスワードをそのまま送る。多くの製品が対応していて分かりやすいが、TLS で守る必要がある |
| SASL バインド | Kerberos・NTLM（GSS-SPNEGO・GSSAPI）など | パスワードを送らない。Windows の PC や管理ツールはふつうこちら。そのあとの通信に署名・暗号化もかけられる |
このあと出てくる「簡易バインド」「SASL バインド」は、この名乗り方のことです。
LDAP の通信を守る4つの方法
DC への LDAP の通信を守る方法は、大きく分けて次の4つです。
| 方法 | ポート | 説明 |
|---|---|---|
| SASL ＋ 署名・暗号化 | 389 | Kerberos（SASL）でバインドし、認証で作った鍵でメッセージに署名・暗号化する。Windows 同士ではふつうこの形で、TLS は使わない |
| 簡易バインド（TLS なし） | 389 | パスワードがそのまま流れる。LDAP 署名を必須にした DC は、暗号化されていない簡易バインドを拒否する |
| LDAPS | 636（GC は 3269） | 最初に TLS をつないでから LDAP を話す |
| StartTLS | 389 | 389 でつないだあと、途中で TLS に切り替える |
Windows の管理ツールや PC は、ふだんは1つ目の「389 番で Kerberos ＋ 署名・暗号化」を使います。LDAPS や StartTLS が必要になるのは、簡易バインドしか使えない製品（Linux の機器、アプライアンス、一部のアプリ）が AD を参照するときです。
LDAP でパスワードを変えるときは暗号化が必須
AD のパスワードは unicodePwd という属性に入っていて、LDAP でこれを書き換える（パスワードの変更・リセット）には、128 ビット以上で暗号化された接続が必要です。
認証（バインド）が成功していても、接続が暗号化されていなければ、DC はパスワードの書き込みを断ります。新しいパスワードがそのまま通信路に流れてしまうからです。暗号化の方法は、TLS（LDAPS・StartTLS）でも、SASL バインドの鍵による暗号化でもかまいません。
この条件にかかわるのは、LDAP でパスワードを変更・リセットする製品やしくみです。たとえば、Microsoft Entra Connect のパスワードライトバック（クラウドで変えたパスワードをオンプレミスの AD に書き戻す機能）では、この条件を満たしていないとエラー 8023062C になります。Linux の機器やパスワードリセットの製品が、簡易バインドで AD のパスワードを変えようとしてうまくいかないときも、まず LDAPS か StartTLS を使っているかを確かめます。
LDAPS に使う DC の証明書
LDAPS には、DC に入っているサーバ証明書が使われます。設定画面はなく、条件を満たす証明書を入れると自動で LDAPS が使えるようになります。条件は次のとおりです。
| 条件 | 内容 |
|---|---|
| 名前 | DC の FQDN（例：dc01.corp.example.com）が、サブジェクトの CN かサブジェクト代替名（SAN）の DNS 名に入っている |
| 用途 | 拡張キー使用法（EKU）にサーバ認証（1.3.6.1.5.5.7.3.1）が入っている |
| 秘密鍵 | コンピュータのストアに、証明書と対になる秘密鍵がある |
| 信頼 | DC とクライアントの両方が信頼する CA から発行されている |
AD 証明書サービス（AD CS）のエンタープライズ CA があると、DC は DC 用の証明書を自動で受け取ります。この証明書は LDAPS などの TLS とスマートカードログオンの両方に使われます。コンピュータの個人ストアに条件を満たす証明書が複数あると、Schannel は最初に見つかった有効な証明書を使うので、意図しない証明書が選ばれることがあります。NTDS サービスのストアに証明書を入れると、そちらが優先されます。
証明書は、クライアント側でチェーンをたどって確かめられます。
LDAPS の接続先は、証明書に入っている FQDN で指定します。IP アドレスや短い名前で接続すると、名前が合わずに失敗します。
HTTP の統合 Windows 認証と TLS
IIS や AD FS で使う「統合 Windows 認証」では、まずブラウザとサーバのあいだに TLS（HTTPS）の通り道を作り、その中の HTTP ヘッダーで Negotiate（Kerberos か NTLM）の認証データをやり取りします。ここでも、外側の TLS がサーバを確かめて通り道を守り、内側の Kerberos・NTLM がユーザーを確かめる、という二重の形です。
チャネルバインディング：認証を TLS に結び付ける
外側が TLS、内側が認証という二重の形には、1つ弱点があります。TLS と内側の認証は、それぞれ独立に行われるので、内側の認証が「どの TLS の通り道の上で行われたか」をサーバは知りません。そのため、途中にいる第三者が、クライアントとのあいだの TLS と、サーバとのあいだの TLS を別々に張り、内側の認証データだけを中継すると、サーバはそれに気づけません。とくに、サーバを確かめない NTLM では、この中継（リレー）の危険が大きくなります。
これを防ぐのがチャネルバインディングです。
「バインド」と「チャネルバインディング」は別のもの
名前が似ていますが、LDAP の「バインド」とチャネルバインディングは別のしくみです。英語の bind は「結び付ける」という意味で、何と何を結び付けるかが違います。
LDAP のバインドは、接続に「だれか」を結び付ける操作（名乗って認証を受けること）でした。チャネルバインディングは、その認証を「TLS の通り道」に結び付けて、どの通り道の上で行われた認証かを確かめるしくみです。LDAP では、TLS（LDAPS・StartTLS）の上で SASL バインドをするときに、チャネルバインディングを組み合わせて使います。これを「LDAP チャネルバインディング」と呼んでいます。
チャネルバインディングのしくみ
クライアントは、自分が使っている TLS の通り道から作った値（チャネルバインディングトークン、CBT）を、Kerberos や NTLM の認証データの中に入れて送ります。認証データは改ざんできないように守られているので、サーバは受け取った CBT と自分の側の TLS の値を比べることで、「この認証は、自分とのあいだの TLS の上で行われたものか」を確かめられます。Microsoft はこれを、サービスの名前（SPN）を確かめるサービスバインディングとあわせて「拡張保護（Extended Protection for Authentication）」と呼んでいます。
| どこで使うか | 設定 |
|---|---|
| LDAP（DC） | グループポリシー「ドメイン コントローラー: LDAP サーバー チャネル バインド トークンの要件」。TLS の上の SASL バインドに効く（簡易バインドには効かない） |
| AD FS | ExtendedProtectionTokenCheck。既定は Allow |
| IIS | Windows 認証の「拡張保護」の設定 |
| WinRM | CbtHardeningLevel。既定は Relaxed |
| SQL Server | 「拡張保護」の設定（Allowed・Required） |
チャネルバインディングは「クライアントとサーバが同じ TLS の通り道を見ている」ことが前提です。途中のリバースプロキシやロードバランサ、SSL インスペクションの機器が TLS をいったんほどいて張り直すと、両端の値が一致しなくなり、Kerberos・NTLM の認証が失敗します。AD FS では、シングルサインオンにならずに認証のダイアログが出る原因になります。チャネルバインディングを必須にする前に、通信の途中で TLS を終端している機器がないかを確かめてください。
リモートデスクトップと TLS
リモートデスクトップ（RDP）では、セキュリティ層の設定で TLS を使うかが決まります。「ネゴシエート」（既定）、「SSL（TLS）」、「RDP」の3つから選び、ネゴシエートでは両方が対応していれば TLS を使います。TLS を使うと、サーバの証明書でサーバを確かめられます。証明書を用意しないと、リモートデスクトップは自己署名の証明書を自動で作ります。
ネットワークレベル認証（NLA）を有効にすると、画面（セッション）を作る前にユーザーを認証します。このとき使うのが CredSSP という SSP で、TLS と Negotiate を組み合わせて動きます。
CredSSP は、まず TLS の通り道を作り、その中で Negotiate（Kerberos か NTLM）でユーザーを認証します。最後に、リモート側でサインインするための資格情報を、TLS と認証の鍵の両方で暗号化して渡します。認証が済むまで画面を作らないので、認証していない相手にサーバの資源を使わせずに済みます。
WinRM と TLS
PowerShell のリモート操作で使う WinRM は、HTTP（TCP 5985）と HTTPS（TCP 5986）の2つの待ち受けを持てます。Windows Server では、PowerShell のリモート操作は既定で有効で、HTTP の待ち受けが使われます。
「HTTP だから暗号化されていない」と思われがちですが、WinRM の HTTP では、最初の認証（Kerberos・NTLM）で作った鍵を使って、そのあとの通信の中身を暗号化します。HTTPS では、この暗号化を TLS が受け持ちます。
違いが出るのは「接続先のサーバが本物か」です。ドメインの中で Kerberos を使えば、HTTP でもサーバを確かめられます。一方、ワークグループのコンピュータや IP アドレスで接続するときは NTLM になり、サーバを確かめられません。このとき WinRM はエラーを出し、接続先を TrustedHosts の一覧に入れるとエラーを出さずに接続できるようになります。ただし、TrustedHosts に入れるのは「確かめられないことを承知のうえでエラーを出さない」という意味で、相手を確かめたことにはなりません。サーバを確かめたいときは、HTTPS の待ち受けを用意し、証明書でサーバを確かめるのが確実です。
HTTPS の待ち受けに使う証明書は、ホスト名と一致し、サーバ認証の用途を持ち、期限内で失効しておらず、自己署名でないものが必要です。
Windows で TLS を使う場面のまとめ
| 場面 | ポート | 内側の認証 | TLS の役割 |
|---|---|---|---|
| LDAPS・StartTLS | 636・3269・389 | 簡易バインド、SASL（Kerberos など） | 簡易バインドのパスワードを守る。LDAP でのパスワード変更に必須 |
| IIS・AD FS | 443 | Negotiate（Kerberos・NTLM） | サーバを確かめ、通り道を守る。CBT で認証と結び付ける |
| RDP（NLA） | 3389 | CredSSP の中の Negotiate | サーバを確かめ、資格情報を渡す通り道を守る |
| WinRM（HTTPS） | 5986 | Negotiate など | NTLM のときでもサーバを確かめられる |
証明書を使うけれど TLS ではないもの
スマートカードや Windows Hello for Business（証明書信頼）でのサインインも、証明書を使います。ただし、これは TLS ではなく、PKINIT という Kerberos の拡張（RFC 4556）です。混同しやすいので整理しておきます。
PKINIT では、ユーザーが証明書と秘密鍵を使って TGT を頼み、DC（KDC）も自分の証明書を返してユーザーに確かめてもらいます。DC 側では、KDC として使う証明書が必要で、KDC 認証（KDC Authentication）の用途を持つものが使われます。AD CS には DC 向けの証明書テンプレートとして「ドメイン コントローラー」「ドメイン コントローラー認証」「Kerberos 認証」の3種類があり、DC の設定に応じてこのうちの1つの証明書が使われます。
Windows で TLS を受け持つ Schannel
Windows では、TLS を Schannel（Secure Channel）という部品が受け持っています。Schannel は、Kerberos・NTLM を選ぶ Negotiate や CredSSP と並んで、SSPI という共通の窓口の下にある SSP（セキュリティサポートプロバイダー）の1つです。SSPI については「LSASS・SSPI・Negotiateとは？」の記事で説明しています。
Schannel で使う TLS のバージョンは、レジストリの HKLM\SYSTEM\CurrentControlSet\ の下で、バージョンごと・Client と Server ごとに決められます（値 Enabled と DisabledByDefault）。暗号スイートとその順番は、グループポリシーの コンピューターの構成 ›› 管理用テンプレート ›› ネットワーク ›› SSL 構成設定 か、PowerShell の Get-TlsCipherSuite などで設定します。Microsoft は既定の設定のまま使うことを勧めているので、絞り込むときは古いクライアントや機器とつながるかを検証してから広げてください。
TLS 1.0 と 1.1 は RFC 8996 で非推奨になり、Microsoft も Windows で既定で無効にする方針を発表しています（Windows Server 2025 では既定で無効と案内されています）。LDAPS を使う古いアプライアンスや古いアプリが TLS 1.0・1.1 しか使えないと、この変更でつながらなくなります。システムログに Schannel のイベント 36871（内部エラー 10013）が出ることがあります。まずは相手側を TLS 1.2 以上に対応させるのが基本で、TLS 1.0・1.1 を有効に戻すのは最後の手段です。
つながらないときの調べ方
LDAPS や WinRM の HTTPS がつながらないときは、次の順に確かめると切り分けやすくなります。
- そのポートに TCP で届くかを確かめます。届かなければ、ファイアウォールやサービスの問題です。
- 接続に使った名前が、証明書の SAN に入っているかを確かめます。IP アドレスで接続すると、ほとんどの場合ここで失敗します。
- 証明書を書き出して
certutil -verify -urlfetchで確かめると、チェーンを作れるか、中間 CA の証明書や CRL を取りにいけるかが分かります。 - バージョンや暗号スイートの食い違いは、Schannel のイベントに出ます。
- 証明書の期限の判定は時計に頼っているので、時刻のずれも確かめます。
TLS がつながったあとで認証だけが失敗するときは、内側の Kerberos・NTLM の問題です。その場合の調べ方は「Windows認証の調べ方」の記事で説明しています。途中に TLS を終端する機器があり、チャネルバインディングで失敗している可能性も考えます。
Schannel のイベント
Schannel のイベントは、システムログに「ソース：Schannel」で記録されます。
| イベント ID | 意味 |
|---|---|
| 36886 | サーバとして使える既定の証明書がない（DC で LDAPS の証明書がないときなど） |
| 36882 | サーバの証明書が、信頼されていない CA から発行されている |
| 36884 | サーバの証明書に、期待した名前が入っていない |
| 36874 | クライアントが使える暗号スイートを、サーバが1つも使えない |
| 36887・36888 | 致命的なアラートを受け取った・出した。アラートの番号で原因の見当がつく（45 期限切れ、48 信頼できない CA、70 バージョンが合わない など） |
記録するイベントの範囲は、HKLM\SYSTEM\CurrentControlSet\ の EventLogging（DWORD）で決まります。1 はエラーだけ、7 はすべてで、変更後は再起動が必要です。すべてを記録すると成功したハンドシェイクも大量に残るので、調べるあいだだけ上げるようにします。
確認に使うコマンド
PC01（PowerShell）：DC01 の LDAPS のポートに届くか確かめる
Test-NetConnection -ComputerName dc01.corp.example.com -Port 636
DC01（PowerShell・管理者）：コンピュータの個人ストアの証明書を、期限と秘密鍵の有無つきで表示する
Get-ChildItem -Path Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey
PC01（コマンドプロンプト）：書き出した DC01 の証明書のチェーンと失効を確かめる
certutil -verify -urlfetch .\dc01.cer
DC01（PowerShell・管理者）：Schannel のイベントを新しい順に20件表示する
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'} -MaxEvents 20
DC01（コマンドプロンプト・管理者）：TLS のバージョンをレジストリで設定しているか確かめる
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" /s
SV02（コマンドプロンプト・管理者）：WinRM のリスナー（HTTP・HTTPS）と使っている証明書を表示する
winrm enumerate winrm/config/listener
LDAPS は ldp.exe でも確かめられます。Connection ›› Connect でサーバに DC の FQDN、ポートに 636 を入れ、SSL にチェックを入れて接続し、RootDSE の情報が表示されれば LDAPS は動いています。
まとめ
| 項目 | ひとことで |
|---|---|
| 役割分担 | 外側の TLS がサーバを確かめて通り道を守り、内側の Kerberos・NTLM などがユーザーを確かめる |
| TLS が特に大事な場面 | サーバを確かめない NTLM と、パスワードをそのまま送る簡易バインド |
| LDAP | Windows 同士は 389 の SASL ＋ 署名・暗号化。簡易バインドやパスワード変更には LDAPS・StartTLS |
| チャネルバインディング | 内側の認証を外側の TLS に結び付け、中継を防ぐ。途中で TLS をほどく機器があると失敗する |
| RDP・WinRM | NLA は CredSSP（TLS ＋ Negotiate）。WinRM の HTTPS は NTLM のときにサーバを確かめるのに役立つ |
| PKINIT | 証明書を使う Kerberos の拡張で、TLS ではない |
| Schannel | Windows の TLS を受け持つ SSP。設定はレジストリ・GPO・PowerShell |
Windows の認証で TLS が出てきたら、「外側の TLS が何を確かめ、内側でだれがだれを確かめているか」を分けて考えると整理しやすくなります。つながらないときも、TLS の段階で止まっているのか、その中の認証で止まっているのかを最初に見分けることが近道です。
- TLS/SSL overview (Schannel SSP)（Microsoft Learn）
- Security Support Provider Interface Architecture（Microsoft Learn）
- LDAP signing overview for Active Directory Domain Services（Microsoft Learn）
- LDAP channel binding overview for Active Directory Domain Services（Microsoft Learn）
- Configure certificates for LDAP over SSL in Active Directory Domain Services（Microsoft Learn）
- Enable LDAP over SSL with a third-party certification authority（Microsoft Learn）
- Change a Windows Active Directory and LDS user password through LDAP（Microsoft Learn）
- Troubleshoot error code 8023062C（Microsoft Learn）
- Integrated Windows Authentication with Extended Protection（Microsoft Learn）
- AD FS troubleshooting: Integrated Windows Authentication（Microsoft Learn）
- Connect to the database engine with Extended Protection（Microsoft Learn）
- Credential Security Support Provider（Microsoft Learn）
- Policy CSP – ADMX_TerminalServer（RDP のセキュリティ層）（Microsoft Learn）
- Installation and configuration for Windows Remote Management（Microsoft Learn）
- Security Considerations for PowerShell Remoting using WinRM（Microsoft Learn）
- How to configure WINRM for HTTPS（Microsoft Learn）
- Smart card certificate requirements and enumeration（KDC の証明書）（Microsoft Learn）
- Guidelines for enabling smart card logon with third-party certification authorities（Microsoft Learn）
- RFC 4556：Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
- Transport Layer Security (TLS) registry settings（Microsoft Learn）
- Features removed or no longer developed in Windows Server（TLS 1.0・1.1）（Microsoft Learn）
- Schannel Events（Microsoft Learn）
- RFC 8996：Deprecating TLS 1.0 and TLS 1.1
コメント