Bernd Jungbluth, Horn (info@berndjungbluth.de)<\/p>\n
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.<\/b><\/p>\nWarnung<\/h2>\n
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!<\/p>\n
Das aktuelle Berechtigungskonzept der Beispielumgebung basiert auf der SQL Server-Authentifizierung. Der Zugang zum SQL Server erfolgt über die Anmeldungen WaWiMa <\/b>und WaWiPersonal<\/b>. 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. <\/p>\n
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. <\/p>\n
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. <\/p>\n
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<\/b>. Diese Anmeldung ist Mitglied der Serverrolle sysadmin <\/b>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.<\/p>\nEin Windows-Benutzerkonto<\/h2>\n
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<\/b> (siehe Bild 1). In der Computerverwaltung erweitern Sie auf der linken Seite den Ordner Lokale Benutzer und Gruppen<\/b>.<\/p>\n
<\/p>\n
Bild 1: Start der Computerverwaltung<\/span><\/b><\/p>\n Nach einem Rechtsklick auf den Unterordner Benutzer <\/b>öffnen Sie mit dem Eintrag Neuer Benutzer <\/b>den gleichnamigen Dialog. Hier geben Sie als Benutzernamen Bienlein <\/b>ein. Anschließend sichern Sie das Benutzerkonto mit einem Kennwort in den Eingabefeldern Kennwort <\/b>und Kennwort <\/b>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 <\/b>deaktivieren. Mit einem Klick auf Erstellen <\/b>wird das neue Windows-Benutzerkonto angelegt (siehe Bild 2).<\/p>\n Bild 2: Windows-Benutzer Bienlein<\/span><\/b><\/p>\n Glückwunsch. Nun haben Sie auf Ihrem Rechner einen virtuellen Anwender namens Bienlein<\/b>. Beenden Sie den Dialog mit der Schaltfläche Schließen<\/b>. <\/p>\n Im nächsten Schritt erstellen Sie für das Windows-Benutzerkonto Bienlein <\/b>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.<\/p>\n Im SQL Server Management Studio navigieren Sie im Objekt-Explorer zum Ordner Sicherheit <\/b>und erweitern dort den Unterordner Anmeldungen<\/b>. Wählen Sie in dessen Kontextmenü den Eintrag Neue Anmeldung <\/b>(siehe Bild 3) und klicken Sie in dem darauffolgenden Dialog auf die Schaltfläche Suchen<\/b>.<\/p>\n Bild 3: Neue Anmeldung im SQL Server<\/span><\/b><\/p>\n In dem Auswahlfenster Benutzer oder Gruppe auswählen <\/b>legen Sie den Verweis zu dem Windows-Benutzerkonto Bienlein <\/b>fest. Der schnellste Weg ist die direkte Eingabe des Windows-Benutzerkontos und einem anschließenden Klick auf Namen überprüfen<\/b>. Ist die Eingabe korrekt, wird diese durch Ihren Rechnernamen ergänzt (siehe Bild 4). Mit einem Klick auf OK <\/b>übernehmen Sie die Auswahl.<\/p>\n Bild 4: Anmeldung mit Windows-Authentifizierung<\/span><\/b><\/p>\n 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 <\/b>zunächst über die Schaltfläche Pfade <\/b>den Suchpfad zu Ihrer Domäne festlegen. Anschließend können Sie wie oben beschrieben das Benutzerkonto aus Ihrem Active Directory auswählen.<\/p>\n Sie haben es bestimmt bemerkt. Die Option Windows-Authentifizierung <\/b>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.<\/p>\n Die weiteren Schritte sind Ihnen von den beiden Anmeldungen WaWiMa <\/b>und WaWiPersonal <\/b>bekannt. Als Erstes weisen Sie der neuen Anmeldung in der Auswahlliste Standarddatenbank <\/b>die Datenbank WaWi_SQL <\/b>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 <\/b>verwendet.<\/p>\n In der Seite Benutzerzuordnung <\/b>autorisieren Sie die Anmeldung für den Zugriff auf die Datenbanken. Hierzu wählen Sie im oberen Bereich die Datenbank WaWi_SQL <\/b>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<\/b>.<\/p>\n 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. <\/p>\n Ein Standardschema brauchen Sie nicht anzugeben. Ohne Angabe wird das Schema dbo <\/b>verwendet. Die Bedeutung dieses Schemas sowie die Vorteile eigener Schemata ist das Thema einer der nächsten Beiträge.<\/p>\n Die Zugriffsrechte des neuen Benutzers legen Sie im unteren Bereich des Dialogs fest. Aktivieren Sie die Datenbankrollen db_datareader<\/b>, db_datawriter <\/b>und edb_execute <\/b>(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 <\/b>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.<\/p>\n Bild 5: Benutzerzuordnung einer Anmeldung<\/span><\/b><\/p>\n Soweit so gut. Mit einem Klick auf OK <\/b>legen Sie die neue Anmeldung an. Im Ordner Anmeldungen <\/b>unter Sicherheit <\/b>sehen Sie den neuen Eintrag Bienlein<\/b>, wobei dem Namen Bienlein <\/b>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.<\/p>\n Mit der Anmeldung wurde der zugehörige Benutzer in der Datenbank WaWi_SQL <\/b>erstellt. Wechseln Sie zur Datenbank WaWi_SQL <\/b>und erweitern Sie dort den Ordner Sicherheit<\/b>. Der Unterordner Benutzer <\/b>listet nun neben den bekannten Einträgen WaWiMa <\/b>und WaWiPersonal <\/b>den neuen Benutzer Bienlein <\/b>auf (siehe Bild 6). <\/p>\n Bild 6: Datenbankbenutzer Bienlein<\/span><\/b><\/p>\n Frau Bienlein arbeitet im Vertrieb. Daher soll sie dieselben Rechte erhalten wie der Benutzer WaWiMa<\/b>. 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 <\/b>den Dialog Datenbankbenutzer<\/b>. Auf der Seite Sicherungsfähige Elemente <\/b>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 <\/b>und aktivieren Sie im Auswahlfenster Objekte hinzufügen <\/b>die Option Alle Objekte, die dem Schema angehören <\/b>(siehe Bild 7). Unter Schemaname <\/b>wählen Sie das Schema dbo <\/b>und bestätigen dies mit einem Klick auf OK<\/b>. <\/p>\n Bild 7: Auswahl der Objekte nach Schema<\/span><\/b><\/p>\n Der Dialog Datenbankbenutzer <\/b>listet nun unter Sicherungsfähige Elemente <\/b>alle Objekte der Datenbank vom Schema dbo <\/b>auf. Dort markieren Sie die Tabelle Bewerber <\/b>und aktivieren im unteren Bereich in der Zeile Aktualisieren <\/b>die Option Verweigern <\/b>(siehe Bild 8). Mit den Rechten zur gespeicherten Prozedur pSelectGeburtstagsliste <\/b>verfahren Sie ähnlich. Sie wählen die gespeicherte Prozedur im oberen Bereich aus und aktivieren dann im unteren Bereich in der Zeile Ausführen <\/b>die Option Verweigern<\/b>. <\/p>\n Bild 8: Rechtevergabe eines Benutzers<\/span><\/b><\/p>\n 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 <\/b>den Eintrag Skript für Aktion in Fenster „Neue Abfrage“ schreiben<\/b>. 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 <\/b>mit einem Klick auf Abbrechen<\/b>.<\/p>\n In der Registerkarte ergänzen Sie diese Zeile mit den Befehlen SELECT<\/b>, INSERT <\/b>und DELETE<\/b>: <\/p>\n Danach sieht die Zeile wie folgt aus:<\/p>\n 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 <\/b>und in der zweiten mit Stellen<\/b>:<\/p>\n Die nächsten drei Zeilen mit GO<\/b>, USE WaWi_SQL <\/b>und einem weiteren GO <\/b>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 <\/b>erweitern Sie die Zugriffsrechte des Benutzers Bienlein<\/b>. <\/p>\n Bild 9: Rechtevergabe per T-SQL<\/span><\/b><\/p>\n Wobei es sich bei dem Erweitern hier eher um ein Einschränken handelt. Grundsätzlich besitzt der Benutzer Bienlein <\/b>durch die Zuordnung zu den Datenbankrollen db_datareader<\/b>, db_datawriter <\/b>und edb_execute <\/b>Lese- und Schreibrechte an allen Tabellen der Datenbank sowie das Recht zum Ausführen aller gespeicherten Prozeduren. Der Zugriff auf die Tabellen Bewerber<\/b>, Mitarbeiter<\/b>, Stellen <\/b>und der gespeicherten Prozedur pSelectGeburtstagsliste <\/b>wird ihm jedoch durch das Recht DENY <\/b>explizit verweigert – und dieses Recht steht über allen anderen. <\/p>\n Zur Kontrolle öffnen Sie erneut den Dialog Datenbankbenutzer <\/b>mit einem Doppelklick auf den Eintrag Bienlein<\/b>. Dieser zeigt Ihnen nun die erteilten Rechte in der Seite Sicherungsfähige Elemente <\/b>(siehe Bild 10). Die zugeordneten Datenbankrollen sehen Sie in der Seite Mitgliedschaft<\/b>. <\/p>\n Bild 10: Verweigerter Zugriff für Bienlein<\/span><\/b><\/p>\n 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<\/b>. Jetzt ist noch die Beispielapplikation an die neue Authentifizierungsmethode anzupassen.<\/p>\n Die Authentifizierung am SQL Server findet in der Beispielapplikation mit der Funktion fTabellenEinbinden <\/b>statt. Diese ermittelt über die Access-Abfrage Anmeldedaten <\/b>die zum aktuellen Anwender passende SQL Server-Anmeldung. Für die Mitarbeiter im Vertrieb ist das die Anmeldung WaWiMa<\/b>, für die Kollegen in der Personalabteilung die Anmeldung WaWiPersonal<\/b>. Die Zuordnungen wie die Anmeldedaten sind in den Tabellen Benutzer <\/b>und Datenquellen <\/b>hinterlegt. Zum Schutz dieser Daten und insbesondere der dort gespeicherten Kennwörter sind beide Tabellen als Systemobjekte definiert und somit nicht ohne weiteres sichtbar. <\/p>\n Der ganze Aufwand ist nur zum Schutz der Kennwörter zu den Anmeldungen WaWiMa <\/b>und WaWiPersonal <\/b>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.<\/p>\n 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.<\/p>\n 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 <\/b>zu. Damit diese Art der Anmeldung funktioniert, muss die Verbindungszeichenfolge in der Beispielapplikation angepasst werden.<\/p>\n Öffnen Sie die Beispielapplikation WaWi v2 <\/b>und wechseln Sie zur Funktion fOdbcPerTabelle <\/b>im Modul OBDC<\/b>. 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<\/b>. 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.<\/p>\n Durch den Wegfall der Anmeldedaten sind die Variablen strBenutzer <\/b>und strKennwort <\/b>ebenfalls nicht mehr notwendig. Daher löschen Sie die Deklaration der Variablen sowie diese beiden Zeilen:<\/p>\n Aus dem gleichen Grund trennen Sie sich auch von diesen Zeilen:<\/p>\n Jetzt ändern Sie den Eintrag Trusted_Connection=No <\/b>in Trusted_Connection=Yes<\/b>. 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:<\/p>\n 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 <\/b>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.<\/p>\n 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:<\/p>\n 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. <\/p>\n Dazu wechseln Sie zur Funktion fAdoPerTabelle <\/b>im Modul ADO<\/b>. Die nun anstehenden Änderungen sind ähnlich der eben durchgeführten. Als erstes ändern Sie hier ebenfalls die Quelle des Recordsets in Datenquellen.<\/p>\n Danach entfernen Sie die Deklarationen der Variablen strBenutzer <\/b>und strKennwort <\/b>sowie die folgenden Zeilen:<\/p>\n Anschließend ergänzen Sie den Aufbau der Verbindungszeichenfolge mit dem Parameter Integrated Security<\/b>. Mit diesem Parameter findet bei OLE DB die Übergabe der aktuellen Windows-Anmeldung statt. Der Parameter akzeptiert als Wert sowohl SSPI <\/b>wie auch Yes<\/b>. Sie sollten an dieser Stelle SSPI <\/b>verwenden, denn der Wert Yes <\/b>wird nicht von allen OLE DB-Treibern unterstützt. SSPI <\/b>steht für Security Support Provider Interface<\/b>. Diese Schnittstelle ermöglicht die Verwendung von Funktionen verfügbarer Sicherheitsmodelle, unter anderem das Prüfen einer Authentifizierung. Mit dem Eintrag Integrated Security <\/b>haben die Zeilen zu den Parametern User ID <\/b>und Password <\/b>keine Bedeutung mehr. Weshalb Sie die beiden Zeilen nun löschen. Danach sollte der Aufbau der Verbindungszeichenfolge so aussehen:<\/p>\n Zum Abschluss passen Sie noch die Meldung am Ende der Funktion an. Am besten nutzen Sie denselben Text wie in der Funktion fOdbcPerTabelle<\/b>. <\/p>\n 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 <\/b>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:<\/p>\n Wiederholen Sie die Anweisung für die Tabelle Benutzer<\/b>. Hier gibt es gleich eine weitere Änderung. Danach wechseln Sie zu Access in den Navigationsbereich und öffnen die Tabelle Datenquellen <\/b>im Entwurfsmodus. Entfernen Sie die nicht mehr benötigten Spalten Benutzer <\/b>und Kennwort <\/b>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<\/b>. Löschen Sie einen der Einträge. Und wenn Sie schon beim Löschen sind, entfernen Sie gleich noch die Tabelle Benutzer <\/b>und die Access-Abfrage Anmeldedaten<\/b>. Jegliche Information dieser Tabelle sowie der Abfrage ist für die Windows-Authentifizierung irrelevant. <\/p>\n <\/p>\n 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 <\/b>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.<\/p>\n Ein Neustart öffnet das unsichtbare Formular Verbindung<\/b>, das die Funktion fTabellenEinbinden <\/b>und dort wiederum die eben angepasste Funktion fOdbcPerTabelle <\/b>ausführt. Nachdem die Funktion fTabellenEinbinden <\/b>alle Tabellen neu verknüpft und die Verbindungszeichenfolgen der Pass Through-Abfragen angepasst hat, wird das Formular Verbindung <\/b>geschlossen und das Formular Start <\/b>geöffnet. <\/p>\n 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 <\/b>(siehe Bild 11).<\/p>\n Bild 11: Eingebundene Tabelle per Trusted Connection<\/span><\/b><\/p>\n Das ist als Test natürlich nicht zufriedenstellend. Für einen korrekten Test starten Sie die Beispielapplikation mit den Rechten des Anwenders Bienlein<\/b>. 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. <\/p>\n 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 <\/b>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 <\/b>ein (siehe Bild 12).<\/p>\n Bild 12: Anmeldung als Windows-Benutzer Bienlein<\/span><\/b><\/p>\n Mit einem Klick auf OK <\/b>startet Access nun mit den Rechten des Windows-Benutzerkontos Bienlein<\/b>. In Access müssen Sie als erstes den Lizenzbestimmungen und den Datenschutzeinstellungen zustimmen, bevor Sie über Öffnen <\/b>die Access-Applikation WaWi v2 <\/b>starten. Hier bestätigen Sie noch den Sicherheitshinweis mit einem Klick auf Inhalt aktivieren <\/b>und schon arbeiten Sie als Frau Bienlein mit der Beispielapplikation und den Daten der SQL Server-Datenbank WaWi_SQL<\/b>. Das erkennen Sie zum einen im Titel der Applikation und zum anderen am Start-Formular. Beide beinhalten den Namen Bienlein<\/b>. 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 <\/b>per ADO und OLE DB statt. Die gewährten Zugriffsrechte für Frau Bienlein wären somit erfolgreich getestet. <\/p>\n Doch wie sieht es mit den verweigerten Zugriffen aus Dazu öffnen Sie im Navigationsbereich die Pass Through-Abfrage ptSelectGeburtstagsliste<\/b>. Anstelle der Geburtstagsliste erhalten Sie die Fehlermeldung aus Bild 13. Das ist korrekt, führt die Pass Through-Abfrage doch die gespeicherte Prozedur pSelectGeburtstagsliste <\/b>aus und zu dieser haben Sie Frau Bienlein den Zugriff explizit verweigert.<\/p>\n Bild 13: Fehlende EXECUTE-Berechtigung<\/span><\/b><\/p>\n 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<\/b>. Sie wird auch nicht mehr benötigt. Anstelle dessen soll für das Windows-Benutzerkonto Stromberg <\/b>eine eigene Anmeldung im SQL Server erstellt werden. <\/p>\n Dazu brauchen Sie zunächst einen weiteren Windows-Benutzer. Öffnen Sie erneut die Computerverwaltung, wechseln Sie dort zum Eintrag Lokale Benutzer und Gruppen <\/b>und wählen Sie im Kontextmenü des Ordners Benutzer <\/b>den Eintrag Neuer Benutzer<\/b>. Im folgenden Dialog erfassen Sie die Daten zum Kollegen Stromberg <\/b>wie in Bild 14 und legen das neue Windows-Benutzerkonto mit einem Klick auf Erstellen <\/b>an. Danach beenden Sie den Dialog und die Computerverwaltung.<\/p>\n Bild 14: Windows-Benutzer Stromberg<\/span><\/b><\/p>\n Anschließend gehen Sie zum SQL Server Management Studio, navigieren über Sicherheit <\/b>zum Ordner Anmeldungen <\/b>und klicken in dessen Kontextmenü auf Neue Anmeldung<\/b>. Im Dialog Anmeldung – Neu <\/b>wählen Sie über Suchen <\/b>das eben erstellte Windows-Benutzerkonto Stromberg <\/b>aus, legen als Standarddatenbank WaWi_SQL <\/b>fest und wechseln zur Seite Benutzerzuordnung<\/b>. Hier aktivieren Sie die Datenbank WaWi_SQL <\/b>sowie die Datenbankrollen db_datareader<\/b>, db_datawriter <\/b>und edb_execute<\/b>. Mit einem Klick auf OK <\/b>legen Sie die Anmeldung sowie den zugehörigen Benutzer in der Datenbank mitsamt den Zugriffsrechten an.<\/p>\n 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<\/b>. Dieses Mal geben Sie im Anmeldedialog die Daten des Kollegen Stromberg ein. Nach einem Klick auf OK <\/b>startet Access mit den Rechten des Windows-Benutzerkontos Stromberg <\/b>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 <\/b>und klicken auf die Schaltfläche Inhalte aktivieren<\/b>. Sie sehen das Start-Formular mit dem Namen Stromberg <\/b>und den aktiven Schaltflächen der Personal-Abteilung (siehe Bild 15). Testen Sie die neue Anmeldung mit den Schaltflächen Geburtstagsliste <\/b>und Bewerber<\/b>. Beide liefern Ihnen die angeforderten Daten. Womit der Test der Anmeldung Stromberg <\/b>ebenfalls erfolgreich abgeschlossen wäre.<\/p>\n Bild 15: Start-Formular für Stromberg<\/span><\/b><\/p>\n 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 <\/b>arbeiten. Für diese Mitarbeiter müssten Sie die entsprechenden Anmeldungen im SQL Server anlegen – oder Sie verwenden stattdessen Windows-Gruppen.<\/p>\n 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. <\/p>\n 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.<\/p>\n Ä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.<\/p>\n Öffnen Sie die Computerverwaltung aufs Neue. Dieses Mal markieren Sie im Ordner Lokale Benutzer und Gruppen <\/b>den Eintrag Gruppen <\/b>und wählen aus dessen Kontextmenü Neue Gruppe<\/b>. Nennen Sie die Gruppe Vertrieb <\/b>und klicken Sie auf Hinzufügen<\/b>. In dem Auswahldialog geben Sie Bienlein <\/b>ein und beenden die Auswahl mit OK<\/b>. Zurück im Dialog Neue Gruppe <\/b>sehen Sie nun das Windows-Benutzerkonto Bienlein <\/b>als Mitglied der Gruppe Vertrieb <\/b>(siehe Bild 16). Bestätigen Sie die neue Gruppe mit Erstellen <\/b>und wiederholen Sie den Vorgang für eine weitere Gruppe mit der Bezeichnung Personal<\/b>. Dieser ordnen Sie das Windows-Benutzerkonto Stromberg <\/b>zu. Nach einem weiteren Klick auf Erstellen <\/b>schließen Sie den Dialog mit der Schaltfläche OK<\/b>.<\/p>\n Bild 16: Windows-Gruppe Vertrieb<\/span><\/b><\/p>\n 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 <\/b>und wählen im Kontextmenü des Unterordners Anmeldungen <\/b>den Eintrag Neue Anmeldung<\/b>. Im Dialog öffnen Sie über Suchen <\/b>die Auswahl Benutzer oder Gruppe auswählen <\/b>und geben die Windows-Gruppe Personal <\/b>ein. Ein Klick auf Namen überprüfen <\/b>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 <\/b>und aktivieren in dem folgenden Dialog die Option Gruppen <\/b>(siehe Bild 17).<\/p>\n Bild 17: Die fehlende Grundeinstellung<\/span><\/b><\/p>\n 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 <\/b>dann auch gefunden. Die Auswahl übernehmen Sie mit einem Klick auf OK<\/b>. Zurück im Dialog Anmeldung – Neu <\/b>wählen Sie noch als Standarddatenbank WaWi_SQL <\/b>aus, bevor Sie zur Seite Benutzerzuordnung <\/b>wechseln.<\/p>\n Die Anmeldung zur Windows-Gruppe Personal <\/b>soll die gleichen Rechte wie die Anmeldung Stromberg <\/b>erhalten. Dazu aktivieren Sie im oberen Teil des Dialogs die Datenbank WaWi_SQL <\/b>und im unteren Bereich die Datenbankrollen db_datareader<\/b>, db_datawriter <\/b>und edb_execute<\/b>. Soweit so gut, nur klicken Sie jetzt bitte nicht auf OK<\/b>. Vielmehr verwenden Sie an dieser Stelle wieder die Schaltfläche Skript<\/b>, wodurch Sie die entsprechenden T-SQL-Befehle zur Rechtevergabe in einer neuen Registerkarte erhalten. Den Dialog schließen Sie mit Abbrechen<\/b>.<\/p>\n 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 <\/b>speichern (siehe Bild 18).<\/p>\n Bild 18: Rechtevergabe für die Anmeldung Personal<\/span><\/b><\/p>\n Ein Klick auf Ausführen <\/b>legt dann die neue Anmeldung mitsamt dem zugehörigen Benutzer in der Datenbank WaWi_SQL <\/b>und dessen Zugriffsrechten an. Dass es sich bei der neuen Anmeldung um eine Windows-Gruppe handelt, sehen Sie an dem Symbol der Anmeldung. Während bei der Anmeldung Stromberg <\/b>nur ein Kopf abgebildet ist, zeigt das Icon zur Anmeldung Personal <\/b>zwei Köpfe (siehe Bild 19).<\/p>\n Bild 19: Symbole der Windows-Authentifizierung<\/span><\/b><\/p>\n Die Anmeldung zur Windows-Gruppe Vertrieb <\/b>erstellen Sie direkt per T-SQL-Skript. Dazu kopieren Sie das eben erstelle Skript Rechtevergabe Personal <\/b>und speichern es unter der Bezeichnung Rechtevergabe Vertrieb<\/b>. Das neue Skript öffnen Sie im SQL Server Management Studio über Datei|Öffnen|Datei <\/b>und ersetzen dort den Begriff Personal <\/b>mit Vertrieb<\/b>. Beide Anmeldungen haben in der Datenbank WaWi_SQL <\/b>erst einmal die gleichen Rechte. Nur wird dem Vertrieb der Zugriff auf die Objekte der Personalabteilung verweigert. Diese erweiterte Rechtevergabe haben Sie bereits für die Anmeldung Bienlein <\/b>definiert und in einem eigenen Skript gespeichert. Öffnen Sie dieses Skript und übernehmen Sie die DENY<\/b>-Anweisungen in ihr neues Skript. In den so übernommenen Zeilen tauschen Sie den Namen Bienlein <\/b>mit Vertrieb <\/b>aus. Heraus kommt ein Skript wie in Bild 20, das Sie nun über die Taste F5 <\/b>ausführen und dann in Ihrer Dokumentation speichern. Das Skript zur Rechtevergabe der Anmeldung Bienlein <\/b>können Sie löschen. Ihre Dokumentation umfasst nun zwei T-SQL-Skripte, eines mit den Rechten zur Anmeldung Vertrieb <\/b>und eines zur Anmeldung Personal<\/b>.<\/p>\n Bild 20: Rechtevergabe für die Anmeldung Vertrieb <\/span><\/b><\/p>\n Durch die beiden neuen Anmeldungen Vertrieb <\/b>und Personal <\/b>sind die Anmeldungen Stromberg <\/b>und Bienlein <\/b>nicht mehr erforderlich und können entfernt werden. Am besten beginnen Sie mit der Anmeldung Stromberg<\/b>, besitzt diese doch volle Lese- und Schreibrechte. Dazu wählen Sie aus dem Kontextmenü der Anmeldung den Eintrag Löschen<\/b>. Zur Sicherheit erhalten Sie einen etwas überdimensionierten Dialog, der Sie darüber informiert, was genau Sie gleich auslösen werden. Weitaus wichtiger ist jedoch der Hinweis, den Sie nach einem Klick auf OK <\/b>erhalten (siehe Bild 21). Dieser rät Ihnen zunächst die zugehörigen Benutzer in den Datenbanken zu entfernen. Das ist ein wichtiger Punkt beim Löschen bestehender Anmeldungen. Ohne vorherige Prüfung der Benutzer entfernen Sie womöglich eine Anmeldung, die für den Zugriff auf eine oder mehrere Datenbanken noch benötigt wird. <\/p>\n Bild 21: Hinweis beim Löschen einer Anmeldung<\/span><\/b><\/p>\n Hinzu kommt, dass Sie die Anmeldung zwar ohne weiteres löschen können, die Benutzer in den Datenbanken mitsamt den Zugriffsrechten jedoch bestehen bleiben. Solche verwaisten Benutzer stellen wegen den immer noch existierenden Zugriffsrechten eine Sicherheitslücke dar. Angenommen, der Kollege Stromberg wechselt in die Abteilung Controlling<\/b>. Als Folge entfernen Sie sein Windows-Benutzerkonto aus der Windows-Gruppe Personal<\/b>. Wodurch ihm der Zugang zum SQL Server und somit zur Datenbank WaWi_SQL <\/b>nicht mehr zur Verfügung steht. Als Controller benötigt Herr Stromberg einen Zugriff auf die Datenbank Auswertungen<\/b>. Hierzu legen Sie im SQL Server eine Anmeldung für das Windows-Benutzerkonto Stromberg <\/b>an und ordnen dieses der Datenbank zu. Mit dieser Anmeldung hat der Kollege Stromberg jetzt nicht nur Zugriff auf die Datenbank Auswertungen<\/b>, sondern auch wieder auf die Datenbank WaWi_SQL<\/b>. Dort existiert immer noch ein Benutzer mit einem Verweis zur Anmeldung Stromberg <\/b>und dieser Verweis ist durch die neu erstellte Anmeldung wieder vollständig. Somit besitzt Herr Stromberg unerlaubterweise den vollen Zugriff auf die Daten der Datenbank WaWi_SQL<\/b>. <\/p>\n Wenn das keine guten Gründe sind, den Löschvorgang erst einmal abzubrechen und sich vorher die Benutzerzuordnungen anzuschauen. Schließen Sie den Sicherheitshinweis mit Cancel <\/b>und einem weiteren Klick auf Abbrechen<\/b>. Danach öffnen Sie den Dialog zur Anmeldung mit einem Doppelklick auf den Eintrag Stromberg<\/b>. In der Seite Benutzerzuordnung <\/b>prüfen Sie die einzelnen Zuordnungen der Anmeldung zu den Datenbanken. Sollte auch nur eine der Zuordnungen noch benötigt werden, dürfen Sie die Anmeldung nicht löschen. In der Beispielumgebung ist dies recht einfach. Die Anmeldung ist lediglich der Datenbank WaWi_SQL <\/b>zugeordnet. Deaktivieren Sie die Zuordnung und klicken Sie auf OK<\/b>. Hiermit wird der Benutzer in der Datenbank gelöscht und der Dialog geschlossen. Erst jetzt können Sie die Anmeldung Stromberg <\/b>bedenkenlos entfernen. Anschließend wiederholen Sie den Vorgang mit der Anmeldung Bienlein. <\/p>\n Bleiben noch die Anmeldungen WaWiMa <\/b>und WaWiPersonal<\/b>. Beide sind aktiv und somit ebenfalls eine Sicherheitslücke. Jede Person mit Kenntnis dieser Anmeldungen und der jeweiligen Kennwörter besitzt die entsprechenden Rechte für den Datenzugriff. So ist Frau Bienlein mit der Anmeldung WaWiPersonal <\/b>weiterhin in der Lage auf die Daten der Personalabteilung zuzugreifen. Aus diesem Grund sollten Sie Anmeldungen mit SQL Server-Authentifizierungen umgehend löschen, wenn Sie diese nicht mehr benötigen. Dabei gehen Sie genauso vor wie eben bei den Anmeldungen Stromberg <\/b>und Bienlein<\/b>. Zunächst entfernen Sie zu den Anmeldungen die Benutzer in den Datenbanken und anschließend die Anmeldungen selbst. <\/p>\n Im SQL Server existiert für Frau Bienlein nun weder die Anmeldung WaWiMa <\/b>noch eine Anmeldung zu ihrem Windows-Benutzerkonto. Die Authentifizierung am SQL Server und der Datenzugriff in der Datenbank erfolgt ausschließlich durch die Gruppenzugehörigkeit des Windows-Benutzerkontos Bienlein <\/b>zur Windows-Gruppe Vertrieb<\/b>. <\/p>\n Um dies zu testen, wechseln Sie erneut die Identität und öffnen die Beispielapplikation WaWi v2 <\/b>mit dem Benutzerkonto Bienlein<\/b>. Als Ergebnis zeigt das Start-Formular die aktiven Schaltflächen des Vertriebs. Jede der Schaltflächen liefert Ihnen die gewünschten Daten und ein Doppelklick auf die Pass Through-Abfrage ptSelectGeburtstagsliste <\/b>zudem die erwartete Fehlermeldung. Sie sehen, die Rechtevergabe für Frau Bienlein funktioniert, obwohl im SQL Server für das Windows-Benutzerkonto Bienlein <\/b>keine eigene Anmeldung existiert.<\/p>\n Mit dem Windows-Benutzerkonto Stromberg <\/b>verhält es sich ähnlich. Starten Sie die Beispielapplikation als Anwender Stromberg<\/b>, können Sie im Navigationsbereich jede Tabelle und Pass Through-Abfrage öffnen. Auch das entspricht der aktuellen Rechtevergabe. Das Windows-Benutzerkonto Stromberg <\/b>gehört zur Windows-Gruppe Personal <\/b>und für diese Gruppe gibt es im SQL Server eine Anmeldung mit umfassenden Rechten in der Datenbank WaWi_SQL<\/b>.<\/p>\n Ein großer Vorteil der Zugriffssteuerung über Windows-Gruppen liegt in der Einfachheit der Rechtevergabe. Insbesondere wenn Sie einem neuen Anwender Rechte zuweisen müssen. Öffnen Sie die Computerverwaltung und erweitern Sie den Ordner Lokale Benutzer und Gruppen<\/b>. Nach einem Rechtsklick auf den Ordner Benutzer <\/b>und der Auswahl von Neuer Benutzer <\/b>erfassen Sie ein Benutzerkonto für die Kollegin Beimer (siehe Bild 22).<\/p>\n Bild 22: Windows-Benutzer Beimer<\/span><\/b><\/p>\n Anschließend speichern Sie die Eingabe mit der Schaltfläche Erstellen <\/b>und beenden Sie den Dialog. Danach öffnen Sie das neue Benutzerkonto per Doppelklick und wechseln zur Registerkarte Mitglied von<\/b>. Hier legen Sie Gruppenzugehörigkeit über die Schaltfläche Hinzufügen <\/b>fest. Geben Sie in dem folgenden Dialog die Windows-Gruppe Vertrieb <\/b>ein und bestätigen Sie dies mit OK<\/b>. Mit einem weiteren Klick auf OK <\/b>beenden Sie die Gruppenzuordnung. Das war es schon. Mehr ist nicht erforderlich. Durch die Gruppenzuordnung besitzt Frau Beimer bereits alle notwendigen Rechte für den Datenzugriff. An der Rechtevergabe im SQL Server ändert sich nichts.<\/p>\n Testen Sie es mal. Öffnen Sie die Beispielapplikation mit dem Windows-Benutzerkonto Beimer<\/b>. Nach Bestätigen der Lizenzvereinbarung und der Datenschutzeinstellungen sowie der Freigabe der aktiven Inhalte sehen Sie wie bei Frau Bienlein das Start-Formular mit den aktiven Schaltflächen für den Vertrieb. Ein kurzer Test bestätigt Ihnen die Rechtevergabe. So zeigt ein Klick auf die Schaltfläche Artikel <\/b>die aktuelle Artikelliste, während ein Doppelklick auf die Pass Through-Abfrage ptSelectGeburtstagsliste <\/b>die bekannte Fehlermeldung liefert.<\/p>\n Wenn das keine einfache Rechtevergabe für einen neuen Anwender ist. Im Grunde genommen haben Sie als Datenbankadministrator gar nichts damit zu tun. Das Erstellen neuer Windows-Benutzerkonten ist Aufgabe der IT-Systemadministration. Hier werden die Anwender in Windows-Gruppen zusammengefasst und deren Zugriffsrechte für das Dateisystem und weiterer Applikationen verwaltet. Diese unternehmensweit gültige Gruppenbildung übernehmen Sie einfach in Ihren SQL Server. <\/p>\n Ebenso gehört das Verwalten von Windows-Benutzerkonten zu den Aufgaben des IT-Systemadministrators. Angenommen, der Kollege Stromberg soll für 14 Tage im Vertrieb aushelfen. Für diesen Zeitraum ordnet der IT-Systemadministrator das Windows-Benutzerkonto Stromberg <\/b>der Windows-Gruppe Vertrieb <\/b>zu und entfernt die Zugehörigkeit zur Gruppe Personal<\/b>. Stellen Sie das Szenario doch einmal in Ihrer Computerverwaltung nach. Öffnen Sie das Windows-Benutzerkonto Stromberg <\/b>und wechseln Sie zur Seite Mitglied <\/b>von. Dort markieren Sie die Gruppe Personal <\/b>und klicken auf Entfernen<\/b>. Danach nehmen Sie das Windows-Benutzerkonto über die Schaltfläche Hinzufügen <\/b>in die Windows-Gruppe Vertrieb <\/b>auf. Jetzt öffnen Sie die Beispielapplikation mit dem Benutzerkonto Stromberg <\/b>und Sie sehen das Start-Formular mit den Funktionen des Vertriebs. <\/p>\n Möglich macht dies die neue Formularsteuerung. Sie finden diese in der Funktion fBerechtigungen <\/b>im VBA-Code des Start-Formulars. In der alten Version wurde zunächst der Name des Windows-Benutzerkontos vom aktuell angemeldeten Anwender ermittelt. Abhängig vom Namen folgten dann das Aktivieren und Deaktivieren der Schaltflächen sowie die Ausgabe des Namens im Kopf des Formulars und der Applikation. Der VBA-Code aus Bild 23 zeigt einen Teil dieser simplen Funktionalität.<\/p>\n Bild 23: Formularsteuerung für Bienlein<\/span><\/b><\/p>\n Bisher war das absolut ausreichend. Mit der Umstellung auf Windows-Gruppen hat die alte Variante jedoch einen gravierenden Nachteil. Bei einem Wechsel eines Windows-Benutzerkontos in eine andere Windows-Gruppe hat sie keine Auswirkung. Schließlich bezieht sie sich auf den Namen des Windows-Benutzerkontos und nicht auf den der Windows-Gruppe. Herr Stromberg würde also weiterhin die Schaltflächen der Personal-Abteilung sehen.<\/p>\n Aus diesem Grund ist in der neuen Version nicht mehr das Windows-Benutzerkonto des angemeldeten Anwenders ausschlaggebend, sondern dessen aktuelle Authentifizierung am SQL Server. Im Fall Stromberg ist dies die Anmeldung Vertrieb <\/b>mit dem Verweis auf die gleichnamige Windows-Gruppe. Die Daten zur Authentifizierung ermittelt eine Pass Through-Abfrage, die wiederum die gespeicherte Prozedur pSelectAnmeldung <\/b>ausführt. Inhalt dieser gespeicherten Prozedur ist die folgende Anweisung.<\/p>\n Die SELECT<\/b>-Anweisung basiert auf der Systemsicht sys.user_token<\/b>, die Informationen zur Rechtevergabe des aktuellen Datenbankzugriffs bereitstellt. Dazu gehören unter anderem die Mitgliedschaft zu den Datenbankrollen und die zur Authentifizierung verwendete Anmeldung. Da an dieser Stelle nur die Anmeldung interessiert, wird die Datenausgabe per WHERE<\/b>-Bedingung auf die Typen Windows Login <\/b>und Windows Group <\/b>begrenzt.<\/p>\n Als Ergebnis sehen Sie in der Spalte VerwendeteAnmeldung <\/b>die zur Authentifizierung genutzte Anmeldung, in diesem Fall die der Windows-Gruppe Vertrieb <\/b>(siehe Bild 24).<\/p>\n Bild 24: Systemsicht sys.user_token<\/span><\/b><\/p>\n Die Information zum Windows-Benutzerkonto des tatsächlich angemeldeten Anwenders fehlt jedoch in der Ausgabe der Systemsicht. Hierzu bietet SQL Server die Systemfunktion SUSER_SNAME()<\/b>. Als zusätzliche Ausgabespalte in der SELECT<\/b>-Anweisung liefert sie den Wert Stromberg<\/b>. Anhand dieser Informationen findet in dem folgenden IF<\/b>-Block die Formularsteuerung statt. Diese gilt für alle Mitglieder der Windows-Gruppe Vertrieb<\/b>, also für die Anwender Bienlein<\/b>, Beimer <\/b>und aktuell auch Stromberg<\/b>.<\/p>\n Soweit zur optischen Darstellung der Benutzerrechte, doch wie sieht es eigentlich mit den tatsächlichen Zugriffsrechten aus Das soll ein einfacher Test zeigen. Dazu bietet sich wieder mal die Pass Through-Abfrage ptSelectGeburtstagsliste <\/b>an. Wechseln Sie zum Navigationsbereich und öffnen Sie die Pass Through-Abfrage. Als Ergebnis erhalten Sie die Ihnen bereits gut bekannte Fehlermeldung. Der Test ist erfolgreich. Das Ausführen der gespeicherten Prozedur pSelectGeburststagsliste <\/b>wird dem Windows-Benutzerkonto Stromberg <\/b>verweigert, gehört es doch inzwischen zur Windows-Gruppe Vertrieb<\/b>. Obwohl es mit der neuen Gruppenzugehörigkeit eine entscheidende Änderung der Zugriffsrechte für das Windows-Benutzerkonto gab, hatten Sie als Datenbankadministrator erneut nichts damit zu tun. Die Rechtevergabe liegt alleine bei der IT-Systemadministration. <\/p>\n Ein guter Grund, Windows-Gruppen als Anmeldungen zu verwenden. Mit einer Ausnahme: Die Windows-Benutzerkonten der Datenbankadministratoren. Als Datenbankadministrator sind Sie verantwortlich für den SQL Server und die dort verwalteten Datenbanken und Daten. Insofern sollten Sie wissen, welcher Ihrer Kollegen mit administrativen Rechten im SQL Server arbeitet. Genau dies sehen Sie bei einer Windows-Gruppe aber nicht. Möglicherweise sind Ihnen die Mitglieder dieser Windows-Gruppe nicht einmal bekannt, obliegt die Verwaltung der Gruppenzugehörigkeit doch dem IT-Systemadministrator. Wie wollen Sie Verantwortung für die Daten übernehmen, wenn Sie nicht einmal wissen, welche Personen administrative Rechte im SQL Server besitzen Deshalb sollten Sie für die Anmeldungen der Datenbankadministratoren ausschließlich deren persönliche Windows-Benutzerkonten verwenden. Nur so erkennen Sie die Anwender mit administrativen Rechten im SQL Server. <\/p>\n Nebenbei schützt Sie diese Vorgehensweise noch vor einer kleinen Falle. Meldet sich ein Datenbankadministrator über eine Windows-Gruppe am SQL Server an, kann er die Anmeldung zu dieser Windows-Gruppe löschen und sich somit selbst den Zugang zum SQL Server entziehen. So etwas ist bei einer Anmeldung mit seinem persönlichen Windows-Benutzerkonto nicht möglich. <\/p>\n Mit der Windows-Authentifizierung profitieren Sie nicht nur von einer einfachen Verwaltung der Zugriffsrechte, Sie erhalten zudem eine weitaus höhere Sicherheit. Im Gegensatz zur SQL Server-Authentifizierung erfolgt der Zugang zum SQL Server nicht per Eingabe von Anmeldename und Kennwort, sondern mit der aktuellen Windows-Anmeldung des Anwenders. Ein Angreifer benötigt für einen unerlaubten Datenzugriff also ein gültiges Windows-Benutzerkonto mitsamt Kennwort. Das sollte ihm den Zugang um einiges erschweren. Ihre Anwender sind bestimmt soweit sensibilisiert, dass sie ihre Kennwörter auf keinen Fall preisgeben.<\/p>\n Frau Bienlein ist sauer. Sie hätte gerne einen neuen Bürostuhl. Mühsam hat sie in den letzten Stunden im Internet den passenden Stuhl gesucht und letztendlich auch gefunden. Doch ihr Abteilungsleiter war davon gar nicht begeistert. Er redete was von vertaner Arbeitszeit und Budgetgrenze. Der Bürostuhl sei außerdem viel zu teuer. Als Abteilungsleiter darf er Einkäufe bis maximal 50 Euro selbst bestimmen. Alles andere geht den Weg über die Personalabteilung.<\/p>\n Das findet Frau Bienlein nicht fair. Zur Genugtuung möchte sie sich mit einer kleinen Gehaltserhöhung trösten. Sie startet die Access-Applikation WaWi v2 <\/b>mit gedrückter Umschalt-Taste und erweitert den Navigationsbereich. Jetzt noch schnell mit der Access-Abfrage Anmeldedaten <\/b>die Anmeldung WaWiPersonal <\/b>zuordnen und schon kann sie nach einem Neustart der Access-Applikation ungestört auf die Tabelle Mitarbeiter <\/b>zugreifen. Doch wo ist die Abfrage Im Navigationsbereich gibt es nur noch eine Access-Abfrage namens Wareneingang<\/b>. Neugierig startet Frau Bienlein die Abfrage. Als Ergebnis sieht sie eine Liste mit Firmennamen und Bestelldaten, ergänzt mit Kennzeichen zum Wareneingang und Rechnungsnummern (siehe Bild 25). Frau Bienleins Interesse ist geweckt. <\/p>\n Bild 25: Access-Abfrage Wareneingang<\/span><\/b><\/p>\n Sie wechselt in den Entwurfsmodus der Abfrage und sieht die Tabellen Bestellungen<\/b>, Bestelldetails <\/b>und Lieferanten<\/b>. Nach und nach öffnet sie die Tabellen und schaut sich die Daten an. Schnell erkennt sie den Zusammenhang. Die Daten bilden die Bestellvorgänge des Wareneingangs ab. Nebenbei bemerkt sie in der Tabelle Lieferanten <\/b>den Eintrag Schreibwaren Stiftler<\/b>. Super, denkt Frau Bienlein, da hätte ich mir meinen Stuhl ja direkt bestellen können. <\/p>\n Das bringt sie auf eine Idee. Rein theoretisch geben die drei Tabellen alles her, um den Stuhl zu bestellen. Sie muss lediglich in der Tabelle Bestellungen <\/b>und Bestelldetails <\/b>die entsprechenden Einträge vornehmen. Das wäre dann aber doch zu auffällig. Wie sollte sie die Lieferung des Stuhls erklären Frau Bienlein schaut sich die Daten der Tabellen genauer an und entdeckt die Bankverbindung der Lieferanten. Sie denkt kurz an die Budgetgrenze und kommt auf eine viel bessere Idee. Doch für heute lässt sie es gut sein und geht in den Feierabend.<\/p>\n Zuhause sucht Frau Bienlein im Internet einen Lieferanten für Büromaterialien. Nachdem sie sich für einen adäquaten Kandidaten entschieden hat, bestellt sie eine Kleinigkeit per Vorauskasse. Kurz darauf erhält sie eine E-Mail mit der Bankverbindung des Lieferanten. Das war alles, was sie wissen wollte. Sie storniert ihre Bestellung. Anschließend geht sie zur Website der angegebenen Bank und eröffnet dort ein Girokonto. <\/p>\n Am nächsten Tag startet sie die Applikation WaWi v2 <\/b>erneut mit gedrückter Umschalt-Taste und öffnet die Tabelle Lieferanten<\/b>. Sie gibt einen neuen Datensatz ein. Dabei verwendet sie die Firmenbezeichnung und Adresse des Unternehmens, für das sie sich gestern Abend entschieden hat. Als Bankverbindung hinterlegt sie die Daten ihres neuen Girokontos. Anschließend öffnet sie die Tabelle Bestellungen<\/b>. Hier erfasst Sie für ihren Lieferanten eine Bestellung mit dem heutigen Datum. Für die erforderliche Mitarbeiter-ID schaut sie in die Bestellungen an den Lieferanten Schreibwaren Stiftler <\/b>und übernimmt eine der dort angegebenen IDs. Sie speichert den Datensatz und notiert sich die neu vergebene ID zu ihrer Bestellung. Nun geht es an die Positionen der Bestellung. Dabei orientiert sie sich weiterhin am Lieferanten Schreibwaren Stiftler<\/b>. Sie filtert die Ansicht nach der ID des Lieferanten und schreibt sich einige der Bestell-IDs auf einen Zettel. Jetzt öffnet sie die Tabelle Bestelldetails<\/b>. Hier sucht sie anhand der notierten IDs nach Produkten mit einem geringen Bestellwert. Nach einigen Vergleichen entscheidet sie sich für das Produkt mit der ID 19<\/b>. In der letzten Zeile der Datenblattansicht trägt sie die ID ihrer Bestellung ein, dann die Produkt-ID 19 <\/b>und ergänzt die Eingabe mit der Position 1<\/b>, dem Einzelpreis 1,50 <\/b>und der Menge 10<\/b>. Fertig ist die Bestellung mit einer Gesamtsumme von 15 Euro netto. Soweit so gut. Zufrieden beendet Frau Bienlein ihre kleine Aktion und widmet sich anderen Aufgaben.<\/p>\n Kurz vor Monatsende startet sie die Applikation WaWi v2 <\/b>mit gedrückter Umschalt-Taste. Sie öffnet die Tabelle Bestellungen <\/b>und geht direkt zu ihrer Bestellung. Dort ändert sie den Eintrag der Spalte WareneingangKomplett <\/b>in -1 <\/b>und gibt eine willkürliche Rechnungsnummer ein. Fertig. Der Rest ist Warten. Warten, bis der monatliche Zahlungslauf der Buchhaltung erledigt ist. <\/p>\n [50223]<\/p>\n Am zweiten Tag des neuen Monats schaut Frau Bienlein abends per Online-Banking in ihr Bankkonto. Nervös öffnet sie die Umsatzanzeige – und freut sich über 17,85 Euro. Tags darauf verwischt sie ihre Spuren. Dazu entfernt sie zunächst die Datensätze zu ihrer Bestellung und dann noch den Datensatz ihres fiktiven Lieferanten. Frau Bienlein freut sich schon auf das Monatsende, denn dann wird sie sich wieder eine Kleinigkeit bestellen. <\/p>\n [50597]<\/p>\n [51032]<\/p>\n Kurz gesagt, bietet Ihnen die Windows-Authentifizierung mehr Sicherheit bei weniger Aufwand. Im Gegensatz zur SQL Server-Authentifizierung müssen Sie sich keinen Anmeldenamen ausdenken oder gar ein kompliziertes Kennwort vergeben. Sie verweisen lediglich auf das Windows- oder Active Directory-Benutzerkonto des Anwenders. Anschließend ordnen Sie die Anmeldung wie gewohnt einer oder mehreren Datenbanken zu, wobei dort ein Benutzer erstellt wird, dem Sie dann die entsprechenden Rechte zuweisen. Noch komfortabler ist die Verwendung von Gruppen. Eine Anmeldung basierend auf einer Windows- oder Active Directory-Gruppe erlaubt allen Mitgliedern der Gruppe die Authentifizierung am SQL Server und über den zugehörigen Benutzer in den Datenbanken den entsprechenden Datenzugriff.<\/p>\n [51052]<\/p>\n Fast nebenbei erhalten Sie mit der Windows-Authentifizierung einen weitaus besseren Zugriffsschutz. Schließlich ist weder die Ein- noch Übergabe von Anmeldename und Kennwort erforderlich. Besser noch, Sie müssen die Anmeldedaten nicht mehr mühsam in Ihrer Access-Applikation verstecken und schützen. Die größte Schwachstelle im bisherigen Sicherheitskonzept ist somit geschlossen.<\/p>\n [51831]<\/p>\n Wodurch Frau Bienlein der Zugriff auf die Tabelle Mitarbeiter <\/b>nicht mehr möglich ist. Bisher konnte sie die Daten dieser Tabelle über die SQL Server-Anmeldung WaWiPersonal <\/b>ändern. Dazu hatte sie entweder die Anmeldedaten innerhalb der Access-Applikation manipuliert oder sich das zugehörige Kennwort verschafft. Beides war letztendlich möglich, da der Anmeldevorgang automatisch durch die Applikation erfolgte. Der eigentliche Anwender spielte bei der Authentifizierung am SQL Server gar keine Rolle. Das hat sich mit der Windows-Authentifizierung maßgeblich geändert. Frau Bienlein greift nun mit ihrem Windows-Benutzerkonto auf die SQL Server-Datenbank zu und diesem wird der Zugriff auf die Tabelle Mitarbeiter <\/b>explizit verweigert. Ihre unregelmäßigen Gehaltserhöhungen sind Geschichte.<\/p>\n [52212]<\/p>\n Frau Bienlein wäre nicht Frau Bienlein, hätte sie nicht einen neuen Weg für eine Gehaltsaufbesserung gefunden. Anstelle von Gehaltserhöhungen erfasst sie nun Bestellungen inklusive Wareneingänge für einen nicht existierenden Lieferanten. Die Zahlung dieser fiktiven Rechnungen übernimmt der monatliche Zahlungslauf der Buchhaltung. Dabei wird die beim Lieferanten hinterlegte Bankverbindung verwendet, in diesem Fall eine Bankverbindung von Frau Bienlein. <\/p>\n [53002]<\/p>\n Die Bezahlung der nicht realen Eingangsrechnungen funktioniert zum einen durch die Freigabe von Bestellungen bis zu einer definierten Budgetgrenze und zum anderen durch die getrennte Datenverarbeitung der Bestellungen und dem Zahlungsvorgang. Diese Trennung erlaubt Frau Bienlein das problemlose Beseitigen ihrer Spuren. Da es keine direkte Verbindung der Datenbank WaWi_SQL <\/b>zu den Daten der Buchhaltung gibt, kann sie die Bestellung inklusive Lieferanten ohne weiteres löschen. <\/p>\n [53459]<\/p>\n Dieses Szenario stammt nicht aus einem schlechten Roman. Es ist Realität. Das Zahlen von Rechnungen unterhalb definierter Budgetgrenzen an fiktive Lieferanten gehört zu den gängigen Betrugsfällen. Wobei der Aufwand der Datenmanipulation in Wahrheit hoffentlich aufwendiger ist. Möglich wird dieses Szenario durch das immer noch nicht ausreichende Berechtigungskonzept. Im Bereich der Authentifizierung mag inzwischen eine sehr hohe Ebene erreicht sein, beim letztendlichen Datenzugriff ist aber noch einiges offen. Die Zugriffsrechte innerhalb der Datenbank sind weiterhin zu pauschal. SQL Server bietet Ihnen für eine detailliertere Rechtevergabe mehrere Möglichkeiten. Mit den Datenbankrollen nutzen Sie bereits eine davon. Wie Sie diese für ein wirksameres Berechtigungskonzept einsetzen, erfahren Sie im nächsten Beitrag.<\/p>\n [53939]<\/p>\n [54765]<\/p>\n [54809]<\/p>\n [54854]<\/p>\n [54900]<\/p>\n [54948]<\/p>\n [55029]<\/p>\n [55117]<\/ul>\n Sollte diese Option bereits aktiviert sein, können Sie die Änderung hier abbrechen. Die folgenden Schritte müssen Sie dann nicht ausführen.<\/p>\n [55186]<\/p>\n [55326]<\/p>\n [55361]<\/p>\n [55442]<\/ul>\n Installation der Beispieldatenbank WaWi_SQL<\/p>\n [55521]<\/p>\n [55565]<\/p>\n [55611]<\/p>\n [55671]<\/p>\n [55735]<\/ul>\n [55835]<\/p>\n [55860]<\/ul>\n Sie finden den Treiber im Microsoft Downloadbereich unter dem Suchbegriff ODBC Driver 17 for SQL Server<\/b>.<\/p>\n [55948]<\/p>\n [56053]<\/ul>\n Sie finden den Treiber im Microsoft Downloadbereich unter dem Suchbegriff MSOLEDBSQL<\/b>.<\/p>\n [56143]<\/p>\n [56229]<\/p>\n [56257]<\/p>\n [56309]<\/p>\n [56380]<\/p>\n [56490]<\/p>\n [56526]<\/p>\n [56570]<\/ul>\n Den Namen Ihres SQL Servers sehen Sie als ersten Eintrag im Objekt-Explorer im SQL Server Management Studio. Alternativ öffnen Sie im SQL Server Management Studio mit einem Klick auf die Schaltfläche Neue Abfrage <\/b>eine neue Registerkarte und geben dort den Befehl SELECT @@Servername <\/b>ein. Nach einem Klick auf Ausführen <\/b>sehen Sie als Ergebnis den Namen Ihres SQL Servers.<\/p>\n [56636]<\/p>\n<\/p>\n
Die Anmeldung Bienlein <\/h2>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
DENY UPDATE ON [dbo].[Bewerber] TO [Ihr Rechnername\\Bienlein]<\/pre>\n
DENY SELECT, INSERT, UPDATE, DELETE ON [dbo].[Bewerber] TO [Ihr Rechnername\\Bienlein]<\/pre>\n
DENY SELECT, INSERT, UPDATE, DELETE ON [dbo].[Mitarbeiter] TO [Ihr Rechnername \\Bienlein]\r\nDENY SELECT, INSERT, UPDATE, DELETE ON [dbo].[Stellen] TO [Ihr Rechnername \\Bienlein]<\/pre>\n
<\/p>\n
<\/p>\n
Access und die Windows-Authentifizierung<\/h2>\n
Set<\/span> rsVerbindung = CurrentDb.OpenRecordset(\"Datenquellen\", dbOpenSnapshot)<\/pre>\nIf <\/span>IsNull(rsVerbindung(\"Benutzer\")) Then<\/span> boKomplett = False<\/span>\r\nIf <\/span>IsNull(rsVerbindung(\"Kennwort\")) Then<\/span> boKomplett = False<\/span><\/pre>\n\";UID=\" & rsVerbindung(\"Benutzer\") & _\r\n\";PWD=\" & fKennwortLesen(rsVerbindung(\"Kennwort\"))<\/pre>\n
''Datenquelle ermitteln\r\nSet<\/span> rsVerbindung = CurrentDb.OpenRecordset( \"Datenquellen\", dbOpenSnapshot)\r\nIf <\/span>Not<\/span> rsVerbindung.EOF Then<\/span>\r\n ''Inhalte prüfen\r\n If <\/span>IsNull(rsVerbindung(\"Server\")) Then<\/span> boKomplett = False<\/span>\r\n If <\/span>IsNull(rsVerbindung(\"Datenbank\")) Then<\/span> boKomplett = False<\/span>\r\n ''Anmeldedaten vollständig\r\n If <\/span>boKomplett = True<\/span> Then<\/span>\r\n ''Connection definieren\r\n fOdbcPerTabelle = _\r\n \"ODBC;DRIVER=ODBC Driver 17 for SQL Server\" _\r\n & \";Trusted_Connection=Yes\" & _\r\n \";Server=\" & rsVerbindung(\"Server\") & _\r\n \";Database=\" & rsVerbindung(\"Datenbank\")\r\n End If \r\nElse<\/span>\r\n ''Keine Anmeldedaten gefunden\r\n boKomplett = False<\/span>\r\nEnd If <\/pre>\n''Verbindungsdaten unvollständig\r\nIf <\/span>boKomplett = False<\/span> Then<\/span>\r\n MsgBox<\/span> \"Die Verbindungsdaten sind nicht vollständig erfasst.\" & vbCrLf<\/span> & \"Bitte ergänzen Sie die fehlenden Informationen.\", vbCr<\/span>itical, CurrentDb.Properties!AppTitle\r\nEnd If<\/span><\/pre>\nSet<\/span> rsVerbindung = CurrentDb.OpenRecordset( \"Datenquellen\", dbOpenSnapshot)<\/pre>\n\";User ID=\" & rsVerbindung(\"Benutzer\") & _\r\n\";Password=\" & fKennwortLesen(rsVerbindung(\"Kennwort\"))<\/pre>\n
fAdoPerTabelle = \"Provider=MSOLEDBSQL;Integrated Security=SSPI;Server=\" & rsVerbindung(\"Server\") & \";Database=\" & rsVerbindung(\"Datenbank\")<\/pre>\n
fTabelleAlsSystemObjekt \"Datenquellen\", False<\/span><\/pre>\n<\/p>\n
<\/p>\n
<\/p>\n
Die Anmeldung Stromberg<\/h2>\n
<\/p>\n
<\/p>\n
Eine Anmeldung für eine Windows-Gruppe<\/h2>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Löschen einer Anmeldung<\/h2>\n
<\/p>\n
Vorteile von Windows-Gruppen<\/h2>\n
<\/p>\n
<\/p>\n
SELECT [name] As <\/span>VerwendeteAnmeldung, SUSER_SNAME() As <\/span>AktuelleAnmeldung\r\nFROM sys.user_token\r\nWHERE [type] IN (''Windows Login'', ''Windows Group'');<\/pre>\n<\/p>\n
If <\/span>strAnmeldung = \"Vertrieb\" Then<\/span>\r\nMe.cmdAuftraege.Enabled = True<\/span>\r\nMe.cmdKunden.Enabled = True<\/span>\r\n...\r\nMe.cmdStellen.Enabled = False<\/span>\r\nMe.cmdGeburtstagsliste.Enabled = False<\/span>\r\n...\r\nMe.Caption = \"Start - Benutzer \" & strBenutzer\r\nEnd If<\/span><\/pre>\nDer Fall Bienlein<\/h2>\n
<\/p>\n
Fazit und Bewertung<\/h2>\n
Installationsanleitung der Beispielumgebung<\/h2>\n
\n
\n
\n
Installation der Treiber<\/h2>\n
\n
\n
Beispielapplikation WaWi v2<\/h2>\n
\n