Просто настройте сервер LDAP (солнце) под управлением Ubuntu 20.04, следуя руководству по Документация по серверу Ubuntu с включенным TLS с набором пользователей, групп и автоматических подключений в базе данных. Несколько клиентов (здесь: seca) под управлением Ubuntu 20.04 используют сервер для аутентификации. Пока вроде все нормально. Пользователь может аутентифицироваться и менять свои пароли с помощью 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.log на seca я вижу
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
Итак, каким-то образом аутентификация для student9 с помощью pam_sss не выполняется при использовании sudo.
Если я сделаю 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
Что мне не хватает? Как я могу сказать серверу, что суперпользователи могут изменять пароли пользователей.
Как я выяснил, это сделано специально. Один из разработчиков sssd (Стивен Галлахер) прокомментировал это несколько лет назад на fedoraproject.com:
"Это намеренное поведение. SSSD не позволяет пользователю root в локальной системе изменять пароли централизованно управляемых пользователей. Причина этого в том, что нам придется хранить учетные данные администратора LDAP в системе где-то в виде открытого текста. , что означает, что злоумышленник или злоумышленник может легко получить доступ к учетной записи администратора.
Если вам нужно сбросить пароль пользователя LDAP с помощью администратора, гораздо разумнее использовать вместо него ldappasswd, потому что это заставит вас предоставить учетные данные администратора (конечно, если вы храните пароль в /etc/openldap/ldap.conf, вы уязвимы для той же локальной атаки, которая ставит под угрозу вашу инфраструктуру) ".