Tanz der Systeme

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:

• Alle Benutzer müssen auf der Samba-Maschine existieren. Der Parameter add user script kann die Erstellung der Benutzer automatisieren, aber sie sind dann doppelt enthalten.
• Es ist nicht möglich, die Zugriffskontrolle auf Samba-Freigaben anhand der Gruppenmitgliedschaft in der Domäne vorzunehmen. Die Gruppen müssen auf dem Samba-Server manuell nachgepflegt werden, oder der Parameter valid users muss jeden einzelnen Benutzer enthalten.
• Namenskollisionen zwischen Unix- und Domänenbenutzern sind nicht vernünftig behandelbar. Dies gilt insbesondere für Domänen mit Vertrauensstellungen.

Benutzerverwaltung mit winbind

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.

winbind-Installation: noch kein RPM

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.

[global]
      winbind separator = +
      winbind cache time = 10
      template shell = /bin/bash
      template homedir = /home/%D/%U
      winbind uid = 10000-20000
      winbind gid = 10000-20000
      workgroup = NTDOM
      security = domain
      password server = *
[daten]
      path = /daten
      writeable = no
      write list = root NTDOM+administrator
      valid users = root NTDOM+administrator @NTDOM+Benutzer

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:

Konfiguration der Daemons

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.

auth     requisite     /lib/security/pam_unix.so       nullok #set_secrpc
auth     required      /lib/security/pam_securetty.so
auth     required      /lib/security/pam_nologin.so
auth     required      /lib/security/pam_env.so
auth     required      /lib/security/pam_mail.so
account  required      /lib/security/pam_unix.so
password required      /lib/security/pam_unix.so       strict=false
session  required      /lib/security/pam_unix.so       none # debug or trace
session  required      /lib/security/pam_limits.so

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.

auth     required       /lib/security/pam_securetty.so
auth     required       /lib/security/pam_nologin.so
auth     required       /lib/security/pam_env.so 
auth     required       /lib/security/pam_mail.so
auth     sufficient     /lib/security/pam_winbind.so
auth     required       /lib/security/pam_unix.so use_first_pass nullok #set_secrpc 
account  required       /lib/security/pam_winbind.so
password required       /lib/security/pam_unix.so       strict=false
session  required       /lib/security/pam_unix.so       none # debug or trace
session  required       /lib/security/pam_limits.so

NT-Druckermodell

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:

• automatische Installation von Druckertreibern für Windows 95/98/NT/2000;
• Druckertreiber lassen sich direkt von Windows NT über den entsprechenden Assistenten installieren;
• Unterstützung der NT-eigenen Aufrufe StartDocPrinter, EnumJobs und so weiter;
• NT-Zugriffslisten für Druckerobjekte;
• verbesserte Handhabung von Druckjobs durch die Verwendung einer internen Datenbank mit den Jobinformationen.

Konfiguration leicht verändert

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.