MySQLデータベースはLDAPの実行可能な代替ですか？
（私が間違った種類の質問をしたり、間違った場所で質問していた場合はお詫びします。）
私たちは協会（すべてのボランティア）のためにITを運営しています。 OpenLDAPのメンバーデータベースを備えたサーバー、メールサーバー、ftp、自家製ウェブアプリケーションの束があります。
OpenLDAPメンバーデータベースを除いて、これのほとんどは問題ありません。それを設定した人はもういなくなっており、現在のITグループは実際に変更を加えることができません。
それで、私はメンバーデータベースをOpenLDAPからMySQLデータベースに移動することを考えていました。これは可能だと思われます。電子メールおよびFTPサーバーはSQLソースをサポートしており、それに応じてwebappsを変更できます。しかし、私はこれを行うことに不利な点があるかどうかまだ判断できません。したがって、私の質問：
- SQLデータベースに対するLDAPの利点は何ですか？（単純なユーザーデータベースの場合）
- MySQLをユーザーデータベースとして使用しない理由はありますか？
このあたりで、比較できる質問が見つかりませんでした。また、外部で見つけた情報により、10年以上前のページに移動します。
これは多くの要因に依存するため、簡単な答えのない幅広いトピックです。
ユーザーデータベースとしての（オープン）LDAPのいくつかの利点：
- LDAPには、大規模組織の構造化を容易にする固有のツリー構造があります。 （ユーザーがこれらのグループのメンバーであるなどの）実際のリストであるレコードのデータフィールドを作成し、SQLデータベースでこれを実行することも簡単です（注：両方ともSQLでは絶対に可能ですが、さらに複雑です）。 。
- 複数のシステムの中央ユーザーデータベースとしてLDAPを使用する方が簡単です。これは、認証ソースとしてLinux PAMも使用できるMailやFTPなどの場合、またはユーザーが制御する自社開発のシステムの場合はそれほど問題ではありませんが、特にサードパーティのWebアプリケーションを追加すると、各システムに多くの場合、データを共有できない互換性のないスキーマを持つ独自のユーザーデータベース。その場合、多くの場合、少なくともLDAPと同期したり、LDAPに対して認証したりできます。
- レコードのLDAPオブジェクトクラスを使用すると、さまざまな要件を持つ多くの異なるシステムで同じデータベースを簡単に使用できます。オブジェクトクラスをレコードに追加すると、他のレコードには存在せず、他のレコードにはないクラス固有のフィールドがたくさん集まります。 SQLのすべてのレコードについて、空のフィールドをたくさん並べる必要があります。
- LDAPはブラックボックス認証システムにすることができます。つまり、ユーザー名とパスワードをLDAPに送信するだけで、「このコンボは有効ですか？」はい/いいえの回答を取得します。 SQLでは、アプリは実際にデータベースを読み取り、チェック自体を行う必要があります。
残念ながら、実際のLDAPの管理は単純なSQLデータベースに比べてはるかに複雑であり、すべてのシステムが同じSQLユーザーデータベースで完全に機能できる場合、が必要な本当の理由はありません代わりにLDAPを使用します。一方、私はvery長くて難しいと思うでしょう。実際にLDAPを取り出してそれを別のものに置き換える前に、それを理解して理解するのが実際には簡単ではない場合です。これらの種類の変更は、最初は簡単に見える傾向がありますが、その過程で、予期していなかった問題が常に発生するため、予想以上に困難になります。
MySQLデータベースをユーザーアカウントの共有ソースとして使用できますか？はい、間違いなく。私はそのようなシステムをマウントしました、そしてそれは複数のアプリケーションでかなりうまくいきます。
では、LDAPの代わりにMySQLデータベースを使用することの欠点は何ですか？
a）データベースを使用するには、すべてのアプリケーションを調整する必要があります。
通常、anアプリケーションを適応させるのはそれほど多くの作業ではありません。多くの場合、列名を適合させるビューを作成するだけで解決できます。場合によっては、別のパスワードハッシュ形式に対応するためのコードを追加したり、認証プラグインを作成したりする必要があります。
ただし、アプリケーションごとにを実行する必要があります。そして、明日新しいWebアプリケーションをインストールするように求められた場合（たとえば、誰かがWordpressブログ）を追加することを決定した場合）、アプリケーションを再度調査し、それを適応させる方法を確認する必要があります。
'Everyone'はLDAPに対する認証をサポートします。これはデファクト標準であり、適切なサイズのアプリケーションでLDAP認証を行うためのプラグインが見つかりますしないでください。それを実装する明確なケースがあります）。いくつか（非常に少数）の代替があり、認証に使用するためのサポートはほとんどありません。
また、アプリケーションがたまたま別のデータベースエンジンを使用している場合（PostgreSQLを使用する必要がある新しい開発がある場合）、別のエンジン（mysql）のユーザーテーブルを追加でサポートするのが難しい場合があります。
もちろん、適応自体は、それがあなた自身の開発またはオープンソースである場合にのみそれを行うことができます。 Microsoft Windowsがそのようなカスタムスキームをサポートすることを忘れてください！
b）セキュリティの集中化
中央認証サーバーを使用すると、複数の利点があります。
たとえば、中央サーバーがあり、誰かがユーザーjohnのパスワードをブルートフォースにしようとする場合、一般的な設定では、しばらくの間（または手動でブロックを解除するまで）ユーザーをブロックします。サービスが12ある場合、それらすべてに何らかの調整手段があったとしても（ヒント：おそらくそうではないでしょう）、それらのそれぞれは分離され、複数のサービスを攻撃することにより、攻撃者は実際にN回の試行回数のサービスを持つことになります。そのメタデータを共有データベースと調整し、それらをチェックして同じ方法で実装するためのすべてのサービスを調整する必要があります（アプリケーションに追加するコード、メールサーバー、FTPサーバーなど）。
第二に、集中ロギング。単一のサービスで認証を実行すると、複数の場所に分割するのではなく、単一の認証ログを保持できます。
第三に、それは更新のための単一のポイントです。 MD5ハッシュから離れてpdkdf2またはArgon2を使用したいですか？それをサポートするために認証サーバーを更新する必要があるだけです。そうでなければ、その新しいフォーマットをサポートするためにeach and every serviceを取得する必要があります。
第四に、より大きな分離。すべての認証が中央サーバーを経由する場合は、機密データを読み取ることができるのは彼だけになるように構成する必要があります。集中して、安全であることを確認できます。ただし、すべてのサービスがユーザーパスワードを検証する必要がある場合は、より大きな影響があります。それらのSQLインジェクションの脆弱性anyは、ユーザーとハッシュのリストをダンプすることを許可します（そして、それは読み取り専用にされました、さもなければ彼らはそれらを修正したり、偽のユーザーを挿入したりすることができるかもしれません）。
（b）LDAPをまったく使用しない中央サーバーを用意することで解決できることに注意してください。ただし、（a）認証にLDAPプロトコルを使用し続けることは理にかなっています。
主に認証に使用されるLDAPサーバーがMySQLデータベースをストレージに使用できなかった理由はありません。実際、LDAPは、通常の使用よりもはるかに強力です（そのため、LDAPは非常に困難に見えます）。ただし、それを実行する実装については知りません。
現在のLDAPサーバーを維持し、必要に応じて最も一般的なアクションを実行するためのインターフェイスを作成することをお勧めします（複数のLDAPフロントエンドがあり、そのうちの1つがITグループのニーズをカバーする可能性があります）。
カスタムWebアプリケーションのログインプロセスを変更したい場合は、SAMLなどのシングルサインオンソリューションをサポートするように設定しますが、それでも、FTP、メール、他のサービス。
他の回答で（まだ）指摘されていないものを追加したかっただけです。LDAPとSQLを比較すると、リンゴとオレンジがスタックの異なるレイヤーにあるため、それらが比較されます。
- LDAP = IP経由のディレクトリサービスをサポート
- SQL =一般的なデータベース管理。もちろん、ユーザー管理を含めることができます
SQLデータベースを使用してLDAPを実装できますが、それらが異なる機能をサポートしていることを覚えておいてください。 （実際、ほとんどのLDAPソリューションは、裏で何らかのSQLまたは他のデータベースを使用している可能性があります。）
LDAPは、ディレクトリサービスの業界標準です。ダウンストリームサービスの多くが認証、承認などをLDAPサービスに依存している可能性があります。その場合でも、新しいSQLデータベースの上にLDAP互換レイヤーを構築する必要があります。
同時に、他のアプリケーションがこのLDAP互換性を必要としない可能性があり、独自のSQLユーザー管理に移行する方が簡単な場合があります。しかし、この場合でも、アプリケーションで独自のユーザー管理ロジックが必要になる可能性があります（ただし、OAuthまたは同様のものがサポートされている場合を除く）。
最初に他のITアプリケーションを調べて、それらがログインサービスと承認サービスのLDAPサービスにどのように関連付けられているかを確認し、次にカスタムSQLデータベースソリューションに移行するのがどれほど簡単か苦痛かを判断することをお勧めします。