VPN証明書はLDAP区間を守らない

ディレクトリに対して資格情報を確認するVPNログインには、二つの別個のネットワーク接続が関わります。ユーザーからゲートウェイへの接続は、VPN自身の証明書とプロトコル設定によって保護されています。ゲートウェイからディレクトリへの接続は、独自のTLS設定、独自のトラストストア、独自の障害の仕方を持つ別のセッションです。前者が成り立っても、後者については何も保証されません。

この非対称性こそ、暗号化されて見えるのにbindパスワードを平文で送ってしまうログインの仕組みです。

二つの接続、二つの信頼判断

外側のセッションはユーザーが見るもので、VPNのホスト名に結び付いた証明書がクライアントによって検証され、認証のやり取りを運びます。内側のセッションはゲートウェイ内部のディレクトリクライアントのもので、独自に接続を開き、TLSをネゴシエートするかしないかを決めます。どちらの側も、自分が話す相手を別の設定ファイルの素材で検証します。設定を誤った内側の区間は、外側の区間が意図どおりに機能するため、ユーザー側からは見えません。

だからこの障害は大げさではなく静かです。ディレクトリの証明書を決して確認しないゲートウェイでも、ユーザーの認証は正しく行われますが、検証していない経路で認証しているだけです。

StartTLSとLDAPSを意図的に選ぶ

StartTLSは通常のLDAPとして開かれ、慣例的なポート389でその場でアップグレードされます。LDAPSは接続と同時にTLSを開始し、慣例的には636番ポートです。どちらも正当で、アダプターはディレクトリが提供するものに合わせる必要があります。StartTLSを必須にすることは、試して失敗したときに続行することとは異なり、その違いこそbindパスワードが漏れ得る場所です。厳格モードを設定し、パスワードbindに保護されない代替経路を許さないでください。

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZオプションこそが要点で、クエリはアップグレードなしに黙って進むのではなく失敗します。その行の名前とアカウントは例です。OpenLDAPのTLSドキュメントには、その背後にある信頼設定が書かれています。

LDAPクライアントはどのトラストストアを読みますか？

OpenLDAPのクライアントライブラリは、システムファイルからであれプラグイン固有の設定からであれ、独自の信頼設定を読みます。VPNのCAディレクティブはVPNピアに適用されるものであり、LDAPライブラリが同じファイルを読む証拠ではありません。証明書が実際にカバーするディレクトリのホスト名と、ライブラリが信頼する発行チェーンを使ってください。Active Directoryでは、表示名から推測するのではなく、サーバー認証の用途が正しいディレクトリサービス証明書を配備してください。

フェイルオーバー先はすべて同じIDポリシーを満たす必要があります。プライマリが検証されセカンダリが検証されない環境は、弱い経路が障害時にしか発見されないため、フェイルオーバーのない環境より悪いです。

bindアカウントは別の問題のまま

トランスポートを守っても、bindアカウントができることは減りません。ディレクトリの検索範囲、グループ認可、サービスアカウントの権限は別々の決定であり、広いbindアカウントはTLSを有効にしても広いままです。統合に必要な最小のサービスアカウントと検索ベースを使い、エンドポイント、TLSモード、信頼の所有者、更新プロセスをVPN設定と一緒に記録してください。

証明書の不一致が現れたら、正しい証明書またはチェーンを配備してください。検証を無効にすると、目に見える不一致が見えないものになり、二つ目の信頼関係は未検証のまま残ります。

二つの接続、二人の所有者、二つの更新日。これらを文書で分けておくことが、ログインを誠実に保ちます。