Inhaltsverzeichnis

Die Benutzerkontensteuerung UAC

Grundsätzliches

Mit Windows Vista wurde die Benutzerkontensteuerung (UAC → User Account Control) eingeführt, was bei den Benutzern zT schon Empörung auslöste. In Vista war das UAC auch wirklich eine Zumutung, in Windows 7 kam dann eine deutlich entschärfte Variante zum Einsatz, was die Akzeptanz von UAC wieder erhöhte. Aber getreu dem Motto "Ist der Lack erst ruiniert, fährt sichs weiter ungeniert" kenne ich in meinem persönlichen Umfeld nur wenige, die es auch in Windows 7 aktiviert lassen. Im Prinzip aber ist es keine schlechte Sache und ein ähnliches Verfahren bei Mac OSX schon lange Usus.

Die Problematik bei Windows, die zur Etablierung von UAC geführt hat, war zum Einen die sinnfreie Default Einstellung, dass der erste Benutzer, der bei der Installation angelegt wurde, immer Mitglied der Gruppe der Administratoren gewesen ist und zum Anderen, dass auch erfahrene Windows Benutzer, meist aus Bequemlichkeit, häufig mit einem administrativen Account gearbeitet haben. Daraus resultierte eines der grössten Sicherheitsprobleme die man unter Windows kannte, weil jedes weitere gestartete Programm die Möglichkeit hatte im selben Sicherheitskontext zu laufen wie der angemeldete Benutzer. Mit anderen Worten: Kommt eine Schadsoftware (Viren etc) auf dem Computer zur Ausführung, hat diese Vollzugriff auf das gesamte System, mit der Konsequenz, dass der Benutzer oft nur noch Passagier auf seinem System war, ohne dies richtig wahrzunehmen.

UAC legt den Finger nun genau in diese Wunde. Ein Benutzer, der Mitglied der Gruppe der Administratoren ist, bekommt zwei Security Token zugewiesen. Eines welches ihn als Standardbenutzer identifiziert und eines welches ihm administrative Rechte im System erteilt. Standardmäßig arbeitet auch ein Administrator mit dem Standardbenutzer Token und somit mit eingeschränkten Rechten im System. Erst wenn eine Anwendung höhere Rechte erforderlich macht, wird das Admin Security Token angefordert, was sich mit dem UAC Warndialog bemerkbar macht, welcher bestätigt werden muss. Administratoren haben nun die Möglichkeit diesen Warndialog zu bestätigen, was der anfordernden Anwendung die nötigen Rechte erteilt. Benutzer, welche nicht Mitglied der erforderlichen Sicherheits Gruppe sind, werden zur Eingabe eines Passworts aufgefordert.



Da jeder Benutzer der auf einem System arbeitet, egal ob Admin oder nicht, erst mal mit dem Standardbenutzer Token arbeitet, wird verhindert, dass der Benutzer systemkritische Dateien wie zB die Registry in bestimmten Teilen (zB HKLM) oder andere Systemdateien bzw. nicht User bezogene Einstellungen in der Systemsteuerung verändern oder löschen kann. Im Prinzip versucht man damit, den Schaden von Schadsoftware wie zB Viren etc eingrenzen zu können. Microsoft wollte seine Benutzer dahingegen ermutigen mit einem Benutzerkonto mit eingeschränkten Rechten zu arbeiten aber der Schuss ging hier und da auch nach hinten los, weil dieses Konzept auch einen Administratoraccount per Default mal soweit einschränkt, dass keine systemkritischen Anwendungen oder Einstellungen ausgeführt oder verändert werden können, ohne das der Benutzer seine Zustimmung dafür gegeben hat. Das hat nun zur Folge, dass auch sicherheitsbewusste Administratoren nun keinen Sinn mehr sehen, ihren Arbeitsalltag mit einem Benutzerkonto mit eingeschränkten Rechten zu verrichten. Die stolpern dann gleich über die nächste Hürde, die der Akzeptanz von UAC zT zum Verhängnis geworden ist.

Ein prominentes Beispiel hierfür ist das Command Line Interface cmd.exe. Wird diese gestartet, läuft diese auch in einem Adminaccount nur mit dem Standardbenutzer Token, was zur Folge hat, dass der Admin in einem Terminal keine administrativen Aufgaben mehr erledigen kann. Ein UAC-Dialog wird auch in diesem Fall nicht erzeugt, der Admin wird zB mit einem simplen "Zugriff verweigert" alleine gelassen. Hier kommt eine Variante ins Spiel, wie der Benutzer selbst höhere Rechte anfordern kann. Das Kontextmenü einer ausführbaren Datei beinhalten die Option "Als Administrator ausführen", über die Funktion ausgeführt wird automatisch der UAC-Dialog aufgerufen und bei erfolgreicher Bestätigung die Anwendung mit höhreren Rechten ausgeführt. Selbes Prozedere wird uU auch bei Anwendungen notwendig sein, welche nicht hinsichtlich UAC Kompatibilität programmiert wurden, wie zB ältere Anwendungen, aus Zeiten vor Windows Vista. Damit solche Programme dauerhaft für die UAC Ausführung gekennzeichnet werden, kann in den Eigenschaften der ausführbaren Datei (eines Drittherstellers) im Register »Kompatibilität« in der Sektion »Berechtigungsstufe« die Checkbox »Programm als Administrator« aktiviert werden.



Werden hingegen UAC konforme Anwendungen oder Installationspakete gestartet, die höhere Rechte erfordern, wird dies durch ein kleines buntes Schild im Icon kenntlich gemacht. Solche Anwendungen rufen automatisch den UAC-Dialog bei der Ausführung auf. (Sollte UAC deaktiviert sein, wird dieses Schild nicht mehr eingeblendet). Softwareentwickler haben die Möglichkeit eine Manifestdatei in ihrer Anwendung einzubinden in welchen uA auch der Security Level (requestedExecutionLevel) der Anwendung festgelegt werden kann. Wird das Level-Attribut von requestedExecutionLevel auf "asInvoker" gesetzt, so läuft die Applikation mit dem Token, welcher die Applikation gestartet hat (normalerweise also mit eingeschränkten Rechten). Setzt man das Attribut auf "highestAvailable", so fordert das einen UAC-Bestätigungsdialog bei Administratoren an und läuft bei Standardbenutzern mit eingeschränkten Rechten. "requireAdministrator" dagegen fordert in jedem Fall die erweiterten Rechte ein.1). Des Weiteren wertet der Installer den Namen der ausfühbaren Datei aus; befinden sich im Namen Stichwörter wie zB Setup, Install oder Update, wird vom Installer automatisch der UAC-Dialog aufgerufen. Somit können auf einfache Weise auch Anwendungen gekennzeichnet werden, um bei ihrer Ausführungen automatisch höhere Rechte anzufordern.

Windows 7 und das entschärfte UAC

Da in Windows Vista die Akzeptanz von UAC stark durch eine recht strikte Sicherheitspolitik gelitten hat und sich die Beschwerden darüber in der öffentlichen Internetgemeinde derart überschlugen, was zur Folge hatte, dass vermutlich der am häufigsten zitierte Workaround eine Anleitung zum Abschalten von UAC gewesen ist, hat auch Microsoft eingesehen, dass sie ihre schweineteuere Entwicklung langfristig wohl in die Tonne treten können, wenn sie nicht selbst für adäquate Abhilfe sorgen. Daraus resultierte die Möglichkeit, den Level ab wann UAC einschreiten soll einzustellen. Zu finden ist diese Einstellung in der »Systemsteuerung → Benutzerkonten (und Jugendschutz) → Benutzerkonten → Einstellungen der Benutzerkontensteuerung ändern«.

UAC lässt sich nun über einen Schieberegler in vier Stufen konfigurieren:

Dieser Dialog kann auch im Konfigurationstool »msconfig« (Start → Eingabefeld: msconfig.exe → Tools → UAC-Einstellungen ändern → Starten) oder direkt mit der Eingabe von »%windir%\system32\UserAccountControlSettings.exe« im Eingabefeld im Startmenü aufgerufen werden.

Dieser Slider greift auf die Schlüssel »ConsentPromptBehaviorAdmin«, »EnableLUA« und »PromptOnSecureDesktop« in der Registry unter »HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System« zu.

Die zugehörigen Werte der einzelnen Schlüssel stellen sich wie folgt dar:

UAC Steuerung über Richtlinien

UAC kann ebenfalls über eine Gruppenrichtlinie eingestellt werden. Öffnen Sie hierfür den Richtlinieneditor »gpedit.msc« und navigieren Sie nach »Computerkonfiguration → Windows-Einstellungen → Sicherheitseinstellungen → Lokale Richtlinien → Sicherheitsoptionen«

Hier finden Sie folgende Einträge:

Weitere Erklärungen zu den einzelnen GPOs finden Sie in der Hilfe zu den Optionen im Gruppenrichtlinieneditor.

— pronto 2010/06/30 20:17

1) http://de.wikipedia.org/wiki/User_Account_Control