Passwortänderungen werden nicht übernommen

Hallo und frohe Neues Jahr an das versammelte Forum!

Tatsächlich beginnt das (Arbeits-)Jahr unerfreulich. Auf unserem DM mit UCS 4.0 Errata 21 ist es möglich User Passwörter zu ändern und zu speichern. Allerdings sind diese geänderten PW nur sofort im ebenfalls eingesetzten Zarafa gültig. Dieses ist auf einem Slave Server installiert.

Die Passwörter für die Windows Domain bleiben davon allerdings unbeeindruckt.

Jetzt ist es passiert, dass ich 2 neue User angelegt habe, welche auch wie erwartet Zugriff auf Zarafa haben, allerdings können sich diese nicht an Rechner in der vorhandenen Domäne anmelden.

Wenn ich über UDM versuche die Passwörter der neuen User zu ändern, kommt die Meldung

E: Objekt nicht gefunden.

Was kann ich tun?

kleines Update: Ich kann von allen Usern die Passwörter in der Benutzerverwaltung ändern. Die Änderungen wirken sich auch sofort auf das Login in Zarafa aus. Allerdings ändern sich die PW nicht für die Anmeldung an den PCs meiner Kollegen. Auch 24h Wartezeit bringen hier keine Verbesserung. Kann ich das irgendwie synchronisieren?

Neue User lassen sich auch anlegen, können sich aber anschließend nicht am Rechner anmelden. Benutzername oder Passwort falsch…

Die gleichen Zugangsdaten für Webmail funktionieren dagegen einwandfrei. Ich bin ratlos…

Außerdem fällt mir noch auf, dass die Uhrzeit nicht ganz korrekt ist. Sind zwar nur 2 Minuten, aber man weiß ja nie. Die Zeit auf den Windows Clients wird auch nicht über den DC Master gesynct, sondern über den Slave auf dem auch Zarafa läuft.

-> ermittelt mit “w32tm /query /status”

könnte hier der Hund begraben sein?

also die Uhrzeit war nicht der Schuldige. Ich kann nach wie nicht mit neuen Usern in die Domäne oder auf Netzwerkfreigaben zugreifen. Geänderte Passwörter von bestehenden Usern werden gespeichert, gelten dann aber scheinbar nur für Webmail. Hat keiner eine Idee?

Samba4 wurde schon neu gestartet
S4 Connector ebenfalls
aus purer Verzweiflung sogar der ganze Server.

Hallo,

das klingt ein wenig als würde Änderungen nicht mehr in das AD übertragen, ggf. haben Sie rejects im S4-Connector die das Verhindern.
Einige Hinweise zu Analyse finden Sie z.B. in der SDB unter: sdb.univention.de/1235

Mit freundlichen Grüßen
Janis Meybohm

tatsächlich bekomme ich beim Aufruf von univention-s4connector-list-rejected als Ausgabe:

UCS rejected

S4 rejected

blablabla

last synced USN: 7428

Es scheinen also keine Einträge rejected zu werden. Ein Blick in /var/log/univention/connector-s4.log. brachte ebenfalls keine Auffälligkeiten.

Guten Morgen und guten Start in die Woche.

Die Probleme bestehen nach wie vor. Es sind immer noch eine Einträge im Rejected zu finden. Am Freitag haben wir das Errata Update 4.0E33 eingespielt, welches allerdings auch keine Besserung brachte. Es ist immer noch nicht möglich, geänderte oder neu angelegte PW für die Anmeldung an der Domäne zu verwenden. Die Passwörter werden allerdings nachweislich gespeichert und können für das Zarafa-Login (Client und Webclient) verwendet werden.

Die Zugangsdaten können auch nicht für Netzwerkfreigaben verwendet werden.

Update: Wenn ich mich mit einem “normalen” Domain-User am UMC anmelde, kommt der PW ändern Dialog. Gebe ich das gültige Passwort ein und ändere es zu einem Neuen, kommt der Fehler:

[code]Die Anfrage konnte nicht ausgeführt werden.

Fehlernachricht des Servers:

Passwort ändern fehlgeschlagen. Der Grund konnte nicht festgestellt werden. Für den Fall, dass es hilft, hier die originale Fehlernachricht: Current Kerberos password[/code]

Also scheint der Hund im Kerberos (kleines Wortspiel…) begraben zu sein.

Hallo,

es gibt ggf. mehrere Stellen an denen Passwörter für einen Benutzer in einer UCS AD Domäne gespeichert werden. In Ihrem Fall scheinen “LDAP-Binds” zu funktionieren, Anmeldungen gegen das AD bzw. Kerberos jedoch nicht. Ich hatte daher in erster Instanz auf Rejects getippt.

[quote=“Oids”]Außerdem fällt mir noch auf, dass die Uhrzeit nicht ganz korrekt ist. Sind zwar nur 2 Minuten, aber man weiß ja nie. Die Zeit auf den Windows Clients wird auch nicht über den DC Master gesynct, sondern über den Slave auf dem auch Zarafa läuft.

-> ermittelt mit “w32tm /query /status”

könnte hier der Hund begraben sein?[/quote]Absolut! Zwei Minuten Differenz sind für eine Kerberos-Authentifikation zu viel. Bevor Sie weiter suchen sollten Sie sicher stellen das alle Systeme Ihrer Domäne, inkl. der Clients, die gleiche Uhrzeit haben.

Um das weiter einzugrenzen, können Sie versuchen manuell ein Kerberos Ticket zu erhalten (kinit ), evtl. gibt es hier bessere Fehlermeldungen. Evtl. helfen auch die Troubleshooting Guides sdb.univention.de/1186 weiter um generelle Probleme (z.B. mit DNS) auszuschließen.

Mit freundlichen Grüßen
Janis Meybohm

Hallo,

wir hatten die Möglichkeit dass über den UCS Produktsupport zu untersuchen. Der Vollständigkeit halber im folgenden ein kurzer Abriss der Analyse:

Die Passwörter sowie neue Benutzer/Objekte wurden augenscheinlich nicht in das AD Synchronisiert. Ein “kinit benutzer” meldete: “kinit: krb5_get_init_creds: Client (benutzer@DOMAIN.QA) unknown”
In der /var/log/univention/connector-s4-status.log konnte der folgende Traceback beobachtet werden:[code] — connect failed, failure was: —

Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/main.py”, line 280, in main
connect()
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/main.py”, line 178, in connect
s4.initialize_ucs()
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 872, in initialize_ucs
univention.admin.modules.init(self.lo,position,self.modules[key])
File “/usr/lib/pymodules/python2.7/univention/admin/modules.py”, line 116, in init
univention.admin.ucr_overwrite_properties( module, lo )
File “/usr/lib/pymodules/python2.7/univention/admin/init.py”, line 53, in ucr_overwrite_properties
ucr_prefix = ucr_property_prefix % module.module
AttributeError: ‘NoneType’ object has no attribute ‘module’[/code]

Der Traceback lies darauf schließen, dass mind. ein UDM Modul nicht korrekt geladen werden konnte. Die Beschreibungsdateien für die UDM Module “container/msgpo” und “settings/mswmifilter” waren anscheinend noch für Python 2.6 (statt Python 2.7) ausgestellt: [code]$ head -n1 /usr/share/python-support/univentionUDMModule_container_msgpo.public /usr/share/python-support/univentionUDMModule_settings_mswmifilter.public
==> /usr/share/python-support/univentionUDMModule_container_msgpo.public <==
pyversions=2.6

==> /usr/share/python-support/univentionUDMModule_settings_mswmifilter.public <==
pyversions=2.6[/code]

Ein Resync des für die Pflege dieser Dateien zuständigen Listener-Moduls und ein anschließender S4-Connector neustart konnten die Situation auflösen:univention-directory-listener-ctrl resync udm_extension update-python-modules invoke-rc.d univention-s4-connector restart

Mit freundlichen Grüßen
Janis Meybohm

herzlichen Dank für die kompetente Hilfe! All Systems up and running

Hallo,
Ich hänge mich mal an diesen älteren Thread da mein Problem ähnlich losging:

Eine Passwort-Änderung an der UMC schlug bei uns mit selber Meldung fehl:

Die Anfrage konnte nicht ausgeführt werden. Fehlernachricht des Servers: Passwort ändern fehlgeschlagen. Der Grund konnte nicht festgestellt werden. Für den Fall, dass es hilft, hier die originale Fehlernachricht: Current Kerberos password

Eigentlich wird an diesem Server gar kein samba oder Kerberos benötigt, denn der server fungiert im Grunde als reiner Mailserver mit Open-Xchange.
Trotzdem scheint irgendein rest aus (fehlerhaften? alten? unvollständigen?) Samba Installationen auf dem Server gelegen zu haben, wodurch dieser Fehler auftritt, scheint mir. Ist diese Denke grundsätzlich logisch?
Also habe ich kurzum einfach über das Appcenter die komponente “Active Directory-kompatibler Domänencontroller” nachinstalliert. Stört ja grundsätzlich auch nicht weiter, wenn’s drauf ist.
Installation dauerte extrem lange, lief aber durch.
Das Grundproblem wurde tatsächlich damit gelöst: User können jetzt wieder Ihre Passwörter ändern.
Allerdings erhalte ich nun die fehlermeldung:

Benachrichtigung Nicht alle installierten Componenten wurden registriert. Bitte rufen Sie das Modul "Domänenbeitritt" auf um alle verbliebenen Komponenten zu registrieren.

98univention-samba4-dns und 97univention-s4-connector sind dort tatsächlich noch ausstehend.
der Versuch diese Joinskripte manuell zu starten, hängt scheinbar schon an der Authentifizierung.
Jedenfalls steht er sehr lange bei

Authentifizierung 0 %
Irgendwann geht es dann aber trotzdem weiter damit…

Weitere Fehlermeldungen sieht man dann in der connector-s4-status.log:

Sync 2 rejected changes from S4 to UCS Can't contact LDAP server during resync rejected, sync not possible.

in der /var/log/univention/connector-s4.log finden sich solche Meldungen zu Hauf:

17.03.2015 11:17:34,971 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
17.03.2015 11:17:34,972 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1439, in sync_to_ucs
    result = self.modify_in_ucs(property_type, object, module, position)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1216, in modify_in_ucs
    return ucs_object.modify() and self.__modify_custom_attributes(property_type, object, ucs_object, module, position)
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 363, in modify
    raise univention.admin.uexceptions.insufficientInformation
insufficientInformation

17.03.2015 11:17:35,49 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
17.03.2015 11:17:35,50 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1420, in sync_to_ucs
    result = self.add_in_ucs(property_type, object, module, position)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1199, in add_in_ucs
    self.__set_values(property_type,object,ucs_object, modtype='add')
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1130, in __set_values
    set_values(self.property[property_type].attributes[attr_key])
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1118, in set_values
    ucs_object[ucs_key] = []
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 234, in __setitem__
    raise univention.admin.uexceptions.valueRequired, _('The property %s is required') % self.descriptions[key].short_description
valueRequired: The property First name is required

Soweit ich das sehen kann, ist aber bei allen angelegten User einen Vornamen eingetragen…

Vielleicht hat ja einer eine Idee?

liebe Grüße

Sascha

Ich muss leider revidieren…
Nach der Installation von “Active Directory-kompatibler Domänencontroller” hatte das mit der Passwortänderung wirklich geklappt, aber nach einer Weile, vielleicht auch durch weitere Versuche die join-skripte zum Laufen zu bringen, ging es wieder nicht.
Dieses Mal mit der Fehlermeldung:

" Passwort ändern fehlgeschlagen. Der Grund konnte nicht festgestellt werden. Für den Fall, dass es hilft, hier die originale Fehlernachricht: gensec_update failed: NT_STATUS_LOGON_FAILURE " 

Nach kompletter Deinstallation der ja sowieso nicht benötigten Komponente “Active Directory-kompatibler Domänencontroller” ist nun der Fehler bei Passwortänderungen wieder der alte:

Passwort ändern fehlgeschlagen. Der Grund konnte nicht festgestellt werden. Für den Fall, dass es hilft, hier die originale Fehlernachricht: Current Kerberos password

Noch mal die grundsätzliche Frage: Benötige ich Kerberos überhaupt, wenn Samba bzw. AD nicht genutzt wird?
Und wenn nicht, wie kriege ich das dann sauber entfernt aus dem System?

Danke
Sascha

Hallo,

ich würde jetzt die Punkte aus dem vorherigen Post ignorieren. Wenn ich das richtig verstanden habe, haben Sie Samba und den S4-Connector jetzt wieder deinstalliert.

[quote=“tafkaz”]Noch mal die grundsätzliche Frage: Benötige ich Kerberos überhaupt, wenn Samba bzw. AD nicht genutzt wird?[/quote]Ja, darauf ist das System ausgelegt.

Passwort ändern fehlgeschlagen. Der Grund konnte nicht festgestellt werden. Für den Fall, dass es hilft, hier die originale Fehlernachricht: Current Kerberos passwordWenn ich das jetzt alles richtig verstanden habe ist dass die Fehlermeldung welche erscheint wenn der Benutzer selbst sich an der UMC anmeldet und sein Passwort ändert?
Ist das Passwort des Benutzers zu dem Zeitpunkt bereits abgelaufen (d.h. die Passwortänderung wird von der Login-Maske erzwungen)?
Welche UCS Version ist das?
Funktioniert die Passwortänderung als Benutzer auf der Kommandozeile mit “kpasswd” bzw. welche Meldung gibt es dort?

Mit freundlichen Grüßen
Janis Meybohm

Mastodon