Application Role auf alle Connections von Access 2003 anwenden

13/02/2008 - 13:39 von Mark Schneider | Report spam
Hallo,

brauche bitte Input bei folgender Aufgabenstellung:
Ein bestehendes Accessprojekt (ADP/ADE, Access 2003, SQL Server 2000 Std)
soll im Kundenauftrag von reiner Windows-User-Authentifizierung auf
Verwendung einer Application Role umgestellt werden, damit die User nicht
mehr ausserhalb der Access-Anwendung direkt auf den SQL-Datenbestand
zugreifen können.

Wenn ich nun die Connection um die Application-Role ergànze (und dem
eigentlichen Windows User die direkten Rechte nehme) klappt das auch wie
gewünscht für Tabellen und deren Anzeige, allerdings nicht für gebundene
Elemente (gebundene Reports, Ufos, die an Hauptformulare gebunden sind,
Listboxen/Kombinationsfelder usw.), da diese wohl ihre eigene Connection
(leider dann ohne Application Role) nutzen.

Habe dazu folgendes gefunden

Zitat:
"Subforms not working

Unlike with other database objects, Access does not always use the same
connection to retrieve the data source of a subform. Access frequently (but
not always) creates a new connection to SQL Server just to handle the
subform recordset, or to retrieve the linking field data that connects the
subform to the main form. Because this new connection does not have the
application role applied, a permissions error may be generated if you do not
have explicit permissions to the database object. Unfortunately, this means
that there is no reliable way to use bound subforms when application roles
are applied. The only effective workaround is to have completely unbound
subforms, with the data manipulation handled programmatically. This is the
most serious limitation when using application roles in Access. "

Wenn ich das richtig verstehe geht es also nicht, ohne die gesamte Anwendung
umzubauen und auf alle direkt gebundenen Elemente zu verzichten.

Kennt doch jemand einen Workaround / Trick um die Application Role global
für alle durch Access verwendeten Verbindungen zu setzen?

Oder gibt es einen anderen Weg, um zu realisieren, dass User nicht direkt
auf die Tabellen zugreifen können? (z. B. aus Excel heraus oder per ODBC
oder...
die Rechte auf Excel und ODBC-Verbindungen können wir den Usern nicht
nehmen).

Könnte man evtl. Erfolg haben mit einem normalen globalen SQL-Benutzer (kein
Windows User), der dann hart in der Anwendung verdrahtet ist? Oder stößt man
dann auf die gleichen Probleme, weil Access es im Hintergrund wieder mit der
Windowsauthentifizierung beim Server versucht? (Windows-Authentifizierung
muss für andere Datenbanken auf dem Server bestehen bleiben)?

Hatte jemand schon Erfolg mit dem Nachrüsten einer Application Role, ohne
auf alle gebundenen Controls/Reports/Subforms zu verzichten?

Dank im voraus
Mark
 

Lesen sie die antworten

#1 Stefan Hoffmann
13/02/2008 - 14:23 | Warnen spam
hallo Mark,

Mark Schneider schrieb:
Ein bestehendes Accessprojekt (ADP/ADE, Access 2003, SQL Server 2000 Std)
soll im Kundenauftrag von reiner Windows-User-Authentifizierung auf
Verwendung einer Application Role umgestellt werden, damit die User nicht
mehr ausserhalb der Access-Anwendung direkt auf den SQL-Datenbestand
zugreifen können.


Das ist imho Security by Obscurity. Bei einem ordentlichen Datenmodell
ist es irrelevant, wie darauf zugegriffen wird.

Wenn ich das richtig verstehe geht es also nicht, ohne die gesamte Anwendung
umzubauen und auf alle direkt gebundenen Elemente zu verzichten.


Korrekt.

Kennt doch jemand einen Workaround / Trick um die Application Role global
für alle durch Access verwendeten Verbindungen zu setzen?


Unter SQL Server 2005 und Oracle kann man da mit Logon-Triggern
arbeiten. Die gibts im SQL Server 2000 nicht.

Oder gibt es einen anderen Weg, um zu realisieren, dass User nicht direkt
auf die Tabellen zugreifen können? (z. B. aus Excel heraus oder per ODBC
oder...
die Rechte auf Excel und ODBC-Verbindungen können wir den Usern nicht
nehmen).


Nein, nicht mit dem Ansatz den Access verfolgt. Man bràuchte da ein
Middle-Tier. Bitte nicht füttern.)

Könnte man evtl. Erfolg haben mit einem normalen globalen SQL-Benutzer (kein
Windows User), der dann hart in der Anwendung verdrahtet ist? Oder stößt man
dann auf die gleichen Probleme, weil Access es im Hintergrund wieder mit der
Windowsauthentifizierung beim Server versucht?


Schwer zu sagen.

Der wichtigste Grund für Windows-Authentifizierung ist die Möglichkeit
einzelne Änderungen den Benutzern zuzuordenen zu können. Mit einem
globalen SQL-Benutzer ist das nur durch die Anwendungslogik machbar
(SUSER_SNAME() und Konsorten sind dann ja immer gleich).

Der einzige Trick der mir dazu einfàllt (ist aber auch nicht schön), nur
Verwendung von Sichten, die eine zusàtzliche "session"-temporàre Tabelle
einbinden.
Lege eine globale Tabelle an, die nur von Inhabern der Application Role
beschrieben wird, und binde diese in die Sicht ein, in etwa so:

CREATE TABLE UserSession (UID VARBINARY(85) NOT NULL, TableName
VARCHAR(64) NOT NULL)

Und Sichten mit

SELECT *
FROM Tabelle, UserSession
WHERE UserSession.UID = SUSER_SID() AND TableName = 'Tabelle'

Damit kann man zumindest "Zeitfenster" erzeugen, in denen es geht. D.h.
du schreibst in diese Tabelle die benötigten Tabellen rein, bevor du
darauf zugreifst, und löscht die Eintrage wenn du sie nicht mehr brauchts.

mfG

Access-FAQ http://www.donkarl.com/
KnowHow.mdb http://www.freeaccess.de
Newbie-Info http://www.doerbandt.de/Access/Newbie.htm

Ähnliche fragen