Lokale Administratorrechte unter Windows entziehen – ohne Installation und Support auszubremsen

Beschäftigte benötigen eine neue Anwendung, einen Treiber oder kurzfristige Unterstützung unterwegs. Dauerhafte lokale Administratorrechte erscheinen dann bequem, bleiben aber auch in allen Situationen bestehen, in denen sie nicht gebraucht werden. Sie lediglich zu entziehen, ist ebenfalls keine tragfähige Lösung: Fehlen vorbereitete Installations-, Support- und Notfallwege, kann die tägliche Arbeit ins Stocken geraten.

Die praktikable Antwort ist ein Betriebsmodell aus vier Bausteinen: Standardkonten für den Alltag, getrennte administrative Zugänge für berechtigte Aufgaben, ein schlanker Prozess für befristete Ausnahmen und ein individuell abgesichertes lokales Notfallkonto je Gerät. Windows LAPS kann die Kennwortverwaltung dieses lokalen Kontos unterstützen, entscheidet aber nicht über Rollen, Freigaben oder Softwarebereitstellung.

Erst den tatsächlichen Bedarf ermitteln

Eine Liste der Mitglieder der lokalen Administratorgruppe ist nur der Anfang. Bestehende Rechte können auf einer aktuellen Aufgabe beruhen – oder auf einer Ausnahme, deren Anlass längst entfallen ist. Aus einer historischen Berechtigung sollte deshalb kein dauerhafter Bedarf abgeleitet werden.

Für die Bestandsaufnahme sind drei Blickwinkel wichtig:

Personen und Rollen

• Wer besitzt derzeit lokale Administratorrechte?
• Gehört Administration tatsächlich zur jeweiligen Aufgabe?
• Werden die Rechte regelmäßig oder nur für einzelne Vorgänge benötigt?
• Haben externe Supportkräfte oder Dienstleister administrativen Zugriff?
• Ist die Berechtigung an eine definierte Rolle oder nur an eine bestimmte Person gebunden?

Anwendungen und Geräte

• Welche Programme verlangen bei Installation oder Aktualisierung erhöhte Rechte?
• Benötigen Spezialanwendungen diese Rechte nur bei der Einrichtung oder auch im Betrieb?
• Welche Treiber, Geräte und Erweiterungen werden bisher selbst installiert?
• Welche Computer sind zentral verwaltet, welche nur zeitweise erreichbar?
• Welche Notebooks werden überwiegend mobil oder ohne verlässliche Verbindung zur Unternehmensumgebung eingesetzt?

Tatsächliche Abläufe

• Wie häufig kommen Installationsanfragen vor?
• Welche Vorgänge sind planbar, welche müssen kurzfristig erledigt werden?
• Welche wiederkehrenden Supportfälle lassen sich standardisieren?
• Welche Tätigkeiten scheitern in einem Pilotversuch tatsächlich ohne lokale Administratorrechte?

Eine einfache Erfassungstabelle schafft eine belastbare Entscheidungsgrundlage:

Drei Kontotypen, drei klar getrennte Zwecke

Standardkonto für die tägliche Arbeit

Das normale Benutzerkonto dient der Anmeldung, Kommunikation, Büroarbeit und Nutzung bereitgestellter Anwendungen und Daten. Es besitzt grundsätzlich keine lokalen Administratorrechte.

Persönliches Administrationskonto für administrative Aufgaben

Ein getrenntes Administrationskonto ist für Personen vorgesehen, deren Aufgabe tatsächlich administrative Arbeiten umfasst. Es sollte nicht für E-Mail, Internetzugriffe oder gewöhnliche Büroarbeit verwendet werden.

Nicht jede beschäftigte Person benötigt ein solches zweites Konto. Würden alle bisherigen Administratoren ihre Rechte lediglich unter einem anderen Benutzernamen behalten, wäre das Grundproblem nur verlagert.

Lokales Notfallkonto als Rückfallebene

Ein lokales Administratorkonto kann für klar definierte Support- oder Wiederherstellungssituationen notwendig sein. Es ist nicht für den täglichen Einsatz bestimmt. Für dieses Konto sollte das Unternehmen festlegen:

• ein geräteindividuelles statt eines gemeinsamen Kennworts,
• eng begrenzte Abrufberechtigungen,
• zulässige Gründe für den Zugriff,
• eine nachvollziehbare Dokumentation der Verwendung,
• einen Kennwortwechsel nach Offenlegung oder Nutzung,
• eine regelmäßige Rotation nach der betrieblichen Richtlinie.

Microsoft weist auf die Risiken identischer lokaler Administratorkennwörter auf mehreren Geräten hin und empfiehlt individuelle, vorzugsweise mit Windows LAPS verwaltete Kennwörter.

Installationen nach ihrem tatsächlichen Charakter behandeln

„Softwareinstallation“ ist kein einheitlicher Vorgang. Betriebssystemkomponenten, Treiber, Fachanwendungen und Programme mit eigenen Aktualisierungsmechanismen können unterschiedliche Anforderungen haben. Deshalb sollte nicht für alle Fälle derselbe Weg vorgeschrieben werden.

Eine häufig wiederkehrende Ausnahme ist ein Hinweis auf einen fehlenden Regelprozess. Statt denselben Einzelfall unbegrenzt neu zu genehmigen, sollte daraus ein standardisierter Installations- oder Supportweg entstehen.

Entscheidungshilfe für neue Anforderungen

Bei einer Installations- oder Änderungsanfrage hilft eine kurze, immer gleich angewendete Reihenfolge:

1. Ist die Anwendung oder Änderung betrieblich freigegeben? Falls nicht, ist zunächst eine fachliche und sicherheitsbezogene Prüfung erforderlich.
2. Kann sie ohne lokale Administratorrechte genutzt oder bereitgestellt werden? Wenn ja, gilt der normale Bereitstellungsweg.
3. Kann der Support die administrative Tätigkeit übernehmen? Dann benötigt die anfragende Person keine zusätzlichen Dauerrechte.
4. Tritt derselbe Bedarf regelmäßig auf? Dann sollte daraus ein standardisierter Prozess werden.
5. Ist eine vorübergehende Rechteerweiterung unvermeidbar? Sie muss begründet, genehmigt sowie auf Gerät, Zweck und Dauer begrenzt werden.
6. Ist das Gerät offline oder nicht zentral verwaltet? Vor der Änderung müssen Support und Notfallzugriff praktisch geklärt sein. Ohne getesteten Rückweg sollte es nicht ungeprüft umgestellt werden.

Ausnahmen kurz halten, aber nachvollziehbar machen

Ein Ausnahmeprozess muss alltagstauglich sein. Zugleich sollte später erkennbar bleiben, warum eine Berechtigung vergeben wurde und ob sie wieder entfernt worden ist.

Mindestens festzuhalten sind:

• anfragende Person und betroffenes Gerät,
• Anwendung oder administrative Tätigkeit,
• betriebliche Begründung,
• benötigte Berechtigung,
• Beginn und definiertes Ende,
• genehmigende Stelle,
• gewählter Umsetzungsweg,
• Ergebnis und Entfernung der Berechtigung.

Der Ablauf kann bewusst knapp bleiben: Bedarf beschreiben, Alternative ohne Rechteerweiterung prüfen, Risiko und Dringlichkeit bewerten, Freigabe einholen, Ausnahme begrenzen, Durchführung dokumentieren und die Berechtigung anschließend entfernen. Allgemeingültige Fristen gibt es dafür nicht. Entscheidend sind ein festgelegtes Ende und eine tatsächliche Kontrolle nach Ablauf.

Windows LAPS ist Kennwortverwaltung, kein Berechtigungskonzept

Windows LAPS kann das Kennwort eines lokalen Administratorkontos automatisch verwalten und entsprechend der vorhandenen Umgebung in Microsoft Entra ID oder Active Directory hinterlegen. Damit lassen sich individuelle Kennwörter und eine richtliniengesteuerte Rotation organisieren.

Windows LAPS entscheidet jedoch nicht,

• wer administrative Aufgaben übernehmen darf,
• ob eine Anwendung fachlich freigegeben ist,
• wann eine Ausnahme gerechtfertigt ist,
• wie Software verteilt wird,
• wie Supportfälle dokumentiert und priorisiert werden,
• ob ein Gerät organisatorisch ausreichend verwaltet ist.

Vor der Einführung sind daher organisatorische Fragen zu beantworten: Welches lokale Konto wird verwaltet? Wo wird das Kennwort hinterlegt? Welche eng begrenzten Rollen dürfen es aus welchem Grund abrufen? Wie wird die Verwendung dokumentiert? Wie wird nach einer Offenlegung oder Nutzung der Wechsel ausgelöst? Und welcher Weg bleibt, wenn Gerät oder Verzeichnis nicht erreichbar sind?

Wichtig ist die Abgrenzung: Windows LAPS entzieht keinem Benutzer Administratorrechte. Es sichert die Kennwortverwaltung eines lokalen Kontos ab und bildet damit nur einen Teil des gesamten Modells.

Konkrete Einstellungen, Voraussetzungen und Abrufberechtigungen hängen von der eingesetzten Windows-, Active-Directory- oder Microsoft-Entra-Umgebung ab. Aussagen zu Lizenzierung, Windows-Versionen oder bestimmten Verwaltungsplattformen sind daher nicht Bestandteil dieses Beitrags.

Zuerst mit unterschiedlichen Arbeitsplätzen testen

Die Umstellung sollte nicht gleichzeitig auf allen Geräten erfolgen. Eine geeignete Pilotgruppe umfasst beispielsweise einen typischen Büroarbeitsplatz, ein Homeoffice-Notebook, einen mobilen Arbeitsplatz, einen Computer mit Spezialsoftware, ein Gerät mit regelmäßig benötigter Peripherie und eine IT- oder Supportrolle mit getrenntem Administrationskonto.

Vor dem Entzug der Rechte sollte geprüft sein:

• [ ] Standardsoftware ist installiert oder kann geregelt bereitgestellt werden.
• [ ] Fernsupport funktioniert auch bei einem angemeldeten Standardbenutzer.
• [ ] Der Support kann administrative Installationen ausführen.
• [ ] Das lokale Notfallkonto ist eingerichtet.
• [ ] Eine berechtigte Rolle kann das individuelle Kennwort abrufen.
• [ ] Der Kennwortwechsel nach einer Verwendung ist geregelt.
• [ ] Für offline betriebene Geräte besteht ein getesteter Rückweg.
• [ ] Zuständigkeiten und Kontaktwege sind bekannt.
• [ ] Eine kontrollierte Rücknahme der Änderung ist vorbereitet.

Während des Piloten sollte nicht nur die Zahl der Beschwerden beobachtet werden. Aussagekräftiger ist, welche Tätigkeiten tatsächlich scheitern, welche Anfragen auftreten, wie schnell der Support helfen kann, ob mobile Arbeit und Fernsupport funktionieren und ob befristete Berechtigungen zuverlässig entfernt werden. Auch der Notfallzugriff sollte praktisch getestet werden.

Konkrete Zielwerte muss jedes Unternehmen anhand seiner Arbeitsabläufe und Supportkapazitäten festlegen. Der Pilot ist dann belastbar, wenn Regel-, Ausnahme- und Notfallwege nachweislich funktionieren – nicht lediglich dann, wenn niemand ein Problem meldet.

Kompakte Einführungscheckliste

Bestand und Zielmodell

• [ ] Vorhandene lokale Administratorrechte und ihre tatsächlichen Anlässe erfasst
• [ ] Anwendungen, Treiber, Spezialhardware und externe Zugriffe berücksichtigt
• [ ] Mobile und nicht zentral verwaltete Geräte identifiziert
• [ ] Standardkonto als tägliches Arbeitskonto festgelegt
• [ ] Administrative Rollen klar benannt
• [ ] Persönliche Administrationskonten nur bei begründetem Bedarf vorgesehen
• [ ] Lokales Notfallkonto je Gerät definiert
• [ ] Gemeinsames lokales Administratorkennwort ausgeschlossen

Regelbetrieb und Ausnahmen

• [ ] Verfahren für Standardsoftware und einmalige Installationen vorhanden
• [ ] Update-, Treiber- und Offline-Fälle geprüft
• [ ] Ausnahmeprozess mit Freigabe und Enddatum eingerichtet
• [ ] Entfernung abgelaufener Rechte wird kontrolliert
• [ ] Wiederkehrende Ausnahmen werden in Regelprozesse überführt

LAPS und Pilot

• [ ] Verzeichnis für die Kennworthinterlegung festgelegt
• [ ] Abrufberechtigungen auf notwendige Rollen begrenzt
• [ ] Zulässige Abrufgründe und Dokumentation geregelt
• [ ] Rotation nach Offenlegung oder Nutzung vorgesehen
• [ ] Notfall- und Rückfallwege praktisch getestet

Die Umstellung betrifft damit nicht nur eine Windows-Einstellung, sondern das Zusammenspiel von Endgeräten, Identitäten, Rollen und überprüfbaren Berechtigungen. Bei der Einordnung dieses Zielbilds kann der Bereich IT-Sicherheit und Cyberabwehr von netzmal fachlich anknüpfen. Die konkrete technische Umsetzung muss anschließend zur tatsächlich vorhandenen Microsoft- und Geräteumgebung passen.

Grenzen der Einordnung

Das Prinzip bedarfsgerechter Berechtigungen und die Funktionsweise von Windows LAPS ergeben noch kein vollständiges Einführungsmodell für jede Umgebung. Nicht jede Anwendung funktioniert ohne lokale Administratorrechte. Für Geräte außerhalb von Active Directory oder Microsoft Entra ID ist ein gesondert getesteter Verwaltungs- und Notfallweg erforderlich. Windows LAPS ersetzt zudem keine umfassende Verwaltung privilegierter Identitäten für Server oder Cloud-Dienste.