Samba, 
2. Auflage

Samba, 2. Auflage

Von Jay Ts, Robert Eckstein, and David Collier-Brown
2. Auflage, August 2003
O'Reilly Verlag, ISBN: 3-89721-359-1
www.oreilly.de/catalog/samba2ger/

Dieses Buch ist unter der GNU Free Documentation License (FDL) erschienen. Bitte beachten Sie den Text der GNU FDL.


TOC PREV NEXT INDEX

Kapitel 4

Windows NT-Domänen

In den vorangegangenen Kapiteln haben wir uns auf den Netzwerkbetrieb mit Arbeitsgruppen konzentriert, um die Dinge einfach zu halten und Ihnen Netzwerke mit Samba auf eine möglichst schmerzlose Weise näher bringen zu können. Das Arbeiten mit Arbeitsgruppen hat jedoch seine Nachteile. Für viele Computer-Umgebungen lohnen die größere Sicherheit und die einheitlichen Anmeldemöglichkeiten der Windows NT-Domäne den zusätzlichen Aufwand, den die Implementierung einer Domäne mit sich bringt.

Neben den Domäneneigenschaften, die in Kapitel 1 besprochen wurden, ermöglicht eine Domäne den Einsatz von Anmeldeskripten und Roaming-Profilen (auch als Roving-Profile bezeichnet). Ein Anmeldeskript ist eine Textdatei mit Befehlen, die während des Starts ausgeführt werden. Ein Profil stellt eine Sammlung von Informationen über die Desktop-Umgebung dar, einschließlich des Inhalts des Start-Menüs, der Symbole, die auf dem Desktop auftauchen, und anderer Charakteristika der grafischen Oberfläche, die von den Benutzern an ihre Wünsche angepasst werden können. Ein Roaming-Profil kann seinem Besitzer von Computer zu Computer folgen und lässt diesen dadurch immer in seiner vertrauten Umgebung arbeiten, unabhängig davon, von welchem Rechner er sich anmeldet.

Eine Windows NT-Domäne bietet zentralisierte Kontrolle über das Netzwerk. Von einem Administrator können Richtlinien eingerichtet werden, um Aspekte der Umgebung des Benutzers zu definieren und die Kontrolle zu begrenzen, die dieser über das Netzwerk und dessen Computer haben kann. Administratoren können auch von jeder Windows NT/2000/XP-Workstation eine Fernwartung der Domänen-Controller durchzuführen.

Samba 2.2 besitzt die Fähigkeit, als primärer Domänen-Controller zu agieren, wobei es Domänenanmeldungen von Windows 95/98/Me/NT/2000/XP-Computern unterstützt und es Windows NT/2000/XP1-Systemen erlaubt, der Domäne als Domänen-Member-Server beizutreten. Samba kann einer Domäne ebenfalls als Member-Server beitreten. Damit kann der primäre Domänen-Controller ein Windows NT/2000-System oder ein anderer Samba-Server sein.


Samba 2.2 unterstützt keine LDAP- und Kerberos-Authentifizierung für Active Directory, es kann also nicht als Windows 2000-Active Directory-Domänen-Controller arbeiten. Samba kann allerdings als Member-Server in eine Active Directory-Domäne aufgenommen werden, wobei die Windows 2000-Domänen-Controller entweder im Mixed oder im Native Mode laufen. Der Windows 2000-Server unterstützt (selbst wenn er im Native Mode läuft) den Samba-Server, indem er als PDC-Emulator arbeitet und an Stelle der Authentifizierung im Kerberos-Stil eine Authentifizierung im Windows NT-Stil einsetzt.

Wenn Sie einen Samba-Server in ein Netzwerk einfügen, das bereits eingerichtet ist, müssen Sie nicht entscheiden, ob Sie eine Arbeitsgruppe oder eine Domäne benutzen - es muss einfach nur kompatibel zu dem sein, was bereits vorhanden ist. Falls Sie jedoch die Wahl haben, empfehlen wir Ihnen, sowohl die Arbeitsgruppen- als auch die Domänenlösung sorgfältig zu untersuchen, bevor Sie mit einer großen Installation beginnen. Es macht eine Menge Arbeit, später von der einen zur anderen Variante zu wechseln. Zu guter Letzt sollten Sie auch noch die Tatsache bedenken, dass Microsoft bei der Entwicklung von Windows ebenfalls vermehrt auf Domänen setzt und plant, Windows-Netzwerke irgendwann ausschließlich aus Active Directory-Domänen aufzubauen. Falls Sie jetzt eine Windows NT-Domäne implementieren, werden Sie es später leichter haben, auf Active Directory umzusteigen, wenn Samba eine bessere Unterstützung dafür bietet.

In diesem Kapitel behandeln wir verschiedene Themen, die direkt mit dem Einsatz von Samba in einer Windows NT-Domäne zu tun haben. Dazu gehören folgende Bereiche:

Samba als primärer Domänen-Controller

Samba 2.2 ist in der Lage, die meisten gewünschten Funktionen eines primären Domänen-Controllers in einer Windows NT-Domäne anzubieten, Domänenanmeldungen und Authentifizierung für den Zugriff auf freigegebene Ressourcen zu erledigen sowie Anmeldeskripten, Roaming-Profile und Systemrichtlinien zu unterstützen.


Sie müssen wenigstens Samba 2.2 einsetzen, um sicherzustellen, dass die PDC-Funktionalität für Windows NT/2000/XP-Clients vorhanden ist. Vor Samba 2.2 gab es nur eine eingeschränkte Benutzer-Authentifizierung für NT-Clients.

In diesem Abschnitt werden wir Ihnen zeigen, wie Sie Samba als PDC für den Einsatz mit Windows 95/98/Me- und Windows NT/2000/XP-Clients konfigurieren. Die beiden Gruppen von Windows-Versionen interagieren unterschiedlich in Domänen und werden in einigen Fällen auf etwas unterschiedliche Weise unterstützt. Wenn Sie wissen, dass Sie nur Windows 95/98/Me oder nur Windows NT/2000/XP einsetzen werden, können Sie Samba so einrichten, dass nur die entsprechende Gruppe unterstützt wird. Es schadet jedoch auch nicht, beide gleichzeitig zu unterstützen.


Wenn Sie mehr Informationen über das Einrichten von Domänen haben wollen, schauen Sie sich einmal die Datei Samba-PDC-HOWTO.html im Verzeichnis docs/htmldocs der Samba-Quelldistribution an.

Samba muss der einzige Domänen-Controller dieser Domäne sein. Stellen Sie sicher, dass nicht bereits ein PDC aktiv ist und dass es keine Backup-Domänen-Controller (Backup Domain Controller; BDC) gibt. Samba 2.2 ist nicht in der Lage, mit Backup-Domänen-Controllern zu kommunizieren. Hätten Sie nun Domänen-Controller in Ihrer Domäne, die ihre Daten nicht miteinander abgleichen, wäre Ihr Netzwerk nicht funktionsfähig.


Samba 2.2 kann zwar nicht als Windows NT-BDC agieren bzw. mit einem Windows NT-BDC zusammenarbeiten, es ist jedoch möglich, einen anderen Samba-Server als Sicherung für einen Samba-PDC einzurichten. Nähere Informationen finden Sie in der Datei Samba-BDC-HOWTO.html im Verzeichnis docs/htmldocs der Samba-Quelldistribution.

Um Samba als PDC zu konfigurieren, müssen die Datei smb.conf verändert, einige Verzeichnisse angelegt und der Server neu gestartet werden.

Modifizieren der Datei smb.conf

Sie beginnen zunächst mit einer smb.conf-Datei, die Samba korrekt für den Arbeitsgruppenbetrieb einrichtet. Eine solche Datei haben wir in Kapitel 2 erstellt. Dort fügen Sie folgende Zeilen in den Abschnitt [global] ein:

[global]
 
	; verwenden Sie an Stelle von toltec den Namen Ihres Samba-Servers
 
	; und an Stelle von METRAN den Namen Ihrer Arbeitsgruppe
 
	netbios name = toltec
 
	workgroup = METRAN
 
	encrypt passwords = yes
 
		
 
	domain master = yes
 
	local master = yes
 
	preferred master = yes
 
	os level = 65
 

 
	security = user
 
	domain logons = yes
 
	
 
	; logon path teilt Samba mit, wo die Windows NT/2000/XP-Roaming-Profile abgelegt werden
 
	logon path = \\%L\profiles\%u\%m
 
	logon script = logon.bat
 

 
	logon drive = H:
 
	; logon home wird verwendet, um das Home-Verzeichnis sowie den Ablageort
 
	; der Windows 95/98/Me-Roaming-Profile festzulegen
 
	logon home = \\%L\%u\.win_profile\%m
 
	
 
	time server = yes
 

 
	; an Stelle von jay verwenden Sie die Namen der Benutzer in der Windows NT/2000/XP-
 
	; Gruppe Administratoren, die sich an der Domäne anmelden
 
	domain admin group = root jay
 

 
	; der folgende Befehl funktioniert bei Red Hat Linux - andere Betriebssysteme 

	; benötigen möglicherweise einen anderen Befehl
 
	add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u
 

Fügen Sie nach dem Abschnitt [global] diese drei neuen Freigaben ein:

[netlogon]
 
	path = /usr/local/samba/lib/netlogon
 
	writable = no
 
	browsable = no
 

 
[profiles]
 
	; möglicherweise verwenden Sie ein anderes Verzeichnis für Ihre
 
	; Windows NT/2000/XP-Roaming-Profile
 
	path = /home/samba-ntprof
 
	browsable = no
 
	writable = yes
 
	create mask = 0600
 
	directory mask = 0700
 

 
[homes]
 
	read only = no
 
	browsable = no
 
	guest ok = no
 
	map archive = yes
 

Jetzt die Erklärung. Wenn Sie dieses Beispiel mit der Konfigurationsdatei aus Kapitel 2 vergleichen, werden Sie feststellen, dass die ersten drei Parameter-Einstellungen ähnlich sind. Wir beginnen im Abschnitt [global] mit dem Setzen des NetBIOS-Namens des Samba-Servers. Wir verwenden den voreingestellten Namen - das ist der DNS-Hostname -, geben ihn jedoch explizit an, da der NetBIOS-Name in UNCs verwendet wird, die weiter hinten in smb.conf auftauchen. Die beiden nächsten Zeilen, die den Arbeitsgruppennamen festlegen und den Einsatz verschlüsselter Kennwörter bestimmen, sind identisch mit der smb.conf-Datei aus Kapitel 2. Allerdings liegen die Dinge jetzt ein wenig anders: Es steht zwar immer noch »workgroup« (Arbeitsgruppe) da, tatsächlich setzen wir jedoch den Namen der Domäne. Für eine Arbeitsgruppe wäre die Benutzung verschlüsselter Kennwörter optional; beim Einsatz einer Domäne sind sie dagegen notwendig.

Die nächsten vier Zeilen weisen den Samba-PDC an, die Suchdienste einzusetzen. Die Zeile domain master = yes macht Samba zum Domänen-Hauptsuchdienst, der den Suchdienst für die Domäne über die Grenzen mehrerer Subnetze hinweg ausführt, falls dies erforderlich sein sollte. Trotz gewisser Ähnlichkeiten veranlasst die Option local master = yes Samba nicht, der Hauptsuchdienst in dem Subnetz zu sein, sondern weist es lediglich an, an Suchdienstwahlen teilzunehmen und diese gewinnen zu können. (Diese beiden Zeilen sind eigentlich Standardeinstellungen, die wir aus Gründen der Klarheit hinzufügen.) Die nächsten beiden Zeilen stellen sicher, dass Samba die Wahlen gewinnt. Der Parameter preferred master veranlasst Samba, beim Start eine Wahl zu erzwingen. Der Wert des Parameters os level ist höher als der aller anderen Systeme, wodurch Samba diese Wahl gewinnt. (Zum Zeitpunkt des Schreibens dieses Buches war ein os-Level von 65 ausreichend, um alle Windows-Versionen auszustechen - achten Sie allerdings darauf, dass kein anderer Samba-Server höher liegt!) Wir sorgen dafür, dass Samba sowohl der Domänen- als auch der lokale Hauptsuchdienst ist, da Windows NT/2000-PDCs die Rolle des Domänen-Hauptsuchdiensts immer für sich reservieren und Windows-Clients die Dinge immer in diesem Zustand vorzufinden erwarten, um den primären Domänen-Controller zu finden. Es ist auch möglich, einem anderen Computer im Netzwerk zu erlauben, die Rolle des lokalen Hauptsuchdiensts zu übernehmen, allerdings ist es einfacher und effizienter, wenn der gleiche Server als Domänen- und lokaler Hauptsuchdienst fungiert.

Die nächsten beiden Zeilen im Abschnitt [global] sorgen dafür, dass Samba die eigentlichen Domänenanmeldungen erledigt. Wir setzen security = user, Samba verlangt also einen Benutzernamen und ein Kennwort. Tatsächlich ist dies identisch mit den Einstellungen für die Arbeitsgruppe, die wir in den Kapiteln 1 und 2 behandelt haben, denn dies ist die Voreinstellung. Wir fügen es nur deshalb explizit ein, um Verwirrung zu vermeiden. Eine andere gültige Einstellung ist security = domain, allerdings dient diese Einstellung dazu, dass ein anderer (Windows- oder Samba-)Domänen-Controller die Anmeldungen verarbeitet; sie sollte niemals in der smb.conf eines Samba-PDC zu finden sein. Die nächste Zeile, domain logons = yes, gibt Samba dann an, dass dieser Server Domänenanmeldungen erledigt.

Das Definieren eines Anmeldepfads ist notwendig, um Roaming-Profile für Windows NT/2000/XP-Clients zu unterstützen. Die UNC \\%L\profiles\%u bezieht sich auf eine Freigabe auf dem Samba-Server, in der die Profile abgelegt sind. Die Variablen %L und %u werden von Samba durch den Namen des Servers bzw. den Benutzernamen des angemeldeten Benutzers ersetzt. Der Abschnitt in smb.conf, der die [profiles]-Freigabe definiert, enthält die genaue Angabe darüber, wo die Profile auf dem Server abgelegt sind. Wir werden weiter unten in diesem Kapitel auf dieses Thema zurückkommen.

Die Zeile logon script = logon.bat gibt den Namen einer MS-DOS-Batch-Datei an, die ausgeführt wird, wenn der Client sich an der Domäne anmeldet. Der hier festgelegte Pfad ist relativ zur [netlogon]-Freigabe, die später in der Datei smb.conf definiert wird.

Die Einstellungen logon drive und logon home verfolgen mehrere Zwecke. Wenn Sie logon drive = H: setzen, kann das Home-Verzeichnis des Benutzers mit dem Laufwerkbuchstaben H: auf dem Client verknüpft werden. Der Parameter logon home wird auf den Ablageort des Home-Verzeichnisses auf dem Server gesetzt, und auch hier wird %u zur Laufzeit durch den Benutzernamen des angemeldeten Benutzers ersetzt. Das Home-Verzeichnis dient dazu, die Roaming-Profile für Windows 95/98/Me-Clients zu speichern. Diese Parameter sind mit der Freigabe [homes], die wir hinzufügen, verknüpft, wie wir noch erläutern werden.

Durch time server = yes wird Samba veranlasst, sich selbst als Time-Service für das Netzwerk bekannt zu machen. Dies ist optional.

Der Parameter domain admin group dient in Samba 2.2 dazu, Samba eine Liste der Benutzer zu übergeben, die in der Domäne über administrative Rechte verfügen. Die Liste sollte alle Samba-Benutzer enthalten, die sich von Windows NT/2000/XP-Systemen aus anmelden und Mitglieder der Gruppen der Administratoren oder Domänen-Administratoren sind, falls Roaming-Profile korrekt funktionieren sollen.

Der letzte Parameter, der in den Abschnitt [global] eingefügt werden soll, ist add user script. Diesen benötigen Sie nur, wenn einer oder mehrere Ihrer Clients ein Windows NT/2000/XP-System ist. Im Abschnitt »Anlegen von Computerzugängen« weiter unten in diesem Kapitel werden wir Ihnen mehr zu diesem Thema sagen.

Die restlichen Ergänzungen zu smb.conf sind die Definitionen für drei Freigaben. Die Freigabe [netlogon] ist notwendig, damit Samba Domänenanmeldungen verarbeiten kann, da Windows-Clients während des Anmeldevorgangs eine Verbindung dorthin herstellen müssen und die Anmeldung fehlschlägt, wenn die Freigabe nicht existiert. Abgesehen davon, besteht die einzige Aufgabe von [netlogon] darin, als Speicher für Anmeldeskripten und Systemrichtliniendateien zu fungieren, auf die wir später noch genauer eingehen. Der Pfad zu einem Verzeichnis auf dem Samba-Server wird vorgegeben, und da die Clients die Anmeldeskripten und Systemrichtliniendateien von der Freigabe nur lesen, wird die Freigabe durch die Definition writable = no mit einem Schreibschutz versehen. Die Benutzer müssen die Freigabe nicht sehen. Setzen Sie also den Parameter browsable = no, damit die Freigabe unsichtbar wird.

Die Freigabe [profiles] wird im Zusammenhang mit Windows NT/2000/XP-Roaming-Profilen benötigt. Der Pfad verweist auf ein Verzeichnis auf dem Samba-Server, in dem die Profile abgelegt werden. In diesem Fall müssen die Clients in der Lage sein, die Profildaten zu lesen und zu schreiben. Die Parameter create mask (das Lesen und Schreiben ist nur für den Eigentümer erlaubt) und directory mask (das Lesen, Schreiben und Durchsuchen ist nur für den Eigentümer erlaubt) werden so eingestellt, dass die Profildaten eines Benutzers nur von dem Benutzer gelesen und geschrieben werden können und kein anderer darauf zugreifen oder sie verändern kann.

Die Freigabe [homes] ist notwendig, damit die Definitionen von logon drive und logon home funktionieren. Samba verwendet die Freigabe [homes], um das Home-Verzeichnis des Benutzers (das in /etc/passwd  zu finden ist) als Freigabe hinzuzufügen. Die Freigabe erscheint nicht als »homes«, sondern kann auf dem Client über einen Ordner mit dem gleichen Namen wie der Benutzername des Benutzers zugegriffen werden. Wir werden dieses Thema in Kapitel 9 ausführlicher behandeln.

An dieser Stelle könnten Sie testparm ausführen, um Ihre smb.conf-Datei zu prüfen.

Verzeichnisse auf dem Samba-Server anlegen

Die Freigaben [netlogon] und [profiles], die nun in der neuen smb.conf-Datei definiert sind, verweisen auf Verzeichnisse auf dem Samba-Server. Es ist notwendig, diese Verzeichnisse mit den entsprechenden Rechten anzulegen:

# mkdir /usr/local/samba/lib/netlogon
 
# chmod 775 /usr/local/samba/lib/netlogon
 
# mkdir /home/samba-ntprof
 
# chmod 777 /home/samba-ntprof
 

Die verwendeten Verzeichnisnamen sind lediglich Beispiele. Sie können selbstverständlich Ihre eigenen Namen wählen.

Den Samba-Server neu starten

Nun muss nur noch der Samba-Server neu gestartet werden, und die Änderungen treten in Kraft:

# /etc/rc.d/init.d/smb restart
 

(Verwenden Sie diesen Befehl oder eine andere für Ihr System passende Methode, wie in Kapitel 2 ausgeführt.) Der Server ist nun bereit, Domänenanmeldungen zu akzeptieren.

Anlegen von Computerzugängen

Um in einer Domäne interagieren zu können, muss ein Windows NT/2000/XP-System Mitglied der Domäne sein. Die Domänenmitgliedschaft wird über Computerzugänge implementiert, die Benutzerzugängen ähneln und es einem Domänen-Controller erlauben, Informationen zu speichern, mit denen sich Computer am Netzwerk authentifizieren. Das bedeutet, der Domänen-Controller muss in der Lage sein festzustellen, ob Anfragen, die von einem Computer kommen, von einem Computer stammen, von dem er »weiß«, dass dieser Teil der Domäne ist. Jedes Windows NT/2000/XP-System in der Domäne besitzt einen Computerzugang in der Datenbank des Domänen-Controllers, bei der es sich in einer von Windows NT/2000 verwalteten Domäne um die SAM-Datenbank handeln würde. Samba verwendet zwar einen anderen Ansatz (bei dem die Datei smbpasswd beteiligt ist), es behandelt jedoch Computerzugänge ähnlich wie Benutzerzugänge.

Um einen Computerzugang zu erzeugen, konfiguriert ein Administrator ein Windows NT/2000/XP-System so, dass es Teil der Domäne wird. Bei Samba 2.2 ist der »Domänen-Administrator« der root-Zugang auf dem Samba-Server. Sie müssen folgenden Befehl ausführen:

# smbpasswd -a root
 

um den root-Benutzer in die Kennwortdatenbank von Samba einzufügen. Geben Sie in diesem Fall bei smbpasswd nicht das gleiche Kennwort an wie bei dem eigentlichen root-Zugang auf dem Server. Erzeugen Sie stattdessen ein anderes Kennwort, das ausschließlich für das Anlegen von Computerzugängen verwendet wird. Dies verringert die Wahrscheinlichkeit, dass das root-Kennwort herausgefunden werden kann.

Beim Anlegen des Computerzugangs geschehen auf dem Samba-Server zwei Dinge. Der Datei smbpasswd wird ein Eintrag hinzugefügt, der einen »Benutzernamen« zeigt, bei dem es sich um den NetBIOS-Namen des Computers mit einem angehängten Dollar-Zeichen ($) handelt. Dieser Teil wird vom Befehl smbpasswd erledigt. Die müssen dafür nichts tun.

Bei Samba 2.2 ist außerdem ein Eintrag in der Datei /etc/passwd erforderlich2, um dem Computerzugang eine Benutzer-ID (UID) auf dem Samba-Server zu geben. Dieser Zugang wird niemals für eine Anmeldung am Unix-System verwendet, er sollte also auch kein gültiges Home-Verzeichnis und keine gültige Login-Shell erhalten. Damit dieser Teil funktioniert, müssen Sie den Parameter add user script in Ihrer Samba-Konfigurationsdatei setzen. Dazu verwenden Sie einen Befehl, der den Eintrag in der richtigen Weise anlegt. Auf unserem Red Hat Linux-System setzen wir add user script auf:

/usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u
 

Dieser Befehl fügt einen Eintrag in /etc/passwd ein, der ähnlich dem folgenden Eintrag ist:

aztec$:x:505:100::/dev/null:/bin/false
 

Beachten Sie auch hier, dass der Benutzername mit einem Dollar-Zeichen endet. Der gezeigte Benutzerzugang hat das »Home-Verzeichnis« /dev/null, die Gruppen-ID (GID) 100 und die »Login-Shell« /bin/false. Das Flag -M in unserem useradd-Befehl verhindert das Anlegen des Home-Verzeichnisses. Samba ersetzt die Variable %u im Befehl useradd durch den NetBIOS-Namen des Computers, einschließlich des abschließenden Dollar-Zeichens. Der Grundgedanke dahinter ist, einen Eintrag mit einem gültigen Benutzernamen und einer gültigen UID zu erzeugen. Dies sind die einzigen Teile, die Samba benutzt. Es ist wichtig, dass die UID einmalig ist und nicht für andere Zugänge benutzt wird - vor allem nicht für solche, die mit Samba-Benutzern verknüpft sind.

Falls Sie eine andere Unix-Variante benutzen, müssen Sie den Befehl useradd durch einen Befehl ersetzen, der auf Ihrer Plattform die gleiche Funktion ausführt. Gibt es auf Ihrem System keinen Befehl wie useradd, können Sie sich auch ein Shell-Skript schreiben, das diese Aufgabe erledigt. In jedem Fall sollte der Befehl einen Kennwort-Hash hinzufügen, der nicht mit einem gültigen Kennwort korrespondiert. In der Datei /etc/shadow unseres Linux-Servers finden wir beispielsweise die folgenden beiden Zeilen:

jay:%1%zQ7j7ok8$D/IubyRAY5ovM3bTrpUCn1:11566:0:99999:7:::
 
zapotec$:!!:11625:0:99999:7:::
 

Die erste Zeile ist für den Benutzerzugang von jay. Das zweite Feld zeigt den Kennwort-Hash-Wert - das ist der lange String zwischen dem ersten und dem zweiten Doppelpunkt. Die zweite Zeile ist für den Computerzugang von zapotec, einem Domänen-Member-Server. Sein »Benutzername« endet mit einem Dollar-Zeichen ($), und das zweite Feld wurde in diesem Fall auf »!!« gesetzt. Dabei handelt es sich um einen beliebigen String, der nicht von einem Kennwort erzeugt wurde. Daher gibt es für diesen Zugang auf dem Linux-Host kein gültiges Kennwort. Praktisch jeder ASCII-String kann an Stelle von »!!« verwendet werden. Sie könnten beispielsweise stattdessen »DEAKTIVIERT« einsetzen.


Es ist möglich, die Einträge für /etc/passwd und smbpasswd manuell zu erzeugen. Allerdings empfehlen wir, diese Methode nur sehr sorgfältig und nur für erste Tests oder als letzten Ausweg einzusetzen. Der Grund dafür ist, dass die Sicherheit gewahrt bleiben muss. Wenn ein Computerzugang auf dem Server erzeugt worden ist, wird das nächste Windows NT/2000/XP-System im Netzwerk mit einem passenden NetBIOS-Namen zum Anmelden an der Domäne mit diesem Zugang verknüpft. Dies bietet Crackern eine Möglichkeit, Computerzugänge für ihre eigenen Zwecke zu missbrauchen.

Windows-Clients für Domänen-Anmeldungen konfigurieren

Die clientseitige Konfiguration für Windows-Clients ist wirklich einfach. Sie müssen lediglich vom Arbeitsgruppen- auf den Domänenbetrieb umstellen, indem Sie Domänenanmeldungen aktivieren und im Fall von Windows NT/2000/XP noch das root-Kennwort angeben, das Sie smbpasswd zum Erzeugen von Computerzugängen übergeben haben. Dadurch wird das Windows NT/2000/XP-System ein Mitglied der Domäne.

Windows 95/98/Me

Um Domänenanmeldungen für Windows 95/98/Me zu aktivieren, öffnen Sie die Systemsteuerung und doppelklicken auf das Netzwerk-Symbol. Klicken Sie dann auf Client für Microsoft-Netzwerke und anschließend auf Eigenschaften. An dieser Stelle sollten Sie einen Dialog ähnlich dem aus Abbildung 4-1 sehen. Markieren Sie das Optionsfeld An Windows NT-Domäne anmelden im oberen Bereich des Dialogfelds und geben Sie den Namen der Domäne so ein, wie Sie ihn im Parameter workgroup der Samba-Konfigurationsdatei angegeben haben. Klicken Sie dann auf OK und starten Sie den Rechner neu, wenn Sie dazu aufgefordert werden.
Abbildung 4-1
Einen Windows 95/98-Client für Domänenanmeldungen konfigurieren


Falls Windows sich darüber beschwert, dass Sie bereits an der Domäne angemeldet sind, haben Sie vermutlich schon eine aktive Verbindung zu einer Freigabe in der Arbeitsgruppe (wie etwa ein zugewiesenes Netzlaufwerk). Heben Sie die Verbindung zur Ressource einfach zeitweilig auf, indem Sie mit der rechten Maustaste auf ihr Symbol klicken und den Menüeintrag Trennen wählen.

Wenn Windows neu startet, sollten Sie den normalen Anmeldedialog mit einem Zusatz sehen: einem Feld für eine Domäne. Der Name der Domäne müsste schon ausgefüllt sein, geben Sie einfach nur noch Ihr Kennwort ein und klicken Sie auf OK. An dieser Stelle kontaktiert Windows den primären Domänen-Controller (Samba), um festzustellen, ob das Kennwort korrekt ist. (Sie können diesen Vorgang in den Protokolldateien nachvollziehen.) Wenn das alles geschehen ist, gratulieren wir! Sie haben Samba für den Einsatz als Domänen-Controller für Windows 95/98/Me-Maschinen richtig konfiguriert, und Ihr Client hat sich erfolgreich angemeldet.

Sicherheit auf Benutzerebene für Windows 95/98/Me

Nachdem Sie nun einen primären Domänen-Controller zum Authentifizieren von Benutzern haben, können Sie eine viel größere Sicherheit für Freigaben implementieren, die sich auf Windows 95/98/Me-Systemen befinden.3 Um diese Funktionalität zu aktivieren, öffnen Sie die Systemsteuerung, doppelklicken auf das Netzwerk-Symbol und klicken im Dialogfeld auf die Registerkarte Zugriffssteuerung. Das Fenster müsste nun so aussehen wie das in Abbildung 4-2.
Abbildung 4-2
Einrichten der Zugriffskontrolle auf Benutzerebene

Klicken Sie auf den Radio-Button Zugriffssteuerung auf Benutzerebene und geben Sie den Namen Ihrer Domäne in den Eingabebereich ein. Klicken Sie auf den OK-Button. Falls Sie den Dialog aus Abbildung 4-3 sehen, gibt es auf dem System bereits Freigaben.
Abbildung 4-3
Fehlerdialog beim Ändern der Zugriffssteuerung auf Benutzerebene

In diesem Fall sollten Sie den Vorgang abbrechen und einen Vermerk über die einzelnen Freigaben des Computers anlegen, um das erneute Freigeben dieser Ressourcen zu erleichtern. Anschließend wiederholen Sie diesen Teil. (Um eine Liste der Freigaben zu erhalten, starten Sie die MS-DOS-Eingabeaufforderung und führen den Befehl net view \\Computername aus.) Ansonsten erhalten Sie eine Meldung, die Sie bittet, den Rechner neu zu starten, damit die Änderungen an der Konfiguration wirksam werden.

Nach dem Neustart können Sie Freigaben mit einer Zugriffssteuerung auf Benutzerebene erzeugen. Dazu klicken Sie mit der rechten Maustaste auf den Ordner, den Sie freigeben wollen, und wählen Freigabe... Dadurch öffnet sich der Dialog Eigenschaften von Freigabe, der in Abbildung 4-4 zu sehen ist.
Abbildung 4-4
Das Dialogfeld Eigenschaften von Freigabe

Klicken Sie auf den Radio-Button Freigegeben als: und weisen Sie der Freigabe einen Namen sowie einen Kommentar zu. Klicken Sie anschließend auf den Button Hinzufügen... Sie sehen das Dialogfeld Benutzer hinzufügen, das in Abbildung 4-5 dargestellt wird.
Abbildung 4-5
Das Dialogfeld Benutzer hinzufügen

Was ist geschehen? Windows hat den primären Domänen-Controller (in diesem Fall Samba) kontaktiert und eine Liste der Domänenbenutzer und -gruppen angefordert. Sie können nun einen Benutzer oder eine Gruppe auswählen und sie zu einer oder mehreren der drei Listen auf der rechten Seite des Fensters - Schreibgeschützt, Alle Zugriffsrechte oder Benutzerdefiniert - hinzufügen, indem Sie auf die Buttons in der Mitte des Fensters klicken. Wenn Sie fertig sind, klicken Sie auf OK. Haben Sie Benutzer oder Gruppen auf die Benutzerdefiniert-Liste gesetzt, wird Ihnen der Dialog Zugriffsrechte ändern präsentiert, der in Abbildung 4-6 zu sehen ist. Darin können Sie die Rechte festlegen, die Sie gewähren wollen. Klicken Sie dann auf OK, um den Dialog zu schließen.
Abbildung 4-6
Das Dialogfeld Zugriffsrechte ändern

Sie kehren nun zum Dialog Eigenschaften von Freigabe zurück, worin die Spalten Name: und Zugriffsrechte: mit den Rechten ausgefüllt sind, die Sie gerade erzeugt haben. Klicken Sie auf ok, um den Vorgang abzuschließen. Denken Sie daran, dass Sie diese Aktion für alle Ordner ausführen müssen, die Sie zuvor mit Sicherheit auf Freigabeebene freigegeben hatten.

Windows NT 4.0

Um Windows NT für Domänenanmeldungen zu konfigurieren, melden Sie sich am Computer als Administrator oder als ein anderer Benutzer aus der Gruppe der Administratoren an, öffnen die Systemsteuerung und doppelklicken auf das Netzwerk-Symbol. Wählen Sie das Register Identifikation, falls dieses nicht bereits ausgewählt ist.

Klicken Sie auf den Button Ändern... Sie sollten nun den Dialog aus Abbildung 4-7 sehen. Darin können Sie festlegen, dass der Windows NT-Client ein Mitglied der Domäne wird, indem Sie auf das Optionsfeld Domäne: im Feld Mitglied von klicken. Geben Sie dann den Namen der Domäne ein, an der sich der Client anmelden können soll. Dies muss der gleiche Name sein wie der, den Sie mit Hilfe des Parameters workgroup in der Samba-Konfigurationsdatei festgelegt haben. Klicken Sie auf das Optionsfeld Computerkonto in der Domäne erstellen und setzen Sie im Texteingabefeld Benutzername: die Bezeichnung »root« ein. In das Feld Kennwort: schreiben Sie das root-Kennwort, das Sie bei smbpasswd zum Erzeugen von Computerzugängen angegeben haben.
Abbildung 4-7
Einen Windows NT-Client für Domänenanmeldungen konfigurieren


Falls Windows sich darüber beschwert, dass Sie bereits angemeldet sind, haben Sie vermutlich schon eine aktive Verbindung zu einer Freigabe in der Arbeitsgruppe (wie etwa ein zugewiesenes Netzlaufwerk). Heben Sie die Verbindung zur Ressource einfach zeitweilig auf, indem Sie mit der rechten Maustaste auf ihr Symbol klicken und den Menüeintrag Trennen wählen.

Wenn Sie auf den OK-Button geklickt haben, sollte Windows ein kleines Dialogfeld präsentieren, das Sie an der Domäne willkommen heißt. Klicken Sie auf den Schließen-Button im Netzwerk-Dialog und starten Sie den Computer auf Aufforderung neu. Sobald das System wieder gestartet ist, zeigt Ihnen die Maschine automatisch ein Anmeldefenster ähnlich dem für Windows 95/98/Me-Clients, mit der Ausnahme, dass der Domänen-Eingabebereich ein Drop-down-Menü besitzt, so dass Sie sich entscheiden können, ob Sie sich am lokalen System oder an der Domäne anmelden. Achten Sie darauf, dass Ihre Domäne ausgewählt ist, und melden Sie sich mit einem für Samba aktivierten Benutzerzugang auf dem Samba-Server an der Domäne an.


Passen Sie auf, dass Sie auch die richtige Domäne im Windows NT-Anmeldedialog ausgewählt haben. Nach dem Auswählen dauert es möglicherweise eine Weile, bis Windows NT eine Liste der verfügbaren Domänen zusammengestellt hat.

Nach der Eingabe des Kennworts muss Windows NT beim primären Domänen-Controller (Samba) prüfen, ob das Kennwort stimmt. Auch diese Aktion können Sie mit Hilfe der Protokolldateien nachvollziehen. Hat es funktioniert, haben Sie Samba erfolgreich dazu konfiguriert, als Domänen-Controller für Windows NT-Maschinen zu arbeiten.

Windows 2000

Um Windows 2000 für Domänenanmeldungen zu konfigurieren, melden Sie sich am Computer als Administrator oder als ein anderer Benutzer aus der Gruppe der Administratoren an. Öffnen Sie dann die Systemsteuerung und doppelklicken Sie auf das System-Symbol, um die Dialogbox Eigenschaften von System zu öffnen. Klicken Sie auf die Registerkarte Netzwerkidentifikation und anschließend auf den Button Eigenschaften. Sie sollten nun den Dialog Änderungen der Benutzerinformationen sehen, der in Abbildung 4-8 dargestellt wird.
Abbildung 4-8
Der Dialog Änderungen der Benutzerinformationen

Klicken Sie auf den Radio-Button mit der Bezeichnung Domäne: und setzen Sie den Namen Ihrer Domäne in den Texteingabebereich ein. Klicken Sie dann auf ok. Dadurch wird der Dialog Benutzername und Kennwort der Domäne geöffnet. Geben Sie als Benutzernamen »root« ein. Als Kennwort verwenden Sie das Kennwort, das Sie smbpasswd für den root-Zugang übergeben haben.


Falls Windows sich darüber beschwert, dass Sie bereits angemeldet sind, haben Sie vermutlich schon eine aktive Verbindung zu einer Freigabe in der Arbeitsgruppe (wie etwa ein zugewiesenes Netzlaufwerk). Heben Sie die Verbindung zur Ressource einfach zeitweilig auf, indem Sie mit der rechten Maustaste auf ihr Symbol klicken und den Menüeintrag Trennen wählen.

Nachdem Sie den OK-Button angeklickt haben, sollte Windows Ihnen ein kleines Dialogfeld präsentieren, mit dem Sie an der Domäne willkommen geheißen werden. Nach einem Klick auf den OK-Button in diesem Dialog wird Ihnen mitgeteilt, dass Sie den Computer neu starten müssen. Klicken Sie auf den OK-Button im Dialog Eigenschaften von System und starten Sie wie angewiesen den Computer neu. Sobald das System wieder hochgefahren ist, präsentiert die Maschine Ihnen einen Dialog zum Anmelden an Windows ähnlich dem in Abbildung 4-9.
Abbildung 4-9
Das Windows 2000-Anmeldefenster

Falls Sie das Anmelden an:-Drop-down-Menü nicht sehen können, klicken Sie auf den Button Optionen <<. Das Menü erscheint daraufhin. Wählen Sie aus dem Menü an Stelle des lokalen Computers Ihre Domäne.


Achten Sie darauf, dass Sie im Anmeldedialog die richtige Domäne auswählen. Wenn Sie gewählt haben, dauert es möglicherweise einen Moment, bis Windows die Liste der verfügbaren Domänen zusammengestellt hat.

Geben Sie den Benutzernamen und das Kennwort eines für Samba aktivierten Benutzers in die Felder Benutzername: und Kennwort: ein und drücken Sie entweder die Enter-Taste oder klicken Sie auf ok. Wenn alles funktioniert, startet Ihre Windows-Sitzung ohne Fehlerdialoge.

Windows XP Home

Unser Beileid, falls Sie versuchen, die Home-Edition von Windows XP in einer Domänenumgebung einzusetzen! Microsoft hat in Windows XP Home keine Unterstützung für Windows NT-Domänen integriert. Das heißt, Sie haben hier ein Produkt, das für den Einsatz in einem domänenbasierten Netzwerk praktisch nicht geeignet ist.

Auf der Client-Seite können sich Benutzer von Windows XP Home nicht an einer Windows NT-Domäne anmelden. Es ist zwar möglich, auf Domänenressourcen zuzugreifen, allerdings muss der Benutzer bei jedem Zugriff auf eine Ressource einen Benutzernamen und ein Kennwort eingeben, eine einmalige Domänenanmeldung ist also nicht ausreichend. Domänenmerkmale wie Anmeldeskripten und Roaming-Profile werden nicht unterstützt.

Als Server ist Windows XP Home nicht in der Lage, einer Windows NT-Domäne als Domänen-Member-Server beizutreten. Es kann Dateien und Drucker bedienen, verwendet allerdings nur eine Sicherheit auf Freigabeebene (»Arbeitsgruppe«). Im Gegensatz zu Windows 95/98/Me kennt es nicht einmal Sicherheit auf Benutzerebene.

Auf Grund dieser Einschränkungen raten wir davon ab, Windows XP Home für irgendeine Art von lokalem Netzwerkbetrieb einzusetzen.

Windows XP Professional

Um Windows XP Professional für Domänenanmeldungen zu konfigurieren, melden Sie sich am Computer als Administrator oder als ein anderer Benutzer aus der Gruppe der Administratoren an, öffnen die Systemsteuerung in der klassischen Ansicht und doppelklicken auf das System-Symbol, um das Dialogfeld Systemeigenschaften zu öffnen. Klicken Sie auf das Register Computername und anschließend auf den Button Ändern... Sie sollten nun den Dialog Computername ändern aus Abbildung 4-10 sehen.

Klicken Sie auf den Radio-Button mit der Bezeichnung Domäne: und setzen Sie den Namen Ihrer Domäne in den Texteingabebereich ein. Klicken Sie anschließend auf ok. Dadurch öffnet sich der Dialog Benutzername und Kennwort der Domäne. Geben Sie als Benutzernamen »root« ein. Als Kennwort verwenden Sie das Kennwort, das Sie smbpasswd für den root-Zugang übergeben haben.


Falls Windows sich darüber beschwert, dass Sie bereits angemeldet sind, haben Sie vermutlich schon eine aktive Verbindung zu einer Freigabe in der Arbeitsgruppe (wie etwa ein zugewiesenes Netzlaufwerk). Heben Sie die Verbindung zur Ressource einfach zeitweilig auf, indem Sie mit der rechten Maustaste auf ihr Symbol klicken und den Menüeintrag Trennen wählen.
Abbildung 4-10
Das Dialogfeld Computername ändern

Sobald Sie auf den OK-Button geklickt haben, sollte Windows Sie über einen kleinen Dialog in der Domäne willkommen heißen. Wenn Sie hier den OK-Button anklicken, wird Ihnen mitgeteilt, dass Sie den Computer neu starten müssen, damit die Änderungen wirksam werden. Klicken Sie die OK-Buttons in den Dialogfeldern, um sie zu schließen, und starten Sie Ihren Computer wie gefordert neu. Ist das System wieder hochgefahren, zeigt Ihnen die Maschine automatisch einen Anmeldedialog ähnlich dem in Abbildung 4-11.
Abbildung 4-11
Das Windows XP-Anmeldefenster

Falls Sie an dieser Stelle einen Dialog erhalten, der Ihnen sagt, dass der Domänen-Controller nicht gefunden werden kann, müssen Sie einen Registry-Eintrag ändern. Gehen Sie dazu folgendermaßen vor.

Öffnen Sie das Start-Menü und klicken Sie auf den Menüeintrag Ausführen... Geben Sie in den Texteingabebereich des sich öffnenden Dialogs den Befehl »regedit« ein und klicken Sie auf ok, um den Registry-Editor zu starten. Sie werden nun die Registry bearbeiten, befolgen Sie daher die restlichen Anweisungen sehr sorgfältig. Klicken Sie auf den +-Button neben dem Ordner HKEY_LOCAL_MACHINE und klicken Sie in dem sich öffnenden Bereich auf den +-Button neben dem Ordner SYSTEM. Öffnen Sie auf die gleiche Weise CurrentControlSet, dann Services und Netlogon. (Sie werden mehrmals nach unten scrollen müssen, um Netlogon in der Liste der Dienste zu finden.) Klicken Sie nun auf den Parameters-Ordner. Sie sehen jetzt Einträge auf der rechten Seite des Fensters. Doppelklicken Sie auf requiresignorseal. Ein Dialogfeld öffnet sich. Ändern Sie im Textbereich Wert: den Eintrag »1« zu »0« (null). Klicken Sie jetzt den OK-Button. Dadurch wird die Registry sowohl im Speicher als auch auf der Festplatte geändert. Schließen Sie den Registry-Editor und melden Sie sich ab und wieder an.

Falls Sie kein Anmelden an:-Drop-down-Menü sehen können, klicken Sie auf den Button Optionen <<. Das Menü erscheint daraufhin. Wählen Sie aus dem Menü an Stelle des lokalen Computers Ihre Domäne.


Achten Sie darauf, dass Sie die richtige Domäne im Anmeldedialog wählen. Danach dauert es eine Weile, bis Windows die Liste der verfügbaren Domänen bereitstellt.

Geben Sie den Benutzernamen und das Kennwort eines für Samba aktivierten Benutzers in die Felder Benutzername: und Kennwort: ein und drücken Sie entweder die Enter-Taste oder klicken Sie auf ok. Wenn alles funktioniert, startet Ihre Windows-Sitzung ohne Fehlermeldungen.

Anmeldeskripten

Nachdem ein Windows-Client eine Verbindung zum Domänen-Controller hergestellt hat (entweder um einen Benutzer zu authentifizieren, wie im Fall von Windows 95/98/Me, oder um sich an einer Domäne anzumelden, wie bei Windows NT/2000/XP), lädt der Client eine MS-DOS-Batch-Datei zur Ausführung herunter. Der Domänen-Controller liefert diese Datei, vorausgesetzt, es wurde eine für ihn zur Verfügung gestellt. Bei dieser Batch-Datei handelt es sich um das Anmeldeskript. Dieses hilft beim Einrichten der Ausgangsumgebung für den Benutzer.

In einer Unix-Umgebung könnte die Fähigkeit, ein solches Skript ausführen zu können, zu einer sehr komplexen Initialisierung und Anpassung führen. Die Windows-Umgebung jedoch ist hauptsächlich an der grafischen Benutzeroberfläche orientiert, die Kommandozeilen-Funktionen sind relativ beschränkt. Am häufigsten wird das Anmeldeskript dazu verwendet, einen net-Befehl auszuführen, wie etwa net use, um einen Netzlaufwerkbuchstaben zuzuweisen:

net use T: \\toltec\test
 

Dieser Befehl sorgt dafür, dass die Freigabe [test] (aus Kapitel 2) im Arbeitsplatz als Laufwerk T: erscheint. Dies geschieht automatisch. T: steht dem Benutzer von Anfang an zur Verfügung, er muss weder den Befehl net use selbst ausführen noch die Funktion Netzlaufwerk verbinden von Windows Explorer bemühen, um das Laufwerk T: zu verbinden.

Ein anderer nützlicher Befehl ist:

net use H: /home
 

Dieser Befehl verknüpft das Home-Verzeichnis des Benutzers mit einem Laufwerkbuchstaben (der, wie hier gezeigt, H: lauten oder auch einen anderen Buchstaben verwenden kann, wie durch logon drive definiert). Damit dies funktioniert, muss in Ihrer smb.conf-Datei eine [homes]-Freigabe definiert sein.

Wenn Sie Roaming-Profile verwenden, sollten Sie auf jeden Fall

net time \\toltec /set /yes
 

in Ihrem Anmeldeskript haben. (Ersetzen Sie wie üblich »toltec« durch den Namen Ihres Samba-PDC.) Dies sorgt dafür, dass die Uhren der Windows-Clients mit dem PDC synchronisiert werden. Das ist wichtig, damit die Roaming-Profile funktionieren.

Ein Anmeldeskript erstellen

In der smb.conf-Datei ist diese Zeile zu finden:

logon script = logon.bat
 

Diese definiert den Ablageort und den Namen der Batch-Datei mit dem Anmeldeskript auf dem Samba-Server. Der Pfad ist relativ zur [netlogon]-Freigabe, die später in der Datei definiert wird:

[netlogon]
 
	path = /usr/local/samba/lib/netlogon
 
	writable = no
 
	browsable = no
 

Bei diesem Beispiel ist das Anmeldeskript /user/local/samba/lib/netlogon/logon.bat. Wir haben die Anweisung writable = no aufgenommen, um sicherzustellen, dass die Netzwerk-Clients in der [netlogon]-Freigabe nichts ändern können. Die Anweisung browsable = no sorgt dafür, dass die Clients die Freigabe beim Durchsuchen des Inhalts des Servers überhaupt sehen können. Von Benutzern, die keine Administratoren sind, sollte in der [netlogon]-Freigabe nichts geändert werden dürfen. Außerdem sollten die Rechte auf dem Verzeichnis für [netlogon] entsprechend gesetzt sein (keine Schreibrechte für »andere« Benutzer), wie wir weiter oben gezeigt haben.

Beachten Sie, dass die Erweiterung des Anmeldeskripts .bat lautet. Passen Sie jedoch auf - die Erweiterung .cmd funktioniert bei Windows NT/2000/XP-Clients, führt bei Windows 95/98/Me-Clients, die .cmd nicht als Erweiterung für Batch-Dateien erkennen, zu Fehlern.

Da das Anmeldeskript auf einem Windows-System ausgeführt werden wird, muss es im MS-DOS-Textdateiformat vorliegen, bei dem das Zeilenende aus einem Carriage Return (Wagenrücklauf), gefolgt von einem Linefeed (Zeilenvorschub) besteht. Unter Unix wird an dieser Stelle ein Newline verwendet, also einfach ein Zeilenvorschubzeichen. Wenn Sie einen Unix-Texteditor einsetzen, um das Anmeldeskript zu schreiben, müssen Sie irgendwie die richtigen Zeichen in das Skript bekommen. Bei vim (das ist ein Klon des Editors vi, der mit Red Hat Linux geliefert wird) wird dazu eine neue Datei erzeugt und folgender Befehl ausgeführt:

:se ff=dos
 

um ein Dateiformat im MS-DOS-Stil zu erhalten, bevor Text eingegeben wird. Bei emacs erreichen Sie das Gleiche mit dem folgenden Befehl:

^X Enter f dos Enter
 

Dabei ist ^X ein Control-X-Zeichen. Enter bedeutet, dass die Enter-Taste gedrückt wird. Ein anderer Weg besteht darin, in einem beliebigen Texteditor eine Datei im Unix-Format zu erzeugen und diese dann mit dem Programm unix2dos in das MS-DOS-Format zu konvertieren:

$ unix2dos unix_file >logon.bat
 

Keine Sorge, wenn auf Ihrem System das Programm unix2dos nicht existiert! Sie können es selbst mit dem folgenden Perl-Zweizeiler implementieren:

#!/usr/bin/perl
 
open FILE, $ARGV[0];
 
while (<FILE>) { s/$/\r/; print }
 

Oder Sie benutzen das Programm Notepad auf einem Windows-System, um Ihr Skript zu schreiben, und ziehen es dann in einen Ordner auf dem Samba-Server. In jedem Fall können Sie das Format Ihres Skripts mit dem Befehl od prüfen:

$ od -c logon.bat
 

Die Ausgabe sollte den folgenden Zeilen ähneln:

0000000   n  e  t     u  s  e      T   :    \  \  t  o  l
 
0000020   t  e  c  \  t  e  s  t  \r  \n
 
0000032
 

Wichtig ist an dieser Stelle, dass am Ende jeder Zeile die Zeichenfolge \r \n steht, das ist ein Carriage Return gefolgt von einem Linefeed.

Unser Beispiel-Anmeldeskript, das einen einzigen net use-Befehl enthält, wurde so erzeugt und eingerichtet, dass es auf jedem Windows-Client erfolgreich ausgeführt werden kann, unabhängig davon, welche Windows-Version auf dem Client installiert ist und welcher Benutzer sich an der Domäne authentifiziert oder anmeldet. Was tun wir aber, wenn wir unterschiedliche Benutzer, Computer oder Windows-Versionen haben, die unterschiedliche Anmeldeskripten brauchen?

Eine Möglichkeit wäre es, Variablen im Anmeldeskript einzusetzen, die dafür sorgen, dass unter bestimmten Bedingungen bestimmte Befehle ausgeführt werden. Nähere Informationen dazu finden Sie in einer Referenz zur Batch-Datei-Programmierung für MS-DOS und Windows NT. Eine solche Referenz ist das Buch Windows NT System-Administration (O'Reilly Verlag).

Die Sprache für Windows-Batch-Befehle ist in ihrer Funktionalität sehr beschränkt. Glücklicherweise unterstützt Samba einen Weg, um die Anpassung durchzuführen. Die Datei smb.conf enthält Variablen, die verwendet werden können, um (zur Laufzeit) den Namen des Servers (%L), den Benutzernamen der Person, die auf die Ressourcen des Servers zugreift (%u), oder den Computernamen des Client-Systems (%m) einzusetzen. Ein Beispiel: Wenn Sie den Pfad des Anmeldeskripts als

logon script = %u/logon.bat
 

angeben, legen Sie für jeden Benutzer in der Freigabe [netlogon] ein Verzeichnis an. Der Name des Verzeichnisses wäre jeweils identisch mit dem Benutzernamen des Benutzers, und in jedes Verzeichnis würden Sie eine angepasste logon.bat-Datei setzen. Damit hätte jeder Benutzer sein eigenes Anmeldeskript. Im Abschnitt »Roaming-Profile« zeigen wir Ihnen ein besseres Beispiel hierfür.


Weitere Informationen über die Variablen der Samba-Konfigurationsdatei, wie die gerade verwendeten %L, %u und %m, finden Sie in Kapitel 6 und in Anhang B.

Wenn Sie Ihr Anmeldeskript verändern und testen, melden Sie sich nicht einfach nur bei Windows ab und wieder an, um das Skript auszuführen. Starten Sie stattdessen Ihr System neu, bevor Sie sich wieder anmelden. Windows hält die Freigabe [netlogon] oft über mehrere Sitzungen hinweg offen. Der Neustart stellt deshab sicher, dass Windows und Samba die Freigabe [netlogon] vollständig freigegeben und neu verbunden haben und beim Anmelden die neue Version des Anmeldeskripts ausgeführt wird.

Roaming-Profile

Ein Vorteil der zentralisierten Authentifizierung an Windows NT-Domänen besteht darin, dass ein Benutzer sich von mehr als nur einem einzigen Computer aus anmelden kann. Damit Benutzer sich auch dann »heimisch« fühlen, wenn sie nicht an ihrem üblichen Rechner angemeldet sind, hat Microsoft die Möglichkeit vorgesehen, die persönlichen Einstellungen von einem Computer zu einem anderen zu übertragen.

Alle Windows-Versionen können für jeden Benutzer des Computers individuell konfiguriert werden. Windows NT/2000/XP unterstützen die Möglichkeit, mehrere Benutzerzugänge zu verarbeiten, und auch Windows 95/98/Me können für die Benutzung durch mehrere Benutzer konfiguriert werden, wobei die Konfigurationseinstellungen der einzelnen Benutzer separat vorgehalten werden. Jeder Benutzer kann die Einstellungen des Computers nach seinem Willen verändern. Das System speichert diese Einstellungen als Profil des Benutzers. Beim Anmelden am System wird dem Benutzer sein vertrauter Desktop präsentiert.

Einige der Einstellungen, wie etwa die Ordneroptionen oder das Hintergrundbild für den Desktop, werden in der Registry gespeichert. Andere, einschließlich der Dokumente und Ordner, die auf dem Desktop erscheinen, und des Inhalts des Start-Menüs, werden als Ordner und Dateien im Dateisystem abgelegt.

Wenn das Profil im lokalen System gespeichert wird, bezeichnet man es als lokales Profil. Unter Windows NT werden die lokalen Profile im Verzeichnis C:\Winnt\Profiles abgelegt. Unter Windows 2000/XP sind sie in C:\Dokumente und Einstellungen zu finden. Werden Windows 95/98/Me für einen einzigen Benutzer konfiguriert (das ist der Standardfall), wird das lokale Profil auf solche Stellen wie die Registry und Verzeichnisse wie C:\Windows\Desktop und C:\Windows\Startmenü verteilt. Werden Windows 95/98/Me dagegen für mehrere Benutzer konfiguriert, wird das lokale Profil des existierenden Benutzers in einen Ordner unterhalb von C:\Windows\Profiles verschoben, der den gleichen Namen trägt wie der Benutzer. Die lokalen Profile aller anderen Benutzer, die danach angelegt werden, werden ebenfalls in diesem Verzeichnis gespeichert. Sie können sich die lokalen Profile anschauen, um ihre Struktur kennen zu lernen - jedes besitzt eine Registry-Datei (USER.DAT für Windows 95/98/Me und NTUSER.DAT für Windows NT/2000/XP) und einige Ordner mit Aliasen und Dokumenten.

Ein Roaming-Profil ist ein Benutzerprofil, das auf einem Server gespeichert wird und seinem Besitzer durch das Netzwerk »folgt«. Meldet sich der Benutzer also von einem anderen Computer aus an der Domäne an, wird sein Profil vom Server heruntergeladen, und auf diesem Computer erscheint sein vertrauter Desktop.


Samba kann Roaming-Profile unterstützen, und es ist sogar eine recht einfache Sache, es entsprechend zu konfigurieren. Allerdings ist dies eine Funktion, deren Einsatz wir Ihnen nicht empfehlen, es sei denn, Sie verstehen Roaming-Profile wirklich gut und sind überzeugt, dass Sie sie implementieren können, ohne dass Schaden auftritt. Falls Sie Roaming-Profile für Ihre Windows-Clients implementieren wollen (oder müssen), raten wir Ihnen, zu Testzwecken zuerst eine kleine Domäne mit einem Samba-Server und wenigen Windows-Clients einzurichten. Unter keinen Umständen dürfen Sie versuchen, Roaming-Profile sorglos oder leichtfertig zu implementieren.

Wie Roaming-Profile funktionieren

Wir werden Ihnen zunächst einmal erklären, wie Roaming-Profile funktionieren, wenn sie richtig eingerichtet worden sind. Sie benötigen ein klares Verständnis von Roaming-Profilen, um feststellen zu können, ob sie so funktionieren, wie sie gedacht waren, oder nicht. Für Benutzer stellen Roaming-Profile oft eine Quelle der Verwirrung dar. Sie sollten deshalb in der Lage sein festzustellen, ob ein Problem mit einem Client seine Ursache in einer Funktion des Roaming-Profils oder in einer echten Fehlfunktion hat.


Eine maßgebliche Quelle für Informationen über Windows NT-Roaming-Profile ist das Microsoft-Whitepaper Implementing Policies and Profiles for Windows NT 4.0, das Sie unter http://www.microsoft.com/ntserver/techresources/management/prof_policies.asp finden können.

Während der Anmeldung an der Domäne wird das Roaming-Profil vom Domänen-Controller kopiert und für die Dauer der Sitzung des Benutzers als lokales Profil verwendet. Meldet sich der Benutzer von der Domäne ab, wird das lokale Profil wieder auf den Domänen-Controller kopiert und als neues Roaming-Profil gespeichert. Ändert sich das lokale Profil, erhält der Server die Aktualisierung erst dann, wenn sich der Benutzer von der Domäne abmeldet oder den Client herunterfährt oder neu startet. Während der Sitzung sendet der Client keine Aktualisierung an den Server, und er empfängt auch keine Aktualisierung, wenn während der Sitzung eine Einstellung auf einem anderen Client geändert wurde. Wenn sich der Benutzer abmeldet, werden die Änderungen an den Konfigurationseinstellungen im lokalen Profil an den Server geschickt, und die Aktualisierungen des Roaming-Profils stehen für die nächste Anmeldesitzung zur Verfügung.

Dieses einfache Verhalten kann zu unerwarteten Ergebnissen führen, wenn Benutzer auf mehr als einem Client auf einmal an der Domäne angemeldet sind. Führt ein Benutzer auf einem Client eine Änderung an den Konfigurationseinstellungen durch, wird das Roaming-Profil entsprechend geändert. Der nächste Client jedoch, der sich abmeldet, könnte veranlassen, dass diese Änderungen überschrieben werden. In diesem Fall gehen die Einstellungen des ersten Clients verloren. Das diesbezügliche Verhalten der verschiedenen Windows-Versionen ist ganz unterschiedlich, und wir haben eine Menge unterschiedlicher Verhaltensweisen gesehen - nicht immer konform mit der Microsoft-Dokumentation oder gar identisch bei verschiedenen Gelegenheiten. Manchmal lehnt Windows es ab, ein Profil zu überschreiben, und liefert möglicherweise einen »Zugriff verweigert«-Fehler. Manchmal dagegen scheint es zu funktionieren, verursacht aber eigenartige Nebenwirkungen. Zu Verwirrung kommt es nahezu immer, wenn eine Datei auf dem Desktop angelegt oder von ihm gelöscht wird, was standardmäßig Teil des Profils ist. Eine gelöschte Datei taucht unter Umständen später wieder auf. Es kann auch passieren, dass eine Datei ohne Warnung unwiderruflich verschwindet (unter Windows 95/98). Oder eine Datei, die auf dem Desktop des einen Clients angelegt wurde, wird niemals zum Roaming-Profil hinzugefügt und somit auch nicht den anderen Clients bekannt gemacht. Dieses Verhalten hat sich unter Windows 2000/XP ein wenig verbessert, das heißt, es wurde versucht, Elemente in das Profil einzufügen, die auf gleichzeitig angemeldeten Clients angelegt wurden.

Ein Faktor, der mit ins Spiel kommt, ist die Tatsache, dass Windows die Zeitstempel der lokalen und der Roaming-Profile vergleicht und es ablehnen kann, ein Roaming-Profil zu überschreiben, wenn es neuer ist als das lokale Profil auf dem Client oder umgekehrt. Aus diesem Grund ist es wichtig, dass die Uhren der Windows-Clients und des Samba-PDC synchron laufen. Wir haben Ihnen bereits gezeigt, wie Sie das mit Hilfe des Befehls net time \\server /set /yes im Anmeldeskript erreichen.

Selbst wenn der Server und die Clients korrekt konfiguriert sind, können noch eine Reihe vermeintlicher Probleme auftreten. Am häufigsten passiert es, dass einige Aliase auf den Clients, die nicht von dem Roaming-Profil erzeugt wurden, nicht funktionieren. Diese Aliase können auf dem Desktop oder als Einträge im Start-Menü existieren. Dieses Verhalten resultiert daher, dass Anwendungen oder Dateien zwar auf einem Computer vorhanden sind, nicht jedoch auf anderen. Windows zeigt diese Aliase an, auf dem Desktop haben sie jedoch ein generisches Symbol und erzeugen eine Fehlermeldung, falls ein Beutzer sie doppelt anklickt.


Da Profile üblicherweise den Inhalt des Desktops und anderer Ordner enthalten, kann ein Roaming-Profil auf Grund der Aktionen eines Benutzers, wie dem Erzeugen neuer Dateien auf dem Desktop oder dem Kopieren von Dateien auf den Desktop, ziemlich groß werden. Standardmäßig legt der Internet Explorer seinen Festplatten-Cache im Ordner Temporary Internet Files im Profil ab. Dieses Verzeichnis kann durchaus mehrere tausend Dateien umfassen. Das daraus resultierende riesige Roaming-Profil verursacht dann eine Überlastung des Netzwerks und große Verzögerungen beim Anmelden von Benutzern an der Domäne. (Eine Lösung für dieses Problem ist im Artikel Q185255 der Microsoft Knowledge Base beschrieben.)

Ein Verhalten, das uns einige Male aufgefallen ist, besteht darin, dass das Roaming-Profil aus irgendeinem Grund (z.B. Netzwerkfehler oder Fehlkonfiguration) während der Anmeldung nicht zur Verfügung steht. Stattdessen verwendet Windows dann das lokale Profil auf dem Client. Geschieht dies, erhält der Benutzer möglicherweise ein fremdes Profil, die Vorteile der Roaming-Profile können während dieser Sitzung nicht genutzt werden.

Samba für Roaming-Profile konfigurieren

In einer idealen Welt würden unterschiedliche Windows-Versionen das gleiche Roaming-Profil verwenden. Dadurch wäre es Benutzern möglich, sich von jedem Windows-Client-System - ob Windows 95 oder Windows XP - an der Domäne anzumelden und die vertrauten Einstellungen vorzufinden. Sie könnten sogar gleichzeitig von mehreren Clients aus angemeldet sein; eine Änderung des Profils auf einem der Clients würde schnell den anderen Clients bekannt gemacht werden. Einstellungen, die in einem Roaming-Profil auf einem Client vorgenommen werden und die nicht für andere Clients gelten, würden vernünftig behandelt werden.

Dummerweise funktioniert dieses Szenario in der Wirklichkeit nicht. Es ist wichtig, separate Roaming-Profile zu verwalten, um zu verhindern, dass unterschiedliche Windows-Versionen ein Roaming-Profil verwenden oder modifizieren, das von einer anderen Version erzeugt und/oder benutzt wird.

Wir erledigen dies, indem wir Variablen in der Konfigurationsdatei einsetzen, die auf unterschiedliche Profilverzeichnisse verweisen. Wenn Sie sich Tabelle B-1 in Anhang B anschauen, in der die möglichen Variablen aufgeführt sind, werden Sie versucht sein, die Variable %a zu verwenden, die durch den Namen des Betriebssystems ersetzt wird, das auf dem Client läuft. Das funktioniert jedoch nicht, da Windows 95/98/Me als das gleiche Betriebssystem betrachtet werden. Gleiches gilt für Windows 2000/XP. Wir benutzen deshalb %m, um den NetBIOS-Namen des Clients zu erhalten, und kombinieren dies mit einem symbolischen Link auf das Verzeichnis, in dem das Profil für die Windows-Version dieses speziellen Clients enthalten ist.

Unsere Ergänzungen zu smb.conf, die wir weiter oben in diesem Kapitel gezeigt haben, enthielten diese beiden Zeilen:

logon path = \\%L\profiles\%u\%m
 
logon home = \\%L\%u\.win_profile\%m
 

Die erste Zeile gibt an, wo die Roaming-Profile für Windows NT/2000/XP-Clients abgelegt werden, und die zweite Zeile führt die gleiche Aktion für Windows 95/98/Me-Clients aus. In beiden Fällen wird der Ablageort als UNC angegeben, allerdings wird logon path (für Windows NT/2000/XP) als relativer Pfad zur Freigabe [profiles] festgelegt, während logon home (für Windows 95/98/Me) relativ zum Home-Verzeichnis des Benutzers liegt. Dies geschieht, damit Sambas Emulation dem Verhalten eines Windows NT/2000-PDC entspricht.

Die logon home-UNC muss mit der Angabe des Home-Verzeichnisses des Benutzers beginnen. Im vorherigen Beispiel wäre dies \\%L\%u. Die Variable %L wird zum NetBIOS-Namen des Servers erweitert (in diesem Fall toltec), und %u wird zum Namen des Benutzers. Dies ist notwendig, damit der Befehl:

C:\>net use h: /home
 

das Home-Verzeichnis des Benutzers auf allen Windows-Clients korrekt mit dem Laufwerkbuchstaben H: verknüpft. (Der für diesen Zweck eingesetzte Laufwerkbuchstabe wird durch logon drive definiert.) Wir fügen der UNC das Verzeichnis .win_profile hinzu, um das Windows 95/98/Me-Roaming-Profil in ein Unterverzeichnis des Home-Verzeichnisses des Benutzers zu setzen.


Beachten Sie, dass wir es sowohl in logon path als auch in logon home vermieden haben, als Profil-Verzeichnis das gleiche Verzeichnis wie das Home-Verzeichnis des Benutzers anzugeben. Außerdem wird das Profil-Verzeichnis für keine andere Aufgabe eingesetzt. Das liegt daran, dass bei einer Aktualisierung des Roaming-Profils alle Verzeichnisse und Dateien im Roaming-Profil-Verzeichnis, die nicht Bestandteil des Roaming-Profils sind, gelöscht werden.

In der logon path-Zeile in smb.conf verwenden wir %u, um das Profile-Verzeichnis in ein Unterverzeichnis der [profiles]-Freigabe zu setzen, damit jeder Benutzer für seine Roaming-Profile ein eigenes Verzeichnis erhält.

Definieren Sie die [profiles]-Freigabe folgendermaßen:

[profiles]
 
	writable = yes
 
	create mask = 0600
 
	directory mask = 0700
 
	browsable = no
 
	path = /home/samba-ntprof
 

Die ersten vier Parameter in der Freigabe-Definition legen fest, dass die Roaming-Profile mit den Rechten des Benutzers geschrieben werden, dass Dateien mit Lese- und Schreibrechten für den Eigentümer erzeugt werden und dass Verzeichnisse mit Lese-, Schreib- und Suchrechten für den Eigentümer erzeugt werden und der Zugriff auf diese Verzeichnisse allen anderen Benutzern nicht erlaubt ist. Wie bei der Freigabe [netlogon] setzen Sie browsable = no, damit die Freigabe den Clients im Windows Explorer nicht angezeigt wird.

Wir haben beschlossen, die Windows NT/2000/XP-Profile in /home abzulegen, dem vorgegebenen Ablageort der Home-Verzeichnisse unter Linux. Dadurch ist es einfach, die Roaming-Profile in die Sicherung der Home-Verzeichnisse einzuschließen. Sie können auch ein anderes Verzeichnis verwenden, wenn Sie wollen.

Beachten Sie, dass sowohl in logon path als auch in logon home das Verzeichnis, das Sie angeben, mit %m endet. Diese Variable ersetzt Samba durch den NetBIOS-Namen des Clients. Verwenden Sie den Computernamen des Clients, um indirekt zu identifizieren, welche Version von Windows er ausführt.

Zu Anfang sind die Verzeichnisse, die Sie für die Roaming-Profile angegeben haben, leer. Sie werden belegt, wenn die Clients sich zum ersten Mal abmelden. (Samba erzeugt die Verzeichnisse sogar, falls sie noch nicht existieren.) Zuerst enthalten die Verzeichnisse einfach Profile, die identisch sind mit den lokalen Profilen der Clients. Wir empfehlen Ihnen, an dieser Stelle ein Backup zu machen, bevor die Dinge kompliziert werden. Ein Listing des Roaming-Profil-Verzeichnisses der Benutzerin iman, nachdem sie sich an den Windows 98-Clients mixtec und pueblo sowie den Windows Me-Clients huastec und navajo abgemeldet hat, könnte so aussehen:

$ ls -l /home/iman/.win_profile
 
total 4
 
drwx------    6 iman      iman          4096 Dec  8 18:09 huastec
 
drwx------    9 iman      iman          4096 Dec  7 03:47 mixtec
 
drwx------   11 iman      iman          4096 Dec  7 03:05 navajo
 
drwx------   11 iman      iman          4096 Dec  7 03:05 pueblo
 

Bleiben die Dinge so, teilen die Clients ihre Roaming-Profile nicht. Deshalb gehen wir nun dazu über, an Stelle von separaten Verzeichnissen symbolische Links auf gemeinsame Verzeichnisse einzusetzen:

# mv mixtec Win98
 
# mv navajo WinMe
 
# rm huastec pueblo
 
# ln -s Win98 pueblo
 
# ln -s WinMe huastec
 
# chown iman:iman *
 
# ls -l /home/iman/.win_profile
 
total 6
 
lrwxrwxrwx    1 iman      iman             5 Nov 16 01:40 huastec -> WinMe
 
lrwxrwxrwx    1 iman      iman             5 Nov 16 01:40 mixtec -> Win98
 
lrwxrwxrwx    1 iman      iman             5 Nov 21 17:24 navajo -> WinMe
 
lrwxrwxrwx    1 iman      iman             5 Nov 23 01:16 pueblo -> Win98
 
drwx------    9 iman      iman          4096 Dec  7 03:47 Win98
 
drwx------   11 iman      iman          4096 Dec  7 03:05 WinMe
 

Wenn iman sich nun von einem der Windows 98-Systeme an der Domäne anmeldet, bezieht der Client, an dem sie sich anmeldet, das Profil, das im Verzeichnis Win98 abgelegt ist (ursprünglich ihr lokales Profil auf mixtec). Für die Windows Me-Clients funktioniert dies genauso.

Ein vollständigeres Beispiel. Schauen Sie sich hier das Listing eines »richtigen« Windows 95/98/Me-Profil-Verzeichnisses an:

$ ls -l /home/jay/.win_profile
 
total 12
 
lrwxrwxrwx    1 jay      jay             9 Nov 16 22:14 aztec -> /home/jay
 
lrwxrwxrwx    1 jay      jay             5 Nov 16 01:40 hopi -> Win95
 
lrwxrwxrwx    1 jay      jay             5 Nov 16 01:40 huastec -> WinMe
 
lrwxrwxrwx    1 jay      jay             5 Nov 16 01:38 maya -> Win98
 
lrwxrwxrwx    1 jay      jay             5 Nov 16 01:40 mixtec -> Win98
 
lrwxrwxrwx    1 jay      jay             5 Nov 21 17:24 navajo -> WinMe
 
lrwxrwxrwx    1 jay      jay             5 Nov 23 01:16 pueblo -> Win98
 
lrwxrwxrwx    1 jay      jay             5 Nov 22 02:06 ute -> Win95
 
drwx------    6 jay      jay          4096 Dec  8 18:09 Win95
 
drwx------    9 jay      jay          4096 Dec  7 03:47 Win98
 
drwx------   11 jay      jay          4096 Dec  7 03:05 WinMe
 
lrwxrwxrwx    1 jay      jay             5 Nov 21 22:48 yaqui -> Win98
 
lrwxrwxrwx    1 jay      jay             9 Nov 16 22:14 zuni -> /home/jay
 

Auch hier ist der Computername der einzelnen Clients in diesem Verzeichnis ein symbolischer Link auf dasjenige Verzeichnis, das das tatsächliche Roaming-Profil enthält. Beispielsweise besitzt maya, ein Client mit Windows 98, einen symbolischen Link namens maya auf das Verzeichnis Win98. Ein Listing von Win98 zeigt Folgendes:

$ ls -l Win98
 
total 148
 
drwxr-xr-x    3 jay      jay          4096 Nov 23 01:30 Application Data
 
drwxr-xr-x    2 jay      jay          4096 Nov 23 01:30 Cookies
 
drwxr-xr-x    3 jay      jay          4096 Dec  7 03:47 Desktop
 
drwxr-xr-x    3 jay      jay          4096 Nov 23 01:30 History
 
drwxr-xr-x    2 jay      jay          4096 Nov 23 01:30 NetHood
 
drwxr-xr-x    2 jay      jay          4096 Dec  7 03:47 Recent
 
drwxr-xr-x    3 jay      jay          4096 Nov 23 01:30 Start Menu
 
-rw-r--r--    1 jay      jay        114720 Dec  7 03:46 USER.DAT
 

Die Inhalte der Verzeichnisse Win95 und WinMe sind ähnlich und enthalten Roaming-Profile, die genau so funktionieren, wie sie dies unter ihren jeweiligen Betriebssystemen tun sollten.

Beachten Sie in dem gezeigten Listing, dass aztec und zuni symbolische Links auf /home/jay sind. Wir haben Sie davor gewarnt, ein Roaming-Profil-Verzeichnis identisch mit dem Home-Verzeichnis eines Benutzers zu machen. Allerdings liegen die Dinge hier ein wenig anders. Die Clients aztec und zuni sind Windows XP-Systeme, die logon home anders verarbeiten als andere Versionen von Windows. Wir haben logon home = \\%L\%u\.win profile gesetzt. Alle Versionen von Windows mit Ausnahme von Windows XP entfernen alles nach \\%L\%u und legen das Home-Verzeichnis richtig fest - in diesem Fall mit /home/jay. Windows XP verwendet die vollständige UNC, deshalb fügen wir einfach einen symbolischen Link hinzu, der es auf das richtige Verzeichnis umleitet, damit der Befehl net use H: /home so funktioniert wie vorgesehen. Die Roaming-Profile für Windows XP-Systeme werden davon nicht beeinflusst und befinden sich bei den anderen Roaming-Profilen der Windows NT/2000/XP-Familie, wie dieses Listing zeigt:

$ ls -l /home/samba-ntprof/jay
 
total 16
 
lrwxrwxrwx    1 jay      jay             5 Nov 20 03:45 apache -> Win2K
 
lrwxrwxrwx    1 jay      jay             5 Nov 13 12:35 aztec -> WinXP
 
lrwxrwxrwx    1 jay      jay             5 Nov 13 12:34 dine -> WinNT
 
lrwxrwxrwx    1 jay      jay             5 Nov 24 03:44 inca -> Win2K
 
lrwxrwxrwx    1 jay      jay             5 Nov 13 12:34 pima -> Win2K
 
drwx------   13 jay      jay          4096 Dec  3 15:24 qero
 
drwx------   13 jay      jay          4096 Dec  1 20:31 Win2K
 
drwx------   12 jay      jay          4096 Nov 30 17:04 WinNT
 
drwx------   13 jay      jay          4096 Nov 20 01:23 WinXP
 
lrwxrwxrwx    1 jay      jay             5 Nov 20 06:09 yavapai -> WinXP
 
lrwxrwxrwx    1 jay      jay             5 Nov 13 12:34 zapotec -> Win2K
 
lrwxrwxrwx    1 jay      jay             5 Nov 13 12:35 zuni -> WinXP 
 

Wie Sie sehen können, verwenden wir eine ähnliche Methode für die Windows NT/2000/XP-Roaming-Profile. In dem Listing ist qero kein symbolischer Link, sondern ein Verzeichnis, in dem sich das Roaming-Profil für qero befindet, einem Windows 2000-Client, der kürzlich hinzugefügt wurde. Vor der Installation von Windows 2000 hatten wir noch keinen symbolischen Link namens qero erzeugt. Als jay sich das erste Mal abmeldete, erzeugte Samba ein Verzeichnis namens qero und kopierte das Roaming-Profil, das es von dem Client empfangen hatte, in das neue Verzeichnis. Da dies ein anderes Verzeichnis ist als Win2K, das alle anderen Windows 2000-Clients verwenden, um ihre Roaming-Profile abzulegen, funktioniert das Roaming-Profil für qero wie ein lokales Profil, nur dass es auf dem primären Domänen-Controller gespeichert wird.

Das mag ein wenig seltsam erscheinen, hat aber seinen Sinn. Manchmal wollen Sie möglicherweise einen Client auf diese Weise isolieren, vor allem während das Betriebssystem installiert und konfiguriert wird. Erinnern Sie sich: Wenn dieser Client mit seinem vorgegebenen lokalen Profil sich an der Domäne abmeldet, wird das lokale Profil in das Roaming-Profil-Verzeichnis geschrieben. Würde der Client das gemeinsame Roaming-Profil-Verzeichnis benutzen, hätte dies unerwünschte Auswirkungen, um es vorsichtig auszudrücken. Mit unserer Methode kann das Verzeichnis qero später umbenannt werden, um es zu sichern, oder es könnte einfach gelöscht werden. Dann kann ein neuer symbolischer Link namens qero erzeugt werden, der auf das Verzeichnis Win2K verweist, und qero teilt das Roaming-Profil in Win2K mit den anderen Windows 2000-Clients.

Eine Alternative besteht darin, die symbolischen Links einfach zu erzeugen, bevor die Clients dem Netzwerk hinzugefügt werden. Wenn Sie sich damit vertraut gemacht haben, wie Roaming-Profile funktionieren, werden Sie diese Methode einfacher und schneller finden.

Wir wiederholen es an dieser Stelle jedoch noch einmal: Seien Sie vorsichtig, wenn Sie unterschiedliche Windows-Versionen das gleiche Roaming-Profil benutzen lassen. Die hier gezeigte Methode der Konfiguration von Roaming-Profilen erlaubt es Ihnen, eine Konfiguration für wenige Clients auf einmal zu testen, ohne Ihr gesamtes Netzwerk mit Clients zu beeinträchtigen. Wir könnten beispielsweise zu Testzwecken eine geringe Anzahl an Windows 2000- und Windows XP-Systemen in der Domäne installieren und dann symbolische Links für sie anlegen, die auf ein Verzeichnis namens Win2KXP verweisen, um herauszufinden, ob gemeinsame Roaming-Profile für die Windows 2000- und Windows XP-Systeme unseren Erwartungen entsprechen. Das Verzeichnis Win2KXP könnte als leeres Verzeichnis erzeugt werden. In diesem Fall würde beim ersten Abmelden der Clients ein Roaming-Profil in das Verzeichnis geschrieben werden. Win2KXP könnte aber auch einfach ein umbenanntes Roaming-Profil-Verzeichnis sein, das von einem der Clients angelegt worden ist, als dieser in die Domäne aufgenommen wurde.

Windows 95/98/Me für Roaming-Profile konfigurieren

Damit Roaming-Profile bei Windows 95/98/Me-Clients funktionieren, müssen Sie lediglich eine Einstellung verändern, so dass jeder Benutzer ein eigenes lokales Profil haben kann. Dies bringt als Nebenwirkung mit sich, dass auch Roaming-Profile aktiviert werden.

Öffnen Sie die Systemsteuerung und doppelklicken Sie auf das Kennwörter-Symbol, um das Dialogfeld Eigenschaften von Kennwörter zu öffnen. Klicken Sie auf das Register Benutzerprofile. Das Dialogfeld sieht nun aus wie das in Abbildung 4-12.
Abbildung 4-12
Der Windows 98-Dialog Eigenschaften von Kennwörter

Klicken Sie auf den Button mit der Bezeichnung Benutzer können die Vorgaben und Desktop-Einstellungen ändern. Im Bereich Einstellungen für Benutzerprofile können Sie die gewünschten Optionen aktivieren. Wenn Sie fertig sind, klicken Sie auf ok und starten den Rechner neu. Während dieses ersten Neustarts kopiert Windows die lokalen Profildaten nach C:\Windows\Profiles, versucht aber nicht, das Roaming-Profil vom Server zu kopieren. Beim nächsten Herunterfahren des Systems wird das lokale Profil auf den Server kopiert, und wenn Windows neu startet, kopiert es das Roaming-Profil vom Server.

Windows NT/2000/XP für Roaming-Profile konfigurieren

Unter Windows NT/2000/XP sind Roaming-Profile standardmäßig aktiviert. Falls Sie Ihre Einstellungen überprüfen oder verändern wollen, gehen Sie folgendermaßen vor.

Stellen Sie sicher, dass Sie am lokalen System als Administrator oder als ein anderer Benutzer aus der Gruppe der Administratoren angemeldet sind. Öffnen Sie die Systemsteuerung und doppelklicken Sie auf das System-Symbol. Klicken Sie unter Windows NT/2000 auf das Register Benutzerprofile bzw. unter Windows XP auf das Register Erweitert und klicken Sie anschließend auf den Button Einstellungen im Feld Benutzerprofile. Sie sollten nun das Dialogfeld aus Abbildung 4-13 sehen.
Abbildung 4-13
Der Windows 2000-Dialog Eigenschaften von System, Register Benutzerprofile

Beachten Sie in der Abbildung, dass es zwei Einträge für den Benutzernamen jay gibt. Der Eintrag ZAPOTEC\jay bezieht sich auf den Zugang am lokalen System, METRAN\ jay dagegen bezeichnet den Domänenzugang. Sie erinnern sich: Wenn ein Benutzer sich anmeldet, erlaubt ihm ein Drop-down-Menü im Dialogfeld, sich an einer Domäne oder am lokalen System anzumelden. Meldet jay sich an der lokalen Domäne an, wird nur das lokale Profil verwendet. Beim Anmelden an der Domäne verwendet die gezeigte Konfiguration das Roaming-Profil. Um den Profiltyp eines Benutzers für einen Domänenzugang zu wechseln, klicken Sie zuerst auf den Zugangsnamen. Dieser Zugang wird ausgewählt. Klicken Sie nun auf den Button Typ ändern... im unteren Bereich des Dialogs. Das Dialogfeld Profiltyp ändern wird geöffnet. Klicken Sie entweder auf den Radio-Button für das servergespeicherte Profil oder auf den Radio-Button für das lokale Profil und klicken Sie anschließend auf die OK-Buttons der einzelnen Dialogfelder.

Mandatory-Profile

Mit Hilfe einer einfachen Modifikation kann ein Roaming-Profil in ein Mandatory-Profil (obligatorisches Profil) umgewandelt werden, das die spezielle Eigenschaft besitzt, von seinem Besitzer nicht verändert werden zu können. Mandatory-Profile werden in einigen Rechnerumgebungen verwenden, um die Verwaltung zu vereinfachen. Theoretisch kann nicht so viel schiefgehen, wenn den Benutzern nicht erlaubt ist, ihre Profile zu verändern. Außerdem kann für alle Benutzer das gleiche standardisierte Profil verwendet werden.

In der Praxis gibt es jedoch einige Probleme. Da die Benutzer während einer Sitzung die Konfigurationseinstellungen in ihrem lokalen Profil verändern können, kann es beim nächsten Anmelden an der Domäne zu Verwirrung kommen, wenn sie feststellen, dass ihre Änderungen »verloren« gegangen sind. Installiert der Benutzer eines Clients eine Anwendung neu an einer anderen Stelle, können die Aliase des Programms auf dem Desktop, im Start-Menü oder dem Schnellstartbereich nicht dauerhaft gelöscht werden. Sie tauchen immer wieder auf, wenn sich der Benutzer an der Domäne anmeldet. Im Prinzip handelt es sich bei einem Mandatory-Profil um ein Roaming-Profil, das beim Abmelden nie auf dem Server aktualisiert wird!

Ein anderes Problem besteht darin, dass die unterschiedlichen Windows-Versionen Mandatory-Profile verschieden behandeln. Wenn ein Benutzer, der ein Mandatory-Profil besitzt, eine neue Datei auf seinem Desktop erzeugt, kann es passieren, dass die Datei bei der nächsten Anmeldung oder nach einem Neustart verschwunden ist. Manche Windows-Versionen speichern die Desktop-Dateien im lokalen Profil (selbst wenn die Datei im Mandatory-Profil nicht existiert), andere dagegen nicht.

Um ein Roaming-Profil in ein Mandatory-Profil umzuwandeln, müssen Sie einfach nur die .dat-Datei im Roaming-Profil-Verzeichnis auf dem Server so umbenennen, dass sie stattdessen die Erweiterung .man trägt. Bei einem Windows 95/98/Me-Roaming-Profil würden Sie USER.DAT in USER.MAN umbenennen, bei einem Windows NT/2000/XP-Roaming-Profil benennen Sie NTUSER.DAT in NTUSER.MAN um. Außerdem würden Sie vermutlich das Roaming-Profil-Verzeichnis mit einem Schreibschutz versehen, damit nicht ein Benutzer sich einfach mit seinem Unix-Benutzerzugang auf dem Samba-Host-System anmeldet und etwas ändert.

Falls Sie wollen, dass alle Ihre Benutzer ein gemeinsames Mandatory-Profil verwenden, können Sie die Definitionen von logon path und logon home in Ihrer smb.conf-Datei derart ändern, dass sie auf ein gemeinsames Mandatory-Profil auf dem Server verweisen. Die Verzeichnisstruktur und die symbolischen Links müssen Sie entsprechend anpassen. logon path und logon home könnten beispielsweise folgendermaßen definiert werden:

logon path = \\%L\profiles\%m
 
logon home = \\%L\%u\.win_profile\%m
 

Beachten Sie, dass wir den %u-Teil des Pfads für logon path entfernt haben. Wir würden außerdem die Verzeichnisstruktur auf dem Server so ändern, dass die Trennung der Profile anhand der Benutzernamen aufgehoben wird und wir nur noch ein Profil für jede Windows NT/2000/XP-Version haben.

Für logon home ist dieses Vorgehen nicht geeignet, da es auch zur Festlegung des Home-Verzeichnisses verwendet wird. In diesem Fall würden wir die symbolischen Links im .win_profile-Verzeichnis der einzelnen Benutzer so ändern, dass diese auf ein gemeinsames Mandatory-Profil-Verzeichnis verweisen, in dem die Mandatory-Profile für Windows 95/98/Me stehen. Prüfen Sie auch hier die Eigentümerschaft der Dateien und die Rechte darauf in dem Verzeichnis und verändern Sie diese, falls sich das als notwendig erweisen sollte, damit die Benutzer die Dateien nicht einfach über ihren Unix-Zugang auf dem Samba-Host ändern können.

Optionen für das Anmeldeskript und das Roaming-Profil

Tabelle 4-1 fasst die Optionen zusammen, die üblicherweise im Zusammenhang mit Windows NT-Domänen-Anmeldeskripten und Roaming-Profilen verwendet werden.

Tabelle 4-1
Optionen für Anmeldeskripten
Option
Parameter
Funktion
Vorgabewert
Geltungsbereich
logon script
String (MS-DOS-Pfad)
Name der Anmeldeskript-Batch-Datei
keiner
global
logon path
String (UNC-Server- und Freigabename)
Ablageort des Roaming-Profils
\\%N\%U\
profile
global
logon drive
String (Laufwerkbuchstabe)
gibt das Anmeldelaufwerk für ein Home-Verzeichnis an
Z:
global
logon home
String (UNC-Server- und Freigabename)
gibt einen Ablageort für die Home-Verzeichnisse der Clients an, die sich an der Domäne anmelden
\\%N\%U
global

logon script

Diese Option gibt eine Windows-Batch-Datei an, die auf dem Client ausgeführt wird, nachdem sich ein Benutzer an der Domäne angemeldet hat. Jedes Anmeldeskript sollte im Root-Verzeichnis der [netlogon]-Freigabe oder einem Unterverzeichnis gespeichert werden. Diese Option verwendet oft die Variablen %U oder %m (Benutzer oder NetBIOS-Name), um auf ein spezielles Skript zu verweisen. Zum Beispiel führt

[global]
 
	logon script = %U.bat
 

ein Skript auf der Grundlage des Benutzernamens aus. Handelt es sich bei dem Benutzer, der sich anmeldet, um fred und verweist der Pfad der [netlogon]-Freigabe auf das Verzeichnis /export/samba/netlogon, muss das Skript den Namen /export/samba/netlogon/fred.bat tragen. Da diese Skripten auf den Client heruntergeladen und auf der Windows-Seite ausgeführt werden, müssen sie an Stelle der Unix-Newline-Zeichen Newline-Zeichen im MS-DOS-Stil enthalten.

logon path

Diese Option legt fest, wo die Roaming-Profile abgelegt werden. Wenn sich der Benutzer anmeldet, wird vom Server ein Roaming-Profil auf den Client heruntergeladen und während der Sitzung als lokales Profil verwendet. Meldet sich der Benutzer wieder ab, wird der Inhalt des lokalen Profils wieder auf den Server hochgeladen, bis der Benutzer sich irgendwann wieder anmeldet.

Oft ist es sicherer, eine eigene Freigabe anzulegen, die ausschließlich zum Speichern der Benutzerprofile eingesetzt wird:

[global]
 
	logon path = \\hydra\profile\%U
 

Nähere Informationen über diese Option finden Sie im Abschnitt »Roaming-Profile« weiter oben in diesem Kapitel.

logon drive

Diese Option gibt den Laufwerkbuchstaben auf einem Windows NT/2000/XP-Client an, auf den das mit der Option logon home festgelegte Home-Verzeichnis abgebildet wird. Beachten Sie, dass diese Option nur bei Windows NT/2000/XP-Clients funktioniert, zum Beispiel:

[global]
 
	logon drive = I:
 

Sie sollten immer Laufwerkbuchstaben verwenden, die nicht mit fest zugewiesenen Laufwerken auf der Client-Maschine kollidieren. Die Vorgabe Z: ist insofern eine gute Wahl, als sie so weit wie möglich von A:, C: und D: entfernt ist.

logon home

Diese Option legt den Standort des Home-Verzeichnisses eines Benutzers für die Verwendung durch die MS-DOS-net-Befehle fest. Um beispielsweise ein Home-Verzeichnis als Freigabe auf einem Samba-Server anzugeben, verwenden Sie Folgendes:

[global]
 
	logon home = \\hydra\%U
 

Das funktioniert ganz gut mit dem [homes]-Dienst, Sie können aber auch jedes andere Verzeichnis angeben. Home-Verzeichnisse können mit dem folgenden Befehl mit einem Anmeldeskript verknüpft werden:

C:\>net use i: /home  
 

Systemrichtlinien

Eine Systemrichtlinie kann in einer Windows NT-Domäne als Werkzeug zur Fernverwaltung eingesetzt werden. Sie hilft bei der Implementierung einer ähnlichen Rechnerumgebung auf allen Clients und bei der Beschränkung der Fähigkeit der Benutzer, Konfigurationseinstellungen auf ihren Systemen zu ändern, bzw. ermöglicht es, nur die Ausführung bestimmter Programme zu erlauben. Eine Anwendungsmöglichkeit für Systemrichtlinien besteht darin, sie zusammen mit Mandatory-Profilen einzusetzen, um eine Gruppe von Computern für die öffentliche Benutzung einzurichten, beispielsweise in einer Bibliothek, einer Schule oder einem Internetcafé.

Eine Systemrichtlinie ist eine Sammlung von Registry-Einstellungen, die in einer Datei auf dem PDC gespeichert und automatisch auf den Client heruntergeladen werden, wenn sich Benutzer an der Domäne anmelden. Die Datei, in der die Einstellungen enthalten sind, wird auf einem Windows-System mit Hilfe des Systemrichtlinien-Editors erstellt. Da das Format der Registry bei Windows 95/98/Me und Windows NT/2000/XP unterschiedlich ist, muss sichergestellt werden, dass die Datei im richtigen Format erzeugt wird. Dies ist eine recht einfache Angelegenheit, denn wenn der Systemrichtlinien-Editor unter Windows 95/98/Me ausgeführt wird, erzeugt er eine Datei im Format für Windows 95/98/Me, unter Windows NT/2000/XP verwendet er das von diesen Versionen benötigte Format. Nach dem Erstellen der Datei mit dem Systemrichtlinien-Editor wird sie auf dem primären Domänen-Controller gespeichert und während der Anmeldung durch die Clients automatisch heruntergeladen. Die Richtlinien werden dann auf das Client-System angewendet.

Unter Windows NT 4.0 Server können Sie den Systemrichtlinien-Editor ausführen, indem Sie sich als Administrator oder als ein anderer Benutzer aus der Gruppe der Administratoren anmelden, das Start-Menü öffnen und Programme, dann Verwaltung (Allgemein) und anschließend Systemrichtlinien-Editor wählen. Unter Windows 2000 Advanced Server öffnen Sie das Start-Menü und klicken auf Ausführen... Im sich öffnenden Dialog geben Sie C:\winnt\poledit.exe ein und klicken dann auf ok.

Wenn Sie eine andere Windows-Version als NT Server oder Windows 2000 Advanced Server einsetzen, müssen Sie den Systemrichtlinien-Editor installieren. Allerdings ist es etwas kompliziert, eine Kopie davon zu bekommen. Falls Sie Windows NT 4.0 Workstation oder Windows 2000 Professional verwenden und eine Windows NT 4.0 Server-Installations-CD-ROM besitzen, können Sie die Datei \Clients\Svrtools\Winnt\Setup.bat von dieser CD ausführen, um die Client-based Network Administration Tools zu installieren, zu denen auch poledit.exe gehört. Öffnen Sie dann das Start-Menü, klicken Sie auf Ausführen..., geben Sie dort C:\winnt\system32\poledit.exe ein und klicken Sie auf ok.

Falls Sie Windows 95/98 verwenden, legen Sie eine Windows 95- oder Windows 98-CD-ROM4 in Ihr CD-ROM-Laufwerk ein, öffnen die Systemsteuerung und doppelklicken auf den Button Software. Klicken Sie auf das Register Windows Setup und dann auf den Button Diskette... Im nun erscheinenden Dialog klicken Sie auf Durchsuchen... und wählen das CD-ROM-Laufwerk aus dem Drop-down-Menü Laufwerke. Wenn Sie:

Im Dateinamenbereich auf der linken Seite des Dialogs sollte »grouppol.inf« stehen. Klicken Sie auf die OK-Buttons in den beiden Dialogen. Ihnen wird ein Dialogfeld präsentiert, in dem Sie die beiden Optionsfelder Gruppenrichtlinien und Systemrichtlinien-Editor aktivieren müssen. Klicken Sie nun auf den Button Installieren. Schließen Sie die verbleibenden Dialoge. Nun können Sie den Systemrichtlinien-Editor ausführen, indem Sie das Start-Menü öffnen und dann Programme, Zubehör, Systemprogramme, Systemrichtlinien-Editor wählen. Oder Sie klicken im Start-Menü auf Ausführen... und geben C:\Windows\Poledit ein.

Wenn der Systemrichtlinien-Editor startet, wählen Sie Neue Richtlinie aus dem Datei-Menü. Das sich öffnende Fenster sieht so ähnlich aus wie das in Abbildung 4-14.
Abbildung 4-14
Das Fenster des Systemrichtlinien-Editors

Der nächste Schritt besteht darin, eine Auswahl aus dem Datei-Menü zu treffen, um Richtlinien für Benutzer, Gruppen und Computer hinzuzufügen. Bei jedem Eintrag, den Sie hinzufügen, werden Sie nach dem Benutzernamen oder dem Namen der Gruppe oder des Computers gefragt. Außerdem taucht jeweils ein neues Symbol im Fenster auf. Wenn Sie auf eines dieser Symbole doppelklicken, öffnet sich ein Eigenschaften-Dialog, zu sehen in Abbildung 4-15.
Abbildung 4-15
Der Eigenschaften-Dialog des Systemrichtlinien-Editors

Das obere Fenster in diesem Dialog zeigt die Registry-Einstellungen, die als Teil der Systemrichtlinien modifiziert werden können. Das untere Fenster zeigt beschreibende Informationen oder weitere Einstellungen, die zu den im oberen Fenster ausgewählten gehören. Beachten Sie in der Abbildung, dass es drei Optionsfelder gibt, die in unterschiedlichen Zuständen vorliegen:

Markiert
Bedeutet, dass die Registry-Einstellung in der Richtlinie aktiviert ist.
Weiß (nicht markiert)
Löscht die Registry-Einstellung.
Grau
Sorgt dafür, dass die Registry-Einstellung auf dem Client unverändert bleibt.

Wenn alle Einträge grau bleiben (Voreinstellung), haben die Systemrichtlinien keine Auswirkungen. Die Registry des angemeldeten Clients wird nicht verändert. Sind jedoch einer oder mehrere der Einträge markiert oder nicht markiert (weiß), wird die Registry auf dem Client verändert. Das heißt, die Einstellung wird entsprechend aktiviert oder gelöscht.


Wir liefern Ihnen in diesem Abschnitt genügend Informationen zur Benutzung des Systemrichtlinien-Editors, um erst einmal anzufangen bzw. um sich so richtig ins Unglück stürzen zu können. Denken Sie daran, dass eine Systemrichtlinie, die einmal aktiviert wurde, die Registrys aller Clients verändert, die sich an der Domäne anmelden. Die üblichen Warnungen bezüglich der Bearbeitung einer Windows-Registry gelten natürlich auch hier, allerdings sind sie hier noch wichtiger. Bedenken Sie, wie schwierig (wenn nicht gar unmöglich) es für Sie sein wird, die Registrys auf all den Clients wiederherzustellen, falls etwas schiefgeht. Wie bei den Roaming-Profilen kann eine allzu lässige oder sorglose Implementierung von Systemrichtlinien leicht zu einer domänenweiten Katastrophe führen.
Das Erstellen einer guten Systemrichtliniendatei ist ein komplexes Thema, das wir hier nicht in aller Ausführlichkeit behandeln können. Es wäre ein ganzes Buch notwendig, und siehe da, es gibt ein O'Reilly-Buch zum Thema: Windows System Policy Editor. Eine andere wichtige Quelle mit Dokumentationen zu Windows NT-Systemrichtlinien und dem Systemrichtlinien-Editor ist das Microsoft-Whitepaper Implementing Policies and Profiles for Windows NT 4.0, das unter http://www.microsoft.com/ntserver/techresources/management/prof_policies.asp zu finden ist.

Sobald Sie eine Richtlinie erzeugt haben, klicken Sie auf ok und speichern sie. Benutzen Sie den Dateinamen config.pol für eine Windows 95/98-Systemrichtlinie und ntconfig.pol für eine Richtlinie, die auf Windows NT/2000/XP-Clients verwendet werden soll. Kopieren Sie schließlich die .pol-Datei in das für die [netlogon]-Freigabe verwendete Verzeichnis auf dem Samba-PDC. Die Dateien config.pol und ntconfig.pol müssen in dieses Verzeichnis geschrieben werden - im Gegensatz zu Roaming-Profilen und Anmeldeskripten gibt es keine Möglichkeit, den Ablageort der Systemrichtlinien-Dateien in smb.conf festzulegen. Wenn Sie unterschiedliche Systemrichtlinien für unterschiedliche Benutzer oder Computer wünschen, müssen Sie diesen Teil der Konfiguration im Systemrichtlinien-Editor ausführen.


Seien Sie vorsichtig, falls Sie Windows Me-Clients in Ihrem Netzwerk haben oder einsetzen wollen. Microsoft hat behauptet, dass Windows Me Systemrichtlinien nicht unterstützt. Das Eigenartige daran ist, dass es eine Richtlinie aus einer config.pol-Datei auf dem PDC herunterlädt, es aber keine Garantie dafür gibt, dass die Ergebnisse wie erwartet ausfallen. Prüfen Sie die Auswirkungen Ihrer Systemrichtlinie auf Ihren Windows Me-Clients, um sicherzugehen, dass alles wie gewünscht funktioniert.

Wenn ein Benutzer sich an der Domäne anmeldet, lädt sein Windows-Client die .pol-Datei vom Server herunter. Die Einstellungen in dieser Datei (das heißt die Elemente, die im Systemrichtlinien-Editor angeklickt oder gelöscht wurden) setzen die Einstellungen des Clients außer Kraft.

Wenn alles funktionieren »sollte«, es aber nicht tut, versuchen Sie, den Windows-Client herunterzufahren und neu zu starten, anstatt sich einfach nur ab- und wieder anzumelden. Windows hält manchmal die [netlogon]-Freigabe über mehrere Sitzungen hinweg offen. Dies kann verhindern, dass der Client die aktualisierte .pol-Datei vom Server erhält.

Samba als Domänen-Member-Server

Bisher haben wir uns darauf konzentriert, Samba als primären Domänen-Controller zu konfigurieren und einzusetzen. Falls Sie in Ihrem Netzwerk bereits einen Domänen-Controller haben, entweder ein Windows NT/2000-Server-System oder einen Samba-PDC, können Sie einen Samba-Server als Domänen-Member-Server in die Domäne aufnehmen. Dies schließt das Einrichten eines Computerzugangs für den Samba-Server auf dem primären Domänen-Controller ein, wie ja auch Windows NT/2000/XP-Clients Computerzugänge auf einem Samba-PDC haben können. Wenn ein Client auf Freigaben auf dem Samba-Domänen-Member-Server zugreift, leitet Samba die Authentifizierung an den Domänen-Controller weiter, anstatt die Aufgabe auf dem lokalen System auszuführen. Ist der PDC ein Windows-Server, könnten auch beliebig viele Windows-BDCs existieren, die an Stelle des PDC die Authentifizierung durchführen.

Der erste Schritt besteht darin, den Samba-Server in die Domäne aufzunehmen. Dazu wird für ihn auf dem primären Domänen-Controller ein Computerzugang angelegt. Sie können dies mit dem Befehl smbpasswd erledigen:

# smbpasswd -j DOMÄNE -r PDCNAME -Uadmin_zugang%kennwort
 

In diesem Befehl wird DOMÄNE durch den Namen der Domäne ersetzt, der der Samba-Host beitritt, PDCNAME wird durch den Computernamen des primären Domänen-Controllers ersetzt, admin_zugang wird durch den Benutzernamen eines administrativen Zugangs auf dem Domänen-Controller ersetzt (entweder Administrator oder ein anderer Benutzer aus der Gruppe der Administratoren unter Windows NT/2000 und root auf Samba), und kennwort wird durch das Kennwort dieses Benutzers ersetzt. Hier ein etwas konkreteres Beispiel: In unserer Domäne, die einen Windows NT 4 Server-PDC oder einen Windows 2000 Active Directory-Domänen-Controller namens SINAGUA besitzt, würde der Befehl folgendermaßen lauten:

# smbpasswd -j METRAN -r SINAGUA -UAdministrator%hup8ter
 

Wäre der PDC ein Samba-System, würden wir diesen Befehl verwenden:

# smbpasswd -j METRAN -r toltec -Uroot%jwun83jb
 

wobei jwun83jb das Kennwort für den root-Benutzer ist, das in der Datei smbpasswd enthalten ist, wie wir weiter oben in diesem Kapitel ausgeführt haben.

Wenn Sie alles richtig gemacht haben, antwortet smbpasswd mit einer Meldung, die besagt, dass der Domäne beigetreten wurde. Die vom PDC an Samba zurückgelieferte Sicherheits-ID5 wird in der Datei /usr/local/samba/private/secrets.tdb abgelegt. Die Information in secrets.tdb ist sicherheitsrelevant, schützen Sie deshalb die Datei secrets.tdb auf die gleiche Weise wie die Samba-Kennwortdatei.

Der nächste Schritt besteht darin, die Datei smb.conf zu verändern. Vorausgesetzt, Sie beginnen mit einer gültigen smb.conf-Datei, die Samba korrekt für den Betrieb in einer Arbeitsgruppe konfiguriert, wie die in Kapitel 2 verwendete Datei, müssen dazu einfach nur die folgenden drei Zeilen in den Abschnitt [global] aufgenommen werden:

workgroup = METRAN
 
security = domain
 
password server = *
 

Die erste Zeile legt den Namen der Domäne fest (auch wenn dort »workgroup« steht). Benutzen Sie statt METRAN den Namen Ihrer gewünschten Domäne. Da die Sicherheit auf »domain« gesetzt wird, übergibt Samba die Authentifizierung an einen Domänen-Controller. Die Zeile password server = * weist Samba an, den Domänen-Controller für die Authentifizierung (bei dem es sich um den PDC oder um einen BDC handeln kann) zu ermitteln, indem der WINS-Server abgefragt wird oder Broadcast-Pakete eingesetzt werden, falls kein WINS-Server zur Verfügung steht.

An dieser Stelle wäre es klug, testparm auszuführen, um zu prüfen, ob Ihre smb.conf fehlerfrei ist. Anschließend starten Sie die Samba-Daemons neu.

Ist der PDC ein Windows NT-System, können Sie mit Hilfe des Server-Managers prüfen, ob der Samba-Server erfolgreich hinzugefügt wurde. Öffnen Sie das Start-Menü, wählen Sie Programme, dann Verwaltung (Allgemein) und danach Server-Manager. Der Server-Manager startet mit einem Fenster, das ähnlich aussieht wie das in Abbildung 4-16.
Abbildung 4-16
Das Windows NT Server-Manager-Fenster

Wie Sie sehen können, haben wir sowohl toltec als auch mixtec in eine Domäne aufgenommen, für die das Windows NT 4.0 Server-System sinagua als primärer Domänen-Controller fungiert.

Sie können Ihre Einstellungen unter Windows 2000 Advanced Server prüfen, indem Sie das Start-Menü öffnen und dort Programme, Verwaltung, Active Directory Benutzer und Computer wählen. Das sich öffnende Fenster sieht etwa so aus wie das in Abbildung 4-17.
Abbildung 4-17
Das Windows 2000-Fenster Active Directory Benutzer und Computer

Klicken Sie auf Computer auf der linken Seite des Fensters mit der Baumdarstellung. Ihr Samba-System sollte im rechten Feld des Fensters aufgeführt sein.

Optionen für Windows NT-Domänen

Tabelle 4-2 zeigt die Optionen, die üblicherweise im Zusammenhang mit Samba in einer Windows NT-Domäne zum Einsatz kommen.

Tabelle 4-2
Optionen für Windows NT-Domänen 
Option
Parameter
Funktion
Vorgabewert
Geltungsbereich
domain logons
Boolescher Wert
zeigt an, ob Windows-Domänenanmeldungen verwendet werden
No
global
domain master
Boolescher Wert
teilt Samba mit, dass es die Rolle des Domänen-Hauptsuchdiensts übernehmen soll
Auto
global
add user script
String (Befehl)
Skript, das ausgeführt wird, um einen Benutzer- oder Computerzugang anzulegen
keiner
global
delete user script
String (Befehl)
Skript, das ausgeführt wird, um einen Benutzer- oder Computerzugang zu löschen
keiner
global
domain admin group
String (Liste von Benutzern)
Benutzer in der Gruppe Domänen-Admins
keiner
global
domain guest group
String (Liste von Benutzern)
Benutzer in der Gruppe Domain Guests
keiner
global
password server
String (Liste von Computern)
Liste mit Domänen-Controllern, die für die Authentifizierung genutzt werden, wenn Samba als Domänen-Member-Server läuft
keiner
global
machine password timeout
numerisch (Sekunden)
Legt das Erneuerungsintervall für Maschinenkennwörter an der NT-Domäne fest
604.800
(1 Woche)
global

Nun folgen die ausführlichen Erklärungen der einzelnen Optionen für Windows NT-Domänen aus Tabelle 4-2.

domain logons

Diese Option konfiguriert Samba so, dass es Domänenanmeldungen als primärer Domänen-Controller akzeptiert. Wenn sich ein Client erfolgreich an der Domäne anmeldet, liefert Samba ein besonderes Token an den Client zurück, das es dem Client erlaubt, auf Freigaben in der Domäne zuzugreifen, ohne zuvor noch einmal den PDC um Authentifizierung zu bitten. Beachten Sie, dass die Samba-Maschine Sicherheit auf Benutzerebene (security = user) einsetzen und PDC sein muss, damit diese Option funktioniert. Darüber hinaus erwarten Windows-Maschinen, dass auf dem Samba-Server eine [netlogon]-Freigabe existiert.

domain master

In einem Windows-Netzwerk erledigt ein lokaler Hauptsuchdienst die Suche innerhalb eines Subnetzes. Eine Windows-Domäne kann aus mehreren Subnetzen bestehen, die jeweils ihren eigenen lokalen Hauptsuchdienst besitzen. Der primäre Domänen-Controller führt die Funktion eines Domänen-Hauptsuchdiensts aus. Dazu sammelt er die Suchlisten der lokalen Hauptsuchdienste der einzelnen Subnetze. Jeder lokale Hauptsuchdienst fragt den Domänen-Hauptsuchdienst ab und nimmt die Informationen über andere Subnetze in seine eigenen Suchlisten auf. Wenn Samba als primärer Domänen-Controller konfiguriert ist, setzt es automatisch domain master = yes, wodurch es sich selbst zum Domänen-Hauptsuchdienst macht.

Da Windows NT-PDCs die Rolle des Domänen-Hauptsuchdiensts immer für sich beanspruchen, darf Samba niemals zum Domänen-Hauptsuchdienst gemacht werden, wenn es einen Windows-PDC in der Domäne gibt.

add user script

Es gibt zwei Möglichkeiten, add user script zu benutzen. Wenn der Samba-Server als primärer Domänen-Controller eingerichtet ist, kann es einem Befehl zugewiesen werden, der auf dem Samba-Server ausgeführt wird, um einen Windows NT/2000/XP-Computerzugang in die Kennwortdatenbank von Samba aufzunehmen. Wenn der Benutzer auf dem Windows-System die Einstellungen des Computers ändert, um einer Domäne beizutreten, wird er nach dem Benutzernamen und dem Kennwort eines Benutzers gefragt, der auf dem Domänen-Controller administrative Rechte besitzt. Samba authentifiziert diesen Benutzer und führt dann das add user script mit root-Rechten aus.

Wenn Samba als Domänen-Member-Server konfiguriert ist, kann add user script mit einem Befehl zum Anlegen eines Benutzers am System verknüpft sein. Dies erlaubt es Windows-Clients, Benutzer anzulegen, die auf Freigaben auf dem Samba-System zugreifen dürfen, ohne dass ein Administrator manuell auf dem Samba-Host einen Zugang anlegen muss.

delete user script

Es gibt Gelegenheiten, bei denen Benutzer automatisch aus der Domäne gelöscht werden. delete user script kann einem Befehl zugewiesen werden, der einen Benutzer so von dem Samba-Host entfernt, wie es ein Windows-Server tun würde. Vermutlich wollen Sie jedoch nicht, dass dies passiert, weil der Unix-Benutzer den Zugang möglicherweise aus anderen Gründen benötigt als zur Benutzung mit Samba. Wir empfehlen Ihnen daher, diese Option nur mit großer Sorgfalt einzusetzen.

domain admin group

In einer Domäne mit Windows-Systemen ist es einem Server immer möglich, von einem Domänen-Controller eine Liste der Mitglieder aus der Gruppe der Domänen-Administratoren zu beziehen. Samba 2.2 besitzt nicht die Fähigkeit, dies zu erledigen. Der Parameter domain admin group dient als Möglichkeit, Samba sozusagen manuell darüber zu informieren, wer in der Gruppe ist. Die Liste sollte root (notwendig zum Anlegen von Benutzerzugängen) und alle Benutzer von Windows NT/2000/XP-Clients der Domäne enthalten, die in der Gruppe der Domänen-Administratoren sind. Diese Benutzer müssen vom PDC erkannt werden, damit sie ihre administrativen Aufgaben, wie das Anlegen neuer Benutzer in der Domäne, durchführen können.

password server

In einer Windows-Domäne, in der die Domänen-Controller ein Windows-PDC sowie mehrere Windows-BDC sind, authentifizieren die Clients und die Domänen-Member-Server die Benutzer, indem sie entweder den PDC oder einen der BDCs abfragen. Ist Samba als Domänen-Member-Server konfiguriert, bietet der Parameter password server eine gewisse Kontrolle darüber, wie Samba einen Domänen-Controller findet. Frühere Versionen von Samba konnten nicht die gleiche Methode verwenden wie Windows-Systeme, deshalb war es notwendig, eine Liste von Systemen anzugeben, die ausprobiert werden konnten. Wenn Sie password server = * setzen, ist Samba 2.2 in der Lage, den Domänen-Controller auf die gleiche Weise zu suchen wie Windows, wodurch die Anfragen auf mehrere BDCs verteilt werden können. Durch diese Maßnahme verringert sich die Gefahr, dass die BDCs auf Grund der Authentifizierungsanfragen überlastet werden. Wir empfehlen Ihnen, diese Methode einzusetzen.

machine password timeout

Die globale Option machine password timeout legt eine Laufzeit für Maschinenkennwörter in einer Windows NT-Domäne fest. Standardmäßig wird zurzeit der gleiche Wert benutzt wie bei Windows NT 4.0: 604.800 Sekunden (eine Woche). Samba versucht periodisch, das Maschinenkennwort zu ändern. Dabei handelt es sich um ein Kennwort, das speziell von einem anderen Server verwendet wird, um über Änderungen zu berichten. Diese Option gibt in Sekunden an, wie lange Samba warten soll, bevor es versucht, das Kennwort zu ändern. Die Timeout-Periode kann mit dem folgenden Befehl auf einen Tag geändert werden:

[global]
 
	machine password timeout = 86400
 

Falls Sie mehr darüber wissen wollen, wie Windows NT Domänen-Benutzernamen und -gruppen verwendet, empfehlen wir das Buch Windows NT in a Nutshell von Eric Pearce (O'Reilly & Associates).
1Wenn wir bei unseren Ausführungen über Windows NT-Domänen in diesem Buch Windows XP einschließen, beziehen wir uns auf Windows XP Professional und nicht auf die Home-Edition. Der Grund dafür wird im Abschnitt über Windows XP weiter unten in diesem Kapitel erläutert.
2Der Eintrag in /etc/passwd ist möglicherweise in künftigen Samba-Versionen nicht mehr erforderlich.
3Falls Sie unser Beispiel in diesem Abschnitt verfolgen wollen, Ihr Netzwerk aber keine Windows-Systeme enthält, die Freigaben anbieten, lesen Sie in Kapitel 5 nach, wie Sie eine Freigabe anlegen. Sie sollten zuerst verstanden haben, wie Freigaben eingerichtet werden, bevor Sie mit den hier gezeigten Anweisungen fortfahren!
4Die mit Windows 98 gelieferte Version des Systemrichtlinien-Editors ist ein Update der mit Windows 95 ausgelieferten Version. Verwenden Sie nach Möglichkeit die Version der Windows 98-Distribution.
5Diese Sicherheits-ID (SID) ist Teil eines Zugriffs-Tokens, das dem PDC erlaubt, den Client zu identifizieren und zu authentifizieren.

TOC PREV NEXT INDEX

Copyright © 2003 by O'Reilly Verlag GmbH & Co.KG