SSSD配置中限制root切换至被ldap_access_filter拦截的LDAP用户的实现方法咨询

嘿，这个问题其实挺常见的——root绕开SSSD的访问限制确实是个容易踩的坑，我来给你拆解下原因和解决办法：

为什么root能su到被拦截的用户？ #

首先得明确：你设置的ldap_access_filter是作用在PAM层面的，也就是管用户通过常规登录（比如ssh、本地登录）能不能进来，但root用户默认会绕过PAM的access控制，而且SSSD的NSS模块（负责id命令、用户信息查询）默认不会用这个过滤规则，所以root依然能查到这些用户信息并切换过去。

可行的解决方案 #

1. 给NSS模块添加用户过滤规则（最直接有效） #

你需要在[domain/domain.edu]段里添加ldap_user_filter，把它设置成和你的ldap_access_filter一致的规则，这样NSS只会返回符合条件的用户，不管是id命令还是su操作，都会找不到那些被拦截的用户：

[domain/domain.edu]
# 其他配置保持不变
ldap_user_filter = (&(objectClass=posixAccount)(groupMembership=cn=devtest,ou=groups,ou=people,o=cuid))

这个规则会让SSSD只从LDAP拉取属于devtest组的用户，root就算想su到其他用户，系统会直接提示“用户不存在”，id命令也查不到信息。

2. 修改搜索基的局限性 #

你提到的修改ldap_search_base、ldap_user_search_base这类方法，其实不太推荐：

• 除非你的LDAP里把允许登录的用户单独放在一个OU里，否则没法精准过滤；
• 如果用户属于多个组，这种硬编码的搜索基会非常不灵活，后续维护成本很高；
• 本质上还是不如用filter规则精准，因为filter可以直接基于组 membership 做判断。

3. 额外的优化和验证步骤 #

• 如果你开了enumerate = true（也就是预加载所有用户到缓存），修改filter后需要清理旧缓存：

  sss_cache -u  # 清理用户缓存
  systemctl restart sssd
  

• 可以先用ldapsearch验证你的filter是否正确，确保只返回目标用户：

  ldapsearch -x -H ldaps://sub.domain.edu:636 -b ou=people,o=cuid "(&(objectClass=posixAccount)(groupMembership=cn=devtest,ou=groups,ou=people,o=cuid))"
  

• 保留ldap_access_filter作为第二道防线，防止万一NSS过滤出现疏漏，依然能在PAM层面拦截非法登录。

总结 #

核心思路就是同时在NSS和PAM层面做过滤：用ldap_user_filter限制NSS可见的用户，用ldap_access_filter管PAM登录，这样不管是普通用户登录还是root尝试切换，都能被拦截。

备注：内容来源于stack exchange，提问作者user23497333