Am 04.08.2011 14:42, schrieb Hans-Dietrich Kirmse: > Hallo Rico, hallo Martin, > > Vorab wegen die libnss-ldapd und libpam-ldapd: Ich hatte hier vor > geraumer Zeit (1,5 Jahre?) wegen Problemen mit dem Start des LDAPs > nachgefragt und da gab es leider nur den Verweis auf einen (großen) > Thread ohne Ergebnis. Durch einen anderen Mitstreiter unserer Gruppe > wurde aber ein Lösung angegeben, die ich hier auch gepostet hatte (es > müssen dazu nur bestimmte Accounts und Gruppen angelegt werden) und seit > dem ist das Problem bzw. sind die Fehlermeldungen weg. Bei einer Übernahme der LDAP-Benutzerdaten für Debian aus SuSE hatte ich früher auch mal solche Probleme, ohne sie lösen zu können. > Die Fehlermeldungen kamen durch irgendwelche udev-Regeln, die nicht > erfüllt waren. Ich kann mir nur schwer vorstellen, daß das etwas mit LDAP zu tun hatte. > Wenn man da mit irgendwelchen Dämonen das Problem umgeht, > dann werden hier aus meiner Sicht eher mehr Rechte einem eigentlich > nicht benötigten Dämon gegeben. Es ist eher so, daß entweder die Bibliotheken mit Rootrechten befragt werden oder ein Daemon, der diese nicht mehr benötigt. D.h. für den Vorgang an sich benötige ich weniger Rechte. > Zudem, wenn man hier einen solchen > Stellvertreter zwischenschaltet, dann kann ich mir vorstellen, dass das > ACL-System vom LDAP ausgehebelt wird, um nicht gar zu sagen, dass das > 'ad absurdum' geführt wird. Aber das ist nur meine Meinung als Laie. Nein, die ACLs von LDAP werden damit nicht ausgehebelt. Ein AuthBind ist jedem Benutzer im LDAP gestattet. Das ist etwas anderes als mit RootBindDN nachzufragen, womit Lesezugriff auf die Passworte aller Benutzer benötigt wird. > jedenfalls ist die Argumentation für libnss-ldapd und libpam-ldapd alles > andere als überzeugend. Aber das ist hier m.E. nicht relevant, weil das > doch nur für den Server gebraucht wird - oder denke ich da falsch? Das ist nicht pauschal zu beantworten. Das kommt darauf an was du konkret erreichen willst. Benötigst du nur einem Datei-/Druckservice vom Server, dann ist es nicht unbedingt notwendig. Logon-Skripte für Windowsclients sind natürlich nicht 1:1 verwendbar. Sollen andere Domänenbenutzer einen Drucker an dem Linuxclient benutzen können, dann mußt du diese irgendwie gegenüber dem Server authentifizieren. Hierbei sollte der Linux-Client als Domain-Member-Server agieren. Sollen sich dieselben Benutzer aus dem Server-LDAP auch auf Linuxebene an dem Linuxclient anmelden dürfen, so ist die Variante über lib[pam|nss]-ldap(d) auf dem Client die Sinnvollste. Damit sich der Client dann direkt am LDAP übers Netz anmelden darf, muß dies natürlich dafür freigegeben werden, wo der Sambaserver sonst nur per localhost bzw. Socket darauf zugreift. Das betrifft aber eher die Interface-Einstellung des LDAP-Servers und/oder die Firewall, an den ACLs muß dazu nichts geändert werden. Die zugehörige ACL sieht wahrscheinlich jetzt schon etwa so aus: access to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword by dn="cn=admin,dc=domain,dc=de" write by anonymous auth by self write by * none Das sehe ich aber nicht als Sicherheitsproblem, da LDAP SSL/TLS-verschlüsselt im Netz agieren kann. Per SMB darf die Anmeldung ja auch übers Netz. Die LDAP-Anmeldung könnte dann auch wieder für die Datei-/Druckerfreigabe per SMB am Client genutzt werden. Selbst Rootrechte auf dem Client ermöglichen bei einem AuthBind kein Aushebeln der LDAP-ACLs. Bei Verwendung einer RootBindDN-Konfiguration, würde der lokale Root natürlich das zugehörige Passwort aus der Datei auslesen können und damit mehr Rechte als nötig haben. Die Daemonen sind die Weiterentwicklungen aus den Bibliotheken. > Ich habe doch etwas gefunden (etwas blamabel für mich, da ich jahrelang > einen Arktur eingesetzt hatte): die Anleitung für die SuSE-Clients bei > Arktur sollte übertragen werden können: > > http://arktur.schul-netz.de/wiki/index.php/Installationshandbuch:SUSELinux Und dabei wird nss/pam-ldap auf dem Client verwendet: "Wahrscheinlich müssen Sie jetzt die Installations-CD oder -DVD einlegen, weil SUSE-Linux zwei weitere Pakete installieren möchte: nss_ldap und pam_ldap, außerdem muss auch noch der openldap-client installiert sein. Damit ist das Kapitel LDAP-Cleint beendet." > die Anleitung für Debian/Ubuntu ist nicht passend, weil die Probleme, > die dieser Server an dieser Stelle hat, bei uns einfach nicht relevant > sind. Die UIDs der User (im LDAP) fangen bei uns erst bei 10000 an, die > GIDs ab 1000. > > http://arktur.schul-netz.de/wiki/index.php/Installationshandbuch:DebianLinux Squeeze fängt bei den User/GroupIDs erst bei 1000/1000 an, Lenny hatte da noch 1000/100 als Standard. Interessante Aussage, daß sich Debian bzgl. GroupIDs nicht an die LSB hält. Die sind dort nicht mal spezifiziert. Lediglich zu den UserIDs gibt es dort eine Festlegung: http://refspecs.freestandards.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/tocusersgroups.html > wir verwalten im LDAP nur die User, Gruppen, Rechner und die festen IPs > (also DHCP). Die User, Gruppen und Rechner werden bei uns so angelegt, > wie es die smbldap-Tools machen (würden), allerdings wurden ein paar > Kleinigkeiten von smbldap-populate korrigiert und der root-Account in > 'Administrator' umbenannt. Aber ansonsten alles kompatibel zu den > smbldap-Tools. Kompatibel wozu? Hier scheint es keinen Standard zu geben. Ich habe mir dazu verschiedene Admin-Tools angeschaut und festgestellt, daß jedes die Daten etwas anders ablegt. Es mögen die smbldaptools auf der jeweiligen Distri damit klarkommen, das stellt aber noch nicht sicher, daß das distributionsübergreifend auch funktioniert. (Was aber nicht heißt, daß es grundsätzlich nicht funktioniert.) > in der oben genannten Anleitung für die Debian-Clients wird ja deutlich, > dass PAM und NSS angepasst werden muss. > mir geht es jetzt überhaupt erstmal um eine brauchbare Konfiguration > eines Debian-Clients an den Server. Wenn möglich genauso einfach zu > händeln (also möglichst menügeführt) wie hier in der Anleitung zu den > SuSE-Clients. Eine Anleitung komplett ohne Menüs, damit die > Konfiguration in ein Script/Paket gesteckt werden kann, wird natürlich > auch noch gebraucht - später. ;) Debian ist nun mal kein SuSE, d.h. hier wird es nicht so viel bunte Menus zum konfigurieren geben. Eine bunt bebilderte Anleitung wie bei SuSE wird bei Debian nicht so häufig zu finden sein, aber während der Installation werden die wesentlichen Informationen ähnlich abgefragt und die Debiananleitung zum Arktur ist ansonsten auch gut zu gebrauchen. Sie ist eben "debian-like" und enthält die relevanten Informationen, nur eben ohne Bilder. Für den Rest mußt du etwas lesen und ein wenig verstehen. Bei auftretenden Problemen kannst du gern weitere Fragen stellen, wenns geht mit genauen Fehlerbeschreibungen. Gruß Rico
Attachment:
smime.p7s
Description: S/MIME Kryptografische Unterschrift