Ldapsearch -x -ZZ -D <ldap_hostdn>

UCS - Univention Corporate Server
#1

Hallo,

und einen weiteren Fehler:

CRITICAL: auth failed: ldapsearch -x -ZZ -D <ldap_hostdn>

Nagios-Anmeldung nicht möglich
#2

Hallo,

Eine derartige Meldung ist im Zusammenhang mit abgelaufenen Rechnerzertifikaten bekannt. Eine Anleitung zur Überprüfung und
Aktualisierung finden Sie in folgendem SDB Artikel. http://sdb.univention.de/1000

darüberhinaus können Sie die Befehle

eval $(ucr shell)

und

ldapsearch -x -ZZ -D $ldap_hostdn -w $(cat /etc/machine.secret) -d1 -s base

als User root ausführen und hier anfügen.
Eventuelle datenkritische Bestandteile sollten Sie vor dem Anhängen entfernen.
Auf diesem Weg testen Sie die LDAP-Verbindung über einen simple Bind.

Anschließend können Sie z.B. mittels:

ldapsearch -xLLL -s base

die generelle LDAP-Verbindung verifizieren.

Mit freundlichen Grüßen,
Tim Petersen

#3

Danke für die erneute sehr schnelle Antwort. Leider ist mit den Zertifikaten alles in Ordnung.

Auch wenn ich einen LDAPSEARCH manuell auf dem Server durchführe ist alles okay:
ldapsearch -x -ZZ base liefert die Resultate aus unserem LDAP Baum.

Dies liefert univention-certificate dump -name NAME zurück:

" Validity
Not Before: Jun 29 08:15:03 2011 GMT
Not After : Jun 27 08:15:03 2016 GMT"

#4

Hallo,

um was für eine Systemrolle handelt es sich bei dem System?
Wenn ich das richtig sehe, kommt die Meldung aus dem Nagios Check “univention_joinstatus”. Würden Sie einmal den Befehl univention-check-join-status
auf dem System als root ausführen? Es könnte sein, dass Sie einige Join-Skripte ausführen müssen. Dies können Sie wie im folgenden SDB Artikel beschrieben tun:
http://sdb.univention.de/1176

Sollte dies nicht helfen, würde ich empfehlen das System neu zu joinen. Zur Absicherung könnten Sie zuvor noch folgende Schritte prüfen:

Besteht ein Unterschied wenn der DC Master explizit beim ldapsearch angegeben wird?

ohne DC Master:

eval $(ucr shell) ldapsearch -x -ZZ -D "$ldap_hostdn" -w $(cat /etc/machine.secret) -b "$ldap_base" -s base
mit DC Master:

eval $(ucr shell) ldapsearch -x -ZZ -h "$ldap_master" -D "$ldap_hostdn" -w $(cat /etc/machine.secret) -b "$ldap_base" -s base

Wenn hier unterschiedliche Ergebnisse entstehen, sollte das System neu gejoined werden.

Läuft der Univention Directory Listener und funktioniert die LDAP Replikation?

ps waux | grep /usr/sbin/univention-directory-listener

Wenn der Dienst nicht läuft sollte dieser gestartet und die Logdatei unter “/var/log/univention/listener.log” auf Fehlermeldungen geprüft werden.

/etc/init.d/univention-directory-listener start

Besteht auf dem System ein failed.ldif, eine Datei die bei Replikationsstörungen angelegt wird?

ls -lh /var/lib/univention-directory-replication/failed.ldif

Besteht eine solche Datei, kann diese nach den Hinweisen in der Technischen Dokumentation Kapitel 4.3 Einspielen nicht replizierter Daten (failed.ldif), behandelt werden.

Sollte die Replikation aus einem anderen Grund gestört sein, kann dies auch an den Daten der folgenden Dateien ersehen werden:
Auf dem DC Master:

tail -1 /var/lib/univention-ldap/notify/transaction

Auf dem aktuellen System:

cat /var/lib/univention-directory-listener/notifier_id

Sind die hier ausgegebenen Zahlen nicht identisch liegt vermutich eine Replikationsstörung vor. In diesem Fall kann ein erneutes Joinen des Systems häufig schaffen.

Mit freundlichen Grüßen
Tobias Scherer

#5

Hallo,

leider habe ich die Antwort überlesen bzw. vergessen nachzuschauen.
Jedenfalls nach dem Nochmaligen joinen des Systems funktioniert nun alles so wie es sein soll.

Nochmal vielen Dank für die schnelle u. zielführende Lösung,
Björn

Mastodon