SPNs richtig setzen: setspn ohne Kollateralschaden

Es gibt zwei Arten von Kerberos-Problemen. Die erste Art brüllt: Anmeldung schlägt fehl, Fehlermeldung im Log, Ticket im Helpdesk. Die zweite Art flüstert: Alles funktioniert weiterhin, nur eben mit NTLM. Die zweite Art ist die gefährlichere, weil niemand sie bemerkt – bis Microsoft irgendwann den Stecker zieht.

Genau an dieser Stelle wohnt der Service Principal Name. Ein SPN ist nichts anderes als ein Namensschild, das Kerberos braucht, um zu wissen, welches Konto das Ticket entschlüsseln darf. Fehlt das Schild, findet das KDC den Dienst nicht. Ist das Schild doppelt vergeben, wird die Authentifizierung zum Münzwurf. Und weil setspn.exe seit Jahrzehnten unverändert charmant-brutal arbeitet, kann ein einziger falscher Schalter eine ganze SQL-Farm lahmlegen.

Dieser Praxisartikel gehört zur Serie Microsoft Kerberos (Pillar-Seite: /microsoft-kerberos) und behandelt den unspektakulären, aber alltäglichen Teil: Wie man einen Service Principal Name mit setspn korrekt registriert, warum man -S statt -A nutzt, wie man doppelte SPNs findet und auflöst, und auf welches Konto der SPN eigentlich gehört. Inklusive der Anekdote, die jeder Consultant kennt: „Es funktioniert nur auf dem Server selbst.“ Das ist kein Netzwerkproblem. Das ist ein fehlender SPN, der sich als Netzwerkproblem verkleidet hat.

Was ein SPN ist und warum Kerberos ohne ihn zu NTLM kriecht

Ein SPN ist ein Attribut (servicePrincipalName) an einem AD-Objekt. Er hat maximal drei Teile: Dienstklasse, Hostname, optional Port oder Instanzname. HTTP/portal.contoso.com. MSSQLSvc/sql01.contoso.com:1433. HOST/fs01. Mehr ist es nicht. Kein Zauber, kein Zertifikat, keine Policy. Ein String an einem Konto.

Der Ablauf: Der Client will auf einen Dienst zugreifen, baut aus dem Verbindungsnamen einen SPN zusammen und fragt beim KDC ein Service-Ticket für genau diesen SPN an. Das KDC durchsucht das Verzeichnis, findet das Konto mit diesem SPN und verschlüsselt das Ticket mit dem Schlüssel dieses Kontos. Der Dienst entschlüsselt es und weiß: Der Anrufer ist echt.

Fällt einer dieser Schritte aus, gibt es keinen Kerberos-Fehler im klassischen Sinn, sondern einen stillen Rückfall. Die Fehler KDC_ERR_S_PRINCIPAL_UNKNOWN und KDC_ERR_PRINCIPAL_NOT_UNIQUE bedeuten, dass der Client Zugriff auf einen Dienst verlangt, den Kerberos nicht identifizieren kann. Der SSPI-Aushandlungsmechanismus zuckt mit den Schultern und nimmt NTLM. Der Benutzer merkt nichts. Der Auditor auch nicht, jedenfalls nicht sofort.

KDC_ERR_S_PRINCIPAL_UNKNOWN heißt konkret: Das KDC findet den angeforderten Service Principal nicht, das Service-Ticket wird nicht ausgestellt, weil der SPN keinem Konto zugeordnet werden kann. Das ist keine Kleinigkeit mehr, sondern ein Ablaufdatum. NTLM springt typischerweise genau dann ein, wenn Kerberos nicht verfügbar ist – keine Sichtverbindung zum Domain Controller, ein lokales Konto oder eine Anwendung, die es direkt anfordert.

Der Plan ist bewusst gestaffelt: Auditing ist bereits verfügbar, IAKerb und Local KDC sind für die zweite Jahreshälfte 2026 vorgesehen, und ein späteres großes Windows-Release blockiert Netzwerk-NTLM per Voreinstellung. Typische Randfälle wie unbekannte SPNs, IP-basierte Authentifizierung und lokale Konten sollen dabei über die neuen Fähigkeiten aus Phase 2 abgedeckt werden.

Der Klassiker aus dem Consulting: „Funktioniert nur auf dem Server selbst“

Ein Kunde, eine interne Webanwendung, integrierte Windows-Authentifizierung. Der Entwickler öffnet die Seite per RDP direkt auf dem Webserver: läuft. Jeder Client im Netz: Anmeldefenster, drei Versuche, 401. Der Verdacht fiel natürlich auf die Firewall, dann auf den Proxy, dann auf einen Kollegen, der Urlaub hatte.

Die Ursache war banal. Der Anwendungspool war von Netzwerkdienst auf ein Domänenkonto umgestellt worden, ein SPN wurde nie registriert. Lokal spielt das keine Rolle, weil der Loopback-Zugriff keine Kerberos-Aushandlung über das KDC braucht und ohnehin auf NTLM landet. Von außen sucht der Client den SPN HTTP/portal.contoso.com, das KDC findet nichts, NTLM übernimmt – und weil die Anwendung Kerberos-Delegierung zur Datenbank brauchte, war Schluss. Fünf Minuten Diagnose mit klist und setspn -Q. Zwei Wochen Ticketlaufzeit vorher.

setspn -S statt -A: der Schalter, der Ausfälle verhindert

setspn.exe ist auf jedem Windows-Server mit RSAT-AD-Tools verfügbar und tut genau, was man ihm sagt. Das ist das Problem. Der alte Schalter -A registriert einen SPN, ohne zu prüfen, ob er woanders schon existiert. Der neuere Schalter -S macht dasselbe, prüft aber vorher auf Duplikate im Forest und bricht ab, wenn es einen Treffer gibt.

Die drei Grundregeln lauten entsprechend: denselben SPN nicht auf mehreren Konten registrieren, kein setspn -A verwenden, wenn setspn -S auf Duplikate prüfen kann, und nicht annehmen, dass funktionierende DNS-Auflösung bereits eine konfigurierte Kerberos-Identität bedeutet.

Praktisch heißt das: Erst lesen, dann schreiben. setspn -L CONTOSO\svc-sql zeigt alle SPNs eines Kontos. setspn -Q MSSQLSvc/sql01.contoso.com:1433 fragt einen konkreten SPN ab und nennt das Konto, dem er gehört. Erst wenn beides das erwartete Ergebnis liefert, setzt man mit setspn -S nach. Und immer alle Namensformen, die Clients tatsächlich verwenden.

Wenn Anwendungen beide Namensformen nutzen dürfen, müssen beide am korrekten Konto abgefragt und registriert werden, jeweils mit setspn -S, und beim Troubleshooting explizit getestet werden. Ein sauberes Ergebnis sieht langweilig aus: Dasselbe beabsichtigte Dienstkonto besitzt jede unterstützte Namensform. Unsauber wird es, wenn Benutzer zehn verschiedene Kurznamen verwenden, nur zwei davon SPNs haben, und der Helpdesk je nach angeklicktem Link unterschiedliches Verhalten sieht.

Doppelte SPNs finden und auflösen

Ein Duplikat ist die unangenehmste Variante, weil sie nicht konsistent scheitert. Das KDC kann den Namen nicht eindeutig auflösen, oder es stellt ein Ticket für das falsche Konto aus – dann entschlüsselt der Dienst es nicht und meldet eine manipulierte Nachricht.

Typische Signale sind KDC_ERR_PRINCIPAL_NOT_UNIQUE mit Hinweis auf mehrere Einträge, KRB_AP_ERR_MODIFIED sowie Event ID 11 oder Event ID 4 auf Domain Controllern; Ursache ist fast immer eine fehlerhafte SPN-Konfiguration.

Suchen, ohne den DC zu quälen

Duplikate findet man mit setspn -x, was den gesamten Forest durchsucht und in großen Umgebungen dauern kann; setspn q fragt nach einem konkreten SPN-Namen und ist für große Umgebungen oft die bessere Wahl. Die Suche nach Duplikaten, insbesondere forestweit, kann lange dauern und viel Speicher benötigen. Übersetzt: setspn -X gehört ins Wartungsfenster, nicht in die Mittagsspitze. Für den Alltag reicht die gezielte Abfrage.

Diese Abfrage liefert übrigens mehr als nur ein Ja oder Nein. Sie nennt das Konto, das den SPN beansprucht – und das ist meistens schon die halbe Lösung. Ein reales Beispiel: setspn -Q HOST/testcomputer.example.com meldete zwei Objekte, testcomputer1 und testcomputer, mit dem Hinweis auf einen existierenden SPN; testcomputer1 beanspruchte den SPN fälschlicherweise und war die Fehlerquelle.

Auflösen in der richtigen Reihenfolge

Zuerst entscheiden, welches Konto der legitime Besitzer ist. Das ist eine fachliche Frage, nicht eine technische: Unter welcher Identität läuft der Dienst wirklich? Dann den SPN vom falschen Konto entfernen (setspn -D), erst danach am richtigen registrieren (setspn -S). Nicht umgekehrt, sonst hat man kurzzeitig ein Duplikat. Anschließend Tickets auf dem Testclient verwerfen (klist purge) und neu anfordern. Wenn zwei oder mehr Konten denselben SPN tragen, müssen die SPNs entfernt werden, die nicht zum aktuellen Dienstkonto gehören.

Das richtige Konto: Dienstkonto oder Maschinenkonto

Der häufigste Denkfehler: Der SPN gehört zum Server. Falsch. Der SPN gehört zu der Identität, unter der der Dienstprozess läuft. Läuft der Dienst als LocalSystem oder Netzwerkdienst, ist das das Computerkonto. Läuft er unter einem Domänenkonto, gehört der SPN dorthin. Punkt.

Für Standarddienste muss man ohnehin nichts tun. Für die Dienste, die das HOST-SPN des Computerkontos nutzen können, gibt es eine Liste in der setspn-Dokumentation; nur wenn der eigene Dienst nicht dazugehört, muss ein SPN am Computerkonto konfiguriert werden. Wer HOST-SPNs von Hand editiert, hat meist ein anderes Problem, das er gerade verschlimmert.

Sicherheitsseitig ist die Kontowahl kein Detail. Standardmäßig haben nur Computerkonten SPNs, was kaum Risiko bedeutet: Maschinenkonten rotieren ihr Kennwort per Default alle 30 Tage, es besteht aus 120 zufälligen Zeichen und ist damit gegen Kerberoasting praktisch immun. Ein Benutzerkonto mit SPN gilt dagegen als Dienstkonto und ist für die ganze Domäne sichtbar – jeder Benutzer kann ein Service-Ticket anfordern, das mit dem Schlüssel dieses Kontos verschlüsselt wird, und ein menschlich gewähltes Kennwort ist meist schwächer.

Genau darauf basiert Kerberoasting: Jeder authentifizierte Domänenbenutzer kann Service-Tickets für Konten mit SPN anfordern, diese Tickets sind mit dem Kennworthash des Dienstkontos verschlüsselt, und der Angreifer knackt sie offline. Wo SPNs an Benutzerkonten unvermeidbar sind, bietet Microsoft Group Managed Service Accounts an, die starke Kennwörter automatisch und regelmäßig wechseln.

Kontotypen im Vergleich, Klartext ohne Marketing:

Computerkonto (HOST-SPNs) . . . automatische Kennwortrotation, kein manueller SPN nötig, ideal für SMB, WinRM, RDP Klassisches Dienstkonto . . . . manuelle Kennwortpflege, SPN manuell, primäres Kerberoasting-Ziel gMSA . . . . . . . . . . . . . . . automatische Rotation, mehrere Hosts, SPN teils manuell nötig dMSA (Server 2025) . . . . . . . maschinengebundene Schlüssel, Altkonto wird deaktiviert

Auch bei gMSA-Konten gilt: Manche Kerberos-fähigen Anwendungen benötigen weiterhin eine SPN-Registrierung, prüfen lässt sich das mit Get-ADServiceAccount und dem Attribut ServicePrincipalNames. Mit Windows Server 2025 kommt der delegated Managed Service Account hinzu: Er erlaubt den Übergang von traditionellen Dienstkonten zu Maschinenkonten mit verwalteten, vollständig randomisierten Schlüsseln, deaktiviert die alten Dienstkontokennwörter, bindet die Authentifizierung an die Geräteidentität und verhindert so das übliche Abgreifen von Anmeldedaten.

Angreifer nutzen übersehene SPN-Fehlkonfigurationen zunehmend für unauffälligeres Kerberoasting; die von Trellix als „Ghost SPN“ bezeichnete Technik erlaubt es, mit delegierten Verzeichnisrechten einem Standardkonto temporär einen SPN zuzuweisen, ein Ticket anzufordern und die Konfigurationsänderung vor der Entdeckung wieder zu entfernen.

Betriebsprozess: SPNs pflegen, statt sie zu reparieren

Technisch ist alles oben Beschriebene trivial. Der Grund, warum SPN-Probleme trotzdem chronisch sind, ist organisatorisch: Niemand ist zuständig. Der Anwendungsverantwortliche ändert das Dienstkonto, der AD-Betrieb erfährt es nicht, der SPN bleibt am alten Objekt liegen. Sechs Monate später wird das alte Konto gelöscht, und mit ihm verschwindet der SPN – oder eben nicht, und das Duplikat bleibt als Zeitbombe im Verzeichnis.

Ein funktionierender Prozess braucht drei Dinge. Erstens: eine Inventarliste. Welcher Dienst nutzt welchen SPN an welchem Konto? Das kann eine PowerShell-Abfrage in ein CSV sein, gern wöchentlich. Zweitens: eine Regel, dass jede Änderung des Dienstkontos automatisch eine SPN-Prüfung auslöst. Drittens: Monitoring auf die relevanten Ereignisse, statt auf Beschwerden zu warten.

Und dann die Baustelle, die niemand gern anfasst: die Verschlüsselungstypen. RC4 verschwindet parallel zu NTLM, und Kerberoasting-Erkennung setzt genau dort an. Eine gängige Detektionslogik erkennt potenzielle Kerberoasting-Angriffe daran, dass Service-Ticket-Anfragen mit RC4-Verschlüsselung über Event ID 4769 auftreten. Wenn im eigenen Netz noch massenhaft RC4-Tickets für Dienstkonten angefordert werden, sind das entweder Altlasten oder ein Angriff. Beides sollte man wissen wollen.

Für die NTLM-Abschaltung heißt das konkret: Erst Sichtbarkeit, dann Migration. Microsoft empfiehlt in der Zwischenzeit, das erweiterte Auditing sofort auszurollen und die Abhängigkeiten von Anwendungen und Diensten zu erfassen. Dazu gehört, Abhängigkeiten über Anwendungen und Dienste hinweg zu kartieren, bei kritischen Systemen die Hersteller auf Kerberos-Unterstützung anzusprechen und Konfigurationen ohne NTLM zuerst außerhalb der Produktion zu testen.

Wer diese Arbeit in eine Blockwoche schiebt, wird sie später in Störungsmeldungen bezahlen. Mit Zinsen.

FAQ

Woran erkenne ich, dass ein Dienst heimlich NTLM statt Kerberos nutzt?

Auf dem Client mit klist prüfen, ob ein Service-Ticket für den erwarteten SPN im Cache liegt. Fehlt es, obwohl die Anwendung läuft, war es NTLM. Serverseitig zeigen die Anmeldeereignisse das Authentifizierungspaket. Für die systematische Auswertung stehen die erweiterten NTLM-Auditing-Funktionen von Windows Server 2025 und Windows 11 ab Version 24H2 bereit, um zu verstehen, wo und warum das Protokoll noch genutzt wird.

Muss ich SPNs für Aliase und Loadbalancer-Namen extra registrieren?

Ja. Kerberos kennt keine DNS-Alias-Auflösung im Sinne von „ist doch derselbe Server“. Der Client bildet den SPN aus dem Namen, den er verbindet. Jeder CNAME, jeder VIP-Name, jeder Kurzname, den Benutzer tatsächlich eintippen, braucht einen eigenen SPN am korrekten Konto. Deshalb ist Namensdisziplin die günstigste Kerberos-Härtung, die es gibt.

Kann ich setspn -X einfach in der Produktion laufen lassen?

Technisch ja, taktisch nein. Die forestweite Duplikatssuche kann in großen Verzeichnissen erheblich Zeit und Speicher kosten. Für den Alltag ist die gezielte Abfrage mit -Q die richtige Wahl, die Vollsuche gehört ins Wartungsfenster oder auf einen Read-Only-DC beziehungsweise einen dedizierten Abfrage-DC.

<<H3_START)>>Was ist mit PowerShell statt setspn.exe?<<H3_ENDE>>

Funktioniert und ist für Automatisierung besser: Get-ADUser oder Get-ADComputer mit dem Attribut ServicePrincipalNames zum Lesen, Set-ADUser mit Add- beziehungsweise Remove-Operation zum Schreiben. Nur: PowerShell prüft nicht automatisch auf Duplikate. Diese Prüfung muss man im Skript selbst implementieren, sonst hat man die Nachteile von setspn -A in modernem Gewand.

Löst gMSA oder dMSA das SPN-Problem komplett?

Nein, es löst das Kennwortproblem. SPNs müssen bei Kerberos-fähigen Anwendungen weiterhin korrekt registriert werden. Der Nutzen liegt woanders: dMSA verhindert das Abgreifen von Anmeldedaten über ein kompromittiertes Konto, also Kerberoasting, das bei traditionellen Dienstkonten ein verbreitetes Problem ist.

Fazit

Ein Service Principal Name ist ein String. Der Schaden, den ein falsch gesetzter String anrichtet, ist erstaunlich groß: stille NTLM-Rückfälle, gebrochene Delegierung, Authentifizierung nach Zufallsprinzip. Die gute Nachricht: Die Disziplin, die es braucht, ist minimal. Lesen mit -L und -Q, prüfen mit -X im Wartungsfenster, schreiben ausschließlich mit -S, löschen vor dem Neusetzen, testen niemals vom Server selbst. Wer das befolgt, hat den größten Teil aller Kerberos-Tickets im Betrieb bereits eliminiert.

Der zweite Teil ist die Kontowahl. Der SPN gehört an die Identität, unter der der Dienst läuft – Maschinenkonto bei Systemdiensten, Dienstkonto bei allem anderen, und dort möglichst als gMSA oder dMSA statt als Benutzerkonto mit Kennwort von 2017. Das ist zugleich Betriebshygiene und Angriffsflächenreduktion.

Und weil NTLM absehbar per Default abgeschaltet wird, ist SPN-Pflege kein Nice-to-have mehr, sondern Vorbereitung auf einen Stichtag. Mehr Hintergrund zu Tickets, Delegierung und Härtung auf der Pillar-Seite der Serie: /microsoft-kerberos