Office: (Office 2013) Zentrale Passwortliste in einer Excel-Datei von Netzlaufwerk?

Hallo!

Welches Passwort meinst du?
Wenn in der Anwendung nur der Windows-User ausgelesen wird und in der Anwendung kein weiteres Passwort abgefragt wird, weil man sich darauf verlässt, das das der angemeldete Windows-User ist, kann man mit der Set-Variante ohne irgendwelche Passwörter eine andere Identität annehmen, wenn Environ$("USERNAME") eingesetzt wird.

Darauf hinzuweisen, halte ich nicht für unseriös.

Die Ironie-Tags hast du aber schon gesehen?

Der Grund warum ich das schrieb: Es geht mir vor allem um den Einsatz des Aufrufs einer Funktion. Was dahinter steckt, macht man einmal und das wars. Den Aufruf nutzt man mehrmals.

Ob das nun so aussieht:
if fOSUserName() = "irgendwas" then
oder
if Environ$("USERNAME") = "irgendwas" then
Macht für mich den Unterschied, dass man sich bei der 2. Variante merken muss, was man als String an die Environ-Funktion übergibt.
Kapselt man das dann in eine weitere Funktion ist es für mich nicht mehr "aufwendiger".

Code:

führt dann wird zu
if fOSUserName() = "irgendwas" then


Aber zurück zum Thema:

Fall der Windows-User genutzt werden soll, könnte man mittels API auch dessen Kennwort über eine Maske prüfen. Das darf dann übrigens auch ein nicht aktuell angemeldeter Windows-User sein, wenn er Windows bekannt ist.

mfg
Josef

 

Ich bin zwar nicht angesprochen, aber ich glaube du gehst von anderen Voraussetzungen als wir aus. In dem Projekt, in dem ich über die Windows-Usernamen den Zugriff auf die Access-DB steuere müssen die User in der Access-DB KEIN zusätzliches Kennwort in Access angeben. Und genau in diesem Szenario stimmt dann auch wieder die Aussage von sonic.

Also ein bißchen Spass darf schon sein. Wenn ich hier nicht ab und zu auch was zu lachen gehabt hätte, wäre ich in all den Jahren nicht immer wiedergekommen.

 

Nein, das muss er eben nicht.

Wenn Du mit Environ("USERNAME") abfragst, welcher Benutzer gerade aktiv ist, kann sich ein beliebiger Benutzer mit
Code:

zum Administrator machen. - Ohne das zugehörige Passwort zu kennen.

?

 

\@sonic8

Da liegst Du falsch.
Es geht darum, mit einer DB zu arbeiten.
In meinen Anwendungen sind alle User (auch Admins!) mit einem Pwd versehen.
Da nützt auch ein Login (oder Set=...) als Admin nichts.
Ich gehe niemals davon aus, daß die Anmeldung an das BS automatisch auch die Berechtigung für den Start einer DB inkludiert.
Du schon?
Dann haben wir unterschiedliche Auffassungen betr. eines DB-Zuganges.

Wolfgang

 

Ja, durchaus. Es hat aus meiner Sicht klare Vorteile:
1.) Die Benutzer/Passwortverwaltung des Betriebssystems ist besser/sicherer als alles was ich in endlicher Zeit produzieren könnte.
2.) Der Benutzer kann sein Passwort an einer zentralen Stelle verwalten und muss das nicht separat in jeder Anwendung tun.
3.) Weniger relevant, aber dennoch erwähnenswert: Da Access ein Dateibasierendes System ist, kann man über das Betriebssystem zumindest den Usern, die gar nicht mit der Datenbank arbeiten, den Zugriff auf Dateisystemeben komplett verwehren. - Egal wie gut dein Sicherheitsystem in der Datenbank ist, Du kannst nicht verhindern, dass ein User ohne Berechtigunen innerhalb der Anwendung einfach die komplette Datei löscht. - Das gilt für User mit eingeschränkter, aber vorhandener Berechtigung natürlich in meinem Szenario genauso.

In den beiden ersten Punkten spare ich auch den Aufwand ein eine entsprechende eigene Lösung zu entwickeln.

Voraussetzung ist natürlich, dass die Umgebung ein Netzwerk ist, in dem sich jeder User mit seinem eigenen Account anmeldet.