Samba bietet ein fein abgestuftes System der Zugangskontrolle. Die Vielfalt macht dem Administrator das Auswählen schwer. Das Linux-Magazin zeigt, was wirklich wichtig ist, um den Zugang für Windows- Benutzer einzurichten und Benutzerkonten zu verwalten.

Niemand zeigt gern seine Karten, bevor er sie ausgespielt hat. Für die Datenhaltung auf einem Server heißt das: Jeder Benutzer soll genau das lesen und verändern können, was ihn angeht, und vor ungewollten Blicken und Eingriffen anderer geschützt sein. Der Samba-Server hält dazu eine ganze Reihe von Möglichkeiten bereit, die über Einstellungen in der »/etc/smb.conf« beeinflussbar sind. Zentrale Konfigurationsdirektive ist:

security = Sicherheitsstufe

Sie bestimmt den Security Level, also das grundsätzliche Verfahren für die Absicherung von Ressourcen auf dem Server und die Art, in der sich ein Benutzer authentifizieren muss, der eine solche Ressource nutzen möchte. Der Kasten “Security Levels” gibt eine Übersicht über die zur Zeit implementierten vier Sicherheitsstufen.

Sicherheit auf Share- oder Benutzer-Ebene

Die einfachste Art, Ressourcen für Benutzer freizugeben, erreicht man mit der Einstellung:

security = SHARE

Diese Stufe bietet einen minimalen Schutz gegen unbefugtes Lesen und Schreiben in gemeinsam genutzten Verzeichnissen und ist leicht einzurichten. Andererseits erhält jeder Benutzer, der irgendein Passwort für das Share kennt, zumindest lesenden Zugriff. Diese Einstellung hat ihre Berechtigung daher heute nur noch auf reinen CD-ROM- und Printservern oder in ganz und gar freundlichen Umgebungen, insbesondere im Zusammenhang mit der Benutzung von Gastzugängen (»smb.conf«-Direktiven »guest account«, »guest ok«, »guest only«). Etwas anspruchsvoller gestaltet sich die Benutzerverwaltung mit:

security = USER

Hierbei identifiziert sich der Benutzer einmalig durch eine förmliche Anmeldung mit Benutzername und Passwort. Letzteres kann auch verschlüsselt übermittelt werden. Ist der Benutzer am Server angemeldet, darf er alle für diesen Benutzer freigegebenen Shares auf dem Server im Rahmen seiner Linux-Benutzerrechte lesen und verändern.

Unter Umständen kann es sinnvoll sein, Nutzerkennung und Passwort des Linux-Systems aus »/etc/passwd« und »/etc/shadow« direkt für Samba zu nutzen. Um sich damit zu authentifizieren, muss jedoch das Passwort im Klartext an den Server übertragen werden. Der benutzt die »crypt()«-Funktion zum Vergleich mit »/etc/shadow«. Das bei Samba eingesetzte Challenge-Response-Verfahren zur Authentifizierung ist nicht anwendbar, da das Passwort dabei nicht übertragen wird.

Passwortverschlüsselung

Für die Arbeit mit verschlüsselten Passwörtern sind neben »security = user« zwei weitere Konfigurationsdirektiven zuständig:

encrypt passwords = yes
smb passwd file = /etc/samba/smbpasswd

Die Passwortdatei braucht nicht unbedingt angegeben zu werden, wenn man den Standardpfad und -namen verwendet, der für den Samba-Server bei der Kompilation eingestellt wurde. Auf jeden Fall sollte die Datei aber nur für Root les- und beschreibbar sein. Sie enthält die verschlüsselten Windows-Passwörter in jeweils einer Variante für Windows 9x sowie für NT und Nachfolger. Außerdem ist hier die Benutzer-ID des Unix-Accounts abgelegt, unter dessen Berechtigungen die Zugriffe des eingeloggten Samba-Benutzers stattfinden.

Zur Pflege der Passwortdatei dient das Kommando »smbpasswd«. Der Aufruf

# smbpasswd -a wichtel

legt einen Samba-Account für den Benutzer »wichtel« an, sofern bereits ein gleichnamiges Linux-Konto existiert. Aus Sicherheitsgründen sollte ein anderes Passwort gewählt werden als das für den Linux-Account, falls der Benutzer überhaupt die Möglichkeit eines interaktiven Logins erhält. Ansonsten lässt sich auch mit

#  passwd -l wichtel

der Linux-Account abschalten. Änderungen des Samba-Passworts bewerkstelligt der Administrator durch:

#  smbpasswd wichtel

Der Benutzer »wichtel« selbst ruft dazu lediglich

>  smbpasswd

auf. Gelöscht wird der Account durch das Kommando:

#  smbpasswd -x wichtel

Wer sich nicht mit dem »smbpasswd«-Kommando anfreunden kann, hat die Möglichkeit, die Datei »smbpasswd« über das Web-Interface Swat zu verwalten (Abbildung 1). Sollen die Benutzer Gelegenheit dazu erhalten, ihr eigenes Passwort über Swat zu ändern, darf der Linux-Account nicht durch »passwd -l« deaktiviert sein.

Abbildung 1: Die Web-Oberfläche von Swat erlaubt auch das komfortable Ändern von Benutzerpasswörtern.

Abbildung 2: Ein neues Share ist mit Swat im Handumdrehen angelegt. Die Web-Oberfläche erspart das Editieren der »smb.conf«.

Interaktive Logins können dennoch unterbunden werden, indem der Admin den betreffenden Benutzern das Programm »/bin/false« als Login-Shell in die »/etc/passwd« schreibt. Die Alternative ist, »/usr/bin/smbpasswd« selbst als Shell einzusetzen und die Passwörter über Windows Telnet oder Putty zu ändern. Putty bietet den Vorteil einer Passwortübertragung über SSH-Tunnel, während bei Telnet die Passwörter unverschlüsselt übers Netz gehen. Die ungeschützte Übertragung von Passwörtern im Netz sollte aber, wo es nur geht, vermieden werden. Im Falle gleicher Passwörter für den Samba- und Linux-Account wäre bei einer Ausspähung auch der Letztere kompromittiert – mit weitreichenden Folgen für die Sicherheit des Servers insgesamt.

In Umgebungen, in denen viele oder die meisten Benutzer neben dem Zugriff auf Dateien auch die Möglichkeit der interaktiven Anmeldung benötigen, wird aus Bequemlichkeitsgründen dennoch meist dasselbe Passwort für beide Anmeldungen benutzt. Dann ist es zweckmäßig, bei Änderung des Samba-Passworts, die meist vom Benutzer selbst ausgeht, das Linux-Passwort ebenfalls zu ändern, ohne dass ein zusätzlicher Bedieneingriff nötig wird. Samba automatisiert diesen Vorgang mit

unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *New*password* %nn *new*password* %nn *changed*

in der »smb.conf«. Die erste Zeile erklärt sich selbst (»%u« ist die Makro-Ersetzung für den Benutzernamen).

Die zweite Zeile enthält die komplette Pfadangabe zum Linux-Passwortänderungsprogramm. Der Passwort-Chat beschreibt den Wortwechsel zwischen Administrator und Programm, den der SMB-Dämon nachempfinden muss, damit die Änderung gelingt. Das hier gezeigte Beispiel bezieht sich auf SuSE Linux 8.1 und muss für jede andere Linux-Installation angepasst werden.

»%n« steht als Makro für das neue Passwort des Benutzers (zur Laufzeit von »smbd« bereitgestellt), »n« für das abschließende »[Enter]« bei der Passworteingabe. Sternchen sind die Platzhalter für beliebige Zeichenfolgen. Auf Details wie Groß- oder Kleinschreibung etwa des Wortes new und dergleichen ist besonders zu achten.

Jedes Mal, wenn ein Benutzer sein Passwort mit dem Programm »smbpasswd« ändert, wird zuvor das Passwort in der »/etc/passwd« auf den neuen Wert gesetzt. Damit hierfür das alte Passwort nicht abgefragt werden muss, läuft der ganze Vorgang unter »root«-Berechtigung ab. Schlägt er an irgendeiner Stelle fehl, bleibt auch das Samba-Passwort unverändert.

Tücken der Passwortverwaltung

Die Passwort-Synchronisation hat ihre Tücken. Bei vielen Linux-Systemen funktioniert sie nur für den einzelnen Benutzer, nicht aber bei interaktiver Benutzung von »smbpasswd« durch den Systemadministrator. Außerdem scheitert die Änderung oft daran, dass das Linux-System strenge Prüfungen für das neue Passwort eingebaut hat, deren genauer Inhalt dem Benutzer nicht bekannt ist und durch die neutrale Fehlermeldung des »smbpasswd«-Programms nicht gerade erhellt wird.

Sobald mehr als drei Samba-Server im Netz sind, wird das separate Verwalten von Benutzer-Accounts auf jeder einzelnen Maschine doch etwas lästig. Eine Alternative ergibt sich mit

security = SERVER

in der »smb.conf«. Die einzelne Linux-Maschine prüft die Benutzerberechtigung nicht mehr selbst, sondern leitet sie an einen zentralen Server weiter, der dann das Okay (oder Nicht-Okay) zur Benutzung der freigegebenen Ressourcen auf der anfragenden Maschine gibt. Vorteil ist, dass die Samba-Konten nur einmal zentral verwaltet werden.

Ist im Netz bereits ein Windows-NT-Domänen-Controller mit allen benötigten Benutzerkonten vorhanden, braucht der Admin nichts weiter zu tun, als auf dem neu hinzukommenden Samba-Server neben der eben genannten »security«-Direktive noch den Eintrag

password server = ZWERGENHEIM

in die Konfigurationsdatei zu schreiben, sofern der NetBIOS-Name des Domain-Controllers »ZWERGENHEIM« lautet. Die Angabe mehrerer Namen in dieser Zeile ist möglich, sie sind dann durch Leerzeichen zu trennen.

Um Ressourcen des Samba-Servers zu nutzen, muss der Benutzer allerdings auch dort einen Linux-Account besitzen. Der kann jedoch ohne Login-Berechtigung angelegt werden und sogar mit ungültigem Passworteintrag gesperrt sein. Um dem Systemverwalter die Pflege dieser Accounts zu ersparen, gibt es inzwischen Lösungen mit den Direktiven

add user script = Skriptaufruf %u
delete user script = Skriptaufruf %u

sowie der zusätzlichen Daemon-Software »winbindd« (»man smb.conf«, »man winbindd«).

Als Passwortserver kann neben Windows-Domain-Controllern auch jeder Samba-Server dienen, sofern er selbst eine Benutzerdatenbank führt (»security = user« in »smb.conf«, eigene »smbpasswd«-Datei). Dazu muss er nicht einmal PDC sein. Die Vorteile einer zentralen Benutzerverwaltung sind auch ohne Domänenstruktur nutzbar. Wer es allerdings ganz richtig haben möchte, setzt gleich bei allen Samba-Servern

security = DOMAIN

in der »smb.conf« – bis auf eventuell einen Server, der die Funktion des primären Domänen-Controllers übernehmen soll. Wie dieser konfiguriert wird, steht in dem folgenden Artikel dieses Samba-Schwerpunkts.

Schutz und Freigabe von Ressourcen

Die Ressourcen des Rechners, auf dem der Samba-Server läuft, stehen den authentifizierten Benutzern mit einem fein abgestuften System von Berechtigungen zur Verfügung. Die unterste Schicht sind die Zugriffsberechtigungen auf all jene Dateien und Verzeichnisse, die sich aus der Benutzer-ID und der beziehungsweise den Gruppenzugehörigkeit(en) des Benutzers ergeben.

Darüber hinaus bietet Samba eine Reihe weiterer Möglichkeiten, die über Direktiven in der Konfigurationsdatei geregelt sind. Diese Zugriffsmöglichkeiten werden verzeichnisweise vergeben und sind deshalb in einem »[share]«-Abschnitt der »smb.conf« zu finden. » share« steht hier symbolisch für den Share-Namen eines für Windows-Clients freigegebenen Verzeichnisses.

Beispiel: Der Administrator hat ein Verzeichnis gemeinsam zu nutzender Programme unter »/home/samba/shared _progs« angelegt und möchte es unter dem Freigabenamen »programme« im Windows-Netz zur Verfügung stellen. Eine mögliche Konfiguration in der »smb.conf« zeigt Listing 1. Durch »writeable = no« wird das Verzeichnis als nur lesbar festgelegt. Das entspricht der Standardeinstellung. Eine »write list« legt die Benutzer und Gruppen fest, die dennoch Schreibzugriff erhalten, in dem Beispiel sind das die Benutzer »wittchen« und »kobold«.

[programme]
  path = /home/samba/shared_progs
  comment = Gemeinsames Programmverzeichnis
  writeable = no
  write list = wittchen, kobold
  read list = @zwerge
  admin users = prinz

Demgegenüber bestimmt die »read list« eine Anzahl von Benutzern, die Nur-Lese-Zugriff auf das Share erhalten. Diese Einstellung würde selbst dann gelten, wenn das Verzeichnis insgesamt auf »writeable = yes« gesetzt wäre. Als Argument steht hier im Beispiel ein Gruppenname, kenntlich durch ein vorangestelltes @-Zeichen.

Als Besonderheit ist zu beachten, dass die Direktive »write list« stets Vorrang genießt. Das bedeutet, dass der Benutzer »kobold«, auch wenn er zur Gruppe »zwerge« gehört, sowohl Lese- als auch Schreibzugriffe auf das geschützte Verzeichnis ausführen darf. Eine potenziell gefährliche Besonderheit sind die »admin users«. Denn meldet sich ein Samba-Benutzer unter einer der dort genannten Kennungen an (im Beispiel »prinz«), hat er – ungeachtet seiner sonstigen Rechte als Linux-Benutzer – vollen Root-Zugriff auf alle Dateien und Unterverzeichnisse des Shares.

Die Share-Definition kann zwar komplett von Hand in die »smb.conf« geschrieben werden, Swat ist hier aber deutlich bequemer (Abbildung 2). Am besten wird dazu die »Advanced View« verwendet, die alle benötigten »Security Options« anzeigt und editieren lässt. Andere wichtige Direktiven für den täglichen Gebrauch sind im Kasten “Weitere »smb.conf«-Direktiven für … ” zusammengefasst.

Und sonst noch?

Mit den bisher gezeigten Techniken lassen sich die täglichen Aufgaben der Samba-Benutzerverwaltung im Wesentlichen lösen. Abschließend ein Blick auf einige seltener benötigte Features und neue Entwicklungen. Die Prüfung von Benutzerpasswörtern ist nicht nur gegen eine lokale »smbpasswd« oder einen zentralen Passwortserver möglich, sondern seit einiger Zeit auch mit Hilfe von PAM (Pluggable Authentication Modules) oder wahlweise auch LDAP (Lightweight Directory Access Protocol). Über diese Möglichkeiten, den laufenden Verwaltungsaufwand zu senken, informieren ausführlich zwei Howtos in der Samba-Dokumentation[1],[2].

Um Windows-Benutzernamen auf Linux-Benutzerkonten abzubilden, wird die Direktive

username map = /etc/samba/smbusers

in Verbindung mit der Datei »smbusers« genutzt. Das findet besonders oft Verwendung, um den Benutzer »Administrator« oder »Admin« mit Superuser-Rechten auszustatten. Die entsprechende Zeile in »/etc/samba/smbusers« ist:

root = administrator admin

Ähnliche Mappings sind für Gastzugänge üblich, die unter Windows oft als »guest« bezeichnet werden. (uwo)