Share via


Readme_Sicherheitserweiterungsbeispiel

Dieses Beispiel funktioniert nur mit SQL Server 2005 und SQL Server 2008. In einer SQL Server-Version vor SQL Server 2005 kann das Beispiel nicht ausgeführt werden.

Das CustomSecurity-Sicherheitserweiterungsbeispiel verwendet die Formularauthentifizierung zusammen mit SQL Server, um ein benutzerdefiniertes Sicherheitsmodell bereitzustellen, das mit Reporting Services zusammenarbeitet. Dieses Beispiel wird nicht auf Itanium-basierten Betriebssystemen unterstützt.

ms160724.security(de-de,SQL.100).gifSicherheitshinweis:
Das Sicherheitserweiterungsbeispiel sollte nicht in einer Produktionsumgebung bereitgestellt und getestet werden. Es ist in der Regel nicht empfehlenswert, nach der Migration auf eine andere Sicherheitserweiterung zur Windows-Authentifizierung zurückzukehren. Wenn Sie sich dennoch für diesen Schritt entscheiden, können bei dem Versuch, auf Elemente in der Berichtsserver-Datenbank zuzugreifen, die über benutzerdefinierte Sicherheitsbeschreibungen, jedoch über keine Sicherheitsbeschreibungen der Windows-Authentifizierung verfügen, Fehler auftreten. Um zur Windows-Authentifizierung zurückzukehren, müssen Sie Reporting Services neu installieren und manuell die rollenbasierte Sicherheit erneut anwenden. Sie sollten vor Verwenden dieses Beispiels Ihre Konfigurationsdateien sichern.

Wichtig

Die Beispiele dienen nur zu Lernzwecken. Sie sind nicht für den Einsatz in einer Produktionsumgebung gedacht und wurden auch nicht in einer Produktionsumgebung getestet. Microsoft leistet keinen technischen Support für diese Beispiele. Beispielanwendungen und Assemblys sollten nicht ohne die Zustimmung des Systemadministrators mit der SQL Server-Datenbank oder dem Berichtsserver verbunden sein oder verwendet werden. Die Beispiele dienen nur zu Lernzwecken. Sie sind nicht für den Einsatz in einer Produktionsumgebung gedacht und wurden auch nicht in einer Produktionsumgebung getestet. Microsoft leistet keinen technischen Support für diese Beispiele. Beispielanwendungen und Assemblys sollten nicht ohne die Zustimmung des Systemadministrators mit der SQL Server-Datenbank oder dem Berichtsserver verbunden sein oder verwendet werden. Microsoft bietet für diese Beispiele keinen technischen Support. Beispielanwendungen und Assemblys sollten nicht ohne die Zustimmung des Systemadministrators mit der SQL Server-Produktionsdatenbank oder dem Berichtsserver verbunden oder verwendet werden.

Anforderungen

Damit Sie das CustomSecurity-Beispiel ausführen können, sollten Sie mit Visual Studio und entweder Visual C# oder Visual Basic vertraut sein. Außerdem müssen die folgenden Anwendungen installiert sein:

  • Microsoft Visual Studio 2005 oder eine kompatible Entwicklungsumgebung (zum Anzeigen der Projektdateien).
  • Microsoft .NET Framework 2.0.
  • SQL Server, einschließlich Reporting Services.
  • Reporting Services-Beispiele.
  • Ein Berichtsserver, für den Sie in Ihrem Netzwerk die Zugriffsberechtigung haben, falls Sie mit der Beispielerweiterung zusätzliche Datenverarbeitungsfunktionen zu Ihrem Server hinzufügen möchten.

Wichtig

SQL Server-Beispiele und -Beispieldatenbanken müssen heruntergeladen und installiert werden, bevor Sie sie anzeigen oder mit ihnen arbeiten können. Weitere Informationen finden Sie unter Überlegungen zum Installieren der SQL Server-Beispiele und -Beispieldatenbanken.

Speicherort

Dieses Beispiel befindet sich standardmäßig an folgendem Speicherort:

C:\Programme\Microsoft SQL Server\100\Samples\Reporting Services\ Extension Samples\FormsAuthentication Sample

Erstellen des Beispiels

Sie müssen zuerst die Erweiterung kompilieren und und installieren. Bei dem Verfahren wird davon ausgegangen, dass Sie Reporting Services im Standardspeicherort C:\Programme\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services installiert haben. Auf diesen Speicherort wird in den restlichen Abschnitten dieses Themas mit <install> verwiesen.

Generieren Sie die Schlüsseldatei mithilfe der folgenden Anweisungen, falls Sie noch keine Schlüsseldatei mit starkem Namen erstellt haben.

So generieren Sie eine Schlüsseldatei mit starkem Namen

  1. Öffnen Sie eine Microsoft Visual Studio 2005-Eingabeaufforderung. Klicken Sie auf Start, zeigen Sie auf Alle Programme und danach auf Microsoft .NET Framework SDK 2.0, und klicken Sie dann auf SDK-Eingabeaufforderung.

    – oder –

    Öffnen Sie eine Microsoft .NET Framework-Eingabeaufforderung. Klicken Sie auf Start, zeigen Sie auf Alle Programme und dann auf Microsoft .NET Framework SDK 2.0, und klicken Sie anschließend auf SDK-Eingabeaufforderung.

  2. Wechseln Sie an der Eingabeaufforderung mit dem Befehl CD (Verzeichnis wechseln) vom aktuellen Verzeichnis im Eingabeaufforderungsfenster zu dem Ordner, in dem die Beispiele installiert werden.

    Hinweis

    Klicken Sie auf Start, zeigen Sie auf Alle Programme, Microsoft SQL Server und auf Dokumentation und Lernprogramme, und klicken Sie dann auf Beispielordner, um den Ordner zu ermitteln, in dem sich die Beispiele befinden. Wenn das Standardverzeichnis verwendet wurde, befinden sich die Beispiele im Verzeichnis <system_drive>:\Programme\Microsoft SQL Server\100\Samples.

  3. Führen Sie an der Eingabeaufforderung den folgenden Befehl zum Generieren der Schlüsseldatei aus:

    sn -k SampleKey.snk

    Wichtig

    Weitere Informationen zum Schlüsselpaar mit starkem Namen finden Sie unter "Security Briefs: Starke Namen und Sicherheit im .NET Framework" unter .NET-Entwicklung von MSDN.

So kompilieren Sie das Beispiel mit Visual Studio 2005

  1. Öffnen Sie CustomSecurity.sln in Microsoft Visual Studio 2005. Wenn Sie das Beispiel am Standardspeicherort installiert haben, können Sie unter C:\Programme\Microsoft SQL Server\100\Samples\Reporting Services\Extensions darauf zugreifen.

  2. Wählen Sie im Projektmappen-Explorer das Projekt CustomSecurity aus.

  3. Klicken Sie im Menü Projekt auf Verweis hinzufügen.

    Das Dialogfeld Verweis hinzufügen wird geöffnet.

  4. Klicken Sie auf die Registerkarte .NET.

  5. Klicken Sie auf Durchsuchen, und suchen Sie auf dem lokalen Laufwerk nach Microsoft.ReportingServices.Interfaces. Standardmäßig befindet sich die Assembly im Verzeichnis <install>\ReportServer\bin. Klicken Sie auf OK.

    Der ausgewählte Verweis wird dem Projekt hinzugefügt.

    Hinweis

    Der Verweis wurde dem Projekt möglicherweise bereits hinzugefügt. In diesem Fall muss ein Verweis nicht erneut hinzugefügt werden.

  6. Klicken Sie im Menü Erstellen auf Projektmappe erstellen.

Bereitstellen des Beispiels

Nachdem Sie das Beispiel kompiliert haben, müssen Sie die DLLs und die ASPX-Seiten in die entsprechenden Unterverzeichnisse Ihrer Berichtsserverinstallation kopieren.

So stellen Sie das Beispiel bereit

  1. Kopieren Sie Microsoft.Samples.ReportingServices.CustomSecurity.dll und Microsoft.Samples.ReportingServices.CustomSecurity.pdb in das Verzeichnis <install>\ReportServer\bin.

  2. Kopieren Sie Microsoft.Samples.ReportingServices.CustomSecurity.dll und Microsoft.Samples.ReportingServices.CustomSecurity.pdb in das Verzeichnis <install>\ReportManager\bin.

  3. Kopieren Sie die Seite Logon.aspx in das Verzeichnis <install>\ReportServer.

  4. Kopieren Sie die Seite UILogon.aspx in das Verzeichnis <install>\ReportManager\Pages.

Nachdem die Assembly und die Anmeldeseiten auf den Server kopiert wurden, müssen Sie einige Änderungen an der Konfigurationsdatei für den Berichtsserver vornehmen.

Wichtig

Erstellen Sie Sicherungskopien von allen Konfigurationsdateien, bevor Sie Änderungen vornehmen.

So ändern Sie die Datei RSReportServer.config

  1. Öffnen Sie die Datei RSReportServer.config in Visual Studio 2005 oder in einem einfachen Text-Editor wie dem Windows-Editor. RSReportServer.config befindet sich im Verzeichnis <install>\ReportServer.

  2. Suchen Sie das <AuthenticationTypes>-Element, und ändern Sie die Einstellungen wie folgt:

    <Authentication>
    <AuthenticationTypes>
    <Custom/>
    </AuthenticationTypes>
    <EnableAuthPersistence>true</EnableAuthPersistence>
    </Authentication>
    
  3. Suchen Sie das <Security>-Element und das <Authentication>-Element im <Extensions>-Element, und ändern Sie die Einstellungen wie folgt:

    <Security>
       <Extension Name="Forms" 
    Type="Microsoft.Samples.ReportingServices.CustomSecurity.Authorization, 
    Microsoft.Samples.ReportingServices.CustomSecurity" >
          <Configuration>
             <AdminConfiguration>
                <UserName>username</UserName>
             </AdminConfiguration>
          </Configuration>
       </Extension>
    </Security>
    <Authentication>
       <Extension Name="Forms" 
    Type="Microsoft.Samples.ReportingServices.CustomSecurity.AuthenticationExtension,
     Microsoft.Samples.ReportingServices.CustomSecurity" />
    </Authentication>
    

    Weitere Informationen zur .NET Framework-Sicherheit und zu Reporting Services finden Sie unter Sichere Entwicklung (Reporting Services).

  4. Suchen Sie nach dem Element <UI>, und aktualisieren Sie es wie folgt:

    <UI>
       <CustomAuthenticationUI>
          <loginUrl>/Pages/UILogon.aspx</loginUrl>
             <UseSSL>True</UseSSL>
       </CustomAuthenticationUI>
       <ReportServerUrl>http://<server>/ReportServer</ReportServerUrl>
    </UI>
    

Hinweis

Wenn Sie das Sicherheitserweiterungsbeispiel in einer Entwicklungsumgebung ausführen, in der kein SSL-Zertifikat (Secure Sockets Layer) installiert ist, müssen Sie den Wert des <UseSSL>-Elements im vorhergehenden Konfigurationseintrag in False ändern. Es empfiehlt sich, immer SSL zu verwenden, wenn Reporting Services und Formularauthentifizierung kombiniert verwendet werden.

Sie müssen eine Codegruppe für Ihre benutzerdefinierte Sicherheitserweiterung hinzufügen, die die FullTrust-Berechtigung für Ihre Erweiterung erteilt. Hierzu fügen Sie der Datei RSSrvPolicy.config die Codegruppe hinzu.

So ändern Sie die Datei RSSrvPolicy.config

  1. Öffnen Sie die Datei RSSrvPolicy.config, die sich im Verzeichnis <install>\ReportServer befindet.

  2. Fügen Sie das folgende <CodeGroup>-Element nach der vorhandenen Codegruppe in der Sicherheitsrichtliniendatei mit einer URL-Mitgliedschaft $CodeGen hinzu, wie nachfolgend beschrieben, und fügen Sie dann der Datei RSSrvPolicy.config einen Eintrag wie folgt hinzu:

    <CodeGroup
       class="UnionCodeGroup"
       version="1"
       Name="SecurityExtensionCodeGroup"
       Description="Code group for the sample security extension"
       PermissionSetName="FullTrust">
       <IMembershipCondition 
          class="UrlMembershipCondition"
          version="1"
          Url="C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Samples.ReportingServices.CustomSecurity.dll"
       />
    </CodeGroup>
    

Hinweis

Aus Gründen der Übersichtlichkeit weist das Formularauthentifizierungsbeispiel einen schwachen Namen auf und erfordert einen einfachen URL-Mitgliedschaftseintrag in den Sicherheitsrichtliniendateien. In den Sicherheitserweiterungsimplementierungen für Ihre Produktionsumgebung sollten Sie Assemblys mit starken Namen erstellen und beim Hinzufügen von Sicherheitsrichtlinien für Ihre Assembly die Mitgliedschaftsbedingung für starke Namen verwenden. Weitere Informationen zu Assemblys mit starken Namen finden Sie unter Creating and Using Strong-Named Assemblies (in Englisch) auf der MSDN-Website.

Als Nächstes müssen Sie die Berechtigungen für die Codegruppe "Arbeitsplatz" in der Richtliniendatei für den Berichts-Manager erweitern.

So ändern Sie die Datei RSMgrPolicy.config

  1. Öffnen Sie die Richtliniendatei für den Berichts-Manager (RSMgrPolicy.config), die sich im Verzeichnis <install>\ReportManager befindet.

  2. Suchen Sie nach der folgenden Codegruppe in der Datei RSMgrPolicy.config, und ändern Sie das PermissionSetName-Attribut wie folgt von Execution in FullTrust:

    <CodeGroup 
            class="FirstMatchCodeGroup" 
            version="1" 
            PermissionSetName="FullTrust"
            Description="This code group grants MyComputer code Execution 
    permission. ">
        <IMembershipCondition 
                class="ZoneMembershipCondition"
                version="1"
                Zone="MyComputer" />
    

Um die Formularauthentifizierung zu verwenden, müssen Sie die Web.config-Dateien für den Berichts-Manager und den Berichtsserver ändern.

So ändern Sie die Datei Web.config für den Berichtsserver

  1. Öffnen Sie die Datei Web.config in einem Text-Editor. Standardmäßig befindet sich die Datei im Verzeichnis <install>\ReportServer\bin.

  2. Suchen Sie nach dem Element <identity>, und legen Sie das Impersonate-Attribut auf false fest.

    <identity impersonate="false" />
    
  3. Suchen Sie nach dem Element <authentication>, und ändern Sie das Mode-Attribut in Forms.

  4. Fügen Sie das folgende <forms>-Element als untergeordnetes Element des <authentication>-Elements hinzu, und legen Sie die Attribute loginUrl, name, timeout und path wie folgt fest:

    <authentication mode="Forms">
       <forms loginUrl="logon.aspx" name="sqlAuthCookie" timeout="60" 
                   path="/"></forms>
       </authentication>
    
  5. Fügen Sie das folgende <authorization>-Element direkt hinter dem <authentication>-Element ein.

    <authorization> 
       <deny users="?" />
    </authorization>
    

    Damit wird nicht authentifizierten Benutzern das Zugriffsrecht für den Berichtsserver verweigert. Das zuvor konfigurierte loginUrl-Attribut des Elements <authentication> leitet nicht authentifizierte Anforderungen auf die Seite Logon.aspx um.

So ändern Sie die Datei Web.config für den Berichts-Manager

  1. Öffnen Sie die Datei Web.config für den Berichts-Manager. Sie befindet sich im Verzeichnis <install>\ReportManager.

  2. Deaktivieren Sie den Identitätswechsel, indem Sie nach dem Abschnitt <identity impersonate= "true" /> suchen und ihn in <identity impersonate="false" /> ändern.

  3. Fügen Sie dem <appSettings>-Element die folgenden Schlüssel hinzu:

    <add key="ReportServer" value="<Server Name>"/>
    <add key="ReportServerInstance" value="<Instance Name>"/>
    
  4. Ändern Sie den Wert von <Server Name> in den Namen des Berichtsservers und den Wert von <Instance Name> in den Namen der Instanz, der der Berichtsserver zugeordnet ist.

Erstellen der UserAccounts-Datenbank

Das Beispiel enthält das Datenbankskript Createuserstore.sql. Mit diesem Skript können Sie einen Benutzerspeicher für das Forms-Beispiel in einer SQL Server-Datenbank einrichten.

So erstellen Sie die UserAccounts-Datenbank

  1. Öffnen Sie SQL Server Management Studio, und stellen Sie dann eine Verbindung mit der lokalen Instanz von SQL Server her.

  2. Suchen Sie nach der SQL-Skriptdatei Createuserstore.sql. Die Skriptdatei befindet sich in den Beispielprojektdateien.

  3. Führen Sie die Abfrage aus, um die UserAccounts-Datenbank zu erstellen.

  4. Beenden Sie SQL Server Management Studio.

Testen des Beispiels

Mit der folgenden Prozedur wird die Beispielerweiterung getestet. Sie registrieren einen Benutzer mit Administratorrechten, wodurch der Benutzername, der Kennworthash und der Saltwert zur users-Tabelle der UserAccounts-Datenbank hinzugefügt wird. Als Teil dieser Prozedur müssen Sie außerdem diesen Benutzernamen in die Konfigurationsdatei für den Berichtsserver eingeben. Anschließend melden Sie diesen Benutzer an, um sicherzustellen, dass die Kennwortüberprüfung richtig abläuft und dass die Erweiterungsassembly vom Berichtsserver ordnungsgemäß geladen wird.

So testen Sie das Beispiel

  1. Starten Sie den Reporting Services-Dienst neu, indem Sie die folgenden Befehle an der Eingabeaufforderung ausführen:

    net stop "SQL Server Reporting Services (<Instance Name>)"
    net start "SQL Server Reporting Services (<Instance Name>)"
    
  2. Öffnen Sie den Berichts-Manager. Verwenden Sie hierfür entweder das Reporting Services-Programmmenü, oder greifen Sie von Ihrem Browser aus auf das virtuelle Verzeichnis Reports zu.

  3. Geben Sie einen Benutzernamen und ein Kennwort ein, und klicken Sie auf Benutzer registrieren, um den Benutzer der accounts-Datenbank hinzuzufügen.

  4. Öffnen Sie die Datei RSReportServer.config. Suchen Sie nach dem Element <Security>, und fügen Sie den zuvor registrierten Benutzernamen wie folgt hinzu:

    <Security>
       <Extension Name="Forms" 
    Type="Microsoft.Samples.ReportingServices.CustomSecurity.Authorization, 
    Microsoft.Samples.ReportingServices.CustomSecurity" >
          <Configuration>
             <AdminConfiguration>
                <UserName>username</UserName>
             </AdminConfiguration>
          </Configuration>
       </Extension>
    </Security>
    
  5. Kehren Sie zur Seite UILogon.aspx zurück, geben Sie erneut Benutzername und Kennwort ein, und klicken Sie dann auf Anmelden.

Sie sollten ohne Einschränkungen auf den Berichts-Manager und den Berichtsserver zugreifen können. Der von Ihnen als Administrator erstellte Benutzer besitzt Berechtigungen für den Berichtsserver, die denjenigen eines integrierten Administratorkontos auf dem lokalen Computer entsprechen. Im Rahmen dieses Beispiels können Sie nur einen Benutzer als Administrator ausweisen. Sobald Sie über ein integriertes Administratorkonto verfügen, können Sie zusätzliche Benutzer registrieren und ihnen Rollen auf dem Berichtsserver zuweisen.

Hinweis

Sie sollten Ihren Administratorbenutzer den offiziellen Systemadministrator- und Inhalts-Manager-Rollen (Stammordner) Ihres Berichtsservers hinzufügen. Damit beugen Sie der Entstehung von leeren Sicherheitsbeschreibungen in der Berichtsserver-Datenbank vor. Weitere Informationen zu den Rollen Systemadministrator und Inhalts-Manager finden Sie unter Verwenden vordefinierter Rollen.

Verwenden des Webdiensts mit benutzerdefinierter Sicherheit

Sie können die Webdienst-Anwendungsprogrammierschnittstelle (API, Application Programming Interface) mit der Formularauthentifizierung genauso verwenden wie mit der Windows-Authentifizierung. Sie müssen jedoch LogonUser in Ihrem Webdienstcode aufrufen und die Anmeldeinformationen an den aktuellen Benutzer übergeben. Darüber hinaus kann Ihr Webdienstclient nicht die automatische Cookieverwaltung nutzen, die von Internet Explorer oder anderen Webbrowsern bereitgestellt wird. Sie müssen die Proxyklasse von ReportingService2005 um die Cookieverwaltung erweitern. Sie können dies tun, indem Sie die GetWebRequest- und GetWebResponse-Methoden der Webdienstklasse überschreiben.

Debuggen der Beispielerweiterung

Das Ausführen der Beispielerweiterung im Debugger ist nicht nur eine gute Methode, mögliche Probleme zu lösen, sondern auch ein effizientes Verfahren, um den Code schrittweise durchzugehen und den Authentifizierungs- und Überprüfungsvorgangs für den Berichtsserver während seiner Verarbeitung zu verfolgen.

Microsoft .NET Framework stellt mehrere hilfreiche Tools zum Debuggen zur Verfügung, die Sie bei der Analyse des Beispielcodes unterstützen. In dem folgenden Verfahren wird das vorhergehende Beispiel mithilfe von Visual Studio 2005 gedebuggt.

So debuggen Sie den Beispielcode für die Formularauthentifizierung

  1. Starten Sie Visual Studio, und öffnen Sie CustomSecurity.sln auf Ihrem Testberichtserver.

  2. Öffnen Sie Internet Explorer, und navigieren Sie zum Berichts-Manager, ohne den Beispielcode in Visual Studio zu schließen.

  3. Wechseln Sie zu Visual Studio, und fügen Sie einige Haltepunkte in den Projektcode der benutzerdefinierten Sicherheitserweiterung ein.

  4. Behalten Sie das Fenster des Erweiterungsprojekts als aktives Fenster bei, und klicken Sie im Menü Debuggen auf Verarbeiten.

    Das Dialogfeld Prozesse wird geöffnet.

  5. Wählen Sie aus der Liste der Prozesse den Prozess Aspnet_wp.exe aus (oder W3wp.exe, wenn Ihre Anwendung auf IIS 6.0 bereitgestellt wird), und klicken Sie auf Anfügen.

  6. Wählen Sie im Dialogfeld An den Prozess anhängen den Programmtyp Common Language Runtime aus, und klicken Sie dann auf OK. Stellen Sie zur Verbesserung der Debugging-Leistung sicher, dass Systemeigenes Format nicht als Programmtyp ausgewählt ist.

  7. Beim Ausführen des Beispiels wird ein Anmeldeformular geöffnet. Geben Sie die Benutzeranmeldeinformationen in das Anmeldeformular ein, und klicken Sie auf die Schaltfläche Anmelden.

    Sobald beim Verarbeiten Ihre Haltepunkte erreicht werden, sollte der Debugger die Ausführung an dem entsprechenden Punkt beenden.

  8. Gehen Sie den Code schrittweise mit der F11-Taste durch. Weitere Informationen zum Debuggen mit Visual Studio finden Sie in der Dokumentation zu Visual Studio 2005.

Hinweis

Dieses Debugging-Verfahren ist mit einem beträchtlichen Aufwand an Ressourcen und Prozessorzeit verbunden. Wenn Probleme auftreten, müssen Sie Visual Studio schließen und IIS zurücksetzen. Führen Sie anschließend den Vorgang erneut aus, indem Sie die CustomSecurity-Projektmappe an den ASP.NET-Arbeitsprozess anfügen und sich beim Berichts-Manager anmelden.

Entfernen der Beispielerweiterung

Obwohl i. A. nicht zu empfehlen, lässt sich die Windows-Authentifizierung wiederherstellen, nachdem Sie das Beispiel getestet haben.

So kehren Sie zur Windows-Sicherheit zurück

  1. Stellen Sie aus den Sicherungskopien die folgenden Dateien wieder her: Web.config und RSReportServer.config. Damit sollten die Authentifizierungs- und Autorisierungsmethode für den Berichtsserver auf die Windows-Standardsicherheit zurückgesetzt werden. Damit sollten auch alle Einträge entfernt werden, die Sie für Ihre Erweiterung in der Konfigurationsdatei für den Berichtsserver eingefügt haben.

  2. Deaktivieren Sie den anonymen Zugriff in den Internetinformationsdiensten (IIS) für das virtuelle Verzeichnis des Berichtsservers.

Nachdem Sie die Konfigurationsinformationen entfernt haben, steht Ihre Sicherheitserweiterung nicht mehr auf dem Berichtsserver zur Verfügung. Normalerweise müssen Sie keine Sicherheitsbeschreibungen entfernen, die während der Ausführung des Berichtsservers unter der Beispielsicherheitserweiterung erstellt wurden. Wenn die Windows-Authentifizierung aktiviert ist, weist der Berichtsserver die Rolle Systemadministrator automatisch der Gruppe BUILTIN\Administrators auf dem Computer zu, der den Berichtsserver hostet. Sie müssen dann jedoch manuell die rollenbasierte Sicherheit für Ihre Windows-Benutzer erneut anwenden.

Beachten Sie, dass das Zurückkehren zur Windows-Authentifizierung nach der Migration auf eine andere Sicherheitserweiterung in der Regel nicht empfehlenswert ist. Wenn Sie sich dennoch für diesen Schritt entscheiden, können bei dem Versuch, auf Elemente in der Berichtsserver-Datenbank zuzugreifen, die über benutzerdefinierte Sicherheitsbeschreibungen, jedoch über keine Sicherheitsbeschreibungen der Windows-Authentifizierung verfügen, Fehler auftreten.

Siehe auch

Tasks

Reporting Services-Beispiele

Andere Ressourcen

Erweiterungsbeispiele (Reporting Services)
Implementieren von Sicherheitserweiterungen

Hilfe und Informationen

Informationsquellen für SQL Server 2008