LDAP Verbindung

german
ldap

#1

Hallo,
ich teste den UCS in einer VirtualBox VM. In einer zweiten VM läuft ein Debian mit einer Redmine Installation, die eigentlich die LDAP Authentifizierung von UCS nutzen soll. Dazu habe ich einen eigenen Nutzer “redmine” mit einfacher Authentifizierung angelegt. Das Ganze klappt aber nicht.
Wenn ich auf dem UCS in der Konsole folgendes ausführe, funktioniert das nach Eingabe des redmine-Passworts wunderbar:

ldapsearch -x -D uid=redmine,cn=users,dc=<base DN> -W uid=Administrator

Wenn ich das aber in der Debian-VM ausführe, bekomme ich schon ohne Passwort-Eingabe “ldap_bind: Invalid credentials (49)”:

ldapsearch -H ldap://<ip>/ -x -D uid=redmine,cn=users,dc=<base DN> -W uid=Administrator

Beide VMs können sich gegenseitig anpingen. Ich habe noch keine Erfahrung mit LDAP und habe mich jetzt schon durch einige Wikis gegooglet, bisher ohne Erfolg. Wie komme ich hier weiter?


#2

Hallo Heimchen,

Schau mal auf dem UCS, ob beide Ports 389 und 7389 durch die Firewall durchgelassen werden.

iptables -L -nP

Viele Grüße
Ulf


#3
  • Das / am Ende der LDAP-URI gehört da nicht hin - damit wird “/” als LDAP-Basis (und anderes) gesetzt! Siehe RFC 2255
  • stattdessen ein :7389 für den Port anhängen - OpenLDAP läuft unter UCS auf den 7000er Ports, damit auf den Standardports Samba für Windows laufen kann.
  • und. noch ein -b $baseDN ergänzen, um die LDAP-Basis zu setzen. Ansosonten findet die Suche nicht den richtigen Einstiegspunkt.
  • ggf. ldaps:// für Verschlüsselung verwenden - ggf. müssen die Zertifikate dann auch auf das Debian-System kopiert werden. Der Port ist dann :7636.

Siehe auf dem UCS-System die Datei /etc/ldap/ldap.conf.
Wir haben auch eine Dokumentation dazu in unserem Handbuch.


#4

Seltsam ist, dass mir Redmine mit Port 7636 und LDAPS den Verbindungstest als erfolgreich anzeigt, bei ldapsearch klappt es aber mit ldaps:// gar nicht. In ldap.conf ist aber auf LDAP auf 7389 konfiguriert, das nehm ich erstmal. Aber auch damit bekommt Redmine nicht die Zugangsdaten. Und mein Kommando habe ich nun wie folgt geändert:

ldapsearch -H ldap://<ip>:7389 -b dc=host,dc=intranet -x -D uid=redmine,cn=users,dc=host,dc=intranet -W uid=Administrator

Es bleibt aber bei Invalid Credentials (49).
Der Prot scheint in den IP Tables offen zu sein (Accept anywhere ).


#5

Dann bitte mal ein -d 65535 mit einbauen, um die Debug-Ausgabe zu aktivieren. Das sollte hoffentlich aufschlussreicher sein.
Achtung: Das erzeugt eine sehr umfangreiche Ausgabe und fragt weiterhin interaktiv nach dem Passwort. Es empfiehlt sich, dass Passwort per echo -n in eine Datei zu schreiben und deren Dateinamen per -y ./DATEI zu übergeben. Alternativ per -w GEHEIM im Klartext auf der Kommandozeile. Das -W muss dann natürlich entfernt werden. Das Passwort taucht auch in der Ausgabe auf, von daher sollten Sie das Passwort abschließend ändern.

Eine Idee noch: Wenn in der /etc/ldap/ldap.conf (oder ~/.ldaprc) ein TLS_*-Optionen stehen, z.B. TLS_REQCERT, kann das dazu führen, dass der Verbindungsaufbau abgelehnt wird, weil die IP-Adresse nicht im SSL/TLS-Zertifikat steht. Ein LDAPNOINIT=1 vor dem ldapsearch sollte das unterbinden. Siehe man 5 ldap.conf.

Also:

LDAPNOINIT=1 ldapsearch -LLL -d 65535 -H "ldap://${IP}:7389" -b dc=host,dc=intranet -x -D uid=redmine,cn=users,dc=host,dc=intranet -w "${GEHEIM}" uid=Administrator dn

#6

Ich habe etwas Probleme, die Debug-Ausgabe aus dem Terminal herauszubekommen, aber wenn ich das Passwort angebe, ändert sich bereits das Verhalten:

ldapsearch -LLL -H "ldap://${IP}:7389" -b dc=host,dc=intranet -x -D uid=redmine,cn=users,dc=host,dc=intranet -w "${abcd1234}" uid=Administrator dn

Dann kommt “Server is unwilling to perform (53) additional info: authentification bind (DN with no password) disallowed”.

PS: Das Passwort habe ich natürlich nur zu Testzwecken so gewählt. Beim Nutzer redmine habe ich “Einfaches Authentifizierungskonto” in den Optionen angewählt, ansonsten ist alles auf der Voreinstellung.


#7

Mal vorsichtig gefragt: Laut Doku ist die Verbindung nur mit TLS Zertifikat möglich. Ich habe das Zertifikat aber bisher nirgends auf dem Debian konfiguriert und verwende ja auch den unverschlüsselten Zugriff - ldaps funktionierte ja gar nicht, Kann da das Problem liegen?


#8

Jetzt klappt die Verbindung aus Redmine. Ich habe dort statt des Nutzernamens “redmine” jetzt den ganzen Principal “uid=redmine,cn=users,dc=host,dc=intranet” eingetragen. Dann geht’s.