（如果我问了错误的问题或在错误的地方问了问题，请原谅。）
我们为协会（所有志愿者）运营 IT。我们拥有一台服务器，其中有 OpenLDAP 中的会员数据库、邮件服务器、ftp 和一堆自制的 Web 应用程序。
除了 OpenLDAP 成员数据库之外，其他大部分都很好。设置它的人早已离职，而当前的 IT 团队实际上没有能力进行更改。
因此，我正在考虑将成员数据库从 OpenLDAP 移至 MySQL 数据库。这似乎是可行的，我们的电子邮件和 FTP 服务器支持 SQL 源，我们可以相应地修改我们的 Web 应用程序。但我仍然无法确定这样做是否有缺点。因此我的问题：
- LDAP 与 SQL 数据库相比有哪些优势？（适用于简单用户数据库）
- 有什么理由不使用 MySQL 作为用户数据库吗？
我在这里找不到类似的问题。而我在外部找到的信息让我找到了 10 多年前的页面。
答案1
这是一个广泛的话题，没有简单的答案，因为它取决于很多因素。
(Open)LDAP 作为用户数据库的一些好处：
- LDAP 具有固有的树结构，可使大型组织的构建更加容易。此外，为记录设置一个数据字段也比在 SQL 数据库中执行此操作更容易，该记录实际上是事物的列表（例如“用户是这些组的成员”）（注意：在 SQL 中两者都完全可行，只是更复杂）。
- 使用 LDAP 作为多个系统的中央用户数据库更加容易。对于也可以使用 Linux PAM 作为身份验证源的邮件或 FTP 或您控制的自建系统来说，这不是什么大问题，但特别是如果您添加第三方 Web 应用程序，您通常会发现每个系统都有自己的用户数据库，这些数据库的架构不兼容，无法共享任何数据。在这种情况下，您通常至少可以与 LDAP 同步和/或对其进行身份验证。
- 记录的 LDAP 对象类使得许多具有不同要求的不同系统可以轻松地使用同一个数据库 - 只需向记录添加一个对象类，并获取一大堆其他记录中不存在的特定于类的字段，并且需要为 SQL 中的每条记录提供大量空字段。
- LDAP 可以是一个黑盒身份验证系统。这意味着您可以拥有一个只向 LDAP 发送用户名和密码的应用程序，并询问“这个组合有效吗？”并得到是/否的答案。使用 SQL，应用程序实际上需要读取数据库并自行进行检查。
不幸的是，与简单的 SQL 数据库相比，实际管理 LDAP 要复杂得多，如果你的所有系统都可以使用同一个 SQL 用户数据库，那么你没有理由需要改为使用 LDAP。另一方面，我认为非常经过漫长而艰难的思考，在删除 LDAP 并将其替换为其他内容之前，坐下来理解它是否真的更容易。这类更改在开始时往往看起来很容易，但在此过程中总会有一些你没有考虑到的问题出现，这会使事情比预期的要困难得多。
答案2
您可以使用 MySQL 数据库作为用户帐户的共享源吗？当然可以。我已经安装了这样的系统，它在多个应用程序上运行良好。
那么，使用 MySQL 数据库而不是 LDAP 有哪些缺点？
a) 您需要调整所有应用程序以使用您的数据库。
适应起来通常不需要做太多工作一个应用程序。通常，您只需创建一个适应列名的视图即可解决此问题。有时，您可能需要添加一些代码来满足不同的密码哈希格式，或者创建身份验证插件。
但是，你需要这样做适用于每一个应用。当明天要求您安装新的 Web 应用程序（例如，有人决定添加 Wordpress 博客）时，您将需要再次研究该应用程序并了解如何适应它。
“每个人”都支持 LDAP 身份验证。它是事实上标准，你会发现任何规模适中的应用程序都有用于执行 LDAP 身份验证的插件（而对于那些没有插件的应用程序，显然有理由实现它）。还有一些（非常少的）替代方案，它们几乎不支持用于身份验证。
另请注意，如果应用程序碰巧使用不同的数据库引擎（假设有新的开发需要使用 PostgreSQL），那么让它支持来自不同引擎（mysql）的用户表可能会更加困难。
当然，只有当它是你自己开发的或开源的时，你才能进行改编。别想让微软 Windows 支持这种自定义方案了！
b) 安全集中化
使用中央身份验证服务器有多个好处：
首先，如果您有一个中央服务器，并且有人试图强行破解用户的密码john，则常见的设置是让它阻止该用户一段时间（或直到手动解除阻止）。如果您有十几个服务，即使所有服务都有一些限制措施（提示：它们可能没有），每个服务都会被分开，并且通过攻击多个服务，攻击者实际上会尝试 N 次服务数量。您需要将元数据协调到共享数据库中，并协调所有服务以相同的方式检查和实施（需要向应用程序、邮件和 ftp 服务器添加更多代码……）。
第二，集中日志记录。在单个服务上执行身份验证可让您拥有单个身份验证日志，而不是将其分散在多个地方。
第三，它是更新的单点。您想放弃 MD5 哈希而使用 pdkdf2 或 Argon2？您只需更新身份验证服务器以支持它。否则，您需要获取每项服务来支持该新格式。
第四，更大的隔离性。如果所有身份验证都通过中央服务器进行，则应将其配置为只有他才能读取敏感数据，这样您就可以集中精力确保其安全。但是，如果每个服务都需要验证用户密码，那么您将面临更大的风险：SQL 注入漏洞任何他们会允许转储用户和哈希列表（我已经假设它是只读的，否则他们甚至可以修改它们，或者插入虚假用户）。
请注意，您可以通过使用完全不使用 LDAP 的中央服务器来解决 (b)。但考虑到 (a)，继续使用 LDAP 协议进行身份验证是有意义的。
主要用于身份验证的 LDAP 服务器没有理由不能使用 MySQL 数据库进行存储。事实上，LDAP 的功能比它通常的用途要强大得多（这就是它看起来如此令人生畏的原因）。但是，我不知道有任何实现这样做。
我的建议是保留您当前的 LDAP 服务器，并在需要时创建一个界面来在其上执行最常见的操作（有多个 LDAP 前端，也许其中一个可以满足您的 IT 组的需求？）。
如果您想更改自定义 Web 应用程序登录流程，我会让它们支持单点登录解决方案（例如 SAML），但我仍然会让它使用该 LDAP 后端，该后端将与您的 FTP、邮件和其他服务共享。
答案3
只是想补充一些其他答案中尚未指出的内容：比较 LDAP 和 SQL 就像比较苹果和橘子，因为它们位于堆栈中的不同层。
- LDAP = 支持通过 IP 提供的目录服务
- SQL = 通用数据库管理，当然也包括用户管理
您可以使用 SQL 数据库实现 LDAP，但请记住它们支持不同的功能。（事实上，大多数 LDAP 解决方案可能在后台使用一些 SQL 或其他数据库。）
LDAP 是目录服务的行业标准。您的许多下游服务可能都依赖 LDAP 服务进行身份验证、授权等，在这种情况下，您仍然需要在新的 SQL 数据库之上构建一个 LDAP 兼容层。
同时，您的其他应用程序可能不需要此 LDAP 兼容性，并且迁移到您自己的 SQL 用户管理可能更容易。但即使在这种情况下，我怀疑您可能需要在应用程序中使用自己的用户管理逻辑（除非它们支持 OAuth 或类似的东西。）
我建议首先查看您的其他 IT 应用程序，了解它们与 LDAP 服务的登录和授权服务的关联程度，然后再决定迁移到自定义 SQL 数据库解决方案的难易程度。