Authentifizierung mittels ldaps

Problem:
postgres@srv:~/cfg/db2 $ psql db2 ntzkn
Passwort für Benutzer ntzkn:
psql: FATAL: LDAP-Authentifizierung für Benutzer »ntzkn« fehlgeschlagen

Vorgeschichte:
Eine Anwendung nutzt eine postgresql Installation. Diese authentifiziert die Nutzer eines Datenbankclusters. Als Authentifizierungsmethode wird ldap mit einer ldaps-URI eingerichtet und ssl des Datenbankservers aktiviert. Das für ssl des Datenbankservers notwendige Serverzertifikat, der private Schlüssel, und sie Liste vertrauenswürdiger Zertifizierungsstellen wurden im Datenverzeichnis des Datenbankclusters abgelegt und der Datenbankserver startet. Auf eine Zertifikatssperrliste wurde verzichtet. Leider liefert die Anwendung, die den Cluster nutzt, bei der Authentifizierung einen ldap-Fehler. Zur Ursachenbeseitigung soll zunächst der o. g. ldapsearch Befehl mit dem ldaps Protokoll erfogreich durchgeführt werden.

Authentifizierungskonfiguration der Datenbank (postgresql, pg_hba.conf):
local db2 ntzkn ldap “ldaps://ldap.uw.de/uw-mhn.de;uid=”
host db2 ntzkn 127.0.0.1/32 ldap “ldaps://ldap.uw.de/uw-mhn.de;uid=”
(das sind die einzigen Einträge, zum Testen)

Um die ldap-Anbindung auf dem sles11 server zu testen, wurde verwendet:
ldapsearch -v -x -H “ldap://ldap.uw.de/uw-mhn.de” uid=ntzkn | tail
ldap_initialize( ldaps://ldap.uw.de:389/uw-mhn.de??base )
filter: uid=ntzkn
requesting: All userApplication attributes
shadowExpire: 1299625200
sambaKickoffTime: 1299625200

search result

search: 2
result: 0 Success

numResponses: 2

numEntries: 1

Frage:
Wie ist vorzugehen um das Problem zu lösen?

mittlerweile erledigt

Ja, und wie?
Offensichtlich wusste es niemand, also wäre es schön, wenn du nicht nur Fragen stellst sondern auch dein Wissen teilst.

Oh, große Indianer-Entschuldigung … :astonished:
Um eine funktionierende Authentifizierung hinzubekommen wurde nur der postfix ergänzt:
host db2 ntzkn 127.0.0.1/32 ldap “ldaps://ldap.uw.de/uw-mhn.de;uid=;,ou=people,dc=RR,dc=uw-mhn,dc=de”"

Die Sache hat aber einen erheblichen Schönheitsfehler. Der Teilstring ‘dc=RR’ ist abhängig vom übergebenen login. Vom Datenbank client wird sie nach meinem Wissen nicht mitgeteilt. Allerdings wäre das Login für sich alleine schon eindeutig. Auf Zuruf habe ich erfahren, ldap würde auch Wildcards verstehen.
Dann könnte man wohl so etwas wie ‘dc=’ verwenden. '’ wäre kein oder beliebige, beliebig viele Zeichen. Der Einbau in den Parameter für die Authentifizierungsmethode für sich allein, mit ‘’ oder mit ‘\’ maskiert führte nicht zum Erfolg.

Ist jemandem bekannt wie für den Parser für die pg_hba.conf in diesem Fall zu maskieren ist? Gibt es eine Dokumentation dazu?

Imho reicht es, das einfach als * zu schreiben. In deiner Zeile stehen jedoch 3 Anführungszeichen, nicht nur zwei. Ist das so richtig?

Ansonsten einfach mal schauen, was der LDAP-Server konkret für Anfragen bekommt.


Eine weitere Möglichkeit wäre es, die Authentifizierung in PAM zu verlagern und dort den LDAP-Server anzusprechen. Dort ist es dann möglich, mehrere Quellen anzusprechen, z. B. erst das System, dann den LDAP-Server und das wiederum mit mehreren verschiedenen Suchpfaden.

Die pg_hba.conf lehnt das Login schon ab, wenn der erste LDAP-Server “nein” sagt.

Aus performance Gründen und wegen der zentralen Bedeutung können wir das logging leider nicht aktivieren.

Damit hat sich dieser Lösungsweg erledigt. Bei der ersten ‘falschen’ Einrichtung würde die Authentifizierung abgebrochen.

Die Schreibweise mit dem Jokerzeichen * hat nicht funktioniert.

Ich habe mich wahrscheinlich falsch ausgedrückt:

Sobald PostgreSQL eine Zeile findet, in der “Datenbank”, “Benutzername”, “Host/Netzwerk” und der IP-Bereich passen, wird in die Authentifizierungsmethode geschaut.

Wenn dort LDAP steht, wird halt der LDAP-Server befragt. Kennt der den Benutzer nicht oder der Pfad falsch, gibt es eine ablehnende Nachricht.


Was du nicht machen kannst - und was z. B. mit PAM geht: noch eine weitere Zeile in pg_hba.conf auswerten und einen zweiten LDAP-Server oder den gleichen Server mit einen anderen Pfad befragen. Die erste passende Zeile greift, danach ist Schluß.
In PAM kann man stackable authentication nutzen: wenn eine Methode fehlschlägt, wird die nächste probiert. Dort kann man ggf. auch mehrere verschiedene LDAP-Server eintragen und nacheinander befragen.


Zum Debugging: für so etwas existieren Tools wie Wireshark. Einfach mal den Netzwerkverkehr mitschneiden - und dazu ldap statt ldaps nutzen.

workaround:
Mit einer eigens eingerichteten Passagemöglichkeit durch eine unserer firewalls ist es nun möglich einen AD-Server zu nutzen.
Der Parameter für die Authentifizerung ist so gestaltet, daß er nur mit dem login ergänzt werden muß.

Wurde bereits erfolgreich getestet.
Beispiele dazu gibt es in der postgresql docu unter 21.2.7. (…EXAMPLE)
Damit wäre das Problem erledigt.

Das war mir bereits bekannt.

Abschließend nochmal herzlichen Dank für die produktiven Hinweise! :smiley: