SharePoint – Kerberos, NTLM und SPN

Eine über Kerberos (auch Aushandeln genannt) hat schon seine Vorteile. Man hat es beispielsweise etwas schwerer mit Angriffen auf das System. Anders gesagt: Man hat weniger Erfolge. Nur ist es gewissermaßen etwas aufwändiger einzurichten und zu pflegen. Einigen wird dies sicher noch gar nicht bewusst sein, aber ich werde es im Folgenden etwas genauer – trotzdem aber kurz und knapp – erläutern.

Kerberos ist die Standardmethode für eine Authentifizierung unter Windows-Systemen in einer Domäne mit und verwendet für die Authentifizierung verschlüsselte Tickets. Nach der Authentifizierung eines Benutzers in einer Domäne, wird vom KDC (Key Distribution Center – Schlüsselverteilungscenter) im Domänencontroller (DC) für den Benutzer ein Ticket (TGT – Ticket-Granting-Ticket) erstellt. Dies dient quasi als Quittung für den Benutzer und dessen erfolgreiche Authentifizierung. Dieses Ticket hat normalerweise eine Gültigkeitsdauer von zehn Stunden, was bedeutet, dass in dieser Zeit keine erneute Authentifizierung stattfinden muss.  Was das für bedeutet, folgt nun. Wenn Sie sich über Kerberos authentifiziert haben und nun auf eine -Webanwendung (nicht , sondern Kerberos!) zugreifen möchten, dann wird Ihr System sich an das KDC (im DC) wenden, dort sein Ticket vorlegen und dafür ein Dienstticket fordern. Dieses Dienstticket nutzt Ihr System nun, um sich mit dem Dienst (hier ) zu verbinden. Das Dienstticket gibt also Auskunft über die Identität des Clients und dessen Berechtigungsrollen.

Wie gerade – etwas grob und vereinfacht – dargestellt, liegt der Unterschied eben darin, dass NTLM sich bei jeder Authentifizierung an den DC wendet. Kerberos tut dies nur ein Mal, nämlich bei der ersten Anfrage vom Client und dann gibt es ja das gültige Dienstticket.

Es gibt übrigens auch ein nettes Kommandozeilentool namens Klist.exe, das nun in Windows 7 integriert ist. Hiermit lässt sich das Kerberosticket abrufen. Einfach mal testen:

  • KLIST purge – löscht alle Tickets im lokalen Speicher
  • SharePoint-Seite aufrufen
  • KLIST – zeigt das Ticket, wenn man eins bekommen hat 😉

Wer es genauer wissen möchte, der findet genügend Literatur zu dem Thema Authentifizierung.

Was ist ein und wozu braucht man ihn?

Für eine Authentifizierung nach Kerberos ist es wichtig, dass die Dienste von SharePoint, dessen Webanwendungen und der SQL-Server SPNs verwenden. Ein SPN ist ein Dienstprinzipalname oder auch Service Principal Name, der sich aus drei Teilen zusammensetzt.

Der für die Anfrage wichtige Teil ist die Dienstklasse HTTP, welche die beiden Protokolle HTTP und HTTPS enthält. Der zweite und dritte Teil ist Hostname und Port von der Webanwendung. Wenn der Port 80 genutzt wird, dann spielt an dieser Stelle der Port keine Rolle, da es der Standardport für HTTP ist und daher nicht extra mitgegeben werden muss. Diese drei Teile ergeben also den SPN.

Am Beispiel meiner SharePoint-Anwendung http://sps.demo.intern die auf dem Standardport 80 lauscht, wäre der SPN also HTTP/sps.demo.intern. Der Port 80 muss also nicht extra mitgegeben werden. Anders wäre es, wenn ich meine SharePoint-Anwendung mit einem Zertifikat gesichert hätte und dann folgende Adresse nutzen würde: https://sps.demo.intern. Hier ist der Port nicht mehr der Standardport 80, sondern der Port 443, womit sich dann folgender SPN ergäbe: HTTP/sps.demo.intern:443.

Diese SPNs müssen im Active Directory (AD) einem Sicherheitsprinzipal (Benutzer- oder Computerkonto) zugeordnet werden. In Sachen SharePoint bedeutet dies, dass das Anwendungspoolkonto solch ein SPN als Attributeintrag erhalten muss. Es können einem Konto natürlich auch mehrere SPNs zugewiesen werden.

Stellt der Client also jetzt – wie oben beschrieben – eine Ticketanforderung für einen Dienst an den DC bzw. an das KDC stellt, dann wird der angeforderte SPN überprüft.

Beispiel: Ich habe bspw. ein Anwendungspoolkonto Demo\SP_app_svc und weise diesem Konto die SPN HTTP/sps.demo.intern zu. Nun rufe ich meine SharePoint-Seite auf und das Spiel beginnt: Der Client wendet sich mit dem Anwendungspoolkonto Demo\SP_app_svc an den DC und dort an das KDC. Jetzt fordert er sein Dienstticket und das KDC überprüft daraufhin den angeforderten SPN. Wenn alles klar ist, wird der Sitzungsschlüssel für den Dienst erstellt und mit dem Password des SPN-Kontos verschlüsselt. Jetzt kann der Client sein Dienstticket dem Dienst vorlegen, der es dann entschlüsselt – er kennt ja sein eigenes Kennwort – und schon hat er den Sitzungsschlüssel. Fertig ist die Authentifizierung.

Nun aber zurück zum eigentlichen Thema!

SharePoint und Kerberos

Wer SharePoint mit Kerberos nutzen möchte, muss ein paar Dinge beachten. Bei der Installation und beim Einrichten der SharePoint-Webanwendung besteht die Möglichkeit zwischen NTLM, Kerberos und anderen Methoden zu unterscheiden. Wählt man hier Kerberos, so ist dies noch längst kein Garant dafür, dass der SharePoint auch Kerberos nutzt. Man kann ihn also nicht dazu zwingen. Vereinfacht gesagt: Passt etwas an der Konfiguration nicht zu Kerberos, so wird NTLM genutzt.
Fällt dem Anwender nicht auf und der Administrator sieht es nur, wenn er danach sucht.

Aber wie kann man es Kontrollieren?

  1. Auf Ihrem Webserver öffnen Sie die Sicherheitsereignisprotokollliste
  2. Dort finden Sie Ereignisse der Aufgabenkategorie Anmelden – bitte öffnen!
  3. Hier finden Sie den Typ des Anmeldeprozesses – NTLM oder Kerberos?
  4. Sollten Sie die SPNs nicht zugeordent haben, sollte trotzt der Einstellung Kerberos im SharePoint noch immer eine NTLM Authentifizierung stattfinden

Wie kann ich Kerberos nun konfigurieren?

  1. Auf Ihrem Domänencontroller (DC) öffnen Sie den ADSI-Editor
  2. Klicken Sie dann mit der rechten Maustaste auf ADSI-Editor und auf Verbindung herstellen, falls nötig
  3. Im Dialogfeld Verbindungseinstellungen klicken Sie einfach auf OK

  4. Erweitern Sie nun den Knoten Standardmäßiger Namenskontext, die Domäne und die anderen Knoten bis zum Konto (hier unser Anwendungspoolkonto)
  5. Wählen Sie Ihr Anwendungspoolkonto (Dienstkonto) – bei mir Demo\SP_app_svc – und wählen Sie über die rechte Maustaste Eigenschaften
  6. In der Attributliste suchen Sie nun das Attribut servicePrincipalName und öffnen dieses mit einem Doppelklick
  7. Tragen Sie hier Ihre SPNs ein! Es sollten für jede Webanwendung zwei sein, in der Form HTTP/site.domain.de und HTTP/site (FQDN und NetBIOS-Namen). Ein Konto kann also mehrere SPNs besitzen, jedoch darf ein SPN nur für ein Konto registriert sein!
  8. Starten Sie eine neue Anmeldung am SharePoint und kontrollieren Sie jetzt erneut über die Sicherheitsereignisprotokollliste auf dem Webserver, ob aus NTLM nun Kerberos geworden ist.

Hinweis: Sollten Sie von NTLM auf Kerberos umgestiegen sein und/oder bei einer früheren SharePoint-Anmeldung Ihr Passwort im Browser gespeichert haben, dann kann dies eine Kerberos-Anmeldung verhindern, was Ihnen bei der Prüfung in den Ereignisprotokollen vielleicht schon aufgefallen ist. Es kommt hierbei ganz darauf an, ob Sie Ihre SharePoint-Seite zur Zone Lokales Intranet hinzugefügt haben. Sollten Sie dies noch nicht getan haben, dann holen Sie es über folgenden Weg nach:

  1. Browser öffnen
  2. Menü ExtrasInternetoptionen
    (zum Einblenden der Menüzeile Taste ALT drücken, falls nötig)
  3. Reiter Sicherheit wählen
  4. Zone Lokales Intranet wählen und auf Button Sites klicken
  5. Klicken Sie auf den Button Erweitert und tragen Sie hier die Website von SharePoint ein, um sie der Zone hinzuzufügen
  6. Schließen und Bestätigen – Fertig!

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.