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

„Ein interner Dienst, den wir vorerst unter LocalSystem laufen ließen, wurde in der Sicherheitsprüfung als ‚überhöhte Rechte‘ beanstandet. Wohin sollen wir ihn ändern?“ „Der Dienst kam nicht an einen freigegebenen Ordner, also lassen wir ihn als Domänenbenutzer laufen. Wenn das Kennwort abläuft, bleibt der Dienst stehen, also haben wir es nie ablaufen lassen und im Klartext ins Runbook geschrieben.“ — Unter Beratungen rund um Windows-Dienste von Kunden sind diese beiden Klassiker.

Was beide Orte gemeinsam haben: das Anmeldekonto des Dienstes ist als „die Einstellung, die zufällig funktionierte“ eingefroren, nicht als Entwurfsentscheidung. Ein Windows-Dienst läuft immer im Sicherheitskontext irgendeines Kontos, und dieses Konto entscheidet alles: was es lokal tun kann, als wer es von der anderen Seite des Netzwerks aussieht, und wer das Kennwort verwaltet. Lassen Sie das beim Standard, und eine Schwachstelle in einem Dienst führt direkt zur Übernahme der ganzen Maschine, und Klartextkennwörter verstreuen sich in Runbooks und Skripten.

flowchart TB
    accTitle: Drei Dinge, die das Anmeldekonto entscheidet
    accDescr: Ein Dienst läuft immer im Sicherheitskontext eines Kontos, und dieses Konto entscheidet alles, was es lokal tun kann, als wer es von der anderen Seite des Netzwerks aussieht, und wer das Kennwort verwaltet
    acct["Das Anmeldekonto des Dienstes"] --> local["Was es lokal tun kann"]
    acct --> net["Als wer es vom Netzwerk aus gesehen wird"]
    acct --> pwd["Wer das Kennwort verwaltet"]

Abbildung 1: Die Wahl des Anmeldekontos ist eine Entwurfsentscheidung, die zugleich lokale Rechte, Netzwerkidentität und Kennwortverwaltung festlegt.

Es gibt faktisch sechs Wahlmöglichkeiten — LocalSystem, LocalService, NetworkService, ein virtuelles Konto (NT SERVICE\), ein Domänenbenutzer und ein gMSA (gruppenverwaltetes Dienstkonto). An IT-Personal in kleinen und mittleren Unternehmen und an Windows-App-Entwickler gerichtet, ordnet dieser Artikel Rechte, Netzwerkidentität und Kennwortverwaltung dieser sechs in einer Tabelle und fasst einen Entscheidungsfluss zusammen, auf Basis von Microsoft-Learn-Primärquellen Stand August 2026.

Wie man den Dienst selbst baut (Wahl zwischen Aufgabenplanung und Dienst, Umsetzung mit einem .NET Worker Service) behandelt „Windows-Dienste erstellen und betreiben“. Dieser Artikel konzentriert sich auf das „Anmeldekonto“, dort wo die meisten Unfälle passieren.

1. Zuerst das Fazit

• Im Zweifel ist ein virtuelles Konto der erste Kandidat für einen Dienst, der innerhalb einer Maschine fertig wird, und ein gMSA der erste Kandidat für einen Dienst, der mit einer dienstspezifischen Identität auf eine Ressource in der Domäne zugreift. Microsoft gibt auch die Leitlinie, wo immer möglich ein verwaltetes Konto (MSA / virtuelles Konto) zu nutzen.¹²
• Wählen Sie LocalSystem nicht, weil „es funktioniert“. Das Token enthält SYSTEM und BUILTIN\Administrators und hält starke Rechte wie SeDebugPrivilege, daher verliert eine Übernahme fast alles auf dieser Maschine. Dass der Standard von sc.exe create LocalSystem ist, ist der Nährboden für diesen Unfall.³⁴
• Der Unterschied zwischen LocalService und NetworkService ist die Netzwerkidentität. Lokale Rechte sind bei beiden minimal, aber zur Gegenseite sieht LocalService anonym aus und NetworkService wie das Computerkonto.⁵
• **Ein virtuelles Konto (NT SERVICE\) ist der moderne Standard, der Identität pro Dienst trennen kann, ohne Kennwortverwaltung zu brauchen.** Sie können „NT SERVICE\\Dienstname“ direkt auf einer ACL angeben, und das Standard-Dienstkonto von SQL Server ist ebenfalls dieses.[^understand-service-accounts][^sql-service-accounts]
• Wenn LocalSystem, NetworkService oder ein virtuelles Konto ins Netzwerk gehen, werden sie zum Computerkonto (DOMAIN\Computername$). PC$ auf der ACL eines freigegebenen Ordners oder von SQL Server zu vergeben lässt oft einen Domänenbenutzer entbehrlich.³⁶
• Eine Konfiguration, die einen Domänenbenutzer für einen Dienst nutzt, wird sowohl bei der Kennwortoperation als auch gegenüber Kerberoasting zur Schuld. Der SCM meldet sich mit dem gespeicherten Kennwort an, daher wird Ablauf zu einem Startfehler, und das „nie ablaufen + Klartextnotiz“, das das vermeidet, wird ein Geschenk an den Angreifer.⁷⁸
• Ein gMSA lässt Active Directory das Kennwort automatisch erzeugen und rotieren. Die Anforderungen sind eine Domäne und ein KDS-Stammschlüssel, und Sie setzen den Dienst auf „DOMAIN\Kontoname$“ mit leerem Kennwortfeld. Manche Apps unterstützen es nicht, daher müssen Sie vorab validieren.⁹¹⁰
• Ein Kontowechsel ändert die Annahmen von Profil, %TEMP% und DPAPI. Daten, die mit dem DPAPI des alten Kontos geschützt wurden, kann das neue Konto nicht entschlüsseln.
• Ein Inventar des Ist-Zustands lässt sich aus den Anmeldekonten der Dienstliste und aus Ereignis-ID 4624 (Anmeldetyp 5) bestätigen.¹¹

In einem Satz lautet das Fazit dieses Artikels: machen Sie eine Konfiguration, die „einem Dienst kein menschliches Kennwort gibt“ (integrierte Konten, virtuelles Konto, gMSA), zum Standard, und behandeln Sie einen Domänenbenutzer als letzten Ausweg.

2. Das Gesamtbild der Wahlmöglichkeiten — sechs Anmeldekonten in einer Tabelle

Zuerst eine Stufe Wiederholung. Beim Dienststart meldet sich der Dienststeuerungs-Manager (SCM) mit dem konfigurierten Konto an und erzeugt bei Erfolg ein Zugriffstoken und weist es dem Dienstprozess zu. Danach entscheidet jeder Ressourcenzugriff — Dateien, Pipes und dergleichen — durch Abgleich dieses Tokens mit der ACL.⁷ Die Wahl des Anmeldekontos ist also ein Entwurf, der den Inhalt des Tokens entscheidet, das dem Dienstprozess übergeben wird. Hier sind die sechs Wahlmöglichkeiten.

flowchart TB
    accTitle: Was der SCM beim Dienststart tut
    accDescr: Der SCM meldet sich mit dem konfigurierten Konto an, erzeugt bei Erfolg ein Zugriffstoken und weist es dem Dienstprozess zu, und danach entscheidet Ressourcenzugriff durch Abgleich des Tokens mit der ACL
    scm["SCM"] --> logon["Als konfiguriertes Konto anmelden"]
    logon --> token["Ein Zugriffstoken erzeugen"]
    token --> proc["Es dem Dienstprozess zuweisen"]
    proc --> access["Zugriff auf eine Datei oder eine Pipe"]
    access --> check{"Erlaubt die ACL es?"}
    check -->|Ja| ok["Zugriff gelingt"]
    check -->|Nein| deny["Zugriff wird verweigert"]

Abbildung 2: Jeder Ressourcenzugriff des Dienstes wird durch Abgleich des Tokens, das der SCM beim Start erzeugt hat, mit der ACL entschieden.

LocalSystem, LocalService, NetworkService und ein virtuelles Konto haben überhaupt keinen Begriff von einem Kennwort. Die einzigen, die sich mit einem im SCM gespeicherten Kennwort anmelden (= Ablauf und Leck möglich), sind ein Domänenbenutzer und ein lokaler Benutzer.⁷³

Unten gehen wir diese Tabelle Zeile für Zeile durch.

3. Was an LocalSystem falsch ist

3.1. Immer noch stärker als „Als Administrator ausführen“

LocalSystem (Anzeigename Local System, NT AUTHORITY\SYSTEM) ist ein vordefiniertes Konto, das der SCM nutzt, und es hält umfangreiche Rechte auf dem lokalen Computer. Das Token enthält die SIDs von NT AUTHORITY\SYSTEM und BUILTIN\Administrators, und es kann auf die meisten Objekte im System zugreifen. Ferner sind SeDebugPrivilege, das andere Prozesse debuggen kann, und SeTcbPrivilege, das als Teil des OS handelt, standardmäßig aktiviert.³

Diese Stärke ist gleichbedeutend mit der Größe des Schadens bei Übernahme. Hat ein unter LocalSystem laufender Dienst eine Schwachstelle für beliebige Codeausführung, erreicht ein Angreifer in einem Atemzug das Lesen und Verfälschen der Dateien jedes Benutzers auf dieser Maschine (SYSTEM hat standardmäßig Vollzugriff auf NTFS⁵), das Lesen des Speichers anderer Prozesse über SeDebugPrivilege und das Stehlen von Anmeldeinformationen und die laterale Bewegung von dort (ein Ausgangspunkt für Pass-the-Hash und Ähnliches). Die Kette aus Diebstahl von Anmeldeinformationen und lateraler Bewegung ist in „NTLM und Kerberos anhand von Diagrammen erklärt“ und „Windows LAPS in der Praxis“ behandelt.

flowchart TB
    accTitle: Der Schaden, wenn ein LocalSystem-Dienst übernommen wird
    accDescr: Hat ein unter LocalSystem laufender Dienst eine Schwachstelle für beliebige Codeausführung, erreicht ein Angreifer das Lesen und Verfälschen der Dateien jedes Benutzers, das Lesen des Speichers anderer Prozesse und das Stehlen von Anmeldeinformationen sowie laterale Bewegung
    vuln["Eine Schwachstelle für beliebige Codeausführung"] --> sys["Der Angreifer erhält SYSTEM-Rechte"]
    sys --> files["Lesen und Verfälschen von Dateien"]
    sys --> mem["Lesen des Speichers anderer Prozesse"]
    sys --> cred["Stehlen von Anmeldeinformationen"]
    cred --> lateral["Laterale Bewegung zu einer anderen Maschine"]

Abbildung 3: Eine Schwachstelle in einem LocalSystem-Dienst lässt einen Angreifer in einem Atemzug zur Übernahme der ganzen Maschine und zu einem Ausgangspunkt für laterale Bewegung gelangen.

3.2. Warum es trotzdem gewählt wird

Der Grund ist einfach: es ist der Standard, und eine Zugriffverweigerung erscheint nie. Der Standard, wenn Sie obj= bei sc.exe create weglassen, ist LocalSystem,⁴ und viele alte Beispielcodes und Installervorlagen setzen noch LocalSystem voraus. Weil Sie während der Entwicklung frei von Rechtefehlern bleiben können, ist die Struktur da, die „es funktionierte, also lassen“ in Masse erzeugt. Microsofts eigene Dokumentation stellt auch fest, dass die meisten Dienste dieses hohe Rechteniveau nicht brauchen, und dass Sie, wenn Sie es nicht brauchen, LocalService oder NetworkService erwägen sollten.³

flowchart TB
    accTitle: Die Struktur, die LocalSystem weiter gewählt werden lässt
    accDescr: Der Standard von sc.exe create ist LocalSystem, und alte Beispiele und Vorlagen setzen auch LocalSystem voraus, daher erscheint während der Entwicklung keine Zugriffverweigerung und eine Konfiguration es funktionierte also lassen wird in Masse erzeugt
    def["Der Standard von sc.exe create"] --> lsys["Als LocalSystem erzeugt"]
    old["Alte Beispiele und Vorlagen"] --> lsys
    lsys --> noerr["Keine Zugriffverweigerung in der Entwicklung"]
    noerr --> asis["Es funktionierte, also lassen"]
    asis --> mass["Dienste mit überhöhten Rechten werden in Masse erzeugt"]

Abbildung 4: Der Standard und eine Entwicklungserfahrung „keine Zugriffverweigerung“ erzeugen in Masse Dienste, die als LocalSystem eingefroren sind.

3.3. Der Unterschied zu TrustedInstaller — LocalSystem ist auch nicht unbegrenzt

LocalSystem „das stärkste Konto von Windows“ zu nennen ist nicht genau. Windows-Ressourcenschutz (WRP) seit Windows Vista erlaubt Änderungen an wichtigen Betriebssystemdateien, Ordnern und Registrierungsschlüsseln nur TrustedInstaller (dem Windows-Modules-Installer-Dienst), und selbst SYSTEM oder ein Administrator erhält bei einem Überschreiben Zugriff verweigert.¹² Explorers „Sie benötigen eine Berechtigung von TrustedInstaller“ ist dieser Mechanismus. Andersherum: LocalSystem kann fast alles außerhalb des WRP-geschützten Bereichs erreichen, und es gibt gewöhnlich keinen Grund, das einem Geschäftsdienst zu geben.

flowchart TB
    accTitle: Die Beziehung zwischen dem WRP-geschützten Bereich und TrustedInstaller
    accDescr: Änderungen an wichtigen Systemdateien und Registrierungsschlüsseln, die WRP schützt, sind nur TrustedInstaller erlaubt, und selbst SYSTEM oder ein Administrator erhält Zugriff verweigert
    ti["TrustedInstaller"] -->|Kann ändern| wrp["WRP-geschützte Systemdateien und dergleichen"]
    sysadm["SYSTEM und Administratoren"] -->|Zugriff verweigert| wrp
    sysadm -->|Fast alles ist erlaubt| other["Außerhalb des WRP-geschützten Bereichs"]

Abbildung 5: LocalSystem ist auch nicht unbegrenzt; Änderungen am WRP-geschützten Bereich sind nur TrustedInstaller erlaubt.

3.4. Fälle, in denen LocalSystem vernünftig ist

Ausnahmsweise vernünftig ist ein Dienst, dessen benötigte Rechte von vornherein über Administrator-Klasse hinausgehen — eng mit einem Gerätetreiber arbeiten, das Sicherheitsfundament des OS bedienen, andere Dienste oder Sitzungen verwalten und dergleichen. Software wie ein Sicherungs-Agent oder ein EDR trifft zu. Selbst dann lohnt es, zu bestätigen, dass es einen Codepfad gibt, der dieses Recht wirklich nutzt, und zu erwägen, ob die Arbeit, die das Recht braucht, getrennt werden kann (wie man das erkennt, siehe „Wann sind unter Windows tatsächlich Administratorrechte nötig?“).

4. LocalService und NetworkService — integrierte Konten mit geringsten Rechten

LocalService (NT AUTHORITY\LOCAL SERVICE, SID: S-1-5-19) und NetworkService (NT AUTHORITY\NETWORK SERVICE, SID: S-1-5-20) sind integrierte Konten, die für Dienste mit geringen Rechten vorbereitet sind. Beide halten lokal nur minimale Rechte und können wenig mehr als ein Mitglied der Gruppe Users.⁵¹

Der Unterschied zwischen den beiden ist ein Punkt: als wer sie von der anderen Seite des Netzwerks aussehen.⁵

• LocalService: Verbindet sich zur Gegenseite mit anonymen Anmeldeinformationen. Es kann nicht auf eine Ressource zugreifen, die Authentifizierung verlangt.
• NetworkService: Legt der Gegenseite die Anmeldeinformationen des Computers vor (in einer Domänenumgebung DOMAIN\Computername$).

Die Trennung ist LocalService, wenn „es nicht ins Netzwerk geht, oder wenn doch, braucht es keine Identität“, und NetworkService, wenn „Sie mit der Identität der Maschine auf eine Ressource in der Domäne zugreifen wollen“.

flowchart TB
    accTitle: Der Unterschied zwischen LocalService und NetworkService
    accDescr: Lokale Rechte sind bei beiden minimal, aber zur Gegenseite verbindet sich LocalService mit anonymen Anmeldeinformationen und NetworkService legt die des Computers vor
    ls["LocalService"] --> anon["Verbindet sich mit anonymen Anmeldeinformationen"]
    anon -.-> ng["Eine Ressource, die Authentifizierung verlangt, ist nicht möglich"]
    ns["NetworkService"] --> comp["Legt die Anmeldeinformationen des Computers vor"]
    comp -.-> pc["In einer Domäne sieht es wie PC$ aus"]

Abbildung 6: Lokale Rechte sind dasselbe Minimum, aber die von der anderen Seite des Netzwerks sichtbare Identität teilt sich in anonym oder Computerkonto.

Diese beiden haben jedoch aus modernem Blick eine Schwäche. Dasselbe Konto wird von vielen Diensten geteilt. Laufen fünf Dienste als LocalService, können die fünf, solange die ACL pro Konto ist, auf die Ressourcen der jeweils anderen zugreifen. SQL Server unterstützt das Konto Local Service aus demselben Grund nicht: Es ist ein geteiltes Konto und lässt sich nicht von anderen Diensten trennen.¹

flowchart TB
    accTitle: Ein geteiltes Konto lässt sich nicht trennen
    accDescr: Teilen mehrere Dienste dasselbe LocalService, können sie, solange die ACL pro Konto ist, auf die Ressourcen der jeweils anderen zugreifen
    sva["Dienst A"] --> acct["Dasselbe LocalService"]
    svb["Dienst B"] --> acct
    svc["Dienst C"] --> acct
    acct --> mutual["Können auf die Ressourcen der jeweils anderen zugreifen"]
    mutual -.-> reason["Weil die ACL pro Konto ist"]

Abbildung 7: Dienste, die dasselbe Konto teilen, lassen sich per ACL nicht von den Ressourcen der jeweils anderen trennen.

Dieses „geringere Rechte behalten, aber pro Dienst trennen“ zu lösen ist das nächste Thema, das virtuelle Konto.

5. Virtuelle Konten (NT SERVICE\) — der moderne Standard

5.1. Sie können eine Identität pro Dienst ohne Kennwort haben

Ein virtuelles Konto ist ein „verwaltetes lokales Konto“, verfügbar ab Windows Server 2008 R2 / Windows 7. Es hat drei Eigenschaften.⁶

• Das Konto wird automatisch verwaltet; weder Anlegen noch Setzen eines Kennworts ist nötig
• Der Name ist NT SERVICE\<Dienstname>, und es wird eine jedem Dienst eigene Identität
• In einer Domänenumgebung kann es mit den Anmeldeinformationen des Computerkontos (DOMAIN\Computername$) auf das Netzwerk zugreifen

Mit anderen Worten: Es behält den Vorzug „keine Kennwortverwaltung“ von LocalService/NetworkService und nimmt den Nachteil „lässt sich nicht trennen, weil das Konto geteilt ist“ weg. Deshalb setzt das SQL-Server-Setup standardmäßig ein virtuelles Konto wie NT SERVICE\MSSQLSERVER.¹

flowchart TB
    accTitle: Was ein virtuelles Konto vereinbar macht
    accDescr: Ein virtuelles Konto behält den Vorzug keine Kennwortverwaltung von LocalService und NetworkService, nimmt den Nachteil lässt sich nicht trennen weil geteilt weg und hat eine jedem Dienst eigene Identität
    merit["Vorzug (keine Kennwortverwaltung)"] -->|Behalten| va["Virtuelles Konto"]
    demerit["Nachteil (lässt sich nicht trennen weil geteilt)"] -->|Wegnehmen| va
    va --> ident["Eine jedem Dienst eigene Identität"]
    va --> auto["Weder Anlegen noch Kennwortsetzen ist nötig"]

Abbildung 8: Ein virtuelles Konto behält die Vorzüge der integrierten Konten und nimmt nur den Nachteil weg, dass geteilt nicht trennbar ist.

5.2. Sie können „NT SERVICE\Dienstname“ direkt auf eine ACL schreiben

Die praktische Bequemlichkeit ist, dass Sie nur diesen Dienst namentlich zu einer ACL hinzufügen können. „Nur dieser Dienst darf in diesen Datenordner schreiben“ lässt sich ohne Anlegen einer Gruppe und ohne Kennwortverwaltung umsetzen.

# Change the service's logon account to a virtual account
# The value of obj= is "NT SERVICE\service-name". Do not specify a password
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Confirm the configuration (check SERVICE_START_NAME)
sc.exe qc MyAppService

# Grant modify rights on the data folder to this service only
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

In der GUI öffnen Sie in services.msc die Eigenschaften des Dienstes → die Registerkarte „Anmelden“ → geben Sie NT SERVICE\Dienstname unter „Dieses Konto“ ein und lassen Sie die Kennwortfelder leer (für ein virtuelles Konto oder ein MSA ist das Nichtangeben eines Kennworts die Spezifikation des SCM). Nach der Änderung wendet ein Neustart des Dienstes sie an.

5.3. Die Einschränkung — außerhalb der Maschine ist es nicht „dieser Dienst“

Die Identität eines virtuellen Kontos ist maschinenlokal und wird von der Domäne nicht erkannt. Im Netzwerk fällt sie wie später beschrieben auf das Computerkonto zusammen, daher kann die Gegenseite nicht sagen, „welcher Dienst es ist“, und Sie können dieselbe Identität auch nicht über mehrere Server teilen.¹⁰

flowchart TB
    accTitle: Die Identität eines virtuellen Kontos fällt außerhalb der Maschine zusammen
    accDescr: Ein virtuelles Konto, das innerhalb der Maschine pro Dienst einzigartig ist, fällt im Netzwerk ebenfalls auf das Computerkonto zusammen, und die Gegenseite kann nicht sagen, welcher Dienst es ist
    vaa["Virtuelles Konto A"] --> pc["Computerkonto PC$"]
    vab["Virtuelles Konto B"] --> pc
    pc --> remote["Die der Gegenseite sichtbare Identität"]
    remote -.-> nodist["Kann nicht sagen, welcher Dienst es ist"]

Abbildung 9: Selbst mit einer einzigartigen Identität innerhalb der Maschine sieht auf der anderen Seite des Netzwerks jeder Dienst wie dasselbe PC$ aus.

Der Moment, in dem diese Einschränkung — Bedarf einer dienstspezifischen Identität auf der anderen Seite des Netzwerks, Bedarf derselben Identität auf mehreren Servern — zum Problem wird, ist der, in dem ein gMSA (Kapitel 8) gerufen wird.

6. Identität beim Gang ins Netzwerk — die Praxis des Computerkontos (PC$)

6.1. „Ein Dienst kann nicht auf einen freigegebenen Ordner zugreifen“ ist ein Missverständnis

Auf einer der Domäne beigetretenen Maschine authentifiziert sich ein Dienst, der als LocalSystem, NetworkService oder virtuelles Konto läuft, beim Zugriff auf eine entfernte Ressource als Computerkonto (DOMAIN\Computername$).³⁶ Viele der Eingangsberatungen „er kam nicht an einen freigegebenen Ordner, also haben wir ihn zum Domänenbenutzer gemacht“ lösen sich tatsächlich damit. Die Ziel-ACL erlaubte PC$ einfach nicht.

flowchart TB
    accTitle: Remotezugriff als Computerkonto
    accDescr: Ein LocalSystem-, NetworkService- oder virtuelles-Konto-Dienst auf einer der Domäne beigetretenen Maschine authentifiziert sich gegenüber der Gegenseite als Computerkonto, und wenn die Ziel-ACL PC$ erlaubt, kann er zugreifen
    svc["Dienst (LocalSystem, ein virtuelles Konto und dergleichen)"] --> auth["Als PC$ authentifizieren"]
    auth --> acl{"Erlaubt die Ziel-ACL PC$?"}
    acl -->|Ja| ok["Zugriff auf einen freigegebenen Ordner oder eine DB gelingt"]
    acl -->|Nein| ng["Zugriff wird verweigert"]

Abbildung 10: In einer Domänenumgebung begründet allein das Vergeben von PC$ auf der Ziel-ACL Remotezugriff ohne Domänenbenutzer.

Das Vergeben auf der Dateiserverseite ist dasselbe wie eine gewöhnliche ACL-Operation; geben Sie Computername$ als Kontoname an (im GUI-Objektauswahldialog schließen Sie „Computer“ in die Objekttypen ein).

# On the file-server side: grant a service on APPSV01 modify rights on the shared folder
# You need to grant both share permissions and NTFS permissions
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

SQL Server ist dasselbe: Legen Sie das Computerkonto als Anmeldung an, und die Verbindungszeichenfolge geht mit Integrated Security=true und ohne Kennwort durch.

-- On the DB-server side: permit Windows integrated authentication from a service on APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. Die Grenzen des PC$-Ansatzes kennen

Dieser Ansatz hat zwei Grenzen.

1. Die Körnung ist pro Maschine. LocalSystem, NetworkService und jeder virtuelle-Konto-Dienst auf derselben Maschine sehen von der Gegenseite alle wie dasselbe PC$ aus. Sie können auf dem Ziel nicht „nur diesem Dienst erlauben“, und Sie können auch nicht prüfen, welcher Dienst dieses Konto genutzt hat.²
2. Er lässt sich in einer Arbeitsgruppenumgebung nicht nutzen. Ein Computerkonto ist ein Active-Directory-Objekt, daher hat eine Maschine, die nicht der Domäne beigetreten ist, keines. Sie brauchen ein Design, das die Anmeldeinformationen des Zielkontos explizit behandelt.

Wenn Sie Grenze 1 überschreiten wollen, ist die Antwort 2026 nicht der Domänenbenutzer des nächsten Kapitels … sondern dieses Problem zu überspringen und zu einem gMSA weiterzugehen.

flowchart TB
    accTitle: Zwei Grenzen des PC$-Ansatzes
    accDescr: Authentifizierung als PC$ hat Körnung auf Maschinenebene, daher ist weder Erlaubnis noch Prüfung pro Dienst möglich, und in einer Arbeitsgruppe existiert das Computerkonto selbst nicht, daher lässt es sich nicht nutzen
    pcs["Der PC$-Ansatz"] --> lim1["Grenze 1: pro Maschine"]
    pcs --> lim2["Grenze 2: keine Arbeitsgruppe"]
    lim1 -.-> noaudit["Weder Erlaubnis noch Prüfung pro Dienst"]
    lim2 -.-> nocred["Explizite Anmeldeinformationen nutzen"]
    lim1 --> gmsa["Darüber hinaus: ein gMSA"]

Abbildung 11: Wenn Sie die zwei Grenzen Körnung auf Maschinenebene und Domänen-Voraussetzung überschreiten wollen, überspringen Sie den Domänenbenutzer und gehen zu einem gMSA weiter.

7. Das Problem, einen Domänenbenutzer für einen Dienst zu nutzen

7.1. Das strukturelle Problem des Kennworts

Weisen Sie einem Dienst einen Domänenbenutzer (oder einen lokalen Benutzer) zu, speichert der SCM dieses Kennwort und nutzt es bei jedem Start zur Anmeldung. Der SCM verwaltet Ablauf nicht, daher schlägt die Anmeldung fehl, wenn das Kennwort abläuft, und der Dienst startet nicht.⁷

Von dort beginnt die Abwärtsspirale, die man oft im Feld sieht.

1. Ein Unfall, dass der Dienst wegen Ablaufs stehen bleibt, tritt ein
2. Als Wiederholungsvorbeugung wird „Kennwort läuft nie ab“ gesetzt
3. Ein Änderungsverfahren wird nie etabliert, und dasselbe Kennwort steht im Klartext in den Runbooks, Skripten und der Aufgabenplanung mehrerer Server
4. Selbst wenn jemand geht, ändert sich das Kennwort nicht (wenn Sie es ändern, wissen Sie nicht, was stehen bleibt)

flowchart TB
    accTitle: Die Abwärtsspirale des Betriebs mit einem Domänenbenutzer
    accDescr: Das Kennwort läuft ab und der Dienst bleibt stehen, nie-ablaufen wird als Wiederholungsvorbeugung gesetzt, ein Klartextkennwort verbreitet sich in Runbooks und Skripten, und selbst wenn jemand geht, lässt es sich nicht ändern
    expire["1. Ablauf hält den Dienst an"] --> forever["2. Nie-ablaufen wird als Vorbeugung gesetzt"]
    forever --> spread["3. Ein Klartextkennwort verbreitet sich"]
    spread -.-> where["Runbooks, Skripte, Aufgaben"]
    spread --> stuck["4. Selbst wenn jemand geht, lässt es sich nicht ändern"]

Abbildung 12: Ausgehend von einem Ablaufunfall verfestigen sich Nie-ablaufen und die Verbreitung eines Klartextkennworts.

Microsoft weist auch darauf hin, dass eine Konfiguration, die ein Domänenkonto für einen Dienst nutzt, erheblichen Betriebsaufwand in der manuellen Verwaltung von Kennwort und SPN kostet und dass Wartung zu einem Dienststopp führen kann.¹

7.2. Kerberoasting — ein Dienstkonto wird ins Visier genommen

Ein weiterer, für ein Domänenbenutzer-Dienstkonto spezifischer Angriff ist Kerberoasting. Ein Dienst, der Kerberos-Authentifizierung empfängt, registriert einen SPN (Dienstprinzipalname) auf dem Anmeldekonto. Jeder authentifizierte Benutzer in der Domäne kann ein Dienstticket für ein Konto anfordern, das einen SPN registriert hat, daher holt sich ein Angreifer das Ticket und versucht eine Offline-Brute-Force des Kennworts. Ein 10- bis 16-Zeichen-Kennwort, das ein Mensch entschieden hat, hält diesem Angriff nicht stand.

flowchart TB
    accTitle: Der Ablauf von Kerberoasting
    accDescr: Ein Dienstticket zu einem Dienstkonto, das einen SPN registriert hat, kann von jedem authentifizierten Benutzer angefordert werden, daher holt sich ein Angreifer das Ticket und versucht eine Offline-Brute-Force des Kennworts
    atk["Ein authentifizierter Benutzer in der Domäne"] --> req["Ein Ticket für den SPN anfordern"]
    req --> tkt["Ein Dienstticket erhalten"]
    tkt --> brute["Offline-Brute-Force"]
    brute --> weak["Etwa 10 bis 16 Zeichen werden geknackt"]

Abbildung 13: Jeder authentifizierte Benutzer kann ein Ticket anfordern, und ein Kennwort einer von einem Menschen entschiedenen Länge hält einer Offline-Brute-Force nicht stand.

Die wirksame Antwort ist, das Kennwort zu einer Stärke zu machen, die ein Mensch weder erraten noch knacken kann. Microsoft listet auch das Erzwingen eines langen Kennworts und die Nutzung eines gMSA, dessen Kennwort ein langer maschinenerzeugter Zufallswert wird.⁸ Dasselbe Dokument erwähnt auch Kerberos-Härtung (FAST), aber FAST schützt Vorauthentifizierungsdaten und Widerstand gegen KDC-Täuschung; es verhindert nicht, dass ein authentifizierter Benutzer ein Dienstticket zu einem SPN anfordert, daher ist es kein Ersatz für die Kennwortstärke eines Dienstkontos. Die Beziehung zwischen SPNs und Kerberos und die Bedingungen, unter denen Authentifizierung auf NTLM zurückfällt, sind in „NTLM und Kerberos anhand von Diagrammen erklärt“ dargestellt.

7.3. Wenn Sie trotzdem einen Domänenbenutzer nutzen

Wenn Sie keine Wahl haben als einen Domänenbenutzer zu nutzen, etwa weil die Anwendung kein gMSA unterstützt, behandeln Sie Folgendes als Mindestminderung.

• Machen Sie das Kennwort zufällig erzeugte 25 Zeichen oder mehr und schreiben Sie es nirgendwo außer in ein Kennwortverwaltungswerkzeug (Runbooks, Skripte, eine geteilte Excel)
• Machen Sie es zu einem dienstexklusiven Konto und teilen Sie es pro Dienst (teilen Sie es nicht mit einem menschlichen Konto²)
• Verweigern Sie interaktive Anmeldung und Remotedesktop und erlauben Sie nur „Anmelden als Dienst“
• Minimieren Sie die Gruppen, denen es angehört (es zu Domain Admins hinzuzufügen kommt nicht in Frage)
• Etablieren Sie ein periodisches Rotationsverfahren und legen Sie die Stellen, die eine Änderung betrifft, in ein Verzeichnis

All das zu tun ist unsicherer und weniger einfach als die Migration zu einem gMSA — das ist das nächste Kapitel.

8. gMSA — Kennwortverwaltung Active Directory überlassen

8.1. Der Mechanismus und die Wirkung

Ein gMSA (gruppenverwaltetes Dienstkonto) ist ein Domänenkonto, das die Kennwortverwaltung dem Domänencontroller überlässt. Das Kennwort wird vom Domänencontroller aus dem KDS-Stammschlüssel (Key Distribution Service) berechnet, und nur erlaubte Hosts holen es.¹³

flowchart TB
    accTitle: Wie ein gMSA das Kennwort verwaltet
    accDescr: Der Domänencontroller berechnet das Kennwort aus dem KDS-Stammschlüssel, nur erlaubte Hosts holen es und nutzen es zum Ausführen des Dienstes, und das Kennwort wird standardmäßig alle 30 Tage automatisch rotiert
    kds["KDS-Stammschlüssel"] --> dc["Der DC berechnet das Kennwort"]
    dc --> host["Ein erlaubter Host holt es"]
    host --> svc["Zum Ausführen des Dienstes genutzt"]
    dc -.-> rot["Automatische Rotation alle 30 Tage standardmäßig"]

Abbildung 14: Der Domänencontroller übernimmt Erzeugung, Verteilung und Aktualisierung des Kennworts, und Menschen können betreiben, ohne das Kennwort zu kennen.

Die Wirkungen sind klar.⁹

• Ein 240-Byte zufällig erzeugtes Kennwort: Brute-Force und Wörterbuchangriffe werden unrealistisch, und der Widerstand gegen Kerberoasting steigt erheblich
• Automatische Rotation alle 30 Tage standardmäßig: Ein Mensch muss keine Änderung planen, und der Dienst muss nicht gestoppt werden
• Dieselbe Identität kann über mehrere Server geteilt werden: Eine Serverfarm unter Lastausgleich kann sich gegenseitig als derselbe Prinzipal authentifizieren
• Einfachere SPN-Verwaltung: Registrierung und Verwaltung von SPNs können auch delegiert und vereinfacht werden

Menschen können betreiben, ohne das Kennwort zu kennen — nimmt man es als den Mechanismus, der für ein Dienstkonto tut, was Windows LAPS für ein lokales Administratorkennwort tut, ist die Einordnung leichter zu greifen.

8.2. Anforderungen

Ein gMSA hat Voraussetzungen.¹⁰

• Eine Active-Directory-Domänenumgebung (in einer Arbeitsgruppe nicht möglich)
• Domänen- und Gesamtstrukturfunktionsebenen Windows Server 2012 oder höher
• Ein KDS-Stammschlüssel ist bereits angelegt
• Der gMSA-Name ist in der Gesamtstruktur eindeutig, nicht nur in der Domäne
• Das Kennwortänderungsintervall kann nur bei der Erstellung gesetzt werden

Das Anlegen des KDS-Stammschlüssels ist eine einmalige Aufgabe, aber bis zu 10 Stunden nach dem Anlegen können Sie kein gMSA anlegen, weil Sie auf Replikation zu jedem Domänencontroller warten. Es ist eine Sicherheitseinrichtung, um den Unfall zu verhindern, dass das Abrufen des Kennworts fehlschlägt, bevor die Replikation fertig ist.¹⁴

flowchart TB
    accTitle: Vom Anlegen des KDS-Stammschlüssels zum Anlegen eines gMSA
    accDescr: Nach dem Anlegen des KDS-Stammschlüssels warten Sie auf Replikation zu jedem Domänencontroller, daher können Sie bis zu 10 Stunden kein gMSA anlegen; nach Abschluss der Replikation können Sie eines anlegen
    add["Den KDS-Stammschlüssel anlegen"] --> wait["Bis zu 10 Stunden Warten auf Replikation"]
    wait -.-> why["Eine Sicherheitseinrichtung gegen einen Abruf-Fehler-Unfall"]
    wait --> done["Replikation zu jedem DC ist abgeschlossen"]
    done --> ok["Sie können ein gMSA anlegen"]

Abbildung 15: Das Warten von bis zu 10 Stunden nach dem Anlegen des Stammschlüssels ist Wartezeit, um einen Abruffehlschlag zu verhindern, solange die Replikation nicht fertig ist.

# Run as a domain administrator, on a domain controller (or an administrative
# workstation with the AD PowerShell module)

# Confirm whether a KDS root key exists, and create one if not (once per forest)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Actually usable after up to 10 hours

8.3. Das Verfahren von der Erstellung zur Konfiguration

Das Verfahren hat vier Stufen: „① eine zum Abrufen berechtigte Gruppe anlegen → ② das gMSA anlegen → ③ es auf den Servern installieren → ④ es am Dienst setzen“.¹⁰

flowchart TB
    accTitle: Die vier Stufen der Einführung eines gMSA
    accDescr: Es in vier Stufen einführen: Anlegen einer zum Abrufen des Kennworts berechtigten Gruppe, Anlegen des gMSA, Installieren auf jedem Server und Setzen als Anmeldekonto des Dienstes
    st1["① Eine zum Abrufen berechtigte Gruppe anlegen"] --> st2["② Das gMSA anlegen"]
    st1 -.-> add["Die PC$ der Server hinzufügen"]
    st2 --> st3["③ Auf jedem Server installieren"]
    st3 -.-> test["Abruf mit dem Test-Befehl prüfen"]
    st3 --> st4["④ Am Dienst setzen"]

Abbildung 16: Vom Anlegen der Gruppe bis zum Setzen des Dienstes verläuft die Einführung eines gMSA in vier Stufen.

# ① Create a security group permitted to retrieve the password,
#    and add the computer accounts of the servers that will run the service
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Group membership is evaluated at computer logon, so
# restarting the target servers after adding is the reliable approach

# ② Create the gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ On each server that will run the service, install the gMSA and validate
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True means retrieval is working

# ④ Set it as the service's logon account. Append $ to the name, and do not specify a password
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

Beim Setzen aus services.msc ist der Kontoname ebenfalls wie CORP\svc-batch$ — hängen Sie $ am Ende an und lassen Sie die Kennwortfelder leer. Ein Konto der MSA-Familie kann nicht für eine interaktive Anmeldung genutzt werden.¹ Danach vergeben Sie CORP\svc-batch$ auf der ACL eines freigegebenen Ordners oder von SQL Server anstelle von PC$, und Netzwerkzugriff mit einer dienstspezifischen Identität ist fertig, ohne Kennwort.

8.4. Manche Apps unterstützen es nicht

Als Vorbehalt: Nicht jede Software läuft als gMSA. Dinge, die die Anmeldeidentität über einen Standardmechanismus konfigurieren — ein Windows-Dienst, ein IIS-Anwendungspool, eine Aufgabe der Aufgabenplanung — sind breit unterstützt, aber es gibt Einschränkungen wie dass Failoverclustering selbst kein gMSA unterstützt und eine App, deren Inneres ein Kennwort verlangt, es nicht nutzen kann.¹⁰ Microsoft stellt auch klar, dass Sie das Verhalten als gMSA in einer Testumgebung vor der Produktion bestätigen sollten.⁹

flowchart TB
    accTitle: Unterscheiden, ob etwas ein gMSA unterstützt
    accDescr: Eine App, die die Anmeldeidentität über einen Standardmechanismus konfiguriert, unterstützt ein gMSA breit, aber Failoverclustering und eine App, deren Inneres ein Kennwort verlangt, können es nicht nutzen, daher in einer Testumgebung vor der Produktion bestätigen
    app["Die Ziel-App"] --> how{"Wie wird die Anmeldung gesetzt?"}
    how -->|Standardmechanismus| okapp["gMSA unterstützt"]
    okapp -.-> ex1["Dienst, IIS, eine Aufgabe"]
    how -->|Kennwort verlangt| ngapp["gMSA nicht möglich"]
    ngapp -.-> ex2["Failoverclustering"]
    okapp --> test["Vor der Produktion testen"]

Abbildung 17: Eine App, die die Anmeldung über einen Standardmechanismus konfiguriert, ist breit unterstützt, aber manche Entwürfe sind nicht unterstützt, daher ist Validierung vor der Produktion unverzichtbar.

Es gibt auch Geschwister: das sMSA (eigenständiges verwaltetes Dienstkonto) für einen einzelnen Server und das dMSA (delegiertes verwaltetes Dienstkonto, eingeführt in Windows Server 2025, das sich an Geräteidentität bindet, um Diebstahl von Anmeldeinformationen zu begegnen). Für einen Neubau nehmen Sie ein gMSA als Basis und erwägen je nach Anforderungen.⁶

9. Begleitender Entwurf — Anmelderechte, Profil, DPAPI und Prüfung

Vier weitere Dinge, die sich mit dem Konto ändern, zum Behalten.

9.1. Das Recht „Anmelden als Dienst“ (SeServiceLogonRight)

Um als Dienst zu starten, braucht das Konto das Benutzerrecht „Anmelden als Dienst“. LocalSystem, LocalService und NetworkService haben es eingebaut, aber jedes andere Konto (ein Domänenbenutzer, ein gMSA und dergleichen) braucht eine ausdrückliche Zuweisung.¹⁵

Setzen Sie es über die Registerkarte „Anmelden“ der services.msc-GUI, vergibt das Snap-In dieses Recht automatisch. Dagegen prüfen CreateService / ChangeServiceConfig (die APIs, die sc.exe config aufruft) nicht, ob das angegebene Konto dieses Recht hat. Die typische Ursache, dass ein per Skript konfigurierter Dienst beim Start mit „der Dienst wurde aufgrund eines Anmeldefehlers nicht gestartet“ stehen bleibt, ist diese. Verlassen Sie sich nicht auf eine Nebenwirkung eines Werkzeugs; nehmen Sie in das Bereitstellungsverfahren ausdrücklich das Hinzufügen zu „Anmelden als Dienst“ in der lokalen Sicherheitsrichtlinie (secpol.msc) oder die Konfiguration über GPO/Intune auf (in einer Umgebung, die dieses Recht mit Gruppenrichtlinie konfiguriert, wird eine lokale Vergabe überschrieben, wenn die Richtlinie greift, daher braucht das ebenfalls Aufmerksamkeit). Umgekehrt ist der Standardzug für ein dienstexklusives Konto, zugleich „Lokale Anmeldung verweigern“ zu setzen.

flowchart TB
    accTitle: Der Unterschied nach dem Konfigurationsweg des Rechts Anmelden als Dienst
    accDescr: Die services.msc-GUI vergibt das Recht automatisch, aber die API, die sc.exe config aufruft, prüft das Recht nicht, daher hält ein Konto ohne das Recht den Dienst beim Start mit einem Anmeldefehler an
    gui["In services.msc setzen"] --> auto["Das Recht wird automatisch vergeben"]
    auto --> okgui["Der Dienst kann starten"]
    cli["Mit sc.exe config setzen"] --> noval["Das Recht wird nicht geprüft"]
    noval --> has{"Hat es das Recht?"}
    has -->|Ja| okcli["Der Dienst kann starten"]
    has -->|Nein| stop["Bleibt mit einem Anmeldefehler stehen"]
    stop -.-> fix["Ausdrücklich mit secpol.msc oder einer GPO vergeben"]

Abbildung 18: Die GUI vergibt das Recht automatisch, aber eine skriptierte Konfiguration prüft es nicht, daher müssen Sie eine ausdrückliche Vergabe ins Verfahren aufnehmen.

9.2. Profil, %TEMP% und HKEY_CURRENT_USER ändern sich

Der SCM lädt beim Dienststart das Benutzerprofil dieses Kontos.⁷ Daher sind die echten %TEMP%, %APPDATA% und HKEY_CURRENT_USER pro Anmeldekonto eine andere Sache, und wenn Sie Konten wechseln, sehen Einstellungen und Caches, die im Profil des alten Kontos gespeichert waren, aus, als wären sie „verschwunden“.

Die Entwurfsantwort ist einfach: legen Sie die Daten des Dienstes nicht unter das Profil, sondern auf einen ausdrücklichen Pfad wie C:\ProgramData\<App-Name>, und vergeben Sie diese ACL an das Anmeldekonto. So kommt ein Kontowechsel nicht mit einer Datenmigration.

flowchart TB
    accTitle: Profilabhängigkeit und die Antwort der Datenplatzierung
    accDescr: Das echte Profil ist pro Anmeldekonto eine andere Sache, daher lässt ein Kontowechsel die Daten des alten Profils aussehen als wären sie verschwunden, aber das Platzieren auf einem ausdrücklichen Pfad und das Vergeben der ACL macht Migration unnötig
    sw["Wechseln des Anmeldekontos"] --> newprof["Ein anderes Profil wird geladen"]
    newprof --> lost["Die alten Daten sehen aus als wären sie verschwunden"]
    lost -.->|Antwort| fix["Unter ProgramData legen"]
    fix --> acl["Die ACL an das Anmeldekonto vergeben"]
    acl --> nomig["Keine Migration auch wenn das Konto wechselt"]

Abbildung 19: Vermeiden Sie das Profil und legen Sie die Daten auf einen ausdrücklichen Pfad, und ein Kontowechsel kommt nicht mehr mit einer Datenmigration.

9.3. Mit DPAPI geschützte Daten sind an das Konto gebunden

Noch leichter zu übersehen ist DPAPI. Daten, die mit benutzerbezogenem DPAPI (CryptProtectData oder .NETs ProtectedData) verschlüsselt wurden, können grundsätzlich nur von demselben Konto entschlüsselt werden, das sie geschützt hat. In dem Moment, in dem Sie das Konto ändern, lässt sich eine gespeicherte Verbindungszeichenfolge oder ein API-Schlüssel nicht mehr lesen — das ist DPAPI, das seine Arbeit korrekt macht, aber wenn es nicht im Migrationsverfahren steht, wird es zum Vorfall.

flowchart TB
    accTitle: Die Beziehung zwischen DPAPI-geschützten Daten und einem Kontowechsel
    accDescr: Daten, die mit benutzerbezogenem DPAPI geschützt wurden, können nur von demselben Konto entschlüsselt werden, das sie geschützt hat, daher müssen Sie nach dem Wechsel des Anmeldekontos die Geheimnisse erneut eingeben
    protect["Mit dem alten Konto per DPAPI schützen"] --> data["Eine geschützte Verbindungszeichenfolge und dergleichen"]
    data --> who{"Welches Konto entschlüsselt?"}
    who -->|Dasselbe alte Konto| okdec["Kann entschlüsseln"]
    who -->|Das neue Konto| ngdec["Kann nicht entschlüsseln"]
    ngdec --> re["Die Geheimnisse erneut eingeben"]

Abbildung 20: DPAPI-geschützte Daten sind an das Konto gebunden, das sie geschützt hat, und nach einem Kontowechsel müssen Sie erneut eingeben.

Die Antwort ist, ins Migrationsplan das Verfahren „Geheimnisse nach dem Kontowechsel erneut eingeben“ aufzunehmen (für den Entwurf, wo Sie sie speichern, siehe „Geheimnisse in Windows-Apps speichern“). Auch kann eine Konfiguration, die mit integrierter Windows-Authentifizierung als gMSA oder PC$ fertig wird, das Speichern des Geheimnisses selbst beseitigen. Die richtige Reihenfolge ist, zuerst „können wir ohne Speichern auskommen“ zu erwägen, bevor „wo speichern wir es“.

Und wenn der Dienst „mit den Rechten des aufrufenden Benutzers“ verarbeiten will, nutzen Sie Identitätswechsel statt das Konto stärker zu machen. Dazu siehe „Windows-Identitätswechseltoken richtig handhaben“.

9.4. Prüfung — 4624 Anmeldetyp 5 ansehen

Ein Dienststart wird im Sicherheitsereignisprotokoll als Ereignis-ID 4624 (Ein Konto wurde erfolgreich angemeldet) mit Anmeldetyp 5 (Dienst: der SCM hat einen Dienst gestartet) aufgezeichnet. Das Feld „Virtual Account“ im Ereignis zeigt, ob die Anmeldung durch ein MSA / virtuelles Konto erfolgte, daher kann es auch genutzt werden, um die Nutzung verwalteter Konten zu beobachten.¹¹

flowchart TB
    accTitle: Der Ablauf der Prüfung eines Dienststarts
    accDescr: Dass der SCM einen Dienst startet, wird als Ereignis-ID 4624 Anmeldetyp 5 aufgezeichnet, und das Feld Virtual Account kann identifizieren, ob die Anmeldung durch ein verwaltetes Konto erfolgte
    start["Der SCM startet einen Dienst"] --> ev["Ereignis-ID 4624 aufzeichnen"]
    ev --> type5["Anmeldetyp 5 (Dienst)"]
    type5 --> vafield["Feld Virtual Account"]
    vafield --> watch["Beobachten verwalteter Konten"]

Abbildung 21: Ein Dienststart wird als 4624 vom Anmeldetyp 5 aufgezeichnet, und Sie können sogar die Nutzung verwalteter Konten verfolgen.

Für ein Inventar des Ist-Zustands ist das Aggregieren der Anmeldekonten der Dienstliste die schnelle Methode.

# Aggregate which services are running as which account
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Inventory non-standard services running as LocalSystem (tell in-house / third-party by the path)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

Wenn diese Ausgabe „einen Geschäftsdienst, der als LocalSystem läuft“ und „einen Dienst, der als Domänenbenutzer läuft“ aufreiht, ist der Entscheidungsfluss des nächsten Kapitels gerufen.

10. Entscheidungsfluss — mit vier Fragen entscheiden

Hier der Inhalt bisher als Auswahlverfahren. Beantworten Sie vier Fragen der Reihe nach.

flowchart TB
    accTitle: Der Entscheidungsfluss für das Anmeldekonto
    accDescr: Das Anmeldekonto entscheiden, indem Sie der Reihe nach die vier Fragen nach Netzwerkzugriff, Domänenbeitritt, ob eine Identität auf Maschinenebene reicht, und gMSA-Unterstützung beantworten
    q1{"Win-Auth zu einem Partner?"} -->|Nein| va["Virtuelles Konto"]
    va -.-> sys["LocalSystem falls nötig"]
    q1 -->|Ja| q2{"Der Domäne beigetreten?"}
    q2 -->|Nein| cred["Gespeicherte Anmeldeinformationen schützen"]
    q2 -->|Ja| q3{"Maschinenebene genug?"}
    q3 -->|Ja| pcacl["Virtuelles Konto + PC$"]
    q3 -->|Nein| q4{"App unterstützt ein gMSA?"}
    q4 -->|Ja| gmsa["gMSA"]
    q4 -->|Nein| du["Benutzer + Minderungen"]

Abbildung 22: Beantworten Sie die vier Fragen der Reihe nach, und welches der sechs Sie nutzen sollten, ist entschieden.

Frage 1: Greift dieser Dienst mit Windows-Authentifizierung auf eine andere Maschine im Netzwerk zu (einen freigegebenen Ordner, eine DB, eine API und dergleichen)?

Wenn nicht, ist ein virtuelles Konto der Standard. Nur wenn ein besonderes lokales Recht nötig ist, bestätigen Sie diesen Bedarf und erwägen Sie dann LocalSystem.

Frage 2: (Falls es zugreift) Ist die Maschine der Domäne beigetreten?

In einer Arbeitsgruppe können weder PC$ noch ein gMSA genutzt werden. Nutzen Sie ein Design, das die Anmeldeinformationen des Zielkontos explizit behandelt (schützen Sie den Speicher mit DPAPI oder Ähnlichem), oder erwägen Sie den Beitritt zur Domäne.

Frage 3: (In einer Domäne) Reicht eine Identität auf Maschinenebene (PC$)?

Wenn ja, ist ein virtuelles Konto (oder NetworkService) + PC$ auf der Ziel-ACL vergeben fertig. Brauchen Sie eine dienstspezifische Identität oder eine gemeinsame Identität über mehrere Server, gehen Sie zu Frage 4.

Frage 4: Unterstützt die Anwendung ein gMSA?

Wenn ja (Dinge, die die Anmeldung über einen Standardmechanismus konfigurieren — SCM, ein IIS-Anwendungspool, Aufgabenplanung — tun das im Allgemeinen), ein gMSA. Vergessen Sie nicht eine Verhaltensprüfung in einer Validierungsumgebung. Ist es unabhängig davon nicht unterstützt, nutzen Sie nach Anwendung jeder Minderung in Abschnitt 7.3 einen dedizierten Domänenbenutzer.

In einer Tabelle ist es wie folgt.

11. Zusammenfassung

• Das Anmeldekonto eines Dienstes ist eine Entwurfsentscheidung, die zugleich lokale Rechte, Netzwerkidentität und Kennwortverwaltung entscheidet. Lassen Sie es nicht beim Standard (LocalSystem).
• LocalSystem hält ein SYSTEM+Administrators-Token und starke Rechte, und der Schaden bei Übernahme ist maximiert. Die meisten Geschäftsdienste brauchen dieses Recht nicht.
• LocalService und NetworkService sind beide mit geringen Rechten; der Unterschied ist die Netzwerkidentität (anonym oder das Computerkonto). Weil das Konto von mehreren Diensten geteilt wird, lassen sie sich jedoch nicht trennen.
• Ein virtuelles Konto (NT SERVICE\) ist der moderne Standard, der pro Dienst trennen kann, ohne Kennwortverwaltung zu brauchen. Sie können es direkt auf einer ACL angeben, und die Konfiguration ist nur das Ändern des Anmeldekontonamens.
• LocalSystem, NetworkService und ein virtuelles Konto gehen in einer Domänenumgebung als DOMAIN\PC$ ins Netzwerk. PC$ auf der ACL eines freigegebenen Ordners oder von SQL Server zu vergeben lässt oft einen Domänenbenutzer entbehrlich.
• Einen Domänenbenutzer für einen Dienst zu nutzen hat die strukturellen Probleme eines Stopps durch Ablauf, der Verbreitung eines Klartextkennworts und Kerberoasting. Wenn Sie einen nutzen, sind ein dediziertes Konto + ein langes Zufallskennwort + Anmeldebeschränkungen erforderlich.
• Ein gMSA ist ein Mechanismus, in dem AD das Kennwort automatisch erzeugt und rotiert; die Anforderungen sind eine Domäne, Funktionsebene 2012 oder höher und ein KDS-Stammschlüssel. Setzen Sie den Dienst auf „DOMAIN\Name$“ mit leerem Kennwortfeld.
• Wenn Sie das Konto ändern, nehmen Sie das Recht „Anmelden als Dienst“, das Verschieben von Profil und %TEMP% und das erneute Eingeben DPAPI-geschützter Daten ins Migrationsverfahren auf. Die Prüfung lässt sich mit Ereignis-ID 4624 Anmeldetyp 5 bestätigen.

Wenn Sie das nächste Mal einen Dienst installieren, halten Sie auf dem Bildschirm der Anmeldeeinstellungen einen Moment inne und fragen Sie das erneut. Als wer, und wie weit, sollte dieser Dienst zugreifen können? Die Antwort sollte irgendeine Zeile der Entscheidungstabelle dieses Artikels sein.

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 in einer Prüfung 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 LocalSystem-artige lokale Rechte braucht (starke Rechte jenseits eines Administrators). Geht es nur um Dateilesen und -schreiben und 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 von Profil oder DPAPI abhängen, und ob das Recht „Anmelden als Dienst“ vorliegt. Prüfen Sie Start und die Hauptfunktionen in einer Validierungsumgebung, 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 kleine 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 Basis, 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 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.