SharePoint Kerberos Authentifizierung konfigurieren

Heute möchte ich euch gerne zeigen, wie man eine SharePoint Authentifizierung mit Kerberos realisiert. Allerdings möchte ich hier keine grundsätzliche Diskussion führen, welche Vor- und Nachteile Kerberos im Vergleich zu NTLM hat. Dies würde an dieser Stelle zu weit führen und ich möchte mich auf die konkrete Realisierung in SharePoint konzentrieren. In letzter Zeit wird man immer häufiger mit der Kerberos Authentifizierung konfrontiert und man findet dazu sehr unterschiedliche und teilweise auch widersprüchliche Anleitungen im Netz. Deshalb möchte ich die Kerberos Authentifizierung an einem ganz konkreten Beispiel aus dem SharePoint Bereich erläutern. Dabei geht es hier „nur“ um die eigentliche SharePoint Kerberos Authentifizierung. Die für andere Szenarien (SQL Server Reporting Services, Excel Services, …) notwendige Delegierung wird in diesem Beitrag nicht erklärt, weil dies für die grundsätzliche Kerberos Authentifizierung nicht notwendig ist.

In unserem Beispiel haben wir folgendes Szenario:

Die SharePoint Kerberos Authentifizierung konfigurieren wir für die beiden SharePoint Webanwendungen. Diese sollen unter den URLs erreichbar sein, die ebenfalls in der Grafik dargestellt sind.

Zuerst müssen wir die beiden SharePoint Webanwendungen unter einer entsprechenden URL erreichbar machen. Dazu benötigen wir zwingend zwei A-Records im DNS. Diese sehen in unserem Beispiel so aus:

Danach müssen wir herausfinden, unter welchem Dienstkonten die beiden Anwendungspools der Webanwendungen laufen. Dies kann man z.B. auch über die Zentraladministration oder direkt im IIS Manager herausfinden:

Wie es den Best Practices entspricht (wenn man schon mehrere Webanwendungen hat 🙂 ), nutzen die beiden Webanwendungen ein eigenständiges Dienstkonto.

Um die notwendigen SPNs anlegen zu können, benötigen wir noch den Service Account der SQL Instanz, auf dem die Datenbanken der Webanwendungen liegen:

Nun haben wir alle Informationen zusammengetragen, um die notwendigen SPNs setzten zu können:

Um die SPNs setzten zu können, muss der ausführende Benutzer natürlich über entsprechende Rechte verfügen.

Bevor man SPNs hinzufügt, sollte man überprüfen, dass diese nicht bereits vorhanden sind. Dies geschieht über folgenden Befehl:

setspn -l domäne\benutzername

Danach müssen wir für den SQL-Zugriff folgende SPNs setzten (die SPNs sind am Anfang nicht zwingend erforderlich, werden aber für spätere Delegierungen benötigt):

setspn -s MSSQLSvc/sql:1433 svc-sql
setspn -s MSSQLSvc/sql.lanscotest.de:1433 svc-sql

Und noch die SPNs für die beiden SharePoint Webanwendungen:

setspn -s HTTP/sharepoint svc-spapppool
setspn -s HTTP/sharepoint.lanscotest.de svc-spapppool

setspn -s HTTP/mysite svc-spmyapppool
setspn -s HTTP/mysite.lanscotest.de svc-spmyapppool

Hierbei ist zu beachten, dass man immer auch den FQDN mit hinzufügt.

Danach können wir die SharePoint Kerberos Authentifizierung über die Zentraladministration aktivieren. Dazu nehmen wir die entsprechende Änderung bei der Authentifizierungsmethode bei den beiden Webanwendungen vor:

Wenn diese Änderung durchgeführt wurde, sollte man die korrekte Konfiguration auch noch einmal im IIS selbst prüfen:

Dabei ist zu beachten, dass die Reihenfolge der Provider stimmt. Also Negotiate an erster Stelle steht. Die Fehlermeldung oben rechts, dass die beiden Authentifizierungsmethoden nicht gleichzeitig genutzt werden können, kann man ignorieren.

Sind auch die Einstellungen im IIS korrekt, kann man die Funktionalität am Einfachsten über klist validieren:

Wenn man die SharePoint Webanwendung aufruft, sollte auch ein entsprechendes Kerberos Ticket erstellt worden sein. Mit klist purge löscht man alle vorhandenen Tickets, dann wird die Ausgabe übersichtlicher. klist reagiert ab und zu ein bisschen „seltsam“ und zeigt die Tickets nicht an. Dann hilft es im Normalfall, cmd nochmals zu starten bzw. explizit als Administrator auszuführen.

Und somit ist unsere initiale Konfiguration von Kerberos auch schon komplett. Noch eine letzte Anmerkung dazu: Der Claims to Windows Token Service ist für dieses Szenario nicht relevant und ist auf dem SharePoint Server auch deaktiviert. Diesen benötigt man nur für die Delegierung, die ich in einem späteren Beitrag behandeln werde.

In diesem Sinne,

Happy SharePointing… 🙂