Letzte Änderung: 18.10.98 von B. Tritsch
Wichtiger Teil bei einem Netzwerk-Betriebssystem ist die Überwachung der Zugriffe auf die Server und die Kontrolle der Serverzustände.
Die Überwachung des Systems ist als Funktion der lokalen Gruppe der Administratoren zugeordnet. Jedoch wird immer die letzte Aktion eines Administrators aus Sicherheitsgründen in geeigneter Form protokolliert und zur Kontrolle aufbewahrt. Das heißt, auch wenn ein Administrator alle protokollierten Kontrollinformationen löschen würde, wäre der Löschvorgang selbst wieder der erste Eintrag der neuerlichen Protokollinformation!
Überwachbare Systemfunktionen sind im einzelnen:
Die Überwachung der Datei- und Objektzugriffe wird über den Datei-Manager und den dortigen Menüpunkten <Sicherheit> <Überwachen> durch einen Administrator gestartet (Auditing). Alle anderen Überwachungsfunktionen werden mit dem Menüpunkt <Überwachung> im Benutzer-Manager festgelegt.
Das Werkzeug für die Einsicht der Überwachungsinformationen ist die Ereignisanzeige. Sie ersetzt dadurch die Ausgabe von Nachrichtenfenster an Benutzer, die mit deren Inhalt in der Regel nicht allzu viel anfangen können. Die Nachrichten über Systemereignisse sind viel mehr für Administratoren gedacht und werden daher als Protokolle von einem speziellen Systemdienst gesichert. Die Ereignisanzeige kann hierbei Protokolle für System-, Sicherheits- und Anwendungs-Ereignisse anzeigen und verwalten, sowie diese Ereignisprotokolle archivieren. Der dafür benötigte Ereignisprotokollierdienst wird automatisch beim Start von Windows NT initialisiert.
Das Hauptfenster der Ereignisanzeige zeigt die im folgenden aufgeführten Informationen für die ausgewählte Protokollkategorie an. Hierbei gilt es zu beachten, daß das Sicherheitsprotokoll nur von Administratoren betrachtet werden kann.
Der Menüpunkt <Protokoll> <Computer auswählen...> erlaubt es Domäne-Administratoren auch die Protokollinformationen anderer Computer unter Windows NT im Netzwerk abzurufen. Dies ist insbesondere nützlich, wenn ein Benutzer ein instabiles Systemmeldet und der Administrator durch einen Fernzugriff eine erste Diagnose stellen möchte.
Wird der Umfang der Protokolleinträge zu groß für die gezielte Analyse bestimmter Ereignisse, so lassen sich Filterfunktionen einsetzen. Das zugehörige Dialogfenster wird über den Menüpunkt <Ansicht> <Ereignisse filtern...> aktiviert.
Zu Archivierungszwecken können die Protokolle in Dateien gesichert werden. Diese lassen sich mit verschiedensten Werkzeugen (z.B. Crystal Report, MS-Excel) auswerten und aufbereiten. In vielen Unternehmen gehört das Aufbewahren der Protokollinformationen zur Firmenpolitik. Hierdurch können insbesondere Sicherheitsverstöße von Mitarbeitern auch im Nachhinein rekonstruiert werden.
Sollen die Protokolle regelmäßig gesichert werden, dürfen keine Informationen verloren gehen. Dies erreicht man durch entsprechende Einstellungen der Protokollgrößen und der Definition, wie ältere Protokolleinträge behandelt werden.
Wird als Protokollfortsetzung die Option gewählt, daß Ereignisse nie überschrieben werden, so kann es doch einmal geschehen, daß normale Benutzer mit einer administrativen Meldung konfrontiert werden. Diese besagt dann, daß die Ereignisdatei voll ist und von einem Administrator gesichert werden soll. In diesem Fall wird der Benutzer in der Regel den Administrator informieren, um die immer wiederkehrende Meldung durch eine entsprechende Aktion abstellen zu lassen.
Werden Sicherheitereignisse mitprotokolliert, so läßt sich auch das Löschen der Protokollinformationen überwachen. Dies ist zwingend notwendig, wenn ein Administrator, der nach einer unberechtigten Aktion versucht seine Spuren zu verwischen, von seinen Administratorkollegen überführt werden soll. Hierzu kann es jedoch nötig sein, daß alle beteiligten Administratoren ihr eigenes administratives Konto mit zugehörigem individuellen Benutzernamen besitzen und verwenden.
Die NT-Registry ersetzt die noch unter Windows for Workgroups (WfW) und unter Windows 3.1 gebräuchlichen .ini-Dateien mit ihrer fast unüberschaubaren Vielzahl an einstellbaren Parametern durch ein Datenbanksystem. Dies resultierte aus der Tatsache, daß die ini-Dateien eine Reihe von Nachteilen hatten. So bestanden für sie Limits in der Größe, es gab kein Standardlayout, der Zugriff war vergleichsweise langsam und es gab keinen Netzwerkzugriff. Jedoch gab es schon unter Windows 3.1 (nicht NT!) eine Registry, die zur Verwaltung von Dynamic Data Exchange (DDE), Object Linking and Embedding (OLE) und Datei-Manager-Erweiterungen diente. Für Windows NT wurde diese Registry wesentlich ausgebaut und ist jetzt das Herz des Betriebssystems.
Die Registry sorgt für die Verwaltung von Benutzer-, System- und Anwendungseinstellungen. Die Registry-Unterbäume (Hives) haben feste Namen und Bedeutungen. Hierbei ist jeder Hive als Unterbaum der gesamten Registry aufgebaut, in dem sich verschiedenen Schlüssel befinden. Die Schlüssel sind die einzelnen Einträge, denen wiederum Werte zugewiesen werden können.
Zur besseren Übersichtlichkeit wird einzelnen zentralen Registry-Bereichen spezielle Namen und auch Kurzformen zugeordnet, die für die weitere Dokumentation von Registry-Einträgen Verwendung finden sollen.
Mit Hilfe der Registry-Editoren (Regedt32.exe oder Regedit.exe) können auf einer sehr systemnahen Ebene Änderungen an der Registry-Datenbank vorgenommen werden. Die Datenbank kann jedoch auch damit gesichert und wieder ganz oder teilweise rekonstruiert werden. Vorsicht: Eine winzige Änderung in der Registry kann fatale Folgen haben!
Die Registry besteht aus einer Hierarchie, die wie eine Verzeichnisstruktur gegliedert ist. In einzelnen Verzeichnissen können Daten (sogenannte "Werte") oder Schlüssel ("Keys") abgelegt sein, die wiederum auf weitere Schlüssel verweisen. Für jeden Schlüssel wird zusätzlich ein Standardwert (ohne Bezeichnung) angelegt.
Standardmäßig sind alle mit Strukturen assoziierten Dateien im Verzeichnis %SystemRoot%\System32\Config untergebracht. Die Einstellung für alle Benutzer befindet sich in einem Verzeichnis namens All Users, die für die jeweiligen benutzerspezifischen Daten in einem entsprechend benannten Unterverzeichnis von %SystemRoot%\Profiles. Die Daten des Default Users dienen als Vorlage zum Erzeugen eines Profils für einen Benutzer, der sich zum ersten mal anmeldet.
| Registrierungsstruktur | Dateiname |
|---|---|
| HKEY_LOCAL_MACHINES\SAM | Sam, Sam.log, Sam.sav |
| HKEY_LOCAL_MACHINES\Security | Security, Security.log, Security.sav |
| HKEY_LOCAL_MACHINES\Software | Software, Software.log, Software.sav |
| HKEY_LOCAL_MACHINES\System | System, System.alt, System.log, System.log |
| HKEY_CURRENT_CONFIG | System, System.alt, System.log, System.log |
| HKEY_USERS\.DEFAULT | Default, Default.log, Default.sav |
| (nicht mit einer Struktur assoziiert) | Userdiff, Userdiff.log |
| HKEY_CURRENT_USER | Ntuser.dat, Ntuser.dat.log (in den benutzerspezifischen Unterverzeichnissen) |
Die Mehrzahl der 32-Bit-Applikationen hinterlassen während ihrer Installation eine Reihe von Einträgen in der Registry (z.B. ca. 70.000 Einträge bei der Installation von MS-Office 97 Professional). Diese finden sich entweder im Hive HKLM für systemglobale Informationen oder im Hive HKCU für benutzerspezifische Informationen. Aus diesem Grund ist die Kontrolle der Registry eine wesentliche Voraussetzung für die Verwaltung von Benutzereinstellungen und Anwendungen.
Haben die Hives HKLM (= All Users) und HKCU (= benutzerspezifische Daten) gleiche Schlüssel, enthalten jedoch abweichende Werte, dann haben die Werte aus HKCU Vorrang. Bei der Installation einer Applikation für alle Benutzer eines NT-Systems ist darauf zu achten, daß die applikationsspezifischen Einträge in die Registry für alle Benutzer (HKLM) eingetragen werden, und nicht für den installierenden Benutzer alleine (HKCU). Dies wird aber dadurch erschwert, daß in der Regel keine Anwenderkontrolle über das Ziel von Registry-Einträgen durch vom Hersteller mitgelieferte Installationsskripts besteht.
Das Speichern und Wiederherstellen von Registry-Einträgen läßt sich mit der GUI-Version von Regedit.exe durchführen. Es gibt hierfür jedoch auch Kommandozeilen-Optionen:
Speichern von Registry-Keys: regedit /e Dateiname.reg [Schlüsselname]
Wiederherstellen von Registry-Keys; Import von Teilbäumen oder Teilschlüsseln: regedit /i Dateiname.reg
Wiederherstellen von Registry-Keys; die gesamte Registry-Datenbank wird von einer .REG-Datei überschrieben: regedit /c Dateiname.reg
Das Sichern und Restaurieren von Registry-Strukturen kann mit den Programmen Regback.exe, Regrest.exe und Regini.exe aus dem Ressource Kit geschehen.
Im folgenden werden einige Registry-Highlights aufgeführt:
| Position | Name(n) | Bedeutung |
| HKEY_CURRENT_USER\ Software\ Microsoft\ Command\ Processor | CompletionChar | Ein Wert abweichend von Null gibt der NT-Kommandozeile die Fähigkeit, auf Tastendruck Eingaben zu vervollständigen - der Wert gibt den ASCII-Code der jeweiligen Taste an (z.B. 9 für die Tabulatortaste). |
| HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Control\ Print\ Providers | NetPopup | Bei REG_DWORD = 0 wird verhindert, daß bei Druckoperationen eine Popup-Dialogbox auf dem Domain Controller ausgegeben wird. |
| HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Control\ FileSystem | Win31FileSystem | Trägt man hier eine 1 ein, arbeitet NT auf FAT-Partitionen nicht mit langen Dateinamen (Standard =0) |
| HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Control\ FileSystem | NtfsDisable8dot3 NameCreation |
Trägt man hier eine 1 ein, verzichtet NT darauf, für lange NTFS-Dateinamen eine Kurzform zu generieren. Alte Programme (DOS und Windows) sehen solche Dateien nicht! |
| HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ CDRom | AutoRun | Bei 0 wird verhindert, daß beim Einlegen von CDs die AutoRun-Funktionalität ausgeführt wird. |
| HKEY_CLASSES_ROOT\ | lnkfile piffile |
Das jeweilige Löschen des Eintrags IsShortcut unterdrückt den "Verknüpfungspfeil" in Icons, die eine Verknüpfung repräsentieren. |
| HKEY_LOCAL_MACHINE \system \currentcontrolset \services \rdr \parameters | EnablePlainTextPassword (DWORD) | Nach Eintrag des Werts 1 funktioniert unter NT 4.0 Service Pack 3 die Verbindungsaufnahme zu einem SAMBA-Server wieder |