… oder willkommen an den Toren der Unterwelt.
Irgendwann führt kein Weg mehr vorbei an Kerberos. Spätestens wenn man z.B. aus SharePoint auf Drittsysteme mit den Anmelde-Daten des aktuellen Benutzers zugreifen will, dann muss man sich dieser Aufgabe stellen.
Ich will hier nicht auf die Funktionsweise von Kerberos eingehen, und auch nicht auf die tieferen Hintergründe von SharePoint 2010 und Kerberos. Das kann man am besten in dem Handbuch für SharePoint 2010 Administratoren nachlesen und ansonsten hat Microsoft auch eine super Dokumentation für die Konfiguration von SharePoint 2010 und Kerberos geschrieben.
Hier also nur die Ergebnisse, um Kerberos und SharePoint 2010 (und 2013) zum zusammenspielen zu bewegen. Im Wesentlichen sind drei Schritte durchzuführen:
- Service-Principle für den/die Application-Pool Accounts einrichten
- Web-Anwendung in SharePoint auf Kerberos umstellen
- Service-Principle für den SQL-Dienst einrichten
Vielleicht die einzelnen Schritte etwas genauer.
Szenario: Ich habe in meiner SharePoint Umgebung eine Web-Application für ein Extranet mit einem entsprechenden Application SP_AP_Extranet, welcher das Konto demo-he\spAppPool_Extranet verwendet. Hier soll nun also Kerberos verwendet werden. Zudem habe ich noch einen SQL-Server (sp2010he) der mit dem Konto demo-he\spSQLService läuft.
Service-Principles für die Application Pools einrichten
Für jeden Application-Pool Account (der Web-Anwendung die mit Kerberos verwendet werden soll) muss ein Service-Principle registriert werden. Das geht mit dem setspn.exe, das seit Windows 2008 zum Standard gehört. Bei Versionen vor Windows 2008 ist das setspn.exe im Ressource-Kit vorhanden.
setspn.exe -S http/extranet demo-he\spAppPool_Extranet setspn.exe -S http/extranet.demo-he.local demo-he\spAppPool_Extranet
Der Schalter –S ist erst ab Windows 2008 verfügbar; bei früheren Versionen muss man –A verwenden, wobei dabei nicht geprüft wird ob der Service-Principle schon verwendet wird. Somit ist –S auf jeden Fall zu bevorzugen.
Anschließend muss man dem Konto spAppPool_Extranet noch für Delegierungszwecke vertrauen. Dazu kann man im Active Directory entweder dem Konto generell für Delegierungszwecke vertrauen (Basic Delegation) oder die Dienste einschränken, für die die Delegierung verwendet werden kann (Constrained Delegation). Für einige Dienste ist die Constrained Delegation notwendig (Excel-Services, Reporting-Services, …).
Das geht also offenbar von Hand – oder aber auch per Skript. Am einfachsten per PowerShell.
Get-ADUser spAppPool_Extranet | Set-ADObject -add @{"msDS-AllowedToDelegateTo"="http/extranet", "http/extranet.demo-he.local"}
Abschließend sollte der IIS einmal neu gestartet werden, damit der Application-Pool auch die neuen Einstellungen aus dem Active Directory berücksichtigt.
Service-Principle für die Datenbank einrichten
Für die Datenbank funktioniert die Einrichtung im Wesentlichen identisch wie bei der Application-Pools. Also hier auch erst den Service-Principle per setspn.exe einrichten, und dann dem Account noch für Delegierungszwecke vertrauen.
setspn.exe -S mssqlsvc/sp2010he demo-he\spSQLService
setspn.exe -S mssqlsvc/sp2010he.demo-he.local demo-he\spSQLService
Get-ADUser spSQLService | Set-ADObject -add @{"msDS-AllowedToDelegateTo"="mssqlsvc/sp2010he", "mssqlsvc/sp2010he.demo-he.local"}
Anschließend auch hier den SQL-Server Dienst und ggf. auch den IIS neu starten, damit die neuen Einstellungen wirksam werden.
Wenn bei der Konfiguration ein SQL-Alias verwendet wurde (das sollte ja immer der Fall sein), dann spielt das hier keine Rolle. Beim Service-Principle wird immer der im DNS eingetragene Server-Name verwendet, nicht das SQL-Alias.
Wird im SharePoint BCS verwendet, und soll hier auch mit Hilfe von Kerberos mit der Identität der Benutzers auf die Datenbank zugegriffen werden, dann ist noch ein weiterer Schritt notwendig. Dem Application-Pool Account muss auch ein Delegation-Constrained für die Datenbank zugewiesen werden.
Get-ADUser spAppPool_Extranet | Set-ADObject -add @{"msDS-AllowedToDelegateTo"="mssqlsvc/sp2010he", "mssqlsvc/sp2010he.demo-he.local"}
Zusammenfassung
Ich habe hier die gleiche Reihenfolge gewählt, wie sie idR. in der Literatur auch zu finden ist: erst SPN für den Application-Pool setzen, dann SPN für die Datenbank setzen und dann die einzelnen Dienste konfigurieren. Das ist aber eigentlich unpraktisch. Wenn man die Schritte genauso abarbeitet, dann muss man den IIS einmal nach der Einrichtung des SPN für den Application-Pool neu starten, und dann noch einmal nachdem man den SPN für den SQL-Server eingerichtet hat. Auch muss man erst die Constrained Delegation für den Application-Pool anpassen und dann nachdem man den Service-Principle für den SQL-Server eingestellt hat noch einmal (um die Delegation für den BCS zu ermöglichen). Da sind ja Arbeitsschritte doppelt.
Besser wäre also: erst alle SPNs registrieren, dann die Constrained Delegation für alle SPNs einrichten und zum Schluss alle Dienste neu starten.
Also Skript sich das ganze dann so aus:
Import-Module ActiveDirectory
Write-Host "Registering Service Principles"
setspn.exe -S http/extranet demo-he\spAppPool_Extranet
setspn.exe -S http/extranet.demo-he.local demo-he\spAppPool_Extranet
setspn.exe -S mssqlsvc/sp2010he demo-he\spSQLService
setspn.exe -S mssqlsvc/sp2010he.demo-he.local demo-he\spSQLService
Write-Host "Validating Service Principles"
setspn.exe -L demo-he\spAppPool_Extranet
setspn.exe -L demo-he\spSQLService
Write-Host "Adding constrained delegation"
Get-ADUser spAppPool_Extranet | Set-ADObject -add @{"msDS-AllowedToDelegateTo"="http/extranet", "http/extranet.demo-he.local"}
# for BCS add constrained delegation also to the sql-service
#Get-ADUser spAppPool_Extranet | Set-ADObject add @{"msDS-AllowedToDelegateTo"="http/extranet", "http/extranet.demo-he.local", "mssqlsvc/sp2010he", "mssqlsvc/sp2010he.demo-he.local"}
Get-ADUser spSQLService | Set-ADObject -add @{"msDS-AllowedToDelegateTo"="mssqlsvc/sp2010he", "mssqlsvc/sp2010he.demo-he.local"}
Write-Host "Restarting SQL-Service"
net.exe stop MSSQLSERVER
net.exe start MSSQLSERVER
Write-Host "Restarting IIS"
iisreset.exe /noforce
Das ganze führt man also am besten direkt aus der PowerShell aus, da hier dann die PowerShell Befehle zur Verfügung stehen und die Kommandozeilen-Befehle wie setspn.exe natürlich auch.