SPN-Troubleshooting: Duplikate finden und beheben mit setspn

Es gibt diese eine Sorte Ticket im Helpdesk, die jeden Admin innerlich seufzen lässt: „Kerberos geht nicht mehr.“ Keine Fehlermeldung, die was hergibt, der Dienst läuft „irgendwie“, nur eben nicht so, wie er soll. In gefühlt jedem zweiten Fall steckt dieselbe Ursache dahinter – ein doppelter Service Principal Name. Zwei Konten beanspruchen denselben SPN, und der KDC wirft entnervt das Handtuch. Die gute Nachricht: Das lässt sich mit einem einzigen Bordmittel finden und reparieren. Das Werkzeug heißt setspn, ist seit Windows Server 2008 dabei und kann mehr, als die meisten ihm zutrauen.

Warum ein doppelter SPN den ganzen Spaß ruiniert

Ein SPN ist im Grunde ein Wegweiser. Wenn ein Client einen Dienst per Kerberos ansprechen will, fragt er den KDC: „Gib mir bitte ein Ticket für HTTP/app01.contoso.de.“ Der KDC schaut nach, welches Konto diesen SPN trägt, und verschlüsselt das Ticket mit dem Schlüssel genau dieses Kontos. Eindeutig, sauber, fertig.

Jetzt kommt der Salat: Trägt nicht ein Konto, sondern tragen zwei Konten denselben SPN, kann der KDC sich nicht entscheiden. Mit welchem Schlüssel soll er das Ticket denn nun verschlüsseln? Er macht – je nach Konstellation – entweder gar nichts mehr oder wählt das falsche Konto. Der Dienst empfängt ein Ticket, das er nicht entschlüsseln kann, und quittiert das mit einem KRB_AP_ERR_MODIFIED. Klingt nach Manipulation, ist aber nur Verwirrung.

Abbildung 1: Zwei Konten halten denselben SPN – der KDC kann das Ticket keinem eindeutigen Schlüssel zuordnen.

Duplikate aufspüren mit setspn -X

Bevor man irgendwas löscht, will man wissen, ob es überhaupt ein Duplikat gibt – und wenn ja, welche. Dafür gibt es genau einen Befehl, und der durchsucht die komplette Domäne:

Das Tool listet jeden SPN, der mehr als einmal vergeben ist, samt der betroffenen Konten. Läuft die Ausgabe leer durch, gibt es keine Duplikate – dann liegt das Kerberos-Problem woanders (DNS, Zeit, fehlender SPN). Kommt etwas zurück, haben Sie Ihren Schuldigen.

Wollen Sie gezielt einen bestimmten SPN prüfen – etwa weil Sie genau wissen, welcher Dienst zickt – fragen Sie ihn direkt ab:

Die Abfrage zeigt alle Konten, die diesen SPN halten. Bei einem sauberen System ist das genau eines. Sind es zwei, wissen Sie sofort, wer zu viel hat.

Abbildung 2: Der vierstufige Workflow – suchen, zuordnen, falschen Eintrag entfernen, gegenprüfen.

Die wichtigsten setspn-Schalter im Überblick

Den richtigen Schuldigen löschen – nicht den falschen

Jetzt der heikle Teil. Sie haben zwei Konten, beide halten HTTP/app01.contoso.de. Eines davon ist legitim, das andere eine Altlast. Löschen Sie das falsche, läuft alles. Löschen Sie das richtige, steht der Dienst. Die Entscheidung ist simpler, als sie aussieht: Der SPN gehört an das Konto, unter dem der Dienst tatsächlich läuft.

Abbildung 3: Entscheidungshilfe – wohin der SPN gehört und welches Konto ihn abgeben muss.

Angenommen, der Dienst läuft unter dem Dienstkonto svc-app, aber der SPN klebt zusätzlich noch am Computer-Konto APP01$ (klassische Altlast). Dann entfernen Sie ihn vom Computer-Konto:

Läuft der Dienst dagegen als SYSTEM oder NetworkService – also unter der Maschinen-Identität – und jemand hat versehentlich zusätzlich ein Dienstkonto befüllt, drehen Sie es um:

Gegenprüfen – und es das nächste Mal gar nicht erst passieren lassen

Nach dem Löschen wiederholen Sie die Suche. Kommt setspn -X jetzt sauber durch und hält nur noch das richtige Konto den SPN, sind Sie fertig:

Auf dem Client lohnt zusätzlich ein klist purge, damit alte, kaputte Tickets aus dem Cache fliegen. Beim nächsten Zugriff holt sich der Client ein frisches Ticket – und das passt jetzt.

Damit Sie nicht in einem halben Jahr wieder hier landen: Gewöhnen Sie sich an, SPNs ausschließlich mit -S zu setzen, dokumentieren Sie pro Dienst, unter welchem Konto er läuft, und räumen Sie bei jeder Dienstkonto-Migration den alten SPN sofort weg. Drei kleine Disziplinen, die Ihnen viele graue Haare sparen.

Häufige Fragen

Brauche ich Domänen-Admin-Rechte, um setspn zu nutzen?

Zum Lesen (-Q, -L, -X) reichen normale Benutzerrechte – jeder authentifizierte Nutzer darf SPNs abfragen. Zum Schreiben (-A, -S, -D) brauchen Sie Schreibrechte auf das jeweilige Konto. Bei Computer-Konten ist das in der Praxis meist Domänen-Admin oder eine entsprechend delegierte Rolle, bei Dienstkonten reicht oft Schreibrecht auf das eine Objekt.

Wie lange dauert es, bis ein geänderter SPN wirkt?

Die Änderung am AD-Objekt ist sofort da, muss aber erst auf alle Domänencontroller replizieren – je nach Topologie Minuten bis zur nächsten Replikation. Auf dem Client hält sich obendrein das alte Ticket im Cache, bis es abläuft. Mit klist purge erzwingen Sie den Neubezug sofort. Faustregel: Änderung machen, kurz auf Replikation warten, Client-Cache leeren, testen.

Kann ich Duplikate auch mit PowerShell finden?

Ja. Über Get-ADObject mit einem Filter auf servicePrincipalName lassen sich SPNs domänenweit auswerten und mit Group-Object auf Mehrfachvergabe prüfen. Für die schnelle Diagnose am Server ist setspn -X aber unschlagbar bequem – ein Befehl, fertig. PowerShell spielt seine Stärke aus, wenn Sie das regelmäßig automatisiert überwachen wollen.

Der SPN ist eindeutig, trotzdem läuft nur NTLM. Woran liegt das?

Dann ist das Duplikat nicht Ihr Problem. Häufige andere Ursachen: Der Client spricht den Dienst per IP-Adresse statt per Namen an, ein CNAME verbiegt den erwarteten SPN, die Uhren laufen mehr als fünf Minuten auseinander, oder der SPN existiert schlicht gar nicht. Prüfen Sie mit klist am Client, ob überhaupt ein passendes Service-Ticket gezogen wird.

Was bedeutet das große S bei setspn -S genau?

Das -S macht vor dem Hinzufügen eine Duplikatsprüfung über die gesamte Gesamtstruktur. Existiert der SPN bereits irgendwo, bricht der Befehl mit einer Warnung ab, statt ein Duplikat anzulegen. Es ist die defensive Variante von -A und sollte Ihr Standard sein. Es gibt praktisch keinen guten Grund, -A noch bewusst zu verwenden.