Der tägliche Arbeitsplatz darf kein Administrationskonto brauchen

Auf dem Client ist UAC eingeschaltet. Trotzdem gehört das tägliche Benutzerkonto zur lokalen Administratorengruppe, weil ein Fachprogramm gelegentlich Updates installiert. Der Support bestätigt Erhöhungen per Fernwartung, und für schwierige Fälle werden Domänenadministrator-Zugangsdaten eingegeben. Im Prüfbericht erscheint die Benutzerkontensteuerung als aktiv; die Trennung zwischen Alltagsarbeit und Administration existiert praktisch nicht.

Für Active Directory entsteht das Risiko durch die Verbindung dieser Gewohnheiten: Ein gewöhnlicher Arbeitsplatz wird zum Einsatzort weitreichender Berechtigungen. UAC kann bewusste Freigaben unterstützen. Die eigentliche Verbesserung beginnt jedoch beim Entzug unnötiger Administratorrechte und bei einem Administrationsweg, der ohne privilegierte Zugangsdaten in Alltagssitzungen auskommt.

Dieser Baustein betrifft verwaltete, unterstützte Windows-Clients und Mitgliedsserver mit klassischem UAC. Domain Controller erhalten einen gesondert geprüften Administrationspfad. Windows-11-Geräte mit aktiviertem Administrator protection benötigen eine eigene Bewertung: Dessen Modell mit profilgetrennter administrativer Identität ist nicht mit klassischem UAC gleichzusetzen.

Zielbild: Standardbenutzer im Alltag, begrenzte Rechte pro Aufgabe

Das tägliche Konto hat keine direkten oder verschachtelt geerbten lokalen Administratorrechte. E-Mail, Browser, Zusammenarbeit und Fachanwendungen laufen damit ohne regelmäßige Erhöhungen. Installationen und systemweite Updates kommen aus einem verwalteten Verfahren.

Für Administration existieren personenbezogene, getrennte Konten mit einem definierten Geräte- und Aufgabenbereich. Ein Client-Administrationskonto erhält dadurch keine Server- oder Domänenrechte. Besonders privilegierte AD-Konten werden nur auf dafür freigegebenen, geschützten Administrationssystemen verwendet. Ein anderer Benutzername auf demselben unzuverlässigen Arbeitsplatz genügt dafür nicht.

Die Betriebsabnahme verlangt außerdem einen nutzbaren Supportweg: Wer genehmigt eine Ausnahme, wie wird sie umgesetzt, wie lange gilt sie und welcher Nachweis bleibt? Erst wenn dieser Weg funktioniert, werden interaktive Erhöhungsanforderungen gewöhnlicher Benutzer automatisch abgewiesen.

Warum ein gefiltertes Administratortoken nicht genügt

Bei klassischem UAC arbeitet ein Mitglied der lokalen Administratorengruppe normalerweise zunächst mit einem gefilterten Token. Bei einer Erhöhung wird der administrative Token genutzt. Das Konto bleibt trotzdem administrativ berechtigt; der Zustimmungsdialog ist keine belastbare Sicherheitsgrenze gegenüber Schadcode innerhalb dieser administrativen Benutzerumgebung.

Ein echtes Standardbenutzerkonto besitzt diese lokale Administrationsberechtigung nicht. Das ist der entscheidende Unterschied. Auch damit kann Schadcode auf zugängliche Benutzerdateien zugreifen oder vorhandene Anwendungsrechte missbrauchen. Least Privilege begrenzt Befugnisse, beseitigt aber weder Schwachstellen noch jeden möglichen Weg zur Rechteausweitung.

Auch ein erhöhter Prozess bleibt sorgfältig zu behandeln. Von ihm gestartete Programme können dessen Rechte erben; ein UAC-Dialog ist kein Freigabemechanismus für jeden einzelnen Folgeschritt. Eine dauerhaft erhöhte Konsole ist daher keine geeignete Arbeitsumgebung für allgemeine Tätigkeiten.

Vier Richtlinien für eine nachvollziehbare UAC-Baseline

Eine eigene Computer-GPO wird zunächst an eine Pilot-OU gebunden. Der Pfad lautet Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen. Die englischen Namen helfen bei abweichenden Übersetzungen. Die folgenden Werte beschreiben eine bewusst gewählte Projektbaseline, keine vollständige Windows-Sicherheitsbaseline.

UAC als Voraussetzung eingeschaltet lassen

„User Account Control: Run all administrators in Admin Approval Mode“ auf Enabled setzen. Der zugehörige Wert ist EnableLUA = 1. Die übrigen UAC-Regeln setzen diese Aktivierung voraus. Wird diese Einstellung geändert, ist ein Neustart erforderlich; ein erfolgreicher GPO-Abgleich allein ist kein Wirksamkeitsnachweis.

Das integrierte Administratorkonto ist gesondert zu prüfen. Seine eigene Admin-Approval-Mode-Einstellung entscheidet über dessen Verhalten. Es wird nicht als tägliches Arbeitskonto eingesetzt. Wird es für einen dokumentierten Notfallweg benötigt, müssen dessen UAC-Verhalten, Zugang und Wiederherstellung ausdrücklich getestet werden.

Administratoren bewusst bestätigen lassen

„User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode“ auf Prompt for consent on the secure desktop setzen. Erwartet wird ConsentPromptBehaviorAdmin = 2.

Der berechtigte Administrator bestätigt eine angeforderte Erhöhung im geschützten Dialog. Das ist weder MFA noch eine unabhängige Genehmigung durch eine zweite Person. Die Freigabeentscheidung muss zum gestarteten Programm und zur geplanten Aufgabe passen. Häufige, unverständliche Dialoge sind ein Anlass, den Arbeitsablauf zu verbessern.

Den sicheren Desktop verwenden

„User Account Control: Switch to the secure desktop when prompting for elevation“ auf Enabled setzen; erwartet wird PromptOnSecureDesktop = 1. Der echte Erhöhungsdialog wird vom gewöhnlichen Benutzerdesktop getrennt dargestellt.

Das schützt den Dialog gegen bestimmte Manipulationen aus normalen Benutzerprozessen. Es bescheinigt weder dem angeforderten Programm Vertrauenswürdigkeit noch einem bereits kompromittierten System Integrität. Vorhandene UIAccess-Ausnahmen und die tatsächlich verwendete Fernwartung müssen im Pilot auf ihre Wechselwirkung mit dem sicheren Desktop geprüft werden.

Standardbenutzer nicht zur Passworteingabe auffordern

„User Account Control: Behavior of the elevation prompt for standard users“ auf Automatically deny elevation requests setzen; erwartet wird ConsentPromptBehaviorUser = 0. Der normale interaktive UAC-Weg liefert dann eine Ablehnung statt eines Feldes für Administrator-Zugangsdaten.

Diese Einstellung erteilt keine Ersatzberechtigung. Wenn der bisherige Support ausschließlich ein Passwort in diesen Dialog eingibt, fällt dieser Ablauf aus. Softwareverteilung, ein eng geregeltes Endpoint-Privilege-Management oder ein geeigneter IT-Wartungsweg müssen vorher nachweislich funktionieren. Die Policy verhindert nicht generell jede Ausführung administrativer Aufgaben durch verwaltete Dienste oder andere autorisierte Verfahren.

Softwareverteilung und Support vor dem Rechteentzug vorbereiten

Erfassen Sie zunächst die tatsächlich benötigten privilegierten Vorgänge: Installation, Update, Treiberwechsel, VPN-Reparatur, fachliche Spezialfunktionen und Notfallhilfe. Prüfen Sie, ob ein Programm nur während der Installation erhöhte Rechte braucht oder bei jedem Start. Dauerhafte Schreibrechte auf Programmverzeichnisse für alle Benutzer sind keine angemessene Reparatur.

Bevorzugt liefert die bestehende Softwareverteilung freigegebene Pakete. Für begründete Einzelaufgaben kann ein verwaltetes Erhöhungsverfahren konkrete Programme und Bedingungen freigeben. Regeln sollten überprüfbare Programmeigenschaften und geschützte Ablageorte berücksichtigen. Eine pauschale Freigabe beliebiger Installer, Skripte oder Kommandointerpreter würde den Rechteentzug weitgehend entwerten. Auch gestartete Unterprozesse und Updates gehören in die Regelprüfung.

Der Helpdesk erhält einen dokumentierten Ablauf mit Zuständigkeit, Gerätebindung und nachvollziehbarer Freigabe. Er muss auch außerhalb des Firmennetzes funktionieren, soweit dies betrieblich erforderlich ist. Für sensible AD-Administration bleibt ein geschützter Administrationsarbeitsplatz erforderlich; ein Domänenadministratorkonto ist kein Ersatz für fehlende Client-Supportrechte.

In kleinen Wellen ausrollen und nur lesend prüfen

Sichern Sie die bestehenden GPO-Einstellungen und dokumentieren Sie lokale Administratorgruppen einschließlich verschachtelter Mitgliedschaften. Wählen Sie repräsentative Pilotgeräte, etwa mit Fachsoftware, mobilen Nutzern und Fernsupport. Mitgliedsserver und DCs werden nicht ungeprüft in dieselbe erste Welle aufgenommen.

Nach Bereitstellung der Ersatzverfahren folgen gezielter Rechteentzug, GPO-Verarbeitung und erforderliche Neustarts. Neue Gruppenmitgliedschaften und deren Entzug müssen zusätzlich in frischen Anmeldesitzungen geprüft werden; vorhandene Tokens sind kein verlässlicher Beleg des neuen Zustands.

Die vier Werte lassen sich lokal ohne Konfigurationsänderung auslesen:

$policyPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
Get-ItemProperty -LiteralPath $policyPath -ErrorAction Stop |
    Select-Object EnableLUA, ConsentPromptBehaviorAdmin,
        ConsentPromptBehaviorUser, PromptOnSecureDesktop

Erwartet werden in dieser Reihenfolge 1, 2, 0, 1. Fehlende Werte werden nicht als bestandene Prüfung bewertet. Ein Registry-Befund zeigt außerdem weder die verursachende GPO noch allein das wirksame Laufzeitverhalten nach einem notwendigen Neustart.

Die IT prüft deshalb zusätzlich die Computerergebnisse in der GPMC-Gruppenrichtlinienergebnis-Auswertung. whoami /groups zeigt in der jeweiligen Testsitzung deren Gruppen und Tokenattribute. Die Administratoren-SID S-1-5-32-544 mit „Deny only“ kennzeichnet bei einem klassischen Administratorkonto einen gefilterten Token; das Konto ist dadurch nicht aus der Administratorengruppe entfernt. Ergebnisse enthalten interne Identitätsinformationen und gehören in geschützte Projektnachweise.

Vorteile

  • Weniger dauerhaft verfügbare Rechte: Ein Fehler im Browser oder Fachprogramm trifft zunächst auf die Befugnisse eines Standardbenutzers.
  • Klarere Zuständigkeiten: Gerätebereich, berechtigtes Konto und freigegebene Aufgabe lassen sich getrennt festlegen.
  • Weniger improvisierte Passworteingaben: Ein funktionierender IT-Prozess reduziert Situationen, in denen privilegierte Zugangsdaten am Benutzerdesktop eingesetzt werden.
  • Bessere Prüfbarkeit: Gruppenmitgliedschaft, Richtlinienwirkung und erfolgreicher Supportablauf erhalten jeweils konkrete Abnahmekriterien.

Nachteile und Grenzen

  • Mehr Aufwand vor dem Rollout: Altsoftware, Updateverfahren und Support müssen angepasst werden. Ablehnungen ohne Alternative erzeugen Ausfälle und Umgehungsdruck.
  • Zusätzliche Betriebskosten: Getrennte Konten, geschützte Arbeitsplätze und gegebenenfalls Erhöhungssoftware brauchen Pflege und klare Verantwortliche.
  • Keine vollständige Angriffssperre: UAC behebt keine ausnutzbaren Betriebssystemfehler und ersetzt weder Anwendungskontrolle noch Patchmanagement und Erkennung.
  • Kein vollständiges Freigabeprotokoll: Aus aktiver UAC folgt keine lückenlose Historie aller privilegierten Aktionen. Geeignete Verwaltungsprotokolle, Gruppenänderungsüberwachung und gegebenenfalls Prozessüberwachung sind separat einzurichten.

Stolperfallen bei Fernzugriff und Ausnahmen

Interaktive UAC-Dialoge und administrative Netzwerkanmeldungen verhalten sich unterschiedlich. Eine funktionierende lokale Ablehnung beweist keine Absicherung von SMB- oder anderen Verwaltungszugriffen. Kontotyp, Zielberechtigung und Protokoll müssen separat bewertet werden.

Ein Supportproblem wird deshalb nicht durch eine flächige Ausnahme für die Tokenfilterung lokaler Konten behoben. Insbesondere LocalAccountTokenFilterPolicy = 1 ist kein allgemeiner Betriebsstandard. Netzwerkzugänge brauchen passende Berechtigungen und Beschränkungen; UAC ist dort keine universelle interaktive Freigabestelle.

Weitere typische Fehler sind eine unbemerkte zweite Gruppenmitgliedschaft, konkurrierende MDM- und GPO-Einstellungen oder ein Notfallkonto, dessen Anmeldung durch andere Richtlinien blockiert wird. Jede Ausnahme bekommt Eigentümer, begrenzten Geltungsbereich, Ablaufdatum und einen überprüfbaren Ersatzplan.

Abnahme und Rückweg konkret festlegen

Die Abnahme prüft vier Fälle: Alltagsarbeit ohne Erhöhung, erwartete Ablehnung einer harmlosen Erhöhungsanforderung durch den Standardbenutzer, erfolgreiche verwaltete Installation und funktionierende IT-Wartung mit dem vorgesehenen Konto. Für berechtigte Administratoren wird der sichere Desktop sichtbar geprüft. Ein Test darf beim Dialog abgebrochen werden; eine produktive Systemänderung ist dafür nicht nötig.

Wenn notwendiger Support oder Fachbetrieb ausfällt, wird die nächste Welle gestoppt. Der Rückweg stellt gezielt die dokumentierten Vorgängerwerte für betroffene Geräte wieder her und prüft anschließend Sitzung und Verhalten erneut. Bloßes Entkoppeln der GPO oder „Not Configured“ garantiert keine Rücksetzung. UAC global abzuschalten oder allen Benutzern wieder dauerhaft Administratorrechte zu geben, ist kein akzeptabler Standard-Rollback.

Projekt-Checkliste

  • [ ] Direkte und geerbte lokale Administratorrechte sind erfasst und bereinigt.
  • [ ] Alltags-, Client-, Server- und AD-Administration sind angemessen getrennt.
  • [ ] Softwareverteilung, Fernsupport und Notfallweg bestehen den Pilot.
  • [ ] Vier UAC-Werte und ihre tatsächlich gewinnende Verwaltungsquelle sind geprüft.
  • [ ] Neustarts und neue Anmeldesitzungen sind berücksichtigt.
  • [ ] Klassisches UAC und Administrator protection sind im Inventar unterschieden.
  • [ ] Ablehnung, genehmigte Installation und privilegierte Wartung sind belegt.
  • [ ] Ausnahmen, Überwachung, Abnahmeverantwortung und Rückweg sind dokumentiert.