• Artikel

Erweiterter Schutz für die Authentifizierung mit Reporting Services

Erweiterter Schutz ist eine Gruppe von Erweiterungen zu den letzten Versionen des Microsoft-Windows-Betriebssystems. Erweiterter Schutz verbessert den Schutz der Anmeldeinformationen und der Authentifizierung durch Anwendungen. Die Funktion selbst bietet keinen Schutz gegen bestimmte Angriffe, z. B. die Anmeldeinformationen-Weiterleitung, aber sie stellt eine Infrastruktur für Anwendungen, wie z. B. Reporting Services, bereit, um 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 Sie unter Integrierte Windows-Authentifizierung unter Verwendung von "Erweiterter Schutz".

SQL Server 2008 R2 Reporting Servicessupports und erzwingt erweiterten Schutz, der im Betriebssystem aktiviert und in Reporting Services konfiguriert wurde. Standardmäßig akzeptiert Reporting Services Anforderungen, die Negotiate- oder NTLM-Authentifizierung angeben und daher im Betriebssystem von der Unterstützung durch erweiterten Schutz und der erweiterten Reporting Services-Schutzfunktionen profitieren könnten.

Wichtiger HinweisWichtig

Windows aktiviert den erweiterten Schutz nicht standardmäßig. Informationen zum Aktivieren von 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

SQL Server 2008 R2 Reporting Services unterstützt und erzwingt erweiterten Schutz, der im Betriebssystem aktiviert wurde. Wenn das Betriebssystem keinen erweiterten Schutz unterstützt oder die Funktion im Betriebssystem nicht aktiviert wurde, schlägt die erweiterte Schutzfunktion von Reporting Services bei der Authentifizierung fehl. Reporting Services Erweiterter Schutz erfordert auch ein SSL-Zertifikat. Weitere Informationen finden Sie unter Konfigurieren eines Berichtsservers für SSL-Verbindungen (Secure Sockets Layer)

Wichtiger HinweisWichtig

Der erweiterte Schutz wird von Reporting Services standardmäßig nicht aktiviert. Die Funktion kann durch Ändern der Konfigurationsdatei rsreportserver.config oder Aktualisieren der Konfigurationsdatei mithilfe von WMI-APIs aktiviert werden. SQL Server 2008 R2 Reporting Services 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 erweiterte Schutzkonfiguration und Kompatibilität führen zu Authentifizierungsfehlern und Fehlern in den Reporting Services-Ablaufverfolgungsprotokollen. Informationen zur Problembehandlung und das Überprüfen des erweiterten Schutzes mit Reporting Services finden Sie unter Problembehandlung des erweiterten Schutzes (Reporting Services).

Wichtiger HinweisWichtig

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.

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, der erweiterten Schutz unterstützt, verwendet.

Upgrade

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

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

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

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

  • SQL Server 2008 R2 Upgrade Advisor überprüft nicht, ob das Betriebssystem oder die aktuelle Installation von Reporting Services die erweiterte Schutzunterstützung aktiviert hat.

Was der erweiterte Schutz der Reporting Services nicht abdeckt

Die folgenden Funktionsbereiche und die Szenarien werden von der erweiterten Reporting Services-Schutzfunktion nicht unterstützt:

  • Autoren von benutzerdefinierten Reporting Services-Sicherheitserweiterungen müssen ihrer benutzerdefinierten Sicherheitserweiterung Unterstützung für erweiterten Schutz hinzufügen.

  • Komponenten von Drittanbietern, die einer Reporting Services-Installation hinzugefügt oder von ihr verwendet werden, müssen vom Drittanbieter aktualisiert werden, um erweiterten Schutz zu unterstützen. Weitere Informationen erhalten Sie vom Drittanbieter.

Bereitstellungsszenarios und -empfehlungen

Die folgenden Szenarien veranschaulichen verschiedene Bereitstellungen und Topologien und die empfohlene Konfiguration, um sie mit erweitertem Reporting Services Schutz zu sichern.

Direkt

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

Szenario

Szenariodiagramm

So sichern Sie

direkte SSL-Kommunikation.

Der Berichtsserver erzwingt die Kanalbindung zwischen Client und Berichtsserver.

 Erweiterter Schutz und direkter Zugriff mit SSL

1) Clientanwendung

2) Berichtsserver

  • Dienstbindung ist nicht notwendig, da der SSL-Kanal für Kanalbindung verwendet wird.

Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Legen Sie RSWindowsExtendedProtectionScenario auf Direct fest.

direkte HTTP-Kommunikation. Der Berichtsserver erzwingt die Dienstbindung zwischen Client und Berichtsserver.

 Erweiterter Schutz und direkter Zugriff

1) Clientanwendung

2) Berichtsserver

  • Es gibt keinen SSL-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.

Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Legen Sie RSWindowsExtendedProtectionScenario auf Any fest.

Proxy und Netzwerklastenausgleich

Clientanwendungen stellen eine Verbindung mit einem Gerät oder einer Software her, die SSL 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

Szenariodiagramm

So sichern Sie

HTTP-Kommunikation. Der Berichtsserver erzwingt die Dienstbindung zwischen Client und Berichtsserver.

 Erweiterter RS-Schutz und indirekter Zugriff

1) Clientanwendung

2) Berichtsserver

3) Proxy

  • Es gibt keinen SSL-Kanal. Daher ist keine Erzwingung der Kanalbindung möglich.

Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Legen Sie RSWindowsExtendedProtectionScenario auf Any fest.

  • 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.

 Erweiterter RS-Schutz und indirekter Zugriff mit SSL

1) Clientanwendung

2) Berichtsserver

3) Proxy

  • SSL-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.

RSWindowsExtendedProtectionLevel oder Allow in Require

Legen Sie RSWindowsExtendedProtectionScenario auf Proxy fest.

Indirekte HTTPS-Kommunikation mit einem sicheren Proxy. Der Berichtsserver erzwingt die Kanalbindung zwischen Client und Proxy sowie die Dienstbindung zwischen Client und Berichtsserver.

 Erweiterter Schutz und indirekter Zugriff mit SSL und HTTPS

1) Clientanwendung

2) Berichtsserver

3) Proxy

  • SSL-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.

RSWindowsExtendedProtectionLevel oder Allow in Require

Legen Sie RSWindowsExtendedProtectionScenario auf Proxy fest.

Gateway

Dieses Szenario beschreibt Clientanwendungen, die eine Verbindung mit einem Gerät oder einer Software herstellen, die SSL 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

Szenariodiagramm

So sichern Sie

indirekte HTTP-Kommunikation.

Gateway erzwingt die Kanalbindung vom Client zum Gateway. Es gibt eine Dienstbindung vom Gateway zum Berichtsserver.

 Erweiterter RS-Schutz und indirekter Zugriff mit SSL

1) Clientanwendung

2) Berichtsserver

3) Gatewaygerät

  • 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 SSL vom Gateway zum Berichtsserver, daher kann die Kanalbindung nicht erzwungen werden.

  • Dienstbindung kann erzwungen werden.

Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Legen Sie RSWindowsExtendedProtectionScenario auf Any fest.

  • Das Gatewaygerät sollte vom Administrator so konfiguriert werden, 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.

 Erweiterter Schutz und indirekter Zugriff mit SSL und HTTPS

1) Clientanwendung

2) Berichtsserver

3) Gatewaygerät

  • 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.

  • SSL vom Gateway zum Berichtsserver bedeutet, dass Kanalbindung erzwungen werden kann.

  • Dienstbindung ist nicht erforderlich.

Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Legen Sie RSWindowsExtendedProtectionScenario auf Direct fest.

  • Das Gatewaygerät sollte vom Administrator so konfiguriert werden, dass Kanalbindung erzwungen wird.

Kombination

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

Szenario

Szenariodiagramm

So sichern Sie

Indirekter und direkter Zugriff vom Client auf den Berichtsserverdienst ohne SSL auf keiner der Verbindungen vom Client zum Proxy und vom Client zum Berichtsserver.

 Erweiterter Schutz in gemischter Umgebung

1) Clientanwendung

2) Berichtsserver

3) Proxy

4) Clientanwendung

  • 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.

Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Legen Sie RSWindowsExtendedProtectionScenario auf Any fest.

Indirekter und direkter Zugriff vom Client auf den Berichtsserver, wo der Client eine SSL-Verbindung zum Proxy oder dem Berichtsserver herstellt.

 Erweiterter Schutz mit SSL

1) Clientanwendung

2) Berichtsserver

3) Proxy

4) Clientanwendung

  • 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.

Legen Sie RSWindowsExtendedProtectionLevel auf Allow oder Require fest.

Legen Sie RSWindowsExtendedProtectionScenario auf Proxy fest.

Konfigurieren des erweiterten Schutzes für Reporting Services

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

Weitere Informationen zum Verwenden und Bearbeiten der Datei rsreportserver.config finden Sie unter RSReportServer-Konfigurationsdatei. Die erweiterten Schutzeinstellungen können auch geändert und mithilfe von WMI-APIs überprüft werden. Weitere Informationen finden Sie unter SetExtendedProtectionSettings-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 der 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, Allow und Require.

Der Standardwert lautet Off.

Der Wert Off gibt keine Kanal- oder Dienstbindungsüberprüfung an.

Der Wert Allow unterstützt erweiterten Schutz, erfordert ihn aber nicht. Der Wert "Zulassen" 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.

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

Der Wert Require gibt Folgendes an:

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

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

RsWindowsExtendedProtectionScenario

Gibt an, welche Arten des erweiterten Schutzes überprüft werden: Kanalbindung, Dienstbindung oder beide. Gültige Werte sind Any, Proxy und Direct.

Der Standardwert lautet Proxy.

Der Wert Any gibt Folgendes an:

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

  • Dienstbindung wird erzwungen.

Der Wert Proxy gibt Folgendes an:

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

  • Dienstbindung wird erzwungen.

Der Wert Direct gibt Folgendes an:

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

  • Dienstbindung wird nicht erzwungen.

HinweisHinweis
Diese Einstellung 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

Dienstbindung überprüft das beabsichtigte Ziel von Authentifizierungstoken mithilfe von Dienstprinzipalnamen oder SPN. Reporting Services erstellt mithilfe der vorhandenen URL-Reservierungsinformationen eine Liste von SPNs, die als gültig angesehen werden. Das Verwenden der URL-Reservierungsinformationen zur Überprüfung von SPN- und URL-Reservierungen ermöglicht es Systemadministratoren, beide von einem einzelnen Speicherort aus zu verwalten.

Die Liste der gültigen SPNs wird aktualisiert, wenn der Berichtsserver startet, die Konfigurationseinstellungen für erweiterten Schutz geändert werden oder wenn die Anwendungsdomäne wiederverwendet wird.

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 Liste der gültigen SPNs, die für eine Anwendung berechnet wurde, wird von den folgenden Faktoren bestimmt:

  • Jede URL-Reservierung.

  • Jeder SPN, der vom Domänencontroller für das Reporting Services-Dienstkonto 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 und verwendet die 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 und verwendet die 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, wird der NetBIOS-Name des lokalen Computers verwendet, nicht der Name des virtuellen Clusterservers.

Wenn SPNs hinzugefügt werden, wird dem Ablaufverfolgungsprotokoll, das etwa folgendermaßen aussieht, ein Eintrag hinzugefügt:

rshost!rshost!10a8!01/07/2010-19:29:38:: i INFO: SPN Whitelist Added <ComputernamePhysischerNetBIOS> - <DerServername>.

rshost!rshost!10a8!01/07/2010-19:29:38:: i INFO: SPN Whitelist Added <ComputernamePhysischerDNSHostname> - <DerServername>.

Weitere Informationen finden Sie unter Vorgehensweise: Registrieren eines Dienstprinzipalnamens (SPN) für einen Berichtsserver und Informationen zu Registrierungen und Reservierungen für URLs (Reporting Services).