• Artikel

Problembehandlung des erweiterten Schutzes (Reporting Services)

Verwenden Sie dieses Thema, um Probleme beim Verwenden des erweiterten Schutzes mit SQL Server 2008 R2 Reporting Services zu beheben. Auch beim Beheben von allgemeinen Authentifizierungsproblemen kann dieses Thema nützlich sein, da die Ursache für die Probleme möglicherweise die Konfiguration des erweiterten Schutzes ist. Informationen zu aktuellen Entwicklungen mit erweitertem Schutz finden Sie in den aktualisierten Informationen mit erweitertem Schutz.

Common issues and support scenarios

Error messages

Error states

Häufige Probleme und Unterstützungsszenarien

Wie überprüfe ich die aktuellen erweiterten Schutzeinstellungen?

library!DefaultDomain!698!12/29/2009-10:14:49:: i INFO: Initializing RSWindowsExtendedProtectionLevel to 'Off' as specified in Configuration file.

library!DefaultDomain!698!12/29/2009-10:14:49:: i INFO: Initializing RSWindowsExtendedProtectionScenario to 'Proxy' as specified in Configuration file.

Wie finde ich heraus, ob die Authentifizierung durch den erweiterten Schutz fehlschlägt?

Die Dienstablaufverfolgungs-Protokolldatei des Berichtsservers enthält Einträge ähnlich den folgenden:

http!rshost!ec0!12/29/2009-11:01:37:: i INFO: Authentication failed with error state: 46

Suchen Sie die Fehlerstatusnummer und weitere Informationen in der Liste error states an Ende dieses Themas.

Wie kann ich überprüfen, ob erweiterte Schutzüberprüfungen ausgeführt werden?

Aktivieren Sie die ausführliche Protokollierung, indem Sie die Konfigurationsdatei reportingservicesservice.exe.config aktualisieren. Legen Sie im Abschnitt <RStrace> Folgendes fest:

<add name=”Components” value=”all:4” />

  • Starten Sie den Dienst neu.

  • Mit aktivierter ausführlicher Protokollierung schreibt die Authentifizierung Zeilen ähnlich den folgenden und gibt so an, dass die Ausführung von Kanalbindung, Dienstbindung oder beiden Bindungen überprüft wird:

http!rshost!ec0!12/29/2009-11:01:37:: v VERBOSE: Durchführen der Channelbindungsüberprüfung als Proxy.

http!rshost!7b0!12/29/2009-11:26:23:: v VERBOSE: Durchführen der Dienstbindungsüberprüfung.

Weitere Informationen finden Sie unter ReportingServicesService-Konfigurationsdatei.

Berichtsserverkatalog

Microsoft SQL Client wurde nicht aktualisiert, um zur Veröffentlichung von SQL Server 2008 R2 den erweiterten Schutz zu unterstützen. SQL Client wird verwendet, um Verbindungen zu SQL Server-Datenquellen und dem Reporting Services-Katalog herzustellen. Diese Einschränkung in SQL Client wirkt sich auf Reporting Services in folgender Weise aus:

  • Der SQL Server, auf dem die Reporting Services-Katalogdatenbank ausgeführt wird, kann keinen aktivierten erweiterten Schutz haben, da der Berichtsserver dann keine Verbindung zur Katalogdatenbank herstellt und Authentifizierungsfehler zurückgibt.

  • Alle SQL Server, die als Reporting Services-Berichtsdatenquellen verwendet werden, können keinen aktivierten erweiterten Schutz haben, da ansonsten Verbindungsversuche durch den Berichtsserver zur Berichtsdatenquelle fehlschlagen und Authentifizierungsfehler zurückgegeben werden. Sie können das Problem umgehen, indem Sie die Reporting Services-Datenquellen so ändern, dass sie systemeigene Anbieter und nicht SQL Client verwenden. Konfigurieren Sie z. B. die Datenquellen für den ODBC-Treiber. Dann wird der SQL Native Client verwendet, da er erweiterten Schutz unterstützt.

Was geschieht, wenn ich den erweiterten Schutz aktiviere, aber kein SSL konfiguriere?

Das Verhalten hängt von der Einstellung von RSWindowsExtendedProtectionScenario in der Konfigurationsdatei rsreportserver.config ab.

Wenn RSWindowsExtendedProtectionScenario auf "Direkt" festgelegt wird und SSL fehlt

Wenn RSWindowsExtendedProtectionScenarioDirect entspricht, und es keine SSL-URL-Reservierung für den Berichtsserver oder Berichts-Manager gibt, ist die typische Erfahrung für Benutzer, die den Berichtsserver oder Berichts-Manager anzeigen, die Anzeige eines leeren Berichts-Manager-Fensters.

Das liegt daran, dass, wenn SSL fehlt und RSWindowsExtendedProtectionScenario auf "Direkt" festgelegt wird, der Berichtsserver die Authentifizierungstypen <RSWindowsNTLM />, <RSWindowsNegotiate /> und <RSWindowsKerberos /> deaktiviert. Daher gibt es keine aktivierten Authentifizierungstypen, und der Berichtsserver reagiert nicht auf Anforderungen. Dies führt zu den leeren Fenstern.

Die Ablaufverfolgungs-Protokolldatei enthält Fehlermeldungen ähnlich den folgenden:

configmanager!DefaultDomain!938!12/29/2009-11:39:39:: e ERROR: SSL is required on Report Server connections when ExtendedProtectionScenario is set to Direct

configmanager!DefaultDomain!938!12/29/2009-11:39:39:: e ERROR: SSL is required on Report Manager connections when ExtendedProtectionScenario is set to Direct

Wenn RSWindowsExtendedProtectionScenario auf "Proxy" festgelegt wird und SSL fehlt

Wenn RSWindowsExtendedProtectionScenario auf Proxy festgelegt wird, und SSL kein Teil der Umgebung ist, ist die typische Erfahrung für Benutzer, die den Berichtsserver oder Berichts-Manager anzeigen, das Einblenden einer Anmeldeinformationen-Eingabeaufforderungsseite, die nie erfolgreich authentifiziert wird. Wenn SSL auf dem Berichtsserver konfiguriert wird, löst das Hinzufügen von 's' zur URL, die im Browser für Berichtsserver oder Berichts-Manager verwendet wird, das Problem. Zum Beispiel löst https://<uri> löst Problem der Anzeige des Authentifizierungsdialogfelds, wenn das Problem durch Festlegen von RSWindowsExtendedProtectionSscenario auf proxy entstanden ist.

Die Ablaufverfolgungs-Protokolldatei des Berichtsservers enthält Meldungen ähnlich den folgenden:

http!rshost!ec0!12/29/2009-11:01:37:: i INFO: Performing Channel Binding Check as Proxy

http!rshost!76c!12/29/2009-10:26:12:: i INFO: Authentication failed with error state: 45

http!rshost!ec0!12/29/2009-11:01:37:: i INFO: Performing Channel Binding Check as Proxy

http!rshost!ec0!12/29/2009-11:01:37:: i INFO: Authentication failed with error state: 46

Ich kann eine Verbindung in Internet Explorer herstellen, nachdem ich erweiterter Schutz aktiviert habe, aber ich kann keine Verbindung mit dem Berichts-Generator, Management Studio oder irgendeinem .NET-Client herstellen.

Dieses Szenario gilt nur für Betriebssysteme vor Windows 7 und Windows 2008 R2. Vorherige Versionen von Windows wurden anfänglich nicht mit der erweiterten Schutzfunktionalität veröffentlicht, und daher verfügt ein Computer mit der früheren Version des Betriebssystems möglicherweise nicht über alle erweiterten Schutzaktualisierungen, einschließlich der erweiterten Schutzaktualisierung für das .NET-Framework.

Wenn RSWindowsExtendedProtectionLevelAllow oder Require entspricht, muss eine Clientanwendung, die unter einem Betriebssystem ausgeführt wird, das erweiterten Schutz unterstützt, Kanalbindung und manchmal Dienstbindung bereitstellen. In diesem Beispiel:

  • Internet Explorer wurde für erweiterten Schutz als Teil der erweiterten Schutzaktualisierung von Windows aktualisiert.

  • Das .NET Framework wurde jedoch nicht gepatcht. Das .NET Framework ist für .NET-Clients erforderlich, z. B. für den Berichts-Generator und Management Studio.

Um dieses Problem zu diagnostizieren, deaktivieren Sie den erweiterten Schutz, und überprüfen Sie, ob die .NET-Clientanwendung keine Verbindung herstellen kann. So deaktivieren Sie den erweiterten Schutz:

  1. Legen Sie RSWindowsExtendedProtectionLevel auf Off in der Datei RSReportServer.config fest.

  2. Starten Sie den Berichtsserverdienst neu.

Die Lösung ist, alle .NET Framework-Aktualisierungen herunterzuladen.

Warum übergeben lokale Verbindungen die Authentifizierung, wenn der erweiterte Schutz aktiviert ist, aber Remoteverbindungen können nicht hergestellt werden?

Wenn das Betriebssystem eine Loopbackauthentifizierung ausführt, wird der Authentifizierungsmechanismus übersprungen und keine Kanalbindung erzwungen.

Wenn Sie also eine HTTP-Verbindung und folgende Konfigurationseinstellungen verwenden:

  • RSWindowsExtendedProtectionLevel ist auf Require festgelegt

    AND

  • RSWindowsExtendedProtectionScenario ist auf Proxy festgelegt

Die lokale Verbindung ist erfolgreich, aber Remoteverbindungen schlagen fehl.

Abhängig von der URL, die verwendet wurde, um die lokale Verbindung herzustellen, und von der auf dem Berichtsserver konfigurierten URL-Reservierungen, ist es immer noch möglich, dass die lokale Verbindung mit einem Dienstbindungsfehler fehlschlägt, da der SPN, der aus der URL-Reservierung erstellt wurde, möglicherweise keinem SPN in der Liste gültiger SPNs entspricht.

Die Remoteverbindung schlägt immer fehl, wenn Sie eine HTTP-Verbindung herstellen und sich zwischen dem Client und dem Berichtsserver, der konfiguriert wurde, um eine SSL-Verbindung herzustellen, kein Gateway befindet.

401 nicht autorisierter Fehler beim Verwenden eines Hostheaders

Dieses Szenario ist für eine Bereitstellung für horizontales Skalieren von Reporting Services spezifisch und tritt auf, wenn sich der Berichts-Manager und Berichtsserver auf demselben Computer befinden und beide Hostheader und Windows-Authentifizierung verwenden. Wenn Sie beispielsweise versuchen, auf den Berichts-Manager unter http://<derName>/reports zuzugreifen, wird entgegen Ihren Erwartungen keine Liste mit Berichten und Ordnern angezeigt, sondern die Fehlermeldung "HTTP 401 (nichts autorisiert)".

Der Verweis <derNamename> ist nicht der physische Name des Computers und wird als "Hostheader" angesehen. Das ist ein alternativer Name für den Computer, auf dem Reporting Services installiert ist. Hostheader werden auch als Quelle für gültige SPNs verwendet, wenn Reporting Services die gültige Liste der SPNs für den erweiterten Schutz berechnet.

Um den Fehler 401 (nicht autorisiert) zu verhindern, müssen Sie den NetBIOS-Namen und den vollqualifizierten Domänennamen (Fully Qualified Domain Name oder FQDN) für <derName> der in der Windows-Registrierung gespeicherten Liste BackConnectionHostNames hinzufügen. Starten Sie den Computer neu, nachdem Sie die Registrierungsänderung vorgenommen haben.

Weitere Informationen zum Durchführen der Registrierungsänderung finden Sie im Abschnitt "Methode 2: Angeben von Hostnamen" im MicrosoftKnowledge Base-Artikel 896861, Fehler 401.1 wird ausgegeben, wenn Sie eine Website durchsuchen, die die integrierte Authentifizierung verwendet und auf IIS 5.1 oder höher gehostet wird.

Fehlermeldungen

Die folgende Liste von Meldungen wird möglicherweise in der Dienstablaufverfolgungs-Protokolldatei des Berichtsservers angezeigt.

Fehlermeldung

Typ

Ursache

Schritte bei der Problembehandlung

Fehlende oder ungültige ExtendedProtectionScenario-Einstellung

Fehler

  • RSWindowsExtendedProtectionScenario ist nicht in der Datei rsreportserver.config.

  • Aktualisieren Sie die Konfigurationsdatei auf die Standardwerte.

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

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

SSL ist auf Berichtsserververbindungen erforderlich, wenn ExtendedProtectionScenario auf "Direkt" festgelegt wird.

Fehler

  • RSWindowsExtendedProtectionScenario ist auf Direct festgelegt.

  • Die Option Direct erfordert eine SSL-Verbindung.

  • Rufen Sie ein SSL-Zertifikat ab, und konfigurieren Sie eine SSL-URL für Berichtsserver und Berichts-Manager. Dasselbe müssen Sie für die SharePoint-Zentraladministration durchführen, wenn Sie Reporting Services im integrierten SharePoint-Modus verwenden.

  • Legen Sie RSWindowsExtendedProtectionLevel auf Off fest, bis ein SSL-Zertifikat abgerufen und konfiguriert wird.

  • Legen Sie RSWindowsExtendedProtectionScenario auf Any fest, wenn kein SSL-Zertifikat konfiguriert wird, und etwas Schutz dennoch gewünscht wird.

HTTP-Datenverkehr zum Berichtsserver schlägt mit NTLM-, Kerberos-, Negotiate-Authentifizierung fehl.

Warnung

  • RSWindowsExtendedProtectionScenario ist auf Direct festgelegt.

  • "Direkt" erfordert SSL.

  • Eine HTTP-URL-Reservierung wird konfiguriert. Die Authentifizierung auf dieser URL-Reservierung schlägt fehl.

  • Kommunizieren Sie mithilfe von HTTPS mit dem Berichtsserver.

  • Entfernen Sie die HTTP-URL-Reservierung mithilfe des Reporting Services-Konfigurations-Managers.

SSL ist auf Berichts-Manager-Verbindungen erforderlich, wenn ExtendedProtectionScenario auf "Direkt" festgelegt wird.

Fehler

  • RSWindowsExtendedProtectionScenario ist auf Direct festgelegt.

  • Direct erfordert SSL.

  • Der Berichts-Manager hat keine konfigurierte SSL-URL.

  • Rufen Sie ein SSL-Zertifikat ab, und konfigurieren Sie eine SSL-URL für Berichtsserver und Berichts-Manager. Dasselbe müssen Sie für die SharePoint-Zentraladministration durchführen, wenn Sie Reporting Services im integrierten SharePoint-Modus verwenden.

  • Legen Sie RSWindowsExtendedProtectionLevel auf Off fest, bis ein SSL-Zertifikat abgerufen und konfiguriert wird.

  • Legen Sie RSWindowsExtendedProtectionScenario auf Any fest, wenn kein SSL-Zertifikat konfiguriert wird, und etwas Schutz dennoch gewünscht wird.

Direkte Verbindungen zum Berichtsserver schlagen mit NTLM-, Kerberos-, Negotiate-Authentifizierung fehl.

Warnung

  • RSWindowsExtendedProtectionScenario ist Proxy; für den Berichts-Manager wird keine SSL-URL konfiguriert.

  • Wenn auf diese Weise konfiguriert wird, MUSS der Benutzer eine Verbindung zum PROXY über einen SSL-Kanal herstellen. Die Verbindung kann von einem Proxygerät beendet werden. Wenn eine direkte Verbindung mit dem SSRS-Server ohne SSL-Kanal hergestellt wird, schlägt die Authentifizierung fehl.

  • Überprüfen Sie, ob Clients nur HTTPS verwenden.

  • Überprüfen Sie, ob ein Proxy konfiguriert ist, für den SSL-Beendigung konfiguriert wurde.

  • Überprüfen Sie, ob alle lokalen Computer und alle Remote-Computer so konfiguriert wurden, dass der Proxy für Verbindungen zum Berichtsserver und zum Berichts-Manager verwendet wird. Dies erfordert möglicherweise DNS-Aktualisierungen, Browserproxyaktualisierungen oder benutzerdefinierte HOSTS-Dateieinträge für den lokalen Computer.

  • Konfigurieren Sie auf dem Server Reporting Services für Berichtsserver und Berichts-Manager oder in der SharePoint-Zentraladministration eine SSL-URL, wenn Sie Reporting Services im integrierten SharePoint-Modus verwenden. Alle lokalen Verbindungen müssen die SSL-URL verwenden. Dabei wird davon ausgegangen, dass kein Proxy mit Beendigung konfiguriert wurde.

  • Legen Sie die Berichts-Manager-URL explizit so fest, dass die Proxy-URL mit SSL verwendet wird.

HTTP-Datenverkehr zum Berichts-Manager schlägt möglicherweise mit NTLM-, Kerberos-, Negotiate-Authentifizierung fehl.

Warnung

  • ExtendedProtectionScenario wird auf Proxy festgelegt, und eine SSL-URL wird für den Berichts-Manager konfiguriert.

  • Wenn auf diese Weise konfiguriert wird, erwarten Benutzer, die über einen Proxy zugreifen, die erfolgreiche Authentifizierung, auch wenn die Verbindung vom Proxy zum Berichts-Manager nicht über einen SSL-Kanal hergestellt wird.

  • Lokale Verbindungen zum Berichts-Manager müssen SSL verwenden.

  • Überprüfen Sie, ob Clients nur HTTPS (SSL-Kanal) verwenden.

  • Überprüfen Sie, ob ein Proxy konfiguriert ist, für den SSL-Beendigung konfiguriert wurde.

  • Überprüfen Sie, ob alle lokalen Computer und alle Remote-Computer so konfiguriert wurden, dass der Proxy für Verbindungen zum Berichtsserver und zum Berichts-Manager verwendet wird. Dies erfordert möglicherweise DNS-Aktualisierungen, Browserproxyaktualisierungen oder benutzerdefinierte HOSTS-Dateieinträge für den lokalen Computer.

  • Konfigurieren Sie eine SSL-URL auf dem Reporting Services-Server für den Berichtsserver und den Berichts-Manager. Alle lokalen Verbindungen müssen die SSL-URL verwenden. Dabei wird davon ausgegangen, dass kein Proxy mit Beendigung konfiguriert wurde.

  • Legen Sie die Berichts-Manager-URL explizit so fest, dass die Proxy-URL mit SSL verwendet wird.

Fehlerstatus

Dieser Abschnitt enthält Namen und Beschreibungen für Fehlercodes, die Sie möglicherweise im Dienstablauf-Verfolgungsprotokoll des Berichtsservers zum erweiterten Schutz sehen. Weitere Informationen finden Sie unter Berichtsserverdienst-Ablaufverfolgungsprotokoll.

Code

Fehlerstatusname

Beschreibung

44

SNIAUTH_ERRST_SSPIHANDSHAKE_CHANNELBINDINGS_NOTSUPPORTED

Das Betriebssystem unterstützt keine Kanalbindungen, aber der Berichtsserver wird so konfiguriert, dass er erweiterten Schutz erfordert. Aktualisieren Sie das Betriebssystem, oder deaktivieren Sie den erweiterten Schutz.

45

SNIAUTH_ERRST_SSPIHANDSHAKE_CHANNELBINDINGS_EMPTYORWRONG

Die Kanalbindungen vom Client passen nicht zum eingerichteten Transportebenen-Sicherheitskanal. Der Dienst könnte angegriffen werden, oder der Datenanbieter muss möglicherweise aktualisiert werden, um erweiterten Schutz zu unterstützen. Die Verbindung wurde geschlossen.

46

SNIAUTH_ERRST_SSPIHANDSHAKE_CHANNELBINDINGS_NULLOREMPTYORWRONG

Die Kanalbindungen von diesem Client fehlen oder passen nicht zum eingerichteten Transportebenen-Sicherheitskanal. Der Dienst könnte angegriffen werden, oder der Datenanbieter oder das Clientbetriebssystem muss möglicherweise aktualisiert werden, um erweiterten Schutz zu unterstützen. Die Verbindung wurde geschlossen.

48

SNIAUTH_ERRST_SSPIHANDSHAKE_SERVICEBINDINGS_UNSUPPORTED

Das Betriebssystem unterstützt keine Dienstbindungen, aber der Server wird so konfiguriert, dass er erweiterten Schutz erfordert. Aktualisieren Sie das Betriebssystem, oder deaktivieren Sie den erweiterten Schutz.

49

SNIAUTH_ERRST_SSPIHANDSHAKE_SERVICEBINDINGS_QUERYCONTEXTATTRIBUTES

QueryContextAttributes konnte keine Dienstbindungen abrufen. Der Windows-Fehlercode gibt die Ursache des Fehlers an.

51

SNIAUTH_ERRST_SSPIHANDSHAKE_SERVICEBINDINGS_NULL

Die erweiterte Serverschutzebene wird auf Zulässig oder Erforderlich festgelegt, und der Client hat keinen Dienstprinzipalnamen (Service Principal Name oder SPN) bereitgestellt. Um eine Verbindung herzustellen, muss dieser Client erweiterten Schutz unterstützen. Möglicherweise müssen Sie ein Betriebssystem-Service Pack installieren, das Dienstbindung und Kanalbindung zulässt.

52

SNIAUTH_ERRST_SSPIHANDSHAKE_SERVICEBINDINGS_EMPTY

Die erweiterte Serverschutzebene wird auf Zulässig oder Erforderlich festgelegt, und der Client hat keinen SPN bereitgestellt. Um eine Verbindung herzustellen, muss dieser Client erweiterten Schutz unterstützen.

53

SNIAUTH_ERRST_SSPIHANDSHAKE_SERVICEBINDINGS_SERVICECLASSMISMATCH

Das Dienstklassenelement des empfangenen SPNs ist nicht gültig.

54

SNIAUTH_ERRST_SSPIHANDSHAKE_SERVICEBINDINGS_IPADDRESSMISMATCH

Das IP-Adressenelement des empfangenen SPNs ist nicht gültig.

55

SNIAUTH_ERRST_SSPIHANDSHAKE_SERVICEBINDINGS_HOSTNAMEMISMATCH

Das Hostelement des empfangenen SPNs ist nicht gültig.

56

SNIAUTH_ERRST_SSPIHANDSHAKE_OOM

Beim Überprüfen des empfangenen SPNs ist eine Speicherbelegung fehlgeschlagen.

57

SNIAUTH_ERRST_SSPIHANDSHAKE_SERVICEBINDINGS_WSASTRINGTOADDRESSFAILEDFORIPV6

WSAStringToAddress konnte das IP-Adressenelement des empfangenen SPNs nicht in eine Adressenstruktur konvertieren. Der Windows-Fehlercode gibt die Ursache des Fehlers an.