ich soll eine Access Datenbank mit einer Benutzerkennung
und Passwortabfrage versehen OHNE dass der Benutzer bei
jedem öffenen von Access diese Infos eingeben muss.
Kann mir da jemand helfen?
Vielen Dank
Sascha
O.T.
Wann soll den die Benutzerabfrage eingeblendet werden ??
MfG
Ralf
"Sascha" <ra...@gmx.net> schrieb im Newsbeitrag
news:1254701c1249a$d773f970$b1e62ecf@tkmsftngxa04...
"Sascha" <ra...@gmx.net> schrieb:
>ich soll eine Access Datenbank mit einer Benutzerkennung
>und Passwortabfrage versehen OHNE dass der Benutzer bei
>jedem öffenen von Access diese Infos eingeben muss.
Und wozu sollen die dann gut sein?
Chris
--
Bitte schickt mir KEINE Kopien Eurer Postings PER EMAIL. Ich lese alle
Threads, an denen ich mich beteilige ... jedenfalls eine Zeit lang ;-)
Direkte Anfragen per eMail werde ich nicht mehr beantworten.
mit "/user %USERNAME%" (ohne Gänsefüßchen) habe ich unter NT 4 SP 6 den
NT-User an Access 97 übergeben (in der Verknüpfung zur mdb), aber ohne
Paßwort. In Access ist dann in der Tat der NT-User auch der Access-User.
Folgendes ist zu beachten:
a) der User muss in Access mit der gleichen Kennung eingerichtet sein wie
der NT-User
b) dieser User ist bei mir ohne Paßwort
c) wenn sich ein anderer NT-User einloggt, dann erscheint die
Access-Anmeldebox (Access kann ja dann den User nicht finden).
d) um zu vermeiden, dass sich ein anderer NT-User in die mdb einloggt, prüfe
ich bei Startbeginn, ob NT-User und Access-User übereinstimmen (sonst
tschüß); man könnte natürlich auch eine Art Gast-User ermöglichen...
e) ich habe als allererstes eine eigene Access-Arbeitsgruppe eingerichtet
(die ich ebenfalls in der Verknüpfung als Parameter übergebe) und die
notwendigen User eingerichtet (und den Access-Admin entrechtet :-))
Wie gesagt, dies habe ich unter NT4 gemacht. Wie das mit Win 95, 98, 2000,
ME oder bald auch XP ausschaut, kann ich nicht sagen. Ferner habe ich es
auch nur mit Access 97 gemacht.
Vielleicht ist ja eine Anregung dabei.
Schönen Gruß, Johannes
"Sascha" <ra...@gmx.net> schrieb im Newsbeitrag
news:1254701c1249a$d773f970$b1e62ecf@tkmsftngxa04...
Übrigens:
Diese Lösung hat den Vorteil, dass die Passwörter nicht mit entsprechender
Software (ja, die gibt es) aus der Arbeitsgruppendatei ausgelesen werden
können. Sind diese dann noch identisch mit der Netzwerkanmeldung, sind alle
Türen offen. Ich halte deshalb diesen Weg nicht nur für komfortabel, sondern
auch für den sichersten Weg unter MS-Access!
Ich habe zusätzlich noch eine Prüfung drin, ob die Datenbank auch von dem
Firmennetzwerk aus gestartet wird. Von wegen Kopie und so.
Frank
"Johannes Goertz" <johanne...@sqs.de> schrieb im Newsbeitrag
news:e7bNliVJBHA.1880@tkmsftngp02...
"Frank Wiesner" <wie...@ugsnet.de> schrieb:
>Ich habe es fast genauso gemacht, mit dem kleinen Unterschied, dass der
>Aufruf über ein WSH-Script läuft. Dass sollte für alle Windows-Versionen ab
>95 funktionieren (ME und XP ohne Erfahrung).
Ich gebe zu bedenken, daß gerade der WSH aus naheliegenden Gründen oft
abgeschaltet wird.
>Diese Lösung hat den Vorteil, dass die Passwörter
Kannst Du mit dem WSH das Windows-AnmeldePASSWORT an Access weitergeben?
>nicht mit entsprechender
>Software (ja, die gibt es) aus der Arbeitsgruppendatei ausgelesen werden
>können.
Ohne Arbeitsgruppendatei hast Du in Access aber auch keinen User-Login, mit
hingegen die obigen Probleme. Ich sehe darin keinen Vorteil.
>Sind diese dann noch identisch mit der Netzwerkanmeldung, sind alle
>Türen offen. Ich halte deshalb diesen Weg nicht nur für komfortabel, sondern
>auch für den sichersten Weg unter MS-Access!
>Ich habe zusätzlich noch eine Prüfung drin, ob die Datenbank auch von dem
>Firmennetzwerk aus gestartet wird. Von wegen Kopie und so.
Das nützt natürlich nur etwas, wenn Du eine MDE auslieferst.
Johannes hat beschrieben, wie es ohne WSH auch funktioniert. Auch mit einer
VB-Exe sollte gleiches zu erreichen sein.
Für Interessierte habe ich mal mein access.vbs unten drangehängt.
>
<snipt>
> Kannst Du mit dem WSH das Windows-AnmeldePASSWORT an Access weitergeben?
<snip>
> Ohne Arbeitsgruppendatei hast Du in Access aber auch keinen User-Login,
mit
> hingegen die obigen Probleme. Ich sehe darin keinen Vorteil.
Du hast offensichtlich das grundlegende Prinzip noch nicht so ganz
verstanden. Ich versuche mal deutlicher zu formulieren:
1. Es gibt sehr wohl eine Arbeitsgruppendatei, bei der wie üblich der
Benutzer Admin keine oder minimale Rechte hat.
In dieser Arbeitsgruppendatei sind alle Anwender mit Ihrem Anmeldenamen
aber OHNE Password eingetragen.
Da keine Passwörter eingetragen sind, können auch keine ausgelesen
werden.
2. Der Benutzer Admin hat ebenfalls KEIN Password, es erfolgt also auch kein
Anmeldedialog.
3. Der Benutzername kann aber als Parameter beim Aufruf der Datenbank
übergeben werden, ebenfalls die Arbeitsgruppendatei.
Johannes verwendet hierfür die Verknüpfung, ich gehe über den WSH.
Wird die Datenbank direkt über Access oder über den Explorer aufgerufen,
ist der aktuelle Benutzer "Admin" und hat keine Rechte.
4. Natürlich könnte jeder einigermaßen versierte USER sich ohne weiteres als
jemand anderes ausgeben. Deswegen erfolgt
beim Starten der Datenbank sofort die Abfrage, ob Access-User und
Windows-User identisch sind, ansonsten tschüss.
(Ich habe für mich eine Funktion eingebaut, dass ich als Windows-User
auch andere Access-User auf die korrekten Einstellungen der Rechte testen
kann)
5. Nun könnte noch jemand auf die Idee kommen, die ganze Datenbank mitsamt
Arbeitsgruppendatei zu kopieren, auf einem anderen Netzwerk oder zu Hause
schnell einen USER "Wiesner " einrichten und das wars. Deswegen prüfe ich
noch zusätzlich, ob der Zugriff auf unsere Firmenserver vorhanden ist.
Es ist also nicht notwendig, das Windows-Password zu übergeben. Es reicht
aus, als gültiger Windowsbenutzer angemeldet zu sein.
>snip>
> Das nützt natürlich nur etwas, wenn Du eine MDE auslieferst.
>
Alle Sicherheitsabfragen sind in einer getrennten Datenbank, die ohne
Probleme als MDE gespeichert werden kann und als Verweis eingebunden wird.
Sicherlich gibt es bei einer Desktop-Datenbank immer irgendeine
Sicherheitslücke, die Verwendung von Passwörtern in Arbeitsgruppendateien
halte ich jedoch für nicht akzeptabel.
Frank
Hier noch die Datei access.vbs:
' Start MS-Access with loginname
dim WshShell
Set WshShell = Wscript.CreateObject ("Wscript.Shell")
'MDW-Datei
wrk1 = "W:\x\y\z\login.mdw" 'Hier anpassen!
'read the path to Access
key = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\MSACCESS.EXE\"
path = WSHshell.Regread (key)
' read loginname
key95 = "HKEY_LOCAL_MACHINE\Network\Logon\username"
keyNT = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\DefaultUsername"
On error resume next
logname = WSHshell.Regread (key95)
if err = 0 then
winver = "95"
else
winver = "NT"
logname = WSHshell.Regread (keyNT)
end if
Set objArgs = WScript.Arguments ' create object with collection
aufruf = """" + path + """" + "/wrkgrp" + """" + wrk1 + """" + _
"/user" + """" + logname + """"
if objArgs.Count = 1 then
aufruf = aufruf + """" + objArgs(0) + """"
end if
WshShell.Run aufruf 'start access
' end of script
>4. Natürlich könnte jeder einigermaßen versierte USER sich ohne weiteres als
>jemand anderes ausgeben. Deswegen erfolgt
> beim Starten der Datenbank sofort die Abfrage, ob Access-User und
>Windows-User identisch sind, ansonsten tschüss.
> (Ich habe für mich eine Funktion eingebaut, dass ich als Windows-User
>auch andere Access-User auf die korrekten Einstellungen der Rechte testen
>kann)
>5. Nun könnte noch jemand auf die Idee kommen, die ganze Datenbank mitsamt
>Arbeitsgruppendatei zu kopieren, auf einem anderen Netzwerk oder zu Hause
>schnell einen USER "Wiesner " einrichten und das wars. Deswegen prüfe ich
>noch zusätzlich, ob der Zugriff auf unsere Firmenserver vorhanden ist.
Ja, so paßt das. Danke für die ausführliche Erläuterung.
Chris
--
Es gibt Tage, da lohnt es sich einfach nicht, aufzustehen.
Zum Beispiel Montag bis Freitag.