Authentifizierung in einem Berichtsserver
SQL Server Reporting Services (SSRS) bietet mehrere konfigurierbare Optionen zum Authentifizieren von Benutzern und Clientanwendungen für einen Berichtsserver. Standardmäßig verwendet ein Berichtsserver die integrierte Windows-Authentifizierung und geht von vertrauenswürdigen Beziehungen aus, wenn sich Client- und Netzwerkressourcen in der gleichen Domäne oder einer vertrauenswürdigen Domäne befinden. Abhängig von der Netzwerktopologie und den Anforderungen der Organisation können Sie das für die integrierte Windows-Authentifizierung verwendete Authentifizierungsprotokoll anpassen. Alternativ können Sie die Standardauthentifizierung verwenden oder eine selbst bereitgestellte und auf einem benutzerdefinierten Formular basierende Authentifizierungserweiterung nutzen. Jeder dieser Authentifizierungstypen kann individuell aktiviert oder deaktiviert werden. Sie können mehrere Authentifizierungstypen aktivieren, wenn der Berichtsserver mehrere Arten von Anforderungen akzeptieren soll.
Authentifizierungstypen
Alle Benutzer oder Anwendungen, die Zugriff auf Inhalte oder Vorgänge des Berichtsservers anfordern, werden mit dem auf dem Berichtsserver konfigurierten Authentifizierungstyp authentifiziert, bevor sie Zugriff erhalten. In der folgenden Tabelle werden die von Reporting Services unterstützten Authentifizierungstypen beschrieben.
| Name des Authentifizierungstyps | Wert HTTP-Authentifizierungsebene | Standardmäßig verwendet | BESCHREIBUNG |
|---|---|---|---|
| RSWindowsNegotiate | Aushandeln | Ja | Dieser Typ versucht zunächst, Kerberos für die integrierte Windows-Authentifizierung zu verwenden, greift aber auf NTLM (NT LAN Manager) zurück, wenn das aktive Verzeichnis dem Berichtsserver kein Ticket für die Client-Anforderung gewähren kann. Negotiate greift nur auf NTLM zurück, wenn das Ticket nicht verfügbar ist. Wenn der erste Versuch zu einem Fehler und nicht zu einem fehlenden Ticket führt, unternimmt der Berichtsserver keinen zweiten Versuch. |
| RSWindowsNTLM | NTLM | Ja | Dieser Typ verwendet NTLM für die integrierte Windows-Authentifizierung. Die Anmeldedaten werden nicht delegiert oder durch einen Identitätswechsel für andere Anforderungen verwendet. Nachfolgende Anforderungen befolgen eine neue Abfrage-/Rückmeldungs-Sequenz. Je nach den Einstellungen für Ihre Netzwerksicherheit können Benutzer aufgefordert werden, Anmeldeinformationen einzugeben, oder die Authentifizierungsanforderung wird transparent verarbeitet. |
| RSWindowsKerberos | Kerberos | No | Dieser Typ verwendet für die integrierte Windows-Authentifizierung Kerberos. Konfigurieren Sie Kerberos mithilfe von Setupdienstprinzipalnamen (SPNs) für Ihre Dienstkonten. Setup erfordert Domänenadministratorrechte. Sie können die Identitätsdelegierung mit Kerberos einrichten. Dann kann das Token des den Bericht anfordernden Benutzers auch für eine weitere Verbindung verwendet werden. Diese Verbindung würde zu den externen Datenquellen bestehen, die Daten für Berichte liefern. Bevor Sie RSWindowsKerberos angeben, stellen Sie sicher, dass der von Ihnen verwendete Browsertyp diesen Authentifizierungstyp unterstützt. Wenn Sie Microsoft Edge oder Internet Explorer verwenden, wird die Kerberos-Authentifizierung nur über Negotiate unterstützt. Microsoft Edge und Internet Explorer formulieren keine Authentifizierungsanforderung, die Kerberos direkt angibt. |
| RSWindowsBasic | Basic | Nein | Die Standardauthentifizierung wird im HTTP-Protokoll definiert und kann nur verwendet werden, um HTTP-Anforderungen an den Berichtsserver zu authentifizieren. Anmeldeinformationen werden mithilfe der Base64-Codierung an die HTTP-Anforderung übergeben. Bei der Standardauthentifizierung können Sie Transport Layer Security (TLS), früher als Secure Sockets Layer (SSL) bezeichnet, zum Verschlüsseln der Benutzerkontoinformationen verwenden, bevor die Informationen über das Netzwerk gesendet werden. SSL bietet einen verschlüsselten Kanal zum Senden einer Verbindungsanforderung vom Client an den Berichtsserver über eine HTTP TCP/IP-Verbindung. Weitere Informationen finden Sie unter Using SSL to Encrypt Confidential Data. |
| Benutzerdefiniert | (Anonym) | Nein | Die anonyme Authentifizierung weist den Berichtsserver an, den Authentifizierungsheader in einer HTTP-Anforderung zu ignorieren. Der Berichtsserver akzeptiert alle Anforderungen. Führen Sie den Aufruf jedoch mit einer benutzerdefinierten ASP.NET-Formularauthentifizierung aus, die Sie zur Authentifizierung des Benutzers bereitstellen. Geben Sie Custom nur an, wenn Sie ein benutzerdefiniertes Authentifizierungsmodul bereitstellen, das alle Authentifizierungsanforderungen auf dem Berichtsserver verarbeitet. Sie können den benutzerdefinierten Authentifizierungstyp nicht mit der Standardauthentifizierungserweiterung von Windows verwenden. |
Nicht unterstützte Authentifizierungsmethoden
Die folgenden Authentifizierungsmethoden und -anforderungen werden nicht unterstützt:
| Authentifizierungsmethode | Erklärung |
|---|---|
| Anonym | Der Berichtsserver akzeptiert nur die nicht authentifizierten Anforderungen anonymer Benutzer in Bereitstellungen, die eine benutzerdefinierte Authentifizierungserweiterung enthalten. Berichts-Generator akzeptiert nicht authentifizierte Anforderungen, wenn Sie den Zugriff des Berichts-Generators auf einen Berichtsserver aktivieren, der für die Standardauthentifizierung konfiguriert ist. In allen anderen Fällen werden die anonymen Anforderungen mit dem Fehler „HTTP Status 401 Access Denied“ abgelehnt, bevor die Anforderung ASP.NET erreicht. Clients, die den Fehler '401 Access Denied' erhalten, müssen die Anforderung mit einem gültigen Authentifizierungstyp umformulieren. |
| Technologie für einmaliges Anmelden (SSO, Single sign-on technologies) | In Reporting Services gibt es keine systemeigene Unterstützung der Technologien für einmaliges Anmelden. Wenn Sie eine Technologie für einmaliges Anmelden verwenden möchten, erstellen Sie eine benutzerdefinierte Authentifizierungserweiterung. Die Hostumgebung des Berichtsservers unterstützt keine ISAPI-Filter (Internetserver-API). Falls die verwendete SSO-Technologie als ISAPI-Filter implementiert ist, sollten Sie die in den ISA (Internet Security and Acceleration Server)-Server integrierte Unterstützung für RSASecueID oder das RADIUS-Protokoll verwenden. Andernfalls können Sie eine ISA-Server-ISAPI oder ein HTTPModule für RS erstellen. Sie sollten den ISA-Server jedoch direkt verwenden. |
| Passport | Wird in SQL Server Reporting Services nicht unterstützt. |
| Digest | Wird in SQL Server Reporting Services nicht unterstützt. |
Konfigurieren von Authentifizierungseinstellungen
Authentifizierungseinstellungen werden für die Standardsicherheit konfiguriert, wenn die Berichtsserver-URL reserviert ist. Wenn Sie diese Einstellungen inkorrekt bearbeiten, gibt der Berichtsserver für Anforderungen, die nicht authentifiziert werden können, die Fehler HTTP 401 Access Denied zurück. Beim Auswählen eines Authentifizierungstyps müssen Sie bereits wissen, wie die Windows-Authentifizierung in Ihrem Netzwerk unterstützt wird. Sie müssen mindestens einen Authentifizierungstyp angeben. Für RSWindows können mehrere Authentifizierungstypen angegeben werden. RSWindows-Authentifizierungstypen (RSWindowsBasic, RSWindowsNTLM, RSWindowsKerberosund RSWindowsNegotiate) schließen sich mit „Custom“ gegenseitig aus.
Wichtig
Reporting Services überprüft nicht, ob die von Ihnen angegebenen Einstellungen für die Computerumgebung korrekt sind. Es ist möglich, dass die Standardsicherheit für Ihre Installation nicht geeignet ist oder die von Ihnen angegebenen Konfigurationseinstellungen für Ihre Sicherheitsinfrastruktur nicht geeignet sind. Sie sollten Ihre Berichtsserverbereitstellung in einer kontrollierten Testumgebung sorgfältig prüfen, bevor Sie sie Ihrer Organisation zur Verfügung stellen.
Der Berichtsserver-Webdienst und das Webportal verwenden stets denselben Authentifizierungstyp. Sie können keine anderen Authentifizierungstypen für die Funktionsbereiche des Berichtsserverdienstes konfigurieren. In einem Bereitstellungsmodell für horizontales Skalieren sollten Sie sicherstellen, dass alle Ihre Änderungen auf allen Knoten der Bereitstellung dupliziert werden. Sie können keine anderen Knoten in der gleichen Bereitstellung für horizontales Skalieren konfigurieren, um andere Authentifizierungstypen zu verwenden.
Die Hintergrundverarbeitung akzeptiert keine Anforderungen von Endbenutzern. Sie authentifiziert jedoch alle Anforderungen für unbeaufsichtigte Ausführungszwecke. Sie verwendet stets die Windows-Authentifizierung und authentifiziert Anforderungen mit dem Berichtsserverdienst oder dem Konto für die unbeaufsichtigte Ausführung, falls die Authentifizierung konfiguriert ist.