Windows-Authentifizierung auf dem Berichtsserver konfigurieren

Standardmäßig akzeptiert Reporting Services Anfragen, die Negotiate- oder NTLM-Authentifizierung spezifizieren. Wenn Ihre Bereitstellung Client-Anwendungen und Browser enthält, die diese Sicherheitsanbieter nutzen, können Sie die Standardwerte ohne andere Konfigurationen verwenden. Angenommen, du möchtest einen anderen Sicherheitsanbieter für die integrierte Windows-Sicherheit nutzen, oder du änderst die Standardwerte und möchtest die ursprünglichen Einstellungen wiederherstellen. Sie können die Informationen in diesem Artikel nutzen, um Authentifizierungseinstellungen auf dem Berichtsserver anzugeben.

Um die integrierte Windows-Sicherheit zu nutzen, muss jeder Nutzer, der Zugriff auf einen Berichtsserver benötigt, ein gültiges Windows-Lokal- oder Domain-Benutzerkonto haben. Oder sie müssen Mitglied eines lokalen Windows- oder Domain-Gruppenkontos sein. Du kannst Konten von anderen Domains einbeziehen, solange diese Domains vertrauenswürdig sind. Die Konten müssen Zugriff auf den Berichtsserver-Computer haben und dann Rollen zugewiesen werden, um Zugriff auf bestimmte Berichtsserver-Operationen zu erhalten.

Folgende 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 RSReportServer.config-Datei die Einstellung RSWindowsNegotiate , wenn das Report Server-Servicekonto entweder NetworkService oder LocalSystem ist; ansonsten wird die Einstellung RSWindowsNTLM verwendet. Du kannst hinzufügen RSWindowsKerberos , wenn du Anwendungen hast, die nur Kerberos-Authentifizierung verwenden.

    Von Bedeutung

    Wenn Sie RSWindowsNegotiate verwenden, tritt ein Kerberos-Authentifizierungsfehler auf, wenn Sie den Report-Server-Dienst so konfiguriert haben, dass er unter einem Domänenbenutzerkonto ausgeführt wird, und Sie keinen Service Principal Name (SPN) für das Konto registriert haben. Weitere Informationen finden Sie unter Kerberos-Authentifizierungsfehler beheben bei der Verbindung zu einem Berichtsserver in diesem Thema.

  • ASP.NET muss für die Windows-Authentifizierung konfiguriert sein. Standardmäßig enthalten die Web.config Dateien für den Report Server Webservice die Einstellung <authentication mode="Windows"> . Wenn du es auf <authentication mode="Forms">änderst, schlägt die Windows-Authentifizierung für Reporting Services fehl.

  • Die Web.config-Dateien für den Report Server-Webdienst müssen <identity impersonate= "true" /> aufweisen.

  • Die Client-Anwendung oder der Browser muss Windows-integrierte Sicherheit unterstützen.

  • Das Webportal braucht keine weitere Konfiguration.

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

Die Standardeinstellungen funktionieren am besten, wenn alle Client- und Server-Computer in derselben Domäne oder in einer vertrauenswürdigen Domäne sind. Und der Berichtsserver wird für den Intranetzugriff hinter einer Unternehmensfirewall bereitgestellt. Vertrauenswürdige und einzelne Domänen sind Voraussetzung für die Weitergabe von Windows-Zugangsdaten. Zugangsdaten können mehr als einmal weitergegeben werden, wenn Sie das Kerberos Version 5-Protokoll für Ihre Server aktivieren. Andernfalls können Zugangsdaten nur einmal weitergegeben werden, bevor sie ablaufen. Weitere Informationen zum Konfigurieren von Zugangsdaten für Verbindungen mit mehreren Computern finden Sie unter Zugangsdaten und Verbindungsinformationen für Berichtsdatenquellen angeben.

Die folgenden Anweisungen gelten für einen Berichtsserver im einheitlichen Modus. 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 Standarderweiterung Windows Authentication, um Berichtsserver 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 Funktionen der Reporting Services müssen mit einem Betriebssystem verwendet werden, das erweiterten Schutz unterstützt. Du kannst Reporting Services Konfiguration für erweiterten Schutz durch spezifische Einstellungen in der RSReportServer.config-Datei bestimmen. Sie können die Datei aktualisieren, indem Sie sie entweder bearbeiten oder WMI-APIs verwenden. Weitere Informationen finden Sie unter Erweiterter Schutz für die Authentifizierung mit Reporting Services.

Konfigurieren Sie einen Berichtsserver so, dass er Windows-integrierte Sicherheit verwendet

  1. Öffnen Sie RSReportServer.config in einem Texteditor.

  2. Finden Sie <Authentication>.

  3. Kopieren Sie eine der folgenden XML-Strukturen, die am besten zu Ihren Anforderungen passt. Sie können RSWindowsNTLM, RSWindowsKerberos und RSWindowsNegotiate in beliebiger Reihenfolge angeben. Du solltest die Authentifizierungspersistenz aktivieren, wenn du die Verbindung authentifizieren möchtest, anstatt jede einzelne Anfrage. Bei der Authentifizierungspersistenz sind alle Anfragen, die eine Authentifizierung erfordern, während der Verbindung erlaubt.

    Die erste XML-Struktur ist die Standardkonfiguration, wenn das Report Server Service-Konto entweder NetworkService oder LocalSystem ist:

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

    Die zweite XML-Struktur ist die Standardkonfiguration, wenn das Report Server-Servicekonto nicht NetworkService oder LocalSystem ist:

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

    Die dritte XML-Struktur spezifiziert alle Sicherheitspakete, die in Windows integrierter Sicherheit verwendet werden:

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

    Die vierte XML-Struktur spezifiziert NTLM nur für Deployments, die Kerberos nicht unterstützen oder um Kerberos-Authentifizierungsfehler zu umgehen:

    <AuthenticationTypes>
    <RSWindowsNTLM />
</AuthenticationTypes>

  4. Füge es anstelle der vorhandenen Einträge für <Authentication> ein.

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

  5. Passen Sie die Einstellungen für erweiterten Schutz entsprechend an. Erweiterter Schutz ist standardmäßig deaktiviert. Wenn diese Einträge nicht vorhanden sind, kann es sein, dass der aktuelle Computer keine Version von Reporting Services ausführt, die erweiterten Schutz unterstützt. Weitere Informationen finden Sie unter Erweiterter Schutz für Authentifizierung mit Reporting Services

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

  6. Speichern Sie die Datei.

  7. Wenn Sie eine Scale-out-Bereitstellung konfiguriert haben, wiederholen Sie diese Schritte für andere Berichtsserver in der Bereitstellung.

  8. Starte den Berichtsserver neu, um alle derzeit offenen Sitzungen zu löschen.

Beheben Sie Kerberos-Authentifizierungsfehler beim Verbinden mit einem Report Server

Auf einem Berichtsserver, der für Negotiate- oder Kerberos-Authentifizierung konfiguriert ist, fällt eine Client-Verbindung zum Berichtsserver fehl, wenn ein Kerberos-Authentifizierungsfehler auftritt. Kerberos-Authentifizierungsfehler treten nachweislich auf, wenn:

  • Der Report Server Service läuft als Windows-Domain-Benutzerkonto und du hast keinen Service Principal Name (SPN) für das Konto registriert.

  • Der Berichtsserver ist mit dieser Einstellung RSWindowsNegotiate konfiguriert.

  • Der Browser wählt Kerberos statt NTLM im Authentifizierungsheader der Anfrage, die er an den Berichtsserver sendet.

Du kannst den Fehler erkennen, wenn du das Kerberos-Logging aktiviert hast. Ein weiteres Symptom des Fehlers ist, dass man mehrfach nach Zugangsdaten gefragt wird und dann ein leeres Browserfenster sieht.

Du kannst bestätigen, dass du auf einen Kerberos-Authentifizierungsfehler stößt, indem du aus deiner Konfigurationsdatei entfernst <RSWindowsNegotiate> und die Verbindung erneut versuchst.

Nachdem Sie das Problem bestätigt haben, können Sie es auf folgende Weise beheben:

  • Registrieren Sie eine SPN für den Report Server-Service unter dem Domain-Benutzerkonto. Weitere Informationen finden Sie unter Registrieren eines Dienstprinzipalnamens (SPN) für einen Berichtsserver.

  • Ändere das Service-Konto so, dass es unter einem integrierten Konto wie Network Service läuft. Eingebaute Konten ordnen HTTP-SPN dem Host-SPN zu, das definiert wird, wenn Sie einen Computer mit Ihrem Netzwerk verbinden. Weitere Informationen finden Sie unter Konfigurieren eines Dienstkontos (Berichtsserver-Konfigurations-Manager).

  • Benutze NTLM. NTLM funktioniert in der Regel in Fällen, in denen die Kerberos-Authentifizierung fehlschlägt. Um NTLM zu verwenden, entfernen Sie RSWindowsNegotiate aus der Datei RSReportServer.config, und stellen Sie sicher, dass nur RSWindowsNTLM angegeben ist. Wenn Sie diesen Ansatz wählen, können Sie weiterhin ein Domänenbenutzerkonto für den Report Server-Service verwenden, auch wenn Sie dafür kein SPN definieren.

Zusammenfassend solltest du Befehle ausführen, die dem folgenden Beispiel ähneln. Ersetzen Sie die Werte nach Bedarf.

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 für Logging-Informationen, die helfen können, Kerberos-bezogene Probleme zu lösen.

Attribut der Benutzerkontensteuerung

Bestimmen Sie, ob für das Reporting Services-Servicekonto in Active Directory das erforderliche Attribut festgelegt ist. Überprüfen Sie die Ablaufverfolgungsprotokolldatei des Reporting Services-Diensts, um den für das Attribut UserAccountControl protokollierten Wert zu finden. Der aufgezeichnete Wert ist in Dezimalform. Du musst den Dezimalwert in die hexadezimale Form umwandeln und diesen Wert dann im MSDN-Artikel finden, der User-Account-Control Attribut beschreibt.

  • 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. Windows Calculator unterstützt mehrere Modi, in denen die Option Hex und die Optionen Dec angezeigt werden. Wählen Sie die Dec Option, fügen Sie den Dezimalwert ein, den Sie in der Logdatei gefunden haben, und wählen Sie dann die Option 'Hex'.

  • Lesen Sie dann den Artikel User-Account-Control Attribute, um das Attribut für das Dienstkonto zu ermitteln.

SPNs, die in Active Directory für das Reporting Services-Servicekonto konfiguriert sind

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 Konfigurationsdateirsreportserver.config , indem Sie Folgendes setzen:

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

  • Starte den Reporting Services-Dienst neu.

Wenn Sie Extended Protection nicht weiter nutzen möchten, setzen Sie die Konfigurationswerte wieder auf die Standardwerte und starten Sie das Reporting Services Service-Konto 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 Negotiated Kerberos und Negotiated NTLM entscheidet

Wenn Sie den Internet Explorer verwenden, um sich mit dem Berichtsserver zu verbinden, wird im Authentifizierungsheader entweder Negotiated Kerberos oder NTLM angegeben. NTLM wird anstelle von Kerberos verwendet, wenn:

  • Die Anfrage wird an einen lokalen Berichtsserver gesendet.

  • Die Anfrage wird an eine IP-Adresse des Berichtsserver-Computers gesendet, anstatt an einen Host-Header oder Servernamen.

  • Firewall-Software blockiert Ports, die für die Kerberos-Authentifizierung verwendet werden.

  • Das Betriebssystem eines bestimmten Servers hat Kerberos nicht aktiviert.

  • Die Domäne umfasst ältere Versionen von Windows-Client- und Server-Betriebssystemen, die die in neuere Versionen integrierte Kerberos-Authentifizierungsfunktion nicht unterstützen.

Außerdem kann Internet Explorer je nach Konfiguration von URL, LAN und Proxy-Einstellungen entweder Negotiated Kerberos oder NTLM wählen.

Berichtsserver-URL

Wenn die URL einen vollständig qualifizierten Domainnamen enthält, wählt Internet Explorer NTLM aus. Wenn die URL localhost angibt, wählt Internet Explorer NTLM aus. Wenn die URL den Netzwerknamen des Computers angibt, wählt Internet Explorer Negotiate aus, was je nach Existenz eines SPN für das Report Server-Servicekonto erfolgreich oder fehlschlägt.

LAN- und Proxy-Einstellungen auf dem Client

LAN- und Proxy-Einstellungen, die du im Internet Explorer einstellst, können bestimmen, ob NTLM gegenüber Kerberos gewählt wird. Da LAN- und Proxy-Einstellungen jedoch zwischen Organisationen variieren, ist es nicht möglich, genau zu bestimmen, welche Einstellungen zu Kerberos-Authentifizierungsfehlern beitragen. Zum Beispiel könnte Ihre Organisation Proxy-Einstellungen durchsetzen, die URLs von Intranet-URLs in vollständig qualifizierte Domainnamen-URLs umwandeln, die über Internetverbindungen aufgelöst werden. Wenn verschiedene Authentifizierungsanbieter für unterschiedliche Arten von URLs verwendet werden, könnten Sie feststellen, dass einige Verbindungen erfolgreich sind, obwohl Sie erwarten, dass sie ausfallen.

Du könntest auf Verbindungsfehler stoßen, von denen du denkst, dass sie auf Authentifizierungsfehler zurückzuführen sind. Wenn ja, kannst du verschiedene Kombinationen aus LAN- und Proxy-Einstellungen ausprobieren, um das Problem zu isolieren. Im Internet Explorer befinden sich LAN- und Proxy-Einstellungen im Dialogfeld Local Area Network (LAN) Einstellungen, das Sie öffnen, indem Sie LAN-Einstellungen im Tab Connection der Internetoptionen auswählen.

Zusätzliche Informationen zu Kerberos und Berichtsservern

Verwandte Inhalte

  • Last updated on