Das Konto eines Windows-Dienstes wählen — LocalSystem, virtuelle Konten und gMSA

„Ein als LocalSystem laufender Dienst wurde im Audit als überprivilegiert beanstandet. Wohin sollen wir ihn ändern?“ „Wir nutzen einen Domänenbenutzer, damit der Dienst auf einen freigegebenen Ordner zugreifen kann, aber wenn das Kennwort abläuft, bleibt der Dienst stehen.“ — Diese beiden Fälle sind typische Anfragen, wenn das Anmeldekonto des Dienstes keine Entwurfsentscheidung ist, sondern als „die Einstellung, die funktioniert hat“ festgehalten wurde.

Beim Wählen des Anmeldekontos trennen Sie was der Dienst im PC tun kann, als wer er von der Gegenseite gesehen wird, und wer das Kennwort verwaltet. Stärkere lokale Rechte und die Fähigkeit, sich an einem freigegebenen Ordner zu authentifizieren und zu verbinden, sind nicht dasselbe.¹²

Die Schlussfolgerung dieses Artikels lautet: Für einen Geschäftsdienst, der auf einer einzelnen Maschine bleibt, ist ein virtuelles Konto der erste Kandidat; braucht der Dienst in der Domäne eine eigene Identität, ein gMSA. Machen Sie eine Konfiguration, in der „der Dienst kein menschliches Kennwort hält“, zur Grundlage, und behandeln Sie den Domänenbenutzer als letzten Ausweg. Bestehende Dienste sollten Sie jedoch nicht pauschal sofort ändern; prüfen Sie die nötigen Rechte und die Auswirkungen der Migration.³⁴

Der Artikel richtet sich an IT-Verantwortliche in kleinen und mittleren Unternehmen und an Entwicklerinnen und Entwickler von Windows-Apps. Die Erklärung, gestützt auf Microsoft Learn zum Stand August 2026 der Ursprungsfassung, ist in der Reihenfolge Auswahl → lokale Rechte → Identität im Netzwerk → Einführung eines gMSA → Umstellung und Prüfung geordnet. Wie man den Dienst selbst baut, behandelt „Windows-Dienste erstellen und betreiben“.

1. Zuerst wählen: sechs Konten und vier Fragen

1.1 Die Vergleichsachsen sind Rechte, Identität und Kennwortverwaltung

Beim Start eines Dienstes meldet sich der Dienststeuerungs-Manager (SCM) mit dem konfigurierten Konto an. Gelingt das, weist er dem Dienstprozess ein Zugriffstoken zu; jeder Zugriff auf Dateien und Pipes wird danach durch den Abgleich dieses Tokens mit der Zugriffssteuerungsliste (ACL) entschieden. Das Anmeldekonto zu wählen heißt, den Inhalt des Tokens festzulegen, das der Dienst erhält.¹

Die Netzwerkanmeldung als PC$ in der Tabelle setzt eine Domänenumgebung voraus. In einer Arbeitsgruppe steht dasselbe Verfahren nicht zur Verfügung. Auch LocalSystem hat Grenzen, etwa WRP-geschützte Bereiche. Lesen Sie „fast unbegrenzt“ nicht als wörtlich unbegrenzt.⁵⁶²⁷

Bei LocalSystem, LocalService, NetworkService und virtuellen Konten muss der Benutzer kein Dienstkennwort setzen oder verwalten. Bei einer Konfiguration mit Domänenbenutzer oder lokalem Benutzer verwaltet ein Mensch Ablauf und Änderung des im SCM gespeicherten Kennworts. Ein gMSA hat ein Kennwort, überlässt dessen Verwaltung aber AD.¹⁸

1.2 Die Auswahl anhand von vier Fragen treffen

Prüfen Sie zuerst, ob der Dienst sich mit Windows-Authentifizierung mit anderen Maschinen verbindet. Falls ja, entscheiden Sie der Reihe nach ob die Maschine einer Domäne angehört, ob eine maschinenweite Identität reicht, und ob die Anwendung gMSA unterstützt.

flowchart TB
    accTitle: Entscheidungsfluss für das Anmeldekonto
    accDescr: Das Anmeldekonto anhand von vier Fragen der Reihe nach festlegen, ob es Netzwerkzugriff gibt, ob die Maschine einer Domäne angehört, ob eine maschinenweite Identität reicht, und ob die App gMSA unterstützt
    q1{"Verbindung zu anderen Rechnern mit Windows-Auth?"} -->|Nein| va["Virtuelles Konto"]
    va -.-> sys["LocalSystem, wenn privilegierte Rechte nötig"]
    q1 -->|Ja| q2{"Mitglied der Domäne?"}
    q2 -->|Nein| cred["Anmeldeinformationen schützen und speichern"]
    q2 -->|Ja| q3{"Maschinenweite Identität reicht?"}
    q3 -->|Ja| pcacl["Virtuelles Konto + PC$-Berechtigung"]
    q3 -->|Nein| q4{"App unterstützt gMSA?"}
    q4 -->|Ja| gmsa["gMSA"]
    q4 -->|Nein| du["Dedizierter Benutzer + Gegenmaßnahmen"]

Abbildung 1: Bleibt alles lokal, nehmen Sie ein virtuelles Konto. In der Domäne, wenn PC$ nicht fein genug ist, gehen Sie zum gMSA. In einer Arbeitsgruppe entwerfen Sie die Anmeldeinformationen getrennt.

Bestehende lokale Verarbeitung unter LocalService oder maschinenweiten Zugriff unter NetworkService müssen Sie nicht ohne Grund ersetzen. Bei einer neuen Wahl machen Sie das virtuelle Konto zur Grundlage, weil es geringe Rechte und die Trennung je Dienst verbindet.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (19 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Die Rechte im PC festlegen: virtuelle Konten als Grundlage

2.1 LocalService und NetworkService unterscheiden sich in der Netzwerkidentität

LocalService und NetworkService sind integrierte Konten für Dienste mit geringen Rechten. Lokal laufen beide mit etwa den minimalen Rechten eines Mitglieds der Gruppe Benutzer. Unterschiedlich sind die Anmeldeinformationen, die sie der Gegenseite vorlegen.⁶³

Die Aufteilung lautet: LocalService, wenn der Dienst nicht ins Netzwerk geht oder nie nach einer Identität gefragt wird; NetworkService, wenn er in der Domäne die Identität der Maschine braucht.

Beachten Sie jedoch, dass bei beiden mehrere Dienste dasselbe Konto teilen. Solange ACLs an dieses gemeinsame Konto vergeben sind, lassen sich die Dienste nicht unterscheiden. Laufen fünf Dienste als LocalService, erreichen alle fünf jede Ressource, die diesem Konto erlaubt ist. Dass SQL Server Local Service nicht unterstützt, hat denselben Grund: Ein geteiltes Konto lässt sich nicht von anderen Diensten trennen.³

2.2 Mit einem virtuellen Konto lassen sich ACLs je Dienst vergeben

Ein virtuelles Konto ist ein verwaltetes lokales Konto ab Windows Server 2008 R2 / Windows 7. Der Name lautet NT SERVICE\<Dienstname>. Weder das Anlegen eines Kontos noch das Setzen eines Kennworts ist nötig, und jeder Dienst hat eine eigene Identität. Für den Netzwerkzugriff in einer Domäne nutzt es die Anmeldeinformationen des Computerkontos.²

Es behält den Vorteil „keine Kennwortverwaltung“ von LocalService und NetworkService und beseitigt die Schwäche des geteilten Kontos. Dass das SQL-Server-Setup standardmäßig NT SERVICE\MSSQLSERVER und Ähnliches verwendet, folgt derselben Überlegung.³

Der praktische Nutzen ist, dass der Dienst direkt in einer ACL genannt werden kann. Ohne zusätzliche Gruppen oder Kennwortverwaltung können Sie einstellen: „Ändern auf diesem Datenordner diesem Dienst gewähren“.

Das folgende Beispiel stellt einen bestehenden MyAppService auf ein virtuelles Konto um. Prüfen Sie vor der Ausführung das Anmelderecht, die Datenablage und DPAPI aus Kapitel 7, und bestätigen Sie Start und die Hauptfunktionen in einer Testumgebung.

# Das Anmeldekonto des Dienstes auf ein virtuelles Konto ändern
# Der Wert von obj= ist "NT SERVICE\Dienstname". Kein Kennwort angeben
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Die Konfiguration prüfen (SERVICE_START_NAME ansehen)
sc.exe qc MyAppService

# Ändern auf dem Datenordner nur diesem Dienst gewähren
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

In der GUI öffnen Sie in services.msc die Eigenschaften des Dienstes, wechseln zur Registerkarte „Anmelden“, setzen den Kontonamen auf NT SERVICE\Dienstname und lassen die Kennwortfelder leer. Für virtuelle Konten und MSAs wird kein Kennwort angegeben. Die Änderung greift, wenn der Dienst neu startet.³

Eine eigene Identität lokal bedeutet nicht, dass Dienste auf der anderen Seite des Netzwerks unterscheidbar sind. Kapitel 3 erklärt diese Grenze.

2.3 LocalSystem nicht danach beurteilen, „dass es läuft“, sondern nach den nötigen privilegierten Rechten

LocalSystem (NT AUTHORITY\SYSTEM, Anzeigename Lokales System) ist ein vordefiniertes Konto, das der SCM verwendet. Das Token enthält die SIDs NT AUTHORITY\SYSTEM und BUILTIN\Administrators und hält umfangreiche lokale Rechte. Starke privilegierte Rechte wie SeDebugPrivilege und SeTcbPrivilege sind standardmäßig aktiv.⁵

Diese Stärke ist zugleich das Ausmaß des Schadens bei einer Übernahme. Hat ein LocalSystem-Dienst eine Schwachstelle zur beliebigen Codeausführung, kann er zum Ausgangspunkt werden für das Lesen und Verändern der Dateien aller Benutzer, das Lesen des Speichers anderer Prozesse, den Diebstahl von Anmeldeinformationen und laterale Bewegung. Auf NTFS hat SYSTEM standardmäßig Vollzugriff.⁶ Den Zusammenhang von Diebstahl der Anmeldeinformationen und lateraler Bewegung behandeln auch „NTLM und Kerberos anhand von Diagrammen erklärt“ und „Windows LAPS in der Praxis“.

LocalSystem wird trotzdem weiter gewählt, weil es der Standard ist, wenn obj= bei sc.exe create weggelassen wird, und weil es in vielen alten Beispielen und Installervorlagen steht. Während der Entwicklung treten selten Berechtigungsfehler auf, daher bleibt es oft „weil es gelaufen ist“. Microsoft erklärt jedoch, dass die meisten Dienste dieses Rechteniveau nicht brauchen und LocalService oder NetworkService erwogen werden sollten, wenn es nicht nötig ist.⁹⁵

Auch LocalSystem kann nicht alles bedingungslos ändern. Seit Windows Vista beschränkt der Windows-Ressourcenschutz (WRP) Änderungen an wichtigen Systemdateien, Ordnern und Registrierungsschlüsseln auf TrustedInstaller (den Dienst Windows Modules Installer). Selbst SYSTEM und Administratoren erhalten bei einem gewöhnlichen Schreibvorgang Zugriff verweigert. Die Meldung „Sie benötigen eine Berechtigung von TrustedInstaller“ kommt aus diesem Mechanismus.⁷

Trotz dieser Grenze hält LocalSystem für einen Geschäftsdienst weiterhin zu viele Rechte. Zulässige Ausnahmen sind Verarbeitung, deren geforderte privilegierte Rechte von vornherein über das Administratorniveau hinausgehen: enge Kopplung an Gerätetreiber, Eingriffe in die Sicherheitsgrundlage des OS, Verwaltung anderer Dienste und Sitzungen und Ähnliches. Bei Sicherungs-Agents, EDR und dergleichen ist genau diese Notwendigkeit die Frage.

Auch wenn ein Dienst unter eine Ausnahme fällt, prüfen Sie, ob ein Codepfad die privilegierten Rechte wirklich nutzt und ob sich nur dieser Teil trennen lässt. Zur Einordnung siehe „Wann sind unter Windows tatsächlich Administratorrechte nötig?“.

3. Die Identität festlegen, die das Ziel sieht: reicht PC$?

3.1 Wenn nur die Verbindung zu einem freigegebenen Ordner nötig ist, ist ein Domänenbenutzer oft überflüssig

Auf einer der Domäne beigetretenen Maschine authentifiziert sich ein Dienst unter LocalSystem, NetworkService oder einem virtuellen Konto gegenüber der Gegenseite als DOMAIN\Computername$. Manchmal liegt der einzige Grund, warum ein Dienst nicht auf einen freigegebenen Ordner zugreifen kann, darin, dass dieses PC$ in der ACL des Ziels nicht erlaubt ist.⁵²

Was hier nötig ist, sind nicht stärkere lokale Rechte für den Dienst, sondern die richtige Identität auf dem Ziel zu erlauben. Bei einem freigegebenen Ordner setzen Sie sowohl die Freigabeberechtigungen als auch die NTFS-Berechtigungen.

Das folgende Beispiel, auf dem Dateiserver ausgeführt, gewährt dem Dienst auf APPSV01 Ändern. Wenn Sie das Konto in der GUI auswählen, nehmen Sie Computer unter Objekttypen auf.

# Auf dem Dateiserver: dem Dienst auf APPSV01 Ändern auf dem freigegebenen Ordner gewähren
# Sowohl Freigabe- als auch NTFS-Berechtigungen müssen vergeben werden
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

Bei SQL Server gilt dieselbe Überlegung, das Computerkonto als Windows-Anmeldung zu registrieren. Verwenden Sie Integrated Security=true in der Verbindungszeichenfolge und verbinden Sie sich, ohne dass der Dienst das Kennwort eines Domänenbenutzers hält.

-- Auf dem DB-Server: Windows-integrierte Authentifizierung vom Dienst auf APPSV01 erlauben
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

Das ist der Teil, in dem die Windows-Anmeldung auf dem DB-Server angelegt wird. Das Prinzip, die nötigen Berechtigungen auf dem Ziel zu vergeben, unterscheidet sich nicht vom freigegebenen Ordner.

3.2 Mit PC$ lassen sich Dienste nicht einzeln berechtigen oder prüfen

Die Identität eines virtuellen Kontos ist maschinenlokal und wird von der Domäne nicht erkannt. Im Netzwerk fällt sie in PC$ zusammen, sodass allein am Konto nicht erkennbar ist, von welchem Dienst derselben Maschine die Anfrage kommt.¹⁰⁴

flowchart TB
    accTitle: Die Identität eines virtuellen Kontos fällt außerhalb der Maschine zusammen
    accDescr: Virtuelle Konten, die in der Maschine je Dienst eindeutig sind, fallen im Netzwerk auf das Computerkonto zusammen, sodass die Gegenseite nicht sagen kann, um welchen Dienst es sich handelt
    vaa["Virtuelles Konto A"] --> pc["Computerkonto PC$"]
    vab["Virtuelles Konto B"] --> pc
    pc --> remote["Identität, die die Gegenseite sieht"]
    remote -.-> nodist["Dienst nicht unterscheidbar"]

Abbildung 2: Auch wenn Dienste im PC getrennt sind, sieht das Ziel dasselbe PC$. Lokale Trennung und Trennung im Netzwerk sind getrennte Entscheidungen.

Dieser Ansatz hat zwei Grenzen.

Dieselbe Identität auf mehreren Servern zu teilen, übersteigt ebenfalls, was ein maschinenweites PC$ oder virtuelles Konto leisten kann. Sobald in der Domäne eine dienstspezifische Identität oder eine über mehrere Server gemeinsame Identität nötig wird, erwägen Sie ein gMSA vor einem Domänenbenutzer — das ist die Linie dieses Artikels. Ein gMSA ist in einer Arbeitsgruppe ebenfalls nicht nutzbar.

4. Die Rolle des gMSA: eine eigene Identität, die Kennwortverwaltung an AD abgeben

4.1 Erzeugung, Verteilung und Erneuerung des Kennworts von Menschen trennen

Ein gMSA (gruppenverwaltetes Dienstkonto) ist ein Domänenkonto, dessen Kennwortverwaltung den Domänencontrollern überlassen wird. Der Domänencontroller berechnet das Kennwort aus dem Stammschlüssel des Key Distribution Service (KDS), und nur zugelassene Hosts rufen es ab und nutzen es für ihre Dienste.⁸

flowchart TB
    accTitle: Wie die Kennwortverwaltung eines gMSA funktioniert
    accDescr: Der Domänencontroller berechnet das Kennwort aus dem KDS-Stammschlüssel, nur zugelassene Hosts rufen es ab und nutzen es zum Ausführen von Diensten, und das Kennwort rotiert standardmäßig alle 30 Tage automatisch
    kds["KDS-Stammschlüssel"] --> dc["DC berechnet das Kennwort"]
    dc --> host["Zugelassener Host ruft es ab"]
    host --> svc["Zum Ausführen des Dienstes genutzt"]
    dc -.-> rot["Automatische Rotation alle 30 Tage standardmäßig"]

Abbildung 3: Ohne dass ein Mensch das Kennwort kennt, rufen zugelassene Hosts es ab, und der Dienst läuft mit Anmeldeinformationen, die automatisch erneuert werden.

Das sind die Gründe, ein gMSA einem manuell verwalteten Domänenbenutzer vorzuziehen.¹¹ Wo Windows LAPS die Verwaltung lokaler Administratorkennwörter automatisiert, übernimmt ein gMSA die Kennwörter von Dienstkonten; so gesehen wird die Einordnung leichter. Die beiden Mechanismen zielen auf Unterschiedliches.

4.2 Die Prüfung der App-Unterstützung nicht überspringen

gMSAs werden breit von allem unterstützt, das eine Anmeldeidentität über die Standardmechanismen konfiguriert: Windows-Dienste, IIS-Anwendungspools, die Aufgabenplanung und so weiter. Aber nicht jede Anwendung kann sie nutzen. Software, die intern nach einem Kennwort fragt, kann es nicht, und es gibt Einschränkungen wie die, dass Failoverclustering selbst kein gMSA unterstützt.¹⁰

Ist ein gMSA ein Kandidat, bestätigen Sie vor der Produktion in einer Testumgebung, dass der Dienst als gMSA startet und auf die benötigten Ressourcen zugreifen kann. Auch Microsoft verlangt diesen Schritt.¹¹

Verwandte Optionen sind das sMSA (eigenständiges verwaltetes Dienstkonto) für einen einzelnen Server und das in Windows Server 2025 eingeführte dMSA (delegiertes verwaltetes Dienstkonto). Ein dMSA bindet die Authentifizierung an die Geräteidentität, um dem Diebstahl von Anmeldeinformationen entgegenzuwirken. Bei neuen Konfigurationen gehen Sie vom gMSA aus und erwägen diese je nach Anforderung.²

5. Ein gMSA einführen: von den Voraussetzungen bis zur Dienstkonfiguration

5.1 Zuerst zu prüfende Anforderungen

gMSA-Name und Änderungsintervall werden ebenfalls vor der Einführung festgelegt. Darüber nach dem Anlegen des Kontos nachzudenken bedeutet, es neu anzulegen.¹⁰

5.2 Den KDS-Stammschlüssel prüfen und bei Bedarf anlegen

Das Anlegen des KDS-Stammschlüssels ist eine einmalige Aufgabe je Gesamtstruktur. Prüfen Sie zuerst, ob ein Schlüssel existiert, und fügen Sie einen nur hinzu, wenn keiner vorhanden ist.

# Als Domänenadministrator auf einem Domänencontroller ausführen (oder auf einem
# Verwaltungsrechner mit installiertem AD-PowerShell-Modul)

# Prüfen, ob ein KDS-Stammschlüssel existiert, und bei Bedarf anlegen (einmal je Gesamtstruktur)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Tatsächlich nutzbar erst bis zu 10 Stunden später

Auch mit -EffectiveImmediately ist der Schlüssel nicht unbedingt unmittelbar nach dem Anlegen nutzbar. Weil die Replikation auf alle Domänencontroller abgewartet wird, gibt es nach dem Anlegen eine Wartezeit von bis zu 10 Stunden, in der kein gMSA angelegt werden kann. Das verhindert den Fehlschlag, zum Kennwortabruf überzugehen, während die Replikation noch unvollständig ist. Nehmen Sie diese Zeit in den Einführungsplan auf.¹²

5.3 Die zum Abruf berechtigten Hosts eingrenzen und das gMSA konfigurieren

Das Verfahren hat vier Schritte. Die erste Hälfte ist Konfiguration auf der AD-Seite; die zweite Hälfte ist Arbeit auf jedem Server, der den Dienst ausführt.¹⁰

Konfigurieren Sie vor dem nächsten Beispiel auch das Recht „Anmelden als Dienst“ aus 7.1. Dass sc.exe config gelingt, und dass der Dienst sich anmelden kann, sind zwei verschiedene Dinge.

# (1) Eine Sicherheitsgruppe anlegen, die das Kennwort abrufen darf, und
#     die Computerkonten der Server hinzufügen, die den Dienst ausführen
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Die Gruppenmitgliedschaft wird bewertet, wenn sich der Computer anmeldet,
# daher ist ein Neustart der Zielserver nach dem Hinzufügen der zuverlässige Weg

# (2) Das gMSA anlegen
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# (3) Auf jedem Server, der den Dienst ausführt, das gMSA installieren und prüfen
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True bedeutet, das Kennwort kann abgerufen werden

# (4) Als Anmeldekonto des Dienstes setzen. $ an den Namen anhängen und kein Kennwort angeben
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

Auch in services.msc geben Sie den Kontonamen mit nachgestelltem $ ein, etwa CORP\svc-batch$, und lassen die Kennwortfelder leer. MSA-Konten sind nicht für die interaktive Anmeldung nutzbar.³

Auf dem Ziel-Freigabeordner oder SQL Server vergeben Sie die nötigen Berechtigungen an CORP\svc-batch$ statt an PC$. Das Ergebnis ist eine Konfiguration, in der kein Mensch ein Kennwort verwaltet und der Dienst mit eigener Identität auf das Netzwerk zugreift. Hören Sie nicht beim Abrufcheck mit Test-ADServiceAccount auf; prüfen Sie die Hauptfunktionen des Dienstes wirklich.

6. Domänenbenutzer sind der letzte Ausweg: wenn nötig, die Gegenmaßnahmen vollständig umsetzen

6.1 Das Umgehen des Ablaufs zementiert ein anderes Risiko

Wird ein Domänenbenutzer oder ein lokaler Benutzer einem Dienst zugewiesen, speichert der SCM das Kennwort und nutzt es bei jedem Start zur Anmeldung. Der SCM verwaltet den Ablauf jedoch nicht. Läuft das gespeicherte Kennwort ab, schlägt die Anmeldung fehl und der Dienst startet nicht mehr.¹

Daraus entsteht ein Teufelskreis: Um Ausfälle durch Ablauf zu verhindern, wird das Kennwort auf nie ablaufen gesetzt, dasselbe Kennwort bleibt im Klartext in Verfahrensdokumenten, Skripten und Aufgaben auf mehreren Servern, und am Ende kann es niemand mehr ändern, auch nicht nach einem Austritt, weil „niemand weiß, was stehen bleibt, wenn wir es ändern“.

Microsoft weist außerdem darauf hin, dass die Nutzung eines Domänenkontos für einen Dienst betrieblichen Aufwand in der manuellen Verwaltung von Kennwort und SPN kostet und dass Wartung zu Dienstausfällen führen kann. Das Kennwort allein auf nie ablaufen zu setzen löst das Verwaltungsproblem nicht.³

6.2 Ein Konto mit SPN ist auch ein Ziel für Kerberoasting

Ein Dienst, der Kerberos-Authentifizierung entgegennimmt, registriert einen SPN (Dienstprinzipalname) am Anmeldekonto. Jeder authentifizierte Benutzer der Domäne kann ein Dienstticket dafür anfordern; ein Angreifer holt das Ticket und versucht offline, das Kennwort per Brute-Force zu knacken — das ist Kerberoasting.

Die Gegenmaßnahme ist, ein langes, zufällig erzeugtes Kennwort zu nutzen, statt sich auf ein von Menschen gewähltes Kennwort von etwa 10 bis 16 Zeichen zu stützen. Microsoft nennt ebenfalls das Erzwingen langer Kennwörter und gMSAs, die lange maschinell erzeugte Zufallswerte verwenden.¹³

Kerberos-Härtung (FAST), in demselben Dokument erwähnt, schützt Vorauthentifizierungsdaten und bietet Widerstand gegen KDC-Täuschung. Sie verhindert nicht, dass authentifizierte Benutzer Diensttickets für einen SPN anfordern, und sie ist kein Ersatz für die Stärke des Dienstkontokennworts. Zu SPN, Kerberos und den Bedingungen, unter denen die Authentifizierung auf NTLM zurückfällt, siehe „NTLM und Kerberos anhand von Diagrammen erklärt“.

6.3 Bei nicht unterstützten Apps ein dediziertes Konto und den Betrieb zusammen festlegen

Ist ein dedizierter Domänenbenutzer unvermeidlich, etwa weil die Anwendung kein gMSA unterstützt, setzen Sie alle folgenden Gegenmaßnahmen um.

Die Identität des Dienstes von menschlichen Konten zu trennen ist ebenfalls ein wichtiges Prinzip.⁴ Die unterstützten Dienste auf ein gMSA zu legen ist sicherer und leichter zu betreiben, als dass Menschen diese Verwaltung weiterführen; das ist der Grund, das gMSA vorzuziehen.

7. Umstellung und Prüfung: nicht beim Ändern des Kontonamens aufhören

7.1 Das Recht „Anmelden als Dienst“ prüfen

Um als Dienst zu starten, braucht das Konto SeServiceLogonRight (Anmelden als Dienst). LocalSystem, LocalService und NetworkService haben es eingebaut; bei jedem anderen Konto prüfen Sie, dass dieses Recht zugewiesen ist.¹⁴

Halten Sie im Bereitstellungsverfahren fest, wie das Recht konfiguriert wird, ob in der lokalen Sicherheitsrichtlinie (secpol.msc) oder über GPO oder Intune. Sich nicht auf eine Nebenwirkung eines Werkzeugs zu stützen ist wichtig. Bei dienstexklusiven Konten kombinieren Sie das mit dem Verweigern der interaktiven Anmeldung.

7.2 Daten unter dem Profil und die ACLs prüfen

Beim Start eines Dienstes lädt der SCM das Benutzerprofil dieses Kontos. Folglich unterscheiden sich die tatsächlichen %TEMP%, %APPDATA% und HKEY_CURRENT_USER je Konto. Wirken Einstellungen oder Caches nach der Umstellung „verschwunden“, liegt das daran, dass der Dienst ein anderes Profil als das des alten Kontos ansieht.¹

Die Abhilfe ist, die Daten des Dienstes an einen ausdrücklichen Pfad wie C:\ProgramData\<App-Name> zu legen und dem Anmeldekonto eine ACL darauf zu geben. Sind die Daten vom kontobezogenen Profil gelöst, erfordert der nächste Kontowechsel kein erneutes Verschieben des Speicherorts. Für Daten, die bereits unter einem Profil liegen, nehmen Sie die Migration in den Umstellungsplan auf.

Prüfen Sie Berechtigungen nicht nur auf den nötigen Ordnern, sondern auch auf der Registrierung und anderswo. Nach dem Wechsel auf ein Konto mit geringen Rechten prüfen Sie, dass Verarbeitung, die die alten LocalSystem-Rechte voraussetzte, nicht fehlschlägt.

7.3 DPAPI-geschützte Daten lassen sich nicht allein durch Dateiverschiebung übernehmen

Daten, die mit DPAPI im Benutzerbereich (CryptProtectData, .NETs ProtectedData und so weiter) geschützt wurden, können grundsätzlich nur von demselben Konto entschlüsselt werden, das sie geschützt hat. Wechseln Sie das Anmeldekonto, werden gespeicherte Verbindungszeichenfolgen und API-Schlüssel unlesbar.

Legen Sie deshalb getrennt von der Migration der Profildateien ein Verfahren fest, Geheimnisse nach der Umstellung erneut einzugeben. Auch wenn DPAPI die Daten wie vorgesehen schützt, wird daraus ein Dienstausfall, wenn niemand vorbereitet hat. Zur Gestaltung des Speicherorts siehe „Geheimnisse in Windows-Apps speichern“.

Lässt sich die Verbindung durch Windows-integrierte Authentifizierung mit einem gMSA oder PC$ erledigen, entfällt die Geheimnisspeicherung selbst. Die Reihenfolge ist, zuerst zu fragen „können wir uns das Speichern sparen?“ und dann „wo speichern wir?“.

Wenn Sie „mit den Rechten des aufrufenden Benutzers verarbeiten“ wollen, erwägen Sie außerdem Identitätswechsel statt das Anmeldekonto des Dienstes zu stärken. Das erklärt „Windows-Identitätswechseltoken richtig handhaben“.

7.4 Bestandsaufnahme über die Dienstliste, die Startidentität im Protokoll prüfen

Für die erste Bestandsaufnahme zählen Sie die Anmeldekonten in der Dienstliste. Das folgende Beispiel zeigt die Anzahl je Konto und die LocalSystem-Dienste, deren Pfad außerhalb des Windows-Ordners liegt.

# Zählen, welche Dienste unter welchem Konto laufen
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Nicht standardmäßige Dienste finden, die als LocalSystem laufen (Pfad nutzen, um eigene und Drittanbieterdienste von integrierten zu unterscheiden)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

Läuft ein Geschäftsdienst als LocalSystem oder Domänenbenutzer, kehren Sie zur Entscheidung in Kapitel 1 zurück und bestätigen Sie die nötigen privilegierten Rechte und die Identität, die das Ziel verlangt. Nutzen Sie den pfadbasierten Filter als Hinweis, Kandidaten zu finden, und entscheiden Sie anhand dessen, was der Dienst tatsächlich tut.

Der Dienststart lässt sich im Sicherheitsereignisprotokoll mit Ereignis-ID 4624, Anmeldetyp 5 (Service) bestätigen. Das steht für die Anmeldung, die der SCM zum Starten eines Dienstes ausführt. Das Feld Virtual Account zeigt, ob die Anmeldung durch ein MSA oder ein virtuelles Konto erfolgte, und kann daher auch zur Beobachtung verwalteter Konten dienen.¹⁵

7.5 Die Prüfungen vor der Produktivumstellung zusammenfassen

Ob Sie von LocalSystem weggehen oder ein gMSA einführen: Schließen Sie diese Prüfungen ab, bevor Sie die Produktion umstellen. Der Kern der Migration ist, geringste Rechte und den Weiterbetrieb der nötigen Funktionen gemeinsam zu bestätigen.

8. Zusammenfassung

Bei der Wahl eines Dienstkontos trennen Sie lokale Rechte, Identität im Netzwerk und Kennwortverwaltung. Dass LocalSystem der Standard ist, ist kein Grund, es zu nutzen. Für gewöhnliche Geschäftsdienste machen Sie virtuelle Konten zur Grundlage und vergeben die nötigen ACLs. LocalSystem erwägen Sie nur, wenn starke privilegierte Rechte wirklich nötig sind.⁵³

Reicht für die Ziele in der Domäne eine maschinenweite Identität, können ein virtuelles Konto oder Ähnliches plus eine PC$-Berechtigung genügen. Brauchen Sie eine dienstspezifische Identität oder eine, die mehreren Servern gemeinsam ist, wählen Sie ein gMSA und überlassen die Kennwortverwaltung AD. In einer Arbeitsgruppe sind weder PC$ noch gMSA verfügbar; es braucht ein anderes Design, das Anmeldeinformationen behandelt.²¹⁰

Ist ein Domänenbenutzer nötig, stellen Sie ein dediziertes Konto, ein langes Zufallskennwort, Anmeldeeinschränkungen, geringste Rechte, Rotation und ein Verzeichnis bereit. Bei der Umstellung prüfen Sie nicht nur den Kontonamen, sondern auch das Anmelderecht, das Profil und DPAPI.

Die Frage beim nächsten Konfigurieren eines Dienstes lautet: „Als wer, und wie weit, sollte dieser Dienst zugreifen können?“ Wählen Sie das Konto passend zu dieser Antwort, und lassen Sie es nicht als „die Einstellung, die funktioniert hat“ festgehalten.

Verwandte Artikel

• Windows-Dienste erstellen und betreiben ── Von der Abgrenzung zur Aufgabenplanung bis zur Umwandlung eines BackgroundService in einen Dienst
• Wann sind unter Windows tatsächlich Administratorrechte nötig? - UAC, geschützte Bereiche und wie man es am Design erkennt
• Windows-Identitätswechseltoken richtig handhaben ── Rechte pro Thread ausleihen und sicher zurückgeben
• NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt
• Windows LAPS in der Praxis — Schluss mit dem für alle PCs gleichen lokalen Administratorkennwort
• Geheimnisse in Windows-Apps speichern – Klartextkonfiguration mit DPAPI vermeiden

Verwandte Beratungsbereiche

KomuraSoft LLC übernimmt die Gestaltung des Anmeldekontos und die Härtung auf geringste Rechte für Windows-Dienste und residente Apps, die Migration bestehender, unter der Annahme von LocalSystem gebauter Dienste zu einem virtuellen Konto oder einem gMSA sowie die Untersuchung von Ausfällen durch Zugriff verweigert, DPAPI und das Profil nach einem Kontowechsel. Vom Stadium „wir wurden im Audit beanstandet, wissen aber nicht, wo wir anfangen sollen“ zu beginnen ist in Ordnung.

• Windows-App-Entwicklung
• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Quellen

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.

Soll ich einen Dienst, den ich vorerst unter LocalSystem laufen lasse, sofort ändern?

Eine sofortige Änderung ist nicht in jedem Fall die richtige Antwort. Prüfen Sie zuerst, ob dieser Dienst wirklich lokale Rechte auf LocalSystem-Niveau braucht (starke privilegierte Rechte jenseits eines Administrators). Geht es nur um Dateilesen und -schreiben sowie Netzwerkkommunikation, ist der Wechsel zu einem virtuellen Konto (NT SERVICE\Dienstname) der erste Kandidat. Bei der Migration prüfen Sie die Vergabe von Zugriff auf benötigte Ordner und Registrierungsschlüssel, den Umgang mit Daten, die vom Profil oder von DPAPI abhängen, und ob das Recht „Anmelden als Dienst“ vorliegt. Prüfen Sie Start und die Hauptfunktionen in einer Testumgebung, dann stellen Sie die Produktion um.

Soll ich ein virtuelles Konto oder NetworkService wählen?

Für eine neue Wahl empfehlen wir ein virtuelles Konto. Im Netzwerk erscheinen beide als Computerkonto (DOMAIN\Computername$), und beide haben geringe lokale Rechte. NetworkService wird jedoch von mehreren Diensten geteilt, sodass Sie mit einer ACL nicht „nur diesem Dienst erlauben“ trennen können. Ein virtuelles Konto hat eine Identität, die jedem Dienst eigen ist, und Sie können NT SERVICE\Dienstname direkt auf einer ACL angeben. Neuere Microsoft-Produkte wie SQL Server nutzen ebenfalls standardmäßig ein virtuelles Konto.

Kann ich ein gMSA in einer Arbeitsgruppenumgebung (ohne Domäne) nutzen?

Nein. Ein gMSA ist ein Mechanismus, bei dem ein Active-Directory-Domänencontroller das Kennwort erzeugt und verwaltet; eine Domäne und das Anlegen eines KDS-Stammschlüssels sind Voraussetzungen. In einer Arbeitsgruppe ist die Grundlage, lokale Verarbeitung mit einem virtuellen Konto oder LocalService/NetworkService abzuschließen. Brauchen Sie Zugriff auf eine andere Maschine, brauchen Sie ein anderes Design, etwa die explizite Nutzung der Anmeldeinformationen eines auf dem Ziel vorbereiteten Kontos. Netzwerkzugriff als Computerkonto (PC$) gilt ebenfalls nur in einer Domänenumgebung.

Nachdem ich das Anmeldekonto des Dienstes geändert habe, kann ich gespeicherte Einstellungen und Anmeldeinformationen nicht mehr lesen. Warum?

Weil jedes Anmeldekonto an sein eigenes Benutzerprofil, %TEMP%, HKEY_CURRENT_USER und den DPAPI-Schlüssel gebunden ist. Insbesondere Daten, die mit benutzerbezogenem DPAPI (CryptProtectData und Ähnliches) geschützt wurden, können grundsätzlich nur von demselben Konto entschlüsselt werden, das sie geschützt hat. Dateien unter dem Profil (AppData und Ähnliches) sind vom neuen Konto aus auch ein anderer Pfad. Bevor Sie Konten wechseln, planen Sie das Verfahren zum Neuaufbauen DPAPI-geschützter Daten (erneutes Eingeben von API-Schlüsseln und Ähnliches) und das Migrieren von Dateien unter dem Profil.

Wenn der Dienst nur auf einen freigegebenen Ordner zugreifen soll, brauche ich einen Domänenbenutzer?

In vielen Fällen nein. In einer Domänenumgebung authentifiziert sich ein Dienst, der als LocalSystem, NetworkService oder virtuelles Konto läuft, gegenüber der Gegenseite als Computerkonto (DOMAIN\Computername$). Fügen Sie dieses PC$ den Freigabeberechtigungen und den NTFS-Berechtigungen des freigegebenen Ordners hinzu, und er kann lesen und schreiben. Wollen Sie die Zugriffssteuerung mit einer dienstspezifischen Identität oder dieselbe Identität auf mehreren Servern, erwägen Sie ein gMSA statt eines Domänenbenutzers.

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.