我管理一个 LAN，其中包含一些用户列表，这些用户通过 NIS/YP（基于 CentOS/Fedora 的客户端和服务器）进行身份验证来访问他们的 NFS 共享主页。
我正处于从 NIS/YP（Red Hat 等正在缓慢但不可逆转地逐步淘汰）迁移到看似最不难设置的身份验证部分替代方案、SSSD（用于客户端）和 LDAP（用于服务器上的用户数据库）的过程中。
经过多次尝试，我找到了一个看似可以正常工作的设置，并开始考虑加强安全性，但有些事情我一直没有解决。
在大多数情况下，用于查询 LDAP 数据库以验证登录用户身份的标准 ACL 都是这样的：
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
并且一切正常。
因为我不想让用户偷看彼此的记录，所以我将最后一个修改为：
olcAccess: {2}to * by * none
然后我发现“olcRequires：authc”应该禁用对 LDAP 的匿名绑定（这似乎在安全性上有所改进，不是吗？）并启用它，一切似乎都继续正常工作。
然后再次查看第一个 ACL，您会看到针对用户密码的匿名身份验证仍然是授权的（如果前一个规则有效，这似乎是多余的）并且我尝试将其删除：
olcAccess: {0}to attrs=userPassword by self =wx by * none
一切都不再起作用了。
继续阅读，我发现问题在于 SSSD 必须能够最少地查询数据库，以便检索足够的结构来将像“foo”这样的用户名转换为 LDAP 可分辨名称“uid=foo,ou=People,dc=example,dc=com”，然后 LDAP 才能处理。
我知道 SSSD 能够使用“代理用户”来做到这一点，因此我在数据库中添加了这样一个用户，并配置 SSSD 来使用它：
ldap_default_bind_dn = cn=autobind,dc=example,dc=com
ldap_default_authtok = verysecretpassword
并且，我想我添加了必要的 ACL 让它完成它的工作：
olcAccess: {0}to attrs=userPassword by self =wx by dn="cn=autobind,dc=example,dc=com" =x by * none
olcAccess: {1}to attrs=shadowLastChange by self write by dn="cn=autobind,dc=example,dc=com" read by * none
olcAccess: {2}to * by dn="cn=autobind,dc=example,dc=com" read by * none
不用说，它不起作用——不仅无法登录，这很可能是 SSSD 配置错误，而且数据库本身变得无法查询，甚至通过 也返回错误 49（无效凭据）ldapsearch。
重新添加后by anonymous auth它再次工作；显然，有些东西我没有正确理解。
我知道这似乎不是什么大问题，除了我的 ACL 中出现“匿名”让我非常恼火，但似乎无法访问任何重要的东西。
因此，我的问题是：这是否是一种更安全的配置，即在我的 LDAP 用户数据库的 ACL 中完全删除“匿名”访问权限，最终将其必要功能替换为特定于 SSSD 使用的代理用户的功能？如果不是，你会做些什么来进一步加强安全性？
答案1
在我的 LDAP 用户数据库的 ACL 中完全删除“匿名”访问权限，最终用代理的功能取代其必要功能
在这种情况下，不需要。您能禁止所有匿名连接的读取/搜索操作，并在执行用户搜索之前让 SSSD 绑定到机器帐户（我为此使用 Kerberos，SSSD 自动选择 /etc/krb5.keytab），但匿名客户端仍然需要auth最低权限。
更具体地说，by anonymous auth在 OpenLDAP ACL 中初始“简单”绑定必须起作用，因为执行绑定的连接在绑定成功之前仍然处于匿名状态。
因此，如果你定义一个“代理”账户，你只是稍微转移了问题，但并没有真正改变它——匿名连接仍然需要“auth”权限才能绑定为代理账户或者换句话说，如果您要求客户端已经通过身份验证才能进行身份验证，那么它首先如何作为代理帐户进行身份验证？
此外，我通常不会使用olcRequires: authc全局使用，因为它会阻止读取 rootDSE 条目（空 DN），而这正是客户端发现什么身份验证机制服务器上是否可用，以及 StartTLS 是否可用（如果未使用端口 636）。通过阻止匿名连接读取空 DN 上的属性，您可能会破坏 SASL 身份验证（例如 Kerberos/GSSAPI），并将自己限制为仅基于密码的“简单绑定”。