Seit 1992 liefert Samba der freien Softwarewelt Unterstützung für SMB/CIFS und damit Zugang zur Windows-Welt der Datei- und Druckerteilung. Doch hinkt Samba der Funktionalität des Originals immer hinterher, was nicht am mangelnden Willen der Entwickler, sondern an der Geheimniskrämerei seitens Microsoft um ihre Client-Server-Protokolle liegt. Dafür kann Samba einige Tricks, die Windows nicht beherrscht. Wir zeigen, was geht und was nicht.
Mit NT4 Server hat Microsoft den PDC, den primären Domänen-Controller eingeführt. Ein Domänen-Controller ist ein Rechner, welcher zentral alle Benutzer-Accounts und Rechner in seinem Netz verwaltet. Jeder Arbeitsplatz muss von einem dazu berechtigten Administrator im Windows-Domänen-Netz (nicht zu verwechseln mit einer DNS-Domäne!) eingetragen werden. Damit «unterwirft» sich Windows auf dem Client dem Domänen-Controller, worauf dann letzterer sozusagen die absolute Kontrolle über den Client hat. Er bestimmt unter anderem, wer sich wann einloggen darf, wer welche Programme installieren darf oder wer was ausführen kann.
Bereits seit einiger Zeit kann Samba die Tätigkeiten eines PDC übernehmen. Der Code stammt vom Samba-TNG-Projekt, das sich vom ursprünglichen Samba-Projekt abgespalten hatte. Ziel dieses Fork war es, einen vollständigen Primary Domain Controller in Samba implementieren zu können. Grosse Teile der TNG-Sourcen sind inzwischen in das klassische Samba zurückgeflossen, sodass Samba aktuell durchaus einen Windows-PDC ersetzen kann.
Mit der Einführung von Windows 2000 Server hat Microsoft auch den Schritt in Richtung Directory Server (LDAP) gemacht und Active Directory, kurz AD, eingeführt. Mit AD hat ein Domänen-Administrator seine Workstations noch mehr unter Kontrolle. Selbst das Aussehen des Arbeitsplatzes, das Verhalten von einigen Programmen wie dem Internet Explorer, Anti-Viren-Software oder der Firewall kann er ebenso steuern wie die automatische Installation von Updates oder Microsoft-Programmen. Dass es sehr schwer ist, eine solche Funktionalität rein mit Reverse Engineering nachzubilden, leuchtet ein und ist der Grund, weshalb Samba-3.0.x-Versionen nicht als vollständiger Active-Directory-Server-Ersatz oder AD-Backup-Server verwendet werden können, auch wenn Samba sich grundsätzlich gegen LDAP authentifizieren kann.
Die Authentifizierung eines Windows Client in einer AD-Domäne erfolgt mittels Kerberos. Kerberos ist ein vom MIT entwickeltes Authentifizierungssystem zum Single-Sign-On. Ein Client meldet sich an den Kerberos-Server an und authentifiziert sich. War die Authentifizierung erfolgreich, bekommt der Client vom Kerberos-Server ein Ticket mit einer bestimmten Gültigkeitsdauer. Innerhalb dieser Gültigkeitsdauer kann sich der Client mit Hilfe seines Tickets an anderen Kerberos-fähigen Systemen anmelden und darauf zugreifen. Er muss sich nicht mehr mit Benutzername und Passwort anmelden. Ein «Vorzeigen» seines Tickets genügt.
Auch Samba 3.0.x ist Kerberos-fähig und kann mit den Tickets, die der AD-Server ausgestellt hat, umgehen. Dazu muss der Server, auf dem Samba läuft, in die Kerberos-Umgebung (Realm) aufgenommen werden und anschliessend der Samba-Dienst mit Hilfe eines Administrator-Accounts am Active Directory angemeldet werden. In der Konfigurationsdatei von Samba (smb.conf) sollte es genügen, folgende Zeilen zu ergänzen:
Umgekehrt bietet Samba auch die Möglichkeit, Windows-Benutzer auf Unix-Ebene bekanntzugeben. Damit werden unter Unix nicht bekannte Benutzer aus der Windows-Welt übernommen. Konfiguriert wird dieser zusätzliche Dämon namens winbind auch in der Samba-Konfigurationsdatei smb.conf. Man teilt winbind mit, in welchem UID- und GID-Bereich das Mapping auf Unix-User erfolgt:
idmap uid = 10000-20000
winbind gid = 10000-20000
Meldet sich nun ein Windows-Benutzer zum ersten Mal unter Unix an, mappt winbind seinen Numerical Relative Identifier (RID) aus der Windows-Welt auf die UID der Unix-Welt und merkt sich dann dieses Mapping in einer tdb-Datenbank. Analog dazu erfolgt das Mapping der Gruppen. Wichtig ist hierbei, dass ein freier UID/GID-Bereich verwendet wird, da sonst unter Umständen nicht berechtigte Benutzer auf Dateien anderer Zugriff haben könnten. Zum differenzierten Zugriff kann Samba auch noch die ACLs von NTFS auf POSIX-ACLs – sofern vom Betriebs- und Filesystem unterstützt – mappen, um Rechte und andere Dateiattribute auf das darunter liegende Unix-Dateisystem abzubilden. Allerdings sind Microsofts Dateiattribute umfangreicher, und somit können einige wenige und sehr selten benutzte Attribute nicht verwendet werden.
Auf Unix-Seite sollte mit NFS-Exporten von mit Samba exportierten Laufwerken vorsichtig umgegangen werden, da einige Unices keine ACLs über NFS beherrschen. In NFSv4 ist jedoch die komplette Abbildung von NTFS ACLs vorgesehen. Ausser Suns ZFS gibt es aber kein Unix-Dateisystem, welches mehr als die vom POSIX-Standard vorgesehenen ACLs unterstützt.
Das Unix-System muss noch wissen, wo es nebst /etc/passwd nach einem Benutzer suchen soll, was sich über die Datei /etc/nsswitch.conf erledigen lässt:
passwd: files winbind
shadow: files
group: files winbind
Hierbei sollte aber beachtet werden, dass bereits vorhandene Dienste wie LDAP nicht rausgelöscht werden. Ausserdem sollte die Reihenfolge der Einträge der Wahrscheinlichkeit eines Treffers entsprechen – files sollte aber trotzdem an erster Stelle stehen bleiben. Liegen die meisten Benutzer in einem LDAP-Verzeichnis und nur wenige sollen aus einem ADS Server übernommen werden, sollte der Eintrag winbind als letzter in der nsswitch.conf stehen.
Neben dem Verschmelzen verschiedener Plattformen bietet Samba für Unix-Anwender, wie bereits erwähnt, die eine oder andere praktische Möglichkeit.
Ein sehr grosser Vorteil, einen Samba-Server als Fileserver zu verwenden, ist die nahezu unerschöpfliche Möglichkeit an Aktionen, die beispielsweise bei einem Zugriff auf eine Datei oder bei der Anmeldung eines Benutzers erfolgen können. So ist es zum Beispiel möglich, beim Anmelden eines Benutzers zu überprüfen, ob ein Profilverzeichnis für Windows in seinem Home existiert oder ob der Benutzer vielleicht seine Quota überschritten hat, bevor der erste lesende oder schreibende Zugriff erfolgt ist. Denn Windows reagiert seltsam und undeterministisch, wenn es seine Daten in das Profilverzeichnis nicht oder nicht vollständig schreiben kann. Dies kann bei einer Überschreitung der Quota passieren. Mit dem genannten Mechanismus kann der Benutzer sofort informiert werden, noch bevor Windows überhaupt zugreift.
Auch lässt sich ein On-Demand Virenschutz (Anti-Virus-Software auf dem Server vorausgesetzt) realisieren. Greift ein Benutzer auf eine Datei zu, wird vom Samba-Server erst einmal ein Script mit einem Virencheck ausgeführt. Dies sollte für den Benutzer kaum merkbar sein – auch andere Fileserver wie Novell- oder Windows- Server verwenden einen ähnlichen Mechanismus. Ebenfalls liesse sich eine Datei, auf die ein Benutzer zugreifen will, just in diesem Moment vom Server erzeugen – etwa wenn ein Benutzer auf eine Word-Vorlage im Corporate Design zugreift und beispielsweise sein Name als Autor eingetragen werden soll.
All diese Aktionen werden mit der VFS-Schnittstelle (Virtual File System) realisiert. Diese definiert, wie Samba auf eine geteilte Datei zugreifen soll. In der Regel wird beim Zugriff direkt von der Platte gelesen. Mit Hilfe von VFS kann aber ein anderes Modul, Script oder Programm sozusagen zwischen Platte und Benutzerzugriff gelegt werden.
Der nächste grosse Meilenstein in der Samba-Entwicklung wird die Möglichkeit sein, mit Samba 4 (Bild) die Software als Domänen-Controller einer AD-Domäne einsetzen zu können – zumindest was die Authentifizierung betrifft. Zu diesem Zweck wird Samba 4 unter anderem einen eigenen Directory-Server sowie eine spezielle Kerberos-Implementierung mitbringen. Eine komplette Nachbildung der Funktionalität von Microsofts Active Diectory wird man nach jetzigem Stand aber nicht erwarten können. Wer also komplexere Szenarien oder komplizierte Benutzer-, Rechner- oder Programm-Policies braucht, wird wohl um einen Windows Server nicht herum kommen. Dafür kann mit Unterstützung für SMB2 von Windows Vista sowie vollständiger Unterstützung von NTFS ACLs und Alternate Data Streams gerechnet werden.
Gregor Longariva (longariva@softbaer.de) ist Solaris-Administrator am Rechenzentrum der Universität Erlangen-Nürnberg und Spezialist für die Unix-Betriebssysteme Solaris, OpenBSD und Linux.
