Office: Anmelden in der Datenbank über Benutzernamen?

Hallo Steffen,

beim arbeiten mit Berechtigungen, geht es selten darum die daten nicht kopierfähig zu machen, sondern darum wer/was inherhalb der Datei an Datenänderungen machen darf.
Wie bereits gesagt, du hast lediglich die Daten kopiert, was logischerweise geht, weil Lese-Rechte vergeben sind. In der Datei selbst hast du die Tabelle tblReadOnly nicht ändern können, und genau darum geht es!

Ohne diese Lese-Rechte wirst du definitiv nicht an die daten kommen, ohne die DB zu knacken.

Versuche mal die Tabelle tblLocked in der neuen Datei im Anhang mit access auszulesen.
Gruß
JPA

 

Ich habe mir jetzt noch mal die mühe gemacht Schritt für Schritt zu erläutern wie eine accdb-Datenbank-Datei in einer gesicherten Arbeitsgruppe gespeichert wird, dank dem UGAM-Tool:

1. Öffne irgend eine Datenbank-Datei

2. Erstelle mit dem Microsoft-Access-Arbeitsgruppen-Administrator eine neue Arbeitsgruppendatei. Dies geht im UGAM-Tool über Workgroup Administrator und gehe wie folgt vor:
- Klicke auf Beitreten und merke dir die aktuelle Angabe der mdw-datei und klicke auf abbrechen (Wichtig!)
- Klicke auf Erstellen und geben eine Arbeitsgruppen-ID an und bestätigen und neue MDW-Datei angeben (z.B. D:\sys.mdw)
- Klicke auf Beitreten und gebe die zuvor gemerkten mdw-datei wieder an und klick auf ok

3. Starte Access erneut mit folgenden Link:
"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE" /WRKGRP "D:\sys.mdw"

4. Öffne irgend eine Datenbank-Datei

5. Rufe das Dialogfeld User and Group accounts... im UGAM-Tool auf und erstelle einen neuen Benutzer (z.B. Boss), und ordner diesem die Gruppe Administratoren zu

6. Entziehe dem Benutzer Administrator die Gruppe "Administratoren"

7. Starte Access erneut mit folgenden Link:
"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE" /WRKGRP "D:\sys.mdw" /USER "Boss"

8. Erstelle eine neue, leere accdb-Datenbank

9. Lege ein Kennwort fest mit dem UGAM-Tool über User and Group accounts... und Reiter Anmeldungskennwort ändern

10. Lege die weiteren gewünschten Benutzer und Gruppen an. Ordne ggf. den Benutzern Gruppen zu

11. Importiere alle Objekte der zu schützenden Datenbank

12. Definiere alle importierten Tabellen als System Tabelle mit dem UGAM-Tool über Check tables attributes und Set Attribute

13. Mit User and Group permissions... im UGAM-Tool vergebe die gewünschten Berechtigungen pro Benutzer/Gruppe auf die Tabellen (Nur Tabellen, mit den anderen Objekttypen funz es nicht mehr)

14. Verwende zukünftig die Tabellen nicht direkt, also nur über Abfragen/Formulare/Berichte

Gruß
JPA

 

Hallo Jean Pierre,

Danke für die Mühe, die Du Dir gemacht hast.
Auch ich habe soeben ca. 2 Stunden damit verbracht, strikt nach Deinen Angaben eine Test-DB zu schützen, es gelingt mir einfach nicht, sie wasserdicht zu kriegen. Ich habe übrigens auch noch zusätzlich der Gruppe der Benutzer alle Rechte entzogen, diese Gruppe lässt sich nicht löschen und auch die Mitgliedschaft des Administrators auf diese Gruppe lässt sich nicht entfernen. Der Administrator lässt sich ebenfalls nicht löschen; aber das war schon immer so. Des weiteren habe ich den Besitz des Administrators an sämtichen Tabellen entzogen.

Wenn beim Aufruf die Parameter /wrkgadm "xxx.mdw" und /User "USername" wegbleiben und ich in einer beliebigen anderen DB wieder der Standard-Arbeitsgruppe C:\Windows\System32\System.mdw beitrete und danach die vermeintlich geschützte .accdb direkt doppelklicke, bin ich als Administrator der C:\Windows\System32\System.mdw drin und kann im Prinzip alles machen!!
Das einzige, was funktioniert, ist, dass die Tabellen, die auf Attribut Systemtabelle gesetzt sind, in der Tat schreibgeschützt sind.

Andererseits ist in Deiner Locked.accdb die Möglichkeit versperrt, die Zugriffsrechte zu ändern. Irgendetwas an Deiner Locked.accdb musst Du also doch noch zusätzlich gemacht haben, was in deinem Beitrag in #32 vielleicht noch fehlt.

Auf die Gefahr hin, zu nerven, noch einmal der Hinweis:
Beim Original-Acc2003- Datensicherheits-Assistenten (nicht gemeint sind die Boxen für Zugriffsrechte bzw. Konteneinrichtung, diese werden ja durch Dein Ugam-Tool nachgebildet) wurde nach Bestätigung der letzten (8.ten !!) Box eine Überführung der bisher ungesicherten in eine gesicherte Datenbank vorgenommen, zu Sicherheitszwecken wird extra in dieser letzten Box gefragt, wie der Dateiname der Sicherungskopie der BISHERIGEN UNGESICHERTEN Datenbank lauten soll, Standardvorschlag: .bak
Diesen Konvertierungsschritt vermisse ich bei Ugam.

Bitte verstehe mich recht:
Ich bin sehr daran interessiert, für zukünftige Acc2010-Projekte die .mdw-Philosophie aufrecht erhalten zu können (an alle, die sonst noch mitlesen: Jaaa, ich weiß, sie ist knackbar), sehr gern mit Hilfe Deines Ugam-Tools(!!!), wenn es denn so funktionieren würde wie die Original-Werkzeuge bei Access 2003.

Irgendetwas mache ich falsch oder übersehe es.

 

Der Parameter heißt /WRKGRP

Du bist zwar als Administrator drin, jedoch kannst du keine Berechtigungen ändern. Du kannst nicht die berechtigungen ändern die auf die System-Tabellen heerschen.
Falls doch, dann hast du punkt 6 vergessen: 6. Entziehe dem Benutzer Administrator die Gruppe "Administratoren"

Also... es geht um die Tabellen. Ja, in die DB-Datei kommst du rein, das kann man nicht mehr verhindern, das ging früher. Noch mal, nur noch die Tabellen lassen sich schützen, forms+reports+modules+macros nicht mehr. Das macht allerdings nichts, weil das schützt du über die Konvertierung in einer accde Datei. Und btw, in einem BE sind so wie so nur Tabellen vorhanden, oder *wink.gif*

Aber es geht gar nicht so sehr um Schutz vor Einbruch!
Es geht um praktische Systematik. Wenn du über das Berechtigungsystem eine Tabelle nur zum Lesen freigibst, dann gilt das für dein ganzes projekt. Du musst nichts mehr programmieren. Egal wie auch immer die Tabelle aufgerufen wird, per Abfrage, per form, per unterform usw... Die daten sind nicht änderbar.

Wenn du kein berechtigungssystem hast, musst du es per vba programmieren. Im jedem formular wo diese tabelle benutzt wird, musst du drauf achten, das ein vba code die eigenschaft allowedit auf false setzt (z.B.). Durch kluge programmierung kannst du das vereinfachen, aber dann fängst du auch schon wieder an ne klasse dafür zu programmieren.
Genau das macht das berechtigungssystem schon für dich!
Es ist so ähnlich wie die Funktion referentielle integrität von Access. Ein häckchen und sie ist aktiviert, access überwacht grundsätzlich die integrität zwischen den tabellen.
Du kannst es auch lassen und alles nachprogrammieren per vba code und queries... und das in jedem formular wo es diese tabellen betrifft.

Und am ende, bindet einer der sich etwas auskennt die Tabelle in einer anderen Datei ein und ändert alles was er will und dagegen kannst du ohne berechtigungssystem nichts machen!

Das wird bei meiner Anleitung mit Punkt 8 und 11 erledigt:
8. Erstelle eine neue, leere accdb-Datenbank
11. Importiere alle Objekte der zu schützenden Datenbank

Noch mal, mein Add-in ist KEIN Assistent. Er erlaubt "lediglich" das du wieder an die Microsoft Befehle rankommst. Was natürlich von mir genial ist *lachen
Die einzigste Zusatzfunktion ist das setzen der Attributes auf System-Tabelle, als kleiner service *grins

Nein, ich habe exakt diese 13 schritte durchgespielt. Habe es extra noch mal wiederholt, um sicher zu gehen nichts vergessen zu haben.

Und wer konnte die Tabelle tblLocked bisher schon auslesen ohne das Berechitungssystem zu knacken?
Und wer hast geschafft mit knacken?
Hallo Steffen, wie schaut es jetzt bei dir aus?
Gruß
JPA

 

Hallo,

die Tabellen-Geschichte ist einigermaßen "ekelhaft"... *Smilie

Was aber (nur mit VBA-Mitteln!) geht, ist bei Deinem ALTM-Tool das AllowBypass wieder zu aktivieren, da arbeitest Du ja soweit ich das sehe mit einem ähnlichen Trick (Entzug der Berechtigung mittels mdw), oder?

 

ekelhaft *confused.gif*

Alle meine Add-ins sind in einer gesicherten Arbeitsgruppe.

 

Hi,

das ist als Kompliment gemeint, d.h. "ekelhaft schwierig zu umgehen" oder auch "nein, ich kriegs nicht hin den Schutz zu umgehen". *Smilie

 

ah, verstehe *top