Single-Sign-On & SharePoint

Auch wenn in vielen Unternehmen der Internet-Explorer quasi Standard ist, so ist der Interner-Explorer schon lange nicht mehr die Voraussetzung dafür, dass man sich an SharePoint ohne weitere Anmeldung mit seinen Windows-Credentials anmelden kann. Eigentlich hat das nichts mit SharePoint direkt zu tun, sondern betrifft Web-Anwendungen im allgemeinen.

Um sich automatisch bei SharePoint anzumelden (ich bleibe mal bei SharePoint), muss auf der Server-Seite die Windows Integrierte Anmeldung verwendet werden. Dabei werden die Windows-Credentials vom Client an den Server gesendet und zur Authentifizierung verwendet. Früher beherrschte lediglich der Internet Explorer die Weitergabe von Credentials, das hat sich (schon vor längerer Zeit) geändert. In zwischen beherrschen auch Firefox, Chrome und Safari die Windows Integrierte Anmeldung.

Beim Firefox muss dazu angegeben werden, für welche Domänen Firefox Authentifizierungsinformationen weitergibt. Das entspricht quasi den Zonen-Einstellungen des Internet-Explorers. Dazu muss im Firefox zunächst mit about:config die erweiterten Einstellungen geöffnet werden. Anschließend kann man mit den beiden Einstellungen network.negotiate-auth.trusted-uris (für Kerberos Authentifizierung) und network.automatic-ntlm-auth.trusted-uris (für NTLM Authentifizierung) die Domänen angeben, für die die Authentifizierung erlaubt sein soll. Bei mehreren Domänen kann man die mit Komma trennen.

Chrome bedarf keinen weiteren Einstellungen, hier funktionieren NTLM und Kerberos direkt. Beim Safari funktioniert nur Kerberos, wenn man bereits über ein Kerberos-Ticket verfügt.

Damit steht also der großen Browser-Vielfalt nicht mehr im Wege.

Kerberos für SharePoint

… 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:

  1. Service-Principle für den/die Application-Pool Accounts einrichten
  2. Web-Anwendung in SharePoint auf Kerberos umstellen
  3. 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, …).

delegation_2

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.