15.18 Switch User nutzen, um mit beliebigen Rechten zu operieren
Das Anmeldeskript soll aber nicht nur dazu dienen, Laufwerksbuchstaben nach Gruppenzugehörigkeit zuzuweisen. Wie in der Einleitung dieses Kapitels erwähnt wurde, können mit Hilfe des Anmeldeskripts beliebige Operationen und Einstellungen in der Umgebung des sich anmeldenden Benutzers, aber auch im Betriebssystem selbst vorgenommen werden, bis hin zur Deinstallation, zur Installation oder zum Update ganzer Anwendungen und natürlich zum Einspielen von Service Packs für das Betriebssystem Windows XP.
Nun läuft aber das Anmeldeskript im Rechtekontext des sich anmeldenden Anwenders ab. Der Anwender gehört jedoch in der Regel zur Gruppe der Domänenbenutzer und ist damit nicht berechtigt, Dateien an beliebiger Stelle der lokalen Festplatte auszutauschen, neue Verzeichnisse anzulegen, Registrierschlüssel unter HKEY-LOCAL-MACHINE zu ändern, zu löschen oder einzufügen oder Dienste zu installieren. Alle diese Aufgaben können jedoch über ein zentrales Anmeldeskript erfüllt werden, wenn man das Tool Switch User (su.exe) aus dem Windows Server Resource Kit einsetzt. Switch User (SU) arbeitet ähnlich wie unter Windows XP der Befehl run as, jedoch mit dem Unterschied, dass man in einer Batchdatei die Kennung und das Passwort eines anderen Benutzerkontos übergeben kann. SU besteht aus den zwei Komponenten su.exe und suss.exe. Auf jeden Windows-XP-Rechner müssen diese beiden exe-Dateien unter C:\Windows\System32 eingespielt und der SU-Dienst muss einmalig mit dem Befehl suss –install installiert werden. Diese Routine erledigt eine Batch-Datei, die beim Start des Clients mittels einer Gruppenrichtlinie aktiviert wird: Die beiden exe-Dateien su.exe und suss.exe werden in das Verzeichnis \\s1\netlogon\util kopiert. Im Verzeichnis \\s1\netlogon\batch wird eine Routine Start.cmd mit folgendem Inhalt angelegt:
@echo off
cls
echo Startskript wird durchgefuehrt ...
if exist c:\windows\system32\su.exe goto WEITER
copy \\s1\netlogon\util\su.exe c:\windows\system32\su.exe /y
copy \\s1\netlogon\util\suss.exe c:\windows\system32\suss.exe /y
suss.exe –install
:WEITER
Der Parameter /y hinter dem copy-Befehl stellt sicher, dass eine bereits vorhandene Datei überschrieben wird, ohne dass um eine Bestätigung gebeten wird. Der Befehl suss · install installiert den SU-Dienst als automatisch zu startenden Dienst. Sie können weitere copy-Befehle anhängen, um über diese Routine andere Tools in den Suchpfad %SystemRoot%\system32 der Clients einzuspielen.
Als Nächstes erzeugen Sie mit dem Snap-In Active Directory-Benutzer und –Computer eine neue OU Computer und verschieben den Windows-XP-Client dorthin. Jetzt erstellen Sie für die neue OU Computer eine Gruppenrichtlinie: Sie stellen die Maus auf die OU Computer, klicken die rechte Maustaste und wählen Eigenschaften, dann die Registerkarte Gruppenrichtlinien und die Schaltfläche Neu. Als Namen für die neue Gruppenrichtlinie vergeben Sie Install. Wählen Sie nun die Schaltfläche Eigenschaften und dort Benutzerdefinierte Konfigurationseinstellungen deaktivieren. Da diese Richtlinie nur für Computer genutzt wird, jedoch keine Einstellungen für Benutzer in dieser Richtlinie vorgenommen werden, kann die Abarbeitung der Richtlinie beschleunigt werden, wenn diese Option markiert wird.
Hier klicken, um das Bild zu Vergrößern
Über die Schaltfläche OK verlassen Sie die Eigenschaften und wählen sofort Bearbeiten, um ein Startskript für alle Computer zu aktivieren, die in dieser OU Computer liegen. Wählen Sie dafür unter Computerkonfiguration · Windows-Einstellungen · Skripts (Start/Herunterfahren) die Richtlinie Starten.
Hier klicken, um das Bild zu Vergrößern
Geben Sie über die Schaltfläche Hinzufügen das Startskript \\s1\netlogon\batch\start.cmd an.
Hier klicken, um das Bild zu Vergrößern
Sie müssen den Windows-XP-Computer unter Umständen zweimal neu starten, damit das Startskript ausgeführt wird, oder auf dem Client den Befehl gpupdate /force eingeben, damit die neue Gruppenrichtlinie nicht erst beim übernächsten Start des Clients übernommen wird. Über Gruppenrichtlinien aktivierte Startskripte werden ausgeführt, sobald der PC neu startet. Es muss sich niemand an diesem PC anmelden, damit das Startskript abläuft.
Das Startskript läuft im Rechtekontext System ab. Somit können beliebige Aktionen ausgeführt werden. Wenn Sie beobachten möchten, wie das Startskript abläuft, müssen Sie entweder die Zeile @echo off deaktivieren oder eine Echo-Zeile einbauen (echo Startskript wird abgearbeitet) und außerdem unter Computerkonfiguration · Administrative Vorlagen · System die Richtlinie Startskripte sichtbar ausführen aktivieren.
Hier klicken, um das Bild zu Vergrößern
Beachten Sie bei der Erweiterung von Startskripten Folgendes: Da das Startskript auch ohne die Anmeldung eines Benutzers ausgeführt wird, sobald der Computer eine Verbindung zur Domäne aufgebaut hat, kann man in einem Startskript nicht die Variable %LOGONSERVER% verwenden.
Für das weitere Vorgehen benötigen Sie eine neue globale Sicherheitsgruppe local Admins oder Client Admins und eine unscheinbare Kennung, die in die Gruppe local Admins aufgenommen wird. Legen Sie die Sicherheitsgruppe local Admins und die Kennung Intel mit dem Passwort telin1 an. Die Kennung Intel wird in die Gruppe local Admins aufgenommen und erhält kein Exchange-Postfach.
|
Es versteht sich von selbst, dass Sie in einer Produktivdomäne eine andere Kennung als »Intel« und ein komplexes Kennwort für diese Kennung verwenden sollten. Wählen Sie eine Kennung, aus deren Namen nicht hervorgeht, wozu sie verwendet wird.
|
Die nächste Aufgabe besteht darin, dafür zu sorgen, dass die Domänengruppe local Admins in die lokale Gruppe der Administratoren aller Clients eingepflegt wird. Jeder Domänenbenutzer, der später in die Gruppe local Admins aufgenommen wird, kann alle Computer der Organisation administrieren, ohne zur Gruppe der Domänen-Admins zu gehören. Sie können also später alle Mitglieder des Benutzersupports in diese Gruppe einpflegen. Sie können aber auch andere Poweruser zumindest temporär in diese Gruppe aufnehmen.
Ein Beispielszenario soll die Möglichkeiten der Gruppe local Admins verdeutlichen: Sie haben ihre gesamte Anwendersoftware in der Freigabe \\s1\install auf dem Dateiserver abgelegt. Dort gibt es auch ein Verzeichnis \\s1\install\visio, auf das nur die Gruppe local Admins Leserechte hat. Die Anwendung Visio soll nur auf bestimmten Clients installiert werden. Ein Mitarbeiter, auf dessen PC bisher kein Visio installiert war, soll zukünftig mit Visio arbeiten. Es handelt sich um einen EDV-erfahrenen Mitarbeiter, dem Sie zutrauen, dass er sich Visio selbst installieren kann. Sie nehmen den Mitarbeiter in die Domänengruppe local Admins auf, rufen ihn an und bitten ihn, sich mit der Freigabe \\s1\install zu verbinden und das Setup aus dem Unterverzeichnis \\s1\install\visio zu starten. Sobald die Installation von Visio durchlaufen ist, entfernen Sie den Benutzer wieder aus der Gruppe local Admins. Dadurch entziehen Sie dem Benutzer wieder das Recht, Unterverzeichnisse der Freigabe \\s1\install zu sehen oder Anwendungen auf dem Client installieren zu dürfen.
Um die globale Gruppe local Admins der lokalen Gruppe Administratoren hinzuzufügen, benötigen Sie den Befehl net localgroup Administratoren »Company\local Admins« /add. Diesen Befehl nehmen Sie in die Routine \\s1\netlogon\batch\start.cmd mit auf:
@echo off
cls
echo Startskript wird durchgefuehrt ...
if exist c:\windows\system32\su.exe goto WEITER
copy \\s1\netlogon\util\su.exe c:\windows\system32\su.exe /y
copy \\s1\netlogon\util\suss.exe c:\windows\system32\suss.exe /y
suss.exe –install
net localgroup Administratoren "Company\local Admins" /add
:WEITER
Der Befehl su.exe hat folgende Syntax: su.exe Kennung <Befehl>
Der Befehl su.exe Intel %LOGONSERVER%\netlogon\cmd\xyz.cmd würde die Routine xyz.cmd mit allen in ihr enthaltenen Befehlen unter lokalen administrativen Rechten durchführen, weil die Kennung Intel Mitglied der globalen Gruppe local Admins ist und diese globale Gruppe wiederum ein Mitglied der lokalen Gruppe Administratoren. Jedoch würde der Befehl interaktiv zuerst nach dem Passwort der Kennung Intel fragen. Der Befehl echo telin1| su.exe intel %LOGONSERVER%\netlogon\cmd\xyz.cmd würde das Passwort telin1 zwar mit dem Umleitungszeichen an das Tool su.exe übergeben (beachten Sie, dass zwischen dem Passwort und dem Umleitungszeichen »|« kein Leerzeichen stehen darf!), jedoch wäre es ein Sicherheitsloch, wenn das Passwort der Kennung Intel in Klarschrift in einem Anmeldeskript stünde. Jetzt kommt »Trick 17 mit Selbstüberlistung«. Dieses Problem lässt sich nämlich prinzipiell ungefähr so lösen: Man erzeugt eine Batchroutine namens intel.bat mit folgenden Befehlen:
@echo off
cls
c:
cd\
if %1.==. goto ENDE
echo telin1| su.exe intel %1 /e /l
:ENDE
Zuerst sorgt die Routine dafür, dass in die Wurzel des Laufwerks C: gewechselt wird. Die Routine intel.bat wechselt ja später in den Sicherheitskontext des neuen Benutzers Intel. Der Kennung Intel sind jedoch das Laufwerk und der Pfad eventuell nicht bekannt, die zu dem Zeitpunkt aktiv sind, zu dem mittels su.exe in die Kennung Intel gewechselt wurde. Befindet sich der Benutzer, der sich anmeldet, in seinem Basisverzeichnis und sind für diesen Benutzer z.B. bestimmte Netzlaufwerke wohl definiert, so gilt dieses nicht zugleich für die Kennung Intel, zu der gewechselt wird. Wird aber vorher nach C:\ gewechselt, so steht auch die Kennung Intel im Verzeichnis C:\, sobald sie mittels su.exe aktiviert wird.
Die Zeile if %1.==. goto ENDE stellt sicher, dass su.exe nicht ohne Angabe eines Parameters gestartet wird. Der Parameter ist später die unter der Kennung Intel auszuführende Routine. Eine alternative Syntax wäre if »%1«==»« goto ENDE.
Die Parameter /e und /l in der Zeile, in der das Tool su.exe gestartet wird, sorgen dafür, dass der Kennung Intel die Umgebungsvariablen der aufrufenden Kennung übergeben werden. Damit kennt die Kennung Intel z.B. anschließend den Inhalt der Variablen %LOGONSERVER%. Das Passwort intel1 wird über das Umleitungszeichen »|« an das Tool su.exe übergeben, wobei zwischen dem Passwort und dem Umleitungszeichen kein (!) Leerzeichen stehen darf.
Lesen Sie in der Dokumentation des Resource Kits unter »Switch User« nach, welche Bedeutung die einzelnen Parameter haben. Machen Sie sich generell kundig, welche Möglichkeiten SU bietet.
Erscheint die Fehlermeldung CreateProcessAsUser error! (rc=3) beim Aufruf des SU-Tools, so deutet sie darauf hin, dass nicht in den Kontext des neuen Users gewechselt werden kann, weil die Umgebung, aus der gewechselt werden soll, für den neuen User nicht passt. Die zu Windows 2000 Server gehörende SU-Version verursachte allerdings nicht nur bei mir, sondern auch bei anderen Lesern der Erstauflage einige Probleme und diverse Fehlermeldungen wie z.B. Fehlermeldung »CreateProcessAsUser error! (rc=1780), An den Stub wurde ein Nullzeiger übergeben. In den Knowledge-Base-Artikeln 265401 und 821546 wird auf das Problem eingegangen. Außerdem wird auf eine neuere Version von SU hingewiesen, die allerdings nicht zum Download angeboten wird: »Contact Microsoft Product Support Services to obtain the fix.« Ich habe übrigens bisher erfolgreich mit dem alten SU-Tool aus dem Resource Kit von Windows NT 4.0 unter Windows XP gearbeitet.
In obiger Batchroutine lautet das Passwort der Kennung Intel telin1. In dieser Batchroutine steht das Passwort noch lesbar und könnte von einem pfiffigen Anwender missbraucht werden. Diese Batchroutine wandelt man mittels des Tools batcom.exe in eine exe-Datei um: batcom intel.bat.
Sie finden das Tool batcom auf der Buch-DVD im Verzeichnis NETLOGON\Util. In der so erzeugten Datei intel.exe kann man das Passwort nur noch mittels eines Hexeditors einsehen. Um noch mehr Sicherheit zu bekommen, verdichtet man die erzeugte exe-Datei mit einem Tool wie upx.exe, das Sie ebenfalls auf der Buch-DVD finden: upx intel.exe
Die mittels upx verdichtete Datei intel.exe lässt sich dann auch mit einem Hexeditor nicht mehr analysieren. Das so erzeugte Tool intel.exe kopiert man nach %LOGONSERVER%\netlogon\util.
Auf das Verzeichnis netlogon\util haben die Domänenbenutzer Leserechte. Auf dem Unterverzeichnis netlogon\util\batcom entzieht man allen Benutzern – abgesehen von den Domänen-Admins – die Rechte, so dass kein Anwender die ursprüngliche Routine intel.bat mit dem lesbaren Passwort telin1 einsehen kann.
Das neu generierte Tool intel.exe können Sie für alle möglichen Zwecke einsetzen. Der Befehl %LOGONSERVER%\netlogon\util\intel.exe %LOGONSERVER%\netlogon\cmd\test123.cmd im Anmeldeskript würde z.B. die Routine test123.cmd im Rechtekontext der Kennung Intel ausführen, also mit lokalen administrativen Rechten. In der Routine test123.cmd könnten z.B. Befehle stehen, die den Zweig HKEY_LOCAL_MACHINE in der Registrierdatenbank verändern oder neue Anwendungen installieren. Mit diesem mächtigen Werkzeug können Sie über das Anmeldeskript tun, wonach Ihnen der Sinn steht. Einige Beispiele sollen nachfolgend verdeutlichen, welche Möglichkeiten Ihnen ab sofort zur Verfügung stehen.
|
In einer Produktivumgebung sollten Sie aus Sicherheitsgründen einen anderen Dateinamen für die Routine intel.bat und für das daraus hervorgehende Tool intel.exe verwenden. Ebenso sollten Sie eine andere Kennung als die von mir beispielhaft vorgeschlagene Kennung »Intel« verwenden und für diese Kennung ein sehr sicheres Kennwort vergeben, denn Sie sind nicht der einzige Leser dieses Buches.
|
|
