Vorgeschichte:
Änderungen am LDAP - Client (Ubuntu 7.10 und evt. früher) haben bei einige Benutzer zu nicht bootenden Systemen geführt und wahrscheinlich auch deutlichen Zeitaufwand zur Wiederherstellung gekostet. 😢
▶ Das Problem:
Ein als LDAP - Client installiertes System blieb beim Booten mit
Starting kernel log daemon...
hängen.
Der Versuche den kernellog Dämon als User klog zu starten, blieb im noch nicht gestarteten LDAP - Server slapd "hängen".
▶ Im Thread "OpenLDAP als Authentifizierungsserver" http://forum.ubuntuusers.de/topic/139139 wurden dann 3 Lösungsmöglichkeiten angeboten.
1.
slapd vor klog starten
2.
/etc/nsswitch.conf wie folgt abändern:
passwd: files [UNAVAIL=return] ldap
group: files [UNAVAIL=return] ldap
shadow: files [UNAVAIL=return] ldap
3.
in /etc/ldap.conf bind_policy abändern.
bind_policy soft
▶ Die neue Lösung (seit Ubuntu 8.04):
Eine Beschreibung des Bugs und sein Weg zur Lösung erfolgt hier.
https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/155947
Soweit ich die die neue Lösung verstanden habe, werden nun per Start - Stop - Skript die lokalen User aus dem LDAP - Nachfrageprozess, durch einen Eintrag in /etc/ldap unter nss_initgroups_ignoreusers ausgeschlossen.
Siehe Paket libnss-ldapd.
Diskussion:
Fehler in Authentifizierung und Netzwerk sind nicht immer leicht zu finden.
Ein gutes Verständnis des Konzeptes erleichtert Installation und Fehlersuche besonders in diesem Bereich.
Folgende Punkte wurden für mich trotz längerer Suche nicht ganz klar und erschweren meiner Meinung nach die Installation und Fehlersuche:
▶ Warum 2 Pakete libnss-ldapd und libpam-ldap, für die es jetzt aber ein Metapaket (ldap-auth-client) gibt?
▶ Warum, bzw. für welche Programme gibt immer noch 2 Konfigurationsfiles ldap.conf in /etc und /etc/ldap?
▶ Welche Rolle spielt der Parameter rootbinddn in etc/ldap.conf? Wann ist sein Einsatz zwingend nötig?
Dieser Parameter kann bereits bei Installation des Paketes beeinflusst werden.
Wer vor allem das erste Mal einen LDAP - Client installiert, kann mit diesem Parameter, meiner Meinung nach, wenig anfangen.
Wenn dann etwas nicht funktioniert, fragt man sich als Anfänger dann möglicherweise schnell, ob es wohl an diesem rootbinddn liegt.
(er muss ja wichtig sein, wenn er bereits zu Beginn abgefragt wird 😉 )
Mit diesem Parameter wurde bei mir auf folgende Weise nach einem Upgrade von 7.10 auf 8.04 das Login lahm gelegt:
rootbinddn zeigte auf den Adminuser des LDAP - Trees, was mir nicht ganz unlogisch erscheint,
(als Benutzer root möchte ich den LDAP - Tree verwalten) und /etc/ldap.secret war leer.
Da der Loginprozess anscheinend mit root-Rechten läuft blockt die Zeile
by dn="cn=admin,dc=fisc" write
in /etc/ldap/slapd.conf
access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=fisc" write
by anonymous auth
by self write
by * none
den Loginprozess.
Ist nicht fein zu finden.
Nachdem ein LDAP - Client auch ohne den Parameter funktioniert und keine Paßwörter auf irgendwelchen Clients "herumliegen", könnte man doch ganz auf die Konfiguration bei der Installation ganz verzichten?
Wer diesen Parameter braucht, kann ihn dann ja immer noch aktivieren.
▶ Warum ist der Workaround für bug 155947 (siehe oben) so kompliziert?
Immerhin beschert er uns ein weiteres Start - Stop - Skript, mit dessen Verwendung man sich möglicherweise auch irgendwann auseinander setzen muss.
Die Dinge werden dadurch nicht einfacher und überschaubarer.
▶ Welcher Teil von LDAP möchte trotz Einträgen in /etc/nsswitch.conf
passwd: files ldap
group: files ldap
shadow: files ldap
immer noch im LDAP - Tree nachsehen, und blockierte das System am Booten?
Wozu gibt es die nsswitch.conf Einträge, wenn dann doch versucht wird im LDAP - Tree nachzusehen?
Warum taucht dieser Fehler z.B. in Ubuntu 6.06 nicht auf?
▶ Hilft das neue Paket ldap-auth-config langfristig bei einer Verwaltungsvereinfachung?
Im Paket ldap-auth-config wird neben ausgesprochen guten Beispielen zur PAM - Konfiguration eine Möglichkeit geboten verschieden Profile zur Konfiguration eines LDAP - Clients anzulegen und nach /etc/pam.d/* einzuspielen.
Aus der verteilten Struktur in /etc/pam.d/* wird in /etc/auth-client-config/profile.d/ ein einziges File.
Für den "schnelle" Erfolg ist dies sicher ein Fortschritt.
Falls jedoch etwas schief läuft, müssen evt. die Profile und alle Files in /etc/pam.d/* überprüft werden.
Da man die Einträge in /etc/pam.d/* nicht selbst angelegt hat, darf man sich alles Wissen über die Aufteilungen jetzt aneignen.
Wer findet dann heraus, was von den Profilen geändert wurde, oder was vorher Standard war?
Meiner Meinung nach ist es nicht sinnvoll Konfigurationsfiles automatisch über andere Konfigurationsfiles zu ändern.
Statt "automatischer Konfiguration" hätte ich mir die guten Beispiele schon früher gewünscht!