私は多くのActive Directory(AD)ベースのネットワークをインストールし、ベストプラクティスに基づいてさまざまな標準セキュリティテンプレートを適用しましたが、実際にLDAPをより深いレベルで調べたことはなく、最近OSX Lion LDAPの問題について読んだ後( レジスタ および スラッシュドット )、私はかなり心配しており、かなり心配しています。
私はこれを読むのにしばらく費やしましたが、相反するレポートを見続けています。実際に問題が何であるかについての確かな情報はありますか?
さらに、セキュリティに関しては、すべてを最悪のシナリオ/感染した/何でも...罪のないことが証明されるまで罪として扱うという印象を常に受けていました。これが可能な場合でも、責任があるのはクライアントだけでなく、LDAPサーバーですか?
数年前に自分で同じ間違いをしたことがある:
有効なユーザー名(「匿名」以外)と空のパスワードでログインしようとすると、ほとんどのプロトコル/ソフトウェアはエラーコードを返します。これは、ログインせずに匿名での使用を許可するほとんどのシステムにも当てはまります。
ただし、LDAPの場合、一般的なケースでは、サーバーが任意のユーザー名と空のパスワードを使用したログインを許可します。ユーザーは匿名になります。しかし、ログインは成功を示すステータスコードを返します。
RFC2829 は言う:
LDAPクライアントは、明示的に匿名でバインドすることも選択できます(MAY)。そうしたいクライアントは、バインド要求(セクション4.1を参照)で単純な認証オプションを選択し、パスワードを長さゼロに設定する必要があります。 (これは多くの場合LDAPv2クライアントによって行われます。)通常、名前もゼロ長です。
それでは、ログインがユーザーによって直接行われていないことを想像してください。しかし、ユーザーは他のいくつかのソフトウェアにログインし、このソフトウェアはユーザー名とパスワードを受け取り、舞台裏でLDAPログインを行います。
このソフトウェアがLDAPサーバーからの「成功」結果を盲目的に信頼する場合空のパスワードを処理する特別なケースがない場合、ブーム。
そのソフトウェアは、電子メールアドレスなど、現在のユーザーに関するいくつかの情報を読み取ろうとする場合もあります。しかし、LDAPが人々のディレクトリとして使用されている場合、匿名ユーザーがこの情報にアクセスできる可能性があります。多くの場合、LDAPサーバーは企業ネットワーク内からのみ到達可能であり、インターネットからは到達できません。
初めに、私はこの間違いを自分でしたと言いました。当社のソフトウェアは、さまざまな種類の認証フロントエンドとバックエンドをサポートしています。 影響を受けたシステムはLDAPのみでしたサポートされているすべてのシステムの中で。
これが二度と起こらないようにするために、システムがシングルサインオンサービスやスマートカードなどのパスワードなしでない限り、すべての認証システムの空のパスワードをグローバルに拒否するになりました。また、ドキュメントに追加のテストケースを追加しました(適切なケースをテストし、間違ったパスワードをテストし、空のパスワードをテストします)。
simple
BIND要求は、要求とともに送信されるデータに応じて、4つの形式のいずれかになります。
anonymous
、これはすべての初期LDAPセッションの認証状態でもあります。つまり、LDAPクライアントがBIND要求をまだ発行していないか、BIND要求が失敗または拒否されています。サーバー管理者は、認証が行われていないため、匿名認証の試行を拒否し、BIND応答の結果コードをunwilling to perform
に設定することを検討する必要があります。unauthenticated
。サーバー管理者は、認証が行われていないため、匿名認証の試行を拒否し、BIND応答の結果コードをunwilling to perform
に設定することを検討する必要がありますauthenticated
。サーバー管理者は、これらの要求が非セキュア接続、つまり機密性のない接続で送信された場合、これらの要求を拒否するようにサーバーを構成することを検討する必要がありますundefined
。この場合、サーバーの動作はLDAP標準によって定義されていないため、サーバー管理者は認証が行われていないため、匿名認証の試行を拒否し、BIND応答の結果コードをunwilling to perform
に設定することを検討する必要があります。