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.¹⁾. 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.

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:

• Stufe 4 → Immer Benachrichtigen. (Entspricht der Standardstufe von Windows Vista)
• Stufe 3 → Nur benachrichtigen, wenn Änderungen an meinem Computer vom Programmen vorgenommen werden (Standardeinstellung).
• Stufe 2 → Nur benachrichtigen, wenn Änderungen an meinem Computer vom Programm vorgenommen werden (Desktop nicht abblenden).
• Stufe 1 → Nie benachrichtigen (UAC ist abgeschaltet).

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:

• Stufe 1 → ConsentPromptBehaviorAdmin 0 ; PromptOnSecureDesktop 0 ; EnableLUA 0
  
• Stufe 2 → ConsentPromptBehaviorAdmin 5 ; PromptOnSecureDesktop 0 ; EnableLUA 1
  
• Stufe 3 → ConsentPromptBehaviorAdmin 5 ; PromptOnSecureDesktop 1 ; EnableLUA 1
  
• Stufe 4 → ConsentPromptBehaviorAdmin 2 ; PromptOnSecureDesktop 1 ; EnableLUA 1
  

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:

• Benutzerkontensteuerung: Administratorbestätigungsmodus für das integrierte Administratorkonto:
  Während der Installation von Windows 7 wird ein Administratorkonto angelegt, welches im Anschluss nicht verfügbar ist. Dieses Konto kann jedoch aktiviert werden und hat die Besonderheit, dass selbst bei aktiven UAC kein UAC-Dialog augferufen wird. Damit auch dieses Benutzerkonto den UAC Richtlinien entspericht, kann diese Option aktiviert werden.
  Optionen: aktiviert / deaktiviert (Standard)
  Registryschlüssel: »FilterAdministratorToken«
  Wert 0 = deaktiviert (Standard)
  Wert 1 = aktiviert

• Benutzerkontensteuerung: Alle Administratoren im Administratorbestätigungsmodus ausführen:
  Aktiviert oder Deaktiviert UAC
  Optionen: aktiviert (Standard) / deaktiviert
  Registryschlüssel: »EnableLUA«
  Wert 0 = UAC deaktiviert
  Wert 1 = UAC aktiviert (Standard)

• Benutzerkontensteuerung: Anwendungsinstallationen erkennen und erhöhte Rechte anfordern:
  Windows versucht selbständig zu erkennen, ob eine Softwareinstallation "administrative" Rechte benötigt. Ist das der Fall, wird nach Bestätigung der Nachfrage das Setup mit den entsprechenden Rechten ausgestattet. Mit dieser Option können Sie diese automatische Erkennung ausschalten. Bei Anwendern mit administrativen Rechten wird die Installation dann immer mit solchen administrativen Rechten gestartet.
  Optionen: aktiviert (Standard) / deaktiviert
  Registryschlüssel: »EnableInstallerDetection«
  Wert 0 = Automatische Erkennung ausschalten
  Wert 1 = Automatische Erkennung aktiv (Standard)

• Benutzerkontensteuerung: Bei Benutzeraufforderung nach erhöhten Rechten zum sicheren Desktop wechseln:
  Öffnet sich UAC, wird automatisch der Bildschirm abgedunkelt. Das passiert, weil Windows beim Aufruf der UAC auf den »sicheren Desktop« umschaltet und die Benutzeroberfläche ausblendet.
  Optionen: aktiviert (Standard) / deaktiviert
  Registryschlüssel: »PromptOnSecureDesktop«
  Wert 0 = Keinen "sicheren Desktop" verwenden
  Wert 1 = "sicheren Desktop" verwenden (Standard)

• Benutzerkontensteuerung: Datei- und Registrierungsschreibfehler an Einzelbenutzerstandorte virtualisieren:
  Mit dieser Richtlinieneinstellung wird gesteuert, ob Schreibfehler in Anwendungen in definierte Orte in der Registrierung und im Dateisystem umgeleitet werden. Mit der Richtlinieneinstellung werden Anwendungen aufgefangen, die unter dem Administratorkonto ausgeführt werden, und von denen Laufzeitanwendungsdaten in "%Programme%, %Windir%, %Windir%\system32" oder "HKLM\Software\…" geschrieben werden.
  Optionen: aktiviert (Standard) / deaktiviert
  Registryschlüssel: »EnableVirtualization«
  Wert 0 = Für Anwendungen, die Daten in geschützte Speicherorte schreiben, wird wie in vorherigen Windows-Versionen auch ein Fehler zurückgegeben.
  Wert 1 = Zugriffe auf geschützte Speicherbereiche werden umgeleitet. (Standard)

• Benutzerkontensteuerung: Erhöhte Rechte nur für UIAccess-Anwendungen, die an sicheren Orten installiert sind:
  Mit dieser Sicherheitseinstellung wird gesteuert, ob sich Anwendungen, die gemäß Anforderung mit einer Integritätsebene für Eingabehilfen für die Benutzeroberfläche (UIAccess) ausgeführt werden sollen, an einem sicheren Ort im Dateisystem befinden müssen. Sichere Orte sind auf die folgenden Verzeichnisse begrenzt:
  - …\Programme\, einschließlich Unterverzeichnissen
  - …\Windows\system32
  - …\Programme (x86)\, einschließlich Unterverzeichnissen für 64-Bit-Versionen von Windows
  Optionen: aktiviert (Standard)/ deaktiviert
  Registryschlüssel: »EnableSecureUIAPaths«
  Wert 0 = Deaktiviert: Eine Anwendung wird auch dann mit UIAccess-Integrität gestartet, wenn sie sich nicht an einem sicheren Ort im Dateisystem befindet.
  Wert 1 = Aktiviert (Standardeinstellung): Befindet sich eine Anwendung an einem sicheren Ort im Dateisystem, wird sie nur mit UIAccess-Integrität ausgeführt.

• Benutzerkontensteuerung: Nur ausführbare Dateien heraufstufen, die signiert und validiert sind:
  Mit dieser Richtlinieneinstellung werden Public Key Infrastructure (PKI)-Signaturüberprüfungen für alle interaktiven Anwendungen erzwungen, die Rechteerweiterungen erfordern. Administratoren in Unternehmen können die steuern, welche Anwendungen durch Hinzufügen von Zertifikaten im Speicher für vertrauenswürdige Herausgeber auf lokalen Computern ausgeführt werden dürfen.
  Optionen: aktiviert / deaktiviert (Standard)
  Registryschlüssel: »ValidateAdminCodeSignatures«
  Wert 0 = Deaktiviert (Standardeinstellung): Erzwingt nicht die Überprüfung des PKI-Zertifizierungspfads, bevor eine angegebene ausführbare Datei ausgeführt werden darf
  Wert 1 = Aktiviert: Erzwingt die Überprüfung des PKI-Zertifizierungspfads für eine angegebene ausführbare Datei, bevor sie ausgeführt werden darf.

• Benutzerkontensteuerung: Verhalten der Eingabeaufforderung für erhöhte Rechte für Standardbenutzer:
  Diese Sicherheitseinstellung steuert das Verhalten der Eingabeaufforderung für erhöhte Rechte für Standardbenutzer.
  Optionen: 0; 1; 3
  Registryschlüssel: »ConsentPromptBehaviorUser«
  Wert 0 = Anforderungen für erhöhte Rechte automatisch ablehnen.
  Wert 1 = Eingabeaufforderung zu Anmeldeinformationen auf dem sicheren Desktop (Standardeinstellung)
  Wert 3 = Eingabeaufforderung zu Anmeldeinformationen.

• Benutzerkontensteuerung: Verhalten der Eingabeaufforderung mit erhöhten Rechten für Administratoren im Administratorbestätigungsmodus:
  Diese Richtlinieneinstellung steuert das Verhalten der Eingabeaufforderung für erhöhte Rechte für Administratoren.
  Optionen: 0; 1; 2; 3; 4; 5
  Registryschlüssel: »ConsentPromptBehaviorAdmin«
  Wert 0 = Erhöhte Rechte ohne Eingabeaufforderung
  Wert 1 = Eingabeaufforderung zu Anmeldeinformationen auf dem sicheren Desktop.
  Wert 2 = Eingabeaufforderung zur Zustimmung auf dem sicheren Desktop.
  Wert 3 = Eingabeaufforderung zu Anmeldeinformationen.
  Wert 4 = Eingabeaufforderung zur Zustimmung.
  Wert 5 = Eingabeaufforderung zur Zustimmung für Nicht-Windows-Binärdateien (Standardeinstellung).

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

— pronto 2010/06/30 20:17