Freigeben über

Konfigurieren der Windows-Authentifizierung auf dem Berichtsserver

  • Artikel

Standardmäßig akzeptiert Reporting Services Anforderungen, die Negotiate- und NTLM-Authentifizierung verlangen. Wenn eine Bereitstellung Clientanwendungen und Browser umfasst, die diese Sicherheitsanbieter nutzen, können Sie die Standardwerte ohne weitere Konfiguration verwenden. Angenommen, Sie möchten einen anderen Sicherheitsanbieter für die integrierte Windows-Sicherheit nutzen die Standardwerte haben sich geändert und Sie möchten die ursprünglichen Einstellungen wiederherstellen. Anhand der Informationen in diesem Artikel können Sie Authentifizierungseinstellungen auf dem Berichtsserver angeben.

Um die integrierte Sicherheit von Windows nutzen zu können, muss jeder Benutzer, der Zugriff auf einen Berichtsserver benötigt, über ein gültiges Windows-Benutzerkonto verfügen. Oder er muss Mitglied eines lokalen Windows-Gruppenkontos oder eines Windows-Domänengruppenkontos sein. Sie können Konten aus anderen Domänen angeben, sofern diese Domänen vertrauenswürdig sind. Die Konten benötigen Zugriff auf den Berichtsservercomputer und müssen dann Rollen zugewiesen werden, um auf bestimmte Berichtsservervorgänge zugreifen zu können.

Die folgenden Anforderungen müssen ebenfalls erfüllt sein:

  • In den RSReportServer.config-Dateien muss AuthenticationType auf RSWindowsNegotiate, RSWindowsKerberos oder RSWindowsNTLM festgelegt sein. Standardmäßig enthält die Datei RSReportServer.config die RSWindowsNegotiate-Einstellung, wenn das Berichtsserver-Dienstkonto entweder NetworkService oder LocalSystem ist. Andernfalls wird die RSWindowsNTLM-Einstellung verwendet. Sie können RSWindowsKerberos hinzufügen, wenn Anwendungen vorhanden sind, die nur die Kerberos-Authentifizierung verwenden.

    Wichtig

    Wenn Sie RSWindowsNegotiate verwenden, tritt ein Kerberos-Authentifizierungsfehler auf, wenn der Berichtsserverdienst so konfiguriert wurde, dass er unter einem Domänenbenutzerkonto ausgeführt wird und für das Konto kein Dienstprinzipalname (Service Principal Name, SPN) registriert wurde. Weitere Informationen finden Sie unter Beheben von Kerberos-Authentifizierungsfehlern beim Herstellen einer Verbindung mit einem Berichtsserver in diesem Thema.

  • ASP.NET muss für die Windows-Authentifizierung konfiguriert werden. Standardmäßig enthalten die „Web.config“-Dateien für den Berichtsserver-Webdienst die Einstellung <authentication mode="Windows">. Wenn diese Einstellung in <authentication mode="Forms"> geändert wird, tritt bei der Windows-Authentifizierung für Reporting Services ein Fehler auf.

  • Die „Web.config“-Dateien für den Berichtsserver-Webdienst müssen die Einstellung <identity impersonate= "true" /> enthalten.

  • Die Clientanwendung bzw. der Browser muss die integrierte Sicherheit von Windows unterstützen.

  • Das Webportal benötigt keine weitere Konfiguration.

Bearbeiten Sie die XML-Elemente und die Werte in der Datei RSReportServer.config, um die Berichtsserver-Authentifizierungseinstellungen zu ändern. Sie können die Beispiele in diesem Artikel kopieren und einfügen, um bestimmte Kombinationen zu implementieren.

Die Standardeinstellungen eignen sich am besten, wenn sich die Client- und Servercomputer in derselben Domäne oder in einer vertrauenswürdigen Domäne befinden. Und wenn der Berichtsserver für den Intranetzugriff hinter einer Unternehmensfirewall bereitgestellt wird. Vertrauenswürdige Domänen und Einzeldomänen sind eine Voraussetzung für die Weitergabe von Windows-Anmeldeinformationen. Die Anmeldeinformationen können nur dann mehrfach übergeben werden, wenn Sie das Kerberos-Protokoll, Version 5, für die Server aktivieren. Andernfalls können die Anmeldeinformationen nur einmal übergeben werden, bevor sie ablaufen. Weitere Informationen zum Konfigurieren von Anmeldeinformationen für mehrere Computerverbindungen finden Sie unter Angeben der Anmeldeinformationen und Verbindungsinformationen für Berichtsdatenquellen.

Die folgenden Anweisungen beziehen sich auf Berichtsserver, die im einheitlichen Modus ausgeführt werden. Wenn der Berichtserver im integrierten SharePoint-Modus bereitgestellt wird, müssen die Standardauthentifizierungseinstellungen verwendet werden, welche die integrierte Sicherheit von Windows angeben. Der Berichtsserver verwendet interne Funktionen der standardmäßigen Windows-Authentifizierungserweiterung, um Berichtserver im integrierten SharePoint-Modus zu unterstützen.

Erweiterter Schutz für die Authentifizierung

Der erweiterte Schutz für die Authentifizierung wird ab SQL Server 2008 R2 (10.50.x) unterstützt. Die SQL Server -Funktion unterstützt die Verwendung der Kanalbindung und Dienstbindung, um den Authentifizierungsschutz zu verbessern. Die Reporting Services-Funktionen müssen mit einem Betriebssystem verwendet werden, das erweiterten Schutz unterstützt. Sie können die Reporting Services-Konfiguration für erweiterten Schutz durch Einstellungen in der Datei RSReportServer.config bestimmen. Sie können die Datei entweder durch Bearbeitung der Datei oder Verwendung der WMI-APIs aktualisieren. Weitere Informationen finden Sie unter Erweiterter Schutz für die Authentifizierung mit Reporting Services.

Konfigurieren Sie einen Berichtsserver für die Verwendung der integrierten Sicherheit von Windows

  1. Öffnen Sie RSReportServer.config in einem Text-Editor.

  2. Suchen Sie <Authentication>.

  3. Kopieren Sie die XML-Struktur, die Ihren Anforderungen am besten entspricht. Sie können RSWindowsNegotiate, RSWindowsNTLM und RSWindowsKerberos in beliebiger Reihenfolge angeben. Sie sollten die Authentifizierungspersistenz aktivieren, wenn die Verbindung und nicht jede einzelne Anforderung authentifiziert werden soll. Bei Verwendung der Authentifizierungspersistenz werden alle Anforderungen, für die eine Authentifizierung erforderlich ist, zugelassen, solange die Verbindung besteht.

    Die erste XML-Struktur ist die Standardkonfiguration, wenn das Berichtsserver-Dienstkonto entweder NetworkService oder LocalSystem ist:

    <Authentication>
    <AuthenticationTypes>
        <RSWindowsNegotiate />
    </AuthenticationTypes>
    <EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>

    Die zweite XML-Struktur ist die Standardkonfiguration, wenn das Berichtsserver-Dienstkonto weder NetworkService noch LocalSystem ist:

    <Authentication>
    <AuthenticationTypes>
            <RSWindowsNTLM />
    </AuthenticationTypes>
    <EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>

    Die dritte XML-Struktur gibt sämtliche Sicherheitspakete an, die in der integrierten Sicherheit von Windows verwendet werden:

    <AuthenticationTypes>
    <RSWindowsNegotiate />
    <RSWindowsKerberos />
    <RSWindowsNTLM />
</AuthenticationTypes>

    Mit der vierten XML-Struktur wird NTLM nur für Bereitstellungen, die Kerberos nicht unterstützen, bzw. zur Umgehung von Kerberos-Authentifizierungsfehlern angegeben:

    <AuthenticationTypes>
    <RSWindowsNTLM />
</AuthenticationTypes>

  4. Ersetzen Sie damit die vorhandenen Einträge für <Authentication>.

    Sie können Custom nicht mit den RSWindows-Typen verwenden.

  5. Ändern Sie die Einstellungen für erweiterten Schutz nach Bedarf. Erweiterter Schutz ist standardmäßig deaktiviert. Wenn diese Einträge nicht vorhanden sind, wird auf dem aktuellen Computer möglicherweise keine Version von Reporting Services ausgeführt, die erweiterten Schutz unterstützt. Weitere Informationen finden Sie unter Erweiterter Schutz für die Authentifizierung mit Reporting Services

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

  6. Speichern Sie die Datei .

  7. Wenn Sie eine horizontal skalierte Bereitstellung konfiguriert haben, wiederholen Sie diese Schritte für andere in der Bereitstellung vorhandene Berichtsserver.

  8. Starten Sie den Berichtsserver neu, um alle momentan geöffneten Sitzungen zu beenden.

Beheben von Kerberos-Authentifizierungsfehlern beim Herstellen einer Verbindung mit einem Berichtsserver

Bei einem Berichtsserver, der zum Aushandeln oder für die Kerberos-Authentifizierung konfiguriert wurde, kann keine Clientverbindung mit dem Berichtsserver hergestellt werden, wenn ein Kerberos-Authentifizierungsfehler vorliegt. Kerberos-Authentifizierungsfehler treten bekanntermaßen auf, wenn eine der folgende Bedingungen zutrifft:

  • Der Berichtsserverdienst wird unter einem Domänenbenutzerkonto ausgeführt, für das kein Dienstprinzipalname (SPN) registriert wurde.

  • Der Berichtsserver wird mit der Einstellung RSWindowsNegotiate konfiguriert.

  • Der Browser gibt im Authentifizierungsheader der Anforderung, die er an den Berichtsserver sendet, Kerberos statt NTLM an.

Sie können den Fehler erkennen, wenn Sie die Kerberos-Protokollierung aktiviert haben. Ein anderes Fehlersymptom ist, dass Sie mehrfach zur Eingabe von Anmeldeinformationen aufgefordert werden und dann ein leeres Browserfenster angezeigt wird.

Sie können überprüfen, dass ein Kerberos-Authentifizierungsfehler vorliegt, indem Sie <RSWindowsNegotiate> aus der Konfigurationsdatei entfernen und erneut versuchen, eine Verbindung herzustellen.

Nachdem Sie das Problem eindeutig identifiziert haben, können Sie es auf die folgenden Weisen beheben:

  • Registrieren Sie unter dem Domänenbenutzerkonto einen SPN für den Berichtsserverdienst. Weitere Informationen finden Sie unter Registrieren eines Dienstprinzipalnamens (SPN) für einen Berichtsserver.

  • Ändern Sie das Dienstkonto so, dass es unter einem integrierten Konto ausgeführt wird, z. B. als Netzwerkdienst. Integrierte Konten ordnen den HTTP-SPN dem Host-SPN zu, der definiert wird, wenn Sie einen Computer in ein Netzwerk aufnehmen. Weitere Informationen finden Sie unter Konfigurieren eines Dienstkontos (Berichtsserver-Konfigurations-Manager).

  • Verwenden Sie NTLM. NTLM funktioniert im Allgemeinen in Fällen, in denen die Kerberos-Authentifizierung fehlschlägt. Zur Verwendung von NTLM entfernen Sie den Eintrag RSWindowsNegotiate aus der Datei RSReportServer.config, und stellen Sie sicher, dass nur RSWindowsNTLM angegeben ist. Wenn Sie sich für diese Vorgehensweise entscheiden, können Sie auch dann weiterhin ein Domänenbenutzerkonto für den Berichtsserverdienst verwenden, wenn Sie keinen SPN dafür definiert haben.

Zusammenfassend sollten Sie Befehle wie im folgenden Beispiel ausführen. Ersetzen Sie die Werte entsprechend.

setspn -S HTTP/<SSRS Server FDQN> <SSRS Service Account>
setspn -S HTTP/<host header for Report server web site> <SSRS Service Account>
setspn -S HTTP/<SharePoint Server FDQN> <SharePoint Application Pool Account>
setspn -S HTTP/<host header for SharePoint site>  <SharePoint Application Pool Account>
setspn -S HTTP/Dummy <Claims to Windows Taken Service Account>

Protokollieren von Informationen

Es gibt mehrere Quellen von Protokollierungsinformationen, mit denen Probleme im Zusammenhang mit Kerberos gelöst werden können.

User-Account-Control-Attribut

Stellen Sie fest, ob für das Reporting Services-Dienstkonto das erforderliche Attribut in Active Directory festgelegt wurde. Suchen Sie in der Ablaufverfolgungsprotokolldatei des Reporting Services-Diensts nach dem Wert, der für das UserAccountControl-Attribut protokolliert wurde. Der protokollierte Wert weist das Dezimalformat auf. Sie müssen den Dezimalwert in ein hexadezimales Format konvertieren. Anschließend suchen Sie diesen Wert im MSDN-Artikel zum UserAccountControl-Attribut.

  • Der Eintrag im Ablaufverfolgungsprotokoll des Reporting Services-Diensts sieht etwa wie im folgenden Beispiel aus:

    appdomainmanager!DefaultDomain!8f8!01/14/2010-14:42:28:: i INFO: The UserAccountControl value for the service account is 590336

  • Eine Möglichkeit zum Konvertieren des Dezimalwerts in das hexadezimale Format besteht darin, den Microsoft- Windows-Rechner zu verwenden. Der Windows-Rechner unterstützt mehrere Modi mit der Dec-Option und den Hex-Optionen. Wählen Sie die Dec-Option, geben Sie den in der Protokolldatei gefundenen Dezimalwert ein, bzw. fügen Sie ihn ein, und wählen Sie die Option Hex.

  • Lesen Sie dann das Artikel User-Account-Control Attribute (UserAccountControl-Attribut), um das Attribut für das Dienstkonto abzuleiten.

In Active Directory für das Reporting Services-Dienstkonto konfigurierte SPNs

Um die SPNs in der Ablaufverfolgungsprotokolldatei des Reporting Services-Dienstes zu protokollieren, können Sie vorrübergehend die Funktion „Erweiterter Schutz der Reporting Services“ aktivieren.

  • Ändern Sie die Konfigurationsdatei rsreportserver.config , indem Sie folgende Einstellungen vornehmen:

    <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Any</RSWindowsExtendedProtectionScenario>

  • Starten Sie den Reporting Services -Dienst neu.

Wenn Sie den erweiterten Schutz nicht weiterverwenden möchten, setzen Sie die Konfigurationswerte auf die Standardwerte zurück, und starten Sie das Reporting Services-Dienstkonto neu.

<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

Weitere Informationen finden Sie unter Erweiterter Schutz für die Authentifizierung mit Reporting Services.

Wie der Browser zwischen Aushandeln mit Kerberos und Aushandeln mit NTLM auswählt

Wenn Sie über Internet Explorer eine Verbindung mit dem Berichtsserver herstellen, gibt dieser im Authentifizierungsheader entweder ausgehandeltes Kerberos oder NTLM an. NTLM wird statt Kerberos verwendet, wenn eine der folgenden Bedingungen zutrifft:

  • Die Anforderung wird an einen lokalen Berichtsserver gesendet.

  • Die Anforderung wird an eine IP-Adresse des Berichtsservercomputers statt an einen Hostheader oder einen Servernamen gesendet.

  • Firewallsoftware blockiert zur Kerberos-Authentifizierung verwendete Ports.

  • Im Betriebssystem eines bestimmten Servers wurde Kerberos nicht aktiviert.

  • Die Domäne enthält ältere Versionen von Windows-Client- und Serverbetriebssystemen, welche die Kerberos-Authentifizierungsfunktion von neueren Versionen des Betriebssystems nicht unterstützen.

Außerdem hängt die Wahl von ausgehandeltem Kerberos oder NTLM in Internet Explorer von der Konfiguration von URL, LAN und Proxyeinstellungen ab.

Berichtsserver-URL

Wenn die URL einen voll qualifizierten Domänennamen enthält, wählt Internet Explorer NTLM aus. Wenn als URL localhost angegeben wird, wählt Internet Explorer NTLM aus. Wird in der URL der Netzwerkname des Computers angegeben, wählt Internet Explorer Negotiate aus. Je nachdem, ob ein SPN für das Berichtsserver-Dienstkonto vorhanden ist, ist das Aushandeln erfolgreich oder es schlägt fehl.

LAN- und Proxyeinstellungen auf dem Client

In Internet Explorer festgelegte LAN- und Proxyeinstellungen können bestimmen, ob NTLM statt Kerberos gewählt wird. Da verschiedene Organisationen jedoch unterschiedliche LAN- und Proxyeinstellungen verwenden, ist es nicht möglich, die einzelnen Einstellungen genau zu bestimmen, die zu Kerberos-Authentifizierungsfehlern beitragen. Beispielsweise kann eine Organisation Proxyeinstellungen durchsetzen, mit denen Intranet-URLs in vollqualifizierte URLs mit Domänennamen umgewandelt werden, die über Internetverbindungen aufgelöst werden. Wenn verschiedene Authentifizierungsanbieter für unterschiedliche URL-Typen verwendet werden, kann es vorkommen, dass Verbindungen unerwartet erfolgreich hergestellt werden.

Es können Verbindungsfehler auftreten, die Ihrer Meinung nach auf Authentifizierungsfehler zurückzuführen sind. Wenn das der Fall ist, können Sie verschiedene Kombinationen von LAN- und Proxyeinstellungen ausprobieren, um das Problem einzugrenzen. In Internet Explorer befinden sich die LAN- und Proxyeinstellungen im Dialogfeld LAN-Einstellungen , das geöffnet wird, wenn Sie im Dialogfeld Internetoptionen auf der Registerkarte Verbindungen auf LAN-Einstellungen auswählen.

Zusätzliche Informationen für Kerberos und Berichtsserver

Zugehöriger Inhalt