Windows Server 2025でLDAP認証が失敗するときは、ポート、TLS、証明書、バインド方式、適用ポリシーを分けて確認します。389番ポートがすべて平文になるわけではなく、636を指定するだけでLDAPSへ切り替わるわけでもありません。署名要件を無効にする前に、クライアントが保護された接続を使えるか調べましょう。
新規ADとアップグレードで既定を混同しない
Windows Server 2025以降の新しいAD展開では、LDAP署名が既定で要求されます。一方、アップグレードでは既存の署名ポリシーが保持されるため、OS名だけで実際の設定を断定できません。既存ポリシーがない場合の既定も含め、対象DCに適用された結果を確認します。
Server 2025の「Domain controller: LDAP server signing requirements enforcement」は、従来の「LDAP server signing requirements」より優先します。旧ポリシーだけを見て変更したつもりにならず、公式のグループポリシー手順で両者の関係と適用先を確認してください。
LDAP署名・暗号化・チャネルバインディングの違い
| 方式 | 守るものと注意点 |
|---|---|
| LDAP署名 | 非TLSのSASL通信の改ざん検知等。署名だけでは内容の秘匿性はない |
| SASL sealing | 非TLSのSASL通信で暗号化等を提供する |
| LDAPS / StartTLS | TLSで通信を保護する。証明書と相手の名前の検証が必要 |
| チャネルバインディング | TLS上のSASL認証を通信経路と結び付ける。署名設定とは別 |
単純バインドでパスワードを送るアプリは、TLSなしの接続を使わないようにします。ポート389でもStartTLSやSASLの保護を使う構成があるため、「389なら危険、636なら設定を見なくても安全」と判断しないでください。LDAP保護方式の公式整理が比較の根拠になります。
最初に残す情報
- 新規構築かアップグレードか、DCとクライアントのバージョン。
- 接続先のFQDN・ポート・LDAPS/StartTLS設定・バインド方式。
- TLSのエラーか、認証の拒否か、検索結果/権限の問題か。
- 同じ時刻のアプリログとDirectory Service/Schannel等のログ。
- 適用されたGPOと、変更前に動いていた条件。
疎通→TLS→バインド→検索の順に確認する
| 段階 | 成功で分かる範囲 |
|---|---|
| TCP接続 | そのポートへの接続可否。TLSや認証の成功は別 |
| TLSと証明書検証 | 信頼する相手との保護された経路を確立できるか |
| バインド | 選んだ認証方式とアカウントで認証できるか |
| 検索 | ベースDN・フィルター・権限で必要な情報が得られるか |
Windowsのldp.exeでLDAPSを試す場合は、実際のDCのFQDN、636、SSLを指定します。RootDSEが取得できても、業務アプリのアカウントによる認証と必要な検索範囲まで成功したことにはなりません。続いて権限を限定したテストアカウントで検証します。
OpenSSLで証明書を表示できることだけでも不十分です。クライアントが信頼するCAを指定し、名前とチェーンを検証します。次はLDAPSの構文例です。
openssl s_client -connect dc01.example.com:636 -servername dc01.example.com -verify_hostname dc01.example.com -verify_return_error -CAfile approved-ca-chain.pemdc01.example.comとCAファイルは説明用で、実際のDC名と承認済みCAチェーンへ置き換えます。StartTLSを検証する場合は389へ接続し、-starttls ldapを使う構成になります。単に証明書を取得できたという結果と、検証エラーがない結果を区別してください。
AD CSなしでもLDAPSは構成できる
LDAPSはAD CSの新規導入だけを前提にしません。Microsoft以外のCAが発行した適切な証明書も利用できます。既存の社内PKI等の運用方針に従い、発行・配布・更新・失効・秘密鍵の管理を決めます。公開CAが社内専用名や.local名へ必ず発行できると考えないでください。
- DCのFQDNが証明書の名前に適切に含まれている。
- Server Authentication用途を満たし、対応する秘密鍵がDCにある。
- クライアントが発行元からのチェーンを信頼し、有効期限や失効確認条件を満たす。
- 証明書の格納先と選択される証明書を確認する。Local ComputerのPersonalとNTDSストアの関係に注意する。
証明書要件の詳細はMicrosoftの非Microsoft CAによるLDAPS構成を確認します。古い例の鍵長や暗号方式をそのまま採用せず、現在の組織基準に従ってください。複数の証明書がある場合は、入れた証明書が実際に提示されているかを接続側から確認します。
GLPIなどアプリ側で見落としやすい点
接続先のポートを636へ変えただけでは、アプリがTLSを開始する設定にならない場合があります。使用版の設定でSSL/LDAPSかStartTLSかを明示し、同時に矛盾した設定を入れないでください。証明書検証を無効にして接続を通す対応も恒久策にはしません。
Windows上のテストだけ成功してLinux上のアプリが失敗する場合は、そのアプリの実行環境で使うCAストアと実際の接続先名を確認します。エイリアスを使うなら証明書名との整合が必要です。TLS後の認証で止まる場合は、バインド名の形式、パスワード、認証方式、CBT対応を切り分けます。
イベントを読むときの注意点
Directory Serviceの2887/2888等は署名要件に関係する集計、2889は診断設定に応じた詳細の調査に使われます。イベントの意味はOS版と設定を公式資料で確認してください。CBT関連の記録は別の要件として読み、同じ「強力な認証が必要」という表示から一つの設定へ短絡しないでください。
診断ログを増やす場合は、情報量・保存期間・個人情報への影響を考慮して期間を決めます。本番の認証情報を非TLSの単純バインドで送って拒否されるか試す方法は使わず、監査や隔離検証環境で確かめます。
対応できない古いクライアントがある場合
まずアプリの更新、対応するLDAPライブラリ、TLS/署名対応の設定を調べ、業務担当と移行期限を決めます。ドメイン全体の署名やCBTの要件を一括解除する手順を、標準の復旧策にはしません。例外が必要な場合も管理者がリスクと範囲を判断する別の変更管理として扱います。
本番切り替え後の確認
- 各接続先DCが意図した証明書を提示すること。
- 認証だけでなく必要なユーザー/グループ検索が成功すること。
- 不必要に広い権限を与えていないこと。
- 証明書更新後とDC切り替え後も接続できること。
- 未対応クライアントのイベントが残っていないか継続確認すること。
コメント