我已经设置了 SSSD 和 openldap 以成功查询 ldaps://ldap.google.com。我可以使用 ldapsearch 执行查询,并且可以使用 sssctl 和 getent 与目录交互。不幸的是,我所有以目录中的用户身份进行身份验证的尝试都遇到了 INVALID_CREDENTIALS(ldap 错误代码 49)。我使用多个客户端重现了此行为。我可以在 GSuite 管理控制台中的 LDAP 审计日志中观察到这些失败
LDAP bind with uid=brian,ou=Users,dc=XXX,dc=com failed with INVALID_CREDENTIALS
。
我的帐户确实启用了双重身份验证,但我使用应用程序专用密码来尝试验证自己的身份。我检查了四遍密码,甚至还创建了一个新密码来测试一下。Google ldap 服务器的行为就像无法验证身份一样。
关于如何针对 ldap.google.com 设置安全的外部身份验证,您有什么想法吗?
谢谢
答案1
这有点误导,因为“INVALID_CREDENTIALS”实际上是一个比它所暗示的更通用的错误。实际上,这通常是权限错误而不是无效凭据的结果。我在配置自己的本地 OpenLDAP 服务器时遇到了这个问题。问题很可能是您的用户首先没有绑定/验证 LDAPS 服务器的权限。
ldapsearch 适用于 getent 和 sss 守护进程的原因是,它们可能正在使用您的 LDAP 管理员凭据,或者如果您已正确配置它,则使用您的绑定代理用户帐户。(您永远不应该直接通过管理器进行绑定身份验证)。
该问题是由 LDAP 的 ACL(访问控制列表)引起的。您本质上想要做的是允许所有用户读取完整目录(密码字段等敏感对象除外)。
我不知道您当前的 ACL 是什么样的,但您想要做的是从以下 ACL 开始。
免责声明:默认情况下,这不是安全的
access to *
by self write
by users auth
by users read
实际上,这允许用户进行身份验证和读取所有对象,以及覆盖他们自己的用户对象,以便他们可以执行诸如更改密码等操作。
请记住,此配置仅轻微地比默认的允许匿名绑定更安全,任何称职的管理员都不应该允许匿名绑定。您应该通过设置特定属性的访问控制来非常严格地控制用户可以访问的内容。此 ACL 非常开放,因此您应该确保付出更多努力来进一步锁定它。
具有良好模式的正确配置的 LDAP 服务器已经具有一些内置的安全性来保护密码和其他敏感对象,但您应该始终验证这一点。
查阅文档并仔细阅读。LDAP 是一个巨大的怪物,不幸的是,很容易弄乱它。