Oftmals ist es notwendig, dass Cube-Nutzer nur die für sie relevanten Daten sehen dürfen und nicht die Daten anderer Nutzer. In der Regel bietet es sich dafür an, den Benutzernamen aus der Windows-Anmeldung dynamisch zu übernehmen und auch für den Cube-Zugriff zu nutzen. Als Frontend für den Cube-Zugriff wird oftmals MS Excel verwandt, welches dabei allerdings unerwartete Probleme mit sich bringt. Dieser Beitrag schildert die einzelnen Vorgehensschritte zur Umsetzung einer dynamischen Security anhand des Microsoft Beispielprojekts Adventure Works (AW), welches im MS SQL Server 2005 standardmäßig mitgeliefert wird und unter …\Microsoft SQL Server\90\Tools\Samples\AdventureWorks Analysis Services Project\Standard zu finden ist.

Vorgehensschritte am Beispiel Adventure Works

Voraussetzung zur Erprobung der dynamischen Security ist ein Windows-Benutzername (Domäne\Name) und ein äquivalenter Namenseintrag  in der betreffenden Dimension. Dafür wird im Folgenden eine zusätzliche Spalte RealAccount in der DIM Employee erzeugt (VPCPLAYIMAGE\Benutzername), welche den Benutzernamen enthalten soll. Der Name ergibt sich hierbei aus der E-Mailadresse (aus AW) und muss dem Windows-Anmeldenamen entsprechen.

MS Visual Studio à AdventureWorks à AdventureWorks.dsv à DimEmployee (Kontextmenü)à benannte Abfrage ändern: SELECT ergänzen um Spalte:

‘VPCPLAYIMAGE\’ + LEFT(EmailAddress,PATINDEX(‘%@%’, EmailAddress) – 1) AS RealAccount

In Windows soll nun der Beispielnutzer VPCPLAYIMAGE\amy0 angelegt werden, welcher auch in AW zu finden ist (Windows Computerverwaltung).

Im nächsten Schritt soll eine neue Rolle namens DynamicEmployees angelegt werden, in welcher für den neuen RealAccount Attributsicherheit definiert wird.

Rollen(Kontextmenü) à Neue Rolle: DynamicEmployees à Reiter: Mitgliedschaften à amy0 hinzufügen

Im ersten Schritt soll die Attributsicherheit durch das dynamische Eintragen des Benutzernamens mittels der Username-Funktion als zulässige Elementgruppe wie folgt realisiert werden:

Rolle: DynamicEmployeeà Reiter: Dimensionsdaten à Dimension: AdventureWorks DW.Employee à Attributhierarchie: RealAccount à Reiter: Erweitertà Zulässige Elementgruppe

STRTOSET(“{[Employee].[Real Account].&[" + UserName() + "]}”)

Eine mögliche Erweiterung des vorigen Statements durch einen UnknownUser ist empfohlen, um bei Nichterkennen des Benutzernamens aus Sicherheitsgründen einen Nutzer ohne Rechte zu haben. Dieser Nutzer muss dementsprechend zuvor auch in AW angelegt werden (VPCPLAYIMAGE\UnknownUser). Die zugehörige Erweiterung lautet:

IIF(FILTER([Employee].[Real Account].MEMBERS,[Employee].[Real Account].MEMBER_NAME UCASE(UserName())).COUNT=0,STRTOMEMBER(“[Employee].[Real Account]. &[VPCPLAYIMAGE\UnknownUser]“),STRTOMEMBER(“[Employee].[Real Account].[" + UserName() + "]“))

Bei Verwendung des MS SQL-Management Studios oder des MS Analysis Services internen Browsers wird nun bei Anmeldung durch einen Testnutzer (hier:  VPCPLAYIMAGE\amy0) wie gewünscht der Nutzername und die Daten wie bspw. der Reseller Sales Amount nur für amy0 und Personen höherer Hierarchie herausgegeben, wenngleich dieser für alle Employees abgefragt wurde.

SELECT [Measures].[Reseller Sales Amount] ON COLUMNS,[Employee].[Employee].MEMBERS ON ROWS FROM [Adventure Works]

Anpassungen bei Zugriff durch MS Excel Frontend

Beim Zugriff auf den Cube mittels Excel gibt es hingegen nun ohne die Durchführung weiterer Maßnahmen ein Zugriffsproblem auf Namensebene. Bei der MS Excel-Variante besteht kein Zugriff auf die Parents und es wird somit ein Fehler hervorgerufen. Das Problem ist, dass MS Excel sich die kompletten Properties einschließlich der Employees Parent-Child-Beziehung holt, worauf der Nutzer keinen Zugriff hat. Somit wird im Unterschied zum Zugriff ohne MS Excel standardmäßig kein Zugriff auf Employees gewährt. Die Fehlermeldung lautet: „Die Abfrage oder das Öffnen der Tabelle konnte nicht durchgeführt werden. [..]“. Um die Mitgabe der Properties zu vermeiden, kann dieses unter MS Excel wie folgt durchgeführt werden:

MS Excel à Daten: Verbindung mit Cube herstellen à Optionen: Optionen à Anzeige à Kontextbezogene Quickinfos anzeigen (nein), Eigenschaften in Quickinfos anzeigen (nein)

Somit sind die Properties ausgeschaltet und mittels MS Excel kann nun auch Zugriff auf Employees und die Daten des entsprechenden Nutzers gewährt werden.

Anhand dieser Vorgehensweise soll es möglich sein, mit einfachen Mitteln eine dynamische Security zu realisieren ohne einen gewaltigen Pflegeaufwand auf Nutzerebene hervorzurufen.

Dieser Eintrag ist für alle interessant die mit Vista als Betriebssystem arbeiten und sich an die Installation des SP1 gewagt haben.

Nach der Installation dürften sich die Nutzer folgender Ansichten im Internet Explorer erfreuen:

Abb. 1: Fehlermeldung beim Aufruf des Berichts Managers

Abb. 2: Fehlermeldung beim Aufruf des Berichtsservers

Voraussetzung ist natürlich ein Reporting Services Dienst der vor dem SP1 korrekt lief. Sollte das nicht der Fall sein, könnte folgender Artikel weiterhelfen Wie Installieren von SQL Server 2005 Reporting Services auf einem Windows Vista-based Computer.

Nun zur Behebung des Problems

Die Ursache ist die Abschaltung der Funktionalitäten für ‚Skripte’ und ‚Ausführen’ für die Site des Berichtsservers. Mit folgenden Schritten sollten die geliebten Berichte wieder erreichbar sein:

1. Klicken Sie in der Systemsteuerung auf System und Verwaltung.
2. Klicken Sie auf Verwaltung.
3. Doppelklicken Sie auf Internetinformationsdienste-Manager.
4. Klicken Sie in dem Dialogfeld User Account Control auf Fortsetzen.
5. Öffnen Sie im linken Bereich der Verbindungen den Baum soweit bis Sie auf ReportServer treffen. Im Normalfall sollte das folgender Pfad sein <Servername> -> Sites -> Default Web Site -> ReportServer.
6. Klicken Sie auf ReportServer.
7. Im mittleren Bereich auf Handlerzuordnungen doppelklicken.

    


8. Hier liegt die Ursache des Ganzen, das deaktivierte ISAPI Modul. Diese muss nun wieder aktiviert werde. Im Bereich Aktionen auf Featureberechtigungen bearbeiten klicken.

    


9. Im Dialog Featureberechtigungen Skript aktivieren und mit OK bestätigen.
10. Nochmals im Bereich Aktionen auf Featureberechtigungen bearbeiten klicken.
11. Im Dialog Featureberechtigungen Ausführen aktivieren und mit OK bestätigen. Das ISAPI Modul sollte nun wieder aktiviert sein.
12. Anschließend muss jetzt noch der IIS neu gestartet werden. Dazu im linken Bereich Verbindungen den Server auswählen und im rechten Bereich Aktionen auf Neu starten klicken.

Viel Spaß beim weiteren Arbeiten mit Reporting Services 2005, Ihr Jörg Knuth.