只需按照以下指南设置运行 Ubuntu 20.04 的 LDAP 服务器（sun）即可Ubuntu 服务器文档启用 TLS，数据库中有一堆用户、组和自动挂载。运行 Ubuntu 20.04 的几个客户端（此处：seca）使用服务器进行身份验证。到目前为止一切似乎都很好。用户可以使用 进行身份验证和更改密码passwd。无法正常工作的是将用户密码更改为超级用户。
mech@seca:~$ sudo passwd student9
[sudo] password for mech:
passwd: Authentication token manipulation error
passwd: password unchanged
/var/log/syslog与请求对应的服务器中的条目是
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=39 SRCH base="dc=anything,dc=to" scope=2 deref=0 filter="(&(uid=mech)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))"
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=39 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host rhost loginDisabled loginExpirationTime loginAllowedTimeMap sshPublicKey userCertificate;binary mail
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=39 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=40 SRCH base="dc=anything,dc=to" scope=2 deref=0 filter="(&(memberUid=mech)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=40 SRCH attr=objectClass cn userPassword gidNumber modifyTimestamp modifyTimestamp
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=40 SEARCH RESULT tag=101 err=0 nentries=11 text=
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=41 SRCH base="dc=anything,dc=to" scope=2 deref=0 filter="(&(uid=student9)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))"
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=41 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host rhost loginDisabled loginExpirationTime loginAllowedTimeMap sshPublicKey userCertificate;binary mail
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=41 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=42 SRCH base="dc=anything,dc=to" scope=2 deref=0 filter="(&(memberUid=student9)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=42 SRCH attr=objectClass cn userPassword gidNumber modifyTimestamp modifyTimestamp
Jun 10 10:44:18 sun slapd[1035]: conn=1927 op=42 SEARCH RESULT tag=101 err=0 nentries=1 text=
在/var/log/auth.logseca 上我看到
Jun 10 10:46:47 seca sudo: mech : TTY=pts/2 ; PWD=/home/mech ; USER=root ; COMMAND=/usr/bin/passwd student9
Jun 10 10:46:47 seca sudo: pam_unix(sudo:session): session opened for user root by mech(uid=0)
Jun 10 10:46:47 seca passwd[78968]: pam_unix(passwd:chauthtok): user "student9" does not exist in /etc/passwd
Jun 10 10:46:47 seca passwd[78968]: pam_sss(passwd:chauthtok): Authentication failed for user student9: 4 (Systemfehler)
Jun 10 10:46:47 seca sudo: pam_unix(sudo:session): session closed for user root
因此，当使用 sudo 时，使用 pam_sss 对 student9 的身份验证会失败。
如果我这样做student9@seca:~$ passwd一切顺利，并且在服务器中/var/log/syslog我看到：
Jun 10 10:54:28 sun slapd[1035]: conn=1927 op=154 SRCH base="dc=anything,dc=to" scope=2 deref=0 filter="(&(uid=student9)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))"
Jun 10 10:54:28 sun slapd[1035]: conn=1927 op=154 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host rhost loginDisabled loginExpirationTime loginAllowedTimeMap sshPublicKey userCertificate;binary mail
Jun 10 10:54:28 sun slapd[1035]: conn=1927 op=154 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 10 10:54:28 sun slapd[1035]: conn=1927 op=155 SRCH base="dc=anything,dc=to" scope=2 deref=0 filter="(&(memberUid=student9)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Jun 10 10:54:28 sun slapd[1035]: conn=1927 op=155 SRCH attr=objectClass cn userPassword gidNumber modifyTimestamp modifyTimestamp
Jun 10 10:54:28 sun slapd[1035]: conn=1927 op=155 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 10 10:54:28 sun slapd[1035]: conn=1938 fd=20 ACCEPT from IP=xxx.xxx.xxx.xxx:46788 (IP=0.0.0.0:389)
Jun 10 10:54:28 sun slapd[1035]: conn=1938 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jun 10 10:54:28 sun slapd[1035]: conn=1938 op=0 STARTTLS
Jun 10 10:54:28 sun slapd[1035]: conn=1938 op=0 RESULT oid= err=0 text=
Jun 10 10:54:28 sun slapd[1035]: conn=1938 fd=20 TLS established tls_ssf=256 ssf=256
Jun 10 10:54:28 sun slapd[1035]: conn=1938 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Jun 10 10:54:28 sun slapd[1035]: conn=1938 op=1 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN
Jun 10 10:54:28 sun slapd[1035]: conn=1938 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 10 10:54:28 sun slapd[1035]: conn=1938 op=2 BIND dn="uid=student9,ou=People,dc=anything,dc=to" method=128
Jun 10 10:54:28 sun slapd[1035]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
Jun 10 10:54:28 sun slapd[1035]: conn=1938 op=2 BIND dn="uid=student9,ou=People,dc=anything,dc=to" mech=SIMPLE ssf=0
Jun 10 10:54:28 sun slapd[1035]: conn=1938 op=2 RESULT tag=97 err=0 text=
Jun 10 10:54:28 sun slapd[1035]: conn=1938 op=3 UNBIND
Jun 10 10:54:28 sun slapd[1035]: conn=1938 fd=20 closed
/etc/sssd/sssd.conf好像：
[sssd]
config_file_version = 2
domains = anything.to
[domain/anything.to]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://sun.anything.to
cache_credentials = True
enumerate = true
ldap_search_base = dc=anything,dc=to
如果重要的话，/etc/nsswitch.conf看起来像：
passwd: files systemd sss
group: files systemd sss
shadow: files sss
gshadow: files
我遗漏了什么？我如何告诉服务器超级用户可以更改用户密码。
答案1
我发现，这实际上是设计使然。sssd 开发人员之一 (Stephen Gallagher) 几年前在fedoraproject.com：
“这是故意为之。SSSD 的设计不允许本地系统上的 root 更改集中管理用户的密码。这样做的原因是我们必须将 LDAP 管理员的凭据以纯文本形式存储在系统上的某个位置，这意味着恶意管理员或攻击者可以轻松访问管理员帐户。
如果您需要以管理员身份重置 LDAP 用户的密码，那么使用 ldappasswd 是更明智的选择，因为这将强制您提供管理员凭据（当然，如果您将密码存储在 /etc/openldap/ldap.conf 中，您就容易受到同样的本地攻击，从而危害您的基础设施）。”