Projekte:

Papers in anderen sprachen:

	Englisch analyse
	Franzosisch referate
	Italienisch hausarbeiten
	Spanisch seminararbeiten
	Latein schularbeiten

Referat Einleitung - Benutzerrechte auf Windows NT - Computern - Die Registrierung von Windows NT

informatik referate

1. Einleitung - Benutzerrechte auf Windows NT - Computern

In unserer heutigen Informationsgesellschaft gewinnt der Computer immer mehr an Bedeutung. Vor allem aus der modernen Arbeitswelt ist der hellgraue Gehilfe kaum mehr wegzudenken. Von Textverarbeitung über Datenbanken bis hin zur Tabellenkalkulation hat er alles zu bieten, was man sich im Büroalltag nur so wünschen kann. Doch leider wissen nur die wenigsten Leute über die umfangreichen Funktionen des Computers genauer Bescheid. Auch deshalb wird er immer noch oft als eine Art Spielzeug gesehen, und nicht als seriöser Arbeitsgehilfe. Aufgrund dieser Tatsachen ist es auch nicht verwunderlich, dass Manche ihren Experimentierdrängen am Computer freien Lauf lassen. Das erschreckende Resultat folgt, je nach Schwere des Eingriffs, meist nur wenige Momente später. Von Abstürzen einzelner Computer bis hin zur Vernichtung eines ganzen Firmennetzwerkes ist alles möglich.

Um diesem schwerwiegenden Problem entgegenzusteuern hat Windows NT sogenannte Benutzerrechte eingeführt, die es erlauben, den Benutzer in seinen Handlungen einzuschränken und dessen Aktionen am Computer auch zu überwachen.

2. Die Registrierung von Windows NT

Eine wichtige Rolle bei der Vergabe von Benutzerrechten spielt die Registrierung (sog. "Registry"). Sie ist eine binäre, hierarchisch organisierte Datenbank, die systembezogene Einstellungen speichert. Aufgeteilt ist sie in fünf Hauptschlüssel, die im Englischen auch als "Hives" bezeichnet werden. Jeder dieser fünf Schlüssel kann dabei weitere Unterschlüssel (sog."Keys") und Werteinträge (sog. "Values") besitzen. Weiters ist es möglich, dass Einträge in der Konfigurationsdatenbank doppelt existieren. Dieses Phänomen kann man auf die Existenz von Verknüpfungen zurückführen, die auf andere Teile der Registry verweisen. Andert man dabei entweder den Wert der Verknüpfung oder den reellen Wert selbst, so ändern sich automatisch beide Einträge.

Gespeichert wird die Registrierung in sogenannten Strukturdateien im Verzeichnis %SYSTEMROOT%System32Config. Für jede Datei gibt es die dazupassende Sicherungsdatei, die Informationen über die letzten Anderungen an der Registry enthält. Diese hat denselben Dateinamen wie die Strukturdatei, jedoch die Dateiendung *.log.

Die Liste der Strukturdateien und den jeweiligen Schlüssel, der in ihnen abgelegt wird, ist Abb. 2.1. zu entnehmen:

Dateiname:	Schlüssel:
SAM	HKEY_LOCAL_MACHINESAM
SECURITY	HKEY_LOCAL_MACHINESECURITY
SOFTWARE	HKEY_LOCAL_MACHINESOFTWARE
SYSTEM	HKEY_LOCAL_MACHINESYSTEM
DEFAULT	HKEY_USERSDefault
[Benutzername]nnn	HKEY_USERSSecurity ID
USER oder ADMIN	HKEY_CURRENT_USER

In der folgenden Aufstellung findet man eine grobe Beschreibung der fünf Hauptschlüssel der Registry:

HKEY_LOCAL_MACHINE: In diesem Teil sind systemspezifische Informationen und Details über die Konfiguration der Hardware gesichert.

HKEY_CLASSES_ROOT: Aus diesem Schlüssel liest das Betriebssystem Informationen über OLE (Object Linking and Embedding) und ActiveX-Komponenten sowie die Zuordnung von Dateiendungen aus.

HKEY_CURRENT_CONFIG: Daten über die aktuelle Hardwarekonfiguration, die auch im Schlüssel HKEY_LOCAL_MACHINE zu finden ist, werden in diesem Bereich gespeichert.

HKEY_CURRENT_USER: Benutzerspezifische Einstellungen sowie andere relevante Daten des aktuellen Benutzers sind hier gelagert.

HKEY_USERS: In diesem Bereich kann man die Daten aller dem System bekannten lokalen Benutzer, inklusive des gerade angemeldeten Benutzers, finden.

2.1. Die Hauptschlüssel der Registrierung im Detail

Wie schon erwähnt besteht die Windows-NT-Registry aus fünf verschiedenen Hauptschlüssel,

deren Besonderheiten in der folgenden Aufstellung genauer unter die Lupe genommen werden.

HKEY_LOCAL_MACHINE: In diesem Schlüssel sind Informationen über den lokalen Computer gespeichert. Dazu zählt man Informationen über die installierte Hardware (z.B.: Typ des Hauptprozessors, Speicherausbau, Typ des Bussystems, usw.) und die dazugehörenden Treiber bzw. deren Einstellungen. Weiters besitzt dieser Schlüssel folgende vier Unterschlüssel: SAM, Security, Software und Hardware.

SAM ist der sogenannte Security Account Manager, der Informationen über Benutzer und Benutzergruppen sowie Sicherheitsinformationen über die Domäne (sog. "Domain") enthält.

Im Unterschlüssel Security sind Sicherheitsinformationen über den lokalen Rechner gespeichert. Dazu werden die Zugriffsrechte einzelner Benutzer sowie die Zugehörigkeit zu lokalen Gruppen gezählt.

Im Unterschlüssel Software findet man die Einträge von Anwendungsprogrammen, die darin computerspezifische Daten speichern. Benutzerdefinierte Einstellungen von Programmen befinden sich dagegen im Schlüssel HKEY_CURRENT_USERSOFTWARE. Dabei ist es durchaus möglich, dass sich benutzerdefinierte und computerspezifische Daten widersprechen. Wenn dieser Fall eintritt, so haben benutzerspezifische Einstellungen immer eine höhere Priorität als computerspezifische. Darüber hinaus enthält der Unterschlüssel Software wiederum Unterschlüssel, von denen der Wichtigste Classes genannt wird, worin man Zuordnungen von Dateiendungen zu einzelnen Programmen finden kann. (siehe auch: HKEY_CLASSES_ROOT

Der Unterbereich System enthält Informationen zur Hardwarekonfiguration (z.B.: installierte Dateisysteme, virtuelle Gerätetreiber, usw.) und steuert auch den Bootvorgang von Windows NT. Die Informationen für den Startvorgang werden dabei in sogenannten Control-Sets gespeichert, wobei jedes Set eine komplette Hardwarekonfiguration enthält. Der Schlüssel CurrentControlSet stellt dabei die aktuelle Systemkonfiguration dar. Während der Startphase wird ein Unterschlüssel namens Clone angelegt, der eine Kopie von CurrentControlSet enthält. Grundsätzlich werden die Informationen im Unterschlüssel Hardware beim Start des Betriebssystems ermittelt und beim Herunterfahren wieder gelöscht.

HKEY_CURRENT_CONFIG: In diesem Hauptschlüssel werden unterschiedliche Hardwareprofile gespeichert. So kann man beispielsweise zwei unterschiedliche Profile für einen mobilen Rechner und eine Docking-Station einrichten. Der Inhalt dieses ganzen Schlüssels ist auch im Schlüssel HKEY_LOCAL_MACHINE

SystemCurrentControlSetHardwareProfilesCurrent gelagert.

HKEY_CLASSES_ROOT: In diesem Verzeichnis sind alle Informationen über die dem System bekannten Dateiendungen gespeichert.

Zu diesen zählt man auch Anweisungen die Dateien, aufgrund ihrer bestimmten Dateiendungen mit dem dazugehörigen Anwendungsprogramm verknüpfen. Daher ist es möglich, Dateien direkt aus dem Windows NT-Explorer zu öffnen.

Neben allen Dateiinformationen findet man auch Einstellungen von OLE- und ActiveX-Controls. Diese sind vor allem für Programmierer von großer Bedeutung.

Eigentlich stellt der Schlüssel HKEY_CLASSES_ROOT nur eine Verknüpfung mit HKEY_LOCAL_MACHINESoftwareClasses dar, wo die eigentlichen Einstellungen gespeichert sind.

HKEY_CURRENT_USER: Dieser Schlüssel dient zum Sichern von benutzerspezifischen Daten des gerade angemeldeten Benutzers. Führt ein Benutzer einen Anmeldevorgang aus, so werden Einstellungen aus dem Schlüssel HKEY_USERSSecurity-ID-String (siehe auch: HKEY_USERS), in HKEY_CURRENT_USER übernommen. Wird bei einem Anmeldeversuch kein Benutzerprofil gefunden, so wird das Default-Profil (Standardbenutzerprofil) geladen, welches sich im Schlüssel HKEY_USERSDefault befindet. Das gefundene Benutzerprofil und dessen Informationen besitzen dabei eine höhere Priorität als die computerspezifischen Einstellungen unter HKEY_LOCAL_MACHINE.

Der Schlüssel HKEY_CURRENT_USER hat im Endeffekt dieselbe Verknüpfungsfunktion wie HKEY_CLASSES_ROOT. Der einzige Unterschied ist nur, dass HKEY_CURRENT_USER auf das Verzeichnis HKEY_USERSecurity-ID-String des Benutzers verweist.

HKEY_USERS In diesem Bereich werden alle dem System bekannten Benutzerprofile und deren persönliche Einstellungen gespeichert. Für jeden Benutzer ist dabei ein Unterschlüssel mit der Bezeichnung des Security-ID-Strings (z.B.: S-1-5-21-1750099260-1133346281-1777090905-500) vorhanden. Dieser String beginnt mit einem "S", auf welches eine benutzerspezifische Zahlenkombination folgt.

Der Unterschlüssel Default enthält das Standardbenutzerprofil von Windows NT, welches für Anwender geladen wird, die kein persönliches Profil besitzen. Weiters existiert auch der Schlüssel HKEY_USERSSecurity-ID-String, der alle benutzerdefinierten Einstellungen enthält und auf den durch den Schlüssel HKEY_CURRENT_USER verwiesen wird.

In den Unterbereichen Console, Environment und Printers kann man benutzerspezifische Einstellungen für die DOS-Konsole, Umgebungsvariablen oder den Drucker tätigen.

2.2. Werteinträge in der Registry

Neben den einzelnen Schlüsseln der Registrierung, die hierarchisch gegliedert sind, gibt es auch noch einige verschiedene Werteinträge. Dies ist notwendig, da unterschiedliche Daten wie beispielsweise Zahlen oder Texte, in der Konfigurationsdatenbank gespeichert werden müssen. Jeder Eintrag setzt sich dabei aus den Teilen: Name, Datentyp und zugewiesener Wert, zusammen.

Unter Windows NT stehen dabei sechs verschiedene Datentypen zur Verfügung, wobei es darüber hinaus noch möglich ist, eigene benutzerdefinierte Datentypen hinzuzufügen. Die einzelnen Datentypen werden in der folgenden Liste angeführt:

REG_BINARY: Binärdaten, die in hexadezimaler Notation dargestellt werden.

REG_DWORD 32-Bit-Daten (4-Bytes lang) in hexadezimaler oder dezimaler Notation.

REG_EXPAND_SZ Beliebig erweiterbare Zeichenkette, die von Applikationen gesetzt werden kann. Dabei können auch Variablen verwendet werden, die beim Start des Betriebssystems initialisiert werden (z.B.: %SYSTEMROOT oder %USERNAME%).

REG_MULTI_SZ Eine Zeichenkette, die mehrere Parameter beinhalten kann, die voneinander durch binäre Nullen (sog. Null-Bytes) getrennt sind.

REG_FULL_RESOURCE_DESCRIPTOR Ressourcenliste einer Hardwarekomponente oder eines Treibers.

2.3. Bearbeiten der Registry mit dem Registrierungseditor

Um die Konfigurationsdatenbank bearbeiten zu können, ist ein spezielles Hilfsprogramm vonnöten, welches bereits standardmäßig mit Windows NT ausgeliefert wird. Bei diesem handelt es sich um den Registrierungseditor, den man unter Windows NT in zwei verschiedenen Versionen vorfindet. Zum einen gibt es den Regedt32 (im Verzeichnis %SYSTEMROOT%System32; Datei: regedt32.exe), und zum anderen das Programm Regedit (im Verzeichnis %SYSTEMROOT%; Datei: regedit.exe). Beide Anwendungen erfüllen denselben Zweck, jedoch unterscheiden sich markant in der Darstellung der Registry und in den Zusatzfunktionen zum Bearbeiten der Registrierung.

Gemeinsam ist ihnen die Möglichkeit, Einträge in der Konfigurationsdatenbank zu suchen, wobei Regedit hier die weitaus vielfältigeren Möglichkeiten bietet. Werden die gewünschten Werte gefunden, so lassen sich diese mit beiden Programmen bequem bearbeiten. Auch kann man Sicherungsdateien von einzelnen Schlüsseln oder sogar der ganzen Registrierung anfertigen. Bei diesem Punkt sollte zusätzlich das Programm Rdisk (im Verzeichnis %SYSTEMROOT%System32; Datei: rdisk.exe) erwähnt werden, welches Notfalldisketten für Windows NT anlegt. Dabei handelt es sich um auf Diskette gespeicherte Versionen der Registrierung. Sollten nun gröbere Probleme mit den Einstellungen des Computers auftreten, so kann man die gesicherte Dateiversion der Registry, die man entweder mit Rdisk oder mit einem der Registrierungseditoren angelegt hat, wieder herstellen. Weiters besitzen beide Programme Netzwerkfunktionen, die den Zugriff auf eine Konfigurationsdatenbank eines im Netzwerk befindlichen Computers gewährleisten.

Ein weiteres Feature ist das Festlegen von Zugriffsrechten (drei unterschiedliche Arten: Lesen, Vollzugriff und beschränkter Zugriff) für einzelne Benutzer oder ganze Benutzergruppen. Darüber hinaus gibt es auch noch die Möglichkeit die Registry zu Überwachen. Dabei werden alle Zugriffe von Benutzern oder Benutzergruppen protokolliert. Beide Funktionen, das Festlegen von Zugriffsrechten und das Überwachen, sind nur mit dem Registrierungseditor Regedt32 möglich.

3. Systemrichtlinien unter Windows NT

Systemrichtlinien (sog. "Policies") sind untrennbar mit der Registrierung von Windows NT verbunden. Sie eignen sich zum Einschränken von Rechten von einzelnen Benutzern oder auch zum Zurücksetzen von veränderten Registrierungswerten. Darum liegt ihr Einsatzgebiet vor allem im Bereich von großen PC-Netzwerken, wo das Management und die Überwachung von lokalen Arbeitsstationen zur fast unlösbaren Aufgabe geworden ist. In diesen Netzwerken muß der Administrator einen gesunden Mittelweg zwischen größtmöglicher Freiheit für einzelne Benutzer und Bereitstellung funktionsfähiger Arbeitsplatz-PCs finden. Dies sind die Hauptgründe warum hier Policies eingesetzt werden.

Systemrichtlinien sind Sammlungen von Einstellungen, die beim Anmelden eines Benutzers die gewünschten Einträge im benutzer- und maschinenbezogenen Teil der Registrierung des lokalen Computers vornehmen. So kann ein individueller Anwender auf jedem Computer eines Netzwerkes in seinen Tätigkeiten eingeschränkt und kontrolliert werden.

3.1. Systemrichtlinieneditor

Wenn man nun auf den Geschmack gekommen ist, auch in seinem eigenen Netzwerk Richtlinien an einzelne Benutzer zu vergeben, so muß der Systemrichtlinieneditor (siehe: Abb. 3.1.1.) als Werkzeug eingesetzt werden. Dieser bearbeitet die Registrierungsdatenbank mit Hilfe von Systemrichtlinien, für deren Erstellen er eine graphische Oberfläche zur Verfügung stellt.

Der Systemrichtlinieneditor ist im Lieferumfang der Servervariante von Windows NT enthalten und wird vom Betriebssystem auch automatisch installiert. Besitzer einer Windows NT Workstation-Ausführung genießen diesen Komfort nicht, denn der Policy-Editor wird in dieser Version nicht standardmäßig mitgeliefert. Wenn man jedoch manuell einige Dateien kopiert, so lassen sich die Funktionen des Systemrichtlinieneditors auch auf Windows NT Workstations implementieren.

Die auszuführende Programmdatei namens poledit.exe gehört in das Verzeichnis %SYSTEMROOT% (im allgemeinen der Ordner WINNT des Installationslaufwerkes) und die dazugehörige Hilfedatei poledit.hlp sollte nach %SYSTEMROOT%Help kopiert werden.

Zusätzlich benötigt der Systemrichtlinieneditor noch Vorlagedateien (siehe Kapitel 3.3), die in das Verzeichnis %SYSTEMROOT%Inf kopiert werden müssen.

Damit sollte man Richtlinien auch unter Windows NT Workstation erstellen können.

3.1.1. Bedienung des Systemrichtlinieneditors

Grundsätzlich werden alle Systemrichtlinien, egal welche Eingabewerte sie erwarten, zunächst mit einer Checkbox aktiviert bzw. deaktiviert. Diese Checkboxen können drei verschiedene Zustände annehmen, die in Abb. 3.1.2. näher beschrieben werden:

möglichen Zustände der Checkboxen, mit denen man den Policy-Editor be-dient.

Zusätzlich zu den Informationen, die von den Checkboxen herausgelesen werden, können noch weitere Einstellungen vom Betriebssystem verlangt werden. Dies ist beispielsweise der Fall, wenn ein Hintergrundbild durch Systemrichtlinien vorgegeben wird. Hier funktioniert der einfache Klick auf das Kontrollkästchen nicht mehr, da die Richtlinie ja auch wissen muss, welches Bild nun eingebunden werden soll. So erscheint dann nach Aktivierung der Richtlinie im unteren Teil des Fensters ein zusätzliches Eingabeelement, welches je nach Bedarf des Werteintrages implementiert ist. Im Falle des Beispiels mit dem Hintergrundbild wäre dies ein Textfeld, welches den Dateinamen und den Pfad der Bilddatei enthält.

Wie wir bereits wissen ist der Systemrichtlinieneditor ein graphisches Werkzeug zur Bearbeitung der Registry. Daher bietet er neben der Erstellung von Systemrichtlinien auch eine Möglichkeit zum direkten Eingriff in die Registrierung. Man unterscheidet dabei zwischen zwei Modi:

Registrierungsmodus: Hierbei wirken sich die Veränderungen sofort nach dem Setzen der Checkboxen aus. Jedoch können die Eingriffe nur an einem Rechner vorgenommen werden, was heißt, dass die Einträge nur die Registrierung des lokalen Computers betreffen.

Weiters kann man in diesem Modus eine Verbindung zu einem beliebigen Computer des Netzwerkes aufbauen und dessen Registry verändern. Aber auch hier gilt, dass die Veränderungen immer nur auf eine Workstation zutreffen. Aufgrund dieser beschränkten Möglichkeiten spielt der Registrierungsmodus in Netzwerken keine Rolle, da er eher zum Testen von Einstellungen an einem Computer verwendet wird.

Systemrichtlinienmodus: In diesem Modus bietet der Systemrichtlinieneditor viel komplexere Möglichkeiten, die zum Teil schon behandelt wurden. Der größte Vorteil ist es, Policies für spezielle Benutzer oder Benutzergruppen zu erstellen, die diese dann im gesamten Netzwerk kontrollieren können.

Um die Registrierung mit dem Systemrichtlinieneditor zu bearbeiten sind weiters noch Vorlagedateien (ADM-Dateien) vonnöten, die Informationen über die Registrierungsschlüssel beinhalten, die von der Richtlinie betroffen sind. Dabei kann der Policy-Editor nur Registry-Einträge verändern, die zuvor in einer Vorlage definiert worden sind.

► Abb. 3.2.1.: Hier ist ein kleines Listing abgebildet, welches die Option "Anzeige" aus der Systemsteuerung entfernt.

Hinweis: Das Erstellen von eigenen Richtlinien ist ein eigener Teil dieser Arbeit, wo auch die Skriptsprache von Microsoft ausführlich erklärt wird.

Der Policy-Editor kann nun eine oder mehrere Vorlagedateien zugleich verwenden und mit ihnen eine Systemrichtlinie erstellen.

Dazu müssen die ADM-Dateien aber zuerst noch in das Verzeichnis %SYSTEMROOT%Inf kopiert werden, da sie hier vom Systemrichtlinieneditor standardmäßig gesucht werden. Dies gilt auch für jene Dateien, die bereits im Lieferumfang des Editors enthalten sind.

Ein weiteres wichtiges Feature, vor allem für jene, die selbst Vorlagedateien schreiben, ist der Syntaxchecker. Dieser untersucht den Quellcode einer ADM-Datei beim Einbinden in den Systemrichtlinieneditor auf mögliche Fehler und gibt auch die genaue Zeile zurück, wenn ein solcher gefunden wird. Denn sollte man mit schlechten Vorlagedateien herumspielen, so kann das Betriebssystem schlimme Folgeschäden erleiden.

Vorgefertigte Vorlagedateien werden von Firmen wie Microsoft oder Novell geliefert, die sich vor allem um die Sicherheit in Netzwerken Gedanken machen. Hierbei ist vor allem der Microsoft Zero Administration Kit (Zak) hervorzuheben, der einige nützliche ADM-Dateien enthält (z.B.: Vorlagen für Microsoft Office 97).

Noch nicht genauer behandelt wurden bis jetzt die beiden Vorlagedateien (common.adm und winnt.adm), die mit dem Betriebssystem mitgeliefert werden. Eine Beschreibung ihrer Einstellungsmöglichkeiten bietet die folgende Tabelle.

Bevor man sich auf die beiden unterschiedlichen Möglichkeiten der Download-Prozedur von Systemrichtlinien konzentriert, sollte man zuerst das Ereignis des Downloads an sich unter die Lupe nehmen.

Dieser wird ausgeführt, wenn sich ein gültiger Benutzer an einem Windows-System anmeldet. Dabei wird bei jedem Login die Systemrichtlinie für den speziellen Benutzer vom Server heruntergeladen, was man auch als Download bezeichnet. Unter Windows NT gibt es zwei verschiedene Varianten des Downloads von Systemrichtlinien, die in der folgenden Aufstellung näher erklärt werden:

Automatischer Download: Diese Option ist die Standardeinstellung von Windows NT, die sich vor allem für Windows NT-Domänen oder NetWare-Netzwerke anbietet.

Dabei wird die Systemrichtlinie auf dem Primary Domain Controller der NT-Domäne im Verzeichnis %SYTEMROOT%System32ReplImportScripts gelagert.

Meldet sich nun ein Benutzer am Netzwerk an, überträgt das System die Richtlinie automatisch und verarbeitet sie. Diese Prozedur sucht auf den Servern immer nach einer Datei namens ntconfig.pol. Da sich diese Einstellung nicht verändern lässt, ist diese Namenskonvention immer zu beachten.

Weiters sollt man wissen, dass der automatische Download nur bei 32-Bit Netzwerkclients funktioniert (lokale Computer mit Windows 95 oder Windows NT 4.0).

Manueller Download: Die Bezeichnung manueller Download ist bei dieser Vorgangsweise ein wenig irreführend, da es sich hierbei eigentlich auch um einen automatischen Download handelt, den man jedoch auf jedem Client manuell vorbereiten muß. Die Richtliniendatei kann dann aber in jedem beliebigen Verzeichnis liegen. Außerdem kann eine Richtlinie selbst die Information enthalten, ob nun ein manueller Download stattfinden soll, und weiters den Pfad zur Richtliniendatei angeben.

Die Informationen, die man für den manuellen Download benötigt, werden wiederum in der Registrierung jedes Rechners eingetragen. Zuständig dafür sind die Werte innerhalb des Schlüssels HKEY_LOCAL_MACHINESystemCurrentControlSetControlUpdate. Der Wert UpdateMode vom Typ REG_DWORD bestimmt die Art des Downloads (1 - bedeutet automatischer Download, 2 - manueller Download). Ist der manuelle Download gesetzt, so gibt der Wert NetworkPath vom Typ REG_EXPAND_SZ den Pfad zu den Richtliniendateien an.

Wie schon öfters erwähnt lädt ein Windows-System bei jeder Anmeldung eines Benutzers die Richtlinie vom Server und trägt die darin festgehaltenen Einstellung in die lokale Registrierung ein.

Zunächst übernimmt das Betriebssystem die Richtlinien für den Standardbenutzer und den Standard-Computer in HKEY_CURRENT_USER beziehungsweise HKEY_LOCAL_ MACHINE.

Existieren nun individuelle Einstellungen für den Computer, an dem sich der Benutzer gerade angemeldet hat, so verarbeitet Windows diese als nächstes. Da Rechner in einem Windows NT-Netzwerk immer eindeutige Namen haben müssen, erkennt das System den jeweiligen Computer und die für ihn gültige Richtlinie. Dabei kann es vorkommen, dass zuvor geänderte Einträge für den Standard-Computer wiederum überschrieben werden. Dies sollte normalerweise ein gewünschter Effekt sein, den ein schlauer Administrator zuvor geplant haben sollte.

Im Gegensatz zu Computerrichtlinien gestaltet sich die Planung für Benutzer und Benutzergruppen etwas schwieriger, da die Möglichkeiten hier komplexer sind. Wie auch schon bei den Maschinenrichtlinien gibt es eine Richtlinie namens Standardbenutzer, deren Einstellungen als erstes in die Registrierung übernommen werden. Als nächstes wird geprüft, ob eine Richtlinie für den individuellen Benutzer existiert, der sich gerade angemeldet hat. Ist dies der Fall, so werden die Parameter in die Registrierung übernommen. Die Gruppenrichtlinien werden dabei nicht beachtet.

Gibt es aber diese individuelle Systemrichtlinie nicht, so testet Windows die Gruppenmitgliedschaft des Anwenders.

Ist der angemeldete Benutzer Mitglied einer oder mehrerer Gruppen, für die auch noch jeweils getrennte Systemrichtlinien existieren, so trägt das System diese Einstellungen nach und nach in die Registrierung ein.

Dabei arbeitet sich das System von der Gruppe mit der niedrigsten Priorität bis zu der mit der höchsten Wichtigkeit durch. Somit können Werte für eine Gruppe mit höherer Priorität diejenigen für eine mit entsprechend niedriger Priorität überschreiben und eventuell sogar aufheben. Festlegen lassen sich die Gruppenprioritäten mit dem Systemrichtlinieneditor.

Nachdem in den vorhergegangenen Kapiteln vor allem die theoretische Umsetzung von Systemrichtlinien behandelt wurde, so folgt in diesem Abschnitt der praktische Teil. Dieser stellt die Programmierung einer Vorlagedatei in den Mittelpunkt, die das Herzstück jeder Systemrichtlinie bildet. Dabei wird eine propietäre Skriptsprache eingesetzt, die von Microsoft speziell für den Gebrauch mit Systemrichtlinien entwickelt wurde. Diese ist daher nicht gerade sehr umfangreich angelegt, bietet aber ausreichende Möglichkeiten zum Eingreifen in die Registrierung. Als Entwicklungsumgebung wird der Editor von Windows NT eingesetzt, der standardmäßig mit jedem Betriebssystem mitgeliefert wird.

Da nun die technischen Voraussetzungen ausreichend bekannt sind, will ich gerne die Aufgabenstellung beschreiben, die es in diesem Teil zu erfüllen galt. Hierbei sollte man beachten, dass schon einige Vorlagedateien von Microsoft oder von diversen Drittanbietern zur öffentlichen Verwendung zur Verfügung gestellt werden. Daher war es meine Aufgabe, eine ADM-Datei zu programmieren, deren Computer- und Benutzereinstellungen noch nicht von einer Standardvorlage, wie etwa winnt.adm oder common.adm, abgedeckt werden. Die detaillierte Aufgabenstellung setzt sich aus folgenden Punkten zusammen:

Beim Einschalten des Computers soll eine benutzerdefinierte Nachricht angezeigt werden können.

Die Informationsbox, die beim Drucken eines jeden Dokumentes automatisch erscheint, soll über die Systemrichtlinie aktiviert bzw. deaktiviert werden können.

Ist ein angemeldeter Benutzer eine bestimmte Anzahl von Minuten inaktiv, so kann das System ihn nach einer gewissen Zeit automatisch abmelden. So können Computerarbeitsplätze in einem Netzwerk für andere Anwender freigemacht werden.

Der Bildschirmhintergrund eines Benutzers soll mit Hilfe der Systemrichtlinien festgelegt werden können. Auch soll man das Hintergrundbild optional als Fläche darstellen können.

Die Möglichkeit einzelne Laufwerke vor einem bestimmten Benutzer zu verstecken sollte implementiert werden.

Windows NT bietet einem Administrator die Möglichkeit ein maximales Kennwortalter für Benutzer festzulegen. Die Richtlinie soll daher einen Benutzer eine gewünschte Anzahl von Tagen vor dem Ablaufen des Kennwortes benachrichtigen.

Der voreingestellte Windows NT-Installationsordner, in dem alle Setup-Dateien vom Betriebssystem automatisch gesucht werden, soll verändert werden können.

Eine Richtlinie soll erstellt werden, die eine Liste mit jenen Programmen in der Registrierung speichert, die von einem bestimmten Benutzer verwendet werden dürfen. Alle Anwendungen, die nicht auf dieser Liste enthalten sind, bleiben für den Benutzer gesperrt.

Die Erstellung einer Richtlinie, deren einziges Ziel es ist, die Verwendung von drei Checkboxen zu demonstrieren.

Bevor ich zur Erklärung komme, wie man eine Vorlagedatei programmiert, muss ich noch den Quellcode vorher abdrucken. Diesen sollte man schon im Vorhinein genauer studieren, da dies das Verständnis um einiges erleichtert.

173: SetupLaufwerk2='Laufwerk, von dem das Setup von Windows NT durchgeführt wurde'

184: Ausloggen1='Abmelden eines Benutzers nach einer gewissen Zeit von Inaktivität'

189: LegalNoticeCaption='Text, der in der Titelleiste des Dialogfeldes ausgegeben 190: wird:'

219: RestrictApps_Tip2='Um eine Liste von erlaubten Programmen zu machen clicken 220: Sie auf Anzeige'

Um eine Vorlagedatei für eine Systemrichtlinie zu erstellen, sind keine speziellen Entwicklungsumgebungen, wie etwa Visual Basic oder Visual C++ vonnöten. In diesem Fall tut es ein simpler Editor, der imstande ist eine Datei im ASCII-Format abzuspeichern. Achtgeben sollte man vor allem auf die richtige Dateiendung, die in jedem Fall *.adm lauten muss. Anderenfalls ist es dem Systemrichtlinieneditor nicht möglich, die selbsterstellte Vorlagedatei einzubinden.

Den Anfang jeder Vorlagedatei bildet der Schlüsselbegriff CLASS <USER/MACHINE>. Dieser wird im Zusammenhang mit einem Parameter aufgerufen, der entweder MACHINE (Computerrichtinie) oder USER (Benutzerrichtlinie) lautet. Angegeben wird dabei nur, welcher Hauptschlüssel der Registrierung bearbeitet werden soll. Wird so beispielsweise das Schlüsselwort USER verwendet, so weiß der Systemrichtlinieneditor, dass die Anderungen den Registrierungsschlüssel HKEY_CURRENT_USER betreffen. Gleiches gilt für den Parameter MACHINE, der Zugriffe auf den Schlüssel HKEY_LOCAL_MACHINE kennzeichnet.

Weiters ist es möglich, das Schlüsselwort CLASS mehrmals in ein und derselben Vorlagedatei zu verwenden. Hier erfolgt jedesmal eine Neudefinition des zu bearbeitenden Hauptschlüssels. Dies kann auch anhand des vorliegenden Quellcodes demonstriert werden, in dem in Zeile 1 das Schlüsselwort CLASS mit dem Parameter MACHINE aufgerufen wird. Dabei handelt es sich anfangs um eine Computerrichtlinie, die den Hauptschlüssel HKEY_LOCAL_MACHINE betrifft. In Zeile 78 erfolgt jedoch die abermalige Verwendung des Schlüsselbegriffes CLASS, diesmal im Zusammenhang mit dem Parameter USER. Von dieser Stelle an handelt es sich um eine Benutzerrichtlinie.

Darüber hinaus sollte dem Leser nun auch aufgefallen sein, dass das Schlüsselwort CLASS kein END-Statement benötigt, welches normalerweise einzelne Abschnitte einer Vorlagedatei abschließt. Hier genügt, wie schon erwähnt, eine Neudefinition von CLASS.

Nachdem mit dem Schlüsselbegriff CLASS der erste Abschnitt definiert wurde, gilt es nun, diesen in einzelne Kategorien zu zerlegen. Dabei hilft einem das Schlüsselwort CATEGORY <Name>, welches den Anfang einer Kategorie kennzeichnet.

Auch der Schlüsselbgriff CATEGORY benötigt einen Parameter, nämlich <Name>, welcher entweder eine ganz normale Zeichenkette darstellt oder als ein Platzhalter für eine Zeichenkette, die in einem anderen Bereich definiert werden muss, fungiert.

Die Möglichkeit, die einem Kategorien bieten, ist jene der Unterteilung. So ist es beispielsweise möglich, dass einzelne Kategorien weitere Kategorien oder Sammlungen von Systemrichtlinien beinhalten. Im Idealfall sind jene so geordnet, dass sie entweder Anderungen im selben Registrierungsschlüssel betreffen, oder dass sie einen thematischen Zusammenhang bilden.

Die Verwendung von mehreren CATEGORY Abschnitten ist kein absolutes Muß, hat jedoch oft eine selbsterklärende Wirkung. An diesem Punkt möchte ich auf Zeile 3 des Quellcodes hinweisen, wo man den Schlüsselbegriff CATEGORY im Einsatz erlebt. Als Parameter wird in diesem Fall ein Platzhalter eingesetzt, der in einem anderen Bereich definiert ist.

Der Schlüsselbegriff CATEGORY verhält sich nicht so wie sein Pendant CLASS. Ein großer Unterschied zwischen den beiden ist, dass CATEGORY ein weiteres Schlüsselwort zum Beenden einer Kategorie benötigt. Somit wird der Einsatz von END CATEGORY notwendig, welches einzelne Kategorien schließt.

Der Ausdruck POLICY <Name> wird verwendet um eine Systemrichtlinie zu kennzeichnen. Diese kann ein oder mehrere Einstellungen oder direkte Wertvorgaben enthalten und erscheint im Systemrichtlinieneditor als Checkbox. Wie auch der Schlüsselbegriff CATEGORY muss POLICY in Verbindung mit einem Parameter aufgerufen werden. Dieser beinhaltet die gleiche Funktion wie jener des Schlüsselwortes CATEGORY.

Das Schlüsselwort END POLICY hat die gleiche Aufgabe wie END CATEGORY. Der einzige Unterschied ist, dass END POLICY nicht eine Kategorie sondern eine Systemrichtlinie beendet.

Durch das bereits bekannte CLASS-Statement ist der zu bearbeitende Hauptschlüssel schon festgelegt. Leider kann der Systemrichtlinieneditor anhand dieser spärlichen Information noch keine Werte in der Registrierung verändern. Eine genauere Definition ist hier notwendig. Dazu wird der Schlüsselbegriff KEYNAME <Schlüsselname> eingesetzt, der den kompletten untergeordneten Pfad von diesem Hauptschlüssel zum Schlüssel der Registrierung, auf den sich die Richtlinie bezieht, bezeichnet. Der Parameter, der dem Statement folgt, gibt den Pfad an, der zu dem gewünschten Registrierungseintrag führt.

Verwendet wird das Schlüsselwort KEYNAME meistens in einem CATEGORY-Abschnitt, wie es das Beispiel in Zeile 24 demonstriert. Eine weitere Möglichkeit ist es, den Schlüsselbegriff innerhalb eines POLICY-Abschnittes einzusetzen, wie man es anhand der Programmiertechnik aus Zeile 5 erkennen kann.

Wie auch das Schlüsselwort CLASS verlangt KEYNAME kein abschließendes Statement, welches den Definitionsbereich schließt.

Mit dem Statement PART <Name> wird ein Abschnitt definiert, der Einstellungen für eine Systemrichtlinie kennzeichnet. Dieser kann im Vergleich zu Abschnitten, die mit den Schlüsselbegriffen CATEGORY und POLICY erzeugt wurden, keine weiteren Unterabschnitte mehr enthalten. So dient der mit PART erzeugte Bereich zum Manipulieren von Registrierungseinträgen und zum Ausgeben eines Erklärungstextes für die aktuelle Richtlinie.

Aufgrund des vorliegenden Quellcodes kann das Verhalten des Schlüsselwortes PART besser verstanden werden. In Zeile 7 wird beispielsweise ein PART-Abschnitt erzeugt. Auffallend ist, dass er eine ähnliche Funktion ausübt wie die Schlüsselbegriffe CATEGORY und POLICY. Ein PART-Bereich ist aber der kleinste Abschnitt, den man in Vorlagedateien erzeugen kann. Innerhalb eines PART-Abschnittes folgen danach Anweisungen, die zum Bearbeiten der Registrierung oder zur Ausgabe eines Informationstextes dienen.

Immer wenn in einer Vorlagedatei ein Abschnitt definiert wird, so muss dieser am Ende wieder geschlossen werden (Ausnahme: CLASS-Bereiche). Dies ist auch bei dem Schlüsselwort PART der Fall, welches zum Beenden das Statement END PART einsetzt.

Das EDITTEXT Statement erzeugt ein Eingabefeld für Zeichenketten, welches zur Bearbeitung von Werten des Datentyps REG_SZ vorgesehen ist.

Weiters ist zu sagen, dass es nur in einem vom Schlüsselwort PART definierten Abschnitt eingesetzt werden kann. Außerhalb dieses Bereiches ist EDITTEXT nicht einzusetzen.

Mit dem Schlüsselbegriff VALUENAME <Wertname> kann man den Wertnamen innerhalb eins Registrierungsschlüssel definieren, der von der Richtlinie betroffen ist. Der Hauptschlüssel und die Unterschlüssel selbst müssen jedoch vorher von einem KEYNAME-Statement festgelegt werden. Der Parameter, den VALUENAME verlangt, stellt den Wertnamen dar, der dann von der Richtlinie verändert werde kann.

Dies kann man auch anhand des Beispiels erkennen, wo das KEYNAME-Statement beispielsweise in Zeile 5 steht. Darauf folgt die Definition eines PART-Abschnittes (Zeile 7), der wiederum das Schlüsselwort VALUENAME (Zeile 8) enthält.

Der Befehl NUMERIC erzeugt ein Feld mit einem Stellrad für die Eingabe numerischer Zeichen. Dieser Typ erlaubt das Andern von Werten der Typen REG_DWORD und REG_SZ. Das Schlüsselwort NUMERIC arbeitet daher ähnlich wie das EDITTEXT-Statement. Daher kann es auch nur innerhalb eines PART-Abschnittes verwendet werden.

Mit dem Befehl MIN <Wert> kann man den Minimalwert eines Eingabefeldes setzen. Bei jenen Eingabefeldern, bei denen dieses optionale Attribut nicht verwendet wird, ist der Minimalwert standardmäßig 0. Weiters ist es auch möglich den Minimalwert mit einer negativen Zahl zu belegen, was jedoch nur bei wenigen Richtlinien gebraucht wird. Der Parameter, der dem Statement übergeben wird, legt den Minimalwert fest.

Das Schlüsselwort MAX <Wert> legt den Maximalwert eines Eingabefeldes fest. Ist dieses Attribut nicht gesetzt, so wird als Standardwert 9999 verwendet. Ebenso wie der Befehl MIN erwartet MAX einen Parameter, der den Maximalwert des Eingabefeldes entgegennimmt. Diesem können jedoch nicht nur Zahlen übergeben werden, die kleiner als 9999 sind, sondern auch solche, die um ein Vielfaches größer sind.

Das SPIN <Wert>-Statement gibt das Intervall an, mit dem der Wert im Eingabefeld steigt beziehungsweise sinkt, wenn auf das Stellrad geklickt wird. Das Standardintervall ist 1. Wird dem Befehl SPIN als Parameter der Wert 0 übergeben, so werden die Einstellregler auf der Seite des Eingabefeldes entfernt.

Ein Beispiel für die Verwendung der Befehle NUMERIC, MIN, MAX und SPIN kann man in der Zeile 28 finden. Das Ergebnis ist ein Eingabefeld mit Einstellreglern, welches als Minimalwert 0 erhalten kann, als Maximalwert 1000, und welches bei Betätigung der Regler den Wert um jeweils 1 vergrößert oder verringert.

Ist das Kontrollkästchen einer Systemrichtlinie im Systemrichtlinieneditor aktiviert, so wird dem aktuellen Registrierungseintrag, der vorher durch den Befehl VALUENAME festgelegt wurde, dieser Wert zugewiesene. VALUEON <Wert> verlangt einen Parameter, der bei Aktivierung einer Richtlinie in die Registrierung eingetragen wird.

Im Quellcode kann man ein solches Beispiel in Zeile 40 finden. Dort wird es in Verbindung mit dem Parameter Schlüsselwort NUMERIC eingesetzt. Das Ergebnis ist, dass bei Aktivierung der Richtlinie der Wert 1 als Datentyp REG_DWORD in der Registrierung eingetragen wird.

Der Schlüsselbegriff VALUEOFF <Wert> arbeitet ähnlich wie VALUEON. In diesem Fall wird der als Parameter übergebene Wert aber nur eingetragen, wenn die Richtlinie im Systemrichtlinieneditor deaktiviert wird. Natürlich muss man auch hier darauf achten, dass vorher mit dem Befehl VALUENAME ein Wert definiert wird, den es zu verändern gilt.

Verwendung findet das VALUEOFF-Statement in Zeile 41 des Quellcodes. Wiederum ist es mit dem Schlüsselwort NUMERIC gekoppelt, was bedeutet, dass bei Deaktivierung der Richtlinie der Wert 0 in der Registrierung unter dem vorgegebenen Eintrag gespeichert wird. Darüber hinaus sollte man erwähnen, dass dem VALUEOFF Befehl meistens der Schlüsselbegriff VALUEON vorangeht.

Mit dem CHECKBOX Befehl kann ein Kontrollkästchen erzeugt werden, welches Datentypen des Wertes REG_SZ manipulierbar macht. Wie es auch schon bei dem Statement EDITTEXT der Fall ist, kann das Schlüsselwort CHECKBOX nur in einem Abschnitt verwendet werden, der mit dem Schlüsselbegriff PART erzeugt wurde.

Das Schlüsselwort DORPDOWNLIST stellt eine Drop-Down-Liste dar, bei der die Eingabe eines Textes nicht möglich ist.

Der Datentyp der Werte, die dieses Element bearbeiten kann, hängen von der näheren Definition der Auswahlliste ab. Weiters ist anzumerken, dass der Befehl DROPDOWNLIST nur innerhalb eines PART-Abschnittes eingesetzt werden kann.

Mit dem Schlüsselbegriff REQUIRED lässt sich eine Eingabe des Benutzers erzwingen. Steht kein Wert in diesem Eingabefeld, so lässt sich die Richtlinie nicht aktivieren.

NOSORT ist ein spezieller Bezeichner, der nur in Verbindung mit dem Schlüsselwort DROPDOWNLIST eingesetzt werden kann. Es bewirkt, dass die Einträge, die in der Drop-Down-Liste aufscheinen, nicht alphabetisch sortiert werden.

Wie der Schlüsselbegriff NOSORT ist das ITEMLIST-Statement eng mit dem Erzeugen einer Drop-Down-Liste verbunden. Das Schlüsselwort ITEMLIST erzeugt eine Liste von Vorgaben, die dann in der Auswahlliste angezeigt werden. Vor dieser Aufzählung muss der zu ändernde Werte per VALUENAME bezeichnet sein (zwischen dem Schlüsselwort DROPDOWNLIST und ITEMLIST). Eine Vorgabe ist immer nach dem Muster NAME <Name> VALUE <Wert> aufgebaut. Der Parameter Name ist dabei die Zeichenfolge, die in der Drop-Down-Liste erscheint. Den dazugehörigen Wert legt das Schlüsselwort VALUE über den Parameter Wert fest. Dabei werden Datentypen vom Typ REG_SZ in der Registrierung verändert oder eingetragen, es sei denn, es wird der Befehl NUMERIC vorangestellt, dann ist der Datentyp vom Wert REG_DWORD.

Ein Beispiel für eine Drop-Down-Liste findet sich im Quellcode von Zeile 99 bis Zeile 110. Dort wird zuerst mittels DROPDOWNLIST eine Liste erzeugt, die weiters mittels Gebrauch von REQUIRED eine verpflichtende Eingabe erwartet, ansonsten kann die Richtlinie nicht aktiviert werden. Der Befehl NOSORT verbietet der Drop-Down-Liste die Einträge nach dem Alphabet zu ordnen. Danach wird mit Hilfe des Schlüsselwortes VALUENAME der Registrierungseintrag definiert, der von der Richtlinie betroffen ist. Zu guter Letzt wird die Vorgabenliste mit Einträgen durch das ITEMLIST-Statement erzeugt, die dann in der Drop-Down-Liste aufscheinen.

Das END ITEMLIST-Statement ist für das Beenden von Abschnitten, die mit dem Befehl ITEMLIST erzeugt wurden, zuständig. Dies kann man in der Zeile 110 sehen, wo eine Vorgabenliste mit einigen Einträgen geschlossen wird.

Mit dem Schlüsselbegriff LISTBOX können Werte-Listen erstellt werden. Dazu wird ein eigenes Dialogfeld angezeigt, in dem man mittels der Schaltflächen Hinzufügen und Entfernen verschiedene Werte verändern kann. Das Schlüsselwort VALUENAME darf nicht in Verbindung mit LISTBOX verwendet werden, da der Werte-Name innerhalb der Liste zugeordnet wird.

Der Befehl VALUEPREFIX <Präfix> legt fest, ob die Wertnamen für die Liste fest vorgegeben und durchnummeriert werden. Es können dann nur diese Werte geändert werden. Lautet das Präfix zum Beispiel Daten, so erscheinen die Werte als Daten1, Daten2 und so weiter. Der Präfix kann dabei je nach Bedarf gewählt werden und wird dem Befehl VALUEPREFIX als Parameter übergeben.

Das Beispiel zu diesem Schlüsselwort findet man in Zeile 124. Vorher aber wird innerhalb eines PART-Abschnittes noch eine Werte-Liste durch das LISTBOX-Statement erzeugt. Danach muss der Schlüssel definiert werden, wo der Eintrag bearbeitet werden soll, was mittel KEYNAME ausgeführt wird. Erst jetzt kann man den Präfix, der die Daten durchnummeriert, mittels des Befehles VALUEPREFIX hinzufügen. Das Resultat dieser Vorgangsweise ist eine Werte-Liste, in der man einzelne Werte ändern, eintragen oder herauslöschen kann.

Der Schlüsselbegriff TEXT kann ausnahmslos nur innerhalb eines PART-Abschnittes operieren. Dabei liefert er den Text, der als PART-Name angegeben wurde, ohne ein Eingabefeld im unteren Teil des Systemrichtlinieneditors. Der Begriff TEXT dient daher vor allem zum Einfügen von Erläuterungstexten.

Nachdem nun alle Schlüsselworte, die in dieser Vorlagedatei Verwendung finden, genau erklärt wurden, so stellt sich wahrscheinlich doch noch eine letzte Frage: "Was sind diese komischen Zeichen (z.B.: !!LaufwerkeWegschalten1), die anstatt einiger Parameter gebraucht werden?".

Dabei handelt es sich um sogenannte Platzhalter oder Variablen, die anstatt der Zeichenketten eingesetzt werden. Definiert werden diese aber erst zum Schluß der Vorlagedatei, nämlich im Bereich nach dem Eintrag [strings]. Ist die Vorlage nun im Systemrichtlinieneditor eingebunden, so erscheinen anstatt der Platzhalter jener Text, der der Variablen im [strings]-Abschnitt zugewiesen wird.

Eine andere Möglichkeit wäre es die Zeichenketten direkt nach den Schlüsselwörtern einzusetzen. Da aber einige von ihnen sehr lang sind würde die Vorlagedatei unübersichtlich und unlesbar werden. Deshalb ist es besser das System mit den Platzhaltern zu verwenden.

Ein weiteres wichtiges Feature, welches die Skriptsprache von Microsoft unterstützt, ist das einbinden von Kommentaren in den Quelltext. Dazu muss man in einer Zeile nur einen Strichpunkt (;) einfügen, womit die ganze Zeile für eine Anmerkung zur Verfügung steht. Eine Kommentarzeile symbolisiert das folgende Beispiel:

Ist eine Vorlagedatei erst einmal in den Systemrichtlinieneditor eingebunden so werden die Kommentare entfernt und sind daher nicht mehr sichtbar. Dies ist der Grund warum Kommentare entweder nur während der Programmierung einer ADM-Datei nützlich sind oder nur das Verstehen der Syntax bzw. des Quellcodes erleichtert.

Da man nun bereits wissen sollte, wie die Syntax bzw. der Quellcode einer Vorlagedatei aufgebaut ist, möchte ich nun zu jenem Teil kommen, in dem die Darstellung von ADM-Dateien mittels des Systemrichtlinieneditors besprochen wird.

Nachdem man eine selbst programmierte Vorlagedatei entwickelt hat, so ist es jedesmal ein Vergnügen, diese auch in der Praxis auszutesten. Dazu muss natürlich zuerst der Systemrichtlinieneditor gestartet werden. Der nächste Schritt ist es, die ADM-Datei über den Menübefehl Optionen Richtlinienvorlage in den Policy-Editor einzubinden. Erhält man hierbei keine Fehlermeldung des eingebauten Syntaxcheckers, so kann man sich berechtigte Hoffnungen machen, dass die Vorlagedatei auch tatsächlich in der Praxis funktionieren wird. Damit wären die Vorbereitungen für das Erstellen einer Richtlinie abgeschlossen.

◄ Abb. 4.3.1.: Zeigt die Standardsymbole des System-richtlinieneditors, die nach dem Erstellen einer neuen Richtlinie erscheinen.

Der nächste Schritt wäre somit das Erzeugen einer neuen Richtlinie, was man mit dem Menübefehl Datei Neue Richtlinie bewerkstelligt. Als Folge erscheinen zum ersten Mal zwei Symbole im Systemrichtlinieneditor. Bei ihnen handelt es sich um die Symbole des Standardbenutzers und des Standard-Computers (siehe Abb. 4.3.1.).

Dazu sollt man wissen, dass jene Richtlinien, die sich im CLASS USER-Bereich einer Vorlagedatei finden, in der Kategorie Standardbenutzer, bzw. anderen Benutzern oder Benutzergruppen wieder zum Vorschein kommen. Systemrichtlinien, die im CLASS MACHINE-Bereich definiert wurden, können nur mit dem Standard-Computer oder einem benutzerdefinierten Computer zusammenarbeiten.

Mit jenen Befehlen, die man unter dem Menüpunkt Bearbeiten findet, kann man nun Benutzer, Computer oder Benutzergruppen hinzufügen, für die die Richtlinie eingesetzt werden soll. Dabei ist zu beachten, dass für jeden Benutzer, Computer oder jede Gruppe eigene Registrierungs- bzw. Richtlinienvorlagen erstellt werden können. Ist ein Benutzer dann beispielsweise Mitglied mehrerer Gruppen, so kann man über den Menüeintrag Optionen Gruppenpriorität die Priorität einzelner Gruppen (siehe Abb. 4.3.2.) festlegen. Dies wirkt sich nun natürlich auch auf den Benutzer aus, da die Priorität entscheidet, welche Richtlinien nun für ihn mit welchen Werten in Kraft treten.

Diese Grafik stellt den Dialog dar, über welchen man die Gruppenpriorität einer Benutzergruppe festlegen kann. Verwendet werden dafür die Knöpfe Nach oben und Nach unten, welche in dieser Abbildung jedoch deaktiviert sind, da keine Benutzergruppe angeklickt ist.

► Abb. 4.3.3: Stellt das Hauptfenster des System-richtlinieneditors dar, nachdem ein weiterer Benutzer namens Benutzer und eine Benutzergruppe namens Gruppe hinzugefügt wurde.

Durch einen Doppelklick auf eines dieser vier Symbole (siehe Abb. 4.3.3.) erscheint ein neues Dialogfeld, welches die Richtlinien für den gewählten Benutzer, Computer oder die gewünschte Benutzergruppe anzeigt. Alle Anderungen, die in der Registrierung vorgenommen werden sollen, sind über diesen Dialog und dessen abgebildete Richtlinien zu spezifizieren. Hierbei wäre es überdies von Vorteil sich noch einmal die Abb. 3.1.1 näher anzusehen, welche alle möglichen Zustände einer Richtliniencheckbox erklärt.

Als nächstes gelangt man zur hierarchischen Übersicht der Richtlinien (siehe Abb. 4.3.4.), die in jenem ominösen Dialogfeld angezeigt werden, welches uns bereits im vorhergegangenen Absatz beschäftigte. Dies ist auch das erste Mal, bei dem man die Unterteilung einer ADM-Datei in verschiedene Abschnitte zu sehen bekommt. Am Beginn steht, wie man bereits weiß, der Bezeichner CLASS. Dieser wird graphisch entweder von einem Symbol für den Standardbenutzer oder den Standard-Computer repräsentiert, welches natürlich an oberster Stelle steht. Das nächste Schlüsselwort in der Hierarchie ist CATEGORY. Im Dialogfeld wird dieser Bezeichner durch ein Buchsymbol ersetzt, an welches der Name der Kategorie angehängt wird. Innerhalb dieser Kategorie findet man nun eine oder mehrere Richtlinien, die mit dem Befehl POLICY erzeugt werden. Als Symbol für das Schlüsselwort wird die vielbesprochene Richtliniencheckbox eingesetzt. Über diese kann man nun endlich einzelne Werte in der Registrierung verändern.

Als optionale Abschnitte können nun wiederum PART-Bereiche innerhalb des Richtlinienabschnittes ihren Platz finden. Diese dienen vorwiegend zur Eingabe von Registrierungswerten oder zur bloßen Ausgabe von Informationstexten. Angezeigt werden PART-Abschnitte in einem speziellen Bereich des Dialogfeldes Eigenschaften, welcher grau hinterlegt ist. In diesem separaten Fenster werden danach die einzelnen Eingabefelder ausgegeben, die von der Vorlagedatei in dem betreffenden PART-Abschnitt definiert wurden.

Abb. 4.3.3: Aus dieser Grafik kann man die Einteilung einer Vorlagedatei in ihre einzelnen Bereiche entnehmen, und wie sie im Systemrichtlinieneditor dargestellt wird.

In diesem Anhang möchte ich kurz jene Schlüsselbegriffe der Skriptsprache von Microsoft erklären, die in meinem praktischen Beispiel keinen Platz mehr gefunden haben. Jedoch wird die Beschreibung dieser Befehle um einiges kürzer ausfallen als der praktische Teil dieser Arbeit, da sonst der Rahmen gesprengt werden würde.

Die folgende Liste beinhaltet alle restlichen, noch nicht verwendeten Schlüsselbegriffe der Skriptsprache:

ACTIONLISTON: Ist die Checkbox dieser Richtline aktiviert, so wird der Teil bis zum Statement END ACTIONLIST abgearbeitet. Auf dieses Schlüsselwort folgt eine Liste von zu manipulierenden Werten in der Registry. Diesen weist man per VALUE-Statement einen Wert zu. Über KEYNAME lässt sich auch ein neuer Schlüssel definieren. VALUEON und VALUEOFF sind im ACTIONLIST-Statement nicht zulässig.

COMBOBOX: Zeigt eine Drop-Down-Liste an, die verschiedene Auswahlmöglichkeiten, aber auch die Eingabe eines Textes ermöglicht - also eine Mischung aus EDITTEXT und DROPDOWNLIST. Damit lassen sich Werte des Datentyps REG_SZ bearbeiten.

DEFAULT <Wert>: Gibt den Anfangswert des Eingabefeldes (TEXTBOX) an. Fehlt dieses Schlüsselwort, so ist das Eingabefeld zu Beginn leer.

TXTCONVERT: Schreibt den eingegebenen Wert nicht als Zahl, sondern als Zeichenkette. Resultierender Datentyp in der Registrierung ist REG_SZ.

SUGGESTIONS, END SUGGESTIONS: Enthält eine Liste von Vorgaben für die Drop-Down-Liste. Zeichenketten, in denen ein Leerzeichen vorkommt, müssen unter Anführungszeichen stehen, ansonsten interpretiert das System sie als mehrere Zeichenketten.

DELETE: Folgt dem Schlüsselwort VALUE der Befehl DELETE, so wird der entsprechende Eintrag aus der Registrierung entfernt.

EXPLICITVALUE: Lässt es zu, im Editor von Hand einen Wertnamen und den dazu-gehörigen Wert anzugeben. In der Liste sind dann je Wert zwei Felder auszufüllen. Dieses Schlüsselwort kann nicht mit VALUEPREFIX zusammen eingesetzt werden.

ADDITIVE: Ermöglicht die bereits in diesem Schlüssel befindlichen Werte in der Liste anzuzeigen. Neu eingegebne Werte fügt das System dann hinzu anstatt die alten Einträge zu überschreiben.

6. Nachwort

Am Ende meiner Arbeit angelangt, wird es Zeit, sich bei allen Helfern/-innen herzlichst zu bedanken, die sich für meine Arbeit interessiert und auch eingesetzt haben. Insbesonders möchte ich hier Herrn Prof. Franz Furtschegger danken, der als Informatiklehrer die Betreuung dieses Projektes innehatte. Ihm gelang es immer wieder mich mit teils psychologischem Geschick zu motivieren, was einigen kreativen Durststrecken ein Ende setzte. Darüber hinaus bin ich für das Korrekturlesen zu großem Dank verpflichtet.

Einen weiteren großen Anteil bei der Entstehung meines Projektes hatten meine Eltern, die mir immer mit Rat und Tat zur Seite standen.

Das Verfassen meiner Fachbereichsarbeit hat mir viel Freude bereitet und ich hoffe, eine in Form und Inhalt ansprechende Arbeit geliefert zu haben.

Literaturverzeichnis

Luetzow, J. (1997): NT-Registry im Überblick, in: PC Professionell Nr.5/1997: 208-211

Luetzow, J. (1997): System- und Oberflächentuning per Registry, in: PC Professionell Nr.5/1997: 212-220

Savill, J. (1998): Windows NT Frequently Asked Questions, Savill Tech Ltd, https://www.ntfaq.com

Zero Administration Kit for Windows, Microsoft, https://www.microsoft.com/windows/zak

Guide to Microsoft Windows NT Profiles and Policies, Microsoft, https://www.microsoft.com/ntserver/zipdocs/prof_policies.exe

Betriebstechnik	Biographien	Biologie	Chemie	Deutsch	Digitaltechnik
Electronica	Epochen	Fertigungstechnik	Gemeinschaftskunde	Geographie	Geschichte
Informatik	Kultur	Kunst	Literatur	Management	Mathematik
Medizin	Nachrichtentechnik	Philosophie	Physik	Politik	Projekt
Psychologie	Recht	Sonstige	Sport	Technik	Wirtschaftskunde