Bernd Jungbluth, Horn (info@berndjungbluth.de)
Kennwörter. Sie sind ein mehr oder weniger notwendiges Übel, stellen Sie doch den Zugang zu Systemen sicher. Dennoch sind sie nicht selten eine Schwachstelle im Sicherheitskonzept, wie im aktuellen Szenario dieser Beitragsreihe. Für eine automatische Anmeldung am SQL Server wird der Anmeldename und das Kennwort in der Access-Applikation gespeichert. Dort aber lassen sich diese Informationen nicht ausreichend schützen. Dabei kann es so einfach sein. Mit der Windows-Authentifizierung sind die Anmeldedaten für den Zugang zum SQL Server nicht mehr erforderlich. In diesem Teil der Beitragsreihe lernen Sie die Vorteile der Windows-Authentifizierung kennen.
Warnung
Die beschriebenen Aktionen haben Auswirkungen auf Ihre SQL Server-Installation. Führen Sie die Aktionen nur in einer Testumgebung aus. Verwenden Sie unter keinen Umständen Ihren produktiven SQL Server!
Das aktuelle Berechtigungskonzept der Beispielumgebung basiert auf der SQL Server-Authentifizierung. Der Zugang zum SQL Server erfolgt über die Anmeldungen WaWiMa und WaWiPersonal. Ein Anwender braucht lediglich das Kennwort zu einer der beiden Anmeldungen und schon kann er mit den entsprechenden Rechten auf die Daten des SQL Servers zugreifen. Einen direkten Bezug zum tatsächlichen Anwender gibt es bei dieser Art der Authentifizierung nicht.
Das ist bei der Windows-Authentifizierung anders. Hier müssen Sie keinen Anmeldenamen mitsamt Kennwort anlegen, sondern sie verweisen lediglich auf das Windows-Benutzerkonto des Anwenders. Diese so erstellte Anmeldung ordnen Sie dann wie gewohnt der Datenbank zu. Dem dadurch in der Datenbank erstellten Benutzer erteilen Sie dort die Rechte über die Datenbankrollen. Es ändert sich also lediglich die Authentifizierung am SQL Server, die Autorisierung an der Datenbank und die darauf folgende Rechtevergabe bleibt gleich.
Nur haben Sie weniger Aufwand bei der Verwaltung der Anmeldungen und durch den Wegfall der Kennwörter erhalten Sie mehr Sicherheit. Mehr noch, denn durch den Verweis zum Windows-Benutzerkonto erfolgt der Datenzugriff immer mit direktem Bezug zum Anwender. Ein anonymer Zugriff ist nicht mehr möglich. Sie sehen, die Windows-Authentifizierung ist einfach und effektiv.
Sie kennen die Windows-Authentifizierung bereits von Ihrem Windows-Benutzerkonto. Das haben Sie bei der Installation des SQL Servers als Anmeldung zugeordnet. Sie finden es im SQL Server Management Studio unter Sicherheit|Anmeldungen. Diese Anmeldung ist Mitglied der Serverrolle sysadmin und bietet Ihnen somit alle Rechte innerhalb Ihres SQL Servers, weshalb sie sich nicht für einen adäquaten Test der Rechtevergabe eignet. Dazu benötigen Sie ein weiteres Windows-Benutzerkonto.
Ein Windows-Benutzerkonto
Möglicherweise arbeiten Sie mit Ihrem Rechner in einer Windows-Domäne und Ihr Windows-Benutzerkonto wird über ein Active Directory verwaltet. Vielleicht aber testen Sie die Beispiele dieser Beitragsreihe in einer Entwicklungsumgebung mit einem lokalen Windows-Benutzerkonto. Da das Anlegen eines Windows-Benutzerkontos im Active Directory an fehlenden Rechten oder mangelnder Bereitschaft Ihres IT-Systemadministrators scheitern könnte, legen Sie für die weitere Vorgehensweise ein lokales Windows-Benutzerkonto an. Dazu klicken Sie mit der rechten Maustaste auf das Windowslogo in der Taskleiste und wählen den Eintrag Computerverwaltung (siehe Bild 1). In der Computerverwaltung erweitern Sie auf der linken Seite den Ordner Lokale Benutzer und Gruppen.
Bild 1: Start der Computerverwaltung
Nach einem Rechtsklick auf den Unterordner Benutzer öffnen Sie mit dem Eintrag Neuer Benutzer den gleichnamigen Dialog. Hier geben Sie als Benutzernamen Bienlein ein. Anschließend sichern Sie das Benutzerkonto mit einem Kennwort in den Eingabefeldern Kennwort und Kennwort bestätigen. Eine Neuvergabe des Kennworts bei der ersten Verwendung des Windows-Benutzerkontos ist nicht erforderlich. Es handelt sich schließlich um ein Testkonto, dass Sie selbst verwenden. Daher können Sie die Option Benutzer muss Kennwort bei der nächsten Anmeldung ändern deaktivieren. Mit einem Klick auf Erstellen wird das neue Windows-Benutzerkonto angelegt (siehe Bild 2).
Bild 2: Windows-Benutzer Bienlein
Glückwunsch. Nun haben Sie auf Ihrem Rechner einen virtuellen Anwender namens Bienlein. Beenden Sie den Dialog mit der Schaltfläche Schließen.
Die Anmeldung Bienlein
Im nächsten Schritt erstellen Sie für das Windows-Benutzerkonto Bienlein eine Anmeldung in Ihrem SQL Server. Starten Sie das SQL Server Management Studio und melden Sie sich an der SQL Server-Instanz mit Ihrem Windows-Benutzerkonto oder einer anderen Anmeldung mit administrativen Rechten an.
Im SQL Server Management Studio navigieren Sie im Objekt-Explorer zum Ordner Sicherheit und erweitern dort den Unterordner Anmeldungen. Wählen Sie in dessen Kontextmenü den Eintrag Neue Anmeldung (siehe Bild 3) und klicken Sie in dem darauffolgenden Dialog auf die Schaltfläche Suchen.
Bild 3: Neue Anmeldung im SQL Server
In dem Auswahlfenster Benutzer oder Gruppe auswählen legen Sie den Verweis zu dem Windows-Benutzerkonto Bienlein fest. Der schnellste Weg ist die direkte Eingabe des Windows-Benutzerkontos und einem anschließenden Klick auf Namen überprüfen. Ist die Eingabe korrekt, wird diese durch Ihren Rechnernamen ergänzt (siehe Bild 4). Mit einem Klick auf OK übernehmen Sie die Auswahl.
Bild 4: Anmeldung mit Windows-Authentifizierung
Die Windows-Benutzerkonten Ihrer Domäne werden Sie über diesen Weg nicht finden. Hierfür müssen Sie in dem Auswahlfenster Benutzer oder Gruppe auswählen zunächst über die Schaltfläche Pfade den Suchpfad zu Ihrer Domäne festlegen. Anschließend können Sie wie oben beschrieben das Benutzerkonto aus Ihrem Active Directory auswählen.
Sie haben es bestimmt bemerkt. Die Option Windows-Authentifizierung ist im Dialog standardmäßig aktiviert. Aus gutem Grund. Schließlich empfiehlt Microsoft diese Authentifizierungsmethode. Die SQL Server-Authentifizierung hingegen sollte nur in Ausnahmefällen verwendet werden. Zum Beispiel, wenn für den Betrieb der Client-Applikation keine Windows-Benutzerkonten verfügbar sind.
Die weiteren Schritte sind Ihnen von den beiden Anmeldungen WaWiMa und WaWiPersonal bekannt. Als Erstes weisen Sie der neuen Anmeldung in der Auswahlliste Standarddatenbank die Datenbank WaWi_SQL zu. Sollte mit einer Client-Applikation eine Verbindung zum SQL Server ohne die explizite Angabe einer Datenbank erfolgen, wird bei dieser Anmeldung immer die Datenbank WaWi_SQL verwendet.
In der Seite Benutzerzuordnung autorisieren Sie die Anmeldung für den Zugriff auf die Datenbanken. Hierzu wählen Sie im oberen Bereich die Datenbank WaWi_SQL aus. Durch diese Auswahl wird in der Datenbank ein Benutzer erstellt. Den Namen dieses Benutzers sehen Sie neben der gewählten Datenbank in der Spalte Benutzer.
Zwar können Sie den Namen ändern, es ist jedoch nicht unbedingt empfehlenswert. Eines der obersten Gebote der Security ist die Einfachheit. Gestalten Sie die Vergabe und Pflege von Zugriffsberechtigungen so einfach wie möglich. Mit einem von der Anmeldung abweichenden Benutzernamen erhöhen Sie nur den Aufwand. Bei einer Änderung der Zugriffsrechte dieses Benutzers müssten Sie immer erst einmal nachschauen, zu welcher Windows-Authentifizierung er letztendlich gehört.
Ein Standardschema brauchen Sie nicht anzugeben. Ohne Angabe wird das Schema dbo verwendet. Die Bedeutung dieses Schemas sowie die Vorteile eigener Schemata ist das Thema einer der nächsten Beiträge.
Die Zugriffsrechte des neuen Benutzers legen Sie im unteren Bereich des Dialogs fest. Aktivieren Sie die Datenbankrollen db_datareader, db_datawriter und edb_execute (siehe Bild 5). Mit dieser Auswahl darf der Benutzer die Daten aller Tabellen lesen und ändern sowie alle gespeicherten Prozeduren ausführen. Die Zuordnung zur Datenbankrolle public können Sie nicht ändern. Jeder Benutzer ist hier standardmäßig Mitglied. Die Möglichkeiten und vor allem die Gefahren dieser Datenbankrolle lernen Sie im nächsten Beitrag kennen.
Bild 5: Benutzerzuordnung einer Anmeldung
Soweit so gut. Mit einem Klick auf OK legen Sie die neue Anmeldung an. Im Ordner Anmeldungen unter Sicherheit sehen Sie den neuen Eintrag Bienlein, wobei dem Namen Bienlein die Bezeichnung Ihres Rechners vorangestellt ist. Der Einfachheit halber wird im weiteren Text nur der Name des Windows-Benutzerkontos verwendet und auf den Hinweis des Rechnernamens verzichtet.
Mit der Anmeldung wurde der zugehörige Benutzer in der Datenbank WaWi_SQL erstellt. Wechseln Sie zur Datenbank WaWi_SQL und erweitern Sie dort den Ordner Sicherheit. Der Unterordner Benutzer listet nun neben den bekannten Einträgen WaWiMa und WaWiPersonal den neuen Benutzer Bienlein auf (siehe Bild 6).
Bild 6: Datenbankbenutzer Bienlein
Frau Bienlein arbeitet im Vertrieb. Daher soll sie dieselben Rechte erhalten wie der Benutzer WaWiMa. Diesem wird aktuell der Zugriff auf die Tabellen und gespeicherten Prozeduren der Personalabteilung verweigert. Um diese Einschränkungen festzulegen, öffnen Sie mit einem Doppelklick auf den Eintrag Bienlein den Dialog Datenbankbenutzer. Auf der Seite Sicherungsfähige Elemente legen Sie die Rechte für einzelne Tabellen und gespeicherte Prozeduren fest. Zur Auswahl dieser Objekte gibt es mehrere Wege. Einer dieser Wege erfolgt über das Schema. Klicken Sie auf Suchen und aktivieren Sie im Auswahlfenster Objekte hinzufügen die Option Alle Objekte, die dem Schema angehören (siehe Bild 7). Unter Schemaname wählen Sie das Schema dbo und bestätigen dies mit einem Klick auf OK.
Bild 7: Auswahl der Objekte nach Schema
Der Dialog Datenbankbenutzer listet nun unter Sicherungsfähige Elemente alle Objekte der Datenbank vom Schema dbo auf. Dort markieren Sie die Tabelle Bewerber und aktivieren im unteren Bereich in der Zeile Aktualisieren die Option Verweigern (siehe Bild 8). Mit den Rechten zur gespeicherten Prozedur pSelectGeburtstagsliste verfahren Sie ähnlich. Sie wählen die gespeicherte Prozedur im oberen Bereich aus und aktivieren dann im unteren Bereich in der Zeile Ausführen die Option Verweigern.
Bild 8: Rechtevergabe eines Benutzers
Das war noch nicht alles. Sie müssen noch weitere Zugriffsrechte verweigern. Um Ihnen die umständlichen Klicks zu ersparen und um gleichzeitig eine Dokumentation zu dieser Rechtevergabe zu erhalten, wählen Sie im oberen Teil des Dialogs unter Skript den Eintrag Skript für Aktion in Fenster „Neue Abfrage“ schreiben. Das SQL Server Management Studio zeigt Ihnen danach die T-SQL-Befehle zur Rechtevergabe in einer neuen Registerkarte. Genau hier werden Sie die Rechtevergabe vervollständigen. Doch vorher beenden Sie den Dialog Datenbankbenutzer mit einem Klick auf Abbrechen.
In der Registerkarte ergänzen Sie diese Zeile mit den Befehlen SELECT, INSERT und DELETE:
DENY UPDATE ON [dbo].[Bewerber] TO [Ihr Rechnername\Bienlein]
Danach sieht die Zeile wie folgt aus:
DENY SELECT, INSERT, UPDATE, DELETE ON [dbo].[Bewerber] TO [Ihr Rechnername\Bienlein]
Danach kopieren Sie die Zeile und fügen Sie zweimal in das Skript ein. Ersetzen Sie in der ersten eingefügten Zeile den Namen der Tabelle mit Mitarbeiter und in der zweiten mit Stellen:
DENY SELECT, INSERT, UPDATE, DELETE ON [dbo].[Mitarbeiter] TO [Ihr Rechnername \Bienlein] DENY SELECT, INSERT, UPDATE, DELETE ON [dbo].[Stellen] TO [Ihr Rechnername \Bienlein]
Die nächsten drei Zeilen mit GO, USE WaWi_SQL und einem weiteren GO sind für das Skript nicht erforderlich. Entfernen Sie diese Zeilen und ergänzen Sie anschließend das Skript mit entsprechenden Hinweisen und Kommentaren. Heraus kommt ein T-SQL-Skript wie in Bild 9, das Sie in Ihrer Dokumentation zur Rechtevergabe speichern. Mit einem Klick auf die Schaltfläche Ausführen erweitern Sie die Zugriffsrechte des Benutzers Bienlein.
Bild 9: Rechtevergabe per T-SQL
Wobei es sich bei dem Erweitern hier eher um ein Einschränken handelt. Grundsätzlich besitzt der Benutzer Bienlein durch die Zuordnung zu den Datenbankrollen db_datareader, db_datawriter und edb_execute Lese- und Schreibrechte an allen Tabellen der Datenbank sowie das Recht zum Ausführen aller gespeicherten Prozeduren. Der Zugriff auf die Tabellen Bewerber, Mitarbeiter, Stellen und der gespeicherten Prozedur pSelectGeburtstagsliste wird ihm jedoch durch das Recht DENY explizit verweigert – und dieses Recht steht über allen anderen.
Zur Kontrolle öffnen Sie erneut den Dialog Datenbankbenutzer mit einem Doppelklick auf den Eintrag Bienlein. Dieser zeigt Ihnen nun die erteilten Rechte in der Seite Sicherungsfähige Elemente (siehe Bild 10). Die zugeordneten Datenbankrollen sehen Sie in der Seite Mitgliedschaft.
Bild 10: Verweigerter Zugriff für Bienlein
Mit der Rechtevergabe des Benutzers ist das Erstellen der Anmeldung vollständig. Die neue Anmeldung basiert auf einer Windows-Authentifizierung, in diesem Fall auf dem Windows-Benutzerkonto Bienlein. Jetzt ist noch die Beispielapplikation an die neue Authentifizierungsmethode anzupassen.
Access und die Windows-Authentifizierung
Die Authentifizierung am SQL Server findet in der Beispielapplikation mit der Funktion fTabellenEinbinden statt. Diese ermittelt über die Access-Abfrage Anmeldedaten die zum aktuellen Anwender passende SQL Server-Anmeldung. Für die Mitarbeiter im Vertrieb ist das die Anmeldung WaWiMa, für die Kollegen in der Personalabteilung die Anmeldung WaWiPersonal. Die Zuordnungen wie die Anmeldedaten sind in den Tabellen Benutzer und Datenquellen hinterlegt. Zum Schutz dieser Daten und insbesondere der dort gespeicherten Kennwörter sind beide Tabellen als Systemobjekte definiert und somit nicht ohne weiteres sichtbar.
Der ganze Aufwand ist nur zum Schutz der Kennwörter zu den Anmeldungen WaWiMa und WaWiPersonal erforderlich. Diese dürfen lediglich den Entwicklern der Applikation beziehungsweise den Datenbankadministratoren bekannt sein. Den Anwendern und vor allem möglichen Angreifern soll das unerlaubte Ermitteln und Einsetzen dieser Kennwörter so schwer wie möglich gemacht werden.
Wobei letztere wohl eher mit einem Texteditor direkt in die ACCDB schauen. Was auf diesem Weg dort alles zu sehen ist, haben Sie im letzten Beitrag erfahren.
Mit der Windows-Authentifizierung fällt der komplette Aufwand weg. Das Speichern von Kennwörtern ist nicht mehr erforderlich. Die Zugriffsrechte ergeben sich durch das aktuell verwendete Windows-Benutzerkonto des Anwenders. Frau Bienlein greift nun mit der zu ihrem Windows-Benutzerkonto eingerichteten Anmeldung auf die Datenbank WaWi_SQL zu. Damit diese Art der Anmeldung funktioniert, muss die Verbindungszeichenfolge in der Beispielapplikation angepasst werden.
Öffnen Sie die Beispielapplikation WaWi v2 und wechseln Sie zur Funktion fOdbcPerTabelle im Modul OBDC. Hier wird die Verbindungszeichenfolge zusammengesetzt. Die nun anstehenden Änderungen werden die Funktion um einiges verkürzen. Es beginnt mit der Quelle der einzelnen Bestandteile einer Verbindungszeichenfolge, der Abfrage Anmeldedaten. Diese liefert die Bezeichnung des SQL Servers, den Namen der Datenbank sowie die zum aktuellen Anwender passende Anmeldung inklusive des Kennworts. Da die Anmeldedaten nicht mehr benötigt werden, ändern Sie in der folgenden Zeile die Quelle des Recordsets von Anmeldedaten in Datenquellen.
Set rsVerbindung = CurrentDb.OpenRecordset("Datenquellen", dbOpenSnapshot)
Durch den Wegfall der Anmeldedaten sind die Variablen strBenutzer und strKennwort ebenfalls nicht mehr notwendig. Daher löschen Sie die Deklaration der Variablen sowie diese beiden Zeilen:
If IsNull(rsVerbindung("Benutzer")) Then boKomplett = False If IsNull(rsVerbindung("Kennwort")) Then boKomplett = False
Aus dem gleichen Grund trennen Sie sich auch von diesen Zeilen:
";UID=" & rsVerbindung("Benutzer") & _
";PWD=" & fKennwortLesen(rsVerbindung("Kennwort"))
Jetzt ändern Sie den Eintrag Trusted_Connection=No in Trusted_Connection=Yes. Durch diesen Parameter wird bei der Verbindung zum SQL Server die aktuelle Windows-Anmeldung des Anwenders übergeben. Das Erstellen der Verbindungszeichenfolge sieht nun so aus:
''Datenquelle ermitteln Set rsVerbindung = CurrentDb.OpenRecordset( "Datenquellen", dbOpenSnapshot) If Not rsVerbindung.EOF Then ''Inhalte prüfen If IsNull(rsVerbindung("Server")) Then boKomplett = False If IsNull(rsVerbindung("Datenbank")) Then boKomplett = False ''Anmeldedaten vollständig If boKomplett = True Then ''Connection definieren fOdbcPerTabelle = _ "ODBC;DRIVER=ODBC Driver 17 for SQL Server" _ & ";Trusted_Connection=Yes" & _ ";Server=" & rsVerbindung("Server") & _ ";Database=" & rsVerbindung("Datenbank") End If Else ''Keine Anmeldedaten gefunden boKomplett = False End If
Natürlich könnte der Name des SQL Servers und der der Datenbank direkt in der Funktion eingetragen werden. Dadurch wäre die lokale Tabelle Datenquellen ebenso hinfällig. Aber warum sollten Sie auf diesen Komfort verzichten wollen Über die beiden Werte lässt sich die Access-Applikation recht einfach auf einen anderen SQL Server oder eine andere Datenbank umschalten. So sind Sie zum Beispiel in der Lage schnell zwischen Entwicklungsumgebung und Produktivumgebung zu wechseln. Dabei kann die Datenbank zur Entwicklungsumgebung unter einem anderen Namen im gleichen SQL Server liegen oder unter dem Originalnamen in einer anderen SQL Server-Instanz.
Fehlt der Name des SQL Servers beziehungsweise der Datenbank, erhalten Sie durch die Messagebox am Ende der Funktion eine Meldung. Diese können Sie noch etwas anpassen, denn sie prüft nicht mehr die Anmeldedaten, sondern lediglich die Verbindungsdaten:
''Verbindungsdaten unvollständig If boKomplett = False Then MsgBox "Die Verbindungsdaten sind nicht vollständig erfasst." & vbCrLf & "Bitte ergänzen Sie die fehlenden Informationen.", vbCritical, CurrentDb.Properties!AppTitle End If
Soweit zum Datenzugriff per ODBC der für die eingebundenen Tabellen und die Pass Through-Abfragen relevant ist. Die Beispielapplikation nutzt zusätzlich die Datenzugriffsmethode ADO und diese wiederum verwendet OLE DB für den Zugriff auf die Daten. Es ist also eine weitere Anpassung erforderlich.
Dazu wechseln Sie zur Funktion fAdoPerTabelle im Modul ADO. Die nun anstehenden Änderungen sind ähnlich der eben durchgeführten. Als erstes ändern Sie hier ebenfalls die Quelle des Recordsets in Datenquellen.
Set rsVerbindung = CurrentDb.OpenRecordset( "Datenquellen", dbOpenSnapshot)
Danach entfernen Sie die Deklarationen der Variablen strBenutzer und strKennwort sowie die folgenden Zeilen:
";User ID=" & rsVerbindung("Benutzer") & _
";Password=" & fKennwortLesen(rsVerbindung("Kennwort"))
Anschließend ergänzen Sie den Aufbau der Verbindungszeichenfolge mit dem Parameter Integrated Security. Mit diesem Parameter findet bei OLE DB die Übergabe der aktuellen Windows-Anmeldung statt. Der Parameter akzeptiert als Wert sowohl SSPI wie auch Yes. Sie sollten an dieser Stelle SSPI verwenden, denn der Wert Yes wird nicht von allen OLE DB-Treibern unterstützt. SSPI steht für Security Support Provider Interface. Diese Schnittstelle ermöglicht die Verwendung von Funktionen verfügbarer Sicherheitsmodelle, unter anderem das Prüfen einer Authentifizierung. Mit dem Eintrag Integrated Security haben die Zeilen zu den Parametern User ID und Password keine Bedeutung mehr. Weshalb Sie die beiden Zeilen nun löschen. Danach sollte der Aufbau der Verbindungszeichenfolge so aussehen:
fAdoPerTabelle = "Provider=MSOLEDBSQL;Integrated Security=SSPI;Server=" & rsVerbindung("Server") & ";Database=" & rsVerbindung("Datenbank")
Zum Abschluss passen Sie noch die Meldung am Ende der Funktion an. Am besten nutzen Sie denselben Text wie in der Funktion fOdbcPerTabelle.
Nach diesen Änderungen wird weder der Anmeldename noch das Kennwort zum Erstellen der Verbindungszeichenfolgen verwendet. Daher werden Sie die Quelle dieser Informationen nun ebenfalls löschen. Beide sind in der Tabelle Datenquellen hinterlegt. Bevor Sie die Tabelle ändern können, müssen Sie ihr zunächst den Status der Systemtabelle entziehen. Führen Sie dazu im VBA-Direktbereich die folgende Anweisung aus:
fTabelleAlsSystemObjekt "Datenquellen", False
Wiederholen Sie die Anweisung für die Tabelle Benutzer. Hier gibt es gleich eine weitere Änderung. Danach wechseln Sie zu Access in den Navigationsbereich und öffnen die Tabelle Datenquellen im Entwurfsmodus. Entfernen Sie die nicht mehr benötigten Spalten Benutzer und Kennwort und speichern Sie die neue Struktur der Tabelle. Anschließend öffnen Sie die Datenblattansicht. Ohne die Information der Anmeldedaten sehen Sie jetzt zwei Datensätze mit gleichem Inhalt. Beide zeigen die Bezeichnung zu Ihrem SQL Server und zur Datenbank WaWi_SQL. Löschen Sie einen der Einträge. Und wenn Sie schon beim Löschen sind, entfernen Sie gleich noch die Tabelle Benutzer und die Access-Abfrage Anmeldedaten. Jegliche Information dieser Tabelle sowie der Abfrage ist für die Windows-Authentifizierung irrelevant.
Zugegeben, das waren jetzt viele Änderungen. Im Umkehrschluss zeigt dies aber sehr deutlich, von wieviel Ballast Sie sich bei einer Windows-Authentifizierung trennen. Zum Test des neuen Anmeldeverfahrens ist ein Neustart der Beispielapplikation erforderlich, denn es besteht bereits eine Verbindung zum SQL Server. Sind Sie der Installationsanleitung gefolgt, handelt es sich hierbei um die Anmeldung WaWiPersonal und somit um eine Anmeldung basierend auf einer SQL Server-Authentifizierung. Wie Sie im letzten Beitrag erfahren haben, werden Sie solche Verbindungen nur durch einen Neustart der Access-Applikation wieder los.
Ein Neustart öffnet das unsichtbare Formular Verbindung, das die Funktion fTabellenEinbinden und dort wiederum die eben angepasste Funktion fOdbcPerTabelle ausführt. Nachdem die Funktion fTabellenEinbinden alle Tabellen neu verknüpft und die Verbindungszeichenfolgen der Pass Through-Abfragen angepasst hat, wird das Formular Verbindung geschlossen und das Formular Start geöffnet.
Gut, aktuell sind Sie mit Ihrem Windows-Benutzerkonto angemeldet und mit diesem haben Sie im SQL Server administrative Rechte. Ein Test der Zugriffsrechte ist somit nicht aussagekräftig. Dennoch können Sie sich die aktuelle Verbindungsart anzeigen lassen. Dazu fahren Sie mit der Maus über eine der eingebundenen Tabellen. Der zugehörige Tooltip zeigt Ihnen die Verbindungszeichenfolge. Dort sehen Sie den Eintrag Trusted_Connection=Yes (siehe Bild 11).
Bild 11: Eingebundene Tabelle per Trusted Connection
Das ist als Test natürlich nicht zufriedenstellend. Für einen korrekten Test starten Sie die Beispielapplikation mit den Rechten des Anwenders Bienlein. Dazu gibt es mehrere Wege, einer umständlicher als der andere. Ein eher einfacher Weg führt über die Taskleiste. Sollten Sie Access dort noch nicht angeheftet haben, drücken Sie die Windowstaste und gehen Sie in der Auflistung der Applikationen zu dem Access-Symbol. Markieren Sie das Icon und ziehen Sie es mit gedrückter Maustaste in die Taskleiste.
Nun klicken Sie mit der rechten Maustaste und gedrückter Umschalt-Taste auf das Access-Symbol in der Taskleiste und wählen Als anderer Benutzer ausführen. Sie sehen den Eintrag nicht Dann haben Sie Access noch geöffnet. Schließen Sie Access und wiederholen Sie den Vorgang. In dem folgenden Anmeldedialog geben Sie die Anmeldedaten des Anwenders Bienlein ein (siehe Bild 12).
Bild 12: Anmeldung als Windows-Benutzer Bienlein
Mit einem Klick auf OK startet Access nun mit den Rechten des Windows-Benutzerkontos Bienlein. In Access müssen Sie als erstes den Lizenzbestimmungen und den Datenschutzeinstellungen zustimmen, bevor Sie über Öffnen die Access-Applikation WaWi v2 starten. Hier bestätigen Sie noch den Sicherheitshinweis mit einem Klick auf Inhalt aktivieren und schon arbeiten Sie als Frau Bienlein mit der Beispielapplikation und den Daten der SQL Server-Datenbank WaWi_SQL. Das erkennen Sie zum einen im Titel der Applikation und zum anderen am Start-Formular. Beide beinhalten den Namen Bienlein. Zudem bietet Ihnen das Start-Formular nur die Schaltflächen des Vertriebs an. Geregelt wird dies mit der Formularsteuerung, die abhängig vom angemeldeten Anwender nur die erlaubten Schaltflächen freigibt. Klicken Sie doch einmal auf die Schaltflächen. Als Ergebnis sehen Sie die gewünschten Daten. Die Datenermittlung fand über ODBC per eingebundene Tabellen und Pass Through-Abfragen sowie im Formular Artikel per ADO und OLE DB statt. Die gewährten Zugriffsrechte für Frau Bienlein wären somit erfolgreich getestet.
Doch wie sieht es mit den verweigerten Zugriffen aus Dazu öffnen Sie im Navigationsbereich die Pass Through-Abfrage ptSelectGeburtstagsliste. Anstelle der Geburtstagsliste erhalten Sie die Fehlermeldung aus Bild 13. Das ist korrekt, führt die Pass Through-Abfrage doch die gespeicherte Prozedur pSelectGeburtstagsliste aus und zu dieser haben Sie Frau Bienlein den Zugriff explizit verweigert.
Bild 13: Fehlende EXECUTE-Berechtigung
Die Anmeldung Stromberg
Beim aktuellen Stand der Rechtevergabe hat der Kollege Stromberg aus der Personalabteilung das Nachsehen. Durch die eben entfernte Anmeldesteuerung fehlt die Zuordnung seines Windows-Benutzerkontos zur Anmeldung WaWiPersonal. Sie wird auch nicht mehr benötigt. Anstelle dessen soll für das Windows-Benutzerkonto Stromberg eine eigene Anmeldung im SQL Server erstellt werden.
Dazu brauchen Sie zunächst einen weiteren Windows-Benutzer. Öffnen Sie erneut die Computerverwaltung, wechseln Sie dort zum Eintrag Lokale Benutzer und Gruppen und wählen Sie im Kontextmenü des Ordners Benutzer den Eintrag Neuer Benutzer. Im folgenden Dialog erfassen Sie die Daten zum Kollegen Stromberg wie in Bild 14 und legen das neue Windows-Benutzerkonto mit einem Klick auf Erstellen an. Danach beenden Sie den Dialog und die Computerverwaltung.
Bild 14: Windows-Benutzer Stromberg
Anschließend gehen Sie zum SQL Server Management Studio, navigieren über Sicherheit zum Ordner Anmeldungen und klicken in dessen Kontextmenü auf Neue Anmeldung. Im Dialog Anmeldung – Neu wählen Sie über Suchen das eben erstellte Windows-Benutzerkonto Stromberg aus, legen als Standarddatenbank WaWi_SQL fest und wechseln zur Seite Benutzerzuordnung. Hier aktivieren Sie die Datenbank WaWi_SQL sowie die Datenbankrollen db_datareader, db_datawriter und edb_execute. Mit einem Klick auf OK legen Sie die Anmeldung sowie den zugehörigen Benutzer in der Datenbank mitsamt den Zugriffsrechten an.
Um die neue Anmeldung zu testen, klicken Sie mit der rechten Maustaste und gedrückter Umschalt-Taste auf das Access-Symbol in der Taskleiste und wählen Als anderer Benutzer ausführen. Dieses Mal geben Sie im Anmeldedialog die Daten des Kollegen Stromberg ein. Nach einem Klick auf OK startet Access mit den Rechten des Windows-Benutzerkontos Stromberg und verlangt auch für dieses eine Bestätigung der Lizenzbestimmungen und Datenschutzeinstellungen. Nachdem Sie die rechtlichen Punkte geklärt haben, öffnen Sie die Beispielapplikation WaWi v2 und klicken auf die Schaltfläche Inhalte aktivieren. Sie sehen das Start-Formular mit dem Namen Stromberg und den aktiven Schaltflächen der Personal-Abteilung (siehe Bild 15). Testen Sie die neue Anmeldung mit den Schaltflächen Geburtstagsliste und Bewerber. Beide liefern Ihnen die angeforderten Daten. Womit der Test der Anmeldung Stromberg ebenfalls erfolgreich abgeschlossen wäre.
Bild 15: Start-Formular für Stromberg
Eine Anmeldung für eine Windows-Gruppe
Bisher kennen Sie von dem Beispielunternehmen nur Frau Bienlein und Herrn Stromberg. Dabei gibt es noch weitere Kollegen, die mit den Daten der SQL Server-Datenbank WaWi_SQL arbeiten. Für diese Mitarbeiter müssten Sie die entsprechenden Anmeldungen im SQL Server anlegen – oder Sie verwenden stattdessen Windows-Gruppen.
Es gibt viele Möglichkeiten zur Gruppenbildung. Eine oft verwendete Variante bildet die Abteilungen eines Unternehmens ab. Pro Abteilung wird eine Windows-Gruppe erstellt und dieser die Windows-Benutzerkonten der entsprechenden Mitarbeiter zugeordnet. In der Beispielumgebung wäre das eine Gruppe für den Vertrieb und eine weitere für die Personalabteilung. Diesen Gruppen geben Sie dann sowohl in Ihrem Netzwerk wie im SQL Server die entsprechenden Rechte.
Am besten denken Sie von Anfang an in Gruppen. Selbst wenn in einer Abteilung nur eine Person arbeitet. Der Vorteil liegt auf der Hand. Ordnen Sie die Zugriffsrechte der Person zu, müssen Sie dies bei einem neuen Kollegen wiederholen. Erstellen Sie jedoch eine Gruppe und vergeben dieser die Zugriffsrechte, ist das Windows-Benutzerkonto des neuen Mitarbeiters lediglich in die Gruppe aufzunehmen. Die mühsame Vergabe von Zugriffsrechten an den einzelnen Windows-Benutzerkonten entfällt.
Ähnlich ist es im SQL Server. Hier legen Sie nicht pro Windows-Benutzerkonto eine Anmeldung an, sondern nur für die Windows-Gruppen. Durch eine solche Anmeldung erhalten alle Mitglieder der jeweiligen Windows-Gruppe den Zugang zum SQL Server. Die Zugriffsrechte auf die Daten ergeben sich wie bisher durch die Zuordnung der Anmeldung zu den einzelnen Datenbanken. Doch der Reihe nach. Als erstes benötigen Sie Windows-Gruppen.
Öffnen Sie die Computerverwaltung aufs Neue. Dieses Mal markieren Sie im Ordner Lokale Benutzer und Gruppen den Eintrag Gruppen und wählen aus dessen Kontextmenü Neue Gruppe. Nennen Sie die Gruppe Vertrieb und klicken Sie auf Hinzufügen. In dem Auswahldialog geben Sie Bienlein ein und beenden die Auswahl mit OK. Zurück im Dialog Neue Gruppe sehen Sie nun das Windows-Benutzerkonto Bienlein als Mitglied der Gruppe Vertrieb (siehe Bild 16). Bestätigen Sie die neue Gruppe mit Erstellen und wiederholen Sie den Vorgang für eine weitere Gruppe mit der Bezeichnung Personal. Dieser ordnen Sie das Windows-Benutzerkonto Stromberg zu. Nach einem weiteren Klick auf Erstellen schließen Sie den Dialog mit der Schaltfläche OK.
Bild 16: Windows-Gruppe Vertrieb
Danach legen Sie im SQL Server Management Studio für beide Gruppen die Anmeldungen an. Dabei gehen Sie zunächst genauso vor wie bei einer Anmeldung zu einem Windows-Benutzerkonto. Erneut erweitern Sie den Ordner Sicherheit und wählen im Kontextmenü des Unterordners Anmeldungen den Eintrag Neue Anmeldung. Im Dialog öffnen Sie über Suchen die Auswahl Benutzer oder Gruppe auswählen und geben die Windows-Gruppe Personal ein. Ein Klick auf Namen überprüfen liefert Ihnen jedoch nicht die gewünschte Windows-Gruppe. Stattdessen erhalten Sie eine Fehlermeldung mit der Aussage, dass der angegebene Benutzer oder das integrierte Sicherheitsprinzipal nicht existiert. Nein, Sie haben nichts falsch gemacht. Sie müssen Ihre Auswahl nur etwas konkretisieren. Dazu klicken Sie auf Objekttypen und aktivieren in dem folgenden Dialog die Option Gruppen (siehe Bild 17).
Bild 17: Die fehlende Grundeinstellung
Obwohl Microsoft die Verwendung von Gruppen ausdrücklich empfiehlt, scheint es hier dennoch an der entsprechenden Grundeinstellung zu fehlen. Irgendwie hat Microsoft an dieser Stelle zudem etwas Anpassungsschwierigkeiten, denn Sie müssen die Option immer wieder aufs Neue aktivieren, wenn Sie eine Anmeldung zu einer Windows-Gruppe erstellen möchten. Mit dieser erweiterten Suche wird die Windows-Gruppe nach einem Klick auf Namen überprüfen dann auch gefunden. Die Auswahl übernehmen Sie mit einem Klick auf OK. Zurück im Dialog Anmeldung – Neu wählen Sie noch als Standarddatenbank WaWi_SQL aus, bevor Sie zur Seite Benutzerzuordnung wechseln.
Die Anmeldung zur Windows-Gruppe Personal soll die gleichen Rechte wie die Anmeldung Stromberg erhalten. Dazu aktivieren Sie im oberen Teil des Dialogs die Datenbank WaWi_SQL und im unteren Bereich die Datenbankrollen db_datareader, db_datawriter und edb_execute. Soweit so gut, nur klicken Sie jetzt bitte nicht auf OK. Vielmehr verwenden Sie an dieser Stelle wieder die Schaltfläche Skript, wodurch Sie die entsprechenden T-SQL-Befehle zur Rechtevergabe in einer neuen Registerkarte erhalten. Den Dialog schließen Sie mit Abbrechen.
In der Registerkarte können Sie die T-SQL-Befehle nun etwas strukturieren, mit entsprechenden Kommentaren ergänzen und letztendlich als Dokumentation unter dem Namen Rechtevergabe Personal speichern (siehe Bild 18).
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo