我们构建了一个web应用程序（运行在intranet上），该应用程序依赖于用户的LDAP目录（活动目录）。我们使用LDAP目录，而不是将目录用户与应用程序数据库（MySQL）中的"用户"表"同步"，就像使用数据库一样。
当创建从MySQL提取的实体和LDAP用户之间的关系时，我们使用用户GUID（这是一个唯一的字符串）。
我们的目录永远不会有超过300个用户（永远不会）。我们安装了一个专用的DC（域控制器）来满足我们的应用程序请求。网络延迟不是问题。
在我们的代码中，我们可以替换几行代码，从使用LDAP切换到使用MySQL和"用户"表（数据映射器非常棒）
你会这样做吗（没有"用户"表同步）？你反对这种做法的理由是什么？
编辑
我们确实使用了一个"用户"表，但它非常简单，所以sql联接并不是一个真正的问题，我们知道它在使用完整用户表时会有更好的性能，但我们正在寻找其他反对使用LDAP 的论据
CREATE TABLE `user` (
`_id` int(4) unsigned NOT NULL AUTO_INCREMENT,
`guid` varchar(255) NOT NULL,
PRIMARY KEY (`_id`)
);
我不会这么做。我会在每次登录时同步用户数据，除了密码。这样，您就可以在应用程序的数据库中获得应用程序的当前数据，并且可以使用数据库联接功能来获取所有相关信息，而无需查询不同的系统。我只使用LDAP进行身份验证，也许还可以使用基于LDAP组的授权模型。
- 这样你就不需要麻烦使用密码和任何密码政策
- 登录后，您将完全独立于LDAP服务器
- 丢失的LDAP服务器不会影响已登录的用户，只会影响新用户登录将不起作用
即使对象GUID是唯一的，它在整个LDAP中也是唯一的，而不一定是应用程序。
我们经常遇到这样的问题：在LDAP中，当用户名更改（由于结婚或离婚）时，我们会新建一个用户，而不是重命名。但在这种情况下，您可能不想在应用程序中创建新用户。使用您自己的users表，您可以简单地更改用户的ObjectGUID，用户应用程序内部id保持不变，但链接到LDAP中的全新用户。
对于身份验证、基本用户配置文件和用户状态，我肯定会这么做。在我看来，该用户的AD条目很可能比您为该用户提供的数据更为最新。它消除了您管理用户密码的需要。你不需要储存它们，也不需要提供更换它们的设施。当用户状态在Active Directory中被禁用时，您的用户将无法再使用您的应用程序。如果用户的姓名、电子邮件、电话号码在AD中发生了更改，那么您将始终拥有最新的数据，并且无需提供管理工具。
objectGUID是链接您的帐户的完美方式，因为它是唯一且不可变的。