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