Superuser unable to change password of user on LDAP server

Question

Just set up an LDAP server (sun) running Ubuntu 20.04 following the guide on Ubuntu Server Docs with TLS enabled with a bunch of users, groups, and automounts in database. Several clients (here: seca) running Ubuntu 20.04 use the server for authentication. So far everything seemed fine. User can authenticate and change their passwords with passwd. What is not working is changing the password of user as superuser.

mech@seca:~$ sudo passwd student9
[sudo] password for mech: 
passwd: Authentication token manipulation error
passwd: password unchanged

The entries in servers /var/log/syslog corresponding to the request are

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=

In /var/log/auth.log on seca I see

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

So somehow the authentication for student9 with pam_sss fails when using sudo.

If I do student9@seca:~$ passwd everything is fine and in the servers /var/log/syslog I see:

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 looks like:

[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

If important, /etc/nsswitch.conf looks like:

passwd:         files systemd sss
group:          files systemd sss
shadow:         files sss
gshadow:        files

What am I missing? How can I tell the server that it is fine for superusers to change passwords of users.

Answer 1

This is actually by design, as I found out. One of the sssd developers (Stephen Gallagher) commented on that some years ago at fedoraproject.com:

"This is intentional behavior. SSSD is designed not to allow root on the local system to change the passwords of the centrally-managed users. The reason for this is that we would have to store credentials for an LDAP administrator on the system somewhere in plaintext, which would mean that a rogue admin or attacker could easily gain access to an administrator account.

If you need to admin reset an LDAP user's password, it's much wiser to use ldappasswd instead, because this will force you to present admin credentials (of course, if you're storing the password in /etc/openldap/ldap.conf, you're vulnerable to the same local attack compromising your infrastructure)."