»Nein, es tut mir leid ... ich verstehe. Ja, ich weiß, dass Ihre Bookmarks in Netscape wichtig sind. Es ist nur so, dass sie auf der lokalen Festplatte Ihres PC gespeichert waren, und als er abstürzte ... nun, ich kann leider nichts für Sie tun.« Ich höre ein lautes Klicken, als der andere Teilnehmer an dieser Unterhaltung wütend auflegt.
»Es muss einen besseren Weg geben«, seufze ich. »Das Beste wäre, sein Netscape-Profileverzeichnis auf einem Netzwerklaufwerk zu speichern. Dann würde es mit in die allnächtlichen Backups aufgenommen werden. Ich muss aber die Cache-Dateien gar nicht speichern. Ich könnte das Caching ausschalten ... oder ich könnte das Cache-Verzeichnis auf der lokalen Festplatte einrichten. Nachdem die Lesezeichendateien auf einem Netzwerklaufwerk sind, könnte ich sogar je nach Bedarf Einstellungen ändern und Probleme behandeln, ohne in irgendein Büro gehen oder die Dinge über das Telefon erklären zu müssen!«
»Das gefällt mir«, sage ich mit einem halben Grinsen. Es ist ein Grinsen der Zufriedenheit. »Hmmm, aber wie kann ich garantieren, dass das Home-Verzeichnis des Benutzers gemountet wird und sich auf dem richtigen Laufwerksbuchstaben befindet?«, frage ich mich. «Wenn ich nur sicherstellen könnte, dass jeder beim Einloggen die gleichen Freigaben mountet.«
Kennen Sie das? Wenn Sie schon einmal PCs in einem beliebigen Netzwerk verwaltet haben, haben Sie wahrscheinlich all die Geschichten und Beschwerden gehört. In diesem Kapitel möchte ich Ihnen zeigen, wie Sie Samba als Domain Controller (DC) für Windows-9x-Clients einrichten können, um einige dieser Probleme zu lösen. Das gleiche Setup funktioniert auch für Windows für Worksgroups und den MS-DOS-Client, aber ich werde mich hier nicht auf diese konzentrieren.
Ich hoffe, dass Sie nach der Lektüre dieses Kapitels einige Mechanismen kennen gelernt haben, die Ihr Leben etwas einfacher machen. Ich weiß, dass einige dieser Dinge mir wirklich geholfen haben.
Erinnern Sie sich noch daran, dass ich in Kapitel 2, »Windows-Netzwerke«, über Domänen und Arbeitsgruppen gesprochen habe? Ich hoffe, dass die zwei Konzepte mittlerweile etwas mehr Sinn ergeben, falls Sie noch nicht mit ihnen vertraut waren. Lassen Sie uns die zwei Abbildungen noch einmal ansehen (Abbildung 21.1 und 21.2).
Abb. 21.1: Beispiel für eine Arbeitsgruppe
Während Sie sich die Abbildungen 21.1 und 21.2 ansehen, denken Sie an das Konzept des Einloggens in das Netzwerk. An diesem Punkt ist das Netzwerk eine vage Idee, so wie wenn jemand sagt: »Nun, du weißt, was die Leute sagen«. Wer sind die Leute? Niemand weiß es genau.
Der Unterschied zwischen der Anmeldung in einem Netzwerk in einer Arbeitsgruppenumgebung und einem anderen in einer Domänenumgebung besteht darin, dass in einer Domäne das Login wirklich authentifiziert wird! In einer Arbeitsgruppe werden die Benutzerinformationen vom lokalen Rechner einfach zwischengespeichert, um sie im Falle einer Verbindung an andere Server weiterzuleiten. Wenn Sie nun noch einmal zu Abbildung 21.2 zurückgehen, werden Sie feststellen, dass der gleiche DC, der das Login authentifiziert hat, jede Verbindung zu einer Freigabe authentifiziert, die von einem anderen Mitglied der Domäne zur Verfügung gestellt wird. Diese Realisierung bringt uns zu meinen neuen Illustrationen von Arbeitsgruppen und Domänen in den Abbildungen 21.3 und 21.4.
Wie hilft uns das weiter? Zunächst einmal, wenn der Benutzer beim Login in eine Arbeitsgruppe ein falsches Passwort oder einen falschen Benutzernamen eingibt, akzeptiert das Windows-9x-System dies, ohne eine Reaktion zu zeigen. Ohne Verbindung zu einem Server ist es für das lokale System natürlich nicht möglich, eine Reaktion zurückzugeben.
Lassen Sie mich hier einen kurzen Rückzieher machen. Windows 9x kann den Benutzernamen und das Passwort anhand einer lokalen Passwort-Cache-Datei authentifizieren. Diese Dateien können im Verzeichnis \windows gefunden werden und haben die Erweiterung *.pwl. Meiner Meinung nach sind diese Dateien teuflisch. Vielleicht nicht so teuflisch, dass sie das Ende der Welt bedeuten, aber immerhin. Sie verwenden schwache Verschlüsselungsalgorithmen und sind leicht genug zu knacken. Daher stellen sie ein Loch in meinem heiligen Netzwerk-Sicherheitsmodell dar und müssen entsprechend behandelt werden.
Abb. 21.3: Einloggen in das Netzwerk in einer Arbeitsgruppenumgebung
Okay. Vielleicht habe ich heute zu viel Kaffee getrunken, aber hier ist der Knüller. Passwort-Cache-Dateien sind leicht zu knacken. Sie sind außerdem ärgerlich. Wenn Sie Ihr Passwort auf dem DC ändern, müssen Sie Ihr Passwort auch auf dem lokalen Windows-Rechner ändern. Der Hauptzweck für eine Passwort-Cache-Datei besteht darin, alle Passwörter zu sammeln, die ein Benutzer für den Zugriff auf Server in einer Arbeitsgruppe braucht. Wenn Sie sich in das System mit pass1 einloggen und sich dann mit pass2 mit \\server-a verbinden, versucht Windows zuerst, sich mit pass1 und dann mit pass2 mit dem Server zu verbinden, das in Ihrer entsprechenden *.pwl-Datei gespeichert wurde. Windows öffnet Ihre Passwort-Cache-Datei mit Ihrem Login-Passwort als Schlüssel, damit das System alle in der Datei gefundenen Passwörter verwenden kann. In einer Domänenumgebung braucht ein Benutzer nur ein Passwort, also ist der ursprüngliche Gedanke hinter Passwort-Cache-Dateien nicht mehr gültig. Könnte jemand eine dieser *.pwl-Dateien, die ein Domänenpasswort enthält, stehlen und knacken, hätte der Eindringling außerdem Zugriff auf jeden Server, der das Recht verteilt, sich über das Netzwerk in diesen Account einzuloggen.
Aus diesen Gründen setze ich voraus, dass Sie das Passwort-Caching deaktiviert haben. Dies können Sie über den Policy-Editor tun, über den ich am Ende dieses Kapitels kurz reden werde, oder Sie können einfach alle *.pwl-Dateien in Ihrem \windows-Verzeichnis löschen, den folgenden Eintrag in die lokale System-Registry einfügen und dann neu starten:
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Network]
Das Bearbeiten der Registry kann Ihr System unbrauchbar machen. Gehen Sie mit äußerster Sorgfalt vor, wenn Sie den Registrierungseditor (regedit.exe) benutzen.
Ist das Passwort-Caching deaktiviert, kann ich unbeirrt zu meiner ursprünglichen Aussage stehen: Beim Einloggen in eine Arbeitsgruppe findet keine Authentifizierung statt, bis die erste Verbindung zu einem SMB-Server eingegangen wird.
Jetzt kehre ich wieder zu meinem Ausgangspunkt zurück. Wenn sich ein Benutzer in eine Arbeitsgruppe einloggt, kann das lokale System keine Reaktion zur Gültigkeit des Benutzername/Passwort-Paars zurückgeben. Wenn sich ein Benutzer jedoch in eine Domäne einloggt, werden der Benutzername und der Beweis für die Identität an den Domänen-Controller gesendet, der eine Antwort zurückgibt, in der das Login entweder akzeptiert oder abgelehnt wird.
Wie hilft Ihnen das alles? In einem gewissen Sinne hilft es mehr dem Benutzer. Nehmen wir an, ein Benutzer hat den Login-Namen beckett. Nehmen wir weiterhin an, dass er sich in die Arbeitsgruppe einloggt, aber seinen Namen falsch als beclett eingibt. Jedesmal, wenn der Benutzer versucht, sich während dieser Arbeitssitzung mit einer Netzwerkressource zu verbinden, übertragen die lokalen Sitzungen den Namen becklett als Benutzernamen für die Sitzungsaufnahme. Dies würde wahrscheinlich in Anrufen an Ihre Supportabteilung enden, in denen sich der Benutzer beschwert, dass »das Netzwerk mein Passwort nicht mag, aber ich weiss, dass ich es richtig eingebe«. Würde die gleiche Situation in einer Domänenumgebung stattfinden, würde der DC sich über ein falsches Benutzername/Passwort-Paar beschweren, damit das lokale System dies dem Benutzer mitteilen kann.
Das ist genug der theoretischen und philosophischen Erklärungen der Domänenkontrolle. Lassen Sie uns nun ansehen, wie Sie sie implementieren können und mit welcher Art von Tricks und kleinen Spielzeugen ich arbeite.
Die erste Voraussetzung für die Konfiguration von Samba als Domänen-Controller ist, dass der Server im User-Modus operiert. security = server funktioniert ebenfalls, da Samba dann bekannt gibt, dass es den User-Modus verwendet.
security = userSo ist es. Samba kann nicht im Share-Modus arbeiten und gleichzeitig als Domain-Controller agieren.
Danach sollten Sie sicherstellen, dass Samba der Master-Browser für die Domäne ist. Denken Sie an die NetBIOS-Ressourcentypen, über die ich in Kapitel 2 gesprochen habe, die mit Namen verbunden sind. Ein Domänen-Controller, ob es sich nun um einen Windows-NT-PDC oder einen Samba-Rechner handelt, muss den NetBIOS-Namen Domänenname<1b> erfolgreich registrieren können. Der Ressourcentyp <1b> bezeichnet den Master-Browser für eine Domäne, und darüber lokalisieren Windows-Clients den Login-Server der Domäne. Dies sollte aus den Kapiteln 19, »Browsing in lokalen Subnetzen«, und 20, »Browsing in Netzwerken mit Routern«, klar sein. Die einfachste Methode, dies jetzt zu konfigurieren, besteht im Einfügen folgender Parameter in Ihre smb.conf-Datei:
os level = 64Die dritte Voraussetzung ist, dass Sie Samba mitteilen, dass der Server als Domänen-Controller agieren sollte, indem Sie den Parameter domain logons setzen:
domain logons = yesUnd schließlich müssen Sie eine Freigabe namens [netlogon] in der smb.conf erstellen. Alle Windows-9x-Clients, die versuchen, sich in eine Domäne einzuloggen, verbinden sich mit dieser Freigabe. Die Freigabe [netlogon] muss nicht unbedingt Daten enthalten, sie muss nur existieren, und Benutzer müssen sich erfolgreich mit ihr verbinden können. Hier ein einfaches Beispiel, das Sie benutzen werden:
[netlogon]Ich möchte hier eine Sache erwähnen, die optional ist, die ich aber sehr zu schätzen gelernt habe. Mit der Domänenkontrolle kommt die Fähigkeit, eine Batch-Datei zu spezifizieren, die gestartet wird, wenn ein Benutzer sich erfolgreich in die Domäne einloggt. Diese Batch-Datei sollte irgendwo in die [netlogon]-Freigabe platziert werden; sie wird über den Parameter logon script spezifiziert. Der Dateiname selbst kann jedes der Standard-smb.conf-Makros enthalten, aber Parameter, die an die Batch-Datei geleitet werden, können dies nicht. Die folgende Einstellung z.B. funktioniert genauso, wie Sie es sich vorstellen:
logon script = %U.batDas Login-Skript für eine Verbindung wird auf Benutzername.bat gesetzt, wobei Benutzername aus den Informationen zur Sitzungsanfrage geholt wird.
Würde sich der Benutzer beckett erfolgreich einloggen, so würde der Windows-Client folgende Datei zu starten versuchen:
\\server\netlogon\beckett.batWenn Sie jedoch den aktuellen Benutzernamen als Parameter an die Batch-Datei weitergeben wollten, würde Folgendes nicht funktionieren (die Batch-Datei würde %U tatsächlich als einzelnes Befehlszeilenargument erhalten):
logon script = logon.bat %UFür dieses Beispiel werden Sie eine einzige Batch-Datei für alle Benutzer verwenden. Das Skript führt nur einen Befehl aus, der das Home-Verzeichnis des Benutzers mountet. Fügen Sie der smb.conf folgenden Eintrag hinzu:
logon script = logon.batErstellen Sie nun eine Textdatei in \\server\netlogon mit dem Namen logon.bat. Stellen Sie außerdem sicher, dass die Batch-Datei DOS-formatierten Text mit einem CR- und einem LF-Zeichen am Ende jeder Zeile verwendet. Sie können die Datei entweder mit dem in Windows integrierten Editor erstellen oder mit vi und jeder Zeile eine [Strg]+[V]- und [Strg]+[M]-Sequenz anhängen. Hier ist die logon.bat-Datei, die Sie für diese Beispiele verwenden werden:
echo Mapping home directory...Aus Gründen der Vollständigkeit zeigt Listing 21.1 die gesamte smb.conf-Datei, die Sie für Ihren Server eingerichtet haben. Sie werden bemerken, dass Sie Klartextpasswörter benutzen, aber Sambas Funktionen zur Domänenkontrolle funktionieren auch mit verschlüsselten Passwörtern. Für jede Methode sollten Sie sicherstellen, dass Sie die Benutzer-Accounts korrekt eingerichtet haben. Wenn Sie Klartextpasswörter verwenden, überprüfen Sie, ob Sie diese Funktion auf Windows-98-Clients und den benötigten Windows-95-Clients aktiviert haben (siehe Kapitel 12, »Fallstudie: Einen NT-Datei- und Drucker-Server ersetzen«).
Listing 21.1: Samba-Konfigurationsdatei für einen einfachen Windows-9x-Domain-Controller
;Nachdem Sie nun den Samba-Server konfiguriert und gestartet haben, besteht der nächste Schritt darin, den Windows-Client zu konfigurieren, damit er sich in die Domäne einloggt. Vorausgesetzt, dass Sie den Windows-Rechner bereits für den Zugriff auf den SMB-Server konfiguriert haben, sind nur wenige Schritte notwendig. Abhängig von Ihrer Netzwerktopologie, kann sogar nur ein Schritt nötig sein.
Abbildung 21.5 zeigt das Fenster Eigenschaften für den Client für Microsoft-Netzwerke. Um darauf zuzugreifen, öffnen Sie das Netzwerkkontrollfenster, markieren den Eintrag Client für Microsoft-Netzwerke und klicken auf die Schaltfläche Eigenschaften. Wählen Sie die Option An Windows NT-Domäne anmelden im Abschnitt Anmeldebestätigung, und geben Sie den Namen der Domäne ein, die Sie benutzen wollen. Klicken Sie dann so lange auf OK, bis das Netzwerkfenster wieder geschlossen wird. An diesem Punkt will Windows eventuell einige Dateien von der Windows-95-Installations-CD kopieren (warum das System Dateien kopieren muss, wenn der Client bereits installiert ist, ist für mich nicht nachvollziehbar, aber ...). Danach müssen Sie das System neu starten, damit die Änderungen in Kraft treten können.
Abb. 21.5: Einen Windows-95-OSR2-Client konfigurieren, damit er sich in die Domäne CHIPSNDIPS einloggt
Nachdem der PC neu gestartet ist, sollten Sie das vertraute Login-Dialogfeld sehen, mit der Ausnahme, dass es diesmal ein zusätzliches Feld mit dem Domänennamen enthält (siehe Abbildung 21.6), der in Abbildung 21.5 spezifiziert wurde.
Abb. 21.6: Das Netzwerk-Login-Dialogfeld unter Windows, das die Domäne (CHIPSNDIPS) enthält, über die authentifiziert wird
Sie werden möglicherweise zwei übliche Fehlermeldungen sehen, wenn Sie versuchen, sich in die Domäne einzuloggen. Abbildung 21.7 zeigt die erste. Die Meldung ist Windows Art und Weise, Ihnen mitzuteilen: »Ich habe herumgefragt, um zu sehen, ob irgend jemand versuchen würde, diesen Benutzernamen und dieses Passwort für mich zu authentifizieren, aber niemand hat geantwortet.«
Abb. 21.7: Windows-Fehlermeldung, wenn der Client den Besitzer des NetBIOS-Namen Domänenname<1b> nicht finden kann. In diesem Beispiel war der Domänenname CHIPSNDIPS
Dies passiert, wenn Windows den Besitzer des NetBIOS-Namens CHIPSNDIPS<1b> nicht finden kann oder der Name in eine IP-Adresse aufgelöst werden konnte, Windows aber keine Antwort vom Server erhalten hat.
Warum sollte der Client den Domänen-Server nicht finden können? Erinnern Sie sich, als ich sagte, dass je nach Ihrer Netzwerktopologie einige Konfigurationsschritte ausgelassen werden können? Wenn Ihr Samba-Domain-Controller und Ihr Windows-Client in verschiedenen Subnetzen sind, kann der Client den Namen CHIPSNDIPS<1b> nicht über die normalen Broadcast-Methoden auflösen, weil IP-Broadcast-Pakete normalerweise nicht von Routern weitergeleitet werden. Damit der Domänen-Controller gefunden wird, muss der Windows-Client einen WINS-Server kontaktieren, bei dem der Domänen-Controller seinen Namen registriert hat. Ich empfehle Ihnen, Ihren Domänen-Controller zunächst mit einem Client im gleichen logischen Subnetz zu testen, aber wenn Sie über Router testen müssen, sollten Sie noch einmal zu Kapitel 18, »NetBIOS-Namen ohne Broadcasts auflösen«, zurückblättern, um zu sehen, wie Sie WINS verwalten.
Eine mögliche Erklärung für die aktuellen Probleme ist, dass der Samba-Domain-Controller den Namen CHIPSNDIPS<1b> nicht erfolgreich registrieren konnte. Sie können dieses Problem in der nmbd-Debug-Logdatei (d.h. /usr/local/samba/var/log.nmb) überprüfen. Konnte Samba den Namen erfolgreich registrieren, werden Sie Einträge wie diese sehen:
[1999/01/23 10:06:46, 0] nmbd/nmbd_become_dmb.c:become_domain_master_stage2(118)Ich habe dies in den Kapiteln 19 und 20 ausführlicher dargestellt, aber der fundamentale Unterschied zwischen einem Domain-Master-Browser (DMB) und einem lokalen Master-Browser (LMB) besteht darin, dass Sie nur einen DMB pro Domäne haben können. Sie sollten dagegen einen LMB für jedes Subnetz haben. Natürlich sollte der DMB auch der LMB für sein logisches Subnetz sein.
Wenn Sie den DMB für eine bestimmte Domäne finden wollen, benutzen Sie das Tool nmblookup, um den Namen Domänenname<1b> aufzulösen:
# nmblookup CHIPSNDIPS#1bDie Ausgabe sollte die IP-Adresse des Samba-Domain-Controllers anzeigen. Ist das nicht der Fall, sollten Sie Ihre smb.conf-Datei noch einmal überprüfen und sicherstellen, dass die Parameter os level, domain master, local master und preferred master so konfiguriert sind, wie ich es vorher dargestellt habe. Überprüfen Sie außerdem, ob der nmbd-Daemon tatsächlich läuft.
Das zweite weit verbreitete Problem, auf das Sie treffen können, wenn Sie versuchen, sich in eine Domäne einzuloggen, ist, dass der Server gefunden wurde, aber »Nein« sagte (siehe Abbildung 21.8). Es gibt im Wesentlichen zwei Möglichkeiten hierfür, abgesehen davon, dass Sie einfach den Benutzernamen und das Passwort falsch eingegeben haben.
Abb. 21.8: Der Domänen-Controller lehnt die Authentifizierung Ihres Passworts ab
Die erste ist, dass der Server die Sitzungsanfrage abgelehnt hat. Ich habe bereits in Kapitel 4, »Installation und Testen der Konfiguration«, über einige Dinge gesprochen, die dies hervorrufen können. Um Ihr Gedächtnis aufzufrischen: Dies kann passieren, wenn die IP-Adresse des Clients nicht im Wert für den Parameter hosts allow in Ihrer smb.conf aufgeführt ist oder in der Auflistung für hosts deny vorkommt.
Eine andere Möglichkeit ist, dass der Server für die Benutzung von Klartextpasswörtern eingerichtet ist, aber der Client nicht auf Klartext herabstufen will. Sie sollten den zwei Lösungen folgen, die bereits in früheren Kapitel aufgelistet waren:
Wenn Sie sich erfolgreich in die Domäne einloggen können, sollten Sie sehen, wie das Login-Skript in einem DOS-Fenster ausgeführt wird, wie in Abbildung 21.9 dargestellt. Das Schöne daran ist, dass, mit einigen Ausnahmen, der Windows-Client den Unterschied zwischen einer von Samba kontrollierten Domäne und einer von Windows NT kontrollierten nicht feststellen kann. Daher werden auch Ihre Benutzer höchstwahrscheinlich den Unterschied nicht merken!
Abb. 21.9: Nach einem erfolgreichen Login wird das Windows-NT-Login-Skript ausgeführt
Ein Vorteil der Benutzung eines Login-Skripts gegenüber der Windows-Einstellung für Dauerverbindungen, die Laufwerksverbindungen initiieren, besteht darin, dass Sie das Login-Skript ändern können, ohne überhaupt am Client-Rechner sitzen zu müssen. Sie können Netzwerkverbindungen neu zuweisen und sogar Patches für das Betriebssystem und für Anwendungen im Login-Skript laufen lassen. Toll! Das ist, was mir gefällt.
Was Sie bis hierhin gesehen haben, ist ziemlich gut. Sie können sicherstellen, dass Benutzer beim Einloggen die korrekten Informationen angeben, Sie können sicher sein, dass jeder Benutzer zumindest einige notwendige Verbindungen zu Netzwerklaufwerken hat, und Sie können andere Dinge während des Logins ausführen. Was können Sie noch tun?
Ich habe es vorher schon gesagt: Das Schöne an dieser Art von Setup ist, dass der Windows-Client meistens gar nicht weiß, dass es sich nicht um einen Windows-NT-Server handelt, der als Domänen-Controller agiert. Die Themen, die ich jetzt darstellen werde, sind nicht Samba-spezifisch, sondern Teil des Windows-9x-Netzwerkmodells. Egal, ob Sie das Modell mögen oder nicht, Sie müssen die Tools benutzen, die Ihnen gegeben werden, um Ihre Aufgabe so gut wie möglich zu erledigen.
Ein Benutzerprofil entspricht in etwa der Sammlung von dot(.)-Dateien, die Unix verwendet, um Logins, Logouts und das Verhalten von Anwendungen zu kontrollieren. Liegt Ihr Hintergrund eher in der Windows-Terminologie, können Sie sich das Profil als eine Sammlung von benutzerspezifischen *.ini-Dateien und Programmgruppen vorstellen. Das Fazit ist, dass Profile es einem Benutzer ermöglichen, seine Umgebung anzupassen, ohne sie permanent mit einem einzelnen Rechner zu verbinden.
Die Windows-Registry 101
Betrachten Sie diesen Abschnitt als Hintergrundinformation, damit wir alle auf dem gleichen Stand sind. Wenn Sie bereits mit der System-Registry vertraut sind, haben Sie einen Moment Geduld.
Die Windows Registry ist eine Datenbank, die aus zwei Binärdateien besteht, system.dat und user.dat. Die Datei system.dat befindet sich immer im \windows-Verzeichnis (oder dem Verzeichnis, in dem Sie Windows installiert haben). Normalerweise ist auch die Datei user.dat dort zu finden. Im Fall von wandernden Profilen jedoch wird sie von einem für den Benutzer spezifischen Platz heruntergeladen.
Die zwei Dateien sind in einer baumartigen Struktur mit sechs Hauptwurzeln zusammengefasst. Abbildung 21.10 zeigt die System-Registry, wie sie im Windows-95-Registrierungseditor dargestellt wird. Ich werde mich hier nur mit zwei dieser Wurzeln beschäftigen: HKEY_LOCAL_MACHINE (HKLM) und HKEY_CURRENT_USER (HKCU).
Abb. 21.10: Die System-Registry, wie sie vom Windows-95-Registrierungseditor (regedit.exe) dargestellt wird
Die HKLM-Struktur (jede der sechs Wurzeln wird als Struktur bezeichnet) sollte nur Informationen enthalten, die für den Rechner lokal sind. Das ist nicht immer der Fall, da Anwendungen nicht immer die Registry benutzen, die sie sollten.
Die HKCU-Struktur enthält Informationen, die für den aktuell eingeloggten Benutzer relevant sind. Beispiele für die Einstellungen, die in der HKCU-Struktur gespeichert sind, sind u.a. Hintergrund- und Bildschirmschoner-Einstellungen, die Liste zuletzt verwendeter Dateien für Anwendungen und andere benutzerspezifische Dateistandorte. Der lokale Rechner kann so eingerichtet werden, dass er die gleichen Benutzerinformationen für jeden verwendet, der sich einloggt, oder dass er Informationen für jeden Benutzer verfolgt. Ersteres ist das Standardverhalten von Windows. In diesem Fall ist die HKCU-Struktur das Gleiche wie die HKEY_USERS- (HKU-)Struktur. Sie können individuelle Profile über die Registerkarte Benutzerprofile im Dialogfeld Passworteigenschaften aktivieren.
Abb. 21.11: Benutzerprofile unter Windows 95 aktivieren
Die Möglichkeit, individuelle Einstellungen in der Registry zu verwalten, kann an sich schon sehr hilfreich sein, aber Windows ermöglicht es Ihnen außerdem, das Start-Menü und die Desktop-Icons mit einem Benutzerprofil zu verbinden.
Sie können individuelle Benutzerprofile auf zwei Arten erstellen. Mit der ersten Methode kann nur ein einzelner Rechner das Benutzerprofil verwenden, das lokal gespeichert ist. Über die zweite Methode kann das Profil dem Benutzer im Netzwerk folgen, so dass jeder Rechner, in den sich der Benutzer einloggt, Zugriff auf das Profil hat. Letzteres wird als umherziehendes oder wanderndes Benutzerprofil bezeichnet.
Wenn der Windows-Client mit aktivierten Benutzerprofilen für das Einloggen in eine Domäne konfiguriert wird, versucht das lokale System automatisch, das Profil im Home-Verzeichnis des Benutzers zu speichern. Das Profil wird dann beim Login vom Netzwerk auf die lokale Festplatte zwischengespeichert und beim Logout wieder zurückgegeben. Abbildung 21.12 zeigt ein Beispiel hierfür.
Wenn Sie Samba als Domänen-Controller benutzen, wird der Platz, an dem Windows das wandernde Profil im Netzwerk speichert, über den Parameter logon path in der smb.conf-Datei festgelegt. Der Standardwert für diesen Parameter ist ein Unterverzeichnis im Home-Verzeichnis des Benutzers mit dem Namen profile. Viele Leute in den Samba-Mailing-Listen haben berichtet, dass es besser ist, Profile in einer separaten Freigabe zu speichern. Definieren Sie z.B. zunächst eine Freigabe namens [profile]:
[profile]Setzen Sie dann den Parameter logon path auf:
logon path = \\Servername\profile\%U Abb. 21.12: Speichern von Profilinformationen im Home-Verzeichnis des Benutzers
Weitere Informationen über wandernde Profile finden Sie im Windows 95 Resource Kit, das im Windows-Hilfeformat auf der Windows-95-Installations-CD im Verzeichnis \admin\reskit verfügbar ist.
Was Profile für Sie tun können
Ich muss eine Rechtfertigung für meine Erklärung von Benutzerprofilen liefern. Wie können sie meine Aufgabe wirklich vereinfachen, statt sie noch schwieriger zu machen? Hier ist ein Beispiel, das ich verwende, um die Windows-95-Studentenlabors zu managen, die ich an meinem Arbeitsplatz verwalte.
Nehmen wir an, Sie haben einen bestimmten Shortcut, den Sie auf den Desktop jedes Benutzers (oder auch in das Start-Menü) platzieren wollen. Was können Sie tun?
Obwohl die dritte Methode funktionieren würde, ziehe ich die letzte vor, da ich lieber Skripte in Perl oder einer Shell-Sprache schreibe als Batch-Dateien zu verwenden. Zusätzlich können Sie smb.conf-Variablen an preexec- oder postexec-Skripte übergeben und die Variablen korrekt interpretieren lassen.
Lassen Sie mich die Bühne vorbereiten. Sie haben den Logon-Pfad wie folgt definiert:
logon path = \\%N\profile\%USie haben folgende Einstellungen für die [profile]-Freigabe konfiguriert:
[profile]Hier ist das buildprofile-Skript:
#!/bin/shIn diesem Skript ist somelink.lnk der Name der Shortcut-Datei, die Sie an den Desktop jedes Benutzers verteilen wollen. Wenn Windows sich mit der [profile]-Freigabe verbindet, um auf das Profil des Benutzers zuzugreifen, führt der smbd das preexec-Skript aus, das den notwendigen Shortcut kopiert. Mit dieser Art von Konfiguration können Sie alle Arten von komplizierten Tricks durchführen. Seien Sie kreativ!
System-Policies (Richtlinien) sind eng mit der Windows-95-Registry verbunden. Die Beziehung kann wie folgt erklärt werden: Policies definieren, was erlaubt ist und was abgelehnt wird. Die Windows-Registry enthält die aktuellen Policy-Einstellungen in Form von Registrierungsschlüsseln.
Zu Beginn dieses Kapitels habe ich eine Registry-Einstellung benutzt, um das Passwort-Caching zu deaktivieren. Das ist ein Beispiel für eine Policy. Es liegt in der Verantwortung des Betriebssystems, die Policy-Einstellungen, die in der Registry aufgezeichnet werden, durchzusetzen.
Genau wie Windows einen Registrierungseditor, regedit.exe, bietet, stellt es auch einen Policy-Editor mit dem Namen poledit.exe zur Verfügung, den Sie in Abbildung 21.13 sehen. Die Darstellung jedes Details der Policy-Dateien und -Vorlagen würde über den Rahmen dieses Buches hinausgehen. Stattdessen werde ich mich darauf konzentrieren, wie Windows-Clients konfiguriert werden, um die Policy-Dateien von einem Server herunterzuladen und was Sie mit System-Policies tun können.
Abb. 21.13: Der Windows-95-System-Policy-Editor
Der System-Policy-Editor kann von der Windows-Installations-CD heruntergeladen werden. Anweisungen für die Installation des Tools finden Sie in einer Datei mit dem Namen poledit.txt in \admin\apptools\poledit.
Der Policy-Editor ermöglicht es Ihnen, eine Datei zu erstellen, die während des Logins mit der lokalen System-Registry verbunden werden kann. Sie können Windows mitteilen, die Policy-Datei automatisch herunterzuladen:
\\server\netlogon\config.polserver ist hier der NetBIOS-Name des Domänen-Controllers, der das Login durch Setzen des folgenden Registrierungsschlüssels authentifiziert hat:
[HKLM\System\CurrentControlSet\control\Update]Denken Sie an die übliche Warnung in Hinsicht auf die Benutzung des Registrierungseditors. Alternativ können Sie den Policy-Editor auf dem lokalen Rechner installieren und die Registry öffnen. Dann können Sie, wie in Abbildung 21.14 gezeigt, den Update-Modus einrichten.
Abb. 21.14: Den Policy-Update-Modus über den System-Policy-Editor einrichten
Da Sie sich nun den Policy-Editor angesehen haben, stellt Abbildung 21.15 den Prozess des Einloggens in das Netzwerk dar und zeigt, wann die Policy-Datei, wenn überhaupt, heruntergeladen wird.
Um eine Policy-Datei zu erstellen (z.B. config.pol), starten Sie den Policy-Editor und wählen Neu aus dem Menü Datei. Sie können u.a. folgende Einstellungen vornehmen:
Experimentieren Sie mit den verfügbaren Einstellungen. Weitere Informationen über System-Policies finden Sie in den Windows-95- und Windows-98-Resource-Kits. Verfügbare Dokumentation finden Sie auf der Windows-Installations-CD.
Wenn Sie Ihre Policy-Datei erstellt haben, speichern Sie die Einstellungen in einer Datei mit dem Namen config.pol in der [netlogon]-Freigabe auf dem DC. Stellen Sie außerdem sicher, dass Sie das Locking für diese Freigabe deaktiviert haben. Sie sollten eventuell der Definition der Freigabe in smb.conf Folgendes hinzufügen:
locking = noNoch ein letztes Wort zu Policies. Zwar bieten sie einiges an Kontrolle, aber es gibt keinen Mechanismus in Windows 95, der verhindert, dass ein lokaler Benutzer die Policy-Einstellungen in der Registry ändert. Das als kleine Warnung.
Sambas Fähigkeiten zur Domänenkontrolle für Windows-95- und Windows-98-Clients bieten eine Methode für die Authentifizierung von Netzwerk-Logins und nicht nur von Freigabeverbindungen. Die vier Voraussetzungen für einen Samba-DC sind:
Neben den Standard-Domänen-Logins und Login-Skripten unterstützt Samba auch die Windows-9x-Funktionen zum Herunterladen von System-Policies und das Speichern von Benutzerprofilen auf Netzwerklaufwerken.
Ich habe Samba erfolgreich als Domänen-Controller eingerichtet und benutze Login-Skripte. Wenn ein Benutzer sich einloggt, läuft zwar die Batch-Datei korrekt ab, aber das Windows-NT-Logon-Skript-Fenster hängt, bis der Benutzer schließlich irgendwann auf die Schaltfläche Abbrechen klickt. Was mache ich falsch?
Sie machen nichts falsch. Dieses kleine Ärgernis wird dadurch hervorgerufen, dass die Batch-Datei ihr Ausführungsende signalisiert, indem Sie eine Datei mit dem Namen LMSCRIPT.$$$ im aktuellen Arbeitsverzeichnis erstellt. Das Windows-NT-Logon-Skript-Fenster würde dann die Dinge bereinigen. Das Problem tritt zutage, wenn die Batch-Datei die Datei LMSCRIPT.$$$ nicht erstellen kann. Daher weiß das NT-Logon-Skript-Fenster nicht, dass die Batch-Datei ihre Aufgabe beendet hat. Wahrscheinlich sind Sie zu einem Laufwerk und einem Verzeichnis gewechselt, in das der Benutzer nicht schreiben darf. Um dies zu korrigieren, fügen Sie am Ende des Skripts eine Zeile ein, die zurück zur lokalen Festplatte des Benutzers geht (z.B. c:).