Re: PAM LDAP Authentifizierung mit MD5
> IST-Zustand:
> 1.) Die Authentifizierung ist erfolgreich mit Hilfe von libnss-ldap auf LDAP
> umgestellt worden. Bei allen Benutzern, die nicht im ldap sondern in der
> /etc/passwd liegen werden die Passwörter als md5-Hash in /etc/shadow
> gespeichert. -> Soweit in Ordnung!
OK.
> 2.) Als Benutzerverwaltung würde ich gern den LDAP Account Manager
> verwenden. Dieser kann u.a. mit crypt, ssha, md5,... umgehen. Der
> phpldapadmin auch (zusätzlich noch md5crypt.
Ja.
> 3.) Wenn ich in einem der beiden Tools ein Passwort für einen Benutzer als
> CRYPT-Hash speichere funktioniert der Login.
> 4.) Wenn ich in einem der beiden Tools ein Passwort für einen Benutzer als
> MD5-Hash speichere funktioniert der Login NICHT!!
Wie machst du das genau? Du bist dir schon bewußt, das bei LDAP der
Vergleich Eingab<->userPassword im LDAP-Server erfolgt und nicht auf dem
Client. D.h. der Client liefert das Passwort _im Klartext_ (daher macht
man LDAP-Auth ja auch bitte via STARTTLS auf 389 oder direkt
verschlüsselt and 636) an den Server, welcher dann die die Crypt-Methode
(z.B: {MD5}) aus dem userPassword-Attribut ausliest, dann noch ggfls.
das Salt und dann das übergebene Passwort damit verarbeitet und dann das
Ergebnis mit dem Attribut im Objekt vergleicht.
Das heißt also, das es für den Client absolut egal zu sein hat, _wie_
das Passwort im Attribut steht, weil der Client es eh nie zu sehen
bekommt.
Frage ist jetzt: Wie sieht das Attribut eines funktionierenden und wie
das eine nicht-funktionierenden Users aus (slapcat benutzen).
> getent shadow liefert mir bei allen Benutzern aus der /etc/shadow mit
> md5 den Hash-Wert, bei den Benutzern aus dem ldap mit crypt den
> crypt-wert und den Benutzern um ldap mit md5 ein x.
Wenn der den Hash-Wert liefert, dann ist dein lokaler root wohl auch der
LDAP-DB-Admin. Ob das so gut, ist, will ich hier nicht diskutieren, ich
finde es bedenklich.
S°
--
BOFH excuse #76:
Unoptimized hard drive
Reply to: