Die Vergabe von Benutzerrechten in einer OLAP-Datenbank auf einem Microsoft Analysis Server (SSAS) kann auf unterschiedliche Weise gelöst werden. Es können Lese- oder Schreibberechtigungen auf die ganze Datenbank, auf einen oder mehrere Würfel und Measuresgroups vergeben, oder einzelne Elemente einer Dimension oder Measures für den Zugriff gesperrt werden. Diese Berechtigungen werden für Rollen definiert.
In Rollen werden Benutzer mit gleichen Benutzerrechten zusammengefasst. Somit muss nicht für jeden einzelnen Anwender die Berechtigung separat gesetzt werden. Bei weniger komplexen Berechtigungsszenarien können so mit einigen Mausklicks die Berechtigungen erstellt und gepflegt werden. Sieht das Berechtigungsszenario jedoch vor, dass jeder Anwender separat berechtigt werden muss, weil jeder von ihnen z. B. nur seine Region oder seine Kostenstelle sehen darf, muss für jeden Anwender eine eigene Rolle mit den entsprechenden Berechtigungen erstellt werden. Wird beim Reporting der SQL-Durchgriff zur Analyse von Belegdaten genutzt, müssen diese Berechtigungen auch auf der relationalen Datenbank Berücksichtigung finden. Um sich dabei doppelten Pflegeaufwand bei der Vergabe der Berechtigungen zu ersparen, empfiehlt es sich die Berechtigung gleich auf der relationalen Schicht zu pflegen und diese anschließend automatisch an einen Berechtigungswürfel auf der OLAP-Datenbank zu übergeben (siehe Blogbeitrag Rechteverwaltung in SSAS – Teil 2). Oft wird die Verantwortung für die Berechtigungspflege an die Fachabteilung delegiert. Die IT-Abteilung stellt eine speziell benannte Benutzergruppe im Active-Directory (AD) zur Verfügung, der alle Benutzer mit Zugriff auf die BI-Anwendung zugeordnet wurden. Die Vergabe der Berechtigungen der einzelnen Benutzer innerhalb dieser AD-Gruppe muss anschließend von der Fachabteilung vorgenommen werden. Hierfür werden oft Pflegeanwendungen in DeltaMaster genutzt, in denen man jedem einzelnen Benutzer z. B. seine berechtigte Kostenstelle zuweisen kann. Damit die Berechtigungen wirken, muss der korrekte Name der Kostenstelle und der korrekte Benutzername angegeben werden. Dies stellt aber oft ein Problem dar, da nicht immer bekannt ist, wie der genaue Benutzername im Active-Directory lautet. Um dem Pflegenden bei dieser Arbeit zu unterstützen, wäre es hilfreich, wenn alle in der AD-Gruppe befindlichen Benutzer in einer Pflegeanwendung angezeigt würden und anschließend „nur noch“ die berechtigten Kostenstellen zugeordnet werden müssten. Wie eine solche Liste mittels einer SQL-Abfrage ermittelt werden kann, soll dieser Blogbeitrag verdeutlichen.

Voraussetzungen

Der Microsoft SQL-Server bietet die Möglichkeit, mit Hilfe eines Linked-Servers, SQL-Abfragen an ein Active-Directory zu senden, um sich Inhalte desselben anzeigen zu lassen. Voraussetzung dafür ist, dass der Abfragende Mitglied im entsprechenden Active-Directory (Domäne) ist. Außerdem muss der korrekte Name der Domäne bekannt sein. Der Name kann in der Eingabeaufforderung (cmd.exe) über den Befehl net config workstation ermittelt werden.

Abbildung 1: Eingabeaufforderung

Benötigt wird die Angabe hinter „Workstation Domänen-DNS-Name“, im gezeigten Beispiel lautet der Name der Domäne company.de. Anschließend muss ein Verbindungsserver (Linked Server) im SQL Server Management Studio angelegt werden.

Verbindungsserver anlegen

Verbindungsserver können im SQL Server Management Studio im Objekt-Explorer unter dem Ordner Serverobjekte – Verbindungsserver angelegt werden. Ein Klick mit der rechten Maustaste auf den Ordner Verbindungsserver zeigt ein Kontextmenü an, in dem der Eintrag Neuer Verbindungsserver… gewählt werden muss.

Abbildung 2: Objekt-Explorer – Neuer Verbindungsserver

Im anschließend erscheinenden Fenster müssen die folgenden Einträge auf der Registerkarte Allgemein vorgenommen werden:

Verbindungsserver: ADSI
Anbieter: OLE DB Provider for Microsoft Directory Service
Produktname: Active Directory Service Interface
Datenquelle: adsatasource

Abbildung 3: Neuer Vebindungsserver – Allgemein

Auf der Registerkarte Sicherheit wird die Option “im aktuellen Sichtkontext der Anmeldung verwendet” gewählt. Wie eingangs erörtert, muss dabei der abfragende Benutzer Mitglied der Domäne sein.

Abbildung 4: Neuer Vebindungsserver – Sicherheit

Alternativ können die Einträge mit Hilfe der folgenden SQL-Statements erstellt werden:

EXEC sp_addlinkedserver @server = N'ADSI', @srvproduct=N'Active Directory Service Interfaces', @provider=N'ADSDSOObject', @datasrc=N'adsdatasource'
GO
EXEC sp_addlinkedsrvlogin @rmtsrvname=N'ADSI',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL
GO

Im Objekt-Explorer wird die neue Verbindung anschließend direkt unterhalb des Ordners Verbindungsserver angezeigt.

Abbildung 5: Objekt-Explorer mit neuem Verbindungsserver

Active-Directory abfragen

Nach dem Anlegen des Verbindungsservers kann nun das Active-Directory per SQL abgefragt werden. Zunächst wird der Name der von der IT zur Verfügung gestellten Gruppe(n) ermittelt. Im Namen der Gruppe(n) soll der Ausdruck DeltaMaster vorkommen. Über die Funktion OpenQuery und der Angabe des Verbindungsserver (ADSI), der abzufragenden Domäne company.de (DC = company, DC = de) und der Filterung auf die Objektklasse Gruppe (objectClass = Group) und dem Namen DeltaMaster (CN = *DeltaMaster*), wird eine Liste aller AD-Gruppen zurückgegeben, welche im Namen den Ausdruck DeltaMaster enthalten. Eine Besonderheit bei der Abfrage besteht darin, dass als Wildcard statt der bekannten Ausdrücke Prozentzeichen (%) oder Unterstrich (_) der Stern (*) verwendet wird.

SELECT * FROM OpenQuery
(ADSI, 'SELECT sAMAccountName, cn, ADsPath
FROM ''LDAP://DC=company,DC=de''
where objectClass = ''Group'' and CN=''*DeltaMaster*''
')

Abbildung 6: Alle AD-Gruppen mit DeltaMaster im Namen

Das Active-Directory bietet eine Vielzahl an Informationen (Attribute), welche alle über die gezeigte Methode abgefragt werden können. Eine (möglicherweise nicht vollständige) Zusammenfassung ist unter https://msdn.microsoft.com/en-us/library/cc220155.aspx zu finden.
Mit der Information aus der oberen Abfrage der Gruppen können nun alle Mitglieder der AD-Gruppe DeltaMaster_User ermittelt werden. Dazu wird der Gruppenname aus der Spalte ADsPath der oberen Abfrage im Where-Statement als Filterkriterium an das Attribut memberOf übergeben.

SELECT * FROM OpenQuery
(ADSI, 'SELECT sAMAccountName,mail,cn,msDS-PrincipalName
FROM ''LDAP://DC=company,DC=de''
where objectClass = ''User'' and objectClass=''Person'' and
memberOf=''CN=DeltaMaster_User,OU=Groups,OU=Staff,
DC=company,DC=de''
')

Abbildung 7: Alle Mitglieder der AD-Gruppe DeltaMaster_User

Berechtigungspflege

Um diese Informationen in einer DeltaMaster-Pflegeanwendung nutzen zu können, muss eine Sicht im SQL-Server erstellt werden. Diese zeigt in der ersten Spalte alle Benutzer der abgefragten AD-Gruppe und in der zweiten Spalte die zugeordneten Kostenstellen, welche z. B. aus einer Kostenstellentabelle T_S_Kostenstelle kommen können. Zunächst ist die zweite Spalte noch leer, da noch keine Zuordnungen getroffen wurden. Anschließend muss eine DeltaMaster-Pflegeanwendung erstellt werden, über die die entsprechenden Zuordnungen eingegeben werden können. Wie dabei vorzugehen ist, kann im Blogbeitrag „Aufbau eines Datenerfassungssystems für relationale Datenbanken“ nachgelesen werden.

Abbildung 8: DeltaMaster-Pflegeanwendung

Wird eine Zuordnung über die DeltaMaster-Pflegeanwendung vorgenommen, wird diese Information im gezeigten Beispiel in der Tabelle T_D_Mapping_Benutzer_Kostenstelle gespeichert.

Abbildung 9: Inhalt der Tabelle T_D_Mapping_Benutzer_Kostenstelle

In der Mappingtabelle werden die vollständigen Benutzernamen inkl. vorangestellter Domäne (im Screenshot COMPANY) gespeichert, da diese später in der gezeigten Form vom System an den Berechtigungswürfel übergeben werden. Die Kostenstelleninformationen werden typischerweise als ID abgelegt. Diese Tabelle wird anschließend als Quelle für den Berechtigungswürfel herangezogen und bietet somit eine elegante, ohne weiteren Pflegeaufwand zur Verfügung stehende Methode, um auch auf der OLAP-Datenbank die korrekten Benutzerrechte anzuwenden (siehe Blogbeitrag „Rechteverwaltung in SSAS – Teil 2“). Darüber hinaus kann diese Tabelle auch für die korrekte Berechtigungsabfrage in SQL-Durchgriffen genutzt werden (siehe Blogbeitrag „DeltaMaster SQL-Durchgriff optimieren“).

Erweiterungsmöglichkeiten

Werden in den abgefragten AD-Gruppen Benutzer gelöscht, für die schon eine Zuordnung zu einer Kostenstelle vorgenommen und in der Mappingtabelle gespeichert wurden, werden diese Einträge zunächst in der Pflegeanwendung nicht mehr sichtbar. Dies stellt zwar kein Sicherheitsproblem dar, da sich die Benutzer somit auch nicht mehr an die Datenbank anmelden können, dennoch sollten diese verwaisten Einträge entfernt werden. Dazu wäre es möglich, über einen automatisierten Task (z. B. per SSIS) regelmäßig einen Abgleich der Mitglieder der AD-Gruppe und der Mappingtabelle vorzunehmen.