Erweiterter Schutz für die Authentifizierung mit Reporting Services

Beim Erweiterten Schutz handelt es sich um eine Reihe von Erweiterungen der aktuellen Versionen des Microsoft Windows-Betriebssystems. Erweiterter Schutz verbessert den Schutz der Anmeldeinformationen und der Authentifizierung durch Anwendungen. Das Feature selbst bietet keinen Schutz gegen bestimmte Angriffe wie z. B. die Weiterleitung von Anmeldeinformationen, es stellt jedoch eine Infrastruktur für Anwendungen wie die Reporting Services bereit, um den Erweiterten Schutz für die Authentifizierung zu erzwingen.

Die Hauptauthentifizierungserweiterungen, die Teil des erweiterten Schutzes sind, sind Dienstbindung und Kanalbindung. Die Kanalbindung verwendet ein Kanalbindungstoken (Channel Binding Token oder CBT), um zu überprüfen, ob der zwischen zwei Endpunkten festgelegte Kanal nicht beeinträchtigt wurde. Dienstbindung überprüft das beabsichtigte Ziel von Authentifizierungstokens mithilfe von Dienstprinzipalnamen (Service Principal Names oder SPN). Weitere Hintergrundinformationen zu erweitertem Schutz finden Sie unter Integrierte Windows-Authentifizierung mit erweitertem Schutz.

SQL Server Reporting Services (SSRS) unterstützen und erzwingen Erweiterten Schutz, der im Betriebssystem aktiviert und in den Reporting Services konfiguriert wurde. Standardmäßig akzeptieren Reporting Services Anforderungen, die die Aushandlungsauthentifizierung oder NTLM-Authentifizierung angeben und daher im Betriebssystem von der Unterstützung des Erweiterten Schutzes und der erweiterten Schutzfunktionen der Reporting Services profitieren könnten.

Wichtig

Windows aktiviert den erweiterten Schutz nicht standardmäßig. Informationen zum Aktivieren des erweiterten Schutzes in Windows finden Sie unter Erweiterter Schutz für die Authentifizierung. Sowohl das Betriebssystem als auch der Clientauthentifizierungsstapel müssen den erweiterten Schutz unterstützen, damit die Authentifizierung erfolgreich ist. Bei älteren Betriebssystemen müssen Sie möglicherweise mehr als ein Update für einen Computer mit vollständigem erweiterten Schutz installieren. Informationen zu aktuellen Entwicklungen mit erweitertem Schutz finden Sie in den aktualisierten Informationen mit erweitertem Schutz.

Übersicht über Reporting Services mit erweitertem Schutz

SSRS unterstützt und erzwingt erweiterten Schutz, der im Betriebssystem aktiviert wurde. Wenn das Betriebssystem keinen erweiterten Schutz unterstützt oder das Feature im Betriebssystem nicht aktiviert wurde, tritt bei der Authentifizierung des Reporting Services-Features für erweiterten Schutz ein Fehler auf. Der Erweiterte Schutz der Reporting Services benötigt außerdem ein TLS/SSL-Zertifikat. Weitere Informationen finden Sie unter Konfigurieren von TLS-Verbindungen auf einem Berichtsserver im nativen Modus

Wichtig

Reporting Services aktivieren den Erweiterten Schutz nicht standardmäßig. Das Feature kann aktiviert werden, indem Sie die Konfigurationsdatei rsreportserver.config bearbeiten oder über die WMI-APIs aktualisieren. SSRS stellt keine Benutzeroberfläche bereit, um erweiterte Schutzeinstellungen zu ändern oder anzuzeigen. Weitere Informationen finden Sie im Abschnitt Konfigurationseinstellungen in diesem Thema.

Häufige Probleme, die wegen Änderungen in erweiterten Schutzeinstellungen oder falsch konfigurierten Einstellungen auftreten, werden nicht mit offensichtlichen Fehlermeldungen oder Dialogfeldern angezeigt. Probleme mit Bezug auf die Konfiguration und Kompatibilität des Erweiterten Schutzes führen zu Authentifizierungsfehlern und Fehlern in den Ablaufverfolgungsprotokollen der Reporting Services.

Wichtig

Einige Technologien für den Datenzugriff unterstützen möglicherweise nicht den erweiterten Schutz. Für die Verbindung mit SQL Server-Datenquellen und der Reporting Services -Katalogdatenbank wird eine Datenzugriffstechnologie verwendet. Falls die Datenzugriffstechnologie den erweiterten Schutz nicht unterstützt, hat dies die folgenden Auswirkungen die Reporting Services:

  • Auf dem SQL Server, auf dem die Reporting Services-Katalogdatenbank ausgeführt wird, kann der erweiterte Schutz nicht aktiviert sein, da der Berichtsserver ansonsten keine Verbindung mit der Katalogdatenbank herstellt und Authentifizierungsfehler zurückgibt.
  • Auf SQL Servern-Instanzen, die als Datenquellen für den Reporting Services-Bericht verwendet werden, kann der erweiterte Schutz nicht aktiviert werden, da andernfalls Verbindungsversuche des Berichtsservers mit der Berichtsdatenquelle fehlschlagen und Authentifizierungsfehler zurückgegeben werden.

Die Dokumentation einer Datenzugriffstechnologie sollte Informationen zu Unterstützung des erweiterten Schutzes enthalten.

Aktualisieren

  • Beim Aktualisieren eines Reporting Services-Servers auf SQL Server 2016 werden der Datei rsreportserver.config Konfigurationseinstellungen mit Standardwerten hinzugefügt. Wenn die Einstellungen bereits vorhanden waren, behält die SQL Server 2016-Installation sie in der Datei rsreportserver.config bei.

  • Wenn der Konfigurationsdatei rsreportserver.config die Konfigurationseinstellungen hinzugefügt werden, ist das Standardverhalten für das erweiterte Schutzfeature der Reporting Services der deaktivierte Zustand. Sie müssen das Feature wie in diesem Artikel beschrieben aktivieren. Weitere Informationen finden Sie im Abschnitt Konfigurationseinstellungen in diesem Artikel.

  • Der Standardwert für die RSWindowsExtendedProtectionLevel-Einstellung ist Off.

  • Der Standardwert für die RSWindowsExtendedProtectionScenario-Einstellung ist Proxy.

  • Aktualisierungsratgeber verifiziert nicht, ob die Unterstützung für den erweiterten Schutz für das Betriebssystem oder die aktuelle Installation der Reporting Services aktiviert ist.

Was der erweiterte Schutz der Reporting Services nicht abdeckt

Die folgenden Featurebereiche und -szenarien werden von der erweiterten Schutzfunktion von Reporting Services nicht unterstützt:

  • Ersteller*innen von benutzerdefinierten Sicherheitserweiterungen für die Reporting Services müssen ihrer benutzerdefinierten Sicherheitserweiterung Unterstützung für den erweiterten Schutz hinzufügen.

  • Drittanbieter müssen die Komponenten von Drittanbietern, die einer Reporting Services-Installation hinzugefügt oder von ihr verwendet werden, aktualisierten, damit der erweiterte Schutz unterstützt wird. Weitere Informationen erhalten Sie vom Drittanbieter.

Bereitstellungsszenarien und -empfehlungen

Die folgenden Szenarios veranschaulichen verschiedene Bereitstellungen und Topologien sowie die empfohlene Konfiguration, um sie mit dem Erweiterten Schutz der Reporting Services zu sichern.

Direkt

Dieses Szenario beschreibt das direkte Herstellen einer Verbindung mit einem Berichtsserver, z. B. eine Intranetumgebung.

Szenario Szenario (Diagramm) So sichern Sie
Direkte TLS-Kommunikation.

Der Berichtsserver erzwingt die Kanalbindung zwischen Client und Berichtsserver.
Diagramm, das die direkte TLS-Kommunikation zeigt.

1) Clientanwendung

2) Berichtsserver
Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Setzen Sie RSWindowsExtendedProtectionScenario auf Direct.



– Dienstbindung ist nicht notwendig, da der TLS-Kanal für Kanalbindung verwendet wird.
direkte HTTP-Kommunikation. Der Berichtsserver erzwingt die Dienstbindung zwischen Client und Berichtsserver. Diagramm, das die HTTP-Kommunikation zeigt.

1) Clientanwendung

2) Berichtsserver
Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Setzen Sie RSWindowsExtendedProtectionScenario auf Any.



– Es gibt keinen TLS-Kanal. Daher ist keine Erzwingung der Kanalbindung möglich.

– Dienstbindung kann überprüft werden, es ist jedoch keine vollständige Verteidigung ohne Kanalbindung. Dienstbindung allein schützt nur vor grundlegenden Bedrohungen.

Proxy und Netzwerklastenausgleich

Clientanwendungen stellen eine Verbindung mit einem Gerät oder einer Software her, die TLS ausführt, und gibt die Anmeldeinformationen zum Server zur Authentifizierung weiter, z. B. ein Extranet, Internet oder Sicheres Intranet. Der Client stellt eine Verbindung mit einem Proxy her, oder alle Clients verwenden einen Proxy.

Beim Verwenden eines Netzwerklastenausgleichsgeräts (NLB-Geräts) ist die Situation identisch.

Szenario Szenario (Diagramm) So sichern Sie
HTTP-Kommunikation. Der Berichtsserver erzwingt die Dienstbindung zwischen Client und Berichtsserver. Diagramm, das die indirekte HTTP-Kommunikation zeigt.

1) Clientanwendung

2) Berichtsserver

3) Proxy
Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Setzen Sie RSWindowsExtendedProtectionScenario auf Any.



– Es gibt keinen TLS-Kanal. Daher ist keine Erzwingung der Kanalbindung möglich.

– Der Berichtsserver muss konfiguriert werden, um den Namen des Proxyservers zu kennen und um sicherzustellen, dass die Dienstbindung ordnungsgemäß erzwungen wird.
HTTP-Kommunikation.

Der Berichtsserver erzwingt die Kanalbindung zwischen Client und Proxy sowie die Dienstbindung zwischen Client und Berichtsserver.
Diagramm, das die indirekte SSL-Kommunikation zeigt.

1) Clientanwendung

2) Berichtsserver

3) Proxy
Legen Sie fest.
RSWindowsExtendedProtectionLevel oder Allow in Require

Setzen Sie RSWindowsExtendedProtectionScenario auf Proxy.



– TLS-Kanal zum Proxy ist verfügbar, daher kann die Kanalbindung zum Proxy erzwungen werden.

– Auch Dienstbindung kann erzwungen werden.

– Der Proxyname muss dem Berichtsserver bekannt sein, und der Berichtsserveradministrator sollte entweder eine URL-Reservierung mit einem Hostheader für ihn erstellen oder den Proxynamen im Windows-Registrierungseintrag BackConnectionHostNames konfigurieren.
Indirekte HTTPS-Kommunikation mit einem sicheren Proxy. Der Berichtsserver erzwingt die Kanalbindung zwischen Client und Proxy sowie die Dienstbindung zwischen Client und Berichtsserver. Diagramm, das die indirekte HTTPS-Kommunikation mit einem sicheren Proxy zeigt.

1) Clientanwendung

2) Berichtsserver

3) Proxy
Legen Sie fest.
RSWindowsExtendedProtectionLevel oder Allow in Require

Setzen Sie RSWindowsExtendedProtectionScenario auf Proxy.



– TLS-Kanal zum Proxy ist verfügbar, daher kann die Kanalbindung zum Proxy erzwungen werden.

– Auch Dienstbindung kann erzwungen werden.

– Der Proxyname muss dem Berichtsserver bekannt sein, und der Berichtsserveradministrator sollte entweder eine URL-Reservierung mit einem Hostheader für ihn erstellen oder den Proxynamen im Windows-Registrierungseintrag BackConnectionHostNames konfigurieren.

Gateway

Dieses Szenario beschreibt Clientanwendungen, die eine Verbindung mit einem Gerät oder einer Software herstellen, die TLS ausführt und den Benutzer authentifiziert. Dann führt das Gerät oder die Software einen Identitätswechsel für den Benutzerkontext oder einen anderen Benutzerkontext durch, bevor es eine Anforderung an den Berichtsserver stellt.

Szenario Szenario (Diagramm) So sichern Sie
indirekte HTTP-Kommunikation.

Das Gateway erzwingt die Kanalbindung vom Client zum Gateway. Es gibt eine Dienstbindung vom Gateway zum Berichtsserver.
Diagramm, das die indirekte SSL-Kommunikation zeigt.

1) Clientanwendung

2) Berichtsserver

3) Gatewaygerät
Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Setzen Sie RSWindowsExtendedProtectionScenario auf Any.



– Kanalbindung vom Client zum Berichtsserver ist nicht möglich, da das Gateway für einen Kontext einen Identitätswechsel durchführt und daher ein neues NTLM-Token erstellt.

– Es gibt kein TLS vom Gateway zum Berichtsserver, daher kann die Kanalbindung nicht erzwungen werden.

– Dienstbindung kann erzwungen werden.

– Der Administrator sollte das Gatewaygerät so konfigurieren, dass Kanalbindung erzwungen wird.
Indirekte HTTPS-Kommunikation mit einem sicheren Gateway. Das Gateway erzwingt die Kanalbindung zwischen Client und Gateway, und der Berichtsserver erzwingt die Kanalbindung zwischen Gateway und Berichtsserver. Diagramm, das die indirekte HTTPS-Kommunikation mit einem sicheren Gateway zeigt.

1) Clientanwendung

2) Berichtsserver

3) Gatewaygerät
Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Setzen Sie RSWindowsExtendedProtectionScenario auf Direct.



– Kanalbindung vom Client zum Berichtsserver ist nicht möglich, da das Gateway für einen Kontext einen Identitätswechsel durchführt und daher ein neues NTLM-Token erstellt.

– TLS vom Gateway zum Berichtsserver bedeutet, dass Kanalbindung erzwungen werden kann.

– Dienstbindung ist nicht erforderlich.

– Der Administrator sollte das Gatewaygerät so konfigurieren, dass Kanalbindung erzwungen wird.

Kombination

Dieses Szenario beschreibt Extranet- oder Internetumgebungen, in denen der Client einen Proxy in Kombination mit einer Intranetumgebung verbindet, in der ein Client eine Verbindung mit dem Berichtsserver herstellt.

Szenario Szenario (Diagramm) So sichern Sie
Indirekter und direkter Zugriff vom Client auf den Berichtsserverdienst ohne TLS entweder über die Verbindung des Clients mit dem Proxy oder des Clients mit dem Berichtsserver. 1) Clientanwendung

2) Berichtsserver

3) Proxy

4) Clientanwendung
Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Setzen Sie RSWindowsExtendedProtectionScenario auf Any.



– Dienstbindung von Client zum Berichtsserver kann erzwungen werden.

– Der Proxyname muss dem Berichtsserver bekannt sein, und der Berichtsserveradministrator sollte entweder eine URL-Reservierung mit einem Hostheader für ihn erstellen oder den Proxynamen im Windows-Registrierungseintrag BackConnectionHostNames konfigurieren.
Indirekter und direkter Zugriff vom Client auf den Berichtsserver, wo der Client eine TLS-Verbindung mit dem Proxy oder dem Berichtsserver herstellt. Diagramm, das den indirekten und direkten Zugriff vom Client auf den Berichtsserver zeigt.

1) Clientanwendung

2) Berichtsserver

3) Proxy

4) Clientanwendung
Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Setzen Sie RSWindowsExtendedProtectionScenario auf Proxy.



– Kanalbindung kann verwendet werden.

– Der Proxyname muss dem Berichtsserver bekannt sein, und der Berichtsserveradministrator sollte entweder eine URL-Reservierung für den Proxy mit einem Hostheader erstellen oder den Proxynamen im Windows-Registrierungseintrag BackConnectionHostNames konfigurieren.

Konfigurieren des erweiterten Schutzes für Reporting Services

Die Datei rsreportserver.config enthält die Konfigurationswerte, die das Verhalten des erweiterten Schutzes der Reporting Services steuern.

Weitere Informationen zur Verwendung und Bearbeitung der Datei rsreportserver.config finden Sie unter RsReportServer.config-Konfigurationsdatei. Die erweiterten Schutzeinstellungen können auch geändert und mithilfe von WMI-APIs überprüft werden. Weitere Informationen finden Sie unterSetExtendedProtectionSettings-Methode (WMI MSReportServer_ConfigurationSetting).

Wenn die Überprüfung der Konfigurationseinstellungen fehlschlägt, werden die Authentifizierungstypen RSWindowsNTLM, RSWindowsKerberos und RSWindowsNegotiate auf dem Berichtsserver deaktiviert.

Konfigurationseinstellungen für den erweiterten Schutz von Reporting Services

In der folgenden Tabelle sind Informationen zu den Konfigurationseinstellungen in der Datei rsreportserver.config für erweiterten Schutz bereitgestellt.

Einstellung Beschreibung
RSWindowsExtendedProtectionLevel Gibt den Grad der Erzwingung des erweiterten Schutzes an. Gültige Werte sind:

Off: Standard. Gibt keine Kanal- oder Dienstbindungsüberprüfung an.

Allow unterstützt erweiterten Schutz, erfordert ihn aber nicht. Gibt Folgendes an:

– Erweiterter Schutz wird für Clientanwendungen, die unter Betriebssystemen ausgeführt werden, die erweiterten Schutz unterstützen, erzwungen. Wie Schutz erzwungen wird, wird durch das Festlegen von RsWindowsExtendedProtectionScenario bestimmt

– Die Authentifizierung ist für Anwendungen zulässig, die unter Betriebssystemen ausgeführt werden, die keinen erweiterten Schutz unterstützen.

Require gibt Folgendes an:

– Erweiterter Schutz wird für Clientanwendungen, die unter Betriebssystemen ausgeführt werden, die erweiterten Schutz unterstützen, erzwungen.

– Die Authentifizierung ist nicht für Anwendungen zulässig, die unter Betriebssystemen ohne Unterstützung von erweitertem Schutz ausgeführt werden.
RsWindowsExtendedProtectionScenario Gibt an, welche Arten des erweiterten Schutzes überprüft werden: Kanalbindung, Dienstbindung oder beides. Gültige Werte sind:

Proxy: Standard. Gibt Folgendes an:

– Windows-NTLM-, Kerberos- und Negotiate-Authentifizierung, wenn ein Kanalbindungstoken vorhanden ist.

– Dienstbindung wird erzwungen.

Any gibt Folgendes an:

– Windows-NTLM-, Kerberos- und Negotiate-Authentifizierung sowie eine Kanalbindung sind nicht erforderlich.

– Dienstbindung wird erzwungen.

Direct gibt Folgendes an:

– Windows-NTLM-, Kerberos- und Negotiate-Authentifizierung, wenn ein CBT vorhanden ist, eine TLS-Verbindung zum aktuellen Dienst vorhanden ist und das CBT für die TLS-Verbindung dem CBT des NTLM-, Kerberos- oder Negotiate-Tokens entspricht.

– Dienstbindung wird erzwungen.



Hinweis: Die Einstellung RsWindowsExtendedProtectionScenario wird ignoriert, wenn RsWindowsExtendedProtectionLevel auf OFF festgelegt ist.

Beispieleinträge in der Konfigurationsdatei rsreportserver.config :

<Authentication>  
         <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>  
         <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionLevel>  
</Authentication>  

Dienstbindung und eingeschlossene SPNs

Die Dienstbindung nutzt Dienstprinzipalnamen (Service Principal Names oder SPN) zur Überprüfung des beabsichtigten Ziels von Authentifizierungstokens. Reporting Services erstellen mithilfe der vorhandenen URL-Reservierungsinformationen eine Liste von SPNs, die als gültig angesehen werden. Anhand der URL-Reservierungsinformationen zur Überprüfung von SPN- und URL-Reservierungen können Systemadministratoren beide von einem einzelnen Standort aus verwalten.

Die Liste der gültigen SPNs wird aktualisiert, wenn eine der folgenden Aktionen erfolgt:

  • Der Berichtsserver wird gestartet.
  • Die Konfigurationseinstellungen für den erweiterten Schutz werden geändert.
  • Die Anwendungsdomäne wird neu gestartet.

Für jede Anwendung gibt es eine spezielle gültige Liste der SPNs. Für Berichts-Manager und Berichtsserver werden z. B. verschiedene Listen mit gültigen SPNs berechnet.

Die gültigen SPNs, die für eine Anwendung berechnet wurde, werden von den folgenden Faktoren bestimmt:

  • Jede URL-Reservierung.

  • Jeder SPN, der vom Domänencontroller für das Dienstkonto für Reporting Services abgerufen wird.

  • Wenn eine URL-Reservierung Platzhalterzeichen ('*' oder '+') enthält, fügt der Berichtsserver jeden einzelnen Eintrag aus der Hosts-Auflistung hinzu.

Hosts-Auflistungsquellen.

In der folgenden Tabelle sind die potenziellen Quellen für die Hosts-Auflistung aufgeführt.

Typ der Quelle BESCHREIBUNG
ComputernameDnsDomäne Der Name der dem lokalen Computer zugewiesenen DNS-Domäne. Wenn der lokale Computer ein Knoten in einem Cluster ist, wird der DNS-Domänenname des virtuellen Clusterservers verwendet.
ComputernameDnsVollqualifiziert Der vollqualifizierte DNS-Name, der den lokalen Computer eindeutig identifiziert. Dieser Name ist eine Kombination des DNS-Hostnamens und des DNS-Domänennamens in der Form Hostname.Domänenname. Wenn der lokale Computer ein Knoten in einem Cluster ist, wird der vollqualifizierte DNS-Domänenname des virtuellen Clusterservers verwendet.
ComputernameDnsHostname Der DNS-Hostname des lokalen Computers. Wenn der lokale Computer ein Knoten in einem Cluster ist, wird der DNS-Hostname des virtuellen Clusterservers verwendet.
ComputernameNetBIOS Der NetBIOS-Name des lokalen Computers. Wenn der lokale Computer ein Knoten in einem Cluster ist, wird der NetBIOS-Name des virtuellen Clusterservers verwendet.
ComputernamePhysischeDnsDomäne Der Name der dem lokalen Computer zugewiesenen DNS-Domäne. Wenn der lokale Computer ein Knoten in einem Cluster ist, wird der DNS-Domänenname des lokalen Computers verwendet, nicht der Name des virtuellen Clusterservers.
ComputernamePhysischerDnsVollqualifiziert Der vollqualifizierte DNS-Name, der den Computer eindeutig identifiziert. Wenn der lokale Computer ein Knoten in einem Cluster ist, wird der vollqualifizierte DNS-Name des lokalen Computers verwendet, nicht der Name des virtuellen Clusterservers.

Der vollqualifizierte DNS-Name ist eine Kombination des DNS-Hostnamens und des DNS-Domänennamens in der Form Hostname.Domänenname.
ComputernamePhysischerDnsHostname Der DNS-Hostname des lokalen Computers. Wenn der lokale Computer ein Knoten in einem Cluster ist, wird der DNS-Hostname des lokalen Computers verwendet, nicht der Name des virtuellen Clusterservers.
ComputernamePhysischerNetBIOS Der NetBIOS-Name des lokalen Computers. Wenn der lokale Computer ein Knoten in einem Cluster ist, ist diese Quelle der NetBIOS-Name des lokalen Computers, nicht der Name des virtuellen Clusterservers.

Weitere Informationen finden Sie unter Registrieren eines Dienstprinzipalnamens (SPN) für einen Berichtsserver und Informationen zu URL-Reservierungen und -Registrierungen (Berichtsserver-Konfigurations-Manager).