Dienstidentitäten und lokaler Zugriff

Unter welchem Konto ein Dienst läuft, wird meistens nebenbei entschieden — und legt gleichzeitig fest, was er lokal darf, als wer er im Netz auftritt und wer sein Kennwort kennt. Dieses Modul behandelt die Fälle, in denen die eingebauten Konten nicht reichen: dasselbe lokale Administratorkennwort auf sechzig Servern, ein gruppenverwaltetes Dienstkonto, dessen Kennwort jeder Domänencomputer abholen darf, ein doppelter SPN, der Kerberos still auf NTLM zurückfallen lässt, und eine Härtungsgruppe, deren Anwendung auf Dienstkonten laut Dokumentation gar nichts schützt.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04

Warum das ein eigenes Thema ist

Ein Dienst braucht eine Identität, unter der er läuft. Diese Wahl wird oft nebenbei getroffen — beim Einrichten steht ein Feld da, jemand trägt ein Konto ein, fertig. Sie entscheidet aber über drei Dinge gleichzeitig: was der Dienst lokal darf, als wer er im Netz auftritt, und wer das zugehörige Kennwort kennt und drehen muss.

Das Modul über Dienste und Aufgabenplanung hat die eingebauten Konten behandelt — LocalSystem, NETWORK SERVICE, LOCAL SERVICE — und das Recht, sich als Dienst anzumelden. Hier geht es um den Fall, in dem die eingebauten Konten nicht reichen: eine eigene Identität im Verzeichnis, mit allem, was daran hängt.

Die Frage, die alles andere sortiertWozu dient dieses Konto? Ein Notfallzugang, ein Dienst auf einem Server, derselbe Dienst auf zwanzig Servern und ein Skript in einer Automatisierung sind vier verschiedene Fälle mit vier verschiedenen richtigen Antworten. Wer stattdessen mit „welches Konto haben wir schon“ anfängt, landet bei einem Konto, das überall passt — und das ist genau die Eigenschaft, die es gefährlich macht.

Ein Hinweis zur Abgrenzung: Der Track active-directory behandelt das Verzeichnis selbst — Struktur, Replikation, Gruppenrichtlinien, privilegierte Zugriffsmodelle. Hier geht es um die Sicht des Serveradministrators: Welches Konto trägt diesen Dienst auf diesem Server, und was muss dafür im Verzeichnis geschehen sein. Die Entscheidungen fallen auf dem Server, ihre Voraussetzungen liegen im Verzeichnis — dieses Modul verbindet beide Seiten.

Zweck bestimmt die Identität

Vier Zwecke, vier Mechanismen. Ein gemeinsames Kennwort auf vielen Hosts ist der Ausfallradius, nicht die Ausnahme.

Person, interaktiv: Persönliches Konto, Rechte befristet erhöht. Nie ein geteiltes Konto, sonst ist keine Handlung mehr zuordenbar.
Ein Dienst auf einem Server: Standalone Managed Service Account (sMSA) — das Verzeichnis verwaltet das Kennwort.
Derselbe Dienst auf mehreren Servern: Group Managed Service Account (gMSA) — dieselbe Identität für alle Instanzen.
Lokaler Notfallzugang: Windows LAPS — je Gerät ein eigenes, automatisch gedrehtes Kennwort.
Skript oder Automatisierung: Secret zur Laufzeit aus einem verwalteten Speicher, nie im Skript.

Die Zeile, die im Betrieb am meisten Schaden anrichtet, ist die vorletzte, wenn sie fehlt: Ein gemeinsames lokales Administratorkennwort auf allen Servern macht aus einem einzelnen Fund einen Zugang zu allen. Genau dagegen ist LAPS gebaut.

Das lokale Administratorkennwort

Jeder Server hat ein lokales Administratorkonto. In vielen Umgebungen trägt es überall dasselbe Kennwort, weil das die Einrichtung vereinfacht und der Notfallzugang funktionieren muss. Windows LAPS löst genau diesen Zielkonflikt.

Windows LAPS — Eine Windows-Funktion, die das Kennwort eines lokalen Administratorkontos automatisch verwaltet und im Verzeichnis sichert — in Active Directory für domänenbeigetretene Server oder in Microsoft Entra ID für dort registrierte Geräte. Je Gerät entsteht ein eigenes Kennwort.

Zwei Punkte, die oft untergehenErstens nennt die Dokumentation den Schutz gegen Pass-the-hash und seitliche Bewegung ausdrücklich als Zweck — es geht nicht um Komfort, sondern darum, dass ein kompromittierter Server nicht die Nachbarn mitnimmt. Zweitens kann Windows LAPS auf Domänencontrollern auch das Kennwort des Verzeichnisdienst-Wiederherstellungsmodus verwalten; das ist genau das Kennwort, das man im Ernstfall braucht und das sonst niemand mehr kennt.

Der Preis steht in derselben Doku: Die Kennwörter liegen im Verzeichnis, geschützt durch ein feingranulares Berechtigungsmodell und optional verschlüsselt. Wer diese Berechtigungen zu weit setzt, hat die Kennwörter aller Server an einem Ort zusammengeführt und lesbar gemacht — die Berechtigung auf dem Attribut ist deshalb der eigentliche Kontrollpunkt, nicht die Einführung des Verfahrens.

Get-LapsADPassword -Identity <Server>: Liest das aktuelle Kennwort aus Active Directory — sichtbar nur für berechtigte Konten.
Get-LapsDiagnostics: Sammelt Diagnosedaten, wenn ein Gerät sein Kennwort nicht sichert.
Reset-LapsPassword: Erzwingt sofort ein neues Kennwort, etwa nachdem jemand das alte benutzt hat.
Invoke-LapsPolicyProcessing: Wendet die Richtlinie an, ohne auf den nächsten Zyklus zu warten.

Verwaltete Dienstkonten

Ein Domänenkonto als Dienstkonto bedeutet, dass irgendwo ein Kennwort steht, das jemand kennt und drehen muss — und dass beim Drehen jeder Dienst mitgezogen werden will, der es benutzt. Verwaltete Dienstkonten beseitigen diesen Handgriff.

sMSA: Verwaltetes Domänenkonto mit automatischer Kennwortverwaltung und vereinfachter SPN-Verwaltung. Für einen Dienst auf einem Host.
gMSA: Dieselbe Funktion, zusätzlich über mehrere Server hinweg. Der Domänencontroller berechnet das Kennwort; berechtigte Mitgliedshosts holen es ab.
Schlüsselverteilungsdienst: Die Grundlage: Der Microsoft Key Distribution Service liefert den Schlüssel, aus dem das Kennwort abgeleitet wird. Ohne ihn gibt es keine gMSA.

Der eigentliche Gewinn zeigt sich bei einem Dienst hinter einem Lastverteiler. Gegenseitige Authentifizierung verlangt, dass alle Instanzen denselben Sicherheitsprinzipal benutzen — mit einer gMSA ist das eine Identität, deren Kennwort Windows verwaltet, statt einer, die jemand auf allen Knoten synchron halten muss.

Die Grenze, die man kennen mussFailoverccluster unterstützen gMSAs laut Dokumentation nicht unmittelbar. Dienste, die auf dem Clusterdienst laufen, können eine gMSA oder sMSA trotzdem benutzen, sofern sie ein Windows-Dienst, ein Anwendungspool oder eine geplante Aufgabe sind oder verwaltete Konten nativ unterstützen. Diese Unterscheidung entscheidet in einem Clusterprojekt darüber, ob das Konzept trägt — und sie ist keine, die man erraten sollte.

Add-KdsRootKey: Legt den Stammschlüssel des Schlüsselverteilungsdienstes an. Einmal je Gesamtstruktur, vor der ersten gMSA.
New-ADServiceAccount -PrincipalsAllowedToRetrieveManagedPassword: Legt die gMSA an und benennt, welche Hosts das Kennwort abholen dürfen.
Install-ADServiceAccount: Installiert das Konto lokal auf einem berechtigten Host.
Test-ADServiceAccount: Prüft auf dem Host, ob das Konto dort tatsächlich benutzbar ist. Der Schritt vor dem Umstellen des Dienstes.

Was der Umstieg voraussetzt

Eine gMSA ist kein Konto, das man anlegt und einträgt. Sie setzt Vorbereitungen voraus, die vor dem ersten Dienst stehen müssen.

Ein Stammschlüssel für den Schlüsselverteilungsdienst muss im Verzeichnis existieren.
Am gMSA-Objekt muss stehen, welche Hosts das Kennwort abholen dürfen — üblicherweise über eine Gruppe.
Auf jedem dieser Hosts muss das Konto lokal installiert werden, bevor ein Dienst darunter startet.
Der Dienst wird danach ohne Kennwort eingetragen: Es gibt keines, das jemand kennen könnte.

Die häufigste FehlkonfigurationDie Liste der berechtigten Hosts bleibt offen oder wird auf eine breite Gruppe gesetzt — etwa alle Domänencomputer. Dann kann jeder Server der Domäne das Kennwort dieses Dienstkontos abholen, und aus einem verwalteten Konto wird ein Konto, dessen Geheimnis überall verfügbar ist. Der Vorteil gegenüber dem statischen Kennwort ist damit aufgebraucht; geblieben ist nur die automatische Rotation.

Der SPN: wie ein Client den Dienst findet

Service Principal Name (SPN) — Der Name, unter dem ein Dienst im Verzeichnis registriert ist — typischerweise in der Form Dienstklasse, Schrägstrich, Hostname. Ein Client, der sich mit Kerberos an einem Dienst anmelden will, fordert beim Domänencontroller ein Ticket für genau diesen Namen an.

Daraus folgt eine Regel, die keine Ausnahme kennt: Ein SPN muss eindeutig sein und an dem Konto hängen, unter dem der Dienst tatsächlich läuft. Läuft ein Dienst als Domänenkonto, gehört der SPN an dieses Konto — nicht an das Computerkonto, an dem er landet, wenn niemand etwas tut.

Ein Schalter, der prüftsetspn -S <SPN> <Konto> fügt einen SPN hinzu und prüft dabei laut Dokumentation, dass es keinen doppelten gibt. setspn -A tut dasselbe ohne diese Prüfung. Der Unterschied ist ein Buchstabe und der Grund dafür, dass Duplikate überhaupt entstehen. Wer -A in einem Skript oder Runbook findet, hat eine Ursache gefunden, bevor der Fehler eintritt.

setspn -L <Konto> — welche SPNs hängen an diesem Konto?
setspn -Q <Dienst>/<Host> — existiert dieser SPN bereits, und woran?
setspn -X — sucht doppelte SPNs in der gesamten Gesamtstruktur.
setspn -D <SPN> <Konto> — entfernt einen SPN von einem Konto.

Wenn ein SPN doppelt existiert

Ist derselbe SPN an zwei Konten registriert, kann der Domänencontroller nicht entscheiden, für welches er ein Ticket ausstellen soll. Die Kerberos-Authentifizierung an diesem Dienst scheitert.

Sichtbar machen lässt sich der Zustand mit setspn -X: Der Schalter durchsucht die Gesamtstruktur nach doppelt vergebenen Namen. Auf einer gewachsenen Umgebung liefert er oft mehr Treffer als erwartet — Reste von Diensten, die einmal umgezogen sind, und Konten, die längst niemand mehr benutzt. Nicht jeder Treffer ist ein akuter Fehler, aber jeder ist eine Störung, die auf ihren Anlass wartet.

Das Fehlerbild ist tückisch, weil es selten nach Kerberos aussieht. Viele Anwendungen fallen bei einem gescheiterten Kerberos-Versuch auf NTLM zurück — dann funktioniert die Anmeldung weiter, nur eben mit einem schwächeren Verfahren und ohne die Eigenschaften, die man von Kerberos erwartet hat. Der Doppelsprung aus dem nächsten Abschnitt funktioniert dann zum Beispiel nicht mehr.

Was das für die Diagnose heißt„Die Anmeldung funktioniert“ ist bei Kerberos-Fragen keine brauchbare Aussage. Die belastbare Frage lautet, womit sie funktioniert. Wo ein Rückfall auf NTLM stattgefunden hat, ist das Symptom nicht der Fehler, sondern seine Verdeckung — und der eigentliche Fehler wird erst dort sichtbar, wo NTLM nicht ausreicht.

Der Doppelsprung

Ein Webserver nimmt die Anmeldung eines Benutzers entgegen und muss danach in dessen Namen auf eine Datenbank zugreifen. Der erste Sprung ist die Anmeldung am Webserver, der zweite der Zugriff auf die Datenbank. Ohne weitere Konfiguration scheitert der zweite: Der Webserver hat kein Ticket, das er im Namen des Benutzers weiterreichen könnte.

Das Fehlerbild ist charakteristisch — auf dem Webserver angemeldet funktioniert der Datenbankzugriff, über den Browser desselben Benutzers nicht. Wer die Anwendung lokal testet, findet den Fehler nie, weil im lokalen Test kein zweiter Sprung stattfindet.

Kurzcheck

Eine Webanwendung greift lokal auf dem Webserver einwandfrei auf die SQL-Instanz zu, über den Browser eines Benutzers aber nicht. Woran liegt es am wahrscheinlichsten?

Der zweite Sprung braucht Delegierung, die nicht konfiguriert ist
Dem Benutzer fehlen Rechte auf der SQL-Instanz
Die SQL-Instanz erlaubt keine Kerberos-Anmeldung

Treffer. Richtig. Im lokalen Test gibt es nur einen Sprung. Erst über den Browser muss der Webserver im Namen des Benutzers weiterreichen — und das erfordert eine ausdrücklich konfigurierte Delegierung.

Delegierung — und wer sie konfigurieren darf

Delegierung ist die Erlaubnis für einen Dienst, im Namen eines Benutzers auf einen anderen Dienst zuzugreifen. Sie kommt in drei Ausprägungen, die sich in ihrer Reichweite dramatisch unterscheiden.

Unbeschränkt: Der Dienst darf im Namen des Benutzers auf alles zugreifen. Ein kompromittierter Server dieser Art ist ein Vollzugriff.
Eingeschränkt (klassisch): Auf eine benannte Liste von Zieldiensten begrenzt. Erfordert laut Doku Domänenadministrator-Rechte und beschränkt das Konto auf eine Domäne.
Ressourcenbasiert eingeschränkt: Die Konfiguration liegt am Zieldienst: Dessen Administrator legt fest, welche vorgelagerten Dienste in seinem Namen auftreten dürfen — auch domänenübergreifend.

Warum die dritte Form die bessere istBei der klassischen Form konfiguriert der Domänenadministrator am vorgelagerten Dienst, und der Betreiber des Zieldienstes erfährt davon nichts. Die Dokumentation benennt das als Problem: Jeder vorgelagerte Dienst, der delegieren darf, ist ein möglicher Angriffspunkt auf den Zieldienst. Die ressourcenbasierte Form dreht die Richtung um — wer den Zieldienst betreibt, entscheidet, wer auf ihn delegieren darf. Das ist nicht nur bequemer, es ist die Grenze an der richtigen Stelle.

Protected Users ist keine Härtung für Dienstkonten

Die Gruppe Protected Users schränkt für ihre Mitglieder mehrere schwache Verfahren ein. Sie taucht deshalb regelmäßig in Härtungsvorschlägen auf — und wird dabei auf Konten angewendet, für die sie nicht gedacht ist.

Mitglieder können sich nicht per NTLM authentifizieren.
DES und RC4 in der Kerberos-Vorauthentifizierung sind ausgeschlossen.
Mitglieder können nicht delegiert werden — weder unbeschränkt noch eingeschränkt.
Ticket-gewährende Tickets lassen sich nicht über die anfängliche Lebensdauer von vier Stunden hinaus erneuern.

Wörtlich in der DokumentationKonten für Dienste und Computer sollen keine Mitglieder der Gruppe Protected Users sein. Die Begründung steht daneben: Für solche Konten bietet die Mitgliedschaft keinen lokalen Schutz, weil Kennwort oder Zertifikat ohnehin immer auf dem Host verfügbar sind. Was bleibt, sind die Einschränkungen — ein Dienstkonto in dieser Gruppe verliert NTLM, verliert die Delegierbarkeit und bekommt ein Ticket, das nach vier Stunden nicht mehr erneuert wird. Aus einer Härtungsmaßnahme wird ein Ausfall, der einige Stunden nach der Änderung beginnt.

Drei Grenzen, nicht eine

Ob ein Dienstkonto tut, was es soll, hängt an drei voneinander unabhängigen Dingen. Ein Fehler in einem davon sieht in der Meldung meistens wie ein Fehler in einem anderen aus.

Berechtigung am Objekt: Was darf das Konto mit dieser Datei, diesem Schlüssel, dieser Freigabe? Steht in der Zugriffssteuerungsliste.
Anmelderecht: Darf sich das Konto überhaupt als Dienst anmelden (SeServiceLogonRight) oder als Batch-Auftrag? Steht in der Sicherheitsrichtlinie.
Netzidentität: Als wer tritt das Konto auf einem anderen Server auf? Entscheidet, ob es dort überhaupt jemanden gibt, dem man Rechte geben kann.

Die zweite Zeile ist die, die bei automatisierter Einrichtung am häufigsten fehlt, und die dritte die, die bei den eingebauten Konten überrascht. Bei einem eigenen Domänenkonto oder einer gMSA ist die Netzidentität eindeutig — das ist einer ihrer Hauptvorteile gegenüber LOCAL SERVICE, das im Netz anonym auftritt.

Nachprüfen lässt sich jede der drei Grenzen einzeln, und genau das ist der Wert der Aufteilung. Für die Berechtigung am Objekt zeigt icacls <Pfad> die Liste, für das Anmelderecht liefert secedit /export /areas USER_RIGHTS eine vergleichbare Datei, und für die Netzidentität beantwortet ein Blick auf StartName in Get-CimInstance Win32_Service die Frage, als wer der Dienst überhaupt auftritt. Drei Befehle, drei getrennte Antworten — statt einer Fehlermeldung, die alle drei Fälle gleich benennt.

Die Reihenfolge beim Einrichten

Aus den drei Grenzen ergibt sich eine Reihenfolge, in der jeder Schritt prüfbar ist, bevor der nächste darauf aufbaut.

Zweck bestimmen: ein Host oder mehrere, Netzzugriff nötig oder nicht.→Identität anlegen — sMSA, gMSA oder Domänenkonto — und bei einer gMSA festlegen, welche Hosts das Kennwort abholen dürfen.→Anmelderecht vergeben, ausdrücklich und nachprüfbar, nicht als Nebeneffekt eines Assistenten.→SPN setzen, mit dem prüfenden Schalter, am Konto des Dienstes.→Berechtigungen am Ziel vergeben — auf Freigabe, Datei, Schlüssel, Datenbank.→Erst danach den Dienst umstellen und über den Weg prüfen, den die Clients benutzen.

Schritt 6 heißt: nicht der Dienststatus, sondern eine echte Anfrage eines echten Clients. Alles davor beweist nur die eigene Schicht.

Was diese Sorgfalt kostetDer Weg über eine gMSA ist deutlich aufwendiger als ein Domänenkonto mit festem Kennwort, und er setzt voraus, dass jemand im Verzeichnis Rechte hat und die Vorbereitungen kennt. Für einen einzelnen internen Dienst ohne Netzzugriff ist er Überbau. Der Kipppunkt ist der zweite Server: Sobald dieselbe Identität an zwei Stellen gebraucht wird, ist das statische Kennwort die teurere Lösung — nur fällt die Rechnung erst bei der ersten Rotation an.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität14 Primärquellen · zuletzt geprüft: 2026-09-04