Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Passwortabfrage beim öffnen verhindern
zurück: Mehrbenutzer einrichten Access, SQL Server weiter: Access 2010 - SQL Server Compact Datenbank Verbindung Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Antwort Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
grisu74
Im Profil kannst Du frei den Rang ändern


Verfasst am:
05. Jan 2014, 16:01
Rufname: Udo
Wohnort: Deutschland

Passwortabfrage beim öffnen verhindern - Passwortabfrage beim öffnen verhindern

Nach oben
       Version: Office 2013

Hallo zusammen.

Ich habe ein Frontend mit SQL-Backend.

Die Tabellen habe ich verlinkt.
Beim Öffnen von Access wird jetzt die SQL-Serveranmeldung eingeblendet.

Wie kann ich das stoppen?

Ich würde da gerne ein eigenes Anmeldefenster mit ODBC-Connectionstring verwenden.

MfG Udo
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
05. Jan 2014, 19:43
Rufname:


AW: Passwortabfrage beim öffnen verhindern - AW: Passwortabfrage beim öffnen verhindern

Nach oben
       Version: Office 2013

Hallo,

such mal nach "DSN-less connection", der Link steht hier im Forum bereits xmal.

Gruß

Christian
grisu74
Im Profil kannst Du frei den Rang ändern


Verfasst am:
06. Jan 2014, 11:00
Rufname: Udo
Wohnort: Deutschland

AW: Passwortabfrage beim öffnen verhindern - AW: Passwortabfrage beim öffnen verhindern

Nach oben
       Version: Office 2013

Hallo.

Danke erst mal.
Die Verbindung bekomme ich hin.

Aber irgendwas übersehe ich!
Wenn die Tabellen verknüpft sind und die Datenbank geschlossen wird bleibt die Verknüpfung ja bestehen.

Wenn jetzt die Datenbank wieder geöffnet wird, kommt folgendes Anmeldefenster.
Dies erscheint vor jeglicher autoexec usw.

Gruß



Unbenannt.JPG
 Beschreibung:
 Dateigröße:  51.93 KB
 Angeschaut:  227 mal

Unbenannt.JPG


Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
06. Jan 2014, 11:38
Rufname:

AW: Passwortabfrage beim öffnen verhindern - AW: Passwortabfrage beim öffnen verhindern

Nach oben
       Version: Office 2013

Hallo,

das war schon klar, darum sollst Du ja nach o.g. Begriff suchen. Deine Verbindung ist nicht DSN-los, daher das Problem.

Gruß

Christian
grisu74
Im Profil kannst Du frei den Rang ändern


Verfasst am:
07. Jan 2014, 08:21
Rufname: Udo
Wohnort: Deutschland

AW: Passwortabfrage beim öffnen verhindern - AW: Passwortabfrage beim öffnen verhindern

Nach oben
       Version: Office 2013

Hallo.

Nach der Methode habe ich die Verknüpfung auch erstellt.
Mir ist aufgefallen, das Microsoft folgenden Syntax verwendet.
Code:
    Set td = CurrentDb.CreateTableDef(stLocalTableName, dbAttachSavePWD, stRemoteTableName, stConnect)
Ich habe das ganze immer ohne dbAttachSavePWDgemacht.

Nur jetzt hat der Benutzer ja immer Zugriff auf alle Tabellen.
Jetzt wird das Passwort und der Benutzer im Connectionstring gespeichert.

Ich möchte aber zur Sicherheit, das der Benutzer zumindest 1 mal das Passwort beim connecten der DB eingibt.

es soll nicht in der Datenbank gespeichert werden.

Gruß
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
07. Jan 2014, 08:40
Rufname:

AW: Passwortabfrage beim öffnen verhindern - AW: Passwortabfrage beim öffnen verhindern

Nach oben
       Version: Office 2013

Hallo,

für jede verlinkte Tabelle wird eine eigene Verbindung zum Server aufgebaut. Wenn Du also das Kennwort nicht mit im Connectionstring speicherst, dann kommt die Nachfrage nach dem Login bei jedem ersten Zugriff auf die Tabelle/View.

Wenn Du also die Funktionalität der dsnlosen Verbindung per Code implementiert hast, dann ist die einfachste Methode, ein entsprechendes Login-Formular vorzuschalten, in das der User die Anmeldedaten eingeben muß. Dann kannst Du den dsnlosen Code verwenden, um alle Tabellen/Views neu zu verlinken mit den eingegebenen Daten.

Allerdings wäre hier schon wieder das Sicherheitsmodell zu überdenken, denn wenn der User ein Kennwort benötigt, dann handelt es sich um einen SQL Server User, entsprechend gibt es entweder nur einen allgemeinen User, den jeder verwendet, oder Du hast je einen SQL Server User für jeden einzelnen Anwender. In letzterem Fall wäre es einfacher, dann auf Windows Authentifizierung umzustellen, womit Deine Anwendung und die verlinkten Tabellen nichts mehr mit dem Login zu tun haben (müßten also nur noch einmal verlinkt werden, außer bei Anwendungsänderungen). Gibt es nur einen User, macht es keinen Sinn, den User nach dem Kennwort zu fragen, denn dann spricht sich das rum und jeder verwendet die Tabellen/Views dann auch für eigene Zwecke wie etwa aus einer eigenen Access-Anwendung/Excel usw., womit die Datensicherheit nicht mehr gewährleistet ist. Also ist es besser, Benutzername und Kennwort mit in den Connectionstring zu speichern, sofern das Frontend ausreichend abgesichert ist, daß da keiner mit Normalmethoden an die Informationen rankommt.
Die Anwendung sollte dann natürlich auch noch über eine eigene Benutzerverwaltung verfügen.

Ich mache es momentan so, daß ich einen SQL Server User habe, der lediglich für den Zeitraum des Logins benutzt wird und nur sehr wenige Objekte verwenden kann. Mit diesem wird ein Login aus einer eigenen Benutzer/Kennwort-Tabellenverwaltung durchgeführt, und wenn der Benutzer sich so angemeldet hat, dann schickt die Login-Prozedur vom Server die Anmeldedaten für einen weiteren SQL Server Benutzer an das Frontend. Das Frontend kann nun alle übrigen Ressourcen mit diesen Anmeldedaten verbinden, womit der Benutzer niemals auf SQL Server User Ebene irgendwelche Anmeldedaten kennen muß und der Login-Benutzer ihm für andere Zwecke nichts nutzt, da dieser nur Berechtigungen auf Login-Objekte hat. Auf diese Weise umgehe ich die Windows-Authentifizierung, die zwar sicherer und einfacher zu verwalten ist, aber voraussetzt, daß man auf Domänenebene die Berechtigung hat, User zu Gruppen hinzuzufügen und ggf. Gruppen neu anzulegen usw., die Berechtigungen habe ich hier leider nicht und daher verwende ich so mein eigenes Sicherheitsmodell.

Gruß

Christian
grisu74
Im Profil kannst Du frei den Rang ändern


Verfasst am:
07. Jan 2014, 10:23
Rufname: Udo
Wohnort: Deutschland

AW: Passwortabfrage beim öffnen verhindern - AW: Passwortabfrage beim öffnen verhindern

Nach oben
       Version: Office 2013

Hallo Bitsqueezer.

Das hört sich sehr interessant an.

Hast du da evtl. eine Beispieldatenbank parat?

Mein Problem war das ich ohne irgend eine Tabelle/View zu öffnen bereits den SQL User und Passwort eingeben musste. Siehe Bild!!

Eine Windows Authentifizierung funktioniert bei mir nicht, da ich teilweise übers Internet arbeite und keinen VPN-Tunnel habe.

Ich komme also gar nicht zu dem Punkt mittels einer selber gebastelten Benutzerverwaltung zu arbeiten, da ich keinen Code vor dieser Anmeldung ausführen kann.

Gruß
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
07. Jan 2014, 13:48
Rufname:


AW: Passwortabfrage beim öffnen verhindern - AW: Passwortabfrage beim öffnen verhindern

Nach oben
       Version: Office 2013

Hallo,

nein, ich habe natürlich keine Beispieldatenbank, da dies ja aus Access und SQL Server besteht und daher so eine Beispieldatenbank nur aufwendig zu konstruieren wäre.

Eine Verbindung per Internet mit Direktzugriff auf einen Datenbankserver per SQL Server User, noch dazu ohne VPN? Ich würde mal sagen: Der reine Wahnsinn. Wenn man schon per Internet auf eine Firmendatenbank zugreifen muß, dann auf jeden Fall zwingend über einen Login auf einer Website und dann gehen alle Zugriffe auf die Datenbank nur über einen Webserver, der als einziger die Verbindungsdaten zum Datenbankserver kennt. Ansonsten kannst Du die Datenbank auch gleich zum Download für alle anbieten...

Aber unabhängig davon funktioniert das Modell auch dann (wenngleich genauso potentiell gefährlich): Die Links auf die Tabellen werden vor dem endgültigen Ausliefern des Frontends komplett entfernt, somit kommt auch keine Nachfrage für eine Anmeldung von Access direkt (im Fall einer ACCDB). Per ADO kannst Du dann einen festen User/Kennwort an den Server im Connectionstring senden und ebenfalls per ADO in der so geöffneten Verbindung eine Stored Procedure ausführen, die dann als Parameter den Usernamen/Kennwort aus Deinem Login-Formular entgegennimmt (die natürlich aus einer Servertabelle kommen und nichts mit dem SQL Server User zu tun haben).
Somit werden für die Ausführung also zwei Username/Kennwort-Paare gebraucht, das eine steckt als immer gleicher Login-Benutzer (für alle Frontends gleich) im Connectionstring, das andere wird vom Benutzer in ein ungebundenes Formular eingegeben und als Parameter an die SP übergeben.
Die SP prüft dann auf dem Server, ob die übergebenen Login-Daten mit dem Inhalt der Tabelle übereinstimmen (Kennwort wird natürlich vor dem Senden an den Server am Frontend verschlüsselt, mindestens in einen Hash umgerechnet, Kennwörter auf dem Server werden auf die gleiche Weise verschlüsselt gespeichert, so daß die SP nur beide verschlüsselte Werte vergleicht und keine Kennwörter im Klartext). Wenn das der Fall ist, bekommt die Anwendung das eigentliche SQL-Username/Kennwort-Paar von der SP als Recordset oder als OUTPUT-Parameter zurückgeliefert, so daß das Frontend nun beginnen kann, alle Tabellen/Views mit Hilfe der zurückgeschickten Anmeldedaten dsnlos zu verbinden. Vor dem Beenden der Anwendung werden die Links einfach wieder gelöscht.
Die zurückgeschickten SQL-Server-Login-Daten können immer der gleiche Benutzer sein oder alternativ, wenn gewünscht, kannst Du auch für jeden Benutzer in der eigenen Usertabelle ein SQL-Server-Username/Kennwort hinterlegen, oder per Department usw.
Vorteil ist vor allem: Wenn Du das SQL Server Kennwort im Backend mal ändern mußt, kannst Du das einfach machen, solange der eine SQL-Server-Login-User immer gleich bleibt. Dieser bekommt lediglich das Recht, diese eine SP auszuführen, und da diese eine gültige User/Kennwort-Eingabe voraussetzt, können Verknüpfungen nicht ohne diese eingerichtet werden. Und Deine Anwendung fragt nie mehr nach SQL Server Usern, ohne dabei an Sicherheit einzubüßen.

Aber wie gesagt, niemals direkt über das Internet, das ist reiner Selbstmord.
Will man eine Fernverbindung zulassen, ist einer der sichersten Wege, eine VPN-Verbindung aufzubauen und das Frontend auf einem Terminalserver zu starten, nebenbei sorgt das auch für die bessere Performance und Sicherheit, da Daten nie zwischen PC und Backend ausgetauscht werden, sondern nur zwischen entferntem Remote-Client und entferntem Datenbankserver.

Gruß

Christian
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Diese Seite Freunden empfehlen

Seite 1 von 1
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Microsoft Access und MS SQL Server: Passwortabfrage bei Zugriff auf MS SQL Server 1 peeka 322 20. Aug 2013, 15:07
peeka Passwortabfrage bei Zugriff auf MS SQL Server
Keine neuen Beiträge Microsoft Access und andere Datenbank-Server: Abfangen der User und Passwortabfrage 2 ArminBu 2335 01. Jun 2010, 13:05
Gast Abfangen der User und Passwortabfrage
Keine neuen Beiträge Microsoft Access und andere Datenbank-Server: Dokument von mehreren Arbeitsplätzen gleichzeitig öffnen??? 1 Gast 3525 29. Jun 2007, 07:21
Gast Dokument von mehreren Arbeitsplätzen gleichzeitig öffnen???
Keine neuen Beiträge Microsoft Access und MS SQL Server: Diagramme lassen sich nicht öffnen, nach SP4/SQL2000-Inst 2 Planktom 1095 26. Sep 2005, 19:37
Planktom Diagramme lassen sich nicht öffnen, nach SP4/SQL2000-Inst
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: HTML Editor Forum