Menüpunkt Datei -> Externe Daten per GPO sperren?

[Christoph]

Hallo zusammen,

gibt es eine Möglichkeit, in Access 2003 den Menüpunkt Datei -> Externe
Daten per Gruppenrichtlinie zu sperren?
Ich möchte nicht, dass Benutzer per ODBC auf Datenbanken zugreifen können.
Denn trotz Beschränkung der Systemsteuerung können über diesen Weg ODBC
Quellen eingerichtet werden.

Danke für die Hilfe.
Grüße

Christoph

[Jens Schilling]

Hallo, Christoph

Post by Christoph
gibt es eine Möglichkeit, in Access 2003 den Menüpunkt Datei ->
Externe Daten per Gruppenrichtlinie zu sperren?
Ich möchte nicht, dass Benutzer per ODBC auf Datenbanken zugreifen
können. Denn trotz Beschränkung der Systemsteuerung können über
diesen Weg ODBC Quellen eingerichtet werden.

Da hab' ich mich bisher nicht mit beschäftigt - aber schau doch mal, ob Du
hiermit weiter kommst :

http://www.wintotal.de/Artikel/gruppenrichtlinien/teil4/teil4.php

[Sven Ludwig]

Post by Jens Schilling
Hallo, Christoph

Post by Christoph
gibt es eine Möglichkeit, in Access 2003 den Menüpunkt Datei ->
Externe Daten per Gruppenrichtlinie zu sperren?
Ich möchte nicht, dass Benutzer per ODBC auf Datenbanken zugreifen
können. Denn trotz Beschränkung der Systemsteuerung können über
diesen Weg ODBC Quellen eingerichtet werden.

Da hab' ich mich bisher nicht mit beschäftigt - aber schau doch mal, ob Du
http://www.wintotal.de/Artikel/gruppenrichtlinien/teil4/teil4.php

Hallo,

also wir setzen die von Jens beschriebenen Gruppenrichtlinienvorlagen
ein und kommen damit gut zurecht. Einzelne Menüpunkte kannst du in der
Gruppenrichtlinie unter "Benutzerkonfiguration / Administrative Vorlagen
/ Microsoft Office Access 2003 / Disable Items in user interface"
abschalten. Einige Menüpunkte sind unter "Predefined" schon vorgegeben.
Sollte Dein Menüpunkt fehlen, kannst Du Ihn unter "Custom" einfach
hinzufügen und damit auch deaktivieren.

Gruß,
Sven

[Jens Schilling]

Hallo, Sven

Post by Sven Ludwig
also wir setzen die von Jens beschriebenen Gruppenrichtlinienvorlagen
ein und kommen damit gut zurecht.

Das finde ich sehr interessant !
Gibt es dazu Besonderes zu berichten (Positives oder Negatives) ?

[Sven Ludwig]

Post by Jens Schilling
Hallo, Sven

Post by Sven Ludwig
also wir setzen die von Jens beschriebenen Gruppenrichtlinienvorlagen
ein und kommen damit gut zurecht.

Das finde ich sehr interessant !
Gibt es dazu Besonderes zu berichten (Positives oder Negatives) ?

Hallo,

wir setzten die GPOs für Office hauptsächlich bei Kunden ein, die Ihre
Benutzer selber anlegen und verwalten wollen. Diese Kunden haben jedoch
nich die Zeit oder das Wissen um Office allgemein mit einigermaßen
vernünftigen Einstellungen für jedes Profil vorzubereiten. Dafür sind
die Office-Richtlinien natürlich ideal. Speziell einige
Sicherheitseinstellungen (Stichwort Makrosicherheit) und
Oberflächeneinstellungen (Stichwort Aufgabenleiste) sind dann natürlich
immer optimal konfiguriert, ohne daß jemand daran rumschrauben muß.
Eigentlich sind das aber nich die Vorteile der Office-GPOs, sondern der
Gruppenrichtlinien allgemein ;-)

Gruß,
Sven

[Christoph]

Hallo Sven,

irgendwie komm ich da nicht weiter.
Wie muss ich das denn bei Custom eintragen, damit es auch wirksam wird? Bei
den vordefinierten Einstellungen sehe ich in der Registry, dass sich bei den
entsprechenden Keys die Werte verändern. Wenn ich Custom-Werte eintrage,
finde ich diese in einem Schlüssel namens "DisabledCmdBarItemsList", aber
leider interessiert sich das Access da nicht die Bohne für. Wäre es FileNew
FileNew... File | New File | New... mal als Beispiel für Datei Neu. Wie muss
das Format lauten.

Komischer Effekt bei den vordefinierten Attributen: Wenn ich die Policy auf
Aktiviert stelle, Häkchen bei den Attributen mache, OK anklicke setzt die
Policy sich automatisch auf Deaktiviert anstatt Aktiviert.

Danke
Grüße
Christoph

[Sven Ludwig]

Post by Christoph
Hallo Sven,
irgendwie komm ich da nicht weiter.
Wie muss ich das denn bei Custom eintragen, damit es auch wirksam wird? Bei
den vordefinierten Einstellungen sehe ich in der Registry, dass sich bei den
entsprechenden Keys die Werte verändern. Wenn ich Custom-Werte eintrage,
finde ich diese in einem Schlüssel namens "DisabledCmdBarItemsList", aber
leider interessiert sich das Access da nicht die Bohne für. Wäre es FileNew
FileNew... File | New File | New... mal als Beispiel für Datei Neu. Wie muss
das Format lauten.
Komischer Effekt bei den vordefinierten Attributen: Wenn ich die Policy auf
Aktiviert stelle, Häkchen bei den Attributen mache, OK anklicke setzt die
Policy sich automatisch auf Deaktiviert anstatt Aktiviert.
Danke
Grüße
Christoph

Hallo,

also bei den Custom-Werten darf nicht der Menüpunkt als Text eingetragen
werden. Es muß stattdessen die "CommandBar-ID" des Menüpunktes
eigetragen werden und das sollte eine Zahl sein. Die IDs sollten sich
bei Google finden lassen.

Bei den vordefinierten Attributen kann ich bei der Sperrung von
Menüpunkten genau das gleiche Verhalten mit dem automatischen
Deaktivieren nachvollziehen. Bei den Tastenkürzeln funktioniert's
merkwürdigerweise ganz normal. Aber ob die Richtlinie trotzdem greift,
kann ich hier grad leider nicht probieren.

Wobei ich mich grad frage, ob das Deaktivieren der Menüpunkte der
richtige Weg für dich ist. Die Benutzer kommen nämlich auch an die
ODBC-Verwaltung, wenn sie in der Tabellenansicht auf "Verknüpfen"
klicken. An diversen anderen Programmpunkten kommt man ebenfalls
dorthin. Vielleicht solltest du allgemein über die Sicherheit und die
Konfiguration der verwendeten Datenbank nachdenken. Ansonsten vielleicht
wirklich die odbcad32.exe sperren.

Gruß,
Sven

[Christoph]

Hallo Sven,

danke für die Hilfe bisher.
Ich habe es nun geschafft, die ID herauszufinden und das Sperren
funktioniert auch.
Ich habe auch den odbcad32 gesperrt.
Was aber immer noch geht ist der Weg über Einfügen - Tabelle - Tabelle
verknüpfen - Dateityp ODBC-Datenbanken. Hier kommt nach wie vor der Dialog
"Datenquelle auswählen" und ich kann mich bei allen Datenbankservern
umschauen ;)

Es ist natürlich logisch, dass der sicherste Weg die Absicherung der
Datenbanken ist. Ab und an muss man aber bestimmte Standard Passwörter von
Firmen einhalten, damit verschiedene Skripte funktionieren etc.
Außerdem möchte ich schon den Versuch verhindern.

Gibt es noch ne Idee wie ich den letzten verbliebenen Dialog sperren kann?
Danke
Grüße
Christoph

Post by Jens Schilling

Post by Christoph
Hallo Sven,
irgendwie komm ich da nicht weiter.
Wie muss ich das denn bei Custom eintragen, damit es auch wirksam wird? Bei
den vordefinierten Einstellungen sehe ich in der Registry, dass sich bei den
entsprechenden Keys die Werte verändern. Wenn ich Custom-Werte eintrage,
finde ich diese in einem Schlüssel namens "DisabledCmdBarItemsList", aber
leider interessiert sich das Access da nicht die Bohne für. Wäre es FileNew
FileNew... File | New File | New... mal als Beispiel für Datei Neu. Wie muss
das Format lauten.
Komischer Effekt bei den vordefinierten Attributen: Wenn ich die Policy auf
Aktiviert stelle, Häkchen bei den Attributen mache, OK anklicke setzt die
Policy sich automatisch auf Deaktiviert anstatt Aktiviert.
Danke
Grüße
Christoph

Hallo,
also bei den Custom-Werten darf nicht der Menüpunkt als Text eingetragen
werden. Es muß stattdessen die "CommandBar-ID" des Menüpunktes
eigetragen werden und das sollte eine Zahl sein. Die IDs sollten sich
bei Google finden lassen.
Bei den vordefinierten Attributen kann ich bei der Sperrung von
Menüpunkten genau das gleiche Verhalten mit dem automatischen
Deaktivieren nachvollziehen. Bei den Tastenkürzeln funktioniert's
merkwürdigerweise ganz normal. Aber ob die Richtlinie trotzdem greift,
kann ich hier grad leider nicht probieren.
Wobei ich mich grad frage, ob das Deaktivieren der Menüpunkte der
richtige Weg für dich ist. Die Benutzer kommen nämlich auch an die
ODBC-Verwaltung, wenn sie in der Tabellenansicht auf "Verknüpfen"
klicken. An diversen anderen Programmpunkten kommt man ebenfalls
dorthin. Vielleicht solltest du allgemein über die Sicherheit und die
Konfiguration der verwendeten Datenbank nachdenken. Ansonsten vielleicht
wirklich die odbcad32.exe sperren.
Gruß,
Sven

[Sven Ludwig]

Hallo,

der Menüpunkt "Einfügen - Tabelle - ..." sollte sich eigentlich auch
über die GPO sperren lassen. Die Schwierigkeit ist nur wieder die ID
heraus zu finden. In der Datenbankansicht, gibt's unter Tabellen noch
den Button "Neu". Der sollte dann wohl auch gesperrt werden, wenn er
nicht die gleiche ID hat, wie die normalen Menüpunkte "Einfügen -
Tabelle - ...". Probiert hab ich das ganze noch nicht - trotzdem viel
Erfolg ;-)

Gruß,
Sven

Post by Christoph
Hallo Sven,
danke für die Hilfe bisher.
Ich habe es nun geschafft, die ID herauszufinden und das Sperren
funktioniert auch.
Ich habe auch den odbcad32 gesperrt.
Was aber immer noch geht ist der Weg über Einfügen - Tabelle - Tabelle
verknüpfen - Dateityp ODBC-Datenbanken. Hier kommt nach wie vor der Dialog
"Datenquelle auswählen" und ich kann mich bei allen Datenbankservern
umschauen ;)
Es ist natürlich logisch, dass der sicherste Weg die Absicherung der
Datenbanken ist. Ab und an muss man aber bestimmte Standard Passwörter von
Firmen einhalten, damit verschiedene Skripte funktionieren etc.
Außerdem möchte ich schon den Versuch verhindern.
Gibt es noch ne Idee wie ich den letzten verbliebenen Dialog sperren kann?
Danke
Grüße
Christoph

Post by Jens Schilling

Post by Christoph
Hallo Sven,
irgendwie komm ich da nicht weiter.
Wie muss ich das denn bei Custom eintragen, damit es auch wirksam wird? Bei
den vordefinierten Einstellungen sehe ich in der Registry, dass sich bei den
entsprechenden Keys die Werte verändern. Wenn ich Custom-Werte eintrage,
finde ich diese in einem Schlüssel namens "DisabledCmdBarItemsList", aber
leider interessiert sich das Access da nicht die Bohne für. Wäre es FileNew
FileNew... File | New File | New... mal als Beispiel für Datei Neu. Wie muss
das Format lauten.
Komischer Effekt bei den vordefinierten Attributen: Wenn ich die Policy auf
Aktiviert stelle, Häkchen bei den Attributen mache, OK anklicke setzt die
Policy sich automatisch auf Deaktiviert anstatt Aktiviert.
Danke
Grüße
Christoph

Hallo,
also bei den Custom-Werten darf nicht der Menüpunkt als Text eingetragen
werden. Es muß stattdessen die "CommandBar-ID" des Menüpunktes
eigetragen werden und das sollte eine Zahl sein. Die IDs sollten sich
bei Google finden lassen.
Bei den vordefinierten Attributen kann ich bei der Sperrung von
Menüpunkten genau das gleiche Verhalten mit dem automatischen
Deaktivieren nachvollziehen. Bei den Tastenkürzeln funktioniert's
merkwürdigerweise ganz normal. Aber ob die Richtlinie trotzdem greift,
kann ich hier grad leider nicht probieren.
Wobei ich mich grad frage, ob das Deaktivieren der Menüpunkte der
richtige Weg für dich ist. Die Benutzer kommen nämlich auch an die
ODBC-Verwaltung, wenn sie in der Tabellenansicht auf "Verknüpfen"
klicken. An diversen anderen Programmpunkten kommt man ebenfalls
dorthin. Vielleicht solltest du allgemein über die Sicherheit und die
Konfiguration der verwendeten Datenbank nachdenken. Ansonsten vielleicht
wirklich die odbcad32.exe sperren.
Gruß,
Sven

[Jens Schilling]

Hallo, Sven

Dank Dir für Deine Ausführungen 1

Post by Sven Ludwig

Post by Jens Schilling

Gruppenrichtlinienvorlagen ein und kommen damit gut zurecht.

Das finde ich sehr interessant !
Gibt es dazu Besonderes zu berichten (Positives oder Negatives) ?

Eigentlich sind das aber nich die Vorteile der
Office-GPOs, sondern der Gruppenrichtlinien allgemein ;-)

Das ist mir schon klar ;-)
Mir ging es aber konkret um die Office-GPOs (denn damit hab' ich noch nichts
gemacht).

[Stefan Hoffmann]

hallo Christoph,

Post by Christoph
gibt es eine Möglichkeit, in Access 2003 den Menüpunkt Datei -> Externe
Daten per Gruppenrichtlinie zu sperren?
Ich möchte nicht, dass Benutzer per ODBC auf Datenbanken zugreifen können.

Primär gehört das Sicherheitskonzept des Servers:

http://support.microsoft.com/kb/318816/de

Post by Christoph
Denn trotz Beschränkung der Systemsteuerung können über diesen Weg ODBC
Quellen eingerichtet werden.

Windows-R, odbcad32 ist auch gesperrt?



mfG
--> stefan <--

[Christoph]

Post by Stefan Hoffmann
Windows-R, odbcad32 ist auch gesperrt?

Nö... wo find ich das denn in den Policies???

[Sven Ludwig]

Post by Christoph

Post by Stefan Hoffmann
Windows-R, odbcad32 ist auch gesperrt?

Nö... wo find ich das denn in den Policies???

Hallo,

wenn du das ODBC-Verwaltungsprogramm komplett sperren willst, mußt Du
unter "Benutzerkonfiguration / Administrative Vorlagen / System /
Angegebene Windowsanwendungen nicht ausführen" die "odbcad32.exe" eintragen.

Gruß,
Sven

[Stefan Hoffmann]

hallo Sven,

Post by Sven Ludwig

Post by Christoph

Post by Stefan Hoffmann
Windows-R, odbcad32 ist auch gesperrt?

Nö... wo find ich das denn in den Policies???

wenn du das ODBC-Verwaltungsprogramm komplett sperren willst, mußt Du
unter "Benutzerkonfiguration / Administrative Vorlagen / System /
Angegebene Windowsanwendungen nicht ausführen" die "odbcad32.exe" eintragen.

Dann erzeuge ich mir eine File-DSN und kopiere sie auf das System...

mfG
--> stefan <--

[Sven Ludwig]

Post by Stefan Hoffmann
hallo Sven,

Post by Sven Ludwig

Post by Christoph

Post by Stefan Hoffmann
Windows-R, odbcad32 ist auch gesperrt?

Nö... wo find ich das denn in den Policies???

wenn du das ODBC-Verwaltungsprogramm komplett sperren willst, mußt Du
unter "Benutzerkonfiguration / Administrative Vorlagen / System /
Angegebene Windowsanwendungen nicht ausführen" die "odbcad32.exe" eintragen.

Dann erzeuge ich mir eine File-DSN und kopiere sie auf das System...
mfG
--> stefan <--

Hallo,

irgendwer findet immer nen Weg ;-) Aber ich denke auch, daß das nich
ganz der richtige Weg ist. In der ODBC-Verwaltung greift doch auch die
normale Windows-Berechtigungssteuerung und in den dahinterhängenden
Datenquellen sollten ja weitere Sicherheitsschranken vorhanden sein. Von
daher macht's eigentlich wenig Sinn, sich so viel Gedanken um die
Sperrung der ODBC-Verwaltung zu machen.

Gruß,
Sven

[Stefan Hoffmann]

hallo Sven,

Post by Sven Ludwig
irgendwer findet immer nen Weg ;-)

Eben.

Wenn man sich System ansieht, die diesen Grad an Sicherheit bieten, dann
handelt es sich immer mehrschichtige Anwendungen. Im klassischen
Client/Server-Betrieb ist das nur mit Application Roles möglich, und die

a) funktionieren nicht immer (ADP).
b) können mit notwendigem Wissen umgangen werden.

Der einzige, echte Schutz auf dieser Ebene ist eine korrekt "gebaute"
Datenbank (Sichten, SPs), welche die notwendige Logik vollständig umsetzt.

Denn im Endeffekt ist es irrelevant, ob ich die Daten mit meiner
Anwendung betrachte, oder direkt.


mfG
--> stefan <--