LDAP自体は、アクティブまたはパッシブの攻撃者に対して安全ではありません。
- データは暗号化されずに「そのまま」移動するため、受動的な攻撃者によってスパイされる可能性があります。
- アクティブな攻撃者は、ストリームを操作して独自のリクエストを挿入したり、自分への応答を変更したりできます。
せいぜい、基本的なLDAPは（ [〜＃〜] sasl [〜＃〜] を介して単純ではないいくつかの認証メカニズムに依存する可能性があります攻撃者による破壊：認証が「パスワードの表示」タイプである場合、パッシブ盗聴者はパスワードを学習し、IDを使用してサーバーに接続できます。 CRAM-MD5 のような少し高度なプロトコルは、その特定の問題を回避しますが、攻撃者が接続をハイジャックしたり、実際の要求や応答をスパイしたりしても何もしません。
つまり、セキュリティを重視する場合は、SSL（つまり「LDAPS」）を使用してください。多くの点で、これはHTTPとHTTPSのようなものです。
補足として、LDAPに基づいて構築されたMicrosoftのActive Directoryプロトコルは、オプションで「署名と暗号化」機能を提供します。 mightで十分なセキュリティを確保できます。ただし、そのプロトコルのきちんとした詳細な仕様を見たことがないので、その場合でもLDAPSをお勧めします。
LDAPプロトコルはデフォルトでは安全ではありませんが、プロトコルは既存のLDAPプロトコルを介してTLSセッションを確立する操作（StartTLS拡張操作）を定義します。あるいは、（SASLを介した）一部の認証メカニズムでは、署名と暗号化を確立できます。最近のLDAPベースのディレクトリサーバーのほとんどはこれらのモードをサポートしており、多くの場合、安全でない通信を防ぐための構成パラメーターがあります。
一方、LDAPSは、適切な暗号がネゴシエートされる限り、デフォルトで安全です。
証明書を作成し、adminエントリにインストールしたユーザー証明書を使用してLDAPにログインします。
明らかに、TLSセッションは、クライアント証明書認証がTLSで行われない限り、認証の品質ではなく、パケットスニッフィングに対する基準を引き上げるだけです。
プレーンテキストのパスワードは最悪のオプションであり、そこから上に行く... SASLなど.
インターネットからLDAPサーバーにアクセスするユーザーが懸念していて、「一部」の属性へのアクセスのみを許可したい場合は、389にプロキシを設定して、サーバーへのリクエストをフィルタリングできます。 LDAPまたはLDAPSの既知のデフォルトポートを使用すると、ユーザーがサービスを見つけやすくなります。
また、インターネットに接続されたLDAPサーバーのDNSにSRVリソースレコードエントリを配置することを検討してください。そうすることで、ユーザーは適切なアドレスとポートを使用してプロキシサーバーにアクセスできます。