User Passwords, can not change

UCS - Univention Corporate Server
#1

Hello,

Ich habe gerade einen moeglichen BUG bemerkt. Seit dem letzten Update heute zu 4.02, errate 258, vielleicht auch schon davor, koennen neue und existierende Benutzer die Passwoerter nicht mehr aendern, der Admin/root kann, jedoch auch mit diesen ist eine Anmeldung in der Domaene nicht mehr moeglich, alle Passwortaenderungen durch die Benuter un der Management Console schlagen fehl. Neu erstellte Benutzer erscheinen nicht in der AD Console von Windows.

Fehlermeldung:

Could not fulfill the request.

Server error message:

Changing password failed. The entered password does not match the current one.

Beim Versuch ueber ssh, kommt die folgende Fehlermeldung fuer ALLE Benutzer:

Current Kerberos password:
passwd: Authentication token manipulation error
passwd: password unchanged

MfG
Olaf Schutze

#2

Nachtrag:

WIr haben alle Skripe des Domaenen-Join mehrfach ausgefuehrt, es erscheint nach der Ausfuehrung, Fehler aufgetreten, jedoch werden diese nicht im Log registriert, in der tabellarischen Auflistung, alle als erfolgreich ausgefuehrt.

Nu haben jedoch ein weiteres, neues Phaenomen: Wenn wir jetzt einen Benutzer anlegen, dann haben wir KEIN Linux Profile mehr.
Wir haben einen Test USer , Login Name: ssss angelegt, dieser kan sich von WIndows her anmelden, funktioniert, die Windows Profile werden erstellt (wie gehabt).
Eine suche nach ssss ergibt:
Last login: Wed Jul 22 09:41:57 2015 from 192.168.1.103
root@:~# find / -name “ssss”
root@a:~# find / -type d -iname “ssss” -ls
root@******:~#

find: `ssss’: No such file or directory
root@apha:~#

Eine Aenderung des Passwortes ist moeglich:
root@******:~# passwd ssss
Current Kerberos password:
New password:
Retype new password:
passwd: password updated successfully
** dieses war zuvor bei allen Nutzern nicht moeglich

Das geaenderte Passwort wird auch bei der Windowsanmeldung erkannt.

Vielleicht weis, jemand, wie man loesen kann.
MfG
Olaf Schutze

#3

Zum Password-Thema habe ich keine gute Idee, außer mal die Systemuhrzeiten der Server zu vergleichen. Kerberos verlangt nahezu identische Systemuhrzeiten auf allen beteiligten Systemen. Weiterhin können Sie mal versuchen, sich manuell ein Kerberos-Ticket für verschiedene Accounts zu besorgen:

kinit administrator@DOMAIN.local kinit userbeidempasswortnichtklappt@DOMAIN.local

Das sollten Sie mal auf dem DC master und den beteiligten Servern ausprobieren und die Fehlermeldungen begutachten. Beachten Sie, DOMAIN.local durch Ihren tatsächlichen UCS-Domänennamen zu ersetzen. Zur Not können Sie die gültigen Namen der Principals auch aus dem LDAP holen: »univention-ldapsearch uid=administrator krb5PrincipalName«

Zum Thema Home-Directory: Ein Home-Directory wird erst dann auf Server X angelegt, wenn sich ein Benutzer auf dem Server X anmeldet (via SSH, oder auch über eine Windows-Freigabe). Dazu dient ein PAM-Modul. Dass sich ein User an Windows selber angemeldet hat, heißt nun aber noch nicht, dass er sich dadurch auch automatisch am dazugehörigen Linux-Server angemeldet und dadurch besagtes PAM-Modul getriggert hat.

Hinzu kommt, dass Linux-User standardmäßig auf jedem Server ihr eigenes Home-Verzeichnis bekommen – es sei denn, man stellt manuell ein, dass das Home via NFS verteilt wird (Sitchworte »Home share« und »Home share path« bei den Usereinstellungen). Es kann also gut sein, dass ein User auf Server A ein Home-Verzeichnis hat, auf Server X aber nicht.

#4

Hallo Herr Bunkus,

Ich habe mal die von Ihnen vorgeschlagenen Schritte ausgefuehrt. Bis auf den admin wir keiner der Benutzer gefunden und auch Fehler werden keine im log angezeigt.
Das ist im Moment nicht so schlimm, Benutzer anlegen geht wieder und alle koennen ihr Passwort wieder aendern.

Anderes, was mir dazu (vielleicht im Zusammenhang, heute erst) aufgefallen war: wir hatten einige Updates waehrend der vergangenen Monate und heute haben sich irgendwie Fehlerchen eingeschlichen, das konnten wir beheben und das heutige Update war fuer mehrere Updates.
Mal sehen, ob sich mit dem heutigen Update etwas in die Richtung verbessert hat.
Falls nicht, werden wir den Server noch einige Tage laufen lassen, ohne Aenderungen und bei naechster Gelegenheit neu installieren.

PS: Zeiteinstellung sind/waren nicht die Ursache, da unser Server als Domain Controler und Virtual Host arbeitet, die Benutzer also nur auf Terminal DIenste des Hostes zurueckgreifen. Die Zeiten der Guests sind mit der Zeit des Hosts identisch

MfG
Olaf Schutze

#5

Moin,

das klingt nicht so gut. Können Sie bitte mal prüfen, ob an den Userobjekten die Kerberos-Attribute gesetzt sind? Das geht wie folgt: »univention-ldapsearch uid=mbunkus|grep -i krb« (»mbunkus« natürlich durch einen existierenden User ersetzen, der nicht adminsitrator ist, für den es also nicht geht). Es sollten jede Menge Einträge erscheinen, bei mir z.B.

krb5PrincipalName: mbunkus@MBU-TEST.INTRANET krb5MaxLife: 86400 krb5Key:: MFKhKzApoAMCARKhIgQg13Q4D1q2rauiAiySS55MzVzAj9geThoJu+daep… krb5Key:: MEKhGzAZoAMCARGhEgQQnUPmwEd0/tR7634+YCdE… krb5Key:: MEqhIzAhoAMCARChGgQYol3yStYI5TRRv6Rn… krb5Key:: MEKhGzAZoAMCARehEgQQZrAjJnpC0uvEeCtUzaw8XaI… krb5Key:: MDqhEzARoAMCAQOhCgQIrW6tAkMsDZe… krb5Key:: MDqhEzARoAMC… krb5Key:: MDq… krb5MaxRenew: 604800 krb5KeyVersionNumber: 1 krb5KDCFlags: 126 objectClass: krb5Principal objectClass: krb5KDCEntry

Bitte pasten Sie mal das, was Sie erhalten. Die krb5Key-Einträge können Sie gerne unleserlich machen/abkürzen, um keine sensitiven Informationen öffentlich zu posten.

Ein erfolgreiches Testen sind dann wie folgt aus:

[code][0 root@master ~] kinit mbunkus@mbu-test.intranet
mbunkus@mbu-test.intranet’s Password:
[0 root@master ~] klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: mbunkus@MBU-TEST.INTRANET

Issued Expires Principal
Aug 10 08:51:24 2015 Aug 10 18:51:22 2015 krbtgt/mbu-test.intranet@MBU-TEST.INTRANET[/code]

Gut zu sehen ist, dass die Groß-/Kleinschreibung des Principals bei kinit nicht relevant ist.

Mastodon