Wann sind unter Windows tatsächlich Administratorrechte nötig? - UAC, geschützte Bereiche und wie man es am Design erkennt

Bei Beratungen rund um Windows vermischen sich oft folgende Themen.

• Wann wird „Als Administrator ausführen“ überhaupt nötig?
• Warum erscheint UAC noch, obwohl ich ein Administratorkonto habe?
• Braucht eine Installation immer Administratorrechte?
• Die App soll in Program Files liegen – bedeutet das auch zur Laufzeit eine Erhöhung?
• Was bewirkt der Unterschied zwischen HKCU und HKLM in der Praxis konkret?
• Wie baut man eine App, bei der „nur ein Teil der Vorgänge“ Administratorrechte braucht?

Diese Frage entscheidet sich nicht allein daran, „ob die Person Administrator ist“. Tatsächlich hängt sie stark davon ab, wohin geschrieben wird, wen die Änderung betrifft, und welchen geschützten Bereich des Betriebssystems sie berührt.

Dieser Artikel ordnet die Situationen, in denen unter Windows Administratorrechte benötigt werden, ausgehend von den Grundlagen von UAC, und fasst praxisnah zusammen, wie weit Standardbenutzerrechte reichen und ab wo es um Erhöhung geht. Der Inhalt basiert auf Microsofts offiziellen Informationen, die Stand März 2026 verifizierbar sind.¹²³⁴⁵

1. Zunächst das Fazit

Vorab nur die praxisrelevanten Kernaussagen.

• Ob unter Windows Administratorrechte nötig sind, entscheidet sich weniger danach, „wie beeindruckend der Vorgang ist“, als vielmehr danach, „ob er das Betriebssystem oder die gesamte Maschine betrifft“.¹⁴
• Verarbeitung, die auf nur das eigene Profil beschränkt bleibt – etwa %AppData%, %LocalAppData%, HKCU oder Documents –, kommt normalerweise ohne Administratorrechte aus.⁶⁷
• Umgekehrt benötigt Verarbeitung, die die gesamte Maschine, alle Benutzer oder geschützte Bereiche berührt – etwa Program Files, Windows, System32, maschinenweite Einstellungen in HKLM / HKCR, Windows-Dienste, Kernel-Treiber, die Firewall oder Aufgaben mit höchster Rechtestufe – tendenziell Administratorrechte.⁴⁶⁸⁹¹⁰
• Wichtig ist hier, dass die Zugehörigkeit des Benutzers zur Gruppe Administrators und die Tatsache, dass die App gerade mit einem Administratorzugriffstoken läuft, zwei verschiedene Dinge sind. Ist UAC aktiviert, laufen gewöhnliche Prozesse auch bei einem Administratorbenutzer mit Standardbenutzerrechten und erhöhen nur bei Bedarf.²⁶
• Installation bedeutet nicht zwangsläufig Administrator. Bei Designs wie der per-user-Installation, die davon ausgehen, unter %LocalAppData% zu installieren, lässt sich ohne Administratorrechte verteilen und aktualisieren.¹¹¹²
• Eine „App, die aus irgendeinem Grund jedes Mal Administratorrechte braucht“, schreibt in Wirklichkeit meist Laufzeitdaten in einen geschützten Bereich, oder deklariert im Manifest requireAdministrator / highestAvailable.⁴¹³
• Auch als künftige Richtung tendiert Windows dazu, nur im nötigen Moment ausdrücklich zu erhöhen. Administrator protection (Vorschau) in Windows 11 zeigt diese Entwicklung recht deutlich.⁵

Kurz gesagt ist es am praxistauglichsten, „braucht es Administratorrechte“ nicht am Titel des Nutzers, sondern an der Grenze, die die App berührt, festzumachen.

2. Was bedeutet „Administratorrechte erforderlich“ überhaupt?

Als Erstes sollte man hier Benutzer und Prozess getrennt betrachten.

UAC unter Windows ist eine Sicherheitsfunktion, die unautorisierte Änderungen am Betriebssystem verhindern soll. Auch bei Microsoft Learn wird erklärt, dass UAC benachrichtigt, wenn Änderungen vorgenommen werden, die Berechtigungen auf Administratorebene erfordern.¹

Darüber hinaus heißt es in der offiziellen Beschreibung von UAC, dass Apps, die ein Administratorzugriffstoken benötigen, den Endbenutzer um Zustimmung bitten, und dass Kindprozesse das Zugriffstoken des Elternprozesses erben, wobei Eltern- und Kindprozess auf derselben Integritätsstufe laufen.²

Daraus lassen sich zwei Dinge ableiten.

2.1 Auch ein „Administratorbenutzer“ läuft nicht ständig als Administrator

Microsoft Learn erklärt, dass bei aktiviertem UAC auch Prozesse, die ein Mitglied der Gruppe Administrators startet, mit Standardbenutzerrechten laufen, sofern sie nicht ausdrücklich erhöht werden.⁶

Der Grund dafür ist, dass bei der Anmeldung eines Administratorbenutzers zwei Zugriffstoken erzeugt werden und im Alltag nur das eingeschränkte davon verwendet wird. Als Diagramm sieht das so aus.²

flowchart TD
    L["Administratorbenutzer meldet sich an"] --> S["Windows erstellt zwei Token"]
    S --> F["Gefiltertes Token<br/>entspricht Standardbenutzer"]
    S --> A["Vollständiges Administratortoken<br/>wird nur bei Erhöhung verwendet"]
    F --> N["Normaler App-Start<br/>auch der Explorer nutzt dies"]
    N --> C["Kindprozess erbt das Token des Elternprozesses<br/>daher auch das Kind Standardbenutzer-äquivalent"]
    N --> Q{"Sollte ein geschützter Bereich<br/>oder Dienst berührt werden?"}
    Q -- "Nein" --> OK["Kann so ausgeführt werden"]
    Q -- "Ja" --> P["UAC-Zustimmungsaufforderung"]
    P --> A
    A --> E["Nur erhöhte Prozesse<br/>können geschützte Bereiche ändern"]

Dass „bei einem Administratorbenutzer trotzdem jedes Mal UAC erscheint“, liegt daran, dass ein Vorgang eintrifft, der nur mit dem vollständigen Administratortoken möglich ist, während mit dem gefilterten Token gestartet wurde. Da das Token beim Start festgelegt wird, lässt sich daraus auch ablesen, dass es nachträglich nur durch das Starten eines neuen Prozesses ergänzt werden kann.

Mit anderen Worten:

• Das eigene Windows-Konto ist ein Administratorkonto
• aber die gerade per Doppelklick gestartete App läuft nicht erhöht
• daher erscheint UAC nur im Moment eines Vorgangs, der Administratorrechte benötigt

Das ist normal.

„Ich bin doch Administrator – warum reichen die Rechte trotzdem nicht?“ ist unter Windows ganz natürliches Verhalten.

2.2 Innerhalb desselben Prozesses lässt sich nicht „nur dieser eine Vorgang plötzlich als Administrator“ ausführen

UAC ist keine Magie auf Funktionsebene, sondern dreht sich darum, mit welchem Token ein Prozess läuft. Da Eltern- und Kindprozesse das Token vererben, lässt sich das Design „innerhalb eines nicht erhöhten UI-Prozesses nur im Moment eines Tastendrucks einzelne Methoden desselben Prozesses zu Administratormethoden machen“ nicht umsetzen.²

Bei Bedarf:

• in eine separate EXE auslagern
• einen Dienst nutzen
• eine Aufgabe mit höchster Rechtestufe nutzen
• erhöhtes COM nutzen

Man muss auf eine solche separate Ausführungseinheit zurückgreifen.¹⁴

Wird ohne Kenntnis dieser Voraussetzung entworfen, entsteht meist die etwas leidige Anfrage: „Wir möchten nur diese eine Schaltfläche als Administrator ausführen“.

Die hier genannten zwei Punkte sind zudem eine häufige Quelle von Missverständnissen, daher greifen wir sie in Kapitel 9 „Häufige Missverständnisse“ noch einmal im Q&A-Format auf. Für interne Erklärungen dürfte Kapitel 9 kürzer und leichter zu zitieren sein.

3. Wovon es abhängt - zunächst die Erkennungsmerkmale

Die klarsten Erkennungsmerkmale sind die folgenden drei.

1. Wohin wird geschrieben?
2. Wen betrifft die Änderung?
3. Wird etwas berührt, das das Betriebssystem schützt?

3.1 Typische Bereiche, in denen Schreiben eine Erhöhung erfordert

Da dies die Grundlage für die folgenden Einzelabschnitte bildet, listen wir zunächst die Bereiche auf, bei denen „ein Schreibversuch eine Erhöhung erfordert“. Fast alles, was ab Kapitel 4 folgt, lässt sich einer der Zeilen dieser Tabelle zuordnen.

Klar „nicht erforderlich“ ist nur die letzte Zeile, C:\ProgramData ist bedingt, der Rest liegt komplett auf der Seite der Erhöhung. Umgekehrt gesagt entscheidet ob sich die Schreibziele der App auf diese letzte Zeile und %ProgramData% konzentrieren lassen, fast vollständig darüber, ob eine Erhöhung nötig ist.⁴⁶⁷

3.2 Entscheidungstabelle nach Vorhaben

Stellt man das von der Seite des „Vorhabens“ aus dar, ergibt sich Folgendes. Die Einstufung wurde einheitlich auf Erforderlich / Situationsabhängig / Nicht erforderlich vereinheitlicht.

Ziemlich grob zusammengefasst:

• Bei Änderungen für sich selbst kommt man meist mit Standardbenutzerrechten aus
• Bei Änderungen für alle ist meist ein Administrator im Spiel
• Wird die Sicherheitsgrenze des Betriebssystems berührt, ist ein Administrator erforderlich

Betrachtet man zuerst nur diese drei Punkte, lässt sich „warum UAC erscheint“ deutlich leichter erklären.

4. Typische Fälle, in denen Administratorrechte häufig nötig sind

4.1 Installation, Aktualisierung und Deinstallation für alle Benutzer

In Microsoft Learns Erläuterung der UAC-Architektur heißt es, dass viele Installationsprogramme in Systemverzeichnisse oder Registrierungsschlüssel schreiben, wofür Standardbenutzer nicht über ausreichende Zugriffsrechte verfügen, und dass Windows Installationsprogramme erkennt und eine Erhöhung anfordert.³

Wichtig ist hier, dass nicht der Installer an sich „privilegiert“ ist, sondern eine Erhöhung nötig ist, weil das Schreibziel ein geschützter Bereich ist.

Typisch sind etwa:

• Ablage in Program Files
• Schreiben maschinenweiter Informationen nach HKLM
• COM-Registrierung oder -Integration für alle Benutzer
• Installation von Diensten oder Treibern
• Ein maschinenweiter Aktualisierungspfad

In diesen Fällen sind Administratorrechte meist erforderlich.³⁸

4.2 Laufzeitdaten nach Program Files oder HKLM schreiben

Auch das kommt ziemlich häufig vor. Microsofts UAC-Designleitfaden erklärt, dass unnötige Erhöhungen vermieden werden sollten und viel alte Software unnötig Administratorrechte benötigt, weil sie nach HKLM / HKCR oder in die Ordner Program Files / Windows System schreibt.⁴

Ferner steht in der Beschreibung von Standardbenutzern ausdrücklich, dass diese weder in den Ordner Program Files noch nach HKEY_LOCAL_MACHINE schreiben können, noch systemverändernde Vorgänge durchführen können.⁶

Das heißt:

• Konfigurationsdateien
• Protokolle
• Caches
• Benutzerspezifischer Zustand
• Verlauf zuletzt verwendeter Elemente

Solche zur Laufzeit veränderlichen Daten im Installationsordner oder in HKLM abzulegen, führt allein schon leicht dazu, dass „diese App nur als Administrator gestartet funktioniert“.

Und das entsteht nicht selten nicht deshalb, weil die App wirklich für Administratoren gedacht ist, sondern schlicht, weil die Wahl des Speicherorts ungünstig ist.

4.3 Registrieren oder Umkonfigurieren von Windows-Diensten

Da Dienste vom Betriebssystem verwaltet werden, lassen sie sich naturgemäß nicht leichtfertig anfassen.

Die offizielle Dokumentation zu den Zugriffsrechten des Dienststeuerungs-Managers erklärt, dass für den Aufruf von CreateService SC_MANAGER_CREATE_SERVICE erforderlich ist und dass nur ein Prozess mit Administrator privileges das für CreateService nutzbare Handle öffnen kann.⁸

Außerdem sollte SERVICE_CHANGE_CONFIG, das für ChangeServiceConfig / ChangeServiceConfig2 benötigt wird, nur an Administratoren vergeben werden, weil sich damit die vom System ausgeführte EXE ändern lässt.⁸

Deshalb setzen Vorgänge wie

• das Registrieren eines Dienstes
• das Ändern der ausführbaren Datei oder des Starttyps eines Dienstes
• das Löschen eines Dienstes
• das Ändern des Sicherheitsdeskriptors eines Dienstes

Administratorrechte voraus.

4.4 Installation eines Kernel-Treibers

Microsoft Learn erklärt, dass ein Standardbenutzer systemverändernde Aufgaben wie die Installation eines kernel-mode driver nicht ausführen kann.⁶

Das ist eine ziemlich klare Grenze. Da Treiber auf der Kernel-Seite laufen, lassen sie sich nicht auf eine Stufe mit dem gewöhnlichen „Speichern von Einstellungen einer Benutzer-App“ stellen.

• Installation eines Gerätetreibers
• Installation eines virtuellen Treibers oder Filtertreibers
• Änderung von Komponenten, die Boot oder I/O betreffen

Bei solchen Vorgängen kann man davon ausgehen, dass Administratorrechte nötig sind.

4.5 Konfiguration von Firewall und Aufgaben mit hoher Rechtestufe

Auch die Firewall ist Teil der Sicherheitsgrenze des Betriebssystems. Microsoft Learns Anleitung zur Firewall-Konfiguration hält ausdrücklich fest, dass für die Bedienung von Windows Firewall with Advanced Security auf einem einzelnen Gerät administrative rights auf diesem Gerät erforderlich sind.⁹

Zum Taskplaner ist zudem definiert, dass TASK_RUNLEVEL_LUA mit minimalen Rechten und TASK_RUNLEVEL_HIGHEST mit den höchsten Rechten ausgeführt wird, und auch die schtasks-Dokumentation besagt, dass man Mitglied der Gruppe Administrators sein muss, um alle Aufgaben auf dem lokalen Computer zu planen, anzuzeigen oder zu ändern.¹⁰

Zusammengefasst liegen Konfigurationen wie

• das Hinzufügen oder Ändern von Windows-Firewall-Regeln
• das Registrieren eines bestimmten Vorgangs als Aufgabe mit höchster Rechtestufe
• das Ausführen eines Jobs unter einem anderen Benutzer oder als SYSTEM

auf der Seite, die Administratorrechte benötigt.

5. Typische Fälle, die oft tatsächlich ohne Administratorrechte auskommen

Es wirkt leicht so, als würde „Windows sofort einen Administrator verlangen“, doch tatsächlich gibt es überraschend viele Bereiche, die sich so gestalten lassen, dass keine Administratorrechte nötig sind.

5.1 Eigene Einstellungen, Cache und Protokolle

Microsoft Learn erklärt, dass sich Apps nicht auf Virtualisierung für Kompatibilität verlassen, sondern entweder in einer per-user location oder in einer computer location innerhalb von %alluserprofile% mit korrekt gesetzter ACL speichern sollten.⁷

In der Praxis lässt sich das mit folgender Aufteilung übersichtlich gestalten.

• Benutzerspezifisch: %AppData%, %LocalAppData%, HKCU
• Gemeinsam genutzt, aber zur Laufzeit aktualisiert: %ProgramData% + ACL-Design
• Die ausführbare Datei selbst: geschützte Bereiche wie Program Files

Ist diese Trennung umgesetzt, lässt sich erreichen, dass die Installation der App selbst zwar Administratorrechte braucht, die alltägliche Nutzung aber ohne Administrator auskommt.

5.2 per-user-Installation und -Aktualisierung

Auch in Microsofts offizieller Dokumentation tauchen Beispiele für per-user-Bereitstellung ganz selbstverständlich auf.

In der Dokumentation des Remote Desktop-Clients wird etwa erklärt, dass die per-user-Installation unter dem LocalAppData jedes Benutzerprofils erfolgt und der Benutzer ohne Administratorrechte aktualisieren kann.¹¹

Auch in der OneDrive-Dokumentation heißt es, dass standardmäßig per-user installiert wird und dass bei einer per-machine-Installation der Befehl mit /allusers ausgeführt wird, wodurch in der Folge eine UAC-Aufforderung erscheint. Zudem landet per-user unter %localappdata%, per-machine unter Program Files.¹²

Daraus wird deutlich, dass allein das Wort „Installation“ nicht darüber entscheidet, ob Administratorrechte nötig sind.

• Installiert jeder Benutzer in seinen eigenen Bereich, kommt man teilweise ohne Administrator aus
• Wird in einen für alle Benutzer gemeinsamen Bereich installiert, ist meist ein Administrator nötig

Wichtig ist, zuerst festzulegen, ob per-user oder per-machine.

5.3 Normale UI-Bedienung und Fachlogik

Umgekehrt benötigen folgende Vorgänge für sich genommen keine Administratorrechte.

• Öffnen von Dokumenten oder Bildern
• Bearbeiten von Dateien im eigenen Profil
• HTTP- oder Datenbankkommunikation
• Ausführen von Fachlogik
• Anzeigen von Ergebnissen auf dem Bildschirm
• Lesen und Schreiben eigener Einstellungen

Wenn trotzdem „die gesamte App als Administrator ausführen“ nötig ist, liegt die Ursache meist nicht in der Kernfunktion der App, sondern darin, dass ein Randvorgang einen geschützten Bereich berührt.

6. Warum heißt es „Diese App braucht Administratorrechte“?

6.1 Das Manifest deklariert requireAdministrator

Im Anwendungsmanifest lässt sich über requestedExecutionLevel die benötigte Berechtigungsstufe deklarieren. Microsoft Learn definiert die folgenden drei.¹³

• asInvoker: läuft mit denselben Rechten wie der startende Prozess
• highestAvailable: läuft mit den höchsten verfügbaren Rechten
• requireAdministrator: läuft mit Administratorrechten

Ist eine App auf requireAdministrator gesetzt, wird bei jedem Start eine Erhöhung vorausgesetzt. Auch bei highestAvailable kann je nach Umgebung eine Erhöhung ins Spiel kommen.¹³

Die naheliegendste Antwort auf „warum erscheint UAC jedes Mal“ lautet daher: weil die App das so deklariert.

6.2 Die App wird von Windows’ installer detection erfasst

Die Erläuterung der UAC-Architektur besagt, dass Windows über eine installer detection technology verfügt und dass viele Installationsprogramme in protected system locations schreiben, wodurch eine Erhöhung nötig wird.³

Und das liegt nicht einfach daran, dass die Datei setup.exe heißt, sondern Windows trifft in gewissem Umfang heuristisch die Einschätzung „das sieht nach einem Installer aus“. Die offizielle Dokumentation nennt dafür folgende Kriterien.³

• 32-Bit-ausführbare Datei
• Kein requestedExecutionLevel-Attribut vorhanden
• Interaktiver Prozess eines Standardbenutzers bei aktiviertem UAC
• Der Dateiname enthält Wörter wie install, setup, update und Ähnliches

Dass SetupLauncher.exe oder Updater.exe plötzlich eine Erhöhung anfordern, ist daher aufgrund des Designs von Windows nicht verwunderlich.

6.3 Eine Legacy-App „lief nur zufällig“ dank Virtualisierung

Das wird ziemlich häufig missverstanden.

Microsoft Learn erklärt, dass UAC für nicht konforme Apps, die in geschützte Bereiche schreiben wollen, eine Datei- und Registrierungsvirtualisierung bereitstellt. Gleichzeitig wird ausdrücklich festgehalten, dass dies eine kurzfristige Kompatibilitätsmaßnahme ist, keine langfristige Lösung.³⁷

Zudem hat die Virtualisierung Einschränkungen.

• Sie gilt nicht für bereits erhöhte Apps
• Sie gilt nur für 32-Bit-Apps
• Sie wird deaktiviert, sobald ein Manifest mit requestedExecutionLevel vorhanden ist
• Eigentlich sollten Apps so korrigiert werden, dass sie an den richtigen Ort schreiben

Das sind die Bedingungen.³⁷

Es kann also vorkommen, dass eine alte 32-Bit-App „scheinbar auch ohne Administrator nach Program Files schreiben konnte“ – das bedeutet aber möglicherweise nicht, dass korrekt geschrieben wurde, sondern lediglich, dass in den VirtualStore ausgewichen wurde.

Aus diesem Grund kann bei Anlässen wie

• der Umstellung auf 64-Bit
• dem Hinzufügen eines Manifests
• einer Änderung der Build-Methode
• dem Voranbringen der UAC-Konformität

ein zuvor nicht sichtbarer „Designfehler beim Speicherort“ plötzlich zum Vorschein kommen.

6.4 Die zur Laufzeit berührten Orte sind von vornherein ungeeignet

In der Praxis ist das letztlich der häufigste Fall.

• Einstellungen neben der EXE speichern
• Protokolle in den Installationsordner schreiben
• Temporäre Dateien unter Program Files anlegen
• Benutzerspezifischen Zustand nach HKLM schreiben

Bei einer solchen Konfiguration entsteht die ziemlich unhandliche Situation, dass die App im Kern eine gewöhnliche UI ist, ihr Start aber Administratorrechte erfordert.⁴⁶

Der Fall „Administrator, weil der Speicherort schlecht gewählt ist“ statt „Administrator, weil der Vorgang anspruchsvoll ist“, kommt wirklich sehr häufig vor.

6.5 Vorgehen, um festzustellen, welcher Fall bei der eigenen App zutrifft

6.1 bis 6.4 sind „Ursachentypen“, aber bei der tatsächlichen Untersuchung muss geklärt werden, welcher davon auf die eigene App zutrifft. Dafür genügen die folgenden zwei Schritte.

Schritt 1: Das requestedExecutionLevel im Manifest prüfen

Zunächst wird geprüft, ob die App selbst eine Erhöhung deklariert. Das in die EXE eingebettete Manifest lässt sich mit mt.exe aus dem Windows SDK extrahieren.

mt.exe -inputresource:MyApp.exe;#1 -out:MyApp.manifest

#1 ist die Ressourcen-ID des in die ausführbare Datei eingebetteten Manifests. Prüfen Sie im extrahierten XML, ob eine Zeile wie die folgende vorhanden ist.

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

Steht dort requireAdministrator, ist die Ursache mit 6.1 geklärt. Bei asInvoker liegt es nicht an der Deklaration, also weiter zu Schritt 2. Es kann auch sein, dass gar kein Manifest eingebettet ist. Auch das ist eine wichtige Information: Eine 32-Bit-ausführbare Datei ohne requestedExecutionLevel kann sowohl unter die installer detection aus 6.2 als auch unter die Virtualisierung aus 6.3 fallen.³

Schritt 2: Prüfen, ob im VirtualStore eine Kopie entstanden ist

Als Nächstes wird geprüft, ob eine vermeintlich in einen geschützten Bereich geschriebene Datei in Wirklichkeit virtualisiert wurde. Das Umleitungsziel ist fest definiert.

dir /s /a "%LocalAppData%\VirtualStore"

Finden sich hier die Konfigurationsdateien oder Protokolle der eigenen App, bedeutet das, die App konnte nicht wirklich nach Program Files schreiben, sondern wurde in eine benutzerspezifische Kopie umgeleitet. Ein Schreibvorgang nach C:\Program Files\Contoso\Settings.ini wird zum Beispiel nach %LocalAppData%\VirtualStore\Program Files\Contoso\Settings.ini umgeleitet.³

Das Virtualisierungsziel auf der Registrierungsseite verhält sich ähnlich: Ein Schreibvorgang nach HKEY_LOCAL_MACHINE\Software wird nach HKEY_USERS\<SID des Benutzers>_Classes\VirtualStore\Machine\Software umgeleitet. Aus Sicht des aktuellen Benutzers lässt sich dasselbe sehen, wenn im Registrierungs-Editor HKEY_CURRENT_USER\Software\Classes\VirtualStore\Machine\Software geöffnet wird.⁷

Betrachtet man diese beiden Schritte, wird klar, ob die Ursache für „Administratorrechte erforderlich“ in der Deklaration oder im Speicherort liegt. Liegt die Ursache im Speicherort, besteht der eigentliche Weg darin, den Ablageort wie in 7.3 zu korrigieren – eine zusätzliche Erhöhung ist keine Lösung.

7. Wie lässt sich das Design gestalten, um unnötige Erhöhungen zu reduzieren?

7.1 Die Grundlage ist asInvoker

Solange die gesamte App nicht wirklich ein Systemverwaltungswerkzeug ist, lautet die Grundlinie, die gewöhnliche UI-App nicht erhöht laufen zu lassen. Auch inhaltlich ist asInvoker im Manifest die Deklaration „läuft mit denselben Rechten wie der Aufrufer“.¹³

Lässt man alles – normale Bildschirmbedienung, Fachlogik und sogar das Speichern benutzerspezifischer Einstellungen – als Administrator laufen, nehmen folgende Probleme zu:

• Die Angriffsfläche wird größer
• Der Betrieb lässt sich schwerer erklären
• UAC erscheint jedes Mal
• Es wird unsichtbar, „welcher Vorgang wirklich einen Administrator braucht“

Auch Microsofts UAC-Designleitfaden erklärt, dass unnötige Erhöhungen vermieden werden sollten und Administratorrechte nur für Aufgaben nötig sein sollten, die sie wirklich brauchen.⁴

7.2 Nur die Administratorrechte benötigenden Vorgänge in eine separate Ausführungseinheit auslagern

Microsoft Learn stellt ausdrücklich Modelle vor, bei denen eine App mit Administratorrechte benötigenden Vorgängen dennoch als Standardbenutzer-App läuft und nur die nötigen Teile abgetrennt werden.¹⁴

Die vier gängigen sind:

• Administrator Broker Model Standardbenutzer-UI-App + Administrator-Helper-EXE
• Operating System Service Model Standardbenutzer-UI + residenter Dienst
• Elevated Task Model Standardbenutzer-UI + geplante Aufgabe mit höchster Rechtestufe
• Administrator COM Object Model Standardbenutzer-UI + erhöhtes COM

Grob lässt sich das so einteilen:

• Bei nur gelegentlichen Administratorvorgängen: Helper-EXE
• Bei ständig, unbeaufsichtigt, häufig: Dienst
• Bei kurzen, wiederkehrenden Jobs: Aufgabe mit höchster Rechtestufe
• Bei vorausgesetztem bestehendem COM: erhöhtes COM

Wie sich dieses Design in einer Windows-App konkret umsetzen lässt, wird ausführlich im separaten Artikel Wie man in einer Windows-App konkret nur die „Vorgänge, die Administratorrechte brauchen“ isoliert behandelt.

7.3 Den Ablageort von Laufzeitdaten korrekt wählen

Das Prinzip für den Speicherort ist recht einfach.

• Benutzerspezifische Daten: HKCU oder %AppData%
• Rein lokaler Cache: %LocalAppData%
• Gemeinsam genutzte, aber zur Laufzeit veränderliche Daten: %ProgramData% + ACL
• Die ausführbare Datei selbst: Program Files

Auch Microsoft Learn erklärt, dass Apps entweder in einer per-user location oder in %alluserprofile% (faktisch ProgramData) mit korrekt gesetzter ACL speichern sollten.⁷

Mit dieser Ordnung lässt sich leichter erreichen, dass nur der Installer erhöht wird, während die laufende App nicht erhöht ist.

7.4 per-user und per-machine zuerst festlegen

Das wird überraschend leicht übersehen.

• Sollte die App von jedem Benutzer selbst installiert werden können?
• Sollte sie an einem gemeinsamen Ort für alle Benutzer installiert werden?
• Wer trägt die Verantwortung für Aktualisierungen?
• Darf die ausführbare Datei aus dem Benutzerprofil heraus laufen?

Bleibt diese Entscheidung unklar, entsteht später leicht ein Durcheinander wie:

• Administrator nur für die Installation
• Administrator auch für die Ausführung
• Administrator auch für Aktualisierungen
• nur ein Teil im Benutzerkontext

Der Unterschied zwischen per-user und per-machine ist nicht bloß eine Frage der Verteilungsart, sondern das Berechtigungsdesign selbst.

8. Wohin entwickelt sich Windows künftig?

Stand März 2026 verfügt Windows 11 über eine Funktion namens Administrator protection (Vorschau). Microsoft Learn beschreibt diese Funktion als eine, die im Normalbetrieb einen deprivileged state beibehält und admin rights nur bei Bedarf just-in-time gewährt.⁵

Darüber hinaus erklärt Microsoft, dass vor Vorgängen, die Administratorrechte erfordern – etwa die Installation von Software, das Ändern von Systemeinstellungen wie Uhrzeit oder Registrierung, oder der Zugriff auf sensible Daten –, eine ausdrückliche Authentifizierung verlangt wird.⁵

Die Funktion selbst befindet sich noch in der Vorschau, und auch die allgemeine Einführung erfolgt schrittweise.⁵

An dieser Stelle lohnt es sich, auch die praktische Bedeutung des Vorschau-Status festzuhalten. Bei mit „Vorschau“ gekennzeichneten Funktionen können sich Verhalten und Einstellungsoptionen bis zur allgemeinen Verfügbarkeit noch ändern, und es lässt sich ohnehin nicht in jeder Umgebung aktivieren. Daher ist es derzeit sicherer, folgende Nutzungsweisen zu vermeiden.

• Unternehmensweite Ausrollung als Standardkonfiguration für den Produktivbetrieb
• Das Erhöhungsdesign der App unter der Annahme weglassen, dass diese Funktion aktiviert ist
• Diese Funktion als verpflichtende Betriebsvoraussetzung für Kundenumgebungen festlegen

Der realistische Ansatz besteht darin, das Verhalten in einer Testumgebung zu prüfen und das Design nur unter der Annahme „das wird sich künftig in diese Richtung entwickeln“ anzupassen. Umgekehrt gilt: Minimiert man Erhöhungen schon jetzt mit asInvoker als Basis, muss man nicht in Eile geraten, sobald diese Funktion allgemein verfügbar wird.

Die Richtung ist jedoch ziemlich klar.

• Kein dauerhaftes Halten eines Administratortokens
• Erhöhung nur im nötigen Moment
• Isolation erhöhter Sitzungen
• Klarere Nachvollziehbarkeit, wann, welche App und warum zum Administrator wurde

Man kann also davon ausgehen, dass ein Design nach dem Motto „läuft erst mal alles als Administrator“ künftig zunehmend schlechter passt.

9. Häufige Missverständnisse

9.1 „Ich bin Administratorbenutzer, also sollte UAC nicht erscheinen“

Es erscheint doch. Bei aktiviertem UAC laufen gewöhnliche Prozesse auch bei Mitgliedern der Gruppe Administrators nicht erhöht und erhöhen nur bei Bedarf.⁶²

9.2 „Bei einer Installation ist immer ein Administrator nötig“

Nicht zwingend. Es gibt Designs, die sich ohne Administratorrechte verteilen lassen, etwa eine per-user-Installation nach %LocalAppData%.¹¹¹²

9.3 „Da die App in Program Files liegt, dürfen auch die Einstellungen dort gespeichert werden“

Das ist nicht in Ordnung. Der Ablageort der ausführbaren Datei und der Speicherort für zur Laufzeit veränderliche Daten sollten getrennt werden. Auch Microsoft nennt das Schreiben nach Program Files oder HKLM zur Laufzeit als typisches Beispiel für unnötige Erhöhung.⁴⁷

9.4 „Wenn man es nur als Administrator ausführt, lösen sich alle Designprobleme“

Das lösen sie nicht. Es mag vorübergehend funktionieren, doch Angriffsfläche, Betriebsfreundlichkeit, Verteilung und Supportfähigkeit verschlechtern sich meist. Zudem lässt sich nicht bequem nur ein Teil desselben Prozesses erhöhen.²¹⁴

9.5 „Es hat früher funktioniert, also ist es auch heute richtig“

Das stimmt nicht unbedingt. Wenn eine alte 32-Bit-App nur dank Virtualisierung „zufällig funktioniert hat“, tritt das Problem bei der Umstellung auf 64-Bit oder beim Hinzufügen eines Manifests zutage. Virtualisierung ist eine vorübergehende Kompatibilitätsmaßnahme, keine langfristige Lösung.³⁷

10. Zusammenfassung

Ob unter Windows Administratorrechte nötig sind, entscheidet sich kurz gesagt danach, „wohin was geändert wird“.

• Bei Änderungen für sich selbst kommt man meist mit Standardbenutzerrechten aus
• Bei Änderungen für alle Benutzer / die gesamte Maschine ist meist ein Administrator nötig
• Wird ein geschützter Bereich oder eine Sicherheitsgrenze des Betriebssystems berührt, sind Administratorrechte erforderlich

Und was in der Praxis wirklich zählt, ist, Vorgänge, die wirklich Administratorrechte benötigen, von Vorgängen, die nur wegen des Speicherorts zufällig einen Administrator benötigen, zu trennen.

Besonders in der Windows-Anwendungsentwicklung sind folgende Leitlinien recht wirksam.

• Die UI grundsätzlich nicht erhöht laufen lassen
• Administratorvorgänge in eine separate EXE / einen Dienst / eine Aufgabe auslagern
• Laufzeitdaten nach AppData / HKCU / ProgramData verlagern
• per-user / per-machine zuerst festlegen

„Braucht es Administratorrechte“ ist keine Frage davon, wie bedeutend eine App ist. Es ist eine Frage davon, welche Grenze des Betriebssystems berührt wird.

Behält man diese Sichtweise von Anfang an im Kopf, werden das Verhalten von UAC, die Wahl der Installationsmethode und das App-Design deutlich überschaubarer.

11. Verwandte Artikel

• Wie man in einer Windows-App konkret nur die „Vorgänge, die Administratorrechte brauchen“ isoliert
• Eine Mindest-Sicherheitscheckliste für die Windows-Anwendungsentwicklung
• Windows-App-Verteilung wählen – MSI/MSIX/ClickOnce/xcopy/eigener Updater

12. Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Warum erscheint die Meldung „Für den angeforderten Vorgang sind Administratorrechte erforderlich“?

Weil die App eine Grenze berührt, die sich auf das Betriebssystem oder die gesamte Maschine auswirkt. Typisch sind das Schreiben in geschützte Bereiche wie Program Files, Windows, System32 oder HKLM, das Registrieren oder Umkonfigurieren von Windows-Diensten, die Installation eines Kernel-Treibers oder das Ändern von Firewallregeln. Auch wenn im Manifest der App requireAdministrator deklariert ist, oder wenn der Dateiname Wörter wie install / setup / update enthält und dadurch von Windows' installer detection erfasst wird, wird eine Erhöhung angefordert. Sehr häufig liegt es nicht daran, dass der Vorgang anspruchsvoll ist, sondern schlicht daran, dass der Speicherort für Einstellungen oder Protokolle in einem geschützten Bereich liegt.

Warum erscheint UAC, obwohl ich ein Administratorkonto verwende?

Weil bei aktiviertem UAC auch Prozesse, die von einem Mitglied der Gruppe Administrators gestartet wurden, mit Standardbenutzerrechten laufen, solange sie nicht ausdrücklich erhöht werden. Auch wenn das eigene Windows-Konto ein Administratorkonto ist, läuft die gerade gestartete App nicht erhöht, und dass UAC nur im Moment eines Vorgangs erscheint, der Administratorrechte benötigt, ist unter Windows ganz normales Verhalten. Man muss die Zugehörigkeit des Benutzers zur Gruppe Administrators und die Tatsache, dass die App gerade mit einem Administratorzugriffstoken läuft, als zwei getrennte Dinge betrachten.

Braucht die Installation einer App zwingend Administratorrechte?

Nicht zwingend. Bei einer per-user-Installation unter %LocalAppData% gibt es Designs, die sich ohne Administratorrechte verteilen und aktualisieren lassen. Als konkretes Beispiel: Die per-user-Installation des Remote Desktop-Clients landet im LocalAppData jedes Benutzerprofils und lässt sich ohne Administratorrechte aktualisieren, und auch OneDrive wird standardmäßig per-user installiert. Administratorrechte werden eher bei einer für alle Benutzer gedachten (per-machine) Installation benötigt, die nach Program Files oder HKLM schreibt. Ob per-user oder per-machine, ist keine Frage der Verteilungsart, sondern das Berechtigungsdesign selbst – deshalb sollte das zuerst festgelegt werden.

Lässt sich nur ein Teil der Vorgänge einer App mit Administratorrechten ausführen?

Innerhalb desselben Prozesses lässt sich nicht „nur in dem Moment, in dem diese Schaltfläche gedrückt wird, einzelne Methoden zu Administratormethoden machen“. UAC dreht sich darum, mit welchem Token ein Prozess läuft, und Eltern- und Kindprozesse vererben dieses Token. Bei Bedarf trennt man das in eine separate Ausführungseinheit ab. Die vier gängigen Modelle sind das Administrator Broker Model, das eine Standardbenutzer-UI mit einer Administrator-Helper-EXE kombiniert, das Operating System Service Model mit einem residenten Dienst, das Elevated Task Model mit einer geplanten Aufgabe höchster Rechtestufe, und das Administrator COM Object Model mit erhöhtem COM.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.