Grundsätzlich gilt: Wenn ein Programm mit Administratorrechten läuft, mit eingeschränkten hingegen Probleme auftreten, dann hat das nur einen Grund: an irgendeiner Stelle im System sind irgendwelche Rechte zu restriktiv gesetzt. Räumt man dem Programm die nötigen Rechte ein, läuft es wieder problemlos. Doch an welcher Stelle verweigert Windows den Zugriff?
Dafür müssen zwei Programme her: Der Registrymonitor Regmon.exe und der Dateimonitor Filemon.exe, beide von SysInternals. Die Programme überwachen sämtliche Zugriffe auf die Registry beziehungsweise auf Dateien und Ordner, was in diesem Fall aber zu viel des Guten ist: Hier interessiert ja nur, wenn Windows den Zugriff auf irgendwas verweigert, weil die nötigen Rechte fehlen. Das aber lässt sich herausfiltern.
Zuerst startet man beide Programme. Klingt einfacher, als es ist, denn wenn „User“ auf das Programmsymbol doppelklickt, kassiert er bloß eine Fehlermeldung, denn die Programme laufen nur im Sicherheitskontext eines Administratorkontos korrekt. Abhilfe schafft der Menüpunkt „Ausführen als …“ aus dem Kontextmenü jedes Programms. Unter Windows 2000 taucht der nur auf, wenn man beim Rechtsklick zugleich die Shift-Taste gedrückt hält. Voraussetzung ist, dass der dazugehörige Dienst läuft. Der heißt unter Windows 2000 ebenfalls „Ausführen als“, unter XP hingegen „Sekundäre Anmeldung“. Klickt man „Ausführen als …“, öffnet sich ein Fenster, in dem sich unten der „Admin“ auswählen lässt. Noch dessen Kennwort eingeben, und schon starten die Programme im richtigen Sicherheitskontext.
Um die Programme lediglich verweigerte Zugriffe anzeigen zu lassen, setzt man bei Regmon unter Options den Filter auf „accdenied“. Bei Filemon klappt das in der aktuellen Version 6.1 leider nicht direkt, da man hier nicht auf die Rückgabe-Codes („Result“) filtern kann. Ein Trick hilft hier: Man filtert auf „Access“ und trägt bei „Highlight“ den Begriff „Denied“ ein. Alle nicht farblich hervorgehobenen Zugriffe ignoriert man dann einfach. Startet man nun eine Anwendung, protokollieren die Monitor-Programme bestenfalls nichts. Wenn doch, muss das noch lange nicht auf ein Problem hindeuten, denn viele Programme laufen trotzdem tadellos.
Erst wenn ein Programm wirklich zickt gilt: Je näher eine Zugriffsverletzung zeitlich mit dem auftreten des Problems zusammenfällt, umso wahrscheinlicher ist, dass sie die Schuldige ist. Daher stoppt man die Überwachung direkt nach dem Auftreten des Problems. Danach prüft man von hinten nach vorne die aufgetretenen Zugriffsverweigerungen und vergibt bei Bedarf die nötigen Rechte.
Beispiel: Outlook 98 startet problemlos, wenn der Anwender über Administrator- oder zumindest Hauptbenutzerrechte verfügt, besitzt er jedoch nur eingeschränkte Benutzerrechte, passiert einfach gar nichts. Regmon spuckt aber sechs Zeilen mit zwei Schlüsselnamen aus. Der eine enthält den Begriff „Joystick“, was ihn mangels angeschlossenen Joysticks erst mal uninteressant macht. Der andere hingegen namens „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Messaging Subsystem“ ist spannender. Ein Doppelklick darauf der Registry-Editor zeigt ihn an. In dessen Kontextmenü unter „Berechtigungen“ erweitert man die Rechte des Benutzers nun so weit wie nötig. In diesem Beispiel reichen die ebenfalls angezeigten Berechtigungen der Hauptbenutzer, anschließend startet und läuft Outlook problemlos.
Ein anderes Beispiel: Der Freeware-FTP-Client LeechFTP läuft zwar auch ohne Admin-Rechte prima, beim Beenden produziert er jedoch eine Fehlermeldung und läuft weiter – es hilft nur das abschießen per Taskmanager. Filemon bestätigt, dass LeechFTP in seinem eigenen Programmverzeichnis schreiben möchte. Sobald man hier dem Benutzer Vollzugriff einräumt, läuft LeechFTP problemlos.
Die Rechte sollte man stets nur im letzten Element des angezeigten Pfades setzten, in den Beispielen also nur beim Unterschlüssel „Windows Messaging Subsystem“ beziehungsweise „C:\Programme\LeechFTP“. Bei den darüber liegenden Objekten reichen Leserechte, selbst wenn beim Unterobjekt Vollzugriff erforderlich ist. Andernfalls würde man mehr Rechte einräumen als unbedingt nötig und damit letztlich das Sicherheitskonzept mehr oder weniger aushebeln.
Zwar treten in der Standardeinstellung im Registry-Schlüssel „HKEY_CURRENT_USER“ (HKCU) keine Zugriffsverletzungen auf, aber durch nachträgliche Änderungen kann es doch dazu kommen. Dann sollte man folgendes beachten: Der Doppelklick auf einen Listeneintrag in Regmon öffnet den Registry-Editor im Sicherheitskontext des Admins, denn Regmon läuft ja im gleichen Kontext. Das bedeutet aber auch, dass der Registry-Schlüssel „HKEY_CURRENT_USER“ (HKCU) der des Admins ist, und nicht der des Users. So kann der Eindruck entstehen, dass Regmon eine Zugriffsverletzung auf einen Schlüssel anzeigt, der gar nicht existiert – tut er aber doch, nur halt nicht im User-Schlüssel des Admins, sondern in dem des Users. Der ist unter HKEY_USERS eingeblendet. Leider ist er dort schwer zu erkennen, denn er ist nicht durch das Alias, sondern durch die SID gekennzeichnet.
Abhilfe schafft, direkt unter HKEY_CURRENT_USER eine neue Zeichenfolge etwa namens „WerBinIch“ anzulegen und als Wert den Namen des Kontos einzutragen, in dessen Sicherheitskontext Regedit gestartet wurde. Zukünftig lässt sich das Konto auch unter HKEY_USERS leicht finden.
Hatte „User“ bereits Regedit gestartet, wechselt Regmon zu diesem, anstatt ihn ein weiteres Mal und dann mit Admin-Rechten zu starten. Für Filemon gilt das ebenso, und da der Explorer stets läuft, öffnet Filemon lediglich ein weiteres Explorerfenster im Sicherheitskontext von User. Um hier Rechte ändern zu können, muss man einen weiteren Explorer beispielsweise via Startmenü und „Ausführen als …“ starten.
