Vor Längerer Zeit habe ich diesen Beitrag im PTS Group Blog veröffentlicht. Passend zu meinem Vortrag morgen, möchte ich diesen Artikel nun auch in meinem Blog veröffentlichen.
In einem früheren Beitrag wurde im PTS Blog bereits über die Installation eines SharePoint 2010 Foundation Servers berichtet. Wer sich für für einen SharePoint 2010 Enterprise Server entscheidet, tut dies meistens um einen oder mehrere der zahlreichen dort enthaltenen Dienste zu nutzen. Wird die Installation etwas größer und eine Trennung der Dienste erforderlich, kann dem Administrator bei der Konfiguration der Sicherheit doch schon mal schnell der Kopf rauchen, denn Kerberos hat es in sich.
Das Szenario
Im Folgenden beschreibe ich wie die Netzwerksicherheit mit Kerberos in einer Umgebung einzurichten ist, in der folgende Server und Dienste existieren:
Server 1: SQL Server
- Datenbankdienste mit SQL Server Agent
- Analysis Services mit SQL Server Browser Dienst
Server 2: SharePoint Server
- Reporting Services im SharePoint integrierten Modus
- SharePoint 2010 Server
- Performance Point Services aktiviert
- Excel Services aktiviert
Wird entweder der SharePoint Server oder der SQL Server - oder gar Beides – nicht richtig für die Verteilung konfiguriert, wird die Verbindung zwischen den Systemen nicht immer einwandfrei funktionieren. Im “normalen” SharePoint Alltag, d.h. dem Umgang mit Listen, Verwalten von Dateien, Listeneinträgen, etc. fällt dies zunächst nicht auf. Wird jedoch eine Datenquelle in Reporting Services angelegt und versucht auf den SQL Server zuzugreifen, erhält man diese Meldung:
rsErrorOpeningConnection: An existing connection was forcibly closed by the remote host.
Hat man im SharePoint sogar schon eine Webpart Seite angelegt und versucht dort den Bericht aufzurufen gibt es die gleiche Meldung, direkt von ASP.Net (links) oder anders von Performance Point (rechts).
Schuld daran sind jedoch nicht fehlende Berechtigungen des Benutzers auf die Datenbank, oder eine Fehlende Netzwerkverbindung, sondern die Authentifizierung im Netzwerk. Damit diese auch mitmacht muss Kerberos konfiguriert werden.
Über Kerberos
Kerberos ist ein Authentifizierungsprotokoll, dass es erlaubt sich im Windows-Netzwerk über mehrere Server hinweg an Diensten zu authentifizieren – und das auch noch vollkommen sicher. Damit dies korrekt funktioniert, muss Ordnung im Netzwerk herrschen, denn standardmäßig vertrauen sich Server nicht gegenseitig und verweigern die Kommunikation wenn es um Kerberos geht. Um dies zu ändern, muss im Active Directory für jeden Server und jedes Dienstkonto ein Secure Principal Name (SPN) hinterlegt werden, und dann wiederrum ist es möglich einzustellen wem dieser Dienst vertraut (bzw. an wen er Kerberos delegieren darf).
Das klingt ja erst mal gar nicht so schwer, oder?
In der Praxis steckt der Teufel bei Kerberos im Detail, denn der kleinste Fehler führt dazu, dass nichts funktioniert.
Ebenso führt die Verwendung von Kerberos eine Beschränkung ein: Je Hostname darf künftig nur noch ein Dienst verwendet werden. D.h. laufen auf Ihrem SharePoint Server z.B. Reporting Services im integrierten Modus und der SharePoint Dienst, erreicht der Nutzer beides über die Webadresse der SiteCollection. Wenn jetzt aber beide Dienste verschiedene Dienstkonten haben, müssten beide Dienstkonsten auf die Adresse der SiteCollection einen SPN haben – und das geht leider nicht.
Schauen wir uns einfach mal, wie Kerberos im oben genannten Szenario für Reporting Services konfiguriert werden muss
Kerberos Konfiguration: Datenbankserver
Als erstes müssen die Dienste für ihren SQL Server SPNs bekommen. Dazu müssen Sie wissen, unter welchem Dienstkonto die Dienste laufen. Unter welchem Benutzer die Dienste laufen verrät einem der SQL Server Configuration Manager, wie hier:
Wichtig: Für den Zugriff über Kerberos darf der SQL Server nicht unter dem lokalen Systemkonto oder dem Netzwerkdienst laufen. Es muss schon ein Active Directory Benutzerkonto sein.
Angenommen, sowohl der Datenbankdienst, als auch Analysis Services, laufen unter einem Dienstkonto mit dem Namen sqlsrv, können Sie wie folgt feststellen, ob das Dienstkonto bereits über SPNs verfügt:
- Über die Eingabe des folgenden Befehls in die Konsole:
setspn –l DOMAIN\sqlsrv - Aufrufen des in der Verwaltungskonsole für Benutzer und Computer und prüfen, ob das Tab Delegierung vorhanden ist
Ist alles bereits richtig konfiguriert, müssten folgende SPNs für dem Benutzer sqlsrv hinterlegt sein, unter der Annahme, dass der Server MeinSQLServer heißt und in der Domäne dev.local Mitglied ist:
MSSQLSvc/MeinSQLServer:1433
MSSQLSvc/MeinSQLServer.dev.local:1433
MSOLAPDisco.3/MeinSQLServer
MSOLAPSvc.3/MeinSQLServer.dev.local
MSOLAPSvc.3/MeinSQLServer
MSOLAPDisco.3/MeinSQLServer.dev.local
MSOLAPSvc.3/MeinSQLServer.dev.local:1433
MSOLAPSvc.3/MeinSQLServer:1433
Fehlen diese Werte, lassens ich diese über den Kommandozeilenbefehl SetSPN –U –A setzen, also:
setspn –U –a MSSQLSvc/MeinSQLServer:1433 DEV\sqlsrv
setspn –U –a MSSQLSvc/MeinSQLServer.domain.local:1433 DEV\sqlsrv
setspn –U –a MSOLAPDisco.3/MeinSQLServer DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer.domain.local DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer DEV\sqlsrv
setspn –U –a MSOLAPDisco.3/MeinSQLServer.domain.local DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer.domain.local:1433 DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer:1433 DEV\sqlsrv
Das wär es für den Datenbankserver. Gehen wir nun zum SharePoint Server über
Kerberos Konfiguration: SharePoint Server
Bevor wir, wie beim SQL Server, die SPNs registrieren, müssen eine ganze Reihe von Voraussetzungen im SharePoint und in Reporting Services geschaffen werden. Als erstes muss sichergestellt werden, dass die Anwendungspools und der Reportserver mit dem selben Dienstkonto betrieben werden. Da in unserem Szenario Reporting Services und SharePoint auf dem selben Server liegen, würde eine andere Konfiguration sonst zu doppelten, und somit widersprüchlichen, SPNs führen.
Den Benutzer des Reporting Services Dienstes erfahren Sie, wie oben, über den SQL Server Configuration Manager. Die Dienstkonten der SharePoint Dienste müssen Sie in der Zentraladministration unter folgendem Pfad überprüfen:
Central Administration > Security > Configure Service Accounts.
Stellen Sie hier sicher, dass die Dienste und die Web Applikation über das selbe Konto, wie Reporting Services verwenden.
Fehlt das Benutzerkonto, klicken Sie unten auf "Register new managed account”
Damit wäre eine der Voraussetzungen erfüllt, es geht jedoch noch weiter.
Claims to Windows Token Service
Für Reporting Services reicht die aktuelle Einstellung bereits aus. Excel Services und Performance Point Services brauchen zur Weitergabe von Kerberos Tokens allerdings auch den Claims to Windows Token Service (C2WTS). Dieser Dienst kann basierend vertrauenswürdigen Anfragen, Sicherheitstokens generieren – somit kann der Dienst für Operationen die Identität des Benutzers annehmen und mit seinen Berechtigungen arbeiten.
Damit es gelingt, muss dieser Dienst seinen Zielen, wo das Token hingeschickt wird, aber auch vertrauen können. Das wird mittels SPNs und Delegierungen festgelegt.
Stellen Sie als erstes sicher, dass dieser Dienst unter einem Domänenbenutzerkonto arbeitet. Dies kann auch über die SharePoint-Maske Configure Service Accounts (siehe oben) erledigt werden. Nun sind da jedoch ein paar Berechtigungen mehr, die dieser Benutzer erfordert. Diese lassen sich in der Verwaltung der Systemsteuerung über die Lokale Sicherheitsrichtlinie einstellen:
- Er muss Mitglied der lokalen Administratorengruppe sein
- Er muss in der Lokalen Sicherheitsrichtlinie folgende Rechte haben:
- Einsetzen als Teil des Betriebssystems (Act as part of the operating system)
- Als Dienst anmelden (Logon as a service)
- Annehmen der Clientidentität nach Authentifizierung (Impersonate a client after authorization)
Soweit, so gut, jetzt sind die meisten Hürden geschafft und es kann an das Erstellen der SPNs und Delegierungen
SharePoint SPNs und Delegierungen
Angenommen, der Claims to Windows Token Service läuft unter einem Benutzer DEV\SPC2WTS, können wir folgenden SPN anlegen. Der Text SP/C2WTS kann beliebig sein, da auf den Dienst von außen nicht zugegriffen wird. Der SPN wird nur für die Delegierung benötigt.
SetSPN –U –A SP/C2WTS DEV\SPC2WTS
Nun die SPNs für das Konto des Anwendungspools:
SetSPN –U –A http/MeinSharePointServer DEV\SPXAPD
SetSPN –U –A http/intranet DEV\SPXAPD
SetSPN –U –A http/intranet.domain.local DEV\SPXAPD
Und jetzt kommt der wichtigste Teil, damit die Kerberos Tickets auch weitereicht werden dürfen: Die Delegierung.
Öffnen Sie dazu auf Ihrem Domänencontroller die Eigenschaften des Benutzers SPC2WTS, dort wird das Tab Delegierung angezeigt. Dort müssen “Benutzer bei Delegierungen angegebener Dienste vertrauen”, “Beliebiges Authentifizierungsprotokoll verwenden” aktiviert sein, dann können Sie auf “Hinzufügen…” klicken.
Es öffnet sich ein neues Fenster, dort gibt es den Button “Benutzer oder Computer”, dort suchen Sie jetzt nach ihrem SharePoint Anwendungspool Benutzer, wenn alles richtig gelaufen ist, erhalten sie dann folgende Anzeigen:
Nun vertrat der User DEV\SPC2WTS dem Benutzer DEV\SPAPD im Kontext des Protokolls http auf dem Server MeinSharePointServer. D.h. SPC2WTS delegiert Kerberos Tokens an http/MeinSharePointServer für den Benutzer SPAPD.
Das wiederholen Sie nun für den Datenbankserver.
Der Benutzer SPAPD muss nämlich das Token weiter delegieren können an den Dienst MSSQLSvc, MSSQLOlapDisco.3 und MSSQLOlapSvc.3 auf dem Datenbankserver.
Weitere Links und Literatur
Wenn Sie diese Einstellungen vorgenommen, sollten Sie Performance Point und Excel Services mit einer erfolgreichen Verbindung belohnen. Ist dies nicht der Fall, prüfen Sie noch die allgemeine Konfiguration dieser Dienste, dazu empfehle ich die folgende Literatur und Links:
Buch: SharePoint 2010 Performance Point Services unleashed
MSDN: Configure Performance Point Services
MSDN: Übersicht über den Claims to Windows Token Service