Windows Server 2025 のドメインコントローラー（DC）へ LDAP 接続しようとすると、これまで通っていた 389/TCP（平文LDAP）が突然つながらなくなったり、636/TCP（LDAPS）でも「強力な認証が必要」と出て困るケースが増えています。本記事では原因を整理し、AD CS を入れない前提でも現実的に運用できる解決策と、どうしても無理な場合の“安全寄りの回避策”までまとめます。
Windows Server 2025で「LDAPが使えない」と感じる典型症状
- アプリ（例：GLPI など）から DC に LDAP 接続すると、389/TCP で
Strong Authentication Required（強力な暗号化/認証が必要）系のエラーになりバインドできない - 検証用にクリーン構築した DC でも、636/TCP（LDAPS）で同様のエラーになり、期待どおりに認証できない
- 本番では AD CS（証明書サービス）を導入しない方針のため、「証明書なしで何とかならないか」「平文LDAPのまま継続できないか」を検討している
原因の本質：Windows Server 2025はLDAPの“安全でない接続”を前提にしなくなった
結論から言うと、Windows Server 2025 の Active Directory（ドメインコントローラー）は、LDAP の安全性要件（特に LDAP 署名の必須化）が既定で強くなり、従来の「平文389で単純バインド（ID/パスワード送信）」のような接続は弾かれやすくなっています。Microsoft Q&A でも Windows Server 2025 では LDAP signing が既定で有効、LDAPS/TLS を使うか LDAP signing を無効化する必要がある、という趣旨の案内が出ています。
ここで重要なのは、「389番がダメ＝ポートが閉じた」ではなく、認証方式・保護方式が要件を満たしていないことが多い点です。Windows の公式ドキュメントでも、LDAP 署名を要求する構成では、署名なしの SASL バインドや、SSL/TLS で暗号化されていない経路での単純バインドが動かなくなること、識別のためにイベントログ（2887/2889 等）が使えることが説明されています。
「強力な認証/暗号化が必要」エラーが意味すること
アプリ側でよく見るエラー（Strong Authentication Required / 強力な認証が必要 / SASL or StartTLS required など）は、ざっくり言うと次のどれかです。
| よくある状況 | DC側が要求していること | アプリ側の見え方 | 方向性 |
|---|---|---|---|
| 389/TCPで単純バインド（平文） | 署名付きSASL、または StartTLS（途中からTLS）、または LDAPS | Strong Authentication Required | StartTLS/LDAPSに切替 |
| 636/TCPを指定したが、実はTLSになっていない | LDAPSは「最初にTLSネゴシエーション」が必須 | Strong Authentication Required になったり、接続失敗になったり | アプリ設定の「SSL/LDAPS」を正しく有効化 |
| LDAPSにしたが証明書が不正/信頼できない | 正しいサーバー証明書（EKU/SAN/秘密鍵/信頼）が必要 | 通信エラー、バインド失敗、証明書検証エラー | 証明書要件を満たし、クライアントに信頼させる |
加えて、組織のセキュリティ強化状況によっては、LDAP チャネルバインディング（Extended Protection for Authentication, CBT）関連の要件が絡むことがあります。チャネルバインディングは「中間者攻撃を受けにくくする」仕組みで、GPO とレジストリ（LdapEnforceChannelBinding）で制御され、監査・失敗イベント（3039/3074/3075 等）を使って影響調査する、という流れが Microsoft の案内にまとまっています。
まずやるべき切り分け：ポートの疎通ではなく「TLSが成立しているか」を確認する
389/636 が開いているかだけを見ても、今回の問題は解けません。重要なのは “LDAPS（TLS）が成立しているか” と “アプリが本当にLDAPS/StartTLSを使っているか” です。
確認チェックリスト（現場で迷いにくい順）
| チェック | 確認方法（例） | OKの目安 | NGだった場合の典型原因 |
|---|---|---|---|
| 636/TCPでTLSハンドシェイクできるか | openssl s_client -connect dc01.example.local:636 -showcerts （StartTLSなら -starttls ldap） | 証明書チェーンが返り、TLSが確立する | DCに有効な証明書がない／証明書要件不足／クライアントが信頼していない |
| DC側でLDAPSが有効になっているか | DC上で ldp.exe → 636 で接続 | RootDSE情報が表示される | 証明書不備、Schannelが別証明書を選択、再起動未実施 など |
| アプリが“ポート636”ではなく“LDAPS”で接続しているか | アプリ設定画面で「SSL/LDAPS」「StartTLS」等の項目を確認 | LDAPS（SSL）または StartTLS が明示的にON | ポートだけ変えた／URIが ldap:// のまま／StartTLS未使用 |
| DCのイベントログで拒否理由を追えるか | Directory Service ログ（2887/2888/2889 など） | “どのクライアントが未対応か”が追跡できる | ログレベル未設定、監査イベント未有効 |
特にイベントログは強力です。Microsoft の説明では、署名なし/非TLSのバインドが発生すると 24時間ごとに要約イベント（2887）、詳細を出したい場合は追加ログで 2889 を出せる、という整理になっています。
イベントIDで原因を絞る（よく使うものだけ）
| イベントID | 意味（要約） | 現場での使い方 |
|---|---|---|
| 2887 | 過去24時間の「署名なしSASL」または「非TLSの単純バインド」の要約 | 影響範囲（未対応クライアントが残っているか）を把握 |
| 2889 | 未対応バインドの詳細（IP/アカウント/種別） | “犯人端末/アプリ”を特定して設定変更へ |
| 3039 / 3074 / 3075 | LDAPチャネルバインディング（CBT）関連の失敗/監査 | チャネルバインディング要件が絡む環境で調査 |
推奨解決策：LDAPS（636）または StartTLS（389）に移行する
Windows Server 2025 の方向性に合わせるなら、「アプリ側をTLS対応に切り替える」のが正攻法です。具体的には次の2択（または併用）になります。
- LDAPS：636/TCP を使用し、接続開始からTLSで保護する
- StartTLS：389/TCP で接続し、途中で TLS に切り替える（StartTLS拡張要求）
Microsoft の LDAPS 有効化手順では「ドメインコントローラーに要件を満たす証明書を入れると、LDAPサービスがSSL接続を待ち受ける（自動的に受け付ける）」と説明されています。つまり “AD CS ロールを入れるかどうか” と “LDAPSが使えるかどうか” は別問題です。証明書さえ用意できれば、AD CS を導入しない方針でも LDAPS 運用は可能です。
AD CSなしで用意できる「サーバー証明書」の選択肢
| 選択肢 | メリット | デメリット | 向いているケース |
|---|---|---|---|
| 商用CA（公開CA） | 多くのクライアントで信頼済み。配布の手間が小さい | コストがかかる。FQDNや更新運用が必要 | 拠点が多い／アプリサーバーが多い／運用を簡素化したい |
| 既存の社内CA（別基盤のPKI） | 組織内で統制しやすい。コストを抑えられる | クライアントへルート証明書配布が必要 | すでに社内CAがある（ただしAD CSでなくても可） |
| 自己署名証明書 | すぐ試せる。検証が早い | クライアント側で信頼させないと失敗しやすい。更新/失効の設計が弱い | 検証環境、短期の検討、閉域の限定運用 |
LDAPS用サーバー証明書の要件（ここを外すと636が不安定になる）
LDAPS は「証明書があれば何でも良い」ではありません。Microsoft の KB（321051）では、LDAPS を有効にするための証明書要件が具体的に列挙されています。要点だけ抜き出すと次のとおりです。
- 証明書は ローカルコンピューターの個人（MY）ストア（または NTDS ストア）に配置されている
- 秘密鍵が存在し、証明書と正しく関連付いている（強い秘密鍵保護は無効が推奨）
- EKU（拡張キー使用法）に Server Authentication（OID: 1.3.6.1.5.5.7.3.1）が含まれる
- DC の FQDN が Subject の CN または SAN（DNS）に含まれる
- DC と LDAPS クライアント双方が信頼するCAで発行されている（自己署名の場合はクライアントへ信頼を配布する）
また、LDAPS 接続トラブルの調査手順として、Microsoft は「サーバー証明書のCN/SANにFQDNがあること」「EKUにServer Authenticationがあること」等の観点を第一に確認するよう案内しています。複数の有効な証明書があると Schannel が意図しない証明書を選ぶ可能性がある点も、地味にハマりどころです。
導入手順（AD CSなし・最短ルート）
ここでは「本番で AD CS を入れない」前提で、現実的に多い流れを“手戻りしにくい順”にまとめます。
- DCのFQDNを確定する LDAPS は証明書の名前検証が絡むため、IP直打ちや短いホスト名では失敗しやすくなります。まずはアプリが接続する宛先を dc01.example.local のようなFQDNに統一します。
- 要件を満たす証明書を用意する 公開CAでも社内CAでも構いません。自己署名の場合は「クライアントが信頼できる状態」を作る作業までセットです。Microsoft の KB には、certreq を使った証明書要求ファイル（INF）の例も載っています。
- 証明書を DC にインポートする（ローカルコンピューターの個人ストア） 秘密鍵付き（PFX など）で入れ、EKU/SAN/FQDNを再確認します。証明書が入ると LDAPS を受け付ける動きになる、という説明が Microsoft にあります。
- DC を再起動（または証明書更新トリガー）して反映させる Schannel の都合で再起動が効く場面があります。KB でも「差し替え時は再起動が必要になる場合がある」旨が触れられています。
- DC上で ldp.exe で 636 接続し、RootDSEが出るか確認 Microsoft は LDAPS 有効化の確認手順として、ldp.exe で 636 接続して RootDSE が出ることを挙げています。
- アプリサーバー側からも 636 のTLS確認 → アプリ設定変更 アプリが動くサーバーから TLS ハンドシェイクできるかを確認し、そのうえでアプリ設定を LDAPS/StartTLS に切り替えます。
GLPIで636を指定しても失敗する“ありがちな落とし穴”
GLPI のような「LDAP連携機能を持つWebアプリ」で、ポートだけ 636 にしても直らないケースは珍しくありません。理由は大きく2つです。
落とし穴：636を入れただけで、通信がLDAPSになっていない
アプリやライブラリによっては、
ldap.example.local+ ポート636を設定しただけ- 接続URIが
ldap://のまま - 「SSLを使う」「LDAPS」チェックがOFF
の状態だと、“平文LDAPを636に投げる”形になり、結果として「強力な認証が必要」になったり、そもそも接続に失敗します。LDAPS は「接続直後にSSL/TLSネゴシエーション」が前提であることが Microsoft の KB に明記されています。
落とし穴：LDAPSはできているが、証明書を信頼できず失敗している
自己署名証明書や社内CA証明書を使う場合、アプリサーバー側（OSやランタイム）がそのCAを信頼していないと、TLSが確立できません。Microsoft は LDAPS トラブルシュートとして、サーバー証明書の要件や、証明書が複数ある場合の Schannel の選択問題などを挙げています。
GLPI側の設定で押さえるポイント（ベース設計）
- 接続方式：LDAPS（SSL）か、389 + StartTLS のどちらかを明示的に有効化
- 接続先：DC の FQDN（証明書の CN/SAN と一致させる）
- 認証：可能なら単純バインドより、環境に合った安全な方式（StartTLS/LDAPS 前提）へ
- 証明書検証：自己署名/社内CAの場合は、アプリサーバーの信頼ストアへルート/中間CAを配布
- 検索条件：Base DN、フィルタ、ユーザー属性（sAMAccountName / userPrincipalName）を整理
「AD CSを入れない」はOK。ただし「証明書なしで安全に」は基本的に成立しない
ここが誤解されやすいポイントです。
- AD CS を導入しない：運用方針として十分あり得る（既存PKIや公開CAで代替可能）
- 証明書を使わない：LDAPS/StartTLS（TLS）そのものが成立しないため、Windows Server 2025 の要件強化と衝突しやすい
Microsoft の LDAPS 有効化手順（KB321051）でも、LDAPS を有効にするには要件を満たす証明書が必要で、証明書が入ることで LDAP が SSL 接続を受け付けるようになる、という整理です。
どうしても平文LDAP（389）を残したい場合：要件緩和という選択肢はあるが、短期・限定で
アプリがどうしても StartTLS/LDAPS に対応できない、改修が間に合わない、移行期間が必要——このような事情がある場合に限り、ドメインコントローラー側の要件を緩和して “古い動き” に戻すことは技術的には可能です。
ただし、これはセキュリティ上の後退です。Microsoft の LDAP 署名に関する説明でも、署名なし/非TLSの通信が中間者攻撃や改ざん等のリスクを高めることが述べられており、恒久運用としては推奨されません。
緩和で触ることが多い設定（代表例）
| 設定名 | 場所（GPO） | 変更の方向性 | 期待される効果 | 主なリスク |
|---|---|---|---|---|
| Domain controller: LDAP server signing requirements | セキュリティ オプション | 「要求」→「なし（交渉/任意）」へ | 署名できないLDAPクライアントが通りやすくなる | 改ざん耐性の低下、攻撃面の拡大 |
| Network security: LDAP client signing requirements | セキュリティ オプション | 要件を緩める | クライアント側が署名を要求しすぎている場合に調整 | クライアント側の安全性低下 |
| Domain controller: LDAP server channel binding token requirements | セキュリティ オプション | 「Always」→「When supported / Never」へ | CBT非対応クライアントとの互換性を確保 | 中間者攻撃耐性の低下 |
なお「LDAP server signing requirements」の挙動について、Microsoft Learn の説明では「Require signature は TLS/SSL が使われていない場合に署名交渉を要求する」旨が書かれています。つまり、正しくLDAPS/StartTLSに移行できれば、署名要件のせいで詰まる確率は下がります。
緩和をやるなら“セット”で入れたい防御（現実的な落としどころ）
- 通信経路の制限：DCの389を、アプリサーバーのIPからのみ許可（FW/ACLで制限）
- 移行期限を決める：緩和は「撤去がゴール」。例：3か月以内にLDAPSへ
- ログで可視化：2887/2889 を見て、未対応クライアントを潰していく
- 例外管理：どうしても残る装置（複合機・アプライアンス等）は分離ネットワークへ
Microsoft の手順でも、影響調査としてイベントログ（2887/2889 等）で未対応クライアントを特定し、段階的に強制へ進む流れが推奨されています。
本番運用で失敗しないための設計ポイント
接続先は「DCのFQDN」を標準にする
LDAPS は証明書の名前検証が絡むため、IPアドレスや別名で接続すると証明書不一致になりがちです。証明書の CN/SAN に入っている名前（通常はFQDN）で統一してください。Microsoft の LDAPS トラブルシュートでも、FQDN が CN または SAN に含まれることが要件として挙げられています。
証明書が複数あるDCは“Schannelの選択”に注意
DC のローカルコンピューターストアに有効な証明書が複数存在すると、Schannel が意図しない証明書を選んでしまい、LDAPS が不安定になることがあります。Microsoft は「複数証明書の確認」や、証明書ストアの扱い（NTDS ストア優先など）に触れており、運用では「LDAPSに使わせたい証明書を明確にする」ことが重要です。
監視は「死活（636が開いている）」より「TLSでRootDSEが取れる」を見る
TCP 636 が開いていても、証明書不備があると LDAP リクエストが通らないことがあります。監視や運用チェックは、可能なら RootDSE を取得できるか（ldp.exe相当の確認）まで踏み込むと、更新時の事故を早期に拾えます。LDAPS 確認として RootDSE の表示を挙げる Microsoft の手順は、この運用設計にも使えます。
将来の強制に備え、チャネルバインディングも“監査→修正→強制”で進める
LDAP のセキュリティ強化は「いきなり強制」するとアプリが一斉に落ちます。Microsoft の KB では、CBT/署名の監査イベント（3039/3074/3075、2889 等）で未対応を洗い出し、段階的に対応する流れが推奨されています。Windows Server 2025 世代の運用では、この“段階導入”が現実解になりやすいです。
まとめ：Windows Server 2025でLDAP連携を安定させる最短ルート
- Windows Server 2025 の DC では LDAP の安全性要件が強まり、389 の平文・単純バインドは失敗しやすい
- 本命は LDAPS（636） または StartTLS（389） への移行。AD CS を導入しなくても、公開CAや既存PKI、（検証なら）自己署名で運用は可能
- 636 で失敗する場合は「DCに要件を満たす証明書があるか」「アプリが本当にLDAPSになっているか」「クライアントが証明書を信頼できているか」を優先して切り分ける
- どうしても移行が間に合わない場合のみ、GPOで要件を緩和する回避策はあるが、ログ（2887/2889等）で未対応を潰し、早期にTLS前提へ戻す
コメント