Wofür braucht es eigentlich diesen SPN?

Dieser Artikel erschien zuerst auf Ralfs Blog.

Der SPN, oder ausgeschrieben “Service Principal Name”, ist essentiell für Kerberos Authentifizierungen unter Windows notwendig. Die Profis mögen mir eine stellenweise drastische Vereinfachung in der kommenden Beschreibung verzeihen, mir geht es um das Verständnis…

Meldet sich ein Benutzer an einer Domäne an, dann bekommt er (wenn er sich erfolgreich authentifizieren konnte) vom Domain Controller ein sogenanntes TGT, ein “Ticket Granting Ticket”. Im realen Leben wäre das etwa vergleichbar mit dem Personalausweis (nach Vorlage einer Geburtsurkunde). Will der Benutzer jetzt auf eine Freigabe auf dem Server “file1″ zugreifen, so wendet er sich erneut vertrauensvoll an den DC und erbittet (unter Vorlage seines TGT) ein Session Ticket für den Dienst “CIFS” auf Server “file1″. Der DC durchsucht seine – jetzt kommt’s – Liste der SPNs nach etwas wie “cifs/file1″ oder “host/file1″. Diese Liste entsteht zum Beispiel bei Aufnahme von Servern in die Domäne und wird von den DCs gepflegt. Zu diesen SPNs gehören dann Schlüssel und weitere Attribute, die der DC verwendet, um dem anfragenden Client eine Zutrittsgenehmigung, ein Session Ticket, ausstellen zu können.

Findet der DC einen passenden SPN, dann gibt er dem Benutzer ein Ticket mit, das dieser dann wiederum beim “file1″ vorlegen kann. Klingt kompliziert, isses auch. Der Vorteil davon? Nun, der Benutzer kann sich ohne erneutes Passwort an “file1″ anmelden, und “file1″ weiß auch, dass alles korrekt ist, ohne ein Kennwort zu überprüfen oder beim DC nachfragen zu müssen. Im Vergleich zum realen Leben: Für meinen Firmenausweis musste ich meinen Personalausweis vorlegen (nicht meine Geburtsurkunde!). Mit dieser Firmenkarte komm ich in alle Bereiche, in die ich rein darf, und in die anderen eben nicht. Trotzdem muss der Pförtner bzw. die Türkontrolle nicht jedes Mal beim Einwohnermeldeamt nachfragen. Alles klar? Ok.

Was passiert, wenn der DC keinen SPN findet? Und wie kann es dazu kommen? Vielleicht mal mit der zweiten Frage angefangen: Das passiert zum Beispiel ganz häufig, wenn mit CNAMEs, also DNS-Aliasen, gearbeitet wird. Klassisches Beispiel: Der Server “file1″ ist gleichzeitig auch noch Webserver. Ein Benutzer öffnet seinen Internet Explorer und verbindet sich mit “http://file1/”. Wenn der Webserver auf “Integrierte Windows Authentifizierung” eingestellt ist, dann fordert der Client im Hintergrund für den Benutzer ein Servcie Ticket an für den Server “file1″ und den Dienst “http”. Der DC schaut in der Liste der SPNs und stellt das Session Ticket aus, der Client reicht es den “file1″, et voila, Zugriff klappt. Damit die URL etwas eingängiger wird, kommt jetzt jemand auf die Idee und vergibt einen CNAME für den “file1″, sagen wir mal “intranet”. Gleiches Spiel wie eben, Client beantragt ein Session Ticket, DC sucht nach “intranet” und “http” und findet – nichts! Netterweise (?) probiert Windows dann noch ein paar andere Authentifizierungsmöglichkeiten durch (je nach Einstellungen) und meistens klappt es dann trotzdem – aber Kerberos ist das nicht mehr.

Abhilfe? Klar. Man kann jederzeit weitere SPNs definieren und einem Host zuordnet. Der magische Befehl dazu heißt “setspn”. Hier ein paar Beispiele:

setspn -L file1   zeigt alle SPNs, die für den Server file1 registriert sind

setspn -L intranet   zeigt erst mal nichts

setspn -A host/intranet file1 registriert einen weiteren SPN für den Namen “intranet” auf den Host “file1″. Damit wird der DC im oben genannten Beispiel dann ein Session Ticket für “file1″ ausstellen und die Integrierte Windows Authentifizierung klappt.

setspn -?  zeigt übrigens alle Optionen

Wichtig in diesem Zusammenhang: auch noch einen SPN auf den FQDN, den vollständigen Namen, registrieren, und niemals vom System generierte SPNs überschreiben. Wenn der SPN da sein sollte und er ist es nicht, dann ist das ein Fehler, dessen Ursache man finden muss, ein Anlegen “von Hand” hilft nur bedingt.