Keine Anmeldung an UMC möglich

nach installieren und updaten von OXAE gibt es keinen Zugriff auf die UMC. Der Fehler lautet jedesmal: Authentication failed: no response yet :frowning: . Leider habe ich keine Ahnung wieso. Der Fehler ist auch nach Neuinstallation beliebig reproduzierbar.

Hallo,

über einen ähnlichen Fall sind wir bereits informiert, dabei traten die Probleme nach einer IP Änderung auf. Können Sie uns mitteilen was oder ob etwas geändert wurde, woraufhin anschließend die Anmeldung am Univention Management Console fehlschlägt? Zusätzlich werde ich dieses Problem an OX AE weiterleiten, so dass im Zuge der Weiterentwicklung von OX AE eine Lösung implementiert werden kann.

Falls es sich hierbei doch um ein ähnliches Problem handelt, könnte der folgende Workaround evtl. weiterhelfen:

Die krb5 Einträge aus den Univention Configuration Registry-Variablen auth/admin/methods und auth/user/methods entfernen. Die Univention Configuration Registry-Variablen sollten anschließend wie folgt aussehen:

auth/admin/methods: ldap unix auth/user/methods: ldap unix

Zusätzlich muss die PAM Konfiguration für die Univention Management Console im Template /etc/univention/templates/files/etc/pam.d/univention-management-console angepasst werden. In dieser Datei müssen Sie die auth und account Zeilen entfernen die krb5 enthalten und mit ucr commit /etc/pam.d/univention-management-console die Konfigurationsdatei neu schreiben. Bitte beachten Sie das diese Änderungen bei einem eventuellen OX AE Update wieder überschrieben werden. Die entsprechende Konfigurationsdatei /etc/pam.d/univention-management-console sollte anschließend wie folgt aussehen:

# Warning: This file is auto-generated and might be overwritten by heim
#          univention-baseconfig.
#          Please edit the following file instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
#          univention-baseconfig ÃŒberschrieben werden.
#          Bitte bearbeiten Sie an Stelle dessen die folgende Datei:
#
#       /etc/univention/templates/files/etc/pam.d/univention-management-console
#

auth     sufficient                         pam_unix.so
auth     [success=done new_authtok_reqd=ok          user_unknown=die          service_err=die authinfo_unavail=die          default=die]
                         pam_ldap.so use_first_pass

# cache password (on successful authentification)
auth     [success=done new_authtok_reqd=ok          ignore=ignore default=bad]         pam_passwdcache.so try_first_pass insert max_user
=3
# remove password from cache (on failed authentification)
auth     required                           pam_passwdcache.so try_first_pass delete max_user=3
# authenticate against cache (if a service fails)
auth     required                         pam_passwdcache.so try_first_pass

account  sufficient             pam_unix.so
account  required               pam_ldap.so

session    required   pam_unix.so

Anschließend sollte die Anmeldung am Univention Management Console möglich sein.

Mit freundlichen Grüßen
Murat Odabas

Danke für die Hilfe, aber der OX Support hat folgende Lösung vorgeschlagen:

‘/usr/share/univention-management-console/frontend/modconsole.py’ in folgendem
Abschnitt die ‘10’ durch bspw. ‘30’ (Sekunden) ersetzen.

req = umcp.Request( ‘AUTH’ )
req.body[ ‘username’ ] = authUsername
req.body[ ‘password’ ] = authPassword

id = client.request_send( req )
response = client.response_wait( id, timeout = 10 )

Das hat sofort geholfen. Wir werden erstmal nicht weiter ändern.
Gruß P. Steinmetz u. Th. Krell

Hallo,

bei der Anmeldung am Univention Management Console wird der PAM Stack durchgearbeitet, so dass zuerst die Passwd und anschließend Kerberos und LDAP abgefragt werden. Beim Kerberos-Dienst wird die Abfrage per DNS gestartet. Während dieser Abfrage können die erwarteten Antworten nicht zurückgeliefert werden, da die FQDN zu einer falschen IP aufgelöst wird und Kerberos den KDC nicht erreichen kann. Aus diesem Grund schlägt die Anmeldung am Univention Management Console fehl.

Um dieses Problem dauerhaft zu beheben, d.h. damit bei einem evtl. OXAE Update die Änderungen nicht überschrieben werden, kann der folgende Workaround angewendet werden:

Die krb5 Einträge aus den Univention Configuration Registry-Variablen auth/admin/methods und auth/user/methods entfernen. Die Univention Configuration Registry-Variablen sollten anschließend wie folgt aussehen:

auth/admin/methods: ldap unix auth/user/methods: ldap unix

Zusätzlich muss die PAM Konfiguration für die Univention Management Console in der Datei /etc/pam.d/univention-management-console angepasst werden. In dieser Datei müssen Sie die auth und account Zeilen entfernen die krb5 enthalten. Die entsprechende Konfigurationsdatei /etc/pam.d/univention-management-console sollte anschließend wie folgt aussehen:

# Warning: This file is auto-generated and might be overwritten by heim
#          univention-baseconfig.
#          Please edit the following file instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
#          univention-baseconfig ÃŒberschrieben werden.
#          Bitte bearbeiten Sie an Stelle dessen die folgende Datei:
#
#       /etc/univention/templates/files/etc/pam.d/univention-management-console
#

auth     sufficient                         pam_unix.so
auth     [success=done new_authtok_reqd=ok          user_unknown=die          service_err=die authinfo_unavail=die          default=die]
                         pam_ldap.so use_first_pass

# cache password (on successful authentification)
auth     [success=done new_authtok_reqd=ok          ignore=ignore default=bad]         pam_passwdcache.so try_first_pass insert max_user
=3
# remove password from cache (on failed authentification)
auth     required                           pam_passwdcache.so try_first_pass delete max_user=3
# authenticate against cache (if a service fails)
auth     required                         pam_passwdcache.so try_first_pass

account  sufficient             pam_unix.so
account  required               pam_ldap.so

session    required   pam_unix.so

Wir werden das Verhalten dahingehend ändern, dass diese Einstellung zukünftig auch per Univention Configuration Registry durchgeführt werden kann. Zusätzlich werden wir das Verhalten mit Open-Xchange besprechen.

Mit freundlichen Grüßen
Murat Odabas

Hallo,

ich habe gerade das gleiche Problem und sowohl die Einstellungen zum krb5 als auch die zum Timeout ausprobiert.

Auch noch dem Neustart des UMC Server ist das leider noch immer ohne Erfolg.

Gibt es weitere Ansatzpunkte, die das Verhalten erklären könnten?

Vielen Dank
M. Willecke

Hallo,

gibt es während der Anmeldungen Fehlermeldungen in den UMC Logdateien (evtl. das Debug-Level auf 4 erhöhen) und/oder in der auth.log?

Mit freundlichen Grüßen
Janis Meybohm

Hallo,

ich habe es … das Problem lag am Systemdatum.
Der Rechner lief aus irgendeinem Grund mit Datum “Mi 25. Nov 22:12:23 CET 1987”.

Nach einstellen des richtigen Datums klappt auch die Anmeldung am UCS.

Vielen Dank
M. Willecke

Hallo,

wir konnten dieses Problem Nachvollziehen. Der UMC-Server erkennt derzeit nicht wenn ein SSL-Zertifikat ungültig ist (wie in Ihrem Fall) und bietet trotzdem die Möglichkeit einer verschlüsselten Verbindung an. Diese schlägt dann allerdings fehl und die Fehlermeldung wird angezeigt.
Wir haben dazu einen Eintrag in unserem Bug-Tracking System angelegt und werden das Problem in einer der kommenden UCS Versionen beheben.

Mit freundlichen Grüßen
Janis Meybohm

[b]

Wo finde ich denn bitte genau die “Registry-Variablen”, muss ich über das Webfrontend, in die Console … um die Einträge:

Code:
auth/admin/methods
und
Code:
auth/user/methods
entfernen. Die Univention Configuration Registry-Variablen sollten anschließend wie folgt aussehen:

zu bearbeiten ?

MfG Marc

Hallo,

Univention Configuration Registry ist das Werkzeug um die lokale Systemkonfiguration zu verwalten. Die Univention Configuration Registry-Variablen können sowohl über die Kommandozeile als auch über die Webbasierte Univention Management Console verwaltet werden.

Die Univention Management Console können Sie über den entsprechenden Link auf der Overview Seite des OXAE Servers erreichen. Nach der Anmeldung als Administrator ist das Modul mit dem Namen “Univention Configuration Registry” aufzurufen. Anschließend können Sie nach den entsprechenden Univention Configuration Registry-Variablen suchen und ändern bzw. neu setzen.

Über die Kommandozeile können Sie das Kommandozeilen Werkzeug “univention-configuration-registry” - als Benutzer root - verwenden. Bspw. zeigt bzw. sucht der folgende Befehl die entsprechende Variable mit dem dazugehörigen Wert:

univention-config-registry search auth/admin/methods

Eine Änderung wird folgendermaßen realisiert:

univention-config-registry set auth/admin/methods="ldap unix"

Weitere Informationen zur Verwendung von “Univention Configuration Registry” finden Sie auch im OXAE Handbuch, Kapitel 7 “Univention Configuration Registry”.

Mit freundlichen Grüßen
Murat Odabas

Danke, dass hat funktioniert, aber erst als ich univention-updater net (von 2.2.-6 auf 2.2-9) durchgeführt habe.

Edit (Meybohm):
Da es sich vermutlich um ein anderes Problem handelt, habe ich habe die folgenden Fragen in ein neues Thema “Drei Probleme mit OX” übernommen.

Mir ist aber ein neues Problem aufgefallen, bzw. 3 neue Probleme. Ich bin aber der Annahme, dass diese alle an einem zentralen Problem geknüpft sind ^^

  1. Bei der Anmeldung als User am OXServer:

[quote]Fehlermeldung: Verbindung abgelehnt oder Zeitüberschreitung beim Versuch, eine Verbindung zum entfernten Server localhost für Benutzer marc@test.net herzustellen (MSG-1016,431273310-255)
[/quote]

  1. Wenn ich über das Webfrontend auf das E-Mail-Symbol klicke, poppt folgende Fehlermeldung auf:

[quote]Das E-Mail-Modul ist nicht verfügbar
Es konnte keine Verbindung zum E-Mail-Server aufgebaut werden. Mögliche Gründe: der Mailserver ist (vorübergehend) ausgefallen oder es traten Netzwerkprobleme auf. Um weitere Fehler zu vermeiden wurde das Modul deaktiviert. Bitte wenden Sie sich an Ihren Administrator.
[/quote]

  1. Ich muss ein E-Mail Konto anlegen welches mit POP3 die Mails herunterholt, da gmx den imap Dienst nicht kostenlos zur Verfügung stellt.

Wenn ich nun meine Verbindung prüfen möchte, poppt wieder eine Fehlermeldung auf:

[quote]Fehler
Die Verbindung ist fehlgeschlagen. Bitte überprüfen Sie Ihre Einstellungen: Fehlermeldung: Verbindung abgelehnt oder Zeitüberschreitung beim Versuch, eine Verbindung zum entfernten Server localhost für Benutzer marc@test.net herzustellen (MSG-1016, 431273310-221)[/quote]

MfG Marc

Hallo,

ich habe dieses Problem erst vor einer Woche festgestellt - aber ich bin mir ziemlich sicher, dass es seit der Erneuerung der Zertifikate für den OX (im November 2010) aufgetreten ist. Im Dezember wäre sie nämlich abgelaufen und dann habe ich die Zertifikate entsprechend einer Anweisung vom OX-Supportteam neu generiert. Davor ging die Anmeldung an der UMC garantiert und danach hatte ich sie nicht mehr genutzt - das System lief ja. Nun wollte ich mal wieder nach Updates schauen und dabei dann das Problem festgestellt.

Ich habe die Workarounds, wie in den oberen Beiträgen beschrieben, abgearbeitet, aber leider gelingt mir noch immer keine Anmeldung - weder über https noch über http, was ja eigentlich nicht passieren dürfte, wenn es an den SSL-Zertifikaten liegt.
Ich habe die Systemzeit kontrolliert, den Timeout-Wert auf 30 Sek. erhöht, die Kerberos-Auth. deaktiviert, indem ich das Template angepasst und die Konfiguration neu erzeugt habe und natürlich auch den Server neu gestartet - trotzdem meldet mir der Server immer:
“Authentisierungsfehler: Der UMC-Server hat auf die Authentisierungsanfrage nicht geantwortet”

Kann es sein, dass ein Auth.-dienst überhaupt nicht funktioniert?
Kann man sich nicht auf dem Server direkt über eine Konsole an der UMC anmelden?

Bin für jede Hilfe dankbar.

Peter

In Ergänzung meines obigen Beitrags habe ich heute die Hinweise aus dem Artikel ID #1173 abgearbeitet und folgendes Problem herausgefunden:
Der Befehl
“ldapsearch -x -ZZZ -s base -h $hostname.$domainname”
listet mir folgenden Fehler auf:
ldap_start_tls: Connect error (-11)
additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Also funktioniert die LDAP-Authentisierung nicht.
Ein “/etc/init.d/slap.d restart” zeigt aber einen problemlosen Start an.
Ein “univention-certificate list” zeigt mir auch kein Zertifikat für die univention-management-console.$hostname.$domainname an. Müsste es dafür eigentlich nicht eins geben?

An der Stelle komme ich nun nicht weiter.

Peter

Hallo,

bitte auch den Rest des Artikels prüfen - die Meldung deutet darauf hin dass die SSL-Zertifikate abgelaufen sind.

Mit freundlichen Grüßen
Janis Meybohm

Danke, Janis, für die Reaktion.

Die Zertifikate wurden am 23. November 2010 neu erstellt und sind bzw. waren gültig. Wäre das nicht so, könnte man sich meiner Meinung nach auch nicht am UDM anmelden - das aber ist möglich.
Das hatte ich vor drei Tagen noch mal überprüft.

Allerdings zeigt mir heute ein:
univention-certificate dump -name $hostname.$domainname | egrep -i -A 2 ‘validity’ :
Error opening Certificate /etc/univention/ssl/./cert.pem
21816:error:02001002:system library:fopen:No such file or directory:bss_file.c:352:fopen(’/etc/univention/ssl/./cert.pem’,‘r’)
21816:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:354:
unable to load certificate

und das bedeutet wohl, dass die pem-Datei(n) nicht geladen werden kann/können. Die beiden Zertifikatsdateien stehen unter /etc/univention/ssl/$hostname.$domainname bzw unter
/etc/univention/ssl/univention-directory-manager.$domainname

Definitiv wurden aber die Zertifikate vor drei Tagen noch durch das cerficate dump als gültig ausgewiesen und zwar bis Dezember 2012. (Ein Blick in die Zertifikate bestätigt das auch) Ich vermute hier einfach, dass die pem-Dateien nicht “gefunden” werden.

Auch verweist /etc/univention/ssl/ucsCA/index.txt auf die richtigen neuen pem-Dateien.

Komisch ist doch auch, dass nach wie vor eine Anmeldung am UDM möglich ist, genauso wie die normale OX-Nutzung durch die User.

Was nun?

Hallo,

hier wurde vermutlich einfach nur das “eval $(ucr shell)” vor dem “univention-certificate”-Aufruf vergessen. $hostname und $domainname sind damit nicht gesetzt weshalb das Zertifikat nicht geöffnet werden kann.

Bitte prüfen Sie auch ob evtl. das Root-Zerfitikat abgelaufen ist:

openssl x509 -in /etc/univention/ssl/ucsCA/CAcert.pem -noout -text | egrep -i -A 2 'validity'

Mit freundlichen Grüßen
Janis Meybohm

Vielen Dank, Janis!

[quote=“Meybohm”]Hallo, …

hier wurde vermutlich einfach nur das “eval $(ucr shell)” vor dem “univention-certificate”-Aufruf vergessen. $hostname und $domainname sind damit nicht gesetzt weshalb das Zertifikat nicht geöffnet werden kann.

Bitte prüfen Sie auch ob evtl. das Root-Zerfitikat abgelaufen ist:

openssl x509 -in /etc/univention/ssl/ucsCA/CAcert.pem -noout -text | egrep -i -A 2 'validity'

Mit freundlichen Grüßen
Janis Meybohm[/quote]

Ja genau, ich Dummerchen hatte tatsächlich vergessen, die Variablen einzulesen.
Also die Zertifikate sind gültig bis 22.11.2012, aber die Überprüfung des root-Zertifikats zeigt mir an, dass die Gültigkeit abgelaufen ist. Und damit ist dann klar, warum wohl die Anmeldung an der UMC nicht funktioniert.

Nebenbei gesagt, ist es mir aber rätselhaft, wieso das root-Zertifikat jetzt nur noch bis 11/2010 ungültig sein soll. Denn ich bin mir sicher, dass ich es damals überprüft hatte und da war es bis 2013 gültig. Und auch die Aussage vom OX-Support lautete damals:

[quote]Das Zertifikat vom cyrus-Image ist getrennt zu betrachten, hiervon ist die
Default-Gültigkeit 5 Jahre, dies können Sie wie folgt überprüfen:

openssl x509 -in /var/lib/cyrus/cert.pem -text -noout
[/quote]

Benötige ich nur noch mal einen Tipp, zum Neuerstellen des ssl-root-Zertifikats.
(Da es hier der OX als ApplianceEdition ist, weiß ich nicht, ob der allgemeine Artikel für das Erneuern der SSL-Zertifikate des UCS hier analog anwendbar ist. Nicht, dass ich mehr Schaden anrichte.)

Vielen Dank!

Wollte nicht warten und habe es einfach entsprechend des Artikels geändert - und siehe da - es funktioniert wieder.

Herzlichen Dank an Janis!

Mastodon