-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.08.2011 12:22, schrieb Martin Reising: > On Tue, Aug 02, 2011 at 08:48:49AM +0200, Rico Koerner wrote: >> Die Daemonvarianten sind hier zu bevorzugen, auch wenn sich die >> Paketmaintainer scheinbar noch nicht vollständig miteinander >> abgestimmt haben. Insgesamt läuft das danach mit weniger >> Rootrechten im System und ist auch besser verständlich. > > Wie kann man denn PAM und NSS ohne Rootrechte verwenden, im > gefragten Kontext? NSS geht grundsätzlich ohne Rootrechte, /etc/passwd ist von jedem lesbar. PAM benötigt Rootrechte, wenn es auf /etc/shadow zugreifen muß. Im Falle von LDAP gibt es 2 Möglichkeiten, einen bind mit einer bestimmten DN, um das Passwort zu lesen oder ein AUTH gegen LDAP. Beides kommt ohne Rootrechte im System aus. Für Auth wird einfach versucht, sich mit den eingegebenen Benutzerdaten am LDAP anzumelden und bekommt ein Ja oder Nein zurück. Dafür werden gar keine erweiterten Rechte benötigt, hier wird nicht mal das Passwort vom LDAP herausgegeben. >> Wenn die alten Varianten nicht funktionieren, hat man kaum >> Möglichkeiten zur Fehlersuche. > > strings, pam mit debug und strace bezeichne ich nicht als kaum. Es gab keine Log-Meldungen dazu, um das Problem erstmal einzukreisen. Ohne Fehlermeldung ist eine Suche nach dem Problem nicht grad trivial. Vielleicht fehlt mir da auch etwas Übung mit strace. nss-ldapd war da unter Lenny schon deutlich einfacher zu konfigurieren. Unter Squeeze gibts nun auch libpam-ldapd. >> Es ist kaum konfigurierbar und auch nicht dokumentiert, welche >> INformationen woher geholt werden. > > Du willst doch nicht ernsthaft PAM- und NSS-Modulen bei der > Konfiguration, z.B. in /etc/pam.d, als Parameter eine > Konfigruationsdatei mit absolutem Pfadnamen andrehen? Wer hat das behauptet? Hier ist mitnichten von einer Datei oder absoluten Pfaden die Rede. Ich wüßte jetzt aber auch nicht, was daran so schlimm wäre. Ich meinte damit, daß ich z.B. Benutzer in unterschiedlichen OUs ablege und PAM dann sagen möchte, daß nur die posixAccounts aus einer bestimmten OU für einen bestimmten Service zu verwenden sind. Da es bzgl. LDAP-Strukturen auch keinen eindeutigen Weg gibt, wie/wo ich den User im Verzeichnis anlege, sorgen diverse Unstimmigkeiten mindestens für Verwirrung. Jedes Tool organisiert die Daten etwas anders. Die kleinste Veränderung, obwohl sie im LDAP vollkommen korrekt ist, kann dann für Unstimmigkeiten sorgen (siehe ldapscripts). >> Die Stolpersteine hab ich bei einer Konfiguration mal >> zusammengefasst: >> http://www.netbreaker.de/mediawiki/index.php/Ldapscripts > > Das ist aber eine GANZ andere Baustelle: > > Die ldapscripts sind Kommandozeilentools für die Verwaltung von > Unix-Benutzern im LDAP. Hast du den Beitrag überhaupt gelesen? Vielleicht hilft das beim Verständnis. Es ist zwar im Zusammenhang mit ldapscripts beschrieben, aber die Probleme sind grundsätzlicher Natur in Bezug auf lib[pam|nss]-ldap(d) Und letztenendes ging es ja wohl auch um Unix-Benutzer, die sich dort anmelden sollten. > Die hat mit dem gefragten Kontext, Linuxsysteme an eine > Linux-Sambakiste an zu binden, außer LDAP nichts gemeinsam. Dann frag ich mich, warum du lib[pam|nss]-ldap überhaupt erst in Runde geworfen hast, wenn das in dem Kontext gar nicht relevant ist? Ich habe mich auch nur darauf bezogen und den Hinweis gegeben, den schon seit Lenny empfohlenen Daemon dafür zu verwenden. Der Verzicht auf Rootrechte wurde schon damals als wichtigster Grund angegeben. Gruß Rico -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJON/twAAoJEO1lFpl7wThS2VUH/RWe7MpdbzLhoxnO+GyUT/w7 URLMlj6kMayJV3U7wC8HYZavimWWaQKyzesaRz0T5y/5g370VmSJByLkFE9byIHn +mLWdi0PaM4d52OHp6Sr+vMc5Sq4OaWUjC+dtfwO1tJwpSeRe80tAoKULPFchwk8 DWz6X24Neyt0CEp/mqKIVkRVgRUuS2Memiyzvq5P2BR9uouk4qx4KMTThFPvp6bo RgSFdVgSRUDK82fZxfAnEl3NCzcJP/+d3ISOKPhk8Sw/CTvQuHnY5I/jC09/9Svr 2VA2SwAMK/7BjEg2ok9EO4EQVMnCnddxxALYESVVrtX2wtavxFLBdZgmkATB/8c= =wCD5 -----END PGP SIGNATURE-----
Attachment:
smime.p7s
Description: S/MIME Kryptografische Unterschrift