<\/p>\n
Der Wechsel von einem Access-Backend zum SQL Server als Backend-System hat – neben der Performance und dem Speicherplatz – oft einen entscheidenden Grund: Access schützt die Daten nicht ausreichend vor fremden Zugriffen. Hier hat der SQL Server deutlich die Nase vorn, denn er bietet verschiedene Möglichkeiten der Sicherung der Daten vor dem unbefugten Zugriff. Dieser Artikel zeigt, wie das Sicherheitssystem und die Benutzerverwaltung im SQL Server funktionieren.<\/b><\/p>\n
Mit Access 2010 hat Microsoft sich endgültig vom Sicherheitssystem verabschiedet. Zuvor gab es unter Access noch die sogenannte Arbeitsgruppendatei (.mdw<\/b>) und einige Elemente in der Benutzeroberfläche, mit denen Sie Benutzergruppen, Benutzer und deren Zugriffsrechte auf die einzelnen Elemente einer Datenbank beeinflussen konnten.<\/p>\n
War einer Access-Datenbank eine Arbeitsgruppendatei zugeordnet, fragte Access beim öffnen der Anwendung den Namen und das Kennwort des Benutzers ab und entschied dann, ob dieser die Anwendung überhaupt öffnen durfte. Anschließend gab es Freigaben zum öffnen der verschiedenen Access-Objekte nur entsprechend der Zugriffsberechtigungen des Benutzers oder der Benutzergruppe, der dieser Benutzer zugeordnet war.<\/p>\n
Allerdings war dieses System schon lange nicht mehr sicher und bot nur einen mittelmäßigen Schutz vor Datendiebstahl. Mittelmäßiges Interesse am Knacken der Datenbank vorausgesetzt, war es leicht möglich, an die enthaltenen Daten zu gelangen. Wohl auch deshalb hat sich Microsoft entschlossen, dieses Sicherheitssystem vor einigen Jahren abzuschaffen und die Access-Entwickler und auch die Benutzer nicht mehr in scheinbarer Sicherheit zu wiegen.<\/p>\n
Wer überhaupt ein Sicherheitssystem verwenden wollte, musste umsteigen oder sich auf das allzu rudimentäre Datenbankkennwort verlassen – das aber dann entweder den Zugriff komplett verwehrte oder aber den Datenbankinhalt vollständig freigegeben hat.<\/p>\n
Im SQL Server gibt es erheblich mehr Features, um die in den Tabellen enthaltenen Daten vor neugierigen Blicken oder auch vor unbefugtem Verändern zu schützen. Die Anmeldung an einer Datenbank erfolgt dabei auf zwei verschiedene Arten:<\/p>\n
Die erste Variante ist sinnvoll, wenn Sie über eine Domäne verfügen, also einen Bereich im Netzwerk, in dem die Benutzerrechte für verschiedene Benutzer zentral verwaltet werden. Hier erhält jeder Benutzer bereits in der Domäne ein eigenes Benutzerkonto, mit der sich auf seinem Rechner anmelden und je nach Berechtigungen auf die Daten und Geräte im Netzwerk zugreifen kann.<\/p>\n
Dazu gehören dann auch die SQL Server, die in der Domäne erreichbar sind und die enthaltenen Datenbanken. Im SQL Server werden dann Konten für die in der Domäne bereits vorhandenen Benutzer oder Benutzergruppen angelegt.<\/p>\n
Meldet sich der Benutzer dann unter seinem Windows-Konto am Rechner und somit in der Domäne an und versucht dann, auf den SQL Server zuzugreifen, werden seine Windows-Anmeldedaten daraufhin geprüft, ob das Konto auch im SQL Server vorliegt. Ist das der Fall, wird der Benutzer automatisch auch dort angemeldet, ohne seine Zugangsdaten auch noch für die Anmeldung im SQL Server eingeben zu müssen.<\/p>\n
Die zweite Alternative ist, bei der Installation des SQL Servers für die Authentifizierung den sogenannten gemischten Modus zu aktivieren. Dann ist nicht nur die Windows-Authentifizierung möglich, sondern auch die SQL Server-Authentifizierung. Das bedeutet, dass im SQL Server Konten für Benutzer und Benutzergruppen unabhängig von den Windows-Konten angelegt werden.<\/p>\n
Der Hintergrund ist, dass es nicht immer eine Domäne gibt, unter der die Benutzer verwaltet werden und somit ein vereinfachter Zugriff auch auf die Daten im SQL Server ermöglicht werden kann. Vielleicht haben Sie nur einen einzelnen Rechner und wollen eine lokale SQL Server-Datenbank verwenden, haben ein Netzwerk ohne Domäne, in dem die Benutzer aber dennoch über das Netz auf die Daten von SQL Server-Datenbanken zugreifen sollen oder Sie verwenden den SQL Server für eine Webanwendung.<\/p>\n
Die für die SQL Server-Nutzung angelegten Konten sind also unabhängig von Windows-Konten. Somit benötigen wir also auch ein komplett eigenständiges Paar aus Benutzername und Kennwort. Wenn der Benutzer sich nun am SQL Server anmelden möchte, muss er unter Umständen zwei Anmeldungen durchführen – erst am Windows-System und dann am SQL Server.<\/p>\n
übrigens: Das Benutzerkonto sa<\/b>, das standardmäßig vorhanden ist, ist auch ein SQL Server-Konto. Unnötig zu erwähnen, dass dieses Konto immer mit einem Kennwort geschützt werden muss, da dieses universellen Zugriff auf den SQL Server bietet. Es gibt eine Bedingung, unter der sich ein Benutzer auch ohne Verwendung einer Domäne per Windows Authentifizierung am SQL Server anmelden kann – wenn er sich auf dem gleichen Rechner angemeldet hat, auf dem auch der SQL Server installiert ist.<\/p>\nZweistufige Sicherheit<\/h2>\n
Genau so, wie der Benutzer sich erst am Windows-System und dann am SQL Server anmelden muss (wobei letzteres automatisch geschieht, wenn die Windows-Authentifizierung verwendet wird), gibt es auch innerhalb des SQL Servers zwei Stufen der Absicherung.<\/p>\n
Wenn ein Benutzer ein Konto am SQL Server besitzt, heißt das nämlich noch lange nicht, dass er sich auch an einer Datenbank im SQL Server anmelden kann. Das Benutzerkonto muss auch für die Datenbank eingetragen sein und kann dort dann mit spezifischen Rechten versehen werden.<\/p>\n
Im Prinzip erfolgt die Anmeldung an einer Datenbank im SQL Server also so, dass der SQL Server erst prüft, ob es überhaupt ein Benutzerkonto mit den angegebenen Daten im SQL Server gibt. Ist das nicht der Fall, scheitert die Anmeldung bereits in der ersten Stufe. Gibt es ein Benutzerkonto und ist das Kennwort korrekt beziehungsweise handelt es sich um eine Windows-Authentifizierung, prüft der SQL Server als Nächstes, ob das Benutzerkonto auch der jeweiligen Datenbank zugeordnet ist.<\/p>\n
Wie auch in einer Windows-Domäne gibt es auch beim SQL Server Benutzer und Benutzergruppen. Beiden können Sie Berechtigungen für den Zugriff auf die verschiedenen Elemente einer Datenbank zuweisen.<\/p>\n
Der Vorteil der Konten von Benutzergruppen gegenüber Benutzern treten dabei zutage, wenn mehrere Benutzer mit gleichen Berechtigungen für den Zugriff auf die Datenbank ausgestattet werden sollen. Dann brauchen Sie die Berechtigungen nur für die Benutzergruppe zu definieren und brauchen die Benutzer, die diese Berechtigungen erhalten sollen, einfach nur der Benutzergruppe zuzuweisen.<\/p>\n
Das hat nebenher den Vorteil, dass Sie, wenn ein Benutzer ausscheidet und\/oder ein neuer Benutzer die gleichen Berechtigungen erhalten soll, Sie den Benutzer nur von der Gruppe entfernen oder hinzufügen müssen. Andersherum brauchen Sie, wenn sich einmal die Berechtigungen für die Benutzer dieser Gruppe ändern sollen, nur die Berechtigungen für die Gruppe zu ändern und nicht für jeden einzelnen Benutzer. Sie sehen: Die Vergabe von Berechtigungen über Benutzergruppen ist essenziell, wenn Sie es mit mehr als einem Benutzer zu tun haben.<\/p>\n
Bei der Verwendung der Windows-Authentifizierung gibt es gegebenenfalls bereits Benutzergruppen unter Windows, denen die verschiedenen Benutzer zugeordnet sind. In diesem Fall vergeben Sie die Berechtigungen im SQL Server für die Windows-Benutzergruppen und nicht für einzelne Benutzer. In Unternehmen sollten dies der Fall sein – dort gibt es verschiedenen Benutzergruppen mit individuellen Berechtigungen, denen die Mitarbeiter zugeordnet werden. Dadurch erben die Mitarbeiter die Berechtigungen dieser Gruppe. Scheidet ein Mitarbeiter aus dem Unternehmen aus, wird sein Benutzerkonto aus der Benutzergruppe entfernt – schon sind auch seine Berechtigungen am SQL Server erloschen. Auf diese Weise muss sich der Administrator des SQL Servers oder der Datenbank gar nicht um die Vergabe oder den Entzug von Berechtigungen beschäftigen, denn dies erledigt der Systemadministrator, indem er die Windows-Benutzer aus Gruppen entfernt oder sie diesen hinzufügt.<\/p>\n
Wenn Sie Berechtigungen für Benutzergruppen mit Benutzern in einer Umgebung mit SQL Server-Authentifizierung vergeben wollen, müssen Sie die Benutzergruppen erst noch im SQL Server anlegen und diesen die einzelnen Benutzer zuweisen. Das ist, wie oben erwähnt, die einzig mögliche Variante, wenn die Benutzer und Benutzergruppen nicht in einer Domäne verwaltet werden.<\/p>\n
Wir schauen uns als Erstes an, wie die Windows-Authentifizierung funktioniert. Dazu legen wir im Folgenden auf dem lokalen Rechner zwei Windows-Benutzerkonten an sowie zwei Benutzergruppen an. Jedes Benutzerkonto weisen wir dabei einer Benutzergruppe zu. Dann fügen wir die Benutzergruppen als Anmeldungen zum SQL Server hinzu und ordnen diese unserer Beispieldatenbank Suedsturm_SQL <\/b>zu.<\/p>\nBenutzer hinzufügen<\/h2>\n
Unter Windows 10 Pro können Sie Benutzer über die Benutzeroberfläche hinzufügen. Da es unter den Lesern gegebenenfalls auch Benutzer der Home-Version von Windows 2010 gibt, wollen wir einen alternativen Weg zum Verwalten von Benutzern und Benutzergruppen aufzeigen. Dieser verwendet das Kommandozeilentool net.exe<\/b>. Um dieses zu nutzen, geben Sie cmd <\/b>in das Suchfeld von Windows ein und betätigen die Eingabetaste. In der nun erscheinenden Eingabeaufforderung können Sie mit wenigen Befehlen die Benutzer und Benutzergruppen verwalten. Die Befehle von net.exe <\/b>finden Sie, indem Sie diesen einfach ohne weitere Optionen eingeben (siehe Bild 1).<\/p>\n
![\"Optionen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_001.png\")
<\/p>\n
Bild 1: Optionen des Befehls net.exe zur Benutzerverwaltung<\/span><\/b><\/p>\n Um sich einen überblick über die aktuell vorhandenen Benutzer zu schaffen, verwenden Sie etwa den folgenden Befehl:<\/p>\n Dies liefert die Liste aus Bild 2. Wenn Sie alle Benutzergruppen ausgeben möchten, ist die folgende Option die Richtige:<\/p>\n Bild 2: Ausgabe der aktuellen Benutzer des Systems<\/span><\/b><\/p>\n Dieser Befehl liefert, wenn keine Domäne vorhanden ist, das folgende Resultat:<\/p>\n Wenn wir allerdings den Befehl net.exe LOCALGROUP <\/b>ausführen, liefert dies das Ergebnis aus Bild 3.<\/p>\n Bild 3: Ausgabe der Benutzergruppen<\/span><\/b><\/p>\n Wir wollen nun nicht lange experimentieren, sondern direkt einen neuen Benutzer anlegen. Um einen neuen Benutzer namens Benutzer1 <\/b>mit dem Kennwort password <\/b>anzulegen, verwenden wir den folgenden Befehl:<\/p>\n Dabei erhalten wir allerdings den folgenden Fehler:<\/p>\n Aber keine Sorge: Wir haben lediglich versäumt, die Eingabeaufforderung mit Administrator-Rechten zu starten. Dazu geben Sie nochmals cmd <\/b>im Suchfeld von Windows ein. Es erscheint nun der Eintrag Eingabeaufforderung in der Liste der Suchergebnisse.<\/p>\n Diesen klicken Sie mit der rechten Maustaste an und wählen aus dem Kontextmenü den Befehl Als Administrator ausführen <\/b>aus (siehe Bild 4).<\/p>\n Bild 4: Eingabeaufforderung mit Administratorrechten starten<\/span><\/b><\/p>\n Danach gelingt dann auch der Aufruf des Befehls zum Anlegen eines neuen Benutzers:<\/p>\n Geben Sie danach erneut den Befehl net.exe USER <\/b>ein, erscheint der neue Benutzer namens Benutzer1 <\/b>in der Auflistung. Auf die gleiche Weise legen wir nun den Benutzer mit dem Namen Benutzer2 <\/b>und dem Kennwort password <\/b>an:<\/p>\n Damit haben wir die gewünschten beiden Benutzer zum System hinzugefügt. Nun kommen wir zu den Benutzergruppen. Dazu finden wir zwei mögliche Optionen in der Befehlsliste: GROUP <\/b>und LOCALGROUP<\/b>. Der Befehl net.exe GROUP <\/b>kann nur in Zusammenhang mit einer Domäne angewendet werden. Da wir diese nicht für jeden Leser voraussetzen können, wollen wir die Variante LOCALGROUP <\/b>nutzen, um die neuen Gruppen anzulegen. Mit der Option \/ADD <\/b>und dem Namen der hinzuzufügenden Gruppe, hier Gruppe1<\/b>, fügen wir nun eine erste Gruppe hinzu:<\/p>\n Auf diese Weise legen wir auch noch eine zweite Gruppe an:<\/p>\n Der Befehl net.exe LOCALGROUP <\/b>gibt nun die bereits vorhandenen und die beiden neuen Gruppen aus:<\/p>\n Bevor wir unsere beiden Benutzer den neuen Gruppen zuweisen, schauen wir uns an, wie wir ermitteln können, welche Benutzer einer Gruppe bereits zugeordnet sind. Dazu verwenden wir den Befehl LOCALGROUP<\/b> und geben einfach den Namen der Gruppe an, deren Mitglieder wir ermitteln wollen – hier für die Gruppe Administratoren<\/b>:<\/p>\n Nun fügen wir den Benutzer mit den Namen Benutzer1 <\/b>der Gruppe namens Gruppe1 <\/b>hinzu. Dazu nutzen wir wieder den Befehl LOCALGROUP <\/b>mit den Namen der Gruppe, fügen aber noch die Option \/ADD <\/b>mit den Namen des hinzuzufügenden Benutzers hinzu:<\/p>\n Ein Aufruf des Befehls LOCALGROUP Gruppe1 <\/b>liefert dann den Benutzer Benutzer1 <\/b>als einziges Mitglied dieser Gruppe.<\/p>\n Den Benutzer Benutzer2 <\/b>fügen wir anschließend auf die gleiche Weise der Gruppe Gruppe2 <\/b>hinzu.<\/p>\n <\/p>\n Wenn Sie den Benutzer anschließend wieder aus der Gruppe entfernen wollen, erledigen Sie das mit der folgenden Anweisung:<\/p>\n Um im Anschluss an eventuelle Experimente im Rahmen der Lektüre dieses Artikels das System in den ursprünglichen Zustand zu versetzen, können Sie die Benutzer wie folgt löschen:<\/p>\n Die beiden Benutzer löschen Sie so:<\/p>\n Für die folgenden Experimente im SQL Server sollten Sie die beiden Gruppen und die beiden Benutzer jedoch noch behalten beziehungsweise erneut anlegen.<\/p>\n Nun wollen wir die beiden zuvor unter Windows angelegten Benutzergruppen im SQL Server nutzen. Dazu öffnen Sie das SQL Server Management Studio, in unserem Fall in der Version 2016. Hier arbeiten wir mit einer Datenbank namens Suedsturm_SQL<\/b>, die Sie gegebenenfalls noch anlegen müssen. Das benötigte SQL-Skript finden Sie im Download zu diesem Beitrag, die Anleitung dazu liefert der Beitrag SQL Server-Datenbank kopieren <\/b>(www.access-im-unternehmen.de\/1153<\/b>).<\/p>\n Wie wir weiter oben angeführt haben, hat das Sicherheitssystem des SQL Servers zwei Stufen – die erste erlaubt den Zugriff auf den SQL Server, die zweite dann den Zugriff auf die jeweilige Datenbank. Dementsprechend müssen wir auch zuerst entsprechende Benutzergruppen und Benutzer für den SQL Server einrichten und erst dann für die jeweilige Datenbank.<\/p>\n Um zunächst eine neue Gruppe für die Instanz des SQL Servers anzulegen, klicken Sie mit der rechten Maus auf den Eintrag Sicherheit <\/b>des SQL Servers im SQL Server Management Studio und wählen den Eintrag Neue Anmeldung… <\/b>aus (siehe Bild 5).<\/p>\n Bild 5: Aufruf des Dialogs zum Anlegen einer neuen Anmeldung<\/span><\/b><\/p>\n Es erscheint der Dialog aus Bild 6. Hier können Sie den Namen der anzulegenden Gruppe direkt in das Feld Anmeldename <\/b>eingeben. Allerdings wollen wir es uns etwas gemütlicher machen und klicken zunächst auf die Schaltfläche Suchen<\/b>.<\/p>\n Bild 6: Dialog zum Anlegen einer neuen Anmeldung<\/span><\/b><\/p>\n Dies öffnet wiederum den Dialog aus Bild 7. Auch hier wollen wir noch nicht nach der anzulegenden Gruppe suchen, die wir ja von den Windows-Anmeldungen übernehmen wollen. Wir klicken auf die Schaltfläche Erweitert<\/b>.<\/p>\n Bild 7: Dialog zum Auswählen von Benutzern oder Gruppen<\/span><\/b><\/p>\n Im nun erscheinenden Dialog Benutzer oder Gruppe auswählen <\/b>klicken wir ohne Angabe von Suchkritereien einfach auf die Schaltfläche Jetzt suchen<\/b>. Es erscheinen einige Einträge in der Liste der Suchergebnisse, darunter auch unsere zuvor angelegten Benutzer namens Benutzer1 <\/b>und Benutzer2 <\/b>(siehe Bild 8). Allerdings finden wir hier leider nicht die beiden Gruppen Gruppe1 <\/b>und Gruppe2<\/b>.<\/p>\n Bild 8: Erweiterter Dialog zum Auswählen von Benutzern oder Gruppen<\/span><\/b><\/p>\n Die Ursache ist schnell gefunden. Wenn Sie auf die Schaltfläche Objekttypen <\/b>rechts neben dem Textfeld Objekttyp klicken, erscheint der Dialog Objekttypen<\/b>. Hier ist die Option Gruppen <\/b>standardmäßig deaktiviert. Also setzen wir den fehlenden Haken und schließen den Dialog wieder (siehe Bild 9).<\/p>\n Bild 9: Dialog zur Auswahl der anzuzeigenden Objekttypen<\/span><\/b><\/p>\n Zurück im Dialog Benutzer oder Gruppe auswählen <\/b>klicken Sie nun erneut auf die Schaltfläche Jetzt suchen<\/b>. Nun erscheinen in der Liste der Suchergebnisse auch die beiden Einträge Gruppe1 <\/b>und Gruppe2<\/b> (siehe Bild 10). Hier markieren wir nun zunächst den Eintrag Gruppe1 <\/b>und klicken auf OK<\/b>.<\/p>\n Bild 10: Dialog mit den gesuchten Gruppen<\/span><\/b><\/p>\n Im Dialog Benutzer oder Gruppe auswählen <\/b>finden Sie nun den Eintrag mit dem Rechnernamen und dem Namen der Gruppe (siehe Bild 11).<\/p>\n Bild 11: Die gesuchte Gruppe im Dialog Benutzer oder Gruppe auswählen<\/span><\/b><\/p>\n Dieser wird nach dem Schließen des Dialogs in das Feld Anmeldename des Dialogs Anmeldename – Neu <\/b>übernommen. Wenn Sie den Rechnernamen und den Namen der Gruppe kennen, können Sie diesen natürlich auch hier eintippen – anderenfalls gehen Sie den zuvor beschriebenen Weg über die Suchdialoge. In diesem Dialog stellen Sie unten für die Eigenschaft Standarddatenbank<\/b> noch den Namen der Datenbank ein, auf die die Benutzergruppe zugreifen soll – in unserem Beispiel Suedsturm_SQL<\/b> (siehe Bild 12).<\/p>\n Bild 12: Standarddatenbank auswählen<\/span><\/b><\/p>\n Danach wechseln wir zur zweiten Seite des Dialogs namens Serverrollen<\/b>. Hier stellen wir ein, welche Berechtigungen die Benutzergruppe erhalten soll. Die Serverrolle public <\/b>ist bereits voreingestellt (siehe Bild 13). Die übrigen Serverrollen haben folgende Bedeutung:<\/p>\n Bild 13: Einstellen der Serverrollen der zu erstellenden Gruppe<\/span><\/b><\/p>\n Wenn Sie genauer wissen wollen, welche Berechtigungen sich hinter den einzelnen Serverrollen befinden, können Sie diese mit einer SQL-Abfrage ermitteln. Dazu öffnen Sie eine neue Abfrage über den Kontextmenü-Eintrag Neue Abfrage… <\/b>des Server-Eintrags im Objekt-Explorer und geben den folgenden Befehl ein:<\/p>\n Damit erhalten Sie eine Auflistung aller Befehle, die Sie mit der Rolle ausführen können – in Bild 14 zum Beispiel für die Serverrolle dbcreator<\/b>.<\/p>\n Bild 14: Auflistung der verfügbaren Befehle<\/span><\/b><\/p>\n Beachten Sie, dass die Vergabe von Serverrollen für eine Benutzergruppe dafür sorgt, dass alle Benutzer, die dieser Gruppe zugeordnet werden, die enthaltenen Berechtigungen erhalten. Da wir den Benutzern unserer Datenbank keine weiteren Berechtigungen etwa zum Erstellen neuer Datenbanken oder zum Verwalten von Benutzern zuweisen möchten, belassen wir es an dieser Stelle bei der Rolle public<\/b>.<\/p>\n Auf die gleiche Art, wie wir die Windows-Benutzergruppe namens Gruppe1 <\/b>zum SQL Server hinzugefügt haben, fügen wir nun auch noch die Gruppe namens Gruppe2 <\/b>hinzu.<\/p>\n Sie können nun, um die Wirkung der Berechtigungen zu testen, einmal den Benutzer wechseln und sich als Benutzer1<\/b> anmelden. Sie können damit das SQL Server Management Studio starten, sich dort mit dem lokalen Server verbinden und die Liste der enthaltenen Datenbanken einsehen. Wenn Sie allerdings doppelt auf einen der Datenbank-Einträge klicken, erscheint eine Meldung, nach der Sie keine Berechtigung zum Zugriff auf diese Datenbank haben. Bisher funktioniert also alles nach Plan. Nun wollen wir also noch die Berechtigungen auf Datenbank-Ebene hinzufügen.<\/p>\n Um die Benutzer der Benutzergruppe Gruppe1 <\/b>einer Datenbank zuzuordnen, wechseln wir zur Seite Benutzerzuordnung<\/b> des Dialogs Anmeldung – Neu<\/b>. Hier finden wir nun im oberen Bereich eine Liste der Datenbanken dieses SQL Servers. Um unsere Anmeldung, die sich auf Gruppe1 <\/b>bezieht und somit den Benutzer Benutzer1 <\/b>betrifft, mit Berechtigungen für die Datenbank Suedsturm_SQL<\/b> zu versehen, setzen Sie einen Haken für den entsprechenden Eintrag. Im unteren Bereich des Dialogs erscheinen nun die Datenbankrollen, die Sie für die Gruppe Gruppe1<\/b> in Zusammenhang mit der Datenbank Suedsturm_SQL <\/b>festlegen können (siehe Bild 15). Die Details zu den einzelnen Datenbankrollen für eine Datenbank lauten wie folgt:<\/p>\n Bild 15: Festlegen der Zuordnung des Kontos zu einer Datenbank<\/span><\/b><\/p>\n Auch hier gibt es wieder eine gespeicherte Prozedur, mit der Sie die Berechtigungen der einzelnen Benutzerrollen ermitteln können. Dazu rufen Sie in einer SQL Server-Abfrage den folgenden Befehl auf:<\/p>\n Für die Rolle db_datareader <\/b>liefert dies beispielsweise nur SELECT<\/b>-Berechtigungen, für db_datawriter <\/b>die Berechtigungen für DELETE<\/b>, INSERT<\/b> und UPDATE<\/b>. Schauen Sie selbst einmal in die Berechtigungen – es ist sehr interessant!<\/p>\n Grundsätzlich setzen Sie die etwa die Berechtigungen über die Datenbankrollen db_datareader<\/b> oder db_datawriter <\/b>immer gleich für alle Tabellen der Datenbank. Das ist natürlich wenig differenziert. Wenn Sie etwa eine Datenbank verwenden, die einige Tabellen für einen speziellen Personenkreis vorsieht, während alle Tabellen nur einer kleinen Benutzergruppe zugänglich sein sollen, regeln Sie dies etwas feiner über die Berechtigungen an den einzelnen Datenbankobjekten – mehr dazu weiter unten.<\/p>\n Irritierenderweise gibt es unter den Datenbankrollen sowohl die beiden Rollen db_datareader<\/b> und db_datawriter<\/b>, mit denen Sie die Berechtigung zum Lesen und Schreiben der Daten erteilen können als auch die Rollen db_denydatareader <\/b>und db_denydatawriter<\/b>, mit denen Sie genau diese Rechte einschränken können.<\/p>\n Hier ist es wichtig zu wissen, dass die db_deny…<\/b>-Rollen Priorität haben. Das heißt, wenn Sie etwa db_datareader <\/b>und db_denydatareader <\/b>setzen, kann der Benutzer beziehungsweise die Benutzergruppe die Daten der Datenbank nicht lesen.<\/p>\n Wir wollen an dieser Stelle noch keine Berechtigungen vergeben, die über public <\/b>hinausgehen, da wird dies später noch nachholen und differenzierter erledigen können. Also verlassen wir den Dialog nun mit einem Klick auf die OK<\/b>-Schaltfläche und speichern so die neue Benutzergruppe Gruppe1 <\/b>mit grundlegenden Berechtigungen auf der Datenbank Suedsturm_SQL<\/b>.<\/p>\n Wenn Sie nun noch einmal zum Windows-Benutzer Benutzer1 <\/b>wechseln und die Liste der Datenbanken im SQL Server Management Studio aktualisieren, stellen Sie fest, dass Sie nun auf die Datenbank Suedsturm_SQL <\/b>zugreifen können. Allerdings zeigt diese etwas in der Liste der Tabellen nur die Systemtabellen an, aber nicht die in der Datenbank enthaltenen benutzerdefinierten Tabellen wie etwa tblArtikel<\/b>. Das liegt daran, dass wir der Gruppe bisher noch keine über public <\/b>hinausgehenden Berechtigungen erteilt haben.<\/p>\n Schließlich legen wir auch für die zweite Benutzergruppe namens Gruppe2 <\/b>eine Anmeldung für den SQL Server und für die Datenbank Suedsturm_SQL <\/b>an. Nachdem wir die oben beschriebenen Schritte für Gruppe2<\/b> ausgeführt haben und bevor Sie die änderungen mit einem Klick auf OK <\/b>speichern, wollen wir uns das Skript über die geplanten Aktionen ausgeben lassen. Dazu klicken Sie auf die Schaltfläche Skript <\/b>im oberen Bereich des Dialogs Anmeldung – Neu<\/b>. Dies erzeugt eine neue Abfrage mit folgendem Inhalt:<\/p>\n Sie sehen: Wenn Sie die SQL-Befehle kennen würden, kämen Sie weitgehend ohne den Einsatz der Dialoge des SQL Server Management Studios aus. Würden Sie die Benutzergruppe nun noch der Berechtigung db_datareader <\/b>für die Datenbank Suedsturm_SQL <\/b>zuordnen wollen, kämen noch zwei Zeilen hinzu:<\/p>\n Wollen Sie die Berechtigungen wieder entfernen, erledigen Sie das mit dem DROP<\/b>-Schlüsselwort:<\/p>\n Wir haben mit dem Erstellen einer Anmeldung für die Gruppe den für die meisten Zwecke sinnvolleren Weg gewählt, da Sie nun der Gruppe Benutzer hinzufügen können, welche über die Berechtigungen der Gruppe verfügen sollen. Sie können allerdings auch Anmeldungen für Benutzer anlegen, wenn das in Ihrem Anwendungszweck sinnvoll ist. Dazu geben Sie im Dialog Anmeldung – Neu <\/b>im Bereich Allgemein <\/b>einfach den Namen des Benutzers in das Feld Anmeldename <\/b>ein.<\/p>\n Aktualisieren Sie die Daten im Objekt-Explorer und öffnen Sie den Eintrag Sicherheit|Anmeldungen <\/b>Ihrer SQL Server-Instanz, finden Sie nun die beiden Einträge für Gruppe1 <\/b>und Gruppe2 <\/b>mit vorangestelltem Rechnernamen vor (siehe Bild 16).<\/p>\n Bild 16: Die neuen Gruppen-Anmeldungen im SQL Server<\/span><\/b><\/p>\n Wenn Sie dann zur Datenbank Suedsturm_SQL <\/b>wechseln und dort den Eintrag Sicherheit|Benutzer <\/b>öffnen, finden Sie auch dort die beiden von uns hinzufügten Gruppen als Benutzer vor (siehe Bild 17).<\/p>\n Bild 17: Die neuen Benutzer in der Datenbank<\/span><\/b><\/p>\n Wie wir weiter oben erläutert haben, legen Sie mit den Berechtigungen auf Datenbankebene gleich für alle Objekte wie etwa Tabellen fest, ob der Benutzer beziehungsweise die Benutzergruppe nur lesend oder auch schreibend auf die enthaltenen Daten zugreifen darf. Dabei können Sie dies auch für jede Tabelle und jede Benutzergruppe einzeln festlegen.<\/p>\n Dazu klicken Sie mit der rechten Maustaste auf die Tabelle, deren Berechtigungen Sie einstellen wollen, und wählen dann aus dem Kontextmenü den Eintrag Eigenschaften <\/b>aus. Daraufhin erscheint etwa für die Tabelle tblArtikel <\/b>der noch ziemlich leere Dialog namens Eigenschaften der Tabelle – tblArtikel<\/b>.<\/p>\n Hier wollen wir nun zunächst über die Suchen<\/b>-Schaltfläche den Benutzer beziehungsweise die Benutzergruppe auswählen, für die oder den wir die Berechtigungen für diese Tabelle festlegen wollen. Im nun erscheinenden Dialog Benutzer oder Rollen auswählen <\/b>klicken Sie nun auf die Schaltfläche Durchsuchen<\/b>, was einen weiteren Dialog namens Nach Objekten suchen<\/b>. Dieser zeigt bereits die beiden Gruppen Gruppe1 <\/b>und Gruppe2<\/b> an, wobei wir in diesem Fall nur den Eintrag Gruppe1 <\/b>auswählen (siehe Bild 18).<\/p>\n Bild 18: Auswahl der Objekte, für welche die Berechtigungen festgelegt werden sollen<\/span><\/b><\/p>\n Dieser Eintrag erscheint dann nach dem Schließen des Dialogs Nach Objekten suchen <\/b>mit der OK<\/b>-Schaltfläche in der Liste des Dialogs Benutzer oder Rollen <\/b>auswählen (siehe Bild 19).<\/p>\n Bild 19: Die Gruppe namens Gruppe1 ist ausgewählt.<\/span><\/b><\/p>\n Nun wird auch der eingangs geöffnete Dialog Eigenschaften der Tabelle – tblArtikel<\/b> gefüllt. Oben finden Sie nun den Benutzer vor, für den Sie die Berechtigungen setzen wollen, unten die verschiedenen Berechtigungen für das Objekt (siehe Bild 20).<\/p>\n Bild 20: Festlegen der Berechtigungen für Gruppe1 am Objekt tblArtikel<\/span><\/b><\/p>\n Wir wollen für die Benutzer der Gruppe Gruppe1 <\/b>ausschließlich lesende Rechte für die Tabelle tblArtikel <\/b>festlegen, wozu wir in der Spalte Erteilen<\/b> für die Zeile Auswählen <\/b>einen Haken setzen. Dann speichern wir diese Berechtigung durch das Schließen des Dialogs. Wenn Sie die Berechtigungen für alle Objekte auf diese Weise setzen wollen, ist das eine etwas langweilige Arbeit – wir schauen uns gleich an, ob es hier noch eine alternative Vorgehensweise gibt. Zuvor wollen wir allerdings wieder einen kleinen Test starten.<\/p>\n Dazu wechseln wir unter Windows wieder zum Benutzer Benutzer1<\/b>, der ja der Benutzergruppe Gruppe1 <\/b>angehört und dementsprechend nur lesenden, aber keine schreibenden Zugriff auf die Tabelle tblArtikel <\/b>haben dürfte (und gar keinen Zugriff auf die übrigen Tabellen). Das Ergebnis sehen Sie in Bild 21.<\/p>\n Bild 21: Ein Benutzer der Gruppe Gruppe1 kann keine Daten ändern.<\/span><\/b><\/p>\n Es gibt eine etwas einfachere Methode, die Berechtigungen für eine Benutzerrolle zu setzen. Dieses besteht darin, statt die Vergabe der Berechtigung für jede Kombination aus Tabelle\/Objekt und Benutzer\/Benutzergruppe einzeln vorzunehmen, eine neue Datenbankrolle anzulegen – und zwar eine benutzerdefinierte Datenbankrolle.<\/p>\n Um eine solche anzulegen, öffnen Sie den Eintrag Sicherheit <\/b>der Datenbank Suedsturm_SQL <\/b>und klicken mit der rechten Maustaste auf den Eintrag Rollen<\/b>. Hier finden Sie den Kontextmenü-Eintrag Neu|Neue Datenbankrolle…<\/b> (siehe Bild 22).<\/p>\n Bild 22: Hinzufügen einer neuen Datenbankrolle<\/span><\/b><\/p>\n Mit diesem öffnen Sie den Dialog Datenbankrolle – Neu<\/b>, wo wir zunächst einen Rollennamen eingeben – der Einfachheit halber Gruppe1<\/b>, weil wir diese Rolle der Gruppe mit dem Namen Gruppe1 <\/b>zuweisen wollen.<\/p>\n über die Schaltfläche Hinzufügen <\/b>im unteren Bereich fügen wir dann wieder, wie bereits bei den Datenbankberechtigungen, die Gruppe namens Gruppe1 <\/b>hinzu. Der Dialog sieht dann wie in Bild 23 aus.<\/p>\n Bild 23: Benennen der neuen Rolle<\/span><\/b><\/p>\n In diesem Dialog wechseln wir dann zum Bereich Sicherungsfähige Elemente<\/b>. Hier erscheint unter Sicherungsfähige Elemente zunächst einmal eine leere Liste. Diese füllen wir, indem wir auf die Schaltfläche Suchen <\/b>klicken und im Dialog Objekte hinzufügen <\/b>die Option Alle Objekte, die dem Schema angehören <\/b>auswählen und als Schemaname <\/b>den Wert dbo <\/b>festlegen.<\/p>\n Schließen Sie den Dialog dann wieder, erscheinen alle Tabellen der Datenbank Suedsturm_SQL <\/b>in der Liste der sicherungsfähigen Elemente. Nun können Sie die Tabelle, für die Sie die Berechtigungen festlegen wollen, auswählen und im unteren Bereich die gewünschte Berechtigung selektieren (siehe Bild 24). Hier wollen wir nun für alle Tabellen die Berechtigung Auswählen <\/b>erteilen.<\/p>\n Bild 24: Festlegen der Berechtigungen für die neue Rolle<\/span><\/b><\/p>\n Dazu klicken Sie sich durch die Tabellen in der Liste Sicherungsfähige Elemente <\/b>und aktivieren unten jeweils die Option Auswählen<\/b>. Anschließend schließen wir den Dialog wieder mit einem Klick auf die OK<\/b>-Schaltfläche. Damit haben eine eine benutzerdefinierte Datenbankrolle erstellt, die den lesenden Zugriff auf alle Tabellen erlaubt.<\/p>\n Damit die Benutzergruppe Gruppe1 <\/b>nun auch die Rolle Gruppe1 <\/b>erhält, öffnen Sie nochmals die Eigenschaften des Elements Sicherheit|Benutzer| Bild 25: Zuweisen der benutzerdefinierten Datenbankrolle<\/span><\/b><\/p>\n Diese aktivieren wir nun und schließen den Dialog durch einen Klick auf die Schaltfläche OK <\/b>wieder.<\/p>\n Ob diese änderung sich wie gewünscht auswirkt, prüfen wir nun wieder, indem wir uns als Benutzer1 <\/b>am Windows-Rechner anmelden – der ja zur Benutzergruppe Gruppe1<\/b> gehört, der wir die Datenbankrolle Gruppe1 <\/b>zugewiesen haben. Im Gegensatz zum vorherigen Test sollten wir dort nun alle Tabellen vorfinden und diese auch für den lesenden Zugriff öffnen können.<\/p>\n Das Ergebnis ist wie erwartet – wenn wir uns als Benutzer1 <\/b>anmelden, erhalten wir lesende Zugriffsrechte auf alle Tabellen der Datenbank. Wenn Sie einige Tabellen über den Weg einer benutzerdefinierten Datenbankrolle zum Lesen freigeben und andere über die Berechtigungen der Benutzergruppe Gruppe1<\/b>, werden diese Berechtigungen mit Oder kombiniert – das heißt, dass dann Leserechte für alle Tabellen vorliegen, die überhaupt freigegeben wurden.<\/p>\n Wer aufgepasst hat, wird festgestellt haben, dass die Zuweisung lesender Berechtigungen für alle enthaltenen Tabelle dem Zuweisen der Datenbankrolle db_datareader <\/b>entspricht. Das ist allerdings nur auf den ersten Blick richtig: Wenn wir nun eine Tabelle zur Datenbank hinzufügen, würde der Benutzer mit der benutzerdefinierten Datenbankrolle nämlich erst Berechtigungen für diese Tabelle erhalten, wenn wir diese explizit der benutzerdefinierten Datenbankrolle zuweisen (oder der Benutzergruppe oder dem Benutzer). Verwenden wir hingegen die Datenbankrolle db_datareader<\/b>, gilt die lesende Zugriffsberechtigung auch für neu hinzugefügte Tabellen.<\/p>\n Sie können nun also Berechtigungen auf verschiebenen Ebenen vergeben:<\/p>\n Was geschieht nun, wenn Sie verschiedene Berechtigungen über verschiedene Ebenen vergeben – also lesende Rechte über die Benutzergruppe und schreibende Rechte über die Zuweisung der Datenbankrolle db_datawriter<\/b><\/p>\n Das wollen wir uns nun ansehen, indem wir der Benutzergruppe Gruppe1 <\/b>noch die Datenbankrolle db_datawriter <\/b>zuweisen (siehe Bild 26). Ein erneuter Wechsel zur Anmeldung von Benutzer1 <\/b>zeigt, dass wir nun nicht nur lesend, sondern auch schreibend mit einem Benutzer der Benutzergruppe Gruppe1 <\/b>auf die Tabellen zugreifen können.<\/p>\n Bild 26: Hinzufügen der Datenbankrolle db_datawriter<\/span><\/b><\/p>\n Das waren die grundlegenden Techniken für die Vergabe von Berechtigungen für die Objekte im SQL Server. In weiteren Beiträgen schauen wir uns an, wie Sie die Berechtigungen auf Basis eines Schemas vergeben und wie Sie die Berechtigungen für den Zugriff von einer Access-Datenbank aus nutzen können.<\/p>\n Der Beitrag Berechtigungen für Access-Objekte per SQL Server <\/b>(www.access-im-unternehmen.de\/1159<\/b>) in der folgenden Ausgabe zeigt, wie Sie die Elemente einer Access-Anwendung auf den Zugriff auf geschützte Daten einer SQL Server-Datenbank vorbereiten. Es gibt verschiedene Strategien, unter Access dafür zu sorgen, dass der Benutzer Objekte nur entsprechend seiner Zugriffsrechte auf die Daten im SQL Server erhält. Dieser Beitrag liefert Lösungsvorschläge für diese Aufgabenstellung.<\/p>\n Unter SQL Server-Authentifizierung <\/b>(www.access-im-unternehmen.de\/1155<\/b>) lernen Sie, wie Sie eine SQL Server-Datenbank für den Zugriff über die SQL Server-Authentifizierung einstellen.<\/p>\n Der Beitrag SQL Server-Zugriff ohne gespeichertes Kennwort <\/b>(www.access-im-unternehmen.de\/1156<\/b>) zeigt etwa, wie Sie unter der SQL Server-Authentifizierung von Access auf die Tabellen einer Anwendung zugreifen, ohne dass das Kennwort unverschlüsselt in der Datenbank gespeichert werden muss.<\/p>\n","protected":false},"excerpt":{"rendered":" Der Wechsel von einem Access-Backend zum SQL Server als Backend-System hat – neben der Performance und dem Speicherplatz – oft einen entscheidenden Grund: Access schützt die Daten nicht ausreichend vor fremden Zugriffen. Hier hat der SQL Server deutlich die Nase vorn, denn er bietet verschiedene Möglichkeiten der Sicherung der Daten vor dem unbefugten Zugriff. Dieser Artikel zeigt, wie das Sicherheitssystem und die Benutzerverwaltung im SQL Server funktionieren.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662018,66052018,44000022],"tags":[],"class_list":["post-55001154","post","type-post","status-publish","format-standard","hentry","category-662018","category-66052018","category-SQL_Server_und_Co"],"yoast_head":"\nnet.exe USER<\/pre>\n
![\"Ausgabe](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_002.png\")
<\/p>\nnet.exe GROUP<\/pre>\n
Dieser Befehl kann nur auf Windows-Domänencontrollern ausgeführt werden.<\/pre>\n
![\"Ausgabe](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_003.png\")
<\/p>\nnet.exe USER \/ADD Benutzer1 password<\/pre>\n
C:\\>net.exe USER \/ADD Benutzer1 password\r\nSystemfehler 5 aufgetreten.\r\nZugriff verweigert<\/pre>\n
![\"Eingabeaufforderung](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_004.png\")
<\/p>\nC:\\>net.exe USER \/Add Benutzer1 password\r\nDer Befehl wurde erfolgreich ausgeführt.<\/pre>\n
C:\\>net.exe USER \/Add Benutzer2 password<\/pre>\n
C:\\>net.exe LOCALGROUP \/ADD Gruppe1\r\nDer Befehl wurde erfolgreich ausgeführt.<\/pre>\n
C:\\>net.exe LOCALGROUP \/ADD Gruppe2\r\nDer Befehl wurde erfolgreich ausgeführt.<\/pre>\n
C:\\>net.exe LOCALGROUP\r\nGruppen für <\/font>DESKTOP-PC-I5\r\n------------------------------------------------------\r\n...\r\n*Gruppe1\r\n*Gruppe2\r\n...\r\nDer Befehl wurde erfolgreich ausgeführt.<\/pre>\n
Benutzer einer Gruppe anzeigen<\/h2>\n
C:\\WINDOWS\\system32>net.exe LOCALGROUP Administratoren\r\nAliasname Administratoren\r\nBeschreibung Administratoren haben uneingeschränkten Vollzugriff auf den Computer bzw. die Domäne.\r\nMitglieder\r\n-------------------------------------------------------\r\nAdministrator\r\nUser\r\nDer Befehl wurde erfolgreich ausgeführt.<\/pre>\n
Benutzer einer Gruppe hinzufügen<\/h2>\n
C:\\>net.exe LOCALGROUP Gruppe1 \/ADD Benutzer1\r\nDer Befehl wurde erfolgreich ausgeführt.<\/pre>\n
Benutzer aus einer Gruppe entfernen<\/h2>\n
c:\/>LOCALGROUP Gruppe1 \/DELETE Benutzer1<\/pre>\n
C:\\>net.exe LOCALGROUP \/DELETE Gruppe1\r\nC:\\>net.exe LOCALGROUP \/DELETE Gruppe2<\/pre>\n
C:\\>net.exe USER \/DELETE Benutzer1\r\nC:\\>net.exe USER \/DELETE Benutzer2<\/pre>\n
Benutzergruppe im SQL Server nutzen<\/h2>\n
Zugriff einrichten in zwei Stufen<\/h2>\n
![\"Aufruf](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_005.png\")
<\/p>\n![\"Dialog](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_006.png\")
<\/p>\n![\"Dialog](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_007.png\")
<\/p>\n![\"Erweiterter](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_008.png\")
<\/p>\n![\"Dialog](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_009.png\")
<\/p>\n![\"Dialog](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_010.png\")
<\/p>\n![\"Die](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_011.png\")
<\/p>\n![\"Standarddatenbank](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_012.png\")
<\/p>\nServerrolle einstellen<\/h2>\n
![\"Einstellen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_013.png\")
<\/p>\n\n
exec sp_srvrolepermission <Serverrolle><\/pre>\n
![\"Auflistung](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_014.png\")
<\/p>\nExperiment<\/h2>\n
Benutzerzuordnung<\/h2>\n
![\"Festlegen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_015.png\")
<\/p>\n\n
exec sp_dbfixedrolepermission <Datenbankrolle><\/pre>\n
Zugriff verbieten und erlauben<\/h2>\n
Benutzergruppe speichern<\/h2>\n
USE [master]\r\nGO\r\nCREATE LOGIN [DESKTOP-PC-I5\\Gruppe2] FROM WINDOWS WITH DEFAULT_DATABASE=[Suedsturm_SQL]\r\nGO\r\nUSE [Suedsturm_SQL]\r\nGO\r\nCREATE USER [DESKTOP-PC-I5\\Gruppe2] FOR LOGIN [DESKTOP-PC-I5\\Gruppe2]\r\nGO<\/pre>\n
ALTER ROLE [db_datareader] ADD MEMBER [DESKTOP-PC-I5\\Gruppe2]\r\nGO<\/pre>\n
ALTER ROLE [db_datareader] DROP MEMBER [DESKTOP-PC-I5\\Gruppe2]\r\nGO<\/pre>\n
Anmeldung für Benutzer statt Gruppe<\/h2>\n
Benutzergruppen im Objekt-Explorer<\/h2>\n
![\"Die](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_016.png\")
<\/p>\n![\"Die](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_017.png\")
<\/p>\nBerechtigungen für einzelne Datenbankobjekte<\/h2>\n
![\"Auswahl](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_018.png\")
<\/p>\n![\"Die](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_019.png\")
<\/p>\n![\"Festlegen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_020.png\")
<\/p>\nLese- und Schreibrechte prüfen<\/h2>\n
![\"Ein](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_021.png\")
<\/p>\nBenutzerdefinierte Datenbankrollen<\/h2>\n
![\"Hinzufügen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_022.png\")
<\/p>\n![\"Benennen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_023.png\")
<\/p>\n![\"Festlegen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_024.png\")
<\/p>\n![\"Zuweisen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_025.png\")
<\/p>\nVerschiedene Rechte auf verschiedenen Ebenen<\/h2>\n
\n
![\"Hinzufügen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1154_026.png\")
<\/p>\nZusammenfassung und Ausblick<\/h2>\n