Windows Vista Anwendungsentwicklungsanforderungen für die Kompatibilität der Benutzerkontensteuerung

 

Jennifer Allen

Aktualisiert im Juni 2007

Zusammenfassung: Dieses Whitepaper soll Anwendungsentwicklern beim Entwerfen von Windows Vista-fähigen Anwendungen helfen, die mit der Benutzerkontensteuerung kompatibel sind. Detaillierte Schritte zum Entwurfsprozess sind zusammen mit Codebeispielen, Anforderungen und bewährten Methoden enthalten. In diesem Dokument werden auch die technischen Updates und Änderungen an der Benutzeroberfläche in Windows Vista beschrieben. (71 gedruckte Seiten.)

Inhalte

Gründe für die Benutzerkontensteuerung
Windows Vista Updates
Neue Technologien für Windows Vista
UAC-Architektur
Wirkt sich UAC auf Ihre Anwendung aus?
Entwerfen von Anwendungen für Windows Vista
Bereitstellen und Patchen von Anwendungen für Standardbenutzer
Problembehandlung bei gängigen Problemen
Referenzen

Gründe für die Benutzerkontensteuerung

Anwendungsentwickler haben durchgängig Windows-Anwendungen erstellt, die übermäßige Benutzerrechte und Windows-Berechtigungen erfordern, was häufig erfordert, dass der ausführende Benutzer ein Administrator ist. Daher werden nur wenige Windows-Benutzer mit den geringsten Erforderlichen Benutzerrechten und Windows-Berechtigungen ausgeführt. Viele Unternehmen, die eine Balance zwischen einfacher Bereitstellung und Benutzerfreundlichkeit und Sicherheit suchen, haben ihre Desktops aufgrund von Kompatibilitätsproblemen mit Standardbenutzeranwendungen häufig als Administrator bereitgestellt.

Die folgende Liste enthält zusätzliche Gründe, warum es schwierig ist, als Standardbenutzer auf Computern vor Microsoft Windows Vista auszuführen:

1. Viele Windows-Anwendungen erfordern, dass der angemeldete Benutzer ein Administrator ist, aber keinen Zugriff auf Administratorebene erfordert. Diese Anwendungen führen eine Vielzahl von Administratorzugriffsprüfungen durch, bevor sie ausgeführt werden, einschließlich:
   • Überprüfung des Administratorzugriffstokens.
   • Zugriffsanforderungen für "All Access" an systemgeschützten Speicherorten.
   • Schreiben von Daten an geschützte Speicherorte, z. B. %ProgramFiles%, %WinDir% und HKLM\Software.
2. Viele Windows-Anwendungen sind nicht mit dem Konzept der geringsten Rechte konzipiert und trennen Benutzer- und Administratorfunktionen nicht in zwei separate Prozesse.
3. Windows 2000 und Windows XP erstellen jedes neue Benutzerkonto standardmäßig als Administrator; Daher funktionieren wichtige Windows-Komponenten wie Datum und Uhrzeit und die Energieverwaltungs-Systemsteuerungen für einen Standardbenutzer nicht gut.
4. Windows 2000- und Windows XP-Administratoren müssen zwei separate Benutzerkonten erstellen– eines für administrative Aufgaben und ein Standardbenutzerkonto, um tägliche Aufgaben auszuführen. Daher müssen Sich Benutzer von ihren Standardbenutzerkonten abmelden und sich wieder als Administrator anmelden oder Ausführen als verwenden, um administrative Aufgaben auszuführen.

Mit der Benutzerkontensteuerung (User Account Control, UAC) stellt Microsoft eine Technologie bereit, die die Bereitstellung von Standard-Benutzerdesktops im Unternehmen und zu Hause vereinfacht.

Aufbauend auf der Windows-Sicherheitsarchitektur, wie sie ursprünglich im Microsoft Windows NT 3.1-Betriebssystem entworfen wurde, versuchte das UAC-Team, ein Standardbenutzermodell zu implementieren, das sowohl flexibel als auch sicherer war. In früheren Versionen von Windows wird während des Anmeldeprozesses ein Zugriffstoken für einen Administrator erstellt. Das Zugriffstoken des Administrators umfasst die meisten Windows-Berechtigungen und die meisten administrativen Sicherheits-IDs (SIDs). Dieses Zugriffstoken stellt sicher, dass ein Administrator Anwendungen installieren, das Betriebssystem konfigurieren und auf jede Ressource zugreifen kann.

Das UAC-Team hat beim Erstellen von Zugriffstoken in Windows Vista einen drastisch anderen Ansatz verfolgt. Wenn sich ein Administratorbenutzer bei einem Windows Vista-Computer anmeldet, werden zwei Zugriffstoken erstellt: ein gefiltertes Standardbenutzerzugriffstoken und ein vollständiges Administratorzugriffstoken. Anstatt den Desktop (Explorer.exe) mit dem Zugriffstoken des Administrators zu starten, wird das Standardbenutzerzugriffstoken verwendet. Alle untergeordneten Prozesse erben von diesem ersten Start des Desktops (der explorer.exe Prozess), wodurch die Angriffsfläche von Windows Vista begrenzt wird. Standardmäßig melden sich alle Benutzer, einschließlich Administratoren, bei einem Windows Vista-Computer als Standardbenutzer an.

Hinweis Es gibt eine Ausnahme von der vorherigen Anweisung: Gäste melden sich am Computer mit weniger Benutzerrechten und Berechtigungen als Standardbenutzer an.

Wenn ein Administrator versucht, eine Administrative Aufgabe auszuführen, z. B. das Installieren einer Anwendung, fordert die Benutzer-UAC den Benutzer auf, die Aktion zu genehmigen. Wenn der Benutzer die Aktion genehmigt, wird die Aufgabe mit dem vollständigen Administratorzugriffstoken des Administrators gestartet. Dies ist das Standardverhalten der Administratoreingabeaufforderung, das im lokalen Security Policy Manager-Snap-In (secpol.msc) und mit Gruppenrichtlinie (gpedit.msc) konfiguriert werden kann.

Hinweis Ein Administratorkonto auf einem Windows Vista-Computer mit aktivierter UAC wird auch als Administratorkonto im Admin Genehmigungsmodus bezeichnet. Admin Genehmigungsmodus gibt die Standardbenutzerfreundlichkeit für Administratoren an.

Jede Administratorerweiterung ist auch prozessspezifisch, was verhindert, dass andere Prozesse das Zugriffstoken verwenden, ohne den Benutzer zur Genehmigung aufzufordern. Daher haben Administratorbenutzer eine präzisere Kontrolle darüber, welche Anwendungen installiert werden, während sie sich stark auf Schadsoftware auswirken, die erwartet, dass der angemeldete Benutzer mit einem vollständigen Administratorzugriffstoken ausgeführt wird.

Standardbenutzer haben auch die Möglichkeit, die Datenflusserweiterung zu erhöhen und verwaltungstechnische Aufgaben mithilfe der UAC-Infrastruktur auszuführen. Wenn ein Standardbenutzer versucht, eine Administrative Aufgabe auszuführen, fordert die Benutzerkontensteuerung den Benutzer auf, gültige Anmeldeinformationen für ein Administratorkonto einzugeben. Dies ist das Standardverhalten von Benutzereingabeaufforderungen, das im lokalen Sicherheitsrichtlinien-Manager-Snap-In (secpol.msc) und mit Gruppenrichtlinie (gpedit.msc) konfiguriert werden kann.

Windows Vista Updates

Die folgenden Updates spiegeln die kumulativen Kernänderungen in der Funktionalität wider, die in Windows Vista aufgetreten sind.

UAC ist standardmäßig aktiviert.

Daher treten möglicherweise Kompatibilitätsprobleme mit verschiedenen Anwendungen auf, die noch nicht für die Windows Vista-UAC-Komponente aktualisiert wurden. Wenn eine Anwendung ein Administratorzugriffstoken erfordert (dies ist ein Hinweis auf den Fehler "Zugriff verweigert", der beim Ausführen der Anwendung zurückgegeben wird), können Sie das Programm als Administrator ausführen, indem Sie die Option Als Administrator ausführen im Kontextmenü (Rechtsklick) verwenden. Dies ist weiter unten in diesem Dokument im Abschnitt Ausführen von Programmen als Administrator dokumentiert.

Alle nachfolgenden Benutzerkonten werden als Standardbenutzer erstellt.

Sowohl Standardbenutzerkonten als auch Administratorbenutzerkonten können die erweiterte Sicherheit der UAC nutzen. Bei Neuinstallationen ist das erste erstellte Benutzerkonto standardmäßig ein lokales Administratorkonto in Admin Genehmigungsmodus (UAC aktiviert). Alle nachfolgenden Konten werden dann als Standardbenutzer erstellt.

Eingabeaufforderungen zur Erhöhung werden standardmäßig auf dem sicheren Desktop angezeigt.

Die Zustimmungs- und Anmeldeinformationen werden standardmäßig in Windows Vista auf dem sicheren Desktop angezeigt.

Eingabeaufforderungen für Hintergrundanwendungen werden auf der Taskleiste minimiert.

Hintergrundanwendungen fordern den Benutzer automatisch zur Erhöhung auf der Taskleiste auf, anstatt automatisch zum sicheren Desktop zu wechseln, um die Rechte zu erhöhen. Die Eingabeaufforderung zur Erhöhung wird auf der Taskleiste minimiert angezeigt und blinkt, um den Benutzer zu benachrichtigen, dass eine Anwendung Rechteerweiterung angefordert hat. Ein Beispiel für eine Rechteerweiterung im Hintergrund tritt auf, wenn ein Benutzer zu einer Website navibiert und mit dem Herunterladen einer Installationsdatei beginnt. Der Benutzer überprüft dann die E-Mail, während die Installation im Hintergrund heruntergeladen wird. Sobald der Download im Hintergrund abgeschlossen ist und die Installation beginnt, wird die Rechteerweiterung als Hintergrundaufgabe und nicht als Vordergrundaufgabe erkannt. Diese Erkennung verhindert, dass die Installation plötzlich den Fokus des Bildschirms des Benutzers stiehlt, während der Benutzer eine andere Aufgabe ausführt – das Lesen von E-Mails. Dieses Verhalten sorgt für eine bessere Benutzerfreundlichkeit für die Eingabeaufforderung zur Erhöhung. Informationen dazu, wie Anwendungsentwickler sicherstellen können, dass ihre Anwendungen beim Anfordern von Rechteerweiterungen nicht auf die Taskleiste minimiert werden, finden Sie weiter unten in diesem Dokument.

Rechteerweiterungen werden im Anmeldepfad des Benutzers blockiert.

Anwendungen, die gestartet werden, wenn sich der Benutzer anmeldet und Rechteerweiterungen erfordern, werden jetzt im Anmeldepfad blockiert. Ohne zu verhindern, dass Anwendungen zur Erhöhung des Anmeldepfads des Benutzers aufgefordert werden, müssten sowohl Standardbenutzer als auch Administratoren bei jeder Anmeldung auf ein Dialogfeld "Benutzerkontensteuerung" reagieren. Windows Vista benachrichtigt den Benutzer, wenn eine Anwendung blockiert wurde, indem ein Symbol in der Taskleiste platziert wird. Der Benutzer kann dann mit der rechten Maustaste auf dieses Symbol klicken, um Anwendungen auszuführen, deren Aufforderung zur Erhöhung während der Anmeldung des Benutzers blockiert wurde. Der Benutzer kann verwalten, welche Startanwendungen deaktiviert oder aus dieser Liste entfernt werden, indem er auf das Taskleistensymbol doppelklicken.

Das integrierte Administratorkonto ist bei neuen Installationen standardmäßig deaktiviert.

Das integrierte Administratorkonto ist in Windows Vista standardmäßig deaktiviert. Wenn Windows Vista während eines Upgrades von Windows XP feststellt, dass der integrierte Administrator das einzige aktive lokale Administratorkonto ist, lässt Windows Vista das Konto aktiviert und versetzt das Konto in Admin Genehmigungsmodus. Das integrierte Administratorkonto kann sich standardmäßig nicht im abgesicherten Modus beim Computer anmelden. Weitere Informationen finden Sie in den folgenden Abschnitten. Das integrierte Administratorkonto wird während des Setups mit dem Benutzernamen Administrator erstellt.

Nicht in die Domäne eingebunden

Wenn mindestens ein lokales Administratorkonto aktiviert ist, lässt der abgesicherte Modus die Anmeldung mit dem deaktivierten integrierten Administratorkonto nicht zu. Stattdessen kann jedes lokale Administratorkonto für die Anmeldung verwendet werden. Wenn das letzte lokale Administratorkonto versehentlich herabgestuft, deaktiviert oder gelöscht wird, ermöglicht der abgesicherte Modus dem deaktivierten integrierten Administratorkonto die Anmeldung für die Notfallwiederherstellung.

In die Domäne eingebunden

Das deaktivierte integrierte Administratorkonto kann sich in allen Fällen nicht im abgesicherten Modus anmelden. Ein Benutzerkonto, das Mitglied der Gruppe "Domänenadministratoren" ist, kann sich am Computer anmelden, um einen lokalen Administrator zu erstellen, sofern keine vorhanden ist.

Hinweis Wenn das Domänenadministratorkonto noch nie angemeldet war, muss der Computer im abgesicherten Modus mit Netzwerk gestartet werden, da die Anmeldeinformationen nicht zwischengespeichert wurden.

Hinweis Sobald der Computer getrennt ist, rückgängig machen er wieder auf das zuvor dargestellte Verhalten zurück, das nicht in die Domäne eingebunden ist.

Benutzerkontensteuerung und Remoteszenarien

Wenn sich ein Administrator über Remotedesktop für instance remote bei einem Windows Vista-Computer anmeldet, ist der Benutzer standardmäßig als Standardbenutzer am Computer angemeldet. Die Remoteverwaltung wurde so geändert, dass sie auf der Leitung restriktiv ist. Dadurch wird verhindert, dass Schadsoftware Anwendungsschleifen ausführt, wenn ein Benutzer mit administratorischem Potenzial ausgeführt wird.

lokale Benutzerkonten

Wenn ein Benutzer mit einem Administratorkonto in der lokalen SAM-Datenbank (Security Accounts Manager) eines Windows Vista-Computers remote eine Verbindung mit einem Windows Vista-Computer herstellt, verfügt der Benutzer über kein Erhöhungspotenzial auf dem Remotecomputer und kann keine Verwaltungsaufgaben ausführen. Wenn der Benutzer die Arbeitsstation mit einem SAM-Konto verwalten möchte, muss er sich interaktiv am zu verwaltenden Computer anmelden.

Domänenbenutzerkonten

Wenn sich ein Benutzer mit einem Domänenbenutzerkonto remote bei einem Windows Vista-Computer anmeldet, auf dem der Benutzer Mitglied der Gruppe Administratoren ist, wird der Domänenbenutzer mit einem vollständigen Administratorzugriffstoken auf dem Remotecomputer ausgeführt, und die UAC ist nicht wirksam.

Neue ACL-Einstellungen (Default Access Control List)

Die ACLs in bestimmten Windows-Verzeichnissen wurden geändert, um die Datenfreigabe und -zusammenarbeit in Datenverzeichnissen und außerhalb der geschützten Verzeichnisse der Benutzer zu ermöglichen. Das geschützte Verzeichnis eines Benutzers ist sein Benutzerprofil (Z.B. C:\Users\Denise\Pictures\), während ein Beispiel für ein Datenverzeichnis außerhalb der Betriebssystempartition auf einem Datenlaufwerk (Z.B. D:\Pictures\) liegt. Da das Stammverzeichnis C in diesem instance durch restriktivere ACLs geschützt ist, konnten Benutzer in frühen Versionen von Windows Vista keine Datenverzeichnisse verwenden.

Diese ACL-Änderungen stellen sicher, dass Benutzer Dateien freigeben und bearbeiten können, ohne eine Genehmigung für ein Dialogfeld "Benutzerkontensteuerung" erteilen zu müssen. Darüber hinaus können Benutzer jetzt einen Ordner privat machen. Diese Änderung stellt sicher, dass Benutzer weiterhin problemlos die Vertraulichkeit und Integrität von Daten auf Datenlaufwerken aufrechterhalten können. Diese privaten Ordner sind weiterhin von anderen Administratoren lesbar, wenn sie erhöhen, und sollten verwendet werden, um Daten vor Standardbenutzern zu schützen.

Im Folgenden sind die Standard-ACL-Einstellungen für %systemroot% und das Datenlaufwerk in Windows XP aufgeführt.

Windows XP %systemroot% und Datenlaufwerk-ACL-Einstellungen

Benutzer oder Gruppe	Access Control Eintrag
BUILTIN\Administrators	Vollzugriff
NT AUTHORITY\SYSTEM	Vollzugriff
CREATOR OWNER	Vollzugriff
BUILTIN\Users	Lesen Sonderzugang: FILE_APPEND_DATA Sonderzugang: FILE_WRITE_DATA
Jeder	Lesen

In der folgenden Tabelle werden die neuen ACL-Einstellungen für Windows Vista-Datenlaufwerke für Datenlaufwerke beschrieben, die mit format.exe erstellt wurden.

Windows Vista-Datenlaufwerk-ACL-Einstellungen

Benutzer oder Gruppe	Access Control Eintrag
BUILTIN\Administrators	Vollzugriff
NT AUTHORITY\SYSTEM	Vollzugriff
NT AUTHORITY\Authenticated Users	Ändern
BUILTIN\Users	Lesen und Ausführen Generisches Lesen, generisches Ausführen

In der folgenden Tabelle werden die neuen Stammeinstellungen des Windows Vista-Betriebssystems (%systemroot%) beschrieben.

Windows Vista %systemroot% ACL-Einstellungen

Benutzer oder Gruppe	Access Control Eintrag
BUILTIN\Administrators	Vollzugriff
NT AUTHORITY\SYSTEM	Vollzugriff
BUILTIN\Users	Lesen und Ausführen
NT AUTHORITY\Authenticated Users	Ändern Anfügen von Daten
Obligatorische Bezeichnung\Hohe Obligatorische Ebene	Kein Schreibvorgang

Neue UAC-Sicherheitseinstellungen und Namensänderungen für Sicherheitseinstellungen

Die neuen Namensupdates für Sicherheitseinstellungen und Sicherheitseinstellungen finden Sie im Abschnitt Verweise dieses Dokuments.

Neue Technologien für Windows Vista

In den folgenden Abschnitten werden die neuen Technologien für Windows Vista erläutert, einschließlich Installationsprogrammerkennung, Standardbenutzerpatches mit Windows Installer 4.0, Isolation von Benutzerberechtigungen und Virtualisierung.

ActiveX-Installationsdienst

Mit dem ActiveX-Installationsdienst können Unternehmen die Installation von ActiveX-Steuerelementen für Standardbenutzer delegieren. Dieser Dienst stellt sicher, dass routinemäßige Geschäftsaufgaben nicht durch fehlerhafte ActiveX-Steuerungsinstallationen und -updates behindert werden. Windows Vista umfasst auch Gruppenrichtlinie Einstellungen, mit denen IT-Experten Host-URLs definieren können, von denen Standardbenutzer ActiveX-Steuerelemente installieren können. Der ActiveX-Installationsdienst besteht aus einem Windows-Dienst, einer Gruppenrichtlinie administrativen Vorlage und einigen Änderungen in Internet Explorer und ist eine optionale Komponente, die nur auf Clients aktiviert wird, auf denen er installiert ist.

Installationsprogrammerkennung

Installationsprogramme sind Anwendungen, die für die Bereitstellung von Software und die meisten Schreibvorgänge in Systemverzeichnisse und Registrierungsschlüssel konzipiert sind. Diese geschützten Systemspeicherorte können in der Regel nur von Administratorbenutzern geschrieben werden. Dies bedeutet, dass Standardbenutzer nicht genügend Zugriff haben, um Programme zu installieren. Windows Vista erkennt Installationsprogramme heuristisch und fordert Administratoranmeldeinformationen oder Genehmigungen vom Administratorbenutzer an, um mit Zugriffsberechtigungen auszuführen. Windows Vista erkennt auch heuristisch Updater- und Deinstallationsprogramme. Beachten Sie, dass ein Entwurfsziel der UAC darin besteht, zu verhindern, dass Installationen ohne Wissen und Zustimmung des Benutzers ausgeführt werden, da sie in geschützte Bereiche des Dateisystems und der Registrierung schreiben.

Wichtig Wenn Sie neue Installationsprogramme entwickeln, ähnlich wie bei der Entwicklung von Programmen für Windows Vista, müssen Sie ein Anwendungsmanifest mit einem entsprechenden requestedExecutionLevel-Element einbetten (siehe Schritt sechs: Erstellen und Einbetten eines Anwendungsmanifests mit Ihrer Anwendung). Wenn der angeforderteExecutionLevel im eingebetteten Anwendungsmanifest vorhanden ist, wird die Installationsprogrammerkennung außer Kraft gesetzt.

Installationsprogrammerkennung gilt nur für:

• Ausführbare 32-Bit-Dateien
• Anwendungen ohne requestedExecutionLevel
• Interaktive Prozesse, die als Standardbenutzer mit aktivierter LUA ausgeführt werden

Bevor ein 32-Bit-Prozess erstellt wird, werden die folgenden Attribute überprüft, um festzustellen, ob es sich um ein Installationsprogramm handelt:

• Dateiname enthält Schlüsselwörter wie "install", "setup", "update" usw.
• Schlüsselwörter in den folgenden Feldern der Versionsverwaltungsressource: Anbieter, Firmenname, Produktname, Dateibeschreibung, Ursprünglicher Dateiname, interner Name und Exportname.
• Schlüsselwörter im parallelen Manifest, das in die ausführbare Datei eingebettet ist.
• Schlüsselwörter in bestimmten StringTable-Einträgen, die in der ausführbaren Datei verknüpft sind.
• Schlüsselattribute in den RC-Daten, die in der ausführbaren Datei verknüpft sind.
• Zielsequenzen von Bytes in der ausführbaren Datei.

Hinweis Die Schlüsselwörter und Sequenzen von Bytes wurden von allgemeinen Merkmalen abgeleitet, die von verschiedenen Installationstechnologien beobachtet wurden.

Stellen Sie sicher, dass Sie das gesamte Dokument gründlich überprüfen, einschließlich des Abschnitts Sechs: Erstellen und Einbetten eines Anwendungsmanifests mit Ihrer Anwendung.

Hinweis Die Benutzerkontensteuerung: Erkennen von Anwendungsinstallationen und aufforderung zur Erhöhungseinstellung müssen aktiviert sein, damit installationsprogramme erkannt werden können. Diese Einstellung ist standardmäßig aktiviert und kann mit dem Security Policy Manager-Snap-In (secpol.msc) oder mit Gruppenrichtlinie (gpedit.msc) konfiguriert werden.

Allgemeine Informationen und eine Übersicht über den Microsoft Windows Installer finden Sie in der MSDN Library.

Patchen von Anwendungen in einer UAC-Umgebung

Microsoft Windows Installer 4.0 wurde unter Berücksichtigung der UAC entwickelt, um Anwendungsinstallationen und Patches zu vereinfachen. Mit der Einführung von Windows Installer 4.0 können Patches auf Anwendungen angewendet werden, ohne eine neuere Version der Anwendung neu zu installieren. Diese Methode ist ideal, wenn eine Anwendung in einer Computerinstallation bereitgestellt wird und Patches von einem Benutzer bereitgestellt werden müssen, ohne dass ein Administratorzugriffstoken erforderlich ist. Informationen zum Erstellen und Anwenden von Patches auf Anwendungen finden Sie unter Patchen Per-User verwaltete Anwendungen.

Security Center-Integration

Wenn die UAC auf einem Windows Vista-Computer deaktiviert ist, erstellt Security Center eine Warnung und fordert den Benutzer auf, die UAC erneut zu aktivieren. Security Center zeigt diese Warnung an, sobald der Computer neu gestartet wurde, nachdem sich die UAC-Einstellung geändert hat.

Benutzeroberflächenberechtigungsisolation

Benutzeroberflächenberechtigungsisolation (User Interface Privilege Isolation, UIPI) ist einer der Mechanismen, mit denen Anwendungen, die als vollständiger Administrator ausgeführt werden, von Prozessen isoliert werden, die als ein Konto niedriger als ein Administrator auf demselben interaktiven Desktop ausgeführt werden. UIPI ist spezifisch für das Als USER bezeichnete Fenster- und Grafiksubsystem, das Windows- und Benutzeroberflächensteuerelemente unterstützt. UIPI verhindert, dass eine Anwendung mit niedrigeren Berechtigungen Windows-Nachrichten verwendet, um Eingaben von einem Prozess an einen Prozess mit höheren Berechtigungen zu senden. Durch das Senden von Eingaben von einem Prozess an einen anderen kann ein Prozess Eingaben in einen anderen Prozess einfügen, ohne dass der Benutzer Tastatur- oder Mausaktionen bereitstellt.

Das Konzept hinter UIPI ist einfach. Windows Vista definiert eine Reihe von Benutzeroberflächenberechtigungen auf hierarchische Weise. Die Art der Ebenen ist so, dass höhere Berechtigungsstufen Fensternachrichten an Anwendungen senden können, die auf niedrigeren Ebenen ausgeführt werden. Auf niedrigeren Ebenen können jedoch keine Fenstermeldungen an Anwendungsfenster auf höheren Ebenen gesendet werden.

Die Berechtigungsstufe der Benutzeroberfläche befindet sich auf Prozessebene. Wenn ein Prozess initialisiert wird, ruft das Benutzersubsystem das Sicherheitssubsystem auf, um die im Sicherheitszugriffstoken des Prozesses zugewiesene Desktopintegritätsstufe zu bestimmen. Die Desktopintegritätsebene wird vom Sicherheitssubsystem festgelegt, wenn der Prozess erstellt wird, und ändert sich nicht. Daher wird die Berechtigungsstufe der Benutzeroberfläche auch vom Benutzersubsystem festgelegt, wenn der Prozess erstellt wird, und ändert sich nicht.

Alle Anwendungen, die von einem Standardbenutzer ausgeführt werden, verfügen über die gleiche Berechtigungsstufe der Benutzeroberfläche. Als Standardbenutzer werden Anwendungen auf einer einzelnen Berechtigungsstufe ausgeführt. UIPI beeinträchtigt oder ändert das Verhalten des Fenstermessagings zwischen Anwendungen auf derselben Berechtigungsstufe nicht. UIPI tritt für einen Benutzer in Kraft, der Mitglied der Administratorgruppe ist und Anwendungen möglicherweise als Standardbenutzer ausführt (manchmal auch als Prozess mit einem gefilterten Zugriffstoken bezeichnet), und verarbeitet auch die Ausführung mit einem vollständigen Administratorzugriffstoken auf demselben Desktop. UIPI verhindert, dass Prozesse mit niedrigeren Berechtigungen auf Prozesse mit höheren Berechtigungen zugreifen, indem das folgende Verhalten blockiert wird.

Ein Prozess mit niedrigeren Berechtigungen kann nicht:

• Führen Sie eine Fensterhandlevalidierung höherer Prozessberechtigungen aus.
• SendMessage oder PostMessage an Anwendungsfenster mit höheren Berechtigungen. Diese APIs (Application Programming Interfaces) geben einen Erfolg zurück, löschen die Fenstermeldung jedoch im Hintergrund.
• Verwenden Sie Threadhooks, um an einen Prozess mit höheren Berechtigungen anzufügen.
• Verwenden Sie Journalhooks, um einen Prozess mit höheren Berechtigungen zu überwachen.
• Führen Sie die Einschleusung dynamischer Linkbibliotheken (DLL) in einen Prozess mit höheren Berechtigungen aus.

Wenn UIPI aktiviert ist, werden die folgenden freigegebenen USER-Ressourcen weiterhin von Prozessen mit unterschiedlichen Berechtigungsstufen gemeinsam genutzt:

• Desktopfenster, das tatsächlich die Bildschirmoberfläche besitzt
• Schreibgeschützter freigegebener Arbeitsspeicher für den Desktopheap
• Globale Atomtabelle
• Zwischenablage

Das Zeichnen auf dem Bildschirm ist eine weitere Aktion, die nicht von UIPI blockiert wird. Das Zeichnen auf dem Bildschirm bezieht sich auf den Prozess der Verwendung der Paint-Methode zum Anzeigen von Inhalten auf einer externen Ausgabe, z. B. auf einem Monitor. Das GDI-Modell (USER/Graphics Device Interface) lässt keine Kontrolle über Lackierflächen zu. Daher ist es möglich, dass eine Anwendung mit niedrigeren Berechtigungen den Oberflächenbereich eines Anwendungsfensters mit höheren Berechtigungen übermalt.

Hinweis Da die Windows-Shell (Explorer) als Standardbenutzerprozess ausgeführt wird, kann jeder andere Prozess, der als Standardbenutzer ausgeführt wird, weiterhin Tastaturanschläge senden. Dies ist der Hauptgrund, warum ein Administratorkonto in Admin Genehmigungsmodus zur Zustimmung zur Erhöhung aufgefordert wird, wenn es eine Administratoraktion initiiert, z. B. durch Doppelklicken auf eine Setup.exe oder Klicken auf ein Symbol für ein Rechteschild.

Virtualisierung

Wichtig Virtualisierung wird implementiert, um Anwendungskompatibilitätsprobleme für Anwendungen zu verbessern, die als Standardbenutzer unter Windows Vista ausgeführt werden. Entwickler dürfen sich nicht darauf verlassen, dass die Virtualisierung in nachfolgenden Versionen von Windows vorhanden ist.

Vor Windows Vista wurden viele Anwendungen in der Regel von Administratoren ausgeführt. Daher konnten Anwendungen Systemdateien und Registrierungsschlüssel frei lesen und schreiben. Wenn diese Anwendungen von einem Standardbenutzer ausgeführt würden, würden sie aufgrund unzureichenden Zugriffs fehlschlagen. Windows Vista verbessert die Anwendungskompatibilität für diese Benutzer, indem Schreibvorgänge (und nachfolgende Datei- oder Registrierungsvorgänge) an einen Benutzerspeicherort innerhalb des Benutzerprofils umgeleitet werden. Wenn beispielsweise eine Anwendung versucht, in C:\Program Files\Contoso\Settings.ini zu schreiben, und der Benutzer nicht berechtigt ist, in dieses Verzeichnis zu schreiben, wird der Schreibvorgang an C:\Benutzer\<Benutzername>\AppData\Local\VirtualStore\Program Files\contoso\settings.ini umgeleitet. Wenn eine Anwendung für die Registrierung versucht, in HKEY_LOCAL_MACHINE\Software\Contoso\ zu schreiben, wird sie automatisch an HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso oder HKEY_USERS\< Benutzer-SID >_Classes\VirtualStore\Machine\Software\Contoso umgeleitet.

In der folgenden Abbildung wird der Virtualisierungsprozess in Windows Vista beschrieben. In diesem Beispiel ist Denise administrator im Admin Genehmigungsmodus und Brian ein Standardbenutzer. Die Virtualisierung besteht aus zwei Komponenten: Dateivirtualisierung und Registrierungsvirtualisierung.

Abbildung 1. Virtualisierungsprozess

Wichtig Um die Komplexität virtualisierter Dateien und Registrierungsschlüssel zu verringern, müssen Sie beim Entwickeln von Windows Vista-Programmen unbedingt ein Anwendungsmanifest mit einem entsprechenden requestedExecutionLevel einbetten, um die Datei- und Registrierungsvirtualisierung zu deaktivieren.

Virtualisierung ist nur für Folgendes aktiviert:

• Interaktive 32-Bit-Prozesse
• Vom Administrator beschreibbare Datei/Ordner und Registrierungsschlüssel

Die Virtualisierung ist deaktiviert für:

• 64-Bit-Prozesse
• Nicht interaktive Prozesse
• Prozesse, die die Identität annehmen
• Aufrufer im Kernelmodus
• Ausführbare Dateien mit einem requestedExecutionLevel

Virtualisierung und Roaming:

• Virtualisierungsdateien/Ordner und Registrierungsschlüssel werden nicht roamingfähig (siehe Roamingprofile).
• Zugeordnet mit globalen Objekten, die kein Roaming durchführen

Dateivirtualisierung

Bei der Dateivirtualisierung wird die Situation behoben, in der eine Anwendung auf die Möglichkeit angewiesen ist, eine Datei, z. B. eine Konfigurationsdatei, an einem Systemspeicherort zu speichern, der normalerweise nur von Administratoren geschrieben werden kann. Das Ausführen von Programmen als Standardbenutzer in dieser Situation kann aufgrund unzureichender Zugriffsebenen zu Programmfehlern führen.

Wenn eine Anwendung in einen Systemspeicherort schreibt, der nur von Administratoren beschreibbar ist, schreibt Windows alle nachfolgenden Dateivorgänge in einen benutzerspezifischen Pfad unter dem Verzeichnis Virtual Store, das sich unter %LOCALAPPDATA%\VirtualStore befindet. Später, wenn die Anwendung diese Datei zurückliest, stellt das System die Datei im virtuellen Speicher bereit. Da die Windows-Sicherheitsinfrastruktur die Virtualisierung ohne die Unterstützung der Anwendung verarbeitet, ist die Anwendung der Ansicht, dass sie erfolgreich in der Lage war, Programmdateien direkt zu lesen und zu schreiben. Die Transparenz der Dateivirtualisierung ermöglicht Anwendungen die Wahrnehmung, dass sie schreiben und aus der geschützten Ressource lesen, wenn sie tatsächlich auf die virtualisierte Version zugreifen.

Hinweis Wenn Sie Ressourcen in Ordnern und in der Registrierung auflisten, führt Windows Vista globale Datei/Ordner und Registrierungsschlüssel in einer einzigen Liste zusammen. In dieser zusammengeführten Ansicht wird die globale (geschützte) Ressource zusammen mit der virtualisierten Ressource aufgeführt.

Wichtig Die virtuelle Kopie ist immer zuerst für die Anwendung vorhanden. Beispielsweise ist config.ini in \PF\App\config.ini und %LOCALAPPDATA%\VirtualStore\config.ini verfügbar, und die config.ini im virtuellen Speicher wird immer gelesen, auch wenn \PF\App\config.ini aktualisiert wird.

Die folgende Abbildung zeigt, wie globale und zusammengeführte Ansichten für virtualisierte Ressourcen für verschiedene Benutzer angezeigt werden.

Abbildung 2. Virtualisierte Ressourcen und Ansichten

Im Folgenden finden Sie ein Beispiel für den Dateivirtualisierungsprozess:

Syed Abbas, Ein Vertriebsmitarbeiter bei woodgrove Bank, führt unter einem Standard-Benutzerkonto auf einem Computer, den er mit anderen Vertriebsmitarbeitern teilt. Syed verwendet häufig eine Tabellenkalkulationsanwendung, um eine Datei im Verzeichnis Programme\SalesV1\ zu aktualisieren und zu speichern: \Program Files\SalesV1\SalesData.txt. Obwohl Programme\SalesV1\ geschützt ist, wird die Datei aufgrund der Windows Vista-Dateivirtualisierung erfolgreich aus der Sicht der Tabellenkalkulationsanwendung gespeichert. Um dies zu erreichen, wird der Dateischreibvorgang an benutzer\benutzername\appdata\Virtual Store\Program Files\SalesV1\SalesData.txt umgeleitet. Wenn Syed windows Explorer öffnet und zum Verzeichnis "Programme" wechselt, wird die globale Ansicht der SalesData.txt-Datei angezeigt.

Hinweis Damit Syed seine virtualisierten Dateien ermitteln kann, muss er zum virtuellen Speicher mit der Schaltfläche Kompatibilitätsdateien auf der Symbolleiste Explorer navigieren.

Nachdem sich jedoch Stuart Munson, ein weiterer Vertriebsmitarbeiter, bei der Arbeitsstation angemeldet hat, wird ihm die Datei nicht angezeigt, die SalesData.txt im Verzeichnis Programme\SalesV1\. Wenn ein anderer Benutzer den Computer verwendet und die Datei \Program files\SalesV1\SalesData.txt schreibt, wird dieser Schreibvorgang auch in den virtuellen Speicher dieses Benutzers virtualisiert. Die Dateien, die Syed aktualisiert und speichert, bleiben unabhängig von den anderen virtualisierten Dateien auf dem System.

Registrierungsvirtualisierung

Die Registrierungsvirtualisierung ähnelt der Dateivirtualisierung, gilt jedoch für Registrierungsschlüssel unter HKEY_LOCAL_MACHINE\SOFTWARE. Dieses Feature ermöglicht Anwendungen, die auf der Möglichkeit basieren, Konfigurationsinformationen in HKEY_LOCAL_MACHINE\SOFTWARE zu speichern, wenn sie unter einem Standardbenutzerkonto ausgeführt werden. Die Schlüssel und Daten werden an HKEY_CLASSES_ROOT\VirtualStore\SOFTWARE umgeleitet. Wie im Fall der Dateivirtualisierung verfügt jeder Benutzer über eine virtualisierte Kopie aller Werte, die eine Anwendung in HKLM gespeichert hat.

Registrierungsvirtualisierungsdetails

• Kann für einzelne Schlüssel in der Softwarestruktur aktiviert/deaktiviert werden
• Neue FLAGS-Option in reg.exe für die Virtualisierungssteuerung auf Schlüsselebene: Ermöglicht rekursives Aktivieren/Deaktivieren der Virtualisierung und Steuerung der "Richtlinie für open access right"
• ZwQueryKey: Fragen Sie programmgesteuert die Virtualisierungsflags für einen Schlüssel ab.
• Virtualisierung erfolgt zusätzlich zur WoW64-Umleitung
• Aktiviert sowohl in der 64-Bit- als auch in der 32-Bit-Registrierungsansicht: HKU\{SID}_Classes\VirtualStore\Machine\Software und HKU\{SID}_Classes\VirtualStore\Machine\Software\SYSWOW3264
• Die meisten älteren 32-Bit-Apps verwenden die 32-Bit-Ansicht.

Virtualisierung dient nur zur Unterstützung der Anwendungskompatibilität mit vorhandenen Programmen. Anwendungen, die für Windows Vista entwickelt wurden, sollten WEDER Schreibvorgänge in sensible Systembereiche ausführen, noch sollten sie sich auf Virtualisierung verlassen, um Abhilfe für falsches Anwendungsverhalten zu bieten. Beim Aktualisieren von vorhandenem Code für die Ausführung unter Windows Vista sollten Entwickler sicherstellen, dass Anwendungen während der Laufzeit Daten nur an benutzerspezifischen Speicherorten oder an Computerspeicherorten innerhalb von %alluserprofile% (CSIDL_COMMON_APPDATA) speichern, für die die Einstellungen der Zugriffssteuerungsliste (Access Control List, ACL) ordnungsgemäß festgelegt sind.

Wichtig Microsoft beabsichtigt, die Virtualisierung aus zukünftigen Versionen des Windows-Betriebssystems zu entfernen, da weitere Anwendungen zu Windows Vista migriert werden. Die Virtualisierung ist beispielsweise für 64-Bit-Anwendungen deaktiviert.

Virtualisierungsempfehlungen

Virtualisierung dient nur dazu, die Anwendungskompatibilität mit vorhandenen Programmen zu unterstützen. Anwendungen, die für Windows Vista entwickelt wurden, sollten WEDER Schreibvorgänge in sensible Systembereiche ausführen, noch sollten sie sich auf Virtualisierung verlassen, um Abhilfe für falsches Anwendungsverhalten bereitzustellen. Beim Aktualisieren von vorhandenem Code für die Ausführung unter Windows Vista sollten Entwickler sicherstellen, dass Anwendungen während der Laufzeit Daten nur an benutzerspezifischen Speicherorten oder an Computerstandorten in %alluserprofile% speichern, für die die Einstellungen der Zugriffssteuerungsliste (Access Control List, ACL) ordnungsgemäß festgelegt sind.

Wichtig Microsoft beabsichtigt, die Virtualisierung aus zukünftigen Versionen des Windows-Betriebssystems zu entfernen, da weitere Anwendungen zu Windows Vista migriert werden. Die Virtualisierung ist beispielsweise für 64-Bit-Anwendungen deaktiviert.

• Fügen Sie ein Anwendungsmanifest mit einem entsprechenden requestedExecutionLevel für Ihre interaktiven Anwendungen hinzu. Dadurch wird die Virtualisierung für die manifestierte Anwendung deaktiviert.
• Verwenden Sie die Registrierung nicht als Prozesskommunikationsmechanismus. Dienste und Benutzeranwendungen verfügen über unterschiedliche Ansichten des Schlüssels.
• Testen Sie Ihre Anwendung unter Windows Vista: Stellen Sie sicher, dass Prozesse, die als Standardbenutzer ausgeführt werden, nicht in globale Namespaces wie %systemroot% schreiben.
• Für Entwickler von Filtertreibern: Überprüfen Sie Ihren Höhenbereich. Siehe Dateisystemfilter. Diese müssen höher als die FSFilter-Virtualisierung sein.
• Denken Sie daran, dass virtualisierte Ressourcen benutzerspezifische Kopien globaler Ressourcen sind.

Zugriffstokenänderungen

Wenn sich ein Benutzer bei einem Windows Vista-Computer anmeldet, untersucht Windows die administratorlichen Windows-Berechtigungen und relative IDs (RIDs), die das Benutzerkonto besitzt, um festzustellen, ob der Benutzer zwei Zugriffstoken (ein gefiltertes Zugriffstoken und ein Vollzugriffstoken) erhalten soll. Windows erstellt zwei Zugriffstoken für den Benutzer, wenn eines der folgenden Punkte zutrifft:

1. Das Konto des Benutzers enthält eine der folgenden RIDs.
   • DOMAIN_GROUP_RID_ADMINS
   • DOMAIN_GROUP_RID_CONTROLLERS
   • DOMAIN_GROUP_RID_CERT_ADMINS
   • DOMAIN_GROUP_RID_SCHEMA_ADMINS
   • DOMAIN_GROUP_RID_ENTERPRISE_ADMINS
   • DOMAIN_GROUP_RID_POLICY_ADMINS
   • DOMAIN_ALIAS_RID_ADMINS
   • DOMAIN_ALIAS_RID_POWER_USERS
   • DOMAIN_ALIAS_RID_ACCOUNT_OPS
   • DOMAIN_ALIAS_RID_SYSTEM_OPS
   • DOMAIN_ALIAS_RID_PRINT_OPS
   • DOMAIN_ALIAS_RID_BACKUP_OPS
   • DOMAIN_ALIAS_RID_RAS_SERVERS
   • DOMAIN_ALIAS_RID_PREW2KCOMPACCESS
   • DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS
   • DOMAIN_ALIAS_RID_CRYPTO_OPERATORS
2. Das Konto des Benutzers enthält alle anderen Berechtigungen als die eines Standardbenutzerkontos. Ein Standardbenutzerkonto enthält nur die folgenden Berechtigungen.
   • SeChangeNotifyPrivilege
   • SeShutdownPrivilege
   • SeUndockPrivilege
   • SeIncreaseWorkingSetPrivilege
   • SeTimeZonePrivilege

Welche Berechtigungen das gefilterte Token enthält, hängt davon ab, ob das ursprüngliche Token eines der oben aufgeführten eingeschränkten RIDS enthielt. Wenn eine der eingeschränkten RIDs im Token vorhanden ist, werden alle Berechtigungen entfernt, mit ausnahme von:

• SeChangeNotifyPrivilege
• SeShutdownPrivilege
• SeUndockPrivilege
• SeReserveProcessorPrivilege
• SeTimeZonePrivilege

Wenn sich keine eingeschränkten RIDs im Token befinden, werden nur die folgenden Berechtigungen entfernt:

• SeCreateTokenPrivilege
• SeTcbPrivilege
• SeTakeOwnershipPrivilege
• SeBackupPrivilege
• SeRestorePrivilege
• SeDebugPrivilege
• SeImpersonatePrivilege
• SeRelabelPrivilege

Das erste Zugriffstoken, das als gefiltertes Zugriffstoken bezeichnet wird, hat die vorherigen RIDs (sofern vorhanden) als USE_FOR_DENY_ONLY im Zugriffstoken markiert und die zuvor nicht aufgeführten Administratorberechtigungen für Windows entfernt. Das gefilterte Zugriffstoken wird standardmäßig verwendet, wenn der Benutzer Anwendungen startet. Das nicht geänderte Vollzugriffstoken, das als verknüpftes Zugriffstoken bezeichnet wird, wird an das gefilterte Zugriffstoken angefügt und wird verwendet, wenn Anforderungen zum Starten von Anwendungen mit einem vollständigen Verwaltungszugriffstoken gestellt werden.

Weitere Informationen zu RIDs finden Sie im MSDN Library-Artikel SID-Zeichenfolgen [Sicherheit].

Weitere Informationen zu Windows-Berechtigungen finden Sie im MSDN Library-Artikel Autorisierungskonstanten [Sicherheit].

UAC-Architektur

Das folgende Diagramm stellt den Prozessablauf für ausführbare Starts in Windows Vista dar.

Abbildung 3. UAC-Architektur

Im Folgenden finden Sie eine Beschreibung des Prozessablaufs, der im UAC-Architekturdiagramm angezeigt wird, und wie die UAC implementiert wird, wenn eine ausführbare Datei versucht, zu starten.

Standardbenutzerstartpfad

Der Windows Vista-Standardbenutzerstartpfad ähnelt dem Windows XP-Startpfad, enthält jedoch einige Änderungen.

• ShellExecute() ruft CreateProcess() auf.
• CreateProcess() ruft die AppCompat-, Fusion- und Installationsprogrammerkennung auf, um zu beurteilen, ob die Anwendung eine Erhöhung erfordert. Die ausführbare Datei wird dann überprüft, um ihren requestedExecutionLevel zu ermitteln, der im Anwendungsmanifest der ausführbaren Datei gespeichert ist. Die AppCompat-Datenbank speichert Informationen für die Anwendungskompatibilitätsfixeinträge einer Anwendung. Installationsprogrammerkennung erkennt ausführbare Setupdateien.
• CreateProcess() gibt einen Win32-Fehlercode zurück, der ERROR_ELEVATION_REQUIRED.
• ShellExecute() sucht speziell nach diesem neuen Fehler und ruft beim Empfang den Application Information Service (AIS) auf, um den Start mit erhöhten Rechten zu versuchen.

Startpfad mit erhöhten Rechten

Der Startpfad mit erhöhten Windows Vista-Rechten ist ein neuer Windows-Startpfad.

• AIS empfängt den Aufruf von ShellExecute() und wertet die angeforderte Ausführungsebene neu aus und Gruppenrichtlinie, um zu bestimmen, ob die Erhöhung zulässig ist, und um die Benutzerfreundlichkeit für die Erhöhung zu definieren.
• Wenn die angeforderte Ausführungsebene eine Erhöhung erfordert, startet der Dienst die Aufforderung zur Erhöhung auf dem interaktiven Desktop des Aufrufers (basierend auf Gruppenrichtlinie), wobei der von ShellExecute() übergebene HWND verwendet wird.
• Sobald der Benutzer seine Zustimmung oder gültige Anmeldeinformationen erteilt hat, ruft AIS bei Bedarf das entsprechende Zugriffstoken ab, das dem entsprechenden Benutzer zugeordnet ist. Beispielsweise ruft eine Anwendung, die einen requestedExecutionLevel von highestAvailable anfordert, andere Zugriffstoken für einen Benutzer ab, der nur Mitglied der Gruppe Sicherungsoperatoren ist, als für ein Mitglied der lokalen Gruppe Administratoren.
• AIS stellt einen CreateProcessAsUser()-Aufruf erneut aus, gibt das Administratorzugriffstoken an und gibt den interaktiven Desktop des Aufrufers an.

Wirkt sich die UAC auf Ihre Anwendung aus?

Ob Ihre Anwendung vom UAC betroffen ist, hängt vom aktuellen Status der Anwendung ab. In einer Reihe von Fällen sind keine Änderungen erforderlich, um die Anforderungen von Microsoft Windows-Sicherheit zu erfüllen. Einige Anwendungen, einschließlich branchenspezifischer Anwendungen, erfordern jedoch möglicherweise Änderungen an ihren Installations-, Funktions- und Updateprozessen, um in einer Windows Vista-UAC-Umgebung ordnungsgemäß zu funktionieren.

Hinweis Wenn eine Anwendung als Standardbenutzer unter Windows XP gut funktioniert, funktioniert sie gut als Standardbenutzer unter Windows Vista.

Warum muss ich die administrativen Abhängigkeiten meiner Anwendung entfernen?

Ein grundlegender Schritt zur Erhöhung der Sicherheit der gesamten Computingumgebung besteht darin, Benutzern die Ausführung ohne ihr Administratorzugriffstoken zu ermöglichen. Wenn eine Anwendung nur ausgeführt oder installiert wird, wenn der Benutzer Administrator ist, werden Benutzer gezwungen, Anwendungen mit unnötigem erhöhten Zugriff auszuführen. Das grundlegende Problem besteht darin, dass, wenn Benutzer immer gezwungen sind, Anwendungen mit erhöhten Zugriffstoken auszuführen, betrügerischer oder böswilliger Code das Betriebssystem leicht ändern kann, oder schlimmer noch, andere Benutzer beeinträchtigen kann.

Das Ziel von Microsoft besteht darin, dass Kunden verstehen, dass Anwendungen nicht unnötigerweise als Administrator ausgeführt werden sollten, und dass sie jedes Mal fragen, wenn sie aufgefordert werden, die Anforderung einer Anwendung zur Ausführung als Administrator zu genehmigen. UAC ist eine grundlegende Komponente zum Erreichen dieses Ziels und wird einen großen Beitrag zur Wiederherstellung einer sichereren Computerumgebung für alle Benutzer leisten.

Reduzieren der Gesamtbetriebskosten Ihrer Anwendung

Das Standardbenutzerkonto ist sehr attraktiv für IT-Administratoren, die daran interessiert sind, die Sicherheit und Kontrolle über ihre verwalteten Computer zu erhöhen und gleichzeitig die Gesamtbetriebskosten (TCO) zu senken. Da ein Standardbenutzerkonto keine Systemänderungen vornehmen kann, besteht eine direkte Beziehung zur Reduzierung der TCO und einer besseren Steuerung der Anwendungsinstallation und systemweiten Änderungen. Das Standardbenutzerkonto ist auch für Privatbenutzer attraktiv, bei denen Eltern einen Computer mit Kindern teilen. Microsoft Windows Vista enthält integrierte Kindersicherungen, die nur erfolgreich implementiert werden, indem Kinderbenutzerkonten als Standardbenutzer erstellt werden. Standardbenutzerkonten können auch keine Dateien ändern oder löschen, die von anderen Benutzern erstellt wurden. Sie können dateien in profilen anderer Benutzer nicht lesen, Systemdateien infizieren oder vom System freigegebene ausführbare Dateien weder versehentlich noch absichtlich ändern. Standardbenutzerkonten führen zu einer allgemeinen Verbesserung der Computersicherheit und der Kindersicherung.

Standardmäßig sichern

Bei Microsoft sind die Grundsätze der Trustworthy Computing Initiative von Microsoft in der Softwareentwicklung verankert. Folglich ist die verbesserte Sicherheit ein wesentlicher Bestandteil des Windows Vista-Entwicklungsprozesses.

Die Sicherheitssäule von Trustworthy Computing umfasst drei Grundlagen: "Sicher nach Entwurf", "Standardmäßig sicher" und "Sicher in der Bereitstellung". Die Art und Weise, wie Sie und andere ISVs Ihre Anwendungen entwickeln, um zur Allgemeinen Sicherheit des Betriebssystems beizutragen, wird ein wichtiger Erfolgsfaktor für die Erreichung von Trustworthy Computing in Windows Vista sein.

Das Ziel des weiteren Verlaufs dieses Leitfadens besteht darin, Entwicklern folgendes beizubringen:

• Schreiben von Anwendungen, für die der Benutzer kein Administrator sein muss, um Routineaufgaben auszuführen
• Erstellen Sie Installationspakete mit Windows® Installer 4.0-UAC-Patchtechnologien, die gut auf dem Standardbenutzerdesktop in Unternehmen bereitgestellt und auch im Homebereich ordnungsgemäß aktualisiert werden.
• Identifizieren von Standardbenutzer- und Verwaltungsfunktionen und Extrapolieren von verwaltungstechnischen Aufgaben auf UAC-Kompatibilität
• Schreiben von Anwendungsbenutzeroberflächen, die die UAC-Funktionalität nutzen

Für den Erfolg der UAC ist es von entscheidender Bedeutung, dass Anwendungsentwickler die Philosophie der geringsten Rechte annehmen und ihre Anwendungen so entwerfen, dass sie ordnungsgemäß funktionieren, wenn sie mit einem Standardbenutzerkonto ausgeführt werden.

Eines der Ziele der Windows Vista-Version ist es, das Prinzip des Entwerfens für Standardbenutzer und Administratoren im Admin Genehmigungsmodus für alle Entwickler zu fördern und zu fördern. Das Erreichen dieses Ziels hilft bei der Verhinderung verschiedener Angriffe auf einzelne Anwendungen und verringert die Möglichkeit, dass solche Angriffe die Sicherheit des Systems beeinträchtigen. Obwohl diese Ziele heute in gewissem Maße erreicht werden können, indem Administratoren zwei Konten verwenden müssen, schlägt dies tendenziell aus den folgenden Gründen fehl:

• Es ist fast unmöglich, einen Benutzer zu steuern, der über ein vollständiges Administratorzugriffstoken verfügt. Administratoren können Anwendungen installieren und beliebige Anwendungen oder Skripts ausführen. IT-Manager suchen immer nach Möglichkeiten, "Standarddesktops" zu erstellen, auf denen sich Benutzer als Standardbenutzer anmelden. Standarddesktops reduzieren die Helpdeskkosten erheblich und reduzieren den IT-Mehraufwand.
• Es entsteht ein erheblicher Mehraufwand beim Wechseln zwischen Konten, wenn der Benutzer einen Verwaltungsvorgang durchführen möchte.
• Nachdem sie einen Verwaltungsvorgang durchgeführt haben, vergessen Benutzer möglicherweise, wieder zu ihrem Standardbenutzerkonto zu wechseln, oder entscheiden, dass es zu viel Aufwand ist, zurückzuwechseln.

Infolgedessen können sich Benutzer entscheiden, sich immer bei ihren Administratorkonten anzumelden, wodurch die Sicherheitsmaßnahmen verfehlt werden. Um dies zu verringern, führt UAC das Konzept des Admin Genehmigungsmodus ein. Ein Admin Genehmigungsmodus-Benutzerkonto ist ein Benutzerkonto, das Mitglied der lokalen Administratorgruppe auf einem System ist, auf dem UAC aktiviert ist.

Im Unternehmen wird Admin Genehmigungsmodus als Brückentechnologie für die Migration zu Windows Vista verwendet. Im Idealfall führen Unternehmen alle Benutzer als Standardbenutzer aus und deaktivieren die Aufforderung zur Erhöhung für Standardbenutzer. Dieses Setup ermöglicht einen verwalteten Standarddesktop, auf dem Installationen mit einer Softwarebereitstellungstechnologie wie Microsoft Systems Management Server (SMS) bereitgestellt werden.

Wichtig Microsoft empfiehlt weiterhin, dass Mitglieder der Gruppe Domänenadministratoren weiterhin zwei separate Benutzerkonten in Windows Vista verwalten: ein Standardbenutzerkonto und ein Domänenadministratorbenutzerkonto. Die gesamte Domänenverwaltung sollte mit dem Domänenadministratorkonto erfolgen. Um die Sicherheit weiter zu verbessern, sollten Sie eine intelligente Karte Lösung in Domänenumgebungen bereitstellen. Weitere Informationen finden Sie im Planungsleitfaden für den sicheren Zugriff mithilfe von Smartcards .

Im Folgenden sind die Windows Vista-Entwurfsziele für Admin Genehmigungsmodus aufgeführt:

• Vermeiden Sie die Notwendigkeit von zwei separaten Konten für Benutzer, die Mitglieder der Administratorgruppe sind: Dieses Ziel wird erreicht, indem Programme nur mit einem Standardbenutzerzugriffstoken ausgeführt werden, es sei denn, der Benutzer erteilt die Genehmigung zur Verwendung des vollständigen Administratorzugriffstokens.
• Schützen Sie Prozesse, die mit einem vollständigen Verwaltungszugriffstoken ausgeführt werden, vor dem Zugriff oder der Änderung durch die Prozesse, die als Standardbenutzer ausgeführt werden.
• Sorgen Sie für einen nahtlosen Übergang zwischen Administrator- und Standardbenutzerarbeitsbereichen.

Derzeit müssen die meisten Windows-Anwendungen als Administrator ausgeführt werden, führen aber keine verwaltungstechnischen Vorgänge aus. Diese Anwendungen sind ein Nebenprodukt der Microsoft Windows 9x-Betriebssystemphilosophie: "Jeder ist ein Administrator".

Im Folgenden sind Beispiele für problematische Anwendungen aufgeführt:

• Anwendungen, die unnötigerweise in HKEY_LOCAL_MACHINE (HKLM) oder in Systemdateien im Dateisystem schreiben.
• Eine ActiveX-Installation, um eine Branchenanwendung mit einer Weboberfläche zu ermöglichen.
• Anwendungen, die unnötigerweise Zugriff auf Ressourcen anfordern, die ein vollständiges Administratorzugriffstoken erfordern.

Im nächsten Abschnitt werden neue Technologien für Windows Vista vorgestellt, die sich auf ISVs auswirken.

Wie kann ich feststellen, ob meine Anwendung administrative Abhängigkeiten aufweist?

Um Entwickler, ISVs und Organisationen bei der Bewertung ihrer Anwendungen zu unterstützen, stellt Microsoft die Microsoft Standard User Analyzer bereit. Die Standardbenutzeranalyse kann verwendet werden, um das Nicht-UAC-konforme Verhalten einer Anwendung zu identifizieren. Microsoft empfiehlt, dass Entwickler dieses Tool ausführen, um Probleme beim Ausführen der Anwendung unter einem Standardbenutzerkonto zu identifizieren. Diese Tests sollten auch dann ausgeführt werden, wenn die Anwendung bereits unter einem Standardbenutzerkonto unter Windows XP installiert und ordnungsgemäß ausgeführt wird. Die Anwendung kann Vorgänge ausführen, z. B. den Versuch, in Die Speicherorte der Systemregistrierung zu schreiben, und Entscheidungen basierend auf dem Systemverhalten treffen, z. B. die Suche nach einer Fehlerantwort. Windows Vista verhält sich möglicherweise anders als frühere Versionen des Windows-Betriebssystems, da neue Anwendungskompatibilitätsunterstützung hinzugefügt wurde. Daher wird empfohlen, alle Anwendungen mit der neuen Version der Standard-Benutzeranalyse zu testen.

Die Standardbenutzeranalyse zeichnet alle verwaltungstechnischen Vorgänge auf, die von einer Anwendung auftreten, einschließlich Registrierungs-/Dateisystemzugriff und API-Aufrufen mit erhöhten Rechten. Diese Daten werden in einer Protokolldatei gespeichert und im Tool angezeigt. Die Standardbenutzeranalyse identifiziert die folgenden allgemeinen Abhängigkeiten, zusätzlich zu vielen anderen:

• Abhängigkeit von Objekten, die den angeforderten Zugriff nur für vertrauenswürdige Benutzer einschränken.

  Beispielsweise gewährt HKEY_LOCAL_MACHINE administratoren und SYSTEM nur KEY_WRITE. Eine Anwendung, die KEY_WRITE an HKEY_LOCAL_MACHINE anfordert, funktioniert nicht mit aktivierter UAC.

• Verwendung von Windows-Berechtigungen mit Sicherheitsausweitungen, z. B. SE_DEBUG_PRIVILEGE, die das Debuggen von Prozessen anderer Benutzer ermöglichen und nur Administratoren gewährt werden.

Was sind die Anforderungen, wenn ich über eine legitime Administratoranwendung habe?

Für Anwendungen, die standardmäßig legitime Verwaltungsvorgänge ausführen, hat Microsoft eine Erweiterung für den Abschnitt trustInfo des aktuellen Windows XP-Anwendungsmanifestschemas implementiert. Sie können diese neuen Attribute verwenden, um dem System mitzuteilen, dass Sie über eine legitime Verwaltungsanwendung verfügen. Das System fordert automatisch die Genehmigung des Benutzers an, um die Anwendung mit einem vollständigen Administratorzugriffstoken zu starten. Informationen zum Erweitern des Anwendungsmanifests finden Sie im Abschnitt Erstellen und Einbetten eines Anwendungsmanifests mit Ihrer Anwendung in diesem Dokument.

Entwerfen von Anwendungen für Windows Vista

Die folgende Liste stellt einen Workflow zum Entwerfen Ihrer Anwendung für Windows Vista dar:

1. Testen ihrer Anwendung auf Windows Vista-Anwendungskompatibilität
2. Klassifizieren Ihrer Anwendung als Standardbenutzer-, Administrator- oder gemischte Benutzeranwendung
3. Neugestaltung der Funktionalität Ihrer Anwendung für UAC-Kompatibilität
4. Neugestaltung der Benutzeroberfläche Ihrer Anwendung
5. Neugestaltung des Installationsprogramms Ihrer Anwendung
6. Erstellen und Einbetten eines Anwendungsmanifests mit Ihren Administrativen Anwendungen
7. Testen Ihrer Anwendung
8. Signieren Ihrer Anwendung
9. Bestimmen, ob das Windows Vista-Logo-Programm verfolgt werden soll

1. Testen Ihrer Anwendung auf Anwendungskompatibilität

Tests auf Anwendungskompatibilität mit UAC können einfach durchgeführt werden, indem Sie die Standard-Benutzeranalyse installieren.

Um die grafische Protokollanzeige der Standardbenutzeranalyse zu verwenden, müssen Sie den Microsoft Application Verifier installieren. Der Application Verifier ist ein kostenloser Download auf der Microsoft-Website.

Das folgende Verfahren veranschaulicht, wie Sie administrative Anwendungen vor Windows Vista identifizieren, die unter Windows Vista nicht ordnungsgemäß ausgeführt werden, indem Sie die Standard-Benutzeranalyse verwenden.

Es gibt zwei Ansätze, die Sie für die Verwendung der Standardbenutzeranalyse verwenden können: Starten Sie Ihre Anwendung als Standardbenutzer oder starten Sie Ihre Anwendung mit erhöhten Rechten als Administrator:

Starten Sie Ihre Anwendung als Standardbenutzer.

In diesem instance wird die Standardbenutzeranalyse im Diagnosemodus ausgeführt. Die Anwendung schlägt beim ersten Fehler fehl, und die Standardbenutzeranalyse meldet, warum sie fehlgeschlagen ist.

Starten Sie Ihre Anwendung mit erhöhten Rechten als Administrator.

In diesem instance wird die Standardbenutzeranalyse im Vorhersagemodus ausgeführt. Die Anwendung kann ihren Kurs durchlaufen, und die Standardbenutzeranalyse sagt voraus und gibt einen Überblick über die Fehler, die bei der Anwendung auftreten können, wenn sie als Standardbenutzer ausgeführt wird.

Sobald die Fehler behoben und behoben wurden, führen Sie dieses Verfahren erneut als Standardbenutzer ohne die Standardbenutzeranalyse aus, um sicherzustellen, dass Ihre Anwendung unter Windows Vista wie erwartet funktioniert.

So identifizieren Sie Anwendungskompatibilitätsprobleme für Anwendungen vor Windows Vista

1. Melden Sie sich bei einem Windows Vista-Computer als Administrator im genehmigungsmodus Admin an.
2. Klicken Sie auf Start, alle Programme und dann auf Standard User Analyzer.
3. Geben Sie in der Standardbenutzeranalyse für Zielanwendung den vollständigen Verzeichnispfad für eine zu testende Anwendung an, oder klicken Sie auf die Schaltfläche Durchsuchen, um die ausführbare Datei der Programme mit Windows Explorer zu suchen.
4. Klicken Sie im Dialogfeld Benutzerkontensteuerung auf Starten und dann auf Weiter .
5. Führen Sie nach dem Starten der Testanwendung standardmäßige administrative Aufgaben in der Anwendung aus, und schließen Sie die Anwendung, wenn Sie den Vorgang abgeschlossen haben.
6. Untersuchen Sie in der Standardbenutzeranalyse die Ausgabe auf jeder Registerkarte. Verwenden Sie diese Daten, um die Kompatibilitätsprobleme zu identifizieren, die das Programm möglicherweise hat.

2. Klassifizieren Ihrer Anwendung als Standardbenutzer, Administrator oder gemischte Benutzeranwendung

Administrative Anwendungen in Windows Vista verfügen häufig über eine Mischung aus Verwaltungs- und Standardbenutzerfunktionen. Daher müssen bei der Entscheidung, wie Ihre Anwendung in Windows Vista funktioniert, eine Reihe von Optionen berücksichtigt werden. Die Verwaltungsfunktionalität kann vollständig entfernt oder von der Standardfunktion des Benutzerkontos getrennt werden, indem der Benutzer zur Genehmigung aufgefordert wird.

Fragen zum Klassifizieren Ihrer Anwendung

Beantworten Sie die folgenden Fragen, um festzustellen, ob Ihre Anwendung für die Windows Vista-Kompatibilität neu gestaltet werden muss:

• Wird Ihre Anwendung als Standardbenutzer ausgeführt?
• Kann die Verwaltungsfunktionalität so festgelegt werden, dass kein Administratorzugriffstoken mehr erforderlich ist?
• Können die administrativen Abschnitte aus der Funktionalität des Programms entfernt werden?

Wird Ihre Anwendung als Standardbenutzer ausgeführt?

Um diese Frage zu beantworten, stellen Sie sicher, dass die Anwendung oder das Feature von Standardbenutzern vollständig verwendet wird. Wenn ein Teil Ihres Features erfordert, dass der Benutzer administrator ist, lautet die Antwort auf diese Frage "Nein".

Überprüfen, ob die Anwendung oder systemsteuerung von Standardbenutzern verwendet werden kann:

• Testen Sie die Anwendung oder systemsteuerung gründlich sowohl als Standardbenutzer als auch als Administrator. Stellen Sie sicher, dass die Benutzerinteraktionen sowohl für Standardbenutzer als auch für Administratoren identisch sind.
• Überprüfen Sie, wo die Einstellungen in der Registrierung gespeichert sind. Wenn Einstellungen in HKLM gespeichert werden, erfordert die Anwendung oder Systemsteuerung höchstwahrscheinlich ein Administratorzugriffstoken.
• Wenn eine der Einstellungen pro Computer erfolgt, erfordert die Anwendung oder Systemsteuerung ein Administratorzugriffstoken.
• Wenn eine der Einstellungen in den Profilen anderer Benutzer ausgeführt wird, erfordert die Anwendung oder Systemsteuerung ein Administratorzugriffstoken.

Kann die Verwaltungsfunktionalität so festgelegt werden, dass kein Administratorzugriffstoken mehr erforderlich ist?

Wenn Ihre Anwendung oder Systemsteuerung Über Einstellungen oder Interaktionen verfügt, die ein vollständiges Administratorzugriffstoken erfordern, kann es geändert werden, um als Standardbenutzer ordnungsgemäß zu funktionieren? Kann das Programm informationen stattdessen in benutzerspezifischen Einstellungen speichern? Wenn dies nicht der Fall ist, lautet die Antwort auf diese Frage "Nein".

Ein gutes Beispiel für die Art von Feature/Einstellung, die behoben werden kann, ist Calc.exe (der Windows-Rechner). In Windows XP war die Einstellung "Scientific" im Vergleich zu "Standard" eine Computereinstellung, was bedeutete, dass ein vollständiges Administratorzugriffstoken erforderlich war, um die Einstellung zu ändern. In Windows Vista wird diese Einstellung im Profil des Benutzers gespeichert.

So überprüfen Sie, ob administrative Abschnitte aus der Funktionalität des Programms entfernt werden können:

• Testen Sie die Anwendung oder systemsteuerung gründlich sowohl als Standardbenutzer als auch als Administrator. Kann die Benutzeroberfläche für beide Benutzertypen identisch sein?

• Ist es möglich, die Zugriffssteuerungslisten (Access Control Lists, ACLs) zu senken, die zum Schreiben in den HKLM-Schlüssel erforderlich sind?

  Hinweis Dieser Kurs sollte nicht auf die leichte Schulter genommen werden. Seien Sie vorsichtig, um die Gesamtsicherheit des Systems nicht zu gefährden, indem Sie die von der ACL gewährte Kontrolle verringern.

• Ist es möglich, die Benutzeroberfläche so zu ändern, dass der Status pro Benutzer anstelle des globalen Zustands festgelegt wird (und keine globalen Zustandsänderungen über die Benutzeroberfläche verfügbar gemacht werden)?

Können die administrativen Abschnitte aus der Funktionalität des Programms entfernt werden?

Muss Ihr Feature unbedingt über diese Funktionalität verfügen? Wenn Sie die administrativen Features/Funktionen nicht kürzen können, lautet die Antwort auf diese Frage "Nein".

Gehen Sie wie folgt vor, um zu bestimmen, ob die administrativen Abschnitte aus der Funktionalität des Programms entfernt werden können:

• Testen Sie die Systemsteuerung sowohl als Standardbenutzer als auch als Administrator. Wie sieht das Benutzerszenario für die Beibehaltung dieses Features aus?
• Ist diese Einstellung/Funktion an anderer Stelle verfügbar? Möglicherweise ist die Funktionalität in der Systemsteuerung redundant.

Analysieren der Antworten zum Klassifizieren Ihrer Anwendung

Wenn Sie eine der vorherigen Fragen mit "Ja" beantwortet haben

Nehmen Sie die erforderlichen Änderungen in der Anwendung oder Systemsteuerung vor (falls vorhanden), um die Elemente zu entfernen, für die der Benutzer über ein vollständiges Administratorzugriffstoken verfügen muss.

Die folgende Liste enthält ausführliche Informationen zu den Vorteilen einer echten Standardbenutzeranwendung:

• Ihr Feature kann für alle Benutzer gleichermaßen verwendet werden. Dies ist der ideale Zustand, da die meisten Features kein vollständiges Administratorzugriffstoken erfordern sollten.
• Ihren Benutzern wird nie eine Eingabeaufforderung mit Ihren Features angezeigt.
• Ihre Features sind viel sicherer, da nie das Administratorzugriffstoken erforderlich ist.

Wenn Sie alle vorangehenden Fragen mit "Nein" beantwortet haben

Die Anwendung oder Systemsteuerung muss geändert werden, damit das Feature mit der UAC funktioniert.

Überprüfen Sie, ob die Anwendung oder Systemsteuerung mit der UAC funktioniert:

Testen Sie schließlich die Anwendung oder systemsteuerung als Standardbenutzer sowie als Administrator. Stellen Sie sicher, dass andere Optionen (die vorherigen Fragen) für diese bestimmte Anwendung oder Systemsteuerung nicht verwendet werden können.

3. Umgestalten der Funktionalität Ihrer Anwendung für UAC-Kompatibilität

Verwenden Sie die Informationen in diesem Abschnitt, nachdem Sie Ihre Anwendung klassifiziert und ermittelt haben, ob sie für UAC neu gestaltet werden muss.

Eine große Komponente der Neugestaltung Ihrer Anwendung für Windows Vista ist die Untersuchung des Benutzerzugriffsmodells Ihrer Anwendung im Kern.

Anforderungen für alle Windows Vista-Anwendungen

Angeben eines requestedExecutionLevel

Damit die UAC ordnungsgemäß funktioniert, muss das Betriebssystem erkennen können, welcher Code erhöhte Berechtigungen benötigt und welcher Code nicht.

In Windows Vista erfordern diese Änderungen, dass Anwendungen mit Informationen gekennzeichnet werden, mit denen das Betriebssystem bestimmen kann, in welchem Kontext die Anwendung gestartet werden soll. Beispielsweise müssen Standardbenutzeranwendungen gekennzeichnet werden, damit sie als Aufrufer ausgeführt werden können, und Anwendungen, die Barrierefreiheit ermöglichen, müssen vom System identifiziert werden.

Keine Komponenten bei Rundll32 registrieren

Einige Anwendungen verwenden die ausführbaren Windows Rundll32-Dateien, um Komponenten auszuführen. Diese Methode ist jedoch nicht mit den Windows Vista-Entwicklungsanforderungen kompatibel. Das direkte Aufrufen von Rundll32 führt zu UAC-Kompatibilitätsproblemen. Wenn eine Anwendung für die Ausführung der ausführbaren Rundll32-Dateien verwendet, ruft Rundll32 den Application Information Service (AIS) im Namen der Anwendung auf, um die UAC-Aufforderung zur Erhöhung zu initiieren. Daher hat die UAC-Eingabeaufforderung zur Erhöhung keine Kenntnis von der ursprünglichen Anwendung und zeigt die Anwendung an, die rechte Rechte als "Windows-Hostprozess(Rundll32)" anfordert. Ohne eine klare Beschreibung und ein Symbol für die Anwendung, die Rechteerweiterung anfordert, haben Benutzer keine Möglichkeit, die Anwendung zu identifizieren und zu bestimmen, ob eine Erhöhung sicher ist.

Wenn Ihre Anwendung rundll32 aufruft, um Komponenten auszuführen, verwenden Sie den folgenden Workflow, um den Ausführungsaufruf neu zu gestalten.

1. Erstellen Sie eine neue separate ausführbare Datei für Ihre Anwendung.
2. Rufen Sie in der neuen ausführbaren Datei die exportierte Funktion in Ihrer DLL auf, die Sie mit Rundll32 angegeben hätten. Möglicherweise müssen Sie die DLL laden, wenn sie keine LIB-Datei enthält.
3. Erstellen Sie in einer Ressourcendatei ein neues Symbol für die ausführbare Datei, und fügen Sie es hinzu. Dieses Symbol wird in der Eingabeaufforderung zur Erhöhung der Benutzerkontensteuerung angezeigt, wenn die Anwendung Rechteerweiterungen anfordert.
4. Geben Sie einen kurzen, aussagekräftigen Namen für die ausführbare Datei an. Dieser Name wird in der Eingabeaufforderung zur Erhöhung der Benutzerkontensteuerung angezeigt, wenn die Anwendung Rechteerweiterung anfordert.
5. Erstellen Und einbetten Sie eine Anwendungsmanifestdatei für die ausführbare Datei, und markieren Sie sie mit der angeforderten Ausführungsebene requireAdministrator. Dieser Vorgang wird im Abschnitt Erstellen und Einbetten eines Anwendungsmanifests mit Ihrer Anwendung beschrieben.
6. Authenticode signieren Sie die neue ausführbare Datei. Dieser Vorgang wird im Abschnitt Authenticode Sign Your Application (Authenticode Sign Your Application) beschrieben.

Nach der Deinstallation einer Anwendung sollte der Benutzer in der Lage sein, sie ohne Fehler neu zu installieren.

Anforderungen für Standardbenutzeranwendungen

Im Folgenden finden Sie eine Zusammenfassung der Punkte, die Sie beim Entwerfen von Anwendungen beachten sollten, die ordnungsgemäß unter einem Standardbenutzerkonto ausgeführt werden. Entwickler sollten diese Anforderungen während der Entwurfsphase ihrer Anwendungen berücksichtigen.

Einrichtung

• Führen Sie bei der ersten Ausführung niemals administrative Aktionen (z. B. das Abschließen des Setupprozesses) aus. Dies sollte im Rahmen des anfänglichen Setupprozesses erfolgen.
• Schreiben Sie niemals direkt in das Windows-Verzeichnis oder die Unterverzeichnisse. Verwenden Sie die richtigen Methoden zum Installieren von Dateien, z. B. Schriftarten.
• Wenn Sie Ihre Anwendung automatisch aktualisieren müssen, verwenden Sie einen Mechanismus, der für Standardbenutzer geeignet ist, z. B. Windows Installer 4.0 User Account Control Patching, um das Update durchzuführen.

Speichern des Zustands

• Schreiben Sie keine Benutzerinformationen oder beschreibbare Informationen in Programme oder Programmverzeichnisse.
• Verwenden Sie keine hartcodierten Pfade im Dateisystem. Nutzen Sie die KnownFolders-API und ShGetFolder, um zu ermitteln, wo Daten geschrieben werden sollen.

Ausführen und Testen unter einem Standardbenutzerkonto

Wenn Sie eine nicht administrative Anwendung schreiben, z. B. eine BRANCHENanwendung oder eine Benutzeranwendung wie ein Spiel, müssen Sie Immer Anwendungsdaten an einen Speicherort schreiben, auf den der Standardbenutzer Zugriff hat. Im Folgenden sind einige der empfohlenen Anforderungen aufgeführt.

• Schreiben von Benutzerdaten in das Benutzerprofil: CSIDL_APPDATA.
• Schreiben von Daten pro Computer in Benutzer\Alle Benutzer\Anwendungsdaten: CSIDL_COMMON_APPDATA.
• Die Anwendung kann nicht von administrativen APIs abhängig sein. Beispielsweise schlägt ein Programm, das den erfolgreichen Aufruf der Windows-Funktion SetTokenInformation() erwartet, unter einem Standardbenutzerkonto fehl.

Schnelles Benutzerwechseln (FUS)-fähig

Anwendungen werden häufiger von einem anderen Benutzer als dem Benutzer installiert, der die Anwendung ausführen wird. Dies bedeutet beispielsweise, dass ein übergeordnetes Element die Anwendung für das untergeordnete Element installiert. Im Unternehmen installiert ein Bereitstellungssystem, z. B. SMS oder Gruppenrichtlinie Ankündigung, die Anwendung mithilfe eines Administratorkontos.

Wenn die Benutzereinstellungen bei der ersten Ausführung nicht vorhanden sind, erstellen Sie sie neu. Gehen Sie nicht davon aus, dass sich der Setupprozess um die Einstellungen gekümmert hat.

Anforderungen für Administratoranwendungen

Verwenden Sie die HWND-Eigenschaft, um als Vordergrundanwendung anerkannt zu werden.

Hintergrundanwendungen fordern den Benutzer automatisch zur Erhöhung auf der Taskleiste auf, anstatt automatisch zum sicheren Desktop zur Erhöhung zu wechseln. Die Eingabeaufforderung zur Erhöhung wird auf der Taskleiste minimiert angezeigt und blinkt, um den Benutzer darüber zu informieren, dass eine Anwendung die Erhöhung angefordert hat. Ein Beispiel für eine Hintergrunderweiterung tritt auf, wenn ein Benutzer zu einer Website navigieren und mit dem Herunterladen einer Installationsdatei beginnt. Der Benutzer überprüft dann die E-Mail, während die Installation im Hintergrund heruntergeladen wird. Sobald der Download im Hintergrund abgeschlossen ist und die Installation beginnt, wird die Erhöhung als Hintergrundaufgabe und nicht als Vordergrundaufgabe erkannt. Diese Erkennung verhindert, dass die Installation abrupt den Fokus des Bildschirms des Benutzers stiehlt, während der Benutzer eine andere Aufgabe ausführt, nämlich das Lesen von E-Mails. Dieses Verhalten sorgt für eine bessere Benutzerfreundlichkeit für die Eingabeaufforderung zur Erhöhung.

Einige Vordergrundanwendungen werden jedoch derzeit als Hintergrundanwendungen unter Windows Vista aufgefordert. Dieses Verhalten ist das Ergebnis eines fehlenden übergeordneten HWND. Um sicherzustellen, dass Windows Vista Ihre Anwendung als Vordergrundanwendung bestätigt, müssen Sie einen übergeordneten HWND mit einem ShellExecute-, CreateElevatedComObject -Aufruf (COM) oder einem Aufruf mit verwaltetem Code übergeben.

Der UAC-Erhöhungsmechanismus verwendet den HWND, um zu bestimmen, ob es sich bei der Erhöhung um eine Hintergrund- oder Vordergrunderweiterung handelt. Wenn die Anwendung als Hintergrundanwendung ermittelt wird, wird die Erhöhung auf der Taskleiste als blinkende Schaltfläche platziert. Der Benutzer muss wie bei jeder Anwendung, die den Vordergrundzugriff anfordert, auf die Schaltfläche klicken, bevor die Erhöhung fortgesetzt wird. Wenn der HWND nicht übergeben wird, tritt dies auf, auch wenn die Anwendung möglicherweise über einen Vordergrund verfügt.

Das folgende Codebeispiel veranschaulicht, wie HWND mit ShellExecute übergeben wird:

BOOL RunAsAdmin( HWND hWnd, LPTSTR lpFile, LPTSTR lpParameters )
{
    SHELLEXECUTEINFO   sei;
    ZeroMemory ( &sei, sizeof(sei) );

    sei.cbSize          = sizeof(SHELLEXECUTEINFOW);
    sei.hwnd            = hWnd;
    sei.fMask           = SEE_MASK_FLAG_DDEWAIT | SEE_MASK_FLAG_NO_UI;
    sei.lpVerb          = _TEXT("runas");
    sei.lpFile          = lpFile;
    sei.lpParameters    = lpParameters;
    sei.nShow           = SW_SHOWNORMAL;

    if ( ! ShellExecuteEx ( &sei ) )
    {
        printf( "Error: ShellExecuteEx failed 0x%x\n", GetLastError() );
        return FALSE;
    }
    return TRUE;
}

Im folgenden Codebeispiel wird veranschaulicht, wie HWND mit CreateElevatedComObject mithilfe des Höhenmonikers übergeben wird. Es wird davon ausgegangen, dass Sie COM bereits für den aktuellen Thread initialisiert haben. Weitere Informationen zum Höhenmoniker finden Sie in Schritt vier dieses Dokuments.

HRESULT CreateElevatedComObject(HWND hwnd, REFCLSID rclsid, REFIID riid, __out void ** ppv)
{
    BIND_OPTS3 bo;
    WCHAR  wszCLSID[50];
    WCHAR  wszMonikerName[300];

    StringFromGUID2(rclsid, wszCLSID, sizeof(wszCLSID)/sizeof(wszCLSID[0])); 
    HRESULT hr = StringCchPrintf(wszMonikerName, sizeof(wszMonikerName)/sizeof(wszMonikerName[0]), L"Elevation:Administrator!new:%s", wszCLSID);
    if (FAILED(hr))
        return hr;
    memset(&bo, 0, sizeof(bo));
    bo.cbStruct = sizeof(bo);
    bo.hwnd = hwnd;
    bo.dwClassContext  = CLSCTX_LOCAL_SERVER;
    return CoGetObject(wszMonikerName, &bo, riid, ppv);

BIND_OPTS3 ist neu in Windows Vista. Es wird von BIND_OPTS2 abgeleitet. Nachfolgend ist diese Definition gezeigt:

typedef struct tagBIND_OPTS3 : tagBIND_OPTS2
{
    HWND hwnd;
} BIND_OPTS3, * LPBIND_OPTS3;

Die einzige Ergänzung ist ein HWND-Feld, hwnd. Dieses Handle stellt ein Fenster dar, das zum Besitzer der Erhöhungsbenutzeroberfläche wird, wenn die Aufforderung zum sicheren Desktop aktiviert ist.

Im folgenden Codebeispiel wird veranschaulicht, wie HWND in verwaltetem Code übergeben wird, um sicherzustellen, dass übergeordnete Dialogfelder den HWND und dessen Verwendung kennen.

System.Diagnostics.Process newProcess = new System.Diagnostics.Process();
System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo("D:\SomeProgram.exe");
info.UseShellExecute = true;
info.ErrorDialog = true;
info.ErrorDialogParentHandle = this.Handle;
newProcess.StartInfo = info;
newProcess.Start();

Keine Aufforderung zur Erhöhung im Anmeldepfad des Benutzers

Anwendungen, die starten, wenn sich der Benutzer anmeldet und Erhöhungen erfordern, werden jetzt im Anmeldepfad blockiert. Ohne die Aufforderung von Anwendungen zur Erhöhung im Anmeldepfad des Benutzers zu blockieren, müssten sowohl Standardbenutzer als auch Administratoren bei jeder Anmeldung auf ein Dialogfeld "Benutzerkontensteuerung" reagieren. Windows Vista benachrichtigt den Benutzer, wenn eine Anwendung blockiert wurde, indem ein Symbol in der Taskleiste platziert wird. Der Benutzer kann dann mit der rechten Maustaste auf dieses Symbol klicken, um Anwendungen auszuführen, für die die Aufforderung zur Erhöhung blockiert wurde, während sich der Benutzer angemeldet hat. Der Benutzer kann verwalten, welche Startanwendungen deaktiviert oder aus dieser Liste entfernt werden, indem er auf das Taskleistensymbol doppelklicken.

Im Abschnitt Verweise dieses Dokuments finden Sie ein C++-Codebeispiel, das veranschaulicht, wie Sie den Aufgabenplaner verwenden, um die Erhöhung für den Benutzer auszuführen.

Verwenden Sie runas nicht zum Starten eines Prozesses mit erhöhten Rechten

Die Option Ausführen unter Windows XP und Windows Server 2003 wurde in Windows Vista durch Als Administrator ausführen im Kontextmenü (verfügbar, wenn Sie mit der rechten Maustaste auf eine ausführbare Datei klicken) ersetzt. Wenn ein Standardbenutzer die Option Als Administrator ausführen auswählt, wird dem Benutzer eine Liste der aktiven Administratoren auf dem lokalen Computer angezeigt. Standardbenutzer mit höheren Berechtigungen, z. B. Mitglieder der Gruppe Sicherungsoperatoren, werden ebenfalls angezeigt. Wenn ein Administrator die Option Als Administrator ausführen auswählt, fordert ein Dialogfeld Benutzerkontensteuerung den Benutzer sofort auf, den Vorgang fortzusetzen, bevor die Anwendung ausgeführt wird.

Benutzer müssen den Befehl runas an der Eingabeaufforderung verwenden, um eine Anwendung als anderen Benutzer auszuführen.

Wichtig Beachten Sie, dass runas nicht die Möglichkeit bietet, eine Anwendung mit einem Zugriffstoken mit erhöhten Rechten zu starten, unabhängig davon, ob es sich um einen Standardbenutzer mit Berechtigungen wie einen Sicherungsoperator oder einen Administrator handelt. Mit dem Befehl runas kann der Benutzer eine Anwendung mit unterschiedlichen Anmeldeinformationen starten. Die beste Methode zum Starten einer Anwendung mit einem anderen Konto besteht darin, die Aktion programmgesteuert mithilfe eines Diensts auszuführen und sich nicht darauf zu verlassen, dass der Benutzer die Komponente als einen anderen Benutzer ausführt. Wenn Ihr Programm den Befehl runas programmgesteuert verwendet, stellen Sie sicher, dass er nicht zum Starten eines Prozesses mit erhöhten Rechten vorgesehen ist.

Wenn Ihre Anwendung erfordert, dass der Benutzer Teile der Anwendung mit einem anderen Benutzerkonto ausführen muss, stellen Sie sicher, dass der Befehl runas mit der Eingabeaufforderungsoption verfügbar gemacht wird. In der folgenden Tabelle sind die verfügbaren Parameter für den Befehl runas aufgeführt.

Runas-Parameter

Parameter	BESCHREIBUNG
/noprofile	Gibt an, dass das Profil des Benutzers nicht geladen werden soll. Dies ermöglicht es der Anwendung, schneller zu laden, kann jedoch zu Fehlfunktionen bei einigen Anwendungen führen.
/Profil	Gibt an, dass das Profil des Benutzers geladen werden soll. Dies ist die Standardeinstellung.
/Env	Verwenden Sie die aktuelle Umgebung anstelle der des Benutzers.
/netonly	Verwenden Sie diesen Parameter, wenn die angegebenen Anmeldeinformationen nur für den Remotezugriff bestimmt sind.
/savecred	Verwenden Sie anmeldeinformationen, die zuvor vom Benutzer gespeichert wurden. Diese Option ist unter Windows XP, Home Edition nicht verfügbar und wird ignoriert.
/smartcard	Verwenden Sie diesen Parameter, wenn die anmeldeinformationen von einer intelligenten Karte stammen.
/user	Den Benutzernamen des Benutzers. Der Benutzername sollte in Form von USER\DOMAIN oder USER@DOMAIN angegeben werden.
/showtrustlevels	Zeigt die Vertrauensstufen an, die als Argumente für den Parameter /trustlevel verwendet werden können.
/Trustlevel	Eine der in /showtrustlevels aufgelisteten Ebenen.
Programm	Befehlszeile für eine ausführbare Datei.

Beispiel:

runas /noprofile /user:mymachine\Denise cmd

Hinweise:

• Geben Sie das Kennwort des Benutzers nur ein, wenn Sie dazu aufgefordert werden.
• Der Parameter /profile ist nicht mit dem Parameter /netonly kompatibel.
• Der Parameter /savecred ist nicht mit dem /smartcard-Parameter kompatibel.

Anforderungen für Konsolenanwendungen

Eine Konsolenanwendung stellt ihre Ausgabe im Konsolenfenster und nicht mit einer separaten Benutzeroberfläche dar. Wenn eine Anwendung für die Ausführung ein vollständiges Administratorzugriffstoken benötigt, muss diese Anwendung über ein Konsolenfenster mit erhöhten Rechten gestartet werden.

Für Konsolenanwendungen müssen Sie folgendes tun:

Markieren Sie, dass Ihre Anwendung "asInvoker"

Dazu können Sie das Manifest Ihrer Anwendung erstellen, in der Sie RequestedExecutionLevel == alsInvoker festlegen. Mit diesem Setup können Aufrufer aus Kontexten mit nicht erhöhten Rechten Ihren Prozess erstellen, sodass sie mit Schritt 2 fortfahren können.

Geben Sie eine Fehlermeldung an, wenn die Anwendung ohne vollständiges Administratorzugriffstoken ausgeführt wird.

Wenn die Anwendung in einer Konsole ohne erhöhte Rechte gestartet wird, sollte Ihre Anwendung eine kurze Nachricht senden und beenden. Die empfohlene Meldung lautet:

"Zugriff verweigert. Administratorberechtigungen sind erforderlich, um die ausgewählten Optionen zu verwenden. Verwenden Sie eine Administratoreingabeaufforderung, um diese Aufgaben auszuführen."

Die Anwendung sollte auch den Fehlercode ERROR_ELEVATION_REQUIRED zurückgeben, wenn der Start fehlschlägt, um die Skripterstellung zu erleichtern.

Anforderungen für Skripts

Skripts können als eine Gruppe von Anwendungen betrachtet werden, die in einer vordefinierten Reihenfolge ausgeführt werden und die Ergebnisse einer Anwendung in eine andere kanaliert werden.

Um die UAC-Kompatibilität Ihrer Skripts zu gewährleisten, überprüfen Sie die Logik Ihrer Skripts, und fügen Sie "Tests" hinzu, um sicherzustellen, dass Sie (oder die Person, die das Skript ausführt) über ausreichende Berechtigungen für diese Aufgabe verfügt, bevor Sie eine Aktion im Skript ausführen.

Anforderungen für Massenvorgänge

Wenn eine von Ihrer Anwendung ausgeführte Aufgabe aus Aktionen für mehrere Objekte besteht und einige von ihnen möglicherweise das Administratorzugriffstoken des Benutzers erfordern, zeigen Sie die Aufforderung zur Erhöhung beim ersten Mal an, wenn sie benötigt wird. Wenn der Benutzer die Erhöhung genehmigt, führen Sie die restlichen Aufgaben aus. Andernfalls beenden Sie den Batchvorgang. Dieses Verhalten wäre mit dem aktuellen Mehrfachauswahl-/Kopier-/Löschvorgang konsistent.

APIs, die beim Identifizieren eines Administrators helfen

• IsUserAnAdmin()
• GetTokenInformation()

Registrierungs-/Behandeln von Zugriffsberechtigungen, die sich inhärent zwischen Administratoren und Standardbenutzern unterscheiden

• MAXIMUM_ALLOWED
• KEY_WRITE
• DELETE (bei Anwendung auf Registrierungsschlüssel)
• Andere HKLM-ähnliche Schlüsselwörter (geöffnet mit MAXIMUM_ALLOWED auf XP):
• SHELLKEY_HKLM_EXPLORER
• SHELLKEY_HKLM_SHELL

Andere APIs, die auf HKLM-Registrierungswerte und Virtualisierung umgeleitet werden, werden angewendet.

• WritePrivateProfileString(,,,"system.ini");
• CheckSectionAccess("system.ini",...);

4. Neugestaltung der Benutzeroberfläche Ihrer Anwendung für UAC-Kompatibilität

Verwenden Sie die Richtlinien in diesem Abschnitt, um die Benutzeroberfläche Ihrer Anwendung für die UAC-Kompatibilität zu entwickeln. Wenn Sie diese Richtlinien bei der Entwicklung Ihrer Anwendung genau einhalten, wird sichergestellt, dass Ihre Anwendung eine konsistente und vorhersagbare Benutzererfahrung in Windows Vista bietet.

• Auswirkungen der UAC auf die Windows-Benutzeroberfläche
• Ziele der UAC-Benutzeroberfläche
• Eingabeaufforderung für Rechteerweiterungen
• Prozessablauf für die Benutzererfahrung
• Einstiegspunkte für rechte Rechte
• Implementierung der Benutzeroberfläche
• Wann sie der Benutzeroberfläche Ihrer Anwendung ein Schildsymbol hinzufügen sollen
• Wichtige Entscheidungen für Nur-Administrator-Anwendungen

Wichtig Durch einfaches Refraktorieren der Benutzeroberfläche Ihrer Anwendung werden die Anforderungen an die UAC-Kompatibilität nicht erfüllt. Die Kernfunktionen Ihrer Anwendung müssen den Windows Vista-Standardbenutzermodellanforderungen entsprechen. Diese Anforderungen wurden im vorherigen Schritt, Schritt 3: Neugestaltung der Funktionalität Ihrer Anwendung für UAC-Kompatibilität, ausführlich erläutert.

Auswirkungen der UAC auf die Windows-Benutzeroberfläche

Die größten und unmittelbarsten Auswirkungen auf die Benutzererfahrung werden administratoren spüren. Administratorbenutzer müssen nun die Berechtigung zum Ausführen von Verwaltungsaufgaben bereitstellen. In Verbindung damit erhalten Standardbenutzer jetzt die Möglichkeit, Administratoren aufzufordern, bestimmte administrative Aufgaben innerhalb der derzeit angemeldeten Sitzung zu erteilen.

Ziele der UAC-Benutzeroberfläche

Das allgemeine Ziel der UAC-Benutzeroberfläche besteht darin, Vorhersagbarkeit in der Benutzererfahrung zu ermöglichen:

• Für einen Administrator bedeutet dies, dass der Benutzer immer weiß, wann er die Berechtigung zum Ausführen einer Aufgabe mit erhöhten Rechten erteilen muss.

Dies ist die Anforderung des eigenen Administratorzugriffstokens des Benutzers, damit er vom Administrator erforderliche Änderungen vornehmen kann.

• Für Standardbenutzer bedeutet dies, dass sie wissen, wann sie:
  • Muss die Administratorgenehmigung (Home- und nicht verwaltete Umgebungen) für administrative Aufgaben bereitstellen.
  • ODER, wenn eine Aufgabe nicht abgeschlossen werden kann (verwaltete Umgebungen, in denen die Rechteerweiterung explizit nicht zulässig ist) und sich an den Helpdesk wenden muss

Entwurfsziele

Die folgende Liste enthält die UAC-Entwurfsziele.

Unnötige Rechteerweiterungen vermeiden

Benutzer sollten nur erhöhte Rechte ausführen müssen, um Aufgaben auszuführen, die ein Administratorzugriffstoken erfordern. Alle anderen Aufgaben sollten so entworfen werden, dass keine Erhöhung erforderlich ist. Vor Windows Vista-Software erfordert häufig unnötigerweise ein Administratorzugriffstoken, indem sie in die HKLM- oder HKCR-Registrierungsabschnitte oder in die Programmdateien oder Windows-Systemordner schreibt.

Berechenbar sein

Administratoren müssen wissen, welche Aufgaben Rechteerweiterung erfordern. Wenn sie die Notwendigkeit der Erhöhung nicht genau vorhersagen können, ist es wahrscheinlicher, dass sie eine Zustimmung für verwaltungstechnische Aufgaben erteilen, wenn sie dies nicht sollten. Standardbenutzer müssen wissen, welche Aufgaben in verwalteten Umgebungen von einem Administrator ausgeführt werden müssen oder überhaupt nicht ausgeführt werden können.

Minimaler Aufwand erforderlich

Aufgaben, die ein höher privilegiertes Zugriffstoken erfordern, sollten so konzipiert sein, dass eine einzelne Erhöhung erforderlich ist. Aufgaben, die mehrere Erhöhungen erfordern, werden schnell mühsam.

Wiederherstellen des Standardbenutzers

Sobald eine Aufgabe abgeschlossen ist, die eine höhere Ebene von Zugriffstoken erfordert, sollte das Programm in den Standardbenutzerzustand rückgängig machen.

Eingabeaufforderung für Rechteerweiterungen

Die Eingabeaufforderung zur Erhöhung basiert auf einer vorhandenen Windows-Benutzeroberfläche. Die Eingabeaufforderung zur Erhöhung zeigt Kontextinformationen zu der ausführbaren Datei an, die Rechte anfordert, und der Kontext ist unterschiedlich, je nachdem, ob die Anwendung Authenticode signiert ist oder nicht. Die Eingabeaufforderung zur Erhöhung wird in zwei Varianten angezeigt: der Zustimmungsaufforderung und der Anmeldeinformationsaufforderung.

Zustimmungsaufforderung

Die Zustimmungsaufforderung wird Administratoren im Admin Genehmigungsmodus angezeigt, wenn sie versuchen, eine Verwaltungsaufgabe auszuführen. Dies ist die Standardbenutzeroberfläche für Administratoren im genehmigungsmodus Admin und kann im lokalen Sicherheitsrichtlinien-Manager-Snap-In (secpol.msc) und mit Gruppenrichtlinie konfiguriert werden.

Die folgende Abbildung ist ein Beispiel für eine Zustimmungsaufforderung für die Benutzerkontensteuerung.

Abbildung 4. Benutzerkontensteuerung-Zustimmungsaufforderung

Anmeldeinformationsaufforderung

Die Anmeldeinformationsaufforderung wird Standardbenutzern angezeigt, wenn sie versuchen, eine Verwaltungsaufgabe auszuführen. Dies ist die Standardbenutzeroberfläche für Standardbenutzer und kann im lokalen Security Policy Manager-Snap-In (secpol.msc) und mit Gruppenrichtlinie konfiguriert werden.

Die folgende Abbildung zeigt ein Beispiel für eine Anmeldeanmeldeaufforderung für die Benutzerkontensteuerung.

Abbildung 5. Benutzerkontensteuerung-Anmeldeaufforderung

Zustimmungsrichtlinie für die Standardeingabeaufforderung für Rechteerweiterungen für Windows Vista

In der folgenden Tabelle wird der Standardeingabeaufforderungsstil für jeden Benutzerkontotyp in Windows Vista beschrieben.

Standardverhalten der Eingabeaufforderung für rechte Rechte

Benutzerkontotyp	Eingabeaufforderungseinstellung für rechte Rechte
Standardbenutzer	Aufforderung zur Eingabe von Anmeldeinformationen
Administratorkonto im Admin Genehmigungsmodus	Aufforderung zur Eingabe der Zustimmung

Prozessablauf für die Benutzerfreundlichkeit

Der Prozessablauf für die Benutzerfreundlichkeit der UAC besteht aus drei unterschiedlichen Komponenten:

1. Einstiegspunkt für erhöhte Rechte (z. B. ein Steuerelement oder link, das das Symbol für das UAC-Schild anzeigt).
2. Eingabeaufforderung zur Erhöhung (Eine Anforderung zur Zustimmung oder für Administratoranmeldeinformationen).
3. Prozess mit erhöhten Rechten.

Der folgende Beispielworkflow fasst zusammen, wie die vorherigen Komponenten zusammenhängen:

1. Ein Administrator in Admin Genehmigungsmodus meldet sich bei einem Windows Vista-Computer an.
2. Der Benutzer entscheidet sich dann, einen weiteren Administratorbenutzer für den Computer hinzuzufügen.
3. Der Benutzer klickt auf Start, klickt auf Systemsteuerung und klickt dann auf den Link im Abschnitt Sicherheit mit dem Titel Programm durch Windows-Firewall zulassen, der inline mit einem Schildsymbol angezeigt wird.
4. Es wird eine Zustimmungsaufforderung angezeigt, in der der Benutzer zur Genehmigung aufgefordert wird.
5. Der Benutzer klickt auf Weiter , und der Prozess mit erhöhten Rechten wird erstellt.
6. In den Windows-Firewalleinstellungen ändert der Benutzer die Windows-Firewalleinstellungen und klickt dann auf OK, wodurch der Prozess mit erhöhten Rechten beendet wird.
7. Der Benutzer arbeitet weiterhin als Standardbenutzer auf dem Computer.

Hinweis Höheneinstiegspunkte erinnern sich nicht an den Zustand (z. B. wenn Sie von einem abgeschirmten Ort oder einer Aufgabe zurück navigieren), und der Einstiegspunkt merkt sich nicht, dass eine Rechteerweiterung aufgetreten ist. Daher muss der Benutzer die Rechte erneut erhöhen, um die Aufgabe/den Link/die Schaltfläche erneut einzugeben.

Einstiegspunkte für rechte Rechte

Für Einstiegspunkte wird das Schildsymbol an bestimmte Steuerelemente (z. B. Schaltflächen, Befehlslinks, Hyperlinks) angefügt, um anzugeben, dass der nächste unmittelbare Schritt eine Erhöhung erfordert.

Symbol "Schild"

Das Schildsymbol ist die primäre Benutzeroberflächendekoration für einen UAC-Höhenpunkt. Dieses Symbol steht für sicherheitsbezogene Aktivitäten in Windows Vista und früheren Versionen von Windows, und diese Beziehung wird in Windows Vista fortgesetzt.

Die folgende Abbildung ist ein Beispiel für das Schildsymbol.

Abbildung 6. Schildsymbol

Das Schildsymbol spielt in allen drei Komponenten der UAC-Benutzeroberfläche eine wichtige Rolle.

Wenn Sie das System mit Windows Explorer anzeigen, wird jede Anwendung, die zum Anfordern eines Administratorzugriffstokens beim Starten markiert ist, automatisch mit einer Schild-Glyphe über dem Symbol versehen. Dadurch können Benutzer wissen, welche Anwendungen beim Starten die Erhöhung anfordern.

Eigenschaften des Shieldsymbols:

• Konsistente Darstellung über die gesamte Benutzeroberfläche der UAC.
• Gibt keinen visuellen Zustand wider (z. B. aktiv, mit der Maus zeigen, deaktiviert usw.).
• Erinnert sich nicht an den Zustand.

Es gibt drei konsistente Steuerelementstile, die ein Einstiegspunkt, der mit einem Schildsymbol gekennzeichnet ist, innerhalb der Benutzeroberfläche übernehmen kann:

• Schaltfläche "UAC"
• UAC-Link
• UAC-Befehlslink

Diese Stile gelten für alle Szenarien, in denen diese Benutzeroberflächenelemente angezeigt werden können, z. B. Assistenten, Eigenschaftenseiten, Systemsteuerung Framework, Explorer usw. Jede der Stile impliziert, dass sofort eine Eingabeaufforderung zur Erhöhung angezeigt wird, nachdem der Benutzer auf ein UAC-Benutzeroberflächensteuerelement geklickt hat.

Ein vierter Einstiegspunkt für die UAC-Benutzeroberfläche, die UAC-Symbolüberlagerung, wird ebenfalls in diesem Abschnitt erläutert. Ob eine ausführbare Datei eine Symbolüberlagerung empfängt oder nicht, wird vom Anwendungsentwickler nicht gesteuert. Windows Vista überlagert ein Schildsymbol für Anwendungssymbole für ausführbare Dateien, für dieExecutionLevel auf requireAdministrator festgelegt wurde.

Schaltfläche "UAC Shield"

Die UAC-Abschirmungsschaltfläche sollte in jeder Benutzeroberfläche-Schaltfläche verwendet werden, für die beim Drücken die Eingabeaufforderung zur Erhöhung erforderlich ist, um den Benutzer zur Genehmigung oder zur Eingabe von Anmeldeinformationen aufzufordern.

UAC-Abschirmschaltflächen können als Commitschaltflächen (z. B. Weiter in einem Assistenten) oder als Schaltfläche verwendet werden, um eine zusätzliche Benutzeroberfläche für Einstellungen anzuzeigen (z. B. Einstellungen ändern in einem Eigenschaftendialogfeld).

Die UAC-Abschirmschaltfläche besteht aus zwei Komponenten der Benutzeroberfläche:

• Schildsymbol
• Text label

Die UAC-Abschirmschaltfläche ist so verpackt, dass Entwickler sie anstelle einer normalen Schaltfläche verwenden können. Die UAC-Schaltfläche unterstützt auch das Rendern des Schildsymbols auf der linken oder rechten Seite der Textbeschriftung. Darüber hinaus haben Entwickler die Möglichkeit, das Schildsymbol auszublenden/anzuzeigen, während die UAC-Schaltfläche angezeigt wird.

Der folgende Screenshot ist ein Beispiel für eine UAC-Abschirmungsschaltfläche.

Abbildung 7. Schaltfläche "UAC-Abschirmung"

UAC-Link

Der UAC-Link sollte in jedem Benutzeroberflächenlink verwendet werden, für den beim Klicken die Eingabeaufforderung zur Erhöhung erforderlich ist, um den Benutzer zur Eingabe der Genehmigung oder der Anmeldeinformationen aufzufordern.

Ein UAC-Link besteht aus den folgenden Komponenten:

• Schildsymbol
• Hyperlinksteuerelement

Der UAC-Link ist nicht mit dem Schildsymbol gepackt, das ein Entwickler verwenden soll. Entwickler müssen die Schildsymbolressource abrufen und neben dem Link rendern.

Der folgende Screenshot ist ein Beispiel für einen UAC-Link.

Abbildung 8. UAC-Link

UAC-Befehlslink

Der UAC-Befehlslink sollte in jeder Benutzeroberflächesschaltfläche verwendet werden, für die beim Klicken die Eingabeaufforderung zur Erhöhung erforderlich ist, um den Benutzer zur Genehmigung oder zur Eingabe von Anmeldeinformationen aufzufordern.

UAC-Befehlslinks sollten nur als Commitschaltflächen verwendet werden (z. B. "Diese Option ausführen" in einem Dialogfeld).

Der UAC-Befehlslink besteht aus den folgenden Komponenten:

• Schildsymbol
• Standardkomponenten für Befehlslinks
• Linktext
• Text notieren

Der UAC-Befehlslink ist so gepackt, dass ein Entwickler anstelle eines normalen Befehlslinks einen UAC-Befehlslink verwenden kann. Der UAC-Befehlslink unterstützt das Rendern des Schildsymbols auf der linken oder rechten Seite des Befehlslinks.

Im Folgenden ist ein Beispiel für einen UAC-Befehlslink aufgeführt.

Abbildung 9. UAC-Befehlslink

Symbolüberlagerungen

Wenn eine ausführbare Datei in Windows Vista eine Erhöhung zum Starten erfordert, sollte das Symbol der ausführbaren Datei mit einem Schildsymbol "gestempelt" werden, um diese Tatsache anzuzeigen. Das Anwendungsmanifest der ausführbaren Datei muss "requireAdministrator" markieren, um die ausführbare Datei als vollständiges Administratorzugriffstoken festzulegen. Die Überlagerung des Schildsymbols wird auch automatisch auf ausführbaren Dateien platziert, für die gemäß der Heuristik der Installationsprogrammerkennung eine Erhöhung erforderlich ist. Beispielsweise erhält eine Datei mit dem Namen setup.exe automatisch eine Überlagerung des Schildsymbols, auch wenn die ausführbare Datei kein eingebettetes Anwendungsmanifest aufweist.

Die folgende Abbildung ist ein Beispiel für eine UAC-Symbolüberlagerung.

Abbildung 10. UAC-Symbolüberlagerung

Hinweis Anleitungen zum Erstellen und Einbetten eines Anwendungsmanifests mit einer ausführbaren Datei finden Sie im Abschnitt Erstellen und Einbetten eines Anwendungsmanifests mit Ihrer Anwendung dieses Dokuments.

Implementierung der Benutzeroberfläche

Schutzsymbolimplementierung und APIs

Dieser Abschnitt enthält vorläufige Informationen zu den Symbolen und APIs, die Entwicklern beim Migrieren oder Implementieren neuer Verwaltungsanwendungsfunktionen zur Verfügung stehen.

Implementierung und APIs des Shieldsymbols

Symbole	API
Shield	Benutzerressource: IDI_SHIELD
Schaltfläche	Button_SetElevationRequired(hwndButton)
Syslink/Link	Layout IDI_SHIELD neben syslink
Befehlslink	Laden IDI_SHIELD und festlegen als Befehlslinksymbol
Kontextmenü	Symbolunterstützung in DefCM für statische Befehle

Hinzufügen eines Schildsymbols zur Benutzeroberfläche

Fügen Sie ein kleines Symbol hinzu:

#include <shellapi.h>
SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_SMALLICON, &sii);
hiconShield  = sii.hIcon;

Fügen Sie ein großes Symbol hinzu:

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_LARGEICON, &sii);
hiconShield  = sii.hIcon;

Fügen Sie ein Symbol mit benutzerdefinierter Größe hinzu:

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICONLOCATION, &sii);
hiconShield  = ExtractIconEx(sii. ...);

Hinweis Im Allgemeinen sollten Sie das Schildsymbol nicht direkt zur Benutzeroberfläche hinzufügen. Es wird empfohlen, eine der fortgehenden Methoden zum Einbetten des Schildsymbols in einem Steuerelement zu verwenden. Darüber hinaus stellt das hinzufügen eines Schildsymbols in Ihrer Benutzeroberfläche keine UAC-Kompatibilität sicher. Sie müssen auch die gesamte Benutzeroberfläche Ihrer Anwendung refraktorieren (einen requestedExecutionLevel hinzufügen, alle Standardbenutzerfehler beheben und sicherstellen, dass die Benutzeroberfläche benutzerfreundlich und UAC-kompatibel ist).

Hinzufügen eines Schildsymbols zu einer Schaltfläche

Das Standardtastensteuerelement (PUSHBUTTON, DEFPUSHBUTTON) wurde erweitert, sodass Sie ein Symbol zusammen mit dem angezeigten Text hinzufügen können, ohne dass die BS_ICON oder BS_BITMAP Stile festgelegt werden müssen.

Rufen Sie zum Anzeigen des Schildsymbols das folgende Makro (definiert in commctrl.h) auf:

Button_SetElevationRequiredState(hwndButton, fRequired);

Hinweis : hwndButton ist der HWND der Schaltfläche. fRequired bestimmt, ob das UAC-Schildsymbol (TRUE) oder ausblenden (FALSE) angezeigt werden soll.

Hinzufügen eines Schildsymbols zu einer Windows Installer-Schaltfläche

Windows Installer-Dialogfelder, die mithilfe der internen Tabellenunterstützung erstellt wurden, können der letzten Schaltfläche der Dialogsequenz der Benutzeroberfläche ein Schild hinzufügen, indem sie das ElevationShield-Attribut für das Steuerelement festlegen.

Hinzufügen eines Schildsymbols zu einer Schaltfläche "Weiter" in einem Assistenten

Wichtig Beim Anzeigen des UAC-Schildsymbols wird die Schaltfläche "Weiter" nur in AeroWizards (PSH_AEROWIZARD) unterstützt.

Verwenden Sie den folgenden Code, um das Schildsymbol auf der Schaltfläche "Weiter" für eine bestimmte Seite in einem AeroWizard anzuzeigen:

case WM_NOTIFY:
    if (reinterpret_cast<NMHDR*>(lParam)->code == PSN_SETACTIVE)
    {
        // Show next button
        //
        // Note new wParam flag -- when PSWIZBF_ELEVATIONREQUIRED flag
        // is specified, it indicates that the next page will require
        // elevation, so if the next button is being shown, show it as
        // a shield button.

        SendMessage(GetParent(hwndDlg), 
                    PSM_SETWIZBUTTONS, 
                    PSWIZBF_ELEVATIONREQUIRED, 
                    PSWIZBF_NEXT);

        // return 0 to accept the activation
        SetWindowLong(hwndDlg, DWLP_MSGRESULT, 0); 
    }
    break;

Hinzufügen eines Schildsymbols zu einer Schaltfläche für das Aufgabendialogfeld

Vorsicht Eine Schaltfläche für das Aufgabendialogfeld sollte niemals ein UAC-Schildsymbol erfordern. Es wird erwartet, dass die Aktion "Drücken" auf einer Taskdialogschaltfläche commit/cancel und das Aufgabendialogfeld geschlossen wird. Es wäre seltsam, wenn eine solche Schaltfläche dem Benutzer dann die Eingabeaufforderung zur Erhöhung anzeigt.

Erhöhen eines modalen Dialogfelds

Verwenden Sie den Höhenmoniker, um das COM-Objekt zu erhöhen, das das modale Dialogfeld darstellt.

Aufgaben:

• Verschieben Sie das Dialogfeld in ein COM-Objekt.
• Machen Sie eine ShowDialog()-Methode verfügbar.
• Verwenden Sie die API CreateElevatedComObject(), um das COM-Objekt zu erstellen und ShowDialog() aufzurufen.

Diese API führt eine instance des COM-Objekts als Administrator aus, nachdem Sie den Erhöhungsprozess durchlaufen haben.

Hinweis Eine Version dieser API, die komplizierter aufgerufen werden kann, ist verfügbar. Eine vereinfachte Version wird in einer späteren Version von Windows Vista verfügbar sein.

Richtlinien für Schulung und Unterstützung für Benutzer

Wenn eine Benutzeroberfläche neu berechnet und hinter einer Schaltfläche platziert wurde, sollten ISVs auswerten, ob eine Änderung des Schaltflächennamens gerechtfertigt ist. Microsoft rät dringend davon ab , Erweitert als Schaltflächenbezeichnung für Rechteerweiterungsaufgaben zu verwenden. Verwenden Sie stattdessen aussagekräftigere und verständlichere Bezeichnungen wie Einstellungen ändern oder einen Begriff, der angibt, was sich hinter der Schaltfläche befindet.

Richtlinien für die Benutzeroberfläche nur für Administratoren

Wenn eine Anwendung immer von einem Administrator gestartet wird, müssen Sie keine zusätzlichen Schutzschilde auf der Benutzeroberfläche der Anwendung hinzufügen. Dies liegt daran, dass die Anwendung mit erhöhten Rechten versehen ist und alles, was sie tut, mit erhöhten Rechten versehen wird und daher keine weitere Erhöhung benötigt.

Hinweis Wenn Sie links zu einer anderen Administratorbenutzeroberfläche in Ihrer Benutzeroberfläche für Administratoren haben, wird die Benutzeroberfläche mit erhöhten Rechten gestartet. Daher müssen Sie keine Schutzschilde in einer Anwendung einfügen, die ausschließlich administrativ ist.

Wann das Schildsymbol zur Benutzeroberfläche Ihrer Anwendung hinzugefügt werden soll

Eine Administrative Choice-Anwendung

Ein Prozess mit erhöhten Rechten oder EIN COM-Objekt

Die anfängliche Anwendung wird gestartet, ohne dass eine Erhöhung erforderlich ist. Die Elemente auf der Benutzeroberfläche, die ein Administratorzugriffstoken erfordern, werden mit einem Schildsymbol als Identifikation versehen. Diese Dekoration gibt dem Benutzer an, dass für die Verwendung dieses Features eine Administratorgenehmigung erforderlich ist. Wenn die Anwendung erkennt, dass eine dieser Schaltflächen ausgewählt wurde, stehen die folgenden beiden Optionen zur Verfügung.

• Die Anwendung startet ein zweites Programm mit ShellExeucute(), um die Verwaltungsaufgabe auszuführen. Dieses zweite Programm wäre mit einem requestedExecutionLevel von requireAdministrator gekennzeichnet, wodurch der Benutzer zur Genehmigung aufgefordert wird. Dieses zweite Programm wird mit einem vollständigen Administratorzugriffstoken ausgeführt und kann die gewünschte Aufgabe ausführen.
• Die Anwendung startet ein COM-Objekt mithilfe von CreateElevatedComObject(). Diese API würde das COM-Objekt nach der Genehmigung mit einem vollständigen Administratorzugriffstoken starten, und dieses COM-Objekt könnte die gewünschte Aufgabe ausführen.

Diese Methode bietet die größte Benutzererfahrung und ist die bevorzugte Methode für den Umgang mit verwaltungstechnischen Funktionen.

In der folgenden Liste werden die Anforderungen für einen Prozess oder ein COM-Objekt mit erhöhten Rechten aufgeführt:

• Die Systemsteuerung sollte die Schilddekoration und die erforderliche Architektur implementieren.
• Der Entwickler muss festlegen, wo das Schild auf der Benutzeroberfläche angezeigt werden soll.
• Der Entwickler muss die Architekturarbeit ausführen, um die Geschäftslogik in ein COM-Objekt vom Benutzeroberflächenobjekt zu trennen.
• Der Entwickler muss den UAC-Erhöhungsprozess aufrufen, wenn das OnClick-Ereignis für das Schildsymbol erkannt wird.

In der folgenden Liste werden die Vorteile des ordnungsgemäßen Entwerfens eines Prozesses oder COM-Objekts mit erhöhten Rechten erläutert:

• Dies ist die beste Allgemeine Benutzererfahrung für beide Benutzertypen. Die Benutzeroberfläche wird gestartet, für jeden sichtbar, und alle UAC-Funktionen auf dieser Benutzeroberfläche sind für jeden zugänglich. Nur wenn eine Administratoraufgabe erforderlich ist, versucht der Benutzer, zum Abschließen der Aufgabe erhöhte Rechte zu erhöhen.
• Wenn Sie diese Arbeit jetzt ausführen, werden Sie in Zukunft vollständig UAC-konform machen.
• Die Trennung zwischen Benutzeroberfläche und COM ist eine gute Architekturpraxis.

Wenn Sie auf ein Schildsymbol klicken, startet die Anwendung entweder ein Programm mit erhöhten Rechten oder ein COM-Objekt mit erhöhten Rechten, um die Aufgabe auszuführen.

Nur Administratoranwendung

In diesem instance erfordert der anfängliche Start der Anwendung eine Administratorgenehmigung. Diese Methode wird als "prompt before launch" bezeichnet. Nach dem Start wird die Anwendung mit einem vollständigen Administratorzugriffstoken ausgeführt und kann daher die gewünschten Administrativen Aufgaben ausführen. Diese Methode ist die geringste Arbeit für den Entwickler. Das Manifest der Anwendung ist mit dem requestedExecutionLevel von requireAdministrator gekennzeichnet.

Wichtig Dies erfordert zwar den geringsten Aufwand für den Entwickler, aber beachten Sie, dass Administratoren genau wie bei anderen administrativen Anwendungen in Windows Vista eine Erhöhung ausführen müssen, um diese Anwendung verwenden zu können, und dass Standardbenutzer die Anwendung nicht verwenden können.

In der folgenden Liste werden die Anforderungen für Nur-Administrator-Anwendungen aufgeführt:

• Das Anwendungsmanifest sollte eine requestedExecutionLevel-Markierung enthalten, die auf requireAdministrator festgelegt ist.
• Der Benutzer wird zur Administratorgenehmigung aufgefordert, bevor Windows die Anwendung mit einem vollständigen Administratorzugriffstoken startet.

In der folgenden Liste werden die Vorteile einer ordnungsgemäßen Entwicklung einer Nur-Administrator-Anwendung erläutert:

• Das Betriebssystem muss nicht erraten, ob es sich bei Ihrer Setupanwendung um eine Administrative Anwendung handelt.
• Standardbenutzer erhalten automatisch einen Hinweis, dass es sich bei dem Vorgang um einen Verwaltungsvorgang handelt. Wenn Beispielsweise das Symbol für eine Anwendung mit der Kennzeichnung requireAdministrator angezeigt wird, enthält das Symbol ein Schild, das in das Symbol eingebettet ist.
• Wenn Sie Ihre Anwendung unter Windows Vista als erforderlichAdministrator markieren, wissen Sie, dass sie nach dem Start mit einem vollständigen Administratorzugriffstoken ausgeführt wird. Benutzer müssen erhöhte Rechte festlegen, um die Anwendung auszuführen (entweder als Administrator im Genehmigungsmodus Admin oder mithilfe von Als Administrator ausführen).

Hinweis Wenn sie eine Anwendung "requireAdministrator" markieren, wird die Anwendung NICHT automatisch erhöht. Der Benutzer muss zum Starten der Anwendung weiterhin zustimmungsergeben. Es gibt keine Möglichkeit, eine Anwendung in Windows Vista so zu markieren, dass sie im Hintergrund erhöht wird.

Die folgende Liste enthält die Punkte, die beim Entwerfen einer Anwendung mit administratorrechten Gesichtspunkten berücksichtigt werden:

• Diese Benutzeroberfläche bedeutet, dass alle Benutzer eine Eingabeaufforderung zur Erhöhung (entweder die Anmeldeinformationsaufforderung oder die Zustimmungsaufforderung) sehen, bevor die Benutzeroberfläche überhaupt sichtbar ist. Das bedeutet auch, dass niemand einfach die aktuellen Einstellungen anzeigen kann, bis nach der Authentifizierung mit Administratoranmeldeinformationen
• Wenn Sie "requireAdministrator" in einer Setupanwendung markieren, sollten Sie beachten, dass sich der Benutzer, der das Setup ausführt, von dem Benutzer unterscheidet, der die Anwendung verwenden kann. Daher sollten Sie HKEY_CURRENT_USER (HKCU) und andere benutzerspezifische Einstellungen, z. B. das Schreiben in das Benutzerprofil, während Der Verwaltungseinrichtung nicht ändern.

Wichtig Sie müssen davon ausgehen, dass sich der Benutzer, der die Administratoranwendung ausführt, vom normalen Benutzer auf dem Computer unterscheidet.

Ausführbare Dateien, die ein Administratorzugriffstoken erfordern, werden mit einer Schildsymbolüberlagerung gekennzeichnet.

Gemischte Anwendung

Eine gemischte Anwendung kann von Benutzern ausgeführt werden– von allen Benutzern des Systems (Standardbenutzer, Administratoren im Admin Genehmigungsmodus und die dazwischen betreffenden Benutzer wie Sicherungsoperatoren). Dies ist auch eine "Eingabeaufforderung vor dem Start"-Anwendung. Die Anwendung wird mit dem Zugriffstoken des Aufrufers ausgeführt und für Standardbenutzer normal gestartet (keine Aufforderung zur Erhöhung). Das Programm muss dann sein Verhalten zur Laufzeit ändern, um die Features zu deaktivieren, die dem Benutzer basierend auf dem erhaltenen Administratorzugriffstoken nicht zur Verfügung stehen.

Eine gemischte Anwendung verfügt nach dem Start nicht über die Möglichkeit, zusätzliche Administratorrechte zu erhalten. Daher bietet sie nicht die Flexibilität des zuvor beschriebenen Prozesses oder der COM-Objektmethode mit erhöhten Rechten. Dies ist besonders nützlich für Anwendungen, die ein Zugriffstoken benötigen, das über dem eines Standardbenutzers liegt, aber weniger als ein vollständiger Administrator.

Beispielsweise ist die Microsoft Management Console (MMC) als höchste Verfügbar gekennzeichnet. Wenn ein wahrer Standardbenutzer die MMC ausführt, wird MMC als Standardbenutzeranwendung gestartet, ohne dass ein Erhöhungsversuch oder eine Aufforderung erfolgt. Wenn der Benutzer ein Benutzer mit geteiltem Token ist, z. B. ein Administrator im genehmigungsmodus Admin oder ein Sicherungsoperator, fordert das Betriebssystem den Benutzer auf, die Zustimmung zum Starten von MMC mit der "höchsten" verfügbaren Berechtigung des Benutzers zu erhalten. Im Fall eines Standardbenutzers, der über Backup Operator-Berechtigungen verfügt, wird MMC nach der Erhöhung mit Standardbenutzer + Sicherungsoperator gestartet, aber nicht mehr. Wenn ein Administrator MMC startet, wird MMC nach der Erhöhung als vollständige Administratoranwendung ausgeführt.

Der Vorteil einer ordnungsgemäßen Entwicklung einer gemischten Anwendung besteht darin, dass die Anwendung für alle Benutzer des Systems verfügbar ist, obwohl einige Funktionen möglicherweise deaktiviert sind.

Die folgende Liste enthält ausführliche Überlegungen zum Entwerfen gemischter Anwendungen:

• Der Entwickler muss das Verhalten der Anwendung basierend auf den vom Benutzer verfügbaren administratorrechten Windows-Berechtigungen und Benutzerrechten dynamisch ändern.
• Der Standardbenutzer wird daran gehindert, jemals auf administrativer Ebene auf der Benutzeroberfläche zu agieren. Es ist nicht möglich, die Rechte einzufordern, sobald das Programm ausgeführt wird (die Administratoren müssen vor dem Öffnen der Benutzeroberfläche die Rechte erhöhen).

Hinweis Es gibt eine Problemumgehung für den vorherigen Aufzählungszeichen. Ein Administrator kann eine Eingabeaufforderung mit erhöhten Rechten auf dem Computer des Standardbenutzers starten und die Anwendung über die Eingabeaufforderung ausführen. Klicken Sie beispielsweise mit der rechten Maustaste auf die Eingabeaufforderung, wählen Sie Als Administrator ausführen aus, und geben Sie dann "applicationname.exe" in die Eingabeaufforderung ein.

Die Benutzeroberfläche wird zwischen dem Standardbenutzer und dem Administrator im Admin Genehmigungsmodus verzweigt.

Beispiel für eine gemischte Anwendung: Sicherungsanwendung

Die Anwendung kann von einem Mitglied der Gruppe Sicherungsoperatoren gestartet werden. Das Programm überprüft dann, ob die höchste Ebene von Windows-Administratorrechten und Benutzerrechten, die dem Benutzer zur Verfügung stehen, für den Betrieb des Programms ausreicht. Weitere Informationen zum Programmstartverhalten finden Sie im Abschnitt Anwendungsmanifestkennzeichnung und Anwendungsstartverhalten dieses Dokuments.

Wichtige Entscheidungen beim Entwerfen von Administrator-Only Anwendungen

Back-End-Geschäftsobjekte

Dieser Abschnitt bietet eine Übersicht über die drei Modelle, die entwickler beim Entwickeln einer Administrativen Anwendung auswählen können, die die beste Benutzererfahrung bietet.

• Das Admin Broker-Modell
• Das Back-End-Dienstmodell
• Das Admin COM-Objektmodell

Admin Brokermodell

Im Admin Broker-Modell ist die Anwendung in zwei unabhängige ausführbare Dateien unterteilt: eine ausführbare Standardbenutzerdatei und eine ausführbare Administratordatei. Der Entwickler markiert das Standardbenutzerprogramm mithilfe eines Anwendungsmanifests mit einem requestedExecutionLevel von asInvoker und markiert das Verwaltungsprogramm mit einem requestedExecutionLevel von requireAdministrator. Ein Benutzer startet zuerst das Standardbenutzerprogramm. Wenn der Benutzer versucht, einen Vorgang auszuführen, von dem das Standardbenutzerprogramm weiß, dass ein vollständiges Administratorzugriffstoken erforderlich ist, führt er eine ShellExecute() aus und startet das Verwaltungsprogramm. Die Windows ShellExecute()-API untersucht das Manifest und fordert die Genehmigung des Benutzers an, bevor die Anwendung mit dem vollständigen Administratorzugriffstoken des Benutzers ausgeführt wird. Das Verwaltungsprogramm kann dann die administrativen Aufgaben ausführen.

Hinweis Das ausführbare Administratorprogramm kann die prozessübergreifende Kommunikation mit einer ausführbaren Standardbenutzerdatei mithilfe von freigegebenem Arbeitsspeicher, lokalem RPC oder Named Pipes ermöglichen. Wenn das Verwaltungsprogramm die Kommunikation mit der ausführbaren Standardbenutzerdatei aktiviert, muss der Entwickler eine gute Sicherheitspraxis verwenden, um alle Eingaben aus dem Programm mit niedrigeren Berechtigungen zu überprüfen.

Hinweis Es gibt keinen Kommunikationskanal zwischen den beiden Programmen, sobald das zweite Programm gestartet wird.

Die folgenden Listendetails werden für das Administratorbrokermodell verwendet:

• Assistenten: Wenn der Hardware-Assistent erkennt, dass der erforderliche Treiber nicht auf dem Computer installiert ist oder sich am genehmigten Standort des Unternehmens befindet, benötigt er eine Anwendung mit erhöhten Rechten, die einen Treiber in den Computerspeicher verschieben kann.
• Autorun.exe aufrufen Setup.exe: Wenn Sie zum ersten Mal eine Spiel-CD einlegen, muss die Anwendung von autorun.exe eingerichtet werden. Beim zweiten Einlegen der CD besteht der Standardvorgang darin, das Spiel abzuspielen.

Ein Vorteil der Verwendung des Administratorbrokermodells ist, dass es wahrscheinlich der einfachste Mechanismus ist, der für den Entwickler implementiert werden kann.

Die folgende Liste enthält einige Nachteile bei der Verwendung des Admin Brokermodells:

• Die Übergänge von der Anwendung zur Anwendung können für den Benutzer verwirrend sein. Es kann schwierig sein, den Benutzer darüber zu erfahren, warum eine neue Anwendung auf dem Monitor "aufgetaucht" wird.
• Darüber hinaus ist der Zustand schwieriger zwischen diesen beiden Anwendungen zu übergeben. Beispielsweise würden Sie dies nicht verwenden, um den Zustand zwischen einer Standardmäßigen Benutzersteuerung (CPL) und deren Administrator-Entsprechung zu übergeben, nur um derselben CPL administrative und nicht administrative Funktionen zu ermöglichen. Die Standardbenutzer-CPL müsste ihren Zustand irgendwo speichern.
• Häufig gibt es viel replizierten Code, wenn die Funktionalität auf zwei Programme aufgeteilt wird.

Um das Administratorbrokermodell zu implementieren, erstellen Sie zwei Programme (einen Standardbenutzer und ein Administrator), markieren Sie sie mit dem entsprechenden Manifest requestedExecutionLevel, und starten Sie das Verwaltungsprogramm über das Standardbenutzerprogramm mithilfe von ShellExecute().

Das Back-End-Dienstmodell

Im Back-End-Dienstmodell ist die Anwendung erneut in zwei unabhängige ausführbare Dateien unterteilt: eine ausführbare Standardbenutzerdatei, die dem Benutzer die Benutzeroberfläche bereitstellt, und einen Back-End-Dienst, der auf dem System ausgeführt wird. Microsoft Remote Procedure Call (RPC) wird für die Kommunikation zwischen den beiden verwendet. Die Front-End-Anwendung ist mit einem requestedExecutionLevel von asInvoker gekennzeichnet, und der Back-End-Dienst wird als SYSTEM ausgeführt. Die Kommunikation zwischen der Anwendung und dem Back-End-Dienst erfolgt über RPC.

Eine Verwendung für das Back-End-Dienstmodell besteht darin, Programme zu steuern, die sich auf das System auswirken könnten, z. B. Antivirenprogramme oder Anti-Spyware). Die Front-End-Anwendung stellt die Mittel bereit, mit denen die angemeldeten Benutzer- und Steuerungsaspekte des Diensts verwendet werden.

Ein wesentlicher Vorteil der Verwendung des Back-End-Dienstmodells ist, dass keine Aufforderung zur Erhöhung erforderlich ist.

Die folgende Liste enthält einige Nachteile bei der Verwendung des Back-End-Dienstmodells:

• Der Dienst muss die Arten von Aktivitäten einschränken, die die Front-End-Anwendung anweisen kann. Ein Antivirendienst kann es beispielsweise einem Standardbenutzer ermöglichen, eine Überprüfung des Systems zu initiieren, aber nicht die Echtzeit-Virenüberprüfung zu deaktivieren.
• Das Hinzufügen eines unnötigen Diensts zum System kann sich auf das gesamte System auswirken. Stellen Sie sicher, dass Ihr Dienst für Ihre Windows Vista-Implementierung wirklich erforderlich ist und dass der Dienst ordnungsgemäß entworfen wurde.

Um das Back-End-Dienstmodell zu implementieren, erstellen Sie eine Front-End-Standardanwendung für Benutzer und einen Back-End-Dienst. Installieren Sie den Dienst während der Produktinstallationszeit im System.

Das Admin COM-Objektmodell

Dieses Modell ist hier enthalten, wurde aber zuvor in diesem Dokument ausführlich erläutert. Das COM-Objektmodell des Administrators ermöglicht dynamische Verwaltungserweiterungen, um bestimmte Vorgänge innerhalb einer Anwendung oder Systemsteuerung auszuführen.

Ein wichtiger Vorteil für die Verwendung des COM-Objektmodells für Administratoren ist, dass es die beste Benutzeroberfläche für den Benutzer bietet.

Die folgende Liste enthält einige Nachteile bei der Verwendung des COM-Objektmodells für Administratoren:

• Erfordert die meisten Arbeit für den Entwickler, da jedes Anwendungsfeature auf Administratorfunktionen ausgewertet und getestet werden muss und diese Funktion von einem Back-End-COM-Objekt bereitgestellt werden muss.
• Der Benutzer muss die Genehmigung für die Erhöhung bereitstellen.
• Die resultierende "Einheit" der Standardbenutzeranwendung und Admin Com-End-Objekts ist jetzt "drivable" und wird nicht durch UIPI und andere Isolationsmechanismen geschützt.

Um das COM-Objektmodell des Administrators zu implementieren, erstellen Sie eine Front-End-Standardanwendung für Benutzer, und starten Sie COM-Objekte mit erhöhten Rechten, um Verwaltungsaufgaben auszuführen.

5. Neugestaltung des Installationsprogramms Ihrer Anwendung

Die folgenden bewährten Methoden gelten für gut verhaltene Anwendungsinstallationen in einer Windows Vista- oder UAC-Umgebung. Es handelt sich dabei aber nicht um eine vollständige Liste. Eine ausführlichere Erläuterung der Logoanforderungen für Windows Vista, einschließlich der UAC-Anforderungen, finden Sie in der Dokumentation zum Windows Vista-Logo und in der ausführlichen Version des neuesten Entwurfs des Dokuments zu Den Richtlinien für das Windows Vista-Logo.

Verwenden Sie diese Anforderungen bei der Neugestaltung Ihrer Anwendung.

Verwenden Sie Windows Installer 4.0 für Ihr Setuppaket.

Viele der folgenden Anforderungen sind bereits in die Windows Installer-Engine integriert. Die Verwendung von Windows Installer für Ihr Setuppaket unterstützt Sie bei den folgenden Windows Vista-Installationsanforderungen.

Verwenden Sie versionierte Dateien, und führen Sie während der Installation kein Downgrade von Dateien durch.

Die Dateiversionsverwaltung stellt sicher, dass der endgültige Installationsstatus korrekt ist, wenn das Setup abgeschlossen ist. Ohne Dateiversionen sind spezielle Handarbeiten erforderlich, um sicherzustellen, dass Ihre Installation für viele verschiedene Installationsszenarien ordnungsgemäß funktioniert. Beim Installieren von Dateien mit Versionierung sollte außerdem kein Downgrade von Versionen ausgeführt werden, insbesondere nicht freigegebene Dateien. Das Herabstufen von Versionen kann für Ihre Anwendung gut sein, verursacht jedoch häufig Probleme mit anderen Anwendungen. Durch das Deklarieren der richtigen Versionen Ihrer Dateien in Ihrem Windows Installer-Paket unterstützt Windows Installer dieses Feature nativ.

Installieren Sie Anwendungen, und speichern Sie Daten pro Benutzer an verschiedenen Speicherorten.

Anwendungen sollten in einem Ordner unter dem Verzeichnis Programme installiert werden. Um dies zu konfigurieren, können Sie die ProgramFilesFolder-Eigenschaft in der Direcotry-Tabelle Ihres Windows Installer-Pakets verwenden. Die Konfigurationsdaten pro Benutzer sollten in Dateien unter dem Verzeichnis \Users\username\AppData oder in Registrierungsschlüsseln unter dem HKCU-Stamm gespeichert werden. Benutzerdaten, Vorlagen und von der Anwendung erstellte Dateien verfügen alle über geeignete Speicherorte im Unterverzeichnis \Users\username. Obwohl dies in der Vergangenheit nicht erzwungen wurde, führen viele Benutzer Programme mit einem vollständigen Administratorzugriffstoken aus, bei Anwendungen, die Informationen nicht am richtigen Speicherort platzieren, wahrscheinlich fehl. Dies gilt insbesondere, wenn die Virtualisierung deaktiviert ist.

Verwenden Sie einen konsistenten Ordnerspeicherort, wenn Sie freigegebene Komponenten installieren.

Freigegebene Komponenten sollten mithilfe der CommonFilesFolder-Eigenschaft in der Directory-Tabelle Ihres Windows Installer-Pakets im Verzeichnis Common Files installiert werden. Die Verwaltung freigegebener Komponenten kann problematisch sein und sollte nach Möglichkeit vermieden werden. Ein Entwickler, der freigegebene Komponenten nicht konsistent installiert, kann am Ende COM-Registrierungsinformationen (Component Object Model) erhalten, die auf ältere Komponenten verweisen. Windows Installer Merge Modules (MSM) wurde speziell entwickelt, um freigegebene Komponenten konsistent im Kontext aller Pakete zu installieren, die die freigegebene Komponente installieren. Andere Probleme treten auf, wenn Änderungen von freigegebenen Komponenten dazu führen, dass vorhandene Anwendungen fehlschlagen. Eine Möglichkeit, dieses Problem zu beheben, besteht darin, Dass Anwendungen mithilfe von Microsoft .NET- oder Win32-Assemblys mit versionierten Assemblys erstellt werden.

Führen Sie ein Setuprollback aus, wenn eine Installation fehlschlägt.

Teilweise installierte Software kann auf seltsame und unerwartete Weise fehlschlagen, was zu einer schlechten Benutzererfahrung führt. Windows Installer unterstützt dieses Rollbackfeature.

Installieren Sie keine Anwendungsverknüpfungen im gesamten Profil des Benutzers.

Obwohl es verlockend sein kann, ihr Anwendungssymbol jedem bekannten Belichtungspunkt in Windows hinzuzufügen, führt dies häufig dazu, dass Benutzer das Gefühl haben, die Kontrolle über ihren Computer verloren zu haben. Benutzer sind dann gezwungen, diese Verknüpfungen manuell zu entfernen, um dem Computer ein gewünschtes Erscheinungsbild zurückzugeben. Wenn der Entwickler Dem Desktop Symbole hinzufügen möchte, bitten Sie den Benutzer während der Installation um die Berechtigung. Windows Vista behandelt die Auffindbarkeit von Anwendungen nach der Installation und die zuletzt verwendete Anwendungsliste, um großes Durchlaufen des Startmenüs zu vermeiden.

Vermeiden Sie das automatische Starten von Hintergrundanwendungen bei der Benutzeranmeldung.

Obwohl es möglich ist, während der Installation Programme zur Startgruppe oder zum Ausführen des Schlüssels hinzuzufügen, erhöht dies den Mehraufwand für das System. Im Laufe der Zeit kann die Leistung des Systems des Benutzers erheblich beeinträchtigt werden. Wenn Ihre Anwendung von einer Hintergrundaufgabe profitieren kann, lassen Sie sie benutzerkonfigurierbar. Außerdem kann das Hinzufügen einer Startaufgabe über den HLKM-Ausführungsschlüssel verhindern, dass ein Standardbenutzerkonto das Verhalten in Zukunft ändert. Wenn der Benutzer möchte, dass eine Anwendung zur Anmeldezeit gestartet wird, speichern Sie die Informationen im Ausführungsschlüssel von HKCU.

Befolgen Sie sauber Entfernungslogik.

Ein Benutzer kann eine Anwendung nicht nur entfernen, um Speicherplatz freizugeben, sondern auch, um den Computer in seinen Zustand zurückzugeben, bevor die Anwendung installiert wird. Der Deinstallationsvorgang der Anwendung sollte die Anwendung ordnungsgemäß und vollständig entfernen. Windows Installer verwendet standardmäßig die folgenden Regeln:

• Alle nicht freigegebenen Anwendungsdateien und -ordner.
• Freigegebene Anwendungsdateien, deren Verweisanzahl (Refcount) null erreicht.
• Registrierungseinträge, mit Ausnahme von Schlüsseln, die möglicherweise von anderen Programmen freigegeben werden.
• Alle Verknüpfungen aus dem Startmenü, die die Anwendung zum Zeitpunkt der Installation erstellt hat.
• Benutzereinstellungen können als Benutzerdaten betrachtet und zurückgelassen werden, aber es sollte eine Option zur vollständigen sauber Entfernung enthalten sein.
• Das Deinstallationsprogramm selbst (wenn nicht Windows Installer verwendet wird).

6. Erstellen und Einbetten eines Anwendungsmanifests mit Ihrer Anwendung

In Windows Vista können Sie Ihre Anwendungen richtig markieren, wenn Sie ein Anwendungsmanifest in Ihr Programm einbetten, das dem Betriebssystem mitteilt, was die Anwendung benötigt. In der Windows Vista-Version gibt es Bestimmungen, mit denen nicht manifestierten oder nicht signierten Code mit einem vollständigen Administratorzugriffstoken ausgeführt werden kann.

Hinweis In zukünftigen Releases ist die EINZIGE Möglichkeit zum Ausführen einer Anwendung mit erhöhten Rechten ein signiertes Manifest, das die von der Anwendung erforderliche Berechtigungsstufe identifiziert.

Anwendungsmanifestschema

Anwendungsmanifeste sind in der Windows Vista-Version nicht neu. Manifeste wurden in Windows XP verwendet, um Anwendungsentwicklern zu helfen, z. B. die Versionen von DLLs zu identifizieren, mit denen die Anwendung getestet wurde. Das Bereitstellen der Ausführungsebene ist eine Erweiterung des vorhandenen Manifestschemas.

Das Windows Vista-Anwendungsmanifest wurde um Attribute erweitert, mit denen Entwickler ihre Anwendungen mit einer angeforderten Ausführungsebene markieren können. Im Folgenden wird das Format dafür angegeben.

<requestedExecutionLevel
level="asInvoker|highestAvailable|requireAdministrator"
uiAccess="true|false"/>

Mögliche angeforderte Werte der Ausführungsebene

Werte	Beschreibung	Kommentar
Asinvoker	Die Anwendung wird mit demselben Zugriffstoken wie der übergeordnete Prozess ausgeführt.	Empfohlen für Standardbenutzeranwendungen. Führen Sie die Refraktorierung mit internen Höhenpunkten gemäß den Anweisungen in diesem Dokument aus.
höchsteVerfügbar	Die Anwendung wird mit den höchsten Berechtigungen ausgeführt, die der aktuelle Benutzer erhalten kann.	Empfohlen für Anwendungen im gemischten Modus. Planen Sie, die Anwendung in einer zukünftigen Version zu refraktorieren.
requireAdministrator	Die Anwendung wird nur für Administratoren ausgeführt und erfordert, dass die Anwendung mit dem vollständigen Zugriffstoken eines Administrators gestartet wird.	Empfohlen für Nur-Administrator-Anwendungen. Interne Höhenpunkte sind nicht erforderlich. Die Anwendung wird bereits mit erhöhten Rechten ausgeführt.

Hinweis Hostinganwendungen können nur dann zu Standardbenutzer- oder Administratoranwendungen werden, wenn sie diesen bestimmten Typ gehosteter Anwendungen unterstützen. Beispielsweise hostet MMC.exe jetzt nur Administrator-Snap-Ins, und Explorer.exe hostet nur Standardbenutzercode.

Systemverhalten

Anwendungsmarkin	Virtualisieren?
Unmarkierte	Ja
Asinvoker	Nein
requireAdministrator	Nein
höchsteVerfügbar	Nein

Anwendungsmanifestkennzeichnung und Anwendungsstartverhalten

In diesem Abschnitt wird das Verhalten der Rechteerweiterungsaufforderung in Abhängigkeit vom Zugriffstoken des übergeordneten Prozesses, die Einstellung für die Benutzerkontensteuerung: Verhalten der Aufforderung zur Erhöhung für Administratoren in Admin Genehmigungsmodusrichtlinie und die Benutzerkontensteuerung: Verhalten der Rechteaufforderung für Standardbenutzerrichtlinie und die angeforderte Markierung der Ausführungsebene für die Anwendung beschrieben.

Ob eine Anwendung ausgeführt werden kann und welche Benutzerrechte und Windows-Administratorrechte sie erhalten kann, hängt von der Kombination der angeforderten Ausführungsebene der Anwendung in der Anwendungskompatibilitätsdatenbank und den Administratorrechten ab, die für das Benutzerkonto verfügbar sind, das die Anwendung gestartet hat. Die folgenden Tabellen identifizieren das mögliche Laufzeitverhalten basierend auf solchen möglichen Kombinationen.

Anwendungsstartverhalten für ein Mitglied der lokalen Gruppe "Administratoren"

Zugriffstoken für übergeordnete Prozesse	Zustimmungsrichtlinie für Mitglieder der lokalen Administratorgruppe	Keine oder asInvoker	höchsteVerfügbar	requireAdministrator
Standardbenutzer	Keine Eingabeaufforderung	Die Anwendung wird als Standardbenutzer gestartet	Die Anwendung wird mit einem vollständigen Verwaltungszugriffstoken gestartet. keine Eingabeaufforderung	Die Anwendung wird mit einem vollständigen Verwaltungszugriffstoken gestartet. keine Eingabeaufforderung
Standardbenutzer	Aufforderung zur Eingabe der Zustimmung	Die Anwendung wird als Standardbenutzer gestartet	Die Anwendung wird mit einem vollständigen Verwaltungszugriffstoken gestartet. Aufforderung zur Zustimmung	Die Anwendung wird mit einem vollständigen Verwaltungszugriffstoken gestartet. Aufforderung zur Zustimmung
Standardbenutzer	Aufforderung zur Eingabe von Anmeldeinformationen	Die Anwendung wird als Standardbenutzer gestartet	Die Anwendung wird mit einem vollständigen Verwaltungszugriffstoken gestartet. Aufforderung zur Eingabe von Anmeldeinformationen	Die Anwendung wird mit einem vollständigen Verwaltungszugriffstoken gestartet. Aufforderung zur Eingabe von Anmeldeinformationen
Administrator (UAC ist deaktiviert)	–	Die Anwendung wird mit einem vollständigen Verwaltungszugriffstoken gestartet. keine Eingabeaufforderung	Die Anwendung wird mit einem vollständigen Verwaltungszugriffstoken gestartet. keine Eingabeaufforderung	Die Anwendung wird mit einem vollständigen Verwaltungszugriffstoken gestartet. keine Eingabeaufforderung

Anwendungsstartverhalten für ein Standardbenutzerkonto

Zugriffstoken für übergeordnete Prozesse	Zustimmungsrichtlinie für Standardbenutzer	Asinvoker	höchsteVerfügbar	requireAdministrator
Standardbenutzer	Keine Eingabeaufforderung	Die Anwendung wird als Standardbenutzer gestartet	Die Anwendung wird als Standardbenutzer gestartet	Die Anwendung kann nicht gestartet werden.
Standardbenutzer	Aufforderung zur Eingabe von Anmeldeinformationen	Die Anwendung wird als Standardbenutzer gestartet	Die Anwendung wird als Standardbenutzer gestartet	Aufforderung zur Eingabe von Administratoranmeldeinformationen vor dem Ausführen der Anwendung
Standardbenutzer (UAC ist deaktiviert)	–	Die Anwendung wird als Standardbenutzer gestartet	Die Anwendung wird als Standardbenutzer gestartet	Die Anwendung wird möglicherweise gestartet, schlägt aber später fehl.

Anwendungsstartverhalten für einen Standardbenutzer mit zusätzlichen Berechtigungen (z. B. Sicherungsoperator)

Zugriffstoken für übergeordnete Prozesse	Zustimmungsrichtlinie für Standardbenutzer	Asinvoker	höchsteVerfügbar	requireAdministrator
Standardbenutzer	Keine Eingabeaufforderung	Die Anwendung wird als Standardbenutzer gestartet	Die Anwendung wird als Standardbenutzer mit zusätzlichen Berechtigungen gestartet.	Die Anwendung kann nicht gestartet werden.
Standardbenutzer	Aufforderung zur Eingabe von Anmeldeinformationen	Die Anwendung wird als Standardbenutzer gestartet	Aufforderung zur Eingabe von Anmeldeinformationen vor dem Ausführen der Anwendung	Aufforderung zur Eingabe von Administratoranmeldeinformationen vor dem Ausführen der Anwendung
Standardbenutzer (UAC ist deaktiviert)	–	Die Anwendung wird als Standardbenutzer gestartet	Die Anwendung wird als Standardbenutzer mit zusätzlichen Berechtigungen gestartet.	Die Anwendung wird möglicherweise gestartet, schlägt aber später fehl.

uiAccess-Werte

Mögliche uiAccess-Werte

Wert	Beschreibung
False	Die Anwendung muss keine Eingaben auf die Benutzeroberfläche eines anderen Fensters auf dem Desktop steuern. Anwendungen, die keine Barrierefreiheit bereitstellen, sollten dieses Flag auf false festlegen. Anwendungen, die zum Steuern von Eingaben in andere Fenster auf dem Desktop erforderlich sind (z. B. Bildschirmtastatur), sollten diesen Wert auf true festlegen.
True	Die Anwendung kann Die Steuerungsebenen der Benutzeroberfläche umgehen, um Eingaben in Fenster mit höheren Berechtigungen auf dem Desktop zu steuern. Diese Einstellung sollte nur für Benutzeroberflächen-Hilfstechnologien-Anwendungen verwendet werden.

Wichtig Anwendungen, deren uiAccess-Flag auf true festgelegt ist, müssen authenticode signiert sein, um ordnungsgemäß zu starten. Darüber hinaus muss sich die Anwendung an einem geschützten Speicherort im Dateisystem befinden. \Programme\ und \windows\system32\ sind derzeit die beiden zulässigen geschützten Speicherorte.

Erstellen eines eingebetteten Manifests mit Microsoft Visual Studio

Visual Studio bietet die Möglichkeit, eine XML-Manifestdatei automatisch im Ressourcenabschnitt des PE-Images (Portable Executable) einzubetten. In diesem Abschnitt wird erläutert, wie Sie visual Studio verwenden, um ein signiertes PE-Image zu erstellen, das ein Manifest enthält. Dieses Manifest kann daher die erforderlichen requestedExecutionLevel-Attribute enthalten, sodass die Anwendung mit der gewünschten Berechtigungsstufe unter Windows Vista ausgeführt werden kann. Wenn das Programm gestartet wird, werden die Manifestinformationen aus dem Ressourcenabschnitt des PE extrahiert und vom Betriebssystem verwendet. Es ist nicht erforderlich, die grafische Benutzeroberfläche (GUI) von Visual Studio zu verwenden, um ein Manifest einzuschließen. Sobald sich die erforderlichen Änderungen im Quellcode befinden, schließt das Kompilieren und Verknüpfen mithilfe von Befehlszeilentools auch das Manifest in das resultierende PE-Image ein.

Manifestdatei

Um Ihre Anwendung zu markieren, erstellen Sie zunächst eine Manifestdatei, die mit der Zielanwendung verwendet werden soll. Dies kann mit einem beliebigen Text-Editor erfolgen. Die Manifestdatei sollte den gleichen Namen wie die target.exe mit der Erweiterung .manifest haben, wie im folgenden Beispiel gezeigt.

Executable: IsUserAdmin.exe 
Manifest:IsUserAdmin.exe.manifest
Sample application manifest file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="IsUserAdmin"
     type="win32"/> 
  <description>Description of your application</description> 
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

Die Teile des Manifests, die für Ihre Anwendung angepasst werden müssen, sind fett markiert. Hierzu gehören Folgende:

• Die Assemblyidentität
• Der Name
• Der Typ
• Die Beschreibung
• Die Attribute im requestedExecutionLevel

Erstellen von Anwendungsmanifesten in C/C++-Code mit Visual Studio 2005 für nur Windows Vista-Anwendungen

Wichtig Wenn Ihre Anwendung sowohl unter Windows Vista als auch unter Windows XP ausgeführt werden soll, müssen Sie die im nächsten Abschnitt beschriebenen Verfahren befolgen: Erstellen und Einbetten eines Manifests mit Microsoft Visual Studio 2005 für Windows XP- und Windows Vista-Anwendungen.

Als Nächstes müssen Sie das Manifest an die ausführbare Datei anfügen, indem Sie eine Zeile in der Ressourcendatei der Anwendung (die RC-Datei) hinzufügen, damit Microsoft Visual Studio Ihr Manifest in den Ressourcenabschnitt der PE-Datei einbetten lässt. Um dies zu erreichen, platzieren Sie das Manifest im selben Verzeichnis wie der Quellcode für das Projekt, das Sie erstellen, und bearbeiten Sie die RC-Datei, um die folgenden Zeilen einzuschließen.

#define MANIFEST_RESOURCE_ID 1
MANIFEST_RESOURCE_ID RT_MANIFEST "IsUserAdmin.exe.manifest"

Nach dem Neuerstellen der Anwendung sollte das Manifest in den Ressourcenabschnitt der ausführbaren Datei eingebettet werden.

Erstellen und Einbetten eines Manifests mit Microsoft Visual Studio 2005 für Windows XP und Windows Vista-Anwendungen

In Visual Studio 2005 verarbeitet die C/C++-Schnittstelle der integrierten Entwicklungsumgebung (Integrated Development Environment, IDE), die das Einschließen zusätzlicher Manifestdateien in einer ausführbaren Zieldatei ermöglicht, einige Verarbeitungen im XML-Code, wodurch ein doppeltes xmlns-Tag eingefügt wird. Daher kann die zuvor dokumentierte Methode zum Einschließen eines Manifests in ein Visual Studio 2005 C++-Projekt nicht verwendet werden, wenn die Anwendung sowohl unter Windows Vista als auch unter Windows XP ausgeführt werden soll. Die folgenden Verfahren werden geändert, um explizite Versionstags im Abschnitt trustInfo einzuschließen.

Eine Korrektur ist für das mt.exe-Tool geplant, um das Problem zu beheben, bei dem die doppelte Namespacedeklaration im XML-Code generiert wird. Bis eine neue Version von mt.exe verfügbar ist, können Sie das Problem des Zusammenführens von Manifesten vermeiden, indem Sie dem Abschnitt trustinfo des Manifests explizit Versionstags hinzufügen. Ein Beispielmanifest wird unten gezeigt:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
      <ms_asmv2:security>
         <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="asInvoker">
            </ms_asmv2:requestedExecutionLevel>
         </ms_asmv2:requestedPrivileges>
      </ms_asmv2:security>
   </ms_asmv2:trustInfo>
</assembly>

C- oder C++-Projekt

Im folgenden Verfahren wird beschrieben, wie Sie ein Manifest für einen C- oder C++-Projekttyp in Visual Studio 2005 erstellen.

So erstellen Sie ein Manifest für ein C- oder C++-Projekt in Microsoft Visual Studio 2005

1. Öffnen Ihres Projekts in Microsoft Visual Studio 2005
2. Wählen Sie unter Projekt die Option Eigenschaften aus.
3. Wählen Sie unter Eigenschaften die Option Manifesttool und dann Eingabe und Ausgabe aus.
4. Fügen Sie den Namen Ihrer Anwendungsmanifestdatei unter Zusätzliche Manifestdateien hinzu.
5. Erstellen Sie Ihre Anwendung neu.

Hinweis Die aktualisierten Manifeste, die explizite Versionstags enthalten, ermöglichen die ordnungsgemäße Ausführung der Anwendung unter Windows Vista und Windows XP.

Verwalteter Code (C#, J# und Visual Basic)

Visual Studio bettet derzeit kein Standardmanifest in verwalteten Code ein. Bei verwaltetem Code fügt der Entwickler einfach mithilfe von mt.exe ein Standardmanifest in die ausführbare Zieldatei ein. Die Schritte wären wie folgt:

So fügen Sie mit mt.exeeine Standardmanifestdatei in die ausführbare Zieldatei ein

1. Verwenden Sie einen Text-Editor, z. B. Windows-Editor, um die Standardmanifestdatei temp.manifest zu erstellen.
2. Verwenden Sie mt.exe, um das Manifest einzufügen. Der Befehl lautet: mt.exe –manifest temp.manifest –outputresource:YourApp.exe;#1

Hinzufügen des Anwendungsmanifests als Schritt in Visual Studio Post-Build

Das Hinzufügen des Anwendungsmanifests kann auch als Postbuildschritt automatisiert werden. Diese Option ist für C/C++ und die beiden verwalteten Codesprachen C# und J# verfügbar.

Hinweis Die IDE enthält derzeit keine Postbuildoption für eine Visual Basic-Anwendung.

Platzieren Sie die folgende Zeile als Postbuildtask in Den Projekteigenschaften:

mt.exe -manifest "$(ProjectDir)$(TargetName).exe.manifest" 
-updateresource:"$(TargetDir)$(TargetName).exe;#1"

7. Testen Ihrer Anwendung

Testen Sie Ihre neu gestaltete oder neue Anwendung auf Anwendungskompatibilität mit der Standard-Benutzeranalyse. Eine Prozedur, die diesen Prozess detailliert beschreibt, wurde weiter oben in diesem Dokument im Abschnitt Testen Ihrer Anwendung auf UAC-Kompatibilität beschrieben.

Verwenden Sie den folgenden Workflow, um Ihre Anwendung zu testen.

So testen Sie Ihre Anwendung auf endgültige UAC-Kompatibilität

1. Testen Sie die Anwendung mit dem Standardbenutzeranalysetool.
2. Melden Sie sich bei einem Windows Vista-Computer als Administrator im Admin Genehmigungsmodus an, und führen Sie Ihr Programm aus. Stellen Sie sicher, dass Sie alle Funktionen testen, und beachten Sie die Benutzererfahrung. Melden Sie alle Rechteerweiterungen oder Benutzeroberflächenfehler entsprechend.
3. Melden Sie sich bei einem Windows Vista-Computer als Standardbenutzer an, und führen Sie Ihr Programm aus. Stellen Sie sicher, dass Sie alle Funktionen testen und alle Unterschiede oder Fehler in der Standardbenutzerumgebung im Vergleich zum Administrator in Admin Genehmigungsmodus-Benutzeroberfläche notieren. Melden Sie alle Rechteerweiterungen und Fehler bei der Benutzerfreundlichkeit entsprechend.

8. Authenticode Signieren Ihrer Anwendung

Die Anwendung enthält nun ein Manifest, das erkannt und die Informationen beim Anwendungsstart analysiert werden. Die ausführbare Datei kann jedoch manipuliert werden. Um dies zu verhindern, sollten Sie die Anwendung mit einer Authenticode-Signatur signieren. Beachten Sie, dass Windows Vista die Möglichkeit hat, zu verhindern, dass nicht signierte Anwendungen mit einem vollständigen Administratorzugriffstoken gestartet werden. Wenn Ihre Anwendung in gesperrten Umgebungen ordnungsgemäß funktioniert und gleichzeitig eine benutzerfreundlichere Benutzeroberfläche angezeigt wird, sollte sie mit einer Authenticode-Signatur signiert werden.

Um die Anwendung zu signieren, können Sie entweder ein Zertifikat aus makecert.exe generieren oder einen Codesignaturschlüssel von einer der kommerziellen Zertifizierungsstellen (CAs) wie VeriSign, Thawte oder einer Microsoft-Zertifizierungsstelle abrufen.

Hinweis Sie benötigen ein kommerzielles Zertifikat, wenn Sie mit Ihrer Anwendung auf dem Zielcomputer eines Kunden, der Ihre Anwendung installiert, vertrauenswürdig sind.

Wenn Sie die makecert.exe-Datei verwenden, um Ihr Signaturschlüsselpaar zu generieren, beachten Sie, dass nur ein 1024-Bit-Schlüssel generiert wird. Authenticode-Signaturen sollten mindestens ein 2048-Bit-Schlüssel sein. Die makecert.exe-Datei sollte nur zu Testzwecken verwendet werden.

Im folgenden Verfahren werden die allgemeinen Anforderungen für die Verwendung makecert.exe zum Generieren Ihres Signaturschlüsselpaars erläutert. Ein Beispiel und makecert.exe Parameter folgen diesem Verfahren.

So verwenden Sie makecert.exe, um Ihr Signaturschlüsselpaar zu generieren

1. Generieren Sie das Zertifikat.
2. Signieren Sie den Code.
3. Installieren Sie das Testzertifikat.

Beispielsignaturprozedur

Die folgenden Verfahren werden als Beispiele bereitgestellt und sind nicht für die strikte Durchführung vorgesehen. Ersetzen Sie beispielsweise den Namen des Testzertifikats durch den Namen Ihres Zertifikats, und stellen Sie sicher, dass Sie die Prozeduren ihrer spezifischen Zertifizierungsstelle und Entwicklungsumgebung anpassen.

Schritt 1: Generieren des Zertifikats

makecert -r -pe -ss PrivateCertStore -n "CN=Contoso.com(Test)" 
ContosoTest.cer

makecert.exe Parameter

Parameter	BESCHREIBUNG
/r	Zum Erstellen eines selbstsignierten Zertifikats
/Pe	Macht den privaten Schlüssel des Zertifikats auf den Signaturcomputer exportierbar.
/ss StoreName	Der Zertifikatspeichername, in dem das Testzertifikat gespeichert wird. Beispiel: PrivateCertStore
/n X500Name	Der X500-Name des Zertifikatsubjekts. Beispiel: Contoso.com(Test)
CertificateName.cer	Zertifikatname. Beispiel: ContosoTest.cer

Schritt 2: Signieren des Codes

Signtool sign /v /s PrivateCertStore /n Contoso.com(Test) /t 
http://timestamp.verisign.com/scripts/timestamp.dll file.exe

Schritt 3: Installieren des Testzertifikats

So installieren Sie das Testzertifikat

1. Starten Sie ein Befehlsfenster mit erhöhten Rechten, indem Sie mit der rechten Maustaste auf Eingabeaufforderung klicken und Als Administrator ausführen auswählen.
2. Geben Sie in der Eingabeaufforderung mmc.exe ein, und drücken Sie die EINGABETASTE.
3. Wählen Sie im mmc die Option Datei und dann Snap-In hinzufügen/entfernen... aus.
4. Wählen Sie unter Snap-Ins hinzufügen oder entfernen die Option Zertifikate aus, klicken Sie auf Hinzufügen, und klicken Sie dann auf OK.
5. Wählen Sie im Dialogfeld Zertifikate-Snap-In die Option Computerkonto aus, und klicken Sie auf Weiter.
6. Wählen Sie unter Computer auswählen die Option Lokaler Computer aus, und klicken Sie dann auf OK.
7. Klicken Sie unter Snap-Ins hinzufügen oder entfernen auf OK.
8. Navigieren Sie im Snap-In Zertifikate zu Vertrauenswürdige Stammzertifizierungsstellen, klicken Sie mit der rechten Maustaste auf Zertifikate, wählen Sie Alle Aufgaben aus, und wählen Sie dann Importieren...
9. Importieren Sie im Zertifikatimport-Assistenten das Testzertifikat ContosoTest.cer.

9. Teilnehmen am Windows Vista-Logo-Programm

Microsoft bietet das Windows Vista-Logo-Programm an, um Kunden bei der Identifizierung von Systemen und Peripheriegeräten zu unterstützen, die eine umfassende Baselinedefinition von Plattformfeatures und Qualitätszielen erfüllen, um eine hervorragende Computerumgebung für Endbenutzer zu gewährleisten.

Bereitstellen und Patchen von Anwendungen für Standardbenutzer

In der Regel müssen Unternehmen überlegen, wie sie Anwendungen automatisiert auf den Arbeitsstationen ihrer Benutzer installieren und so die Verwaltungskosten senken. Dieses Problem besteht im Wesentlichen aus zwei Teilen: erstens, wie diese Anwendungen für die Bereitstellung gepackt werden sollten, und zweitens, welche Technologie für die Bereitstellung verwendet werden sollte. Bei kleineren Unternehmensumgebungen ist ein robuster, automatisierter Bereitstellungsmechanismus möglicherweise nicht erforderlich.

Vorausgesetzt, das Unternehmen hat bereits eine Bestandsaufnahme der Software erstellt, die in seiner Umgebung ausgeführt wird, besteht der nächste Schritt darin, diese Anwendungen für die Bereitstellung neu zu packen. Microsoft empfiehlt das Windows Installer-Format, da es die einzigartige Möglichkeit hat, die Verwaltung von Benutzereinstellungen von computerspezifischen Einstellungen zu trennen. Diese Art der Verwaltung ist in der Regel mit anderen Paketformaten nicht möglich, insbesondere nicht mit ausführbaren Bereitstellungsdateien, die einfach von einem Konto mit mehr Berechtigungen wie SYSTEM ausgeführt werden. Die MSDN-Bibliothek enthält viele Artikel zu Windows Installer. ein Vorschlag ist die Roadmap zur Windows Installer-Dokumentation.

Das Windows Installer-Format umfasst die Möglichkeit, die Installation dieser Anwendungen über Gruppenrichtlinie (Microsoft IntelliMirror) und auch über SMS zu steuern. Um Install on Demand mit Dateierweiterung oder Verknüpfungen zu aktivieren, müssen die folgenden Tabellen im Windows Installer-basierten Paket mit Werbedaten aufgefüllt werden: Verknüpfung, Erweiterung, Symbol und Verb. Es wird empfohlen, auch die Klasse, MIME, ProgID und TypeLib aufzufüllen. Weitere Informationen zu IntelliMirror und Install on Demand finden Sie unter Patching Per-User Managed Applications .

Es gibt andere Installationstechnologien, die es Anwendungen ermöglichen, pro Benutzer zu installieren und automatische Updates zu unterstützen, z. B. ClickOnce. Dies bedeutet, dass für das Installationsprogramm keine Administrator- oder höhere Berechtigungen erforderlich sind und dass der Benutzer immer die neueste Version ausführen wird, solange der Computer mit dem Netzwerk verbunden ist. Es setzt auch einige Grenzen für die Fähigkeit eines IT-Experten, die Installation dieser Anwendungen zu steuern.

ClickOnce-Bereitstellung ist eine Microsoft .NET-Installationstechnologie, die automatisch eine clientseitige Anwendung installiert und konfiguriert, wenn ein Benutzer auf einen Manifestlink klickt, z. B. auf ein Manifest auf einer Website, auf einer CD oder auf einem UNC-Pfad (Universal Naming Convention). Standardmäßig kopiert sich die Anwendung selbst in den Ordner Temporäre Internetdateien und wird in einer eingeschränkten Umgebung ausgeführt.

Hinweis Selbst wenn Ihre Anwendung mit dem starken IT-Namen signiert wurde, der ihr voll vertrauenswürdig ist, können Sie dennoch nichts tun, das Administratorberechtigungen erfordert, z. B. zugriff auf bestimmte Teile des Dateisystems und der Registrierung. ClickOnce-Anwendungen sind jedoch als Benutzeranwendungen vorgesehen, daher sollte dies kein Problem darstellen.

Wichtig ClickOnce sollte nicht zum Bereitstellen von Anwendungen verwendet werden, die Administrative Vorgänge ausführen.

Bereitstellen auf einem einzelnen Computer

Um eine Anwendung für einen einzelnen Computer bereitzustellen, muss der Administrator die Anwendung auf diesem Computer "veröffentlichen".

Bereitstellen für alle Benutzer in einer Domäne

Um für alle Benutzer in einer Domäne anzukündigen, muss der Administrator die Anwendung über Gruppenrichtlinie Bereitstellung "veröffentlichen". Derzeit nutzt nur die Gruppenrichtlinie-basierte Softwarebereitstellungskomponente der Windows Server® 2003-Betriebssysteme und des Windows 2000 Server-Betriebssystems diese Funktionalität.

Patchen von Anwendungen als Standardbenutzer mit Windows Installer 4.0

Das Patchen von Standardbenutzerkonten ermöglicht es Windows Installer-Paketautoren, signierte Patches zu identifizieren, die von einem zukünftigen Standardbenutzer angewendet werden können. Die folgenden Bedingungen müssen erfüllt sein, um standardmäßiges Benutzerpatching mit Windows Installer 4.0 zu ermöglichen:

• Die Anwendung wurde unter Windows Installer 4.0 installiert.
• Die Anwendung wurde ursprünglich pro Computer installiert.
• Die MsiPatchCertificate-Tabelle ist vorhanden und wird im ursprünglichen Window Installer-Paket (.msi Datei) aufgefüllt.
• Die Patches werden digital von einem Zertifikat signiert, das in der MsiPatchCertificate-Tabelle aufgeführt ist.
• Die Patches können anhand der digitalen Signatur überprüft werden.
• Das Standard-Benutzerkontopatching wurde nicht deaktiviert, indem die MSIDISABLELUAPATCHING-Eigenschaft oder die DisableLUAPatching-Richtlinie festgelegt wurde.

Windows Installer 4.0 Standard-Benutzerdeinstallationsverhalten

Das erwartete Verhalten für einen Windows Installer 4.0-Patch, der von einem Standardbenutzer angewendet wird, besteht darin, dass er auch vom Standardbenutzer entfernt werden kann.

Problembehandlung bei gängigen Problemen

In den folgenden Abschnitten werden häufige Probleme beschrieben, die bei Anwendungen in Windows Vista auftreten.

Häufige Probleme sind beispielweise:

• Probleme bei der ActiveX-Installation
• ActiveX-Dokumente werden nicht installiert
• Anwendung, Framework oder Add-In erforderlich
• Für die Installation/Das Patchen ist eine Administratorberechtigung erforderlich.
• Anwendungseinstellungsorte pro Benutzer
• Standardmäßig wird die Anwendung in einem geschützten Verzeichnis gespeichert.

Probleme bei der ActiveX-Installation

ActiveX-Steuerelemente müssen von einem Administrator installiert werden. ActiveX-Steuerelemente werden in der Regel in Branchenanwendungen verwendet, um die Webbrowserfunktionen zu erweitern, um flexiblere Benutzeroberflächen zu erstellen oder den Zugriff auf Computerressourcen zu erhöhen, die normalerweise anwendungen verweigert werden, die im Webbrowser ausgeführt werden. ActiveX-Steuerelemente werden in der Regel installiert, indem ein Verweis auf das ActiveX-Steuerelement in einer Webseite eingebettet wird. Dies führt dazu, dass Microsoft Internet Explorer das Steuerelement herunterladen und installieren, wenn es nicht auf dem lokalen Computer vorhanden ist. In der Regel befinden sich auf diese Weise heruntergeladene ActiveX-Steuerelemente im Verzeichnis %HOMEPATH%\Local Settings\Temporary Internet Files, das von Standardbenutzern beschreibbar ist. Um jedoch innerhalb des Internet-Explorer funktionieren zu können, müssen die Steuerelemente über Einträge mit mehreren Registrierungen verfügen, die für Nichtadministratoren nicht möglich sind.

Lösung

Das Entfernen des ActiveX-Steuerelements aus der Anwendung führt fast immer zu einem Funktionsverlust. Daher wird dies nicht für die Behebung empfohlen, es sei denn, das ActiveX-Steuerelement bietet eine visuelle oder funktionale Verbesserung, die nicht Teil der Kernfunktionen der Website ist. Ein Beispiel ist ein Aktienticker in einem nicht aktienbezogenen Portal.

In den meisten Fällen ist das Packen des ActiveX-Steuerelements für die Installation per SMS oder Gruppenrichtlinie die richtige Lösung. Die meisten Steuerelemente sind jedoch nicht im Basisimage enthalten, sodass Websites ihre Seiten so ändern müssen, dass sie ordnungsgemäß fehlschlagen. Dies sollte das Erkennen des fehlenden ActiveX-Steuerelements und das Umleiten zur Anforderungsseite für verwaltete Desktop-Software umfassen.

ActiveX-Dokumente werden nicht installiert

ActiveX-Dokumente sind eine veraltete Technologie von Microsoft Visual Basic 4 und Microsoft Visual Basic 5. Sie können ähnlich wie ActiveX-Steuerelemente heruntergeladen werden.

Lösung

Da Visual Basic 4 und Visual Basic 5 veraltet sind, empfiehlt Microsoft, die Anwendung zu ersetzen. Es sollte möglich sein, das ActiveX-Dokument im Rahmen einer Clientinstallation zu installieren. Aktualisierungen des Dokuments werden jedoch ohne erneute Bereitstellung per SMS oder Gruppenrichtlinie eingeschränkt.

Anwendung, Framework oder Add-In erforderlich

Viele Anwendungen verfügen über Abhängigkeiten von anderer Software, die möglicherweise nicht standardmäßig installiert wird, entweder weil sie bereits auf dem Computer verfügbar sind oder weil die andere Anwendung keine verteilbaren Binärdateien für die Verwendung durch Dritte bereitstellt. Unter normalen Umständen wird der Benutzer angewiesen, die zusätzliche Software zu erwerben und zu installieren. Unter einem verwalteten Desktop ist die Installation nicht möglich. Beispiele hierfür sind Adobe Acrobat, Microsoft Office, Office Web-Komponenten, WinZip und die .NET-Sicherheitsrichtlinie für IT-Microsoft.

Lösung

Sobald die Abhängigkeiten identifiziert wurden, können sie entweder mit dem Basisimage gepackt oder über die bedarfsgesteuerte SMS-Installation zur Verfügung gestellt werden. Die Anwendung muss möglicherweise ändern, wie sie den Endbenutzer über die fehlende Software benachrichtigt, und leitet den Benutzer an die SMS-Installationswebsite statt an den Hersteller weiter.

Für die Installation/Das Patchen ist eine Administratorberechtigung erforderlich.

Da für die Installation eines Programms das Hinzufügen von Dateien zu Programmdateien erforderlich ist, erfordert es immer Administratorberechtigungen und muss daher als Benutzer mit erhöhten Berechtigungen ausgeführt werden.

Hinweis Sie können den Patch auch per SMS oder Gruppenrichtlinie in Verbindung mit der ARP-Systemsteuerung (Add or Remove Programs) "pushen". Der Benutzer wählt die zu installierende Software aus, und der Systeminstallationsprogramm übernimmt den Rest – der Benutzer muss kein Administrator sein. Bei Erstinstallationen kann dies durch Verpacken der Software behoben werden, damit ein Installations-Agent pushen kann. Einige Anwendungen basieren jedoch auf häufigen automatischen Updates, die möglicherweise nicht gut mit einem zentral verwalteten Anwendungsmodell übereinstimmen.

Anwendungen, die Updates erkennen und versuchen, sich selbst zu patchen, können dies nicht tun, da sie nicht berechtigt sind, Dateien in den Systemverzeichnissen zu ändern.

Lösung

• Packen Sie Ihre Anwendung/Den Patch für die Bereitstellung per SMS. Anwendungen können weiterhin erkennen, dass ein Upgrade verfügbar ist (solange dies ohne Administratorberechtigungen erforderlich ist) und können zur Bereitstellungswebsite umgeleitet werden.
• Fragen Sie, ob Ihre Anwendung erhöhte Computerberechtigungen benötigt, z. B. Dateisystem, Registrierungszugriff oder COM-Interoperabilität. Andernfalls ist es möglicherweise möglich, die Anwendung als ClickOnce-Bereitstellungspaket neu zu schreiben, das in der Microsoft .NET-Sandbox ausgeführt wird.
• Konvertieren Sie in eine Webanwendung ohne clientseitige Abhängigkeiten.

Per-User Speicherorte für Anwendungseinstellungen

Für Windows Vista sollten die Anwendungseinstellungen, die zur Laufzeit geändert werden müssen, an einem der folgenden Speicherorte gespeichert werden:

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

Vom Benutzer gespeicherte Dokumente sollten in CSIDL_MYDOCUMENTS gespeichert werden.

Hinweis Der Ordner Dokumente eines Benutzers wird nicht mehr unter Dokumente und Einstellungen gespeichert. In Windows Vista enthält ein neues Stammverzeichnis im Dateisystem namens Benutzer jetzt die Profile für Benutzer des Computers.

Da sich diese Verzeichnisse geändert haben, werden Entwickler empfohlen, CSIDLs zu verwenden, um den Pfad zu bestimmten bekannten Verzeichnissen systemunabhängig zu finden. Weitere Informationen finden Sie unter CSIDLs.

Eine Anwendung benötigt Schreibzugriff auf das Dateisystem. Wenn eine Anwendung unter einem verwalteten Desktop ausgeführt wird, verfügt eine Anwendung nur über Schreibberechtigungen für die folgenden Ordner und ihre untergeordneten Ordner.

• CSIDL_PROFILE
• CSIDL_COMMON_APPDATA

Hinweis Standardbenutzer können nicht in Benutzer\Common schreiben.

• C:\Users\Common>cd "Application Data"
  • C:\Users\Common\Application Data>Echo File > File.txt
  • C:\Users\Common\Application Data>

Anwendungen sollten nicht versuchen, an andere Speicherorte zu schreiben, z. B. die folgenden:

• C:\windows.
• C:\Windows\System32.
• Programme\{application}.
• C:\{application}.

Hinweis Dies funktioniert, wenn der Benutzer den Ordner erstellt hat, was die Mitglieder der Gruppe Benutzer standardmäßig tun können.

Eine Anwendung versucht, speziell C:\Users\Profiles\{user} zu erstellen, ist nicht zulässig, da der Benutzer nur Ordner unter C:\Users\{user} erstellen kann. Der ausgewählte Speicherort scheint verwirrt zu sein, je nachdem, wo Microsoft den Ordner Dokumente in früheren Versionen des Betriebssystems gespeichert hat.

Anwendungseinstellungen, die zur Laufzeit geändert werden müssen, sollten an einem der folgenden Speicherorte gespeichert werden:

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

Vom Benutzer gespeicherte Dokumente sollten im Ordner CSIDL_MYDOCUMENTS gespeichert werden.

Alle Pfade sollten nicht hartcodiert sein, sondern die Funktion Environment.GetFolderPath() verwenden.

Standardmäßige Anwendungseinstellungen zum Speichern in einem geschützten Verzeichnis

Bei einigen Anwendungen können Benutzer Daten auf ihrem lokalen Computer speichern oder exportieren. Häufig wird das Dialogfeld standardmäßig auf Orte wie C:\festgelegt, für die Standardbenutzer keine Schreibberechtigungen haben. Darüber hinaus reagieren einige Anwendungen nicht gut, wenn der Code zum Schreiben der Datei aufgrund eines vom Betriebssystem verweigerten Zugriffs fehlschlägt.

Lösung

Angenommen, Benutzer können nur in ihre eigenen Profile schreiben. Für Dokumente, die absichtlich von Benutzern gespeichert wurden, initialisieren Sie die Dialogfelder, um unter Dokumente (Environment.GetFolderPath(Environment.SpecialFolder.Personal) zu beginnen. Denken Sie daran, dass das Dialogfeld Speichern es einem Benutzer ermöglicht, zu anderen Speicherorten als dem Profil des Benutzers zu navigieren. Daher sollte die Anwendung Logik enthalten, um sicherzustellen, dass sie ordnungsgemäß fehlschlägt, wenn ein Benutzer ein anderes Verzeichnis als die in seinem Profil befindet.

Referenzen

Dieser Abschnitt enthält einen Virtualisierungsverweis und einen Verweis auf Sicherheitseinstellungen.

Virtualisierungsreferenz

Dateivirtualisierung

• Virtualisieren (%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(Unterverzeichnisse)
• Umleiten zu: %LOCALAPPDATA%\VirtualStore
• Ausgeschlossene ausführbare Binärdateien: .exe, .dll, .sys

Registrierungsvirtualisierung:

• Virtualisieren (HKLM\SOFTWARE)
• Umleitung zu: HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\<Application Registry Keys>
• Schlüssel, die von der Virtualisierung ausgeschlossen sind
• HKLM\Software\Classes
• HKLM\Software\Microsoft\Windows
• HKLM\Software\Microsoft\Windows NT

Anwendbarkeit

• Virtuelle Speicher werden nicht roam
• Entsprechende globale Objekte würden nicht roamieren.
• Nur für interaktive Standardbenutzer aktiviert
• Deaktiviert für nicht interaktive Prozesse
• Deaktiviert für ausführbare 64-Bit-Dateien
• Deaktiviert für ausführbare Dateien, die eine Ausführungsebene (requestedExecutionLevel) in ihrem Anwendungsmanifest anfordern, das Modell für die Trennung
• Deaktiviert für Kernelmodus und identitätswechselte Aufrufer
• Nur vom Administrator beschreibbare Registrierungsschlüssel und Dateien werden virtualisiert.

Referenz zu UAC-Sicherheitseinstellungen

In diesem Verweis werden die Sicherheitseinstellungen erläutert, die zum Verwalten der UAC mit Gruppenrichtlinie oder der lokalen Sicherheitsrichtlinie des Computers verfügbar sind.

Hinweis Die in diesem Abschnitt beschriebenen Verfahren sind für die Verwaltung nicht verwalteter Computer vorgesehen. Wenn Sie Gruppenrichtlinie verwenden möchten, um die Einstellungen zentral in einer verwalteten Umgebung zu verwalten, verwenden Sie Active Directory-Benutzer und -Computer (dsa.msc) anstelle des lokalen Sicherheitsrichtlinien-Manager-Snap-Ins (secpol.msc).

Konfigurieren der UAC-Sicherheitseinstellungen

Im folgenden Verfahren erfahren Sie, wie Sie die UAC-Sicherheitseinstellungen mit dem Sicherheitsrichtlinien-Manager konfigurieren. Die Prozedur beschreibt die Standardbenutzerfreundlichkeit für einen Administrator im Admin Genehmigungsmodus.

So zeigen Sie die UAC-Sicherheitseinstellungen mit dem Sicherheitsrichtlinien-Manager an/legen sie fest

1. Klicken Sie auf die Schaltfläche Start , geben Sie secpol.msc in das Suchfeld ein, und drücken Sie dann die EINGABETASTE.
2. Klicken Sie in der Zustimmungsaufforderung der Benutzerkontensteuerung auf Weiter.
3. Erweitern Sie unter Lokale Sicherheitseinstellungen den Eintrag Lokale Richtlinien, und klicken Sie dann auf Sicherheitsoptionen.
4. Klicken Sie mit der rechten Maustaste auf die Sicherheitseinstellung, die Sie ändern möchten, und wählen Sie Eigenschaften aus.

Im folgenden Verfahren wird beschrieben, wie Sie die UAC-Sicherheitseinstellungen mit dem Gruppenrichtlinie konfigurieren. Die Prozedur beschreibt die Standardbenutzerfreundlichkeit für einen Administrator in Admin Genehmigungsmodus.

So zeigen Sie die UAC-Sicherheitseinstellungen mit dem Gruppenrichtlinie-Objekt-Editor an/legen sie fest

1. Klicken Sie auf die Schaltfläche Start , geben Sie gpedit.msc in das Suchfeld ein, und drücken Sie dann die EINGABETASTE.
2. Klicken Sie in der Zustimmungsaufforderung der Benutzerkontensteuerung auf Weiter.
3. Erweitern Sie in Gruppenrichtlinie Benutzerkonfiguration und dann Sicherheitsoptionen.
4. Klicken Sie mit der rechten Maustaste auf die Sicherheitseinstellung, die Sie ändern möchten, und wählen Sie Eigenschaften aus.

UAC-Sicherheitseinstellungen

In der folgenden Tabelle sind die konfigurierbaren UAC-Sicherheitseinstellungen aufgeführt. Diese Einstellungen können mit dem Sicherheitsrichtlinien-Manager (secpol.msc) konfiguriert oder zentral mit Gruppenrichtlinie (gpedit.msc) verwaltet werden.

UAC-Sicherheitseinstellungen

Einstellung	BESCHREIBUNG	Standardwert
Benutzerkontensteuerung: Admin Genehmigungsmodus für das integrierte Administratorkonto.	Es gibt zwei mögliche Einstellungen: Aktiviert: Der integrierte Administrator wird als Administrator im Admin Genehmigungsmodus ausgeführt. Deaktiviert: Der Administrator wird mit einem vollständigen Administratorzugriffstoken ausgeführt.	Deaktiviert für Neuinstallationen und Upgrades, bei denen der integrierte Administrator nicht der einzige lokale aktive Administrator auf dem Computer ist. Das integrierte Administratorkonto ist für Installationen und Upgrades auf in die Domäne eingebundenen Computern standardmäßig deaktiviert. Aktiviert für Upgrades, wenn Windows Vista feststellt, dass das integrierte Administratorkonto der einzige aktive lokale Administrator auf dem Computer ist. Wenn Windows Vista dies feststellt, wird auch das integrierte Administratorkonto nach dem Upgrade aktiviert. Das integrierte Administratorkonto ist für Installationen und Upgrades auf in die Domäne eingebundenen Computern standardmäßig deaktiviert.
Benutzerkontensteuerung: Verhalten der Eingabeaufforderung für erhöhte Rechte für Administratoren im Administratorbestätigungsmodus	Für diese Einstellung gibt es drei mögliche Werte: Erhöhen ohne Aufforderung: Unbemerkt erhöhen. Aufforderung zur Eingabe von Anmeldeinformationen: Benutzer müssen ihr Anmeldekennwort eingeben, bevor Sie fortfahren. Aufforderung zur Zustimmung: Bitten Sie den Benutzer um Genehmigung, bevor Sie die Rechte erhöhen. Dies ist die Standardeinstellung.  Diese Einstellung bestimmt, wie der Benutzer vor dem Ausführen eines Programms mit höheren Berechtigungen aufgefordert wird. Diese Richtlinie ist nur wirksam, wenn UAC aktiviert ist.	Aufforderung zur Eingabe der Zustimmung
Benutzerkontensteuerung: Verhalten der Eingabeaufforderung für erhöhte Rechte für Standardbenutzer	Bestimmt, wie der Benutzer vor dem Ausführen eines Programms mit höheren Berechtigungen aufgefordert wird. Diese Richtlinie ist nur wirksam, wenn UAC aktiviert ist. Im Folgenden finden Sie die verfügbaren Konfigurationsoptionen für diese Einstellung: Anforderungen zur Erhöhung automatisch verweigern: Benutzer werden nicht aufgefordert, wenn eine Anwendung eine Verwaltungsaufgabe ausführen möchte. Die Anwendung kann nicht gestartet werden, und dem Benutzer wird ein Zugriff verweigert oder ein gleichwertiger Fehler angezeigt. Aufforderung zur Eingabe von Anmeldeinformationen: Benutzer müssen ihr Anmeldekennwort eingeben, bevor Sie fortfahren.	Aufforderung zur Eingabe von Anmeldeinformationen
Benutzerkontensteuerung: Anwendungsinstallationen erkennen und erhöhte Rechte anfordern	Es stehen zwei mögliche Werte zur Verfügung: Aktiviert: Der Benutzer wird aufgefordert, seine Zustimmung oder Anmeldeinformationen einzugeben, wenn Windows Vista ein Installationsprogramm erkennt. Deaktiviert: Anwendungsinstallationen schlagen automatisch fehl oder schlagen nicht deterministisch fehl.	Aktiviert
Benutzerkontensteuerung: Nur ausführbare Dateien heraufstufen, die signiert und überprüft sind	Es stehen zwei mögliche Werte zur Verfügung: Aktiviert: Nur signierte ausführbare Dateien werden ausgeführt. Diese Einstellung blockiert die Ausführung nicht signierter Anwendungen. Deaktiviert: Sowohl signierter als auch nicht signierter Code wird ausgeführt.	Disabled
Benutzerkontensteuerung: Erhöhte Rechte nur für UIAccess-Anwendungen, die an sicheren Orten installiert sind	Es stehen zwei mögliche Werte zur Verfügung: Aktiviert: Das System gewährt nur UIAccess-Berechtigungen und Benutzerrechte für ausführbare Dateien, die unter %ProgramFiles% oder %windir% gestartet werden. Die ACLs in diesen Verzeichnissen stellen sicher, dass die ausführbare Datei nicht vom Benutzer geändert werden kann (was andernfalls rechteerweiterungen zulassen würde). Ausführbare UIAccess-Dateien, die von anderen Speicherorten gestartet werden, werden ohne zusätzliche Berechtigungen gestartet (d. h. sie werden "asInvoker" ausgeführt). Deaktiviert: Die Standortüberprüfungen werden nicht durchgeführt, sodass alle UIAccess-Anwendungen nach der Benutzergenehmigung mit dem Vollzugriffstoken des Benutzers gestartet werden.	Aktiviert
Benutzerkontensteuerung: Alle Administratoren im Administratorbestätigungsmodus ausführen	Es stehen zwei mögliche Werte zur Verfügung: Aktiviert: Sowohl Administratoren als auch Standardbenutzer werden beim Versuch, Verwaltungsvorgänge auszuführen, aufgefordert. Das Eingabeaufforderungsformat ist von der Richtlinie abhängig. Deaktiviert: UAC ist im Wesentlichen "deaktiviert", und der AIS-Dienst wird vom automatischen Starten deaktiviert.	Aktiviert
Benutzerkontensteuerung: Bei Benutzeraufforderung nach erhöhten Rechten zum sicheren Desktop wechseln	Es stehen zwei mögliche Werte zur Verfügung: Aktiviert: Zeigt die UAC-Eingabeaufforderung zur Erhöhung auf dem sicheren Desktop an. Der sichere Desktop kann nur Nachrichten von Windows-Prozessen empfangen, wodurch Nachrichten von Schadsoftware entfernt werden. Daher können Zustimmungs- und Anmeldeinformationen auf dem sicheren Desktop nicht spooft werden. Deaktiviert: Die UAC-Eingabeaufforderung zur Erhöhung wird auf dem Benutzerdesktop angezeigt.	Aktiviert
Benutzerkontensteuerung: Datei- und Registrierungsschreibfehler an Einzelbenutzerstandorte virtualisieren	Es stehen zwei mögliche Werte zur Verfügung: Aktiviert: Anwendungen, denen kein Anwendungskompatibilitätsdatenbankeintrag oder eine angeforderte Markierung der Ausführungsebene im Anwendungsmanifest fehlt, sind nicht UAC-kompatibel. In Umgebungen, in denen nicht konforme Software verwendet wird, sollte diese Einstellung aktiviert bleiben. Deaktiviert: UAC-konforme Anwendungen dürfen nicht in geschützte Bereiche schreiben und Schreibfehler verursachen. Daher sollten Umgebungen, die nur UAC-konforme Anwendungen verwenden, diese Einstellung deaktivieren. Nicht konforme Anwendungen, die versuchen, in Programme und %systemroot% zu schreiben, schlagen automatisch fehl, wenn diese Einstellung deaktiviert ist.	Aktiviert

Hinweis In den meisten Fällen wird die Option Erhöhen ohne Aufforderung nicht empfohlen. Das Erhöhen ohne Aufforderung würde es Anwendungen, die als Standardbenutzer ausgeführt werden, ermöglichen, Administrative Anwendungen ohne Benutzereinwilligung zu starten und UAC effektiv zu umgehen.

Codebeispiel für task scheduler

Im folgenden C++-Codebeispiel wird veranschaulicht, wie Sie die Aufgabenplanung verwenden, um die Erhöhung für den Benutzer auszuführen. Daher kann die Anwendung während der Anmeldung mithilfe der Anmeldeinformationen eines Administrators automatisch erhöhen, und Windows Vista blockiert die Anwendung nicht. Sie müssen während des Setups einen Administratorbenutzer für Ihre Anwendung erstellen, damit diese Lösung ordnungsgemäß funktioniert.

//---------------------------------------------------------------------
//  This file is part of the Microsoft .NET Framework SDK Code Samples.
// 
//  Copyright (C) Microsoft Corporation.  All rights reserved.
// 
//This source code is intended only as a supplement to Microsoft
//Development Tools and/or on-line documentation.  See these other
//materials for detailed information regarding Microsoft code samples.
// 
//THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY
//KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
//IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
//PARTICULAR PURPOSE.
//---------------------------------------------------------------------

/****************************************************************************
* Main.cpp - Sample application for Task Scheduler V2 COMAPI                * Component: Task Scheduler                          
* Copyright (c) 2002 - 2003, Microsoft Corporation 
* This sample creates a task to at the time registered to start the desired task.                                                             *
****************************************************************************/
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <comdef.h>
#include <comutil.h>
//Include Task header files - Included in Windows Vista Beta-2 SDK from MSDN
#include <taskschd.h>
#include <conio.h>
#include <iostream>
#include <time.h>

using namespace std;

#define CLEANUP \
pRootFolder->Release();\
        pTask->Release();\
        CoUninitialize();

HRESULT CreateMyTask(LPCWSTR, wstring);

void __cdecl wmain(int argc, wchar_t** argv)
{
wstring wstrExecutablePath;
WCHAR taskName[20];
HRESULT result;

if( argc < 2 )
{
printf("\nUsage: LaunchApp yourapp.exe" );
return;
}

// Pick random number for task name
srand((unsigned int) time(NULL));
wsprintf((LPWSTR)taskName, L"Launch %d", rand());

wstrExecutablePath = argv[1];

result = CreateMyTask(taskName, wstrExecutablePath);
printf("\nReturn status:%d\n", result);

}
HRESULT CreateMyTask(LPCWSTR wszTaskName, wstring wstrExecutablePath)
{
    //  ------------------------------------------------------
    //  Initialize COM.
TASK_STATE taskState;
int i;
    HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
    if( FAILED(hr) )
    {
        printf("\nCoInitializeEx failed: %x", hr );
        return 1;
    }

    //  Set general COM security levels.
    hr = CoInitializeSecurity(
        NULL,
        -1,
        NULL,
        NULL,
        RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
        RPC_C_IMP_LEVEL_IMPERSONATE,
        NULL,
        0,
        NULL);

    if( FAILED(hr) )
    {
        printf("\nCoInitializeSecurity failed: %x", hr );
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Create an instance of the Task Service. 
    ITaskService *pService = NULL;
    hr = CreateElevatedComObject( CLSID_TaskScheduler,
                           NULL,
                           CLSCTX_INPROC_SERVER,
                           IID_ITaskService,
                           (void**)&pService );  
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        CoUninitialize();
        return 1;
    }
        
    //  Connect to the task service.
    hr = pService->Connect(_variant_t(), _variant_t(), _variant_t(), _variant_t());
    if( FAILED(hr) )
    {
        printf("ITaskService::Connect failed: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Get the pointer to the root task folder.  This folder will hold the
    //  new task that is registered.
    ITaskFolder *pRootFolder = NULL;
    hr = pService->GetFolder( _bstr_t( L"\\") , &pRootFolder );
    if( FAILED(hr) )
    {
        printf("Cannot get Root Folder pointer: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }
    
    //  Check if the same task already exists. If the same task exists, remove it.
    hr = pRootFolder->DeleteTask( _bstr_t( wszTaskName), 0  );
    
    //  Create the task builder object to create the task.
    ITaskDefinition *pTask = NULL;
    hr = pService->NewTask( 0, &pTask );

    pService->Release();  // COM clean up.  Pointer is no longer used.
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        pRootFolder->Release();
        CoUninitialize();
        return 1;
    }
        

    //  ------------------------------------------------------
    //  Get the trigger collection to insert the registration trigger.
    ITriggerCollection *pTriggerCollection = NULL;
    hr = pTask->get_Triggers( &pTriggerCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get trigger collection: %x", hr );
CLEANUP
        return 1;
    }
  
    //  Add the registration trigger to the task.
    ITrigger *pTrigger = NULL;
    
    hr = pTriggerCollection->Create( TASK_TRIGGER_REGISTRATION, &pTrigger );     
    pTriggerCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\nCannot add registration trigger to the Task %x", hr );
        CLEANUP
        return 1;
    }
    pTrigger->Release();

    //  ------------------------------------------------------
    //  Add an Action to the task.     
    IExecAction *pExecAction = NULL;
    IActionCollection *pActionCollection = NULL;

    //  Get the task action collection pointer.
    hr = pTask->get_Actions( &pActionCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get Task collection pointer: %x", hr );
        CLEANUP
        return 1;
    }
    
    //  Create the action, specifying that it is an executable action.
    IAction *pAction = NULL;
    hr = pActionCollection->Create( TASK_ACTION_EXEC, &pAction );
    pActionCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\npActionCollection->Create failed: %x", hr );
        CLEANUP
        return 1;
    }

    hr = pAction->QueryInterface( IID_IExecAction, (void**) &pExecAction );
    pAction->Release();
    if( FAILED(hr) )
    {
        printf("\npAction->QueryInterface failed: %x", hr );
        CLEANUP
        return 1;
    }

    //  Set the path of the executable to the user supplied executable.
hr = pExecAction->put_Path( _bstr_t( wstrExecutablePath.c_str() ) );  

//hr = pExecAction->put_Path( (BSTR)wstrExecutablePath );  
    if( FAILED(hr) )
    {
        printf("\nCannot set path of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    hr = pExecAction->put_Arguments( _bstr_t( L"" ) );  
//    hr = pExecAction->put_Arguments( _bstr_t( L"ArgumentsToYourExecutable--HelpFileToOpen" ) );  
   if( FAILED(hr) )
    {
        printf("\nCannot set arguments of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    
    //  ------------------------------------------------------
    //  Save the task in the root folder.
    IRegisteredTask *pRegisteredTask = NULL;
    hr = pRootFolder->RegisterTaskDefinition(
            _bstr_t( wszTaskName ),
            pTask,
        TASK_CREATE, 
_variant_t(_bstr_t( L"S-1-5-32-545")),//Well Known SID for \\Builtin\Users group
_variant_t(), 
TASK_LOGON_GROUP,
            _variant_t(L""),
            &pRegisteredTask);
    if( FAILED(hr) )
    {
        printf("\nError saving the Task : %x", hr );
        CLEANUP
        return 1;
    }
    printf("\n Success! Task successfully registered. " );
for (i=0; i<100; i++)//give 10 seconds for the task to start
{
pRegisteredTask->get_State(&taskState);
if (taskState == TASK_STATE_RUNNING)
{
printf("\nTask is running\n");
break;
}
Sleep(100);
}
if (i>= 100) printf("Task didn't start\n");

//Delete the task when done
    hr = pRootFolder->DeleteTask(
            _bstr_t( wszTaskName ),
            NULL);
    if( FAILED(hr) )
    {
        printf("\nError deleting the Task : %x", hr );
        CLEANUP
        return 1;
    }

    printf("\n Success! Task successfully deleted. " );

//  Clean up.
    CLEANUP
    CoUninitialize();
    return 0;
}