Ich verwende seit Jahren Kerberos/LDAP-Authentifizierung in einem kleinen Netzwerk. Kerberos wird in LDAP gespeichert, das wiederum auf einen anderen Standort repliziert wird. Die Rechner am zweiten Standort authentifizieren sich gegenüber der Replik, der alte Standort gegenüber dem Originalserver. Vor kurzem habe ich ein paar neue Benutzerkonten hinzugefügt.
Auf der ursprünglichen Site läuft alles reibungslos. Die neuen Benutzer können sich problemlos beim System anmelden.
Auf der zweiten Seite funktioniert die Nutzung des Replikats kinit userebenfalls problemlos. Allerdings login userwird behauptet, das Passwort sei abgelaufen und müsse umgehend geändert werden. Nach der Passwortänderung ist der Benutzer dann wieder tadellos eingeloggt.
Beim Überprüfen der Einstellungen auf dem Replikat-KDC kadmin.localsieht für mich alles gut aus:
kadmin.local: getprinc user
Principal: [email protected]
Expiration date: [never]
Last password change: Di Nov 22 21:06:35 CET 2022
Password expiration date: [never]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Di Nov 22 21:06:35 CET 2022 ([email protected])
Last successful authentication: Di Nov 22 21:19:27 CET 2022
Last failed authentication: So Nov 13 09:05:17 CET 2022
Failed password attempts: 0
Number of keys: 8
[ ... ]
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
Weder Passwörter noch Principals laufen also ab. Und kinitfunktioniert daher wie erwartet:
root@client:~# kinit user
Password for [email protected]:
root@client:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
22.11.2022 21:25:17 23.11.2022 07:25:17 krbtgt/[email protected]
renew until 23.11.2022 21:25:11
Behauptet jedoch login, das Passwort sei abgelaufen und müsse geändert werden:
root@ganesha:~# login user
Password:
Sie müssen Ihr Passwort sofort ändern (Passwortablauf).
Current Kerberos password:
Enter new Kerberos password:
Retype new Kerberos password:
Linux client 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Letzte Anmeldung: Dienstag, den 22. November 2022, 20:59:02 CET auf pts/5
user@client:~$
Nach diesem Login werden die Principals Last password changeund Last modifiedaktualisiert. Last successful authenticationändert sich nicht. Es ändert sich kinitauch nach erfolgreichem Login nicht. Aber es ändert sich nach erfolgreichem Login loginoder kinitauf den ursprünglichen Clients. Dies kann ein anderes Problem sein, aber es passiert genauso mit den alten Benutzern, die auf beiden Sites perfekt funktionieren. getprincIch kann keinen Unterschied zwischen den alten und den neuen Benutzern erkennen.
Für folgende PAM-Einstellungen sollen also die Vorgaben einer Debian-Installation logingelten :authaccount
auth optional pam_faildelay.so delay=3000000
auth requisite pam_nologin.so
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_group.so
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000
Ich habe einen neuen Bullseye-Client eingerichtet, der das ursprüngliche Kerberos und LDAP über VPN verwendet. Er zeigt das gleiche Verhalten. Ich habe einige PAM-Debuggings durchgeführt:
Jan 23 21:32:44 psyche login[2861]: pam_krb5(login:auth): user user authenticated as [email protected]
Jan 23 21:32:44 psyche login[2861]: pam_unix(login:account): expired password for user user (password aged)
Jan 23 21:32:53 psyche login[2861]: pam_krb5(login:chauthtok): user user changed Kerberos password
Jan 23 21:32:53 psyche login[2861]: pam_unix(login:session): session opened for user user(uid=10##) by admin(uid=0)
Für die alten Benutzer, die auf allen Systemen einwandfrei funktionieren, gibt es (login:account)natürlich keinen Eintrag und daher auch keine Passwortänderung. Es scheint also nichts mit der Replikation zu tun zu haben. Noch seltsamer ist, dass es Systeme gibt, auf denen logines für diese Benutzer einwandfrei funktioniert. Ich habe es überprüft /etc/pam.d/common-accountund es ist auf beiden Systemen identisch.
Ich freue mich über alle Ideen, was überprüft werden sollte.
Vielen Dank für Ihre Hilfe.
Antwort1
Der eigentliche Grund hatte nichts mit Kerberos zu tun. Die fehlerhaften Konten waren shadowMaxin LDAP festgelegt. Obwohl ich diese Einstellung überhaupt nicht kannte, werden Anmeldeinformationen als abgelaufen gemeldet, auch wenn shadowLastChangedas Pluszeichen shadowMaxnoch hinter dem aktuellen Datum liegt. Das Festlegen shadowMaxauf -1 oder das vollständige Löschen des Werts behebt das Problem.
Dies erklärt nicht ganz, warum das Setup auf der anderen Site den Wert anscheinend vollständig ignoriert, aber das ist eine andere Geschichte.