In den letzten Jahren hat Samba sich in vielen Bereichen als ernst zu nehmende Alternative zu NT-Servern herausgestellt. Der freie SMB-Server deckt den Bereich Datei- und Druckdienste weitgehend ab, viele Unternehmen können daher ganz auf den NT-Einsatz auf Servern verzichten, selbst wenn sie auf Windows-Clients angewiesen sind. In größeren Installationen zeigen sich jedoch Grenzen, die zu einem teilweise erheblichen Administrationsaufwand führen. Samba 2.2 löst einige dieser Probleme, sodass sich ein Server unter Samba 2.2 inzwischen fast nahtlos in eine bestehende Domänenlandschaft integrieren kann.
Wesentliche Neuerungen der Version 2.2 sind der Daemon winbind für die Übernahme von Benutzern und Gruppen von einem Domänencontroller, eine feiner granulierte Rechtevergabe durch Access Control Lists (ACL) sowie eine an NT-Mechanismen angelehnte zentrale Druckertreiberverwaltung.
Seit der Version 2.0 beherrscht Samba das Domänenprotokoll von Windows NT als Mitgliedsserver. Die Einstellung
security = domain
ermöglicht die Überprüfung der Benutzerpasswörter durch den Primary Domain Controller. Damit lässt sich eins der größten Probleme beim Einsatz von Samba lösen: die doppelte Passwortverwaltung bei reinen Samba-Servern. Andere Hürden bleiben jedoch bestehen:
winbind ist ein Weg, der die Benutzerverwaltung von Linux und Windows NT vereinheitlicht. Dies geschieht mit denselben Protokollen, die eine NT-Workstation in eine NT-Domäne aufnehmen. Sämtliche Benutzer und Gruppen der Domäne erscheinen unter Unix wie normale Benutzer. winbind realisiert dies auf dem gleichen Weg, wie NIS die Benutzerdatenbank von einem NIS-Master importiert.
Sämtliche Zugriffe auf die Benutzerdatenbank führen Funktionen wie getpwuid(2) oder getgrnam(2) aus. So genannte nsswitch-Module führen diese Funktionen der C-Bibliothek durch. Die Änderung von statischer Konfiguration hin zu den dynamischen nsswitch-Modulen wurde beispielsweise deutlich an der geänderten Konfiguration der Resolver-Bibliothek. Nicht mehr die Datei /etc/host.conf, sondern /etc/nsswitch.conf bestimmt die Reihenfolge der Mechanismen, mit denen Namen zu IP-Adressen aufgelöst werden. Der entsprechende Eintrag in /etc/nsswitch.conf lautet beispielsweise:
hosts: files dns
Dadurch wird zuerst die Datei /etc/hosts und bei Fehlschlägen der DNS-Server befragt, der in der /etc/resolv.conf konfiguriert ist. Diese unterschiedlichen Mechanismen sind in dynamischen Bibliotheken realisiert, die unter /lib/libnss_* zu finden sind. Für jeden erwähnten Mechanismus gibt es eine Datei. Im Beispiel oben erledigt die Datei /lib/libnss_files.so.2 die Suche in /etc/hosts, die Datei /lib/libnss_dns.so.2 ist für die DNS-Anfrage zuständig.
Nicht nur die Namensanfragen, auch die Zugriffe auf die Dateien /etc/passwd und /etc/group realisieren diese Module. winbind stellt die Datei libnss_winbind.so.2 zur Verfügung, die über den winbindd die Zugriffe auf die Benutzerdatenbank an den Primary Domain Controller (PDC) der NT-Domäne weiterleitet. Die Einträge
passwd: files winbind group: files winbind
in der /etc/nsswitch.conf machen sämtliche Benutzer und Gruppen der NT-Domäne sofort unter Unix sichtbar, sofern winbindd läuft und Domänenmitglied ist.
Dadurch, dass ein Benutzer in der virtuellen /etc/passwd auftaucht, lässt sich sein Passwort leider noch nicht überprüfen. Die Authentifizierung von Benutzern regeln heutzutage PAMs (Pluggable Authentication Modules). Mit einem ähnlichen Verfahren werden für die unterschiedlichen Dienste, die Benutzerpasswörter überprüfen müssen, dynamisch Module geladen, um unterschiedlichen Anforderungen gerecht zu werden. Die entsprechenden Module liegen üblicherweise unter /lib/security, die Konfiguration der Dienste erfolgt in den Dateien unterhalb von /etc/pam.d. Zu winbind gehört eine Bibliothek pam_winbind.so, die Passwortanfragen an den PDC weiterleiten kann.
Samba als Domänenmitglied übernimmt alle Benutzer und Gruppen der Domäne automatisch in die lokale Benutzerdatenbank. Damit ist es nicht mehr erforderlich, sie manuell anzulegen. Das ermöglicht ein viel gefragtes Feature: die Zugriffskontrolle anhand von Domänengruppen. Eine Gruppe der Domäne kann in den Parameter valid users aufgenommen werden.
Eine weitere erhebliche Einschränkung bei der Umstellung von NT zu Samba fällt mit der Version 2.2 ebenfalls weg: die Beschränkung auf Unix-Dateisystemrechte, sofern das darunter liegende Unix ACLs unterstützt.
Momentan ist die Installation des eigentlichen winbind noch nicht trivial, da keine fertigen RPMs für die großen Distributionen zur Verfügung stehen. Zudem muss man winbind aus dem TNG-Zweig (The Next Generation) des CVS-Archivs beziehen, da sich der Code noch in der Entwicklung befindet. Hier soll es um die Installation zusammen mit der ebenfalls noch nicht freigegebenen Samba-Version 2.2 mit Suse 7.1 gehen.
Vor Experimenten an den nsswitch-Modulen sollte man eine mögliche Fehlerquelle von vornherein ausschließen: den Name Service Caching Daemon. nscd ist ein Cache für Zugriffe auf die passwd-, group- und andere Dateien. Da auf diese häufig zugegriffen wird, ist ein Caching sinnvoll, wenn diese Dateien groß sind oder die Zugriffe wie bei NIS über ein Netz erfolgen müssen. winbind fällt in die zweite Kategorie, hält aber seinen eigenen Cache vor. Zwei Caching-Systeme sind wenig sinnvoll und erschweren die Fehlersuche erheblich. Mit killall nscd wird man den Daemon temporär los. Dauerhaft lässt er sich abschalten, wenn in /etc/rc.config die Variable START_NSCD auf no gesetzt ist. Niemand dürfte den nscd vermissen.
Für den CVS-Download gibt es unter www.samba.org/samba/cvs.html detaillierte Anweisungen. Man erhält die Entwicklungsversion von 2.2 mit
cvs co -r SAMBA_2_2 samba
Ein
cd samba/source ./configure; make install
installiert Samba unter /usr/local/samba. In einem anderen Verzeichnis kann man sich nun die winbind-Quellen mit
cvs co -r APPLIANCE_TNG samba
laden. Tim Potter hat winbind im TNG-Zweig von Samba geschrieben, da Luke Leighton und andere dort eine recht vollständige Unterstützung des Microsoft Remote Procedure Call System entwickelt haben.
Der gesamte Zugriff auf die Benutzerdatenbank des PDC benutzt eben jenes RPC-System. Auch wenn TNG im Moment ein von Samba abgespaltenes Projekt ist und viele der Ideen nicht ohne Änderungen in den Samba-Hauptzweig einfließen werden (siehe Kasten Samba TNG), können die Clientkomponenten von TNG, zu denen winbind gehört, ohne Komplikationen zusammen mit Samba-2.2-Versionen eingesetzt werden. Insbesondere das Programm rpcclient ist interessant, da es den Netzzugriff auf die Benutzerdatenbank und die Registry von Unix aus ermöglicht.
winbind soll zukünftig mit der normalen, stabilen Samba-Version 2.2 ausgeliefert werden; dies jedoch nicht mit der Version 2.2.0, sondern erst mit einer der Subversionen innerhalb von Samba 2.2. Die Kompilation erfolgt mit
cd samba/source ./configure -enable-static=yes \-enable-shared=no make nsswitch make nsswitch/pam_winbind.so
Aus dem Kompilat kopiert man am besten per Hand die vier benötigten Dateien an die richtige Stelle. make install funktioniert hier nicht, da erstens die existierende 2.2 in /usr/local/samba überschrieben würde, und zweitens der ohnehin nicht benötigte Serverteil von TNG nicht sauber durchkompiliert.
cp bin/winbind \/usr/local/samba/bin cp bin/wbinfo /usr/local/samba/bin cp nsswitch/pam_winbind.so \ /lib/security cp nsswitch/libnss_winbind.so \ /lib/libnss_winbind.so.2
Die hilfreiche Handbuchseite zu winbind findet sich in ../docs/manpages und ist bei Bedarf schnell nach /usr/share/man/man8 kopiert, damit sie im Handbuch zur Verfügung steht.
Listing 1 zeigt eine Beispielkonfiguration. Die Freigabe verleiht dem Unix-Benutzer root- und dem NT-Administrator Schreibrechte, zusätzlich hat die Domänengruppe Benutzer Leserecht. Die auf winbind bezogenen Optionen haben folgende Bedeutung:
winbind separator: Normalerweise trennt NT Domänen- und Benutzernamen durch den Backslash. Da alle Unix-Shells diesen gesondert auswerten, ist bei jedem chmod auf einen NT-Benutzer ein doppelter Backslash notwendig. Mit der Option winbind separator kann man sich ein eigenes Trennzeichen definieren, etwa das +-Zeichen. Damit mutiert der Benutzer vl in der Domäne NTDOM zu NTDOM+vl.
winbind uid/winbind gid: Unter Windows-NT haben Benutzer und Gruppe jeweils einen eindeutigen Security Identifier (SID). Der besteht aus einer 96 Bit langen Domänen-ID und einem 32 Bit langen Relative Identifier (RID), der der uid oder gid unter Unix entspricht. Die 1:1-Umsetzung eines RID in eine entsprechende Unix-uid ist leider nicht möglich, da dies mit existierenden Unix-Benutzern kollidieren würde. Außerdem ist der RID über Domänengrenzen hinweg nicht eindeutig. Bei Vertrauensstellungen zwischen Domänen würde es zu Kollisionen kommen. Mit winbind uid und winbind gid wird dem winbind ein unter Unix nicht belegter Bereich der entsprechenden IDs zur Benutzung übergeben, die er auf Anforderungen NT-Benutzern und Gruppen zuweisen kann. Diese Zuordnung wird in den Datenbanken winbindd_idmap.tdb und winbindd_cache.tdb abgelegt, die sich im Verzeichnis /usr/local/samba/var/locks befinden. Diese Datenbanken sind absolut zentral und als genauso wichtig wie /etc/passwd anzusehen. Bei einem Verlust dieser Dateien müssen sämtliche Unix-Dateien, die NT-Benutzern gehören, erneut mit chown übergeben werden.
template homedir/template shell: In der Windows-NT-Benutzerdatenbank kann man das Unix-Heimatverzeichnis und die Login-Shell nicht speichern. Diese muss winbindd künstlich erzeugen. Das Heimatverzeichnis sollte dabei in Mehrdomänenumgebungen auf jeden Fall die Domänenkomponente %D enthalten, um Namenskollisionen abzufangen. Sollen sich NT-Benutzer interaktiv am Linux-Rechner anmelden, muss das Heimatverzeichnis manuell erzeugt, kann aber selbstverständlich wie üblich per NFS bezogen werden. Bei reinen Samba-Servern ist es möglicherweise nicht notwendig, ein Heimatverzeichnis anzulegen.
Nach Starten der Daemons (nmbd, smbd, winbindd) kann die Domäne betreten werden. Dies geschieht nicht mehr wie bei Samba 2.0 über den Servermanager und smbpasswd, sondern über das Programm samedit, mit dem man sich als Administrator beim PDC anmeldet und mit createuser den Maschinenaccount erzeugt. samedit startet man mit
samedit -S PDC -W NTDOM \-U Administrator
Dabei bezeichnet PDC den Namen des Primary Domain Controller, und NTDOM ist die angenommene Domäne. Am samedit-Prompt kann man nun mit
createuser LINUX$ -j NTDOM -L
die Domäne betreten, wobei LINUX durch den Maschinennamen des Clients zu ersetzen ist. Wenn man die Einträge zu passwd und group wie oben erwähnt an winbind anpasst, sollte man mit
getent passwd
sämtliche Unix- und alle NT-Benutzer sehen. Gleiches gilt für getent group. Ein
touch /tmp/test chmod samba+user /tmp/test
und ein
ls -l /tmp/test
sollte man sich an dieser Stelle nicht entgehen lassen. Hier offenbart sich ein Fehler im ls: Benutzernamen, die länger als acht Zeichen sind, schneidet das Kommando einfach ab.
Wer einen reinen Samba-Server ohne interaktive Logins aufsetzt, kann es bei diesem Stand bewenden lassen und jetzt Domänengruppen in valid users aufnehmen und damit die Zugriffskontrolle auf Samba-Freigaben über Gruppenzuordnungen praktisch vollständig vom PDC aus administrieren. Weiterhin kann man auf das anfällige add user script verzichten, da winbind die Benutzer transparent zuordnet.
Sollen sich auf dem Linux-System Benutzer interaktiv anmelden, ist ein weiterer Schritt notwendig: die Anpassung der PAM-Konfiguration. Die Benutzerauthentifizierung wird unter Linux genau wie der Zugriff auf /etc/passwd über dynamisch ladbare Module abgewickelt, die so genannten Pluggable Authentication Modules. Um das mit winbind kompilierte Modul /lib/security/pam_winbind.so nutzen zu können, sind die Dienste, die das tun sollen, entsprechend zu konfigurieren. Als Beispiel soll hier die Konfiguration des login-Programms dienen, das für das Anmelden an den virtuellen Konsolen zuständig ist.
Vor der Konfiguration der PAM-Module unter /etc/pam.d/ sollte man sich vergegenwärtigen, dass Konfigurationsfehler in diesen Dateien jemanden effektiv aus dem System aussperren können. Nach Fehlern ist möglicherweise ein externes System wie das Suse-Rettungssystem für die Wiederherstellung der eigenen Daten nötig. Daher sollte man den Umgang mit einem solchen Notsystem vorher durchgespielt haben. Die Standard-Konfigurationsdatei /etc/pam.d/login sieht aus wie Listing 2, /etc/pam.d/login.
Verschiedene Zeilen, die mit auth beginnen, sind für die Authentifizierung zuständig. Das Modul pam_unix.so vergleicht den Hash des gelieferten Passworts mit dem Hash in /etc/shadow und übernimmt damit die eigentliche Passwortüberprüfung. Die anderen Zeilen in dieser Datei prüfen unterschiedliche Aspekte wie den Root-Zugang nur über bestimmte Terminals et cetera. Zeilen, die mit account beginnen, sind für Module, die den Zugriff aufgrund etwa der Tageszeit verweigern könnten. Beide Teile müssen durch die winbind-Module ergänzt werden.
Die Einstellung in Listing 3 verkehrt die Reihenfolge der Überprüfung ins Gegenteil. Die Standardinstallation überprüft erst das Passwort und nur bei richtiger Eingabe die anderen Zugangsvoraussetzungen. Die gezeigte Beispielkonfiguration kann die Passwörter erst am Schluss erledigen. Das Modul pam_winbind.so muss als sufficient markiert sein, um NT- und Unix-Passwörter zuzulassen.
Druckertreiber kann Samba 2.2 direkt bei den Warteschlangen hinterlegen. Bei der ersten Benutzung eines Druckers wird der entsprechende Treiber automatisch auf der Workstation installiert, ohne dass der Anwender lokale Administratorrechte haben muss. Die Verwaltung der Treiber geschieht komplett mit NT-eigenen Werkzeugen.
Drucken unter Samba läuft prinzipiell immer so ab, dass der Administrator auf den Clients einen Druckertreiber installieren muss. Dabei kann er sich bei Samba entscheiden, ob der Client oder der Server die endgültige Aufbereitung für den speziellen Drucker vornehmen soll. Man kann auf jedem Client im Netz für jeden verfügbaren Drucker einen speziellen Druckertreiber installieren. Die Alternative ist, auf den Clients einen generischen Postscript-Treiber zu installieren, und das Rendering der Seite auf dem Server durch Ghostscript erledigen zu lassen.
Beides hat Nachteile. Druckertreiber auf dem Client sind aufwendig zu warten, insbesondere wenn beispielsweise ein Treiber-Update einzuspielen ist. Bei der Ghostscript-Lösung verliert man die speziellen Anpassungen, die der Druckerhersteller in den Windows-Treibern vorgenommen hat. Unter Unix ist es beispielsweise immer ein Problem, spezielle Druckereigenschaften wie Papierschächte anzusprechen, oder bei Farbtintenstrahldruckern eine ansprechende Druckqualität zu bekommen.
Setzt man auf Server- und Clientseite Windows NT ein, treten diese Probleme nicht auf. Wenn auf dem Server ein Druckertreiber installiert ist, steht er sofort allen Clients zur Verfügung, ohne dass der Administrator eingreifen müsste. Ein Treiber-Update kann von einem beliebigen Arbeitsplatz aus geschehen und ist sofort für alle verfügbar, die auf diesen Drucker zugreifen.
Samba 2.0 beherrscht dieses Feature für Windows-95/98er-Clients, wobei die Installation nicht trivial ist. Windows NT wurde bislang nicht unterstützt, da NT zu NT über das RPC-System druckt und nicht über die bekannten und unterstützten Druckaufrufe. Version 2.2 soll diese Aufrufe unterstützen, sodass die fortgeschrittenen Features des NT-Drucksystems allen Samba-Benutzern zur Verfügung stehen kann. Damit kann Samba mit folgenden Features mit Windows NT gleichziehen:
Zunächst muss eine Freigabe namens [print$] eingerichtet werden. Der Name dieser Freigabe ist in Samba hart kodiert, also exakt einzuhalten. Windows-NT-Druckerserver benutzen [print$] für den Download von Druckertreibern.
Frühere Versionen von Samba haben eine Freigabe namens [printer$] empfohlen. Dieser Name war an die entsprechende Freigabe von Windows 9x-Clients angelehnt. Windows 9x-Druckserver haben immer eine Freigabe [printer$] mit Nurlesezugriff ohne Passwort, um den Download von Druckertreibern zu ermöglichen.
Die vorherige Implementierung hatte einen Parameter namens printer driver location, um pro Druckerfreigabe den Ort der Treiberdateien anzugeben. Ein anderer Parameter printer driver hat den Namen des Druckertreibers angegeben. Zusammen mit printer driver file sollten sie in neuen Installationen nicht mehr verwendet werden.
In der smb.conf muss eine Freigabe [print$] angelegt sein.
[print$] path = /usr/local/samba/printers guest ok = yes browseable = yes read only = yes write list = ntadmin
Auf diese Freigabe müssen alle Druckerbenutzer Lesezugriff haben. Schreibzugriff ist für die Installation neuer Druckertreiber notwendig. Unterhalb dieser Freigabe müssen verschiedene Verzeichnisse eingerichtet werden, um unterschiedliche Clientarchitekturen zu unterstützen. Im Einzelnen sind dies:
\\Server\print$\W32X86 Windows NT x86 \\Server\print$\WIN40 Windows 95/98 \\Server\print$\W32ALPHA Windows NT Alpha_AXP \\Server\print$\W32MIPS Windows NT R4000 \\Server\print$\W32PPC Windows NT PowerPC
Diese Verzeichnisse sollten einem Administrator gehören, momentan muss dies root sein (uid = 0).
Existieren diese Verzeichnisse, kann man sich an einem Windows-NT-4.0-Client anmelden, und zwar als Benutzer, der auf den Samba-Server mit Root-Rechten zugreifen kann. Das sind entweder root selbst oder ein Benutzer, der in der smb.conf unter admin users eingetragen ist.
In der Netzwerkumgebung sind nun im Bereich Drucker die freigegebenen Drucker des Servers sichtbar.
Hier unterscheidet sich Samba von Windows-NT-Druckerservern. NT gibt gelegentlich Drucker aus, die nicht freigegeben sind. Samba zeigt nur die freigegebenen Drucker an. Die anfängliche Liste von Druckern zeigt keinen Druckertyp an. Man kann einen Druckertreiber bereitstellen, indem man den Knopf Neuer Treiber in den Eigenschaften des Druckers anwählt, und den entsprechenden Druckertreiber installiert. Druckertreiber für andere Betriebssysteme als Windows NT x86 findet man unter dem Menüpunkt Freigabe im Kontextmenü des Druckers.
Volker Lendecke
ist Mitglied im Samba-Team und Mitgründer der Service Network GmbH in Göttingen. Dort ist er für Schulungen verantwortlich und im Bereich Netzwerksicherheit tätig.
| iX-TRACT |
|
Dieser Text ist der Zeitschriften-Ausgabe 04/2001 von iX entnommen.
iOS, Android, Windows Phone 7 und HTML5 - das neue Sonderheft von heise Developer führt Einsteiger und Profis in die Programmierung mobiler Geräte ein.
