Authorisierung

Martinha

Fleissiger Benutzer
Beiträge
65
Hallo,

folgende Situation:
Ich habe eine Accessanwendung erfolgreich bezgl der Daten auf eine MS Sql Db umgestellt. Alle Tabellen und Abfragen laufen jetzt auf dem Server.
Der Server war lokal installiert.
Jetzt möchte ich die Daten auf einen externen Server installieren und es sollen maximal 4 Benutzer damit arbeiten.
ich werde dann bei diesen 4 die verbleibene Access Anwendung mit Formularen, Berichten und Modulen installieren.

Ich habe mir bei Strato einen externen DB Server gemietet.

Dann habe ich gestern mehrere Stunden über Authorisierungs Konzept gelesen...da kann man ganz schnell ins Unterholz geraten.
Frage: was würdet ihr für ein Konzept für diese 4 User empfehlen? Es soll natürlich sicher, aber auch einfach zu handeln sein.

Diese User sollen auf der DB Lese und Schreibberechtigung haben, aber keine alter Befehle absetzten können.
ich dachte an so ein (abstraktes) Konzept:

Ich lege für die 4 User Userkennung und PW auf der DB mit den passenden berechtigungen an.
Ich schicke den Usern über einen sicheren Kanal ein txt- Datei in der User und PW stehen.
Bevor sich die Accessanwendung mit der DB Connectet, liest sie diese Informationen und stellt dann den Connect her.

Wäre das ein gangbarer Weg?

Für Hinweise wäre ich dankbar!
Martin
 
Werbung:
Naja, wie Du / Die User das Login (und Übergabe der Login Daten) machen, hängt ja wesentlich davon ab, wie der Serverzugang in der Access App implementiert ist.
Was die User auf der DB dürfen, hängt davon ab, welche Rechte ihnen unter dem jeweils gegeben Account zur Verfügung stehen.
Stichworte: grant / revoke
 
Hi,

wenn Access aufgerufen wird, stelle ich (hier natürlch lokal) die Verbindung so her:

establishconnection_local ("DbAdcDevelopment")
connectDB "DbAdcDevelopment", "DBADCDEVELOPMENT"

Public Sub establishconnection_local(database_name As String)

Dim connection As ADODB.connection
Dim server_name As String

Dim security_name As String
Dim provider_name As String
Dim connstring As String

'
' Wenn die Verbindung schon da ist, keine neue mehr machen
'

If Me.connected = True Then

Exit Sub

End If

Set connection = New ADODB.connection

provider_name = "MSOLEDBSQL"
server_name = "DESKTOP-1MF9NJB\ADCSQLSERVER"
security_name = "Integrated Security=SSPI"
connstr = "provider= " & provider_name & ";Server=" & server_name & ";database=" & database_name & "; " & security_name

Set connection = New ADODB.connection

With connection
.ConnectionString = connstr
.Open
End With

If connection.State = 1 Then
MsgBox "Connected mit " & database_name, vbExclamation, "Connect Database"
Me.connected = True
Else
MsgBox "Connection mit " & databasename & " konnte nicht hergestellt werden", vbCritical, "Connection Error"
Me.connected = False
End If

End Sub

Connectdb:

....

For i = 0 To db.TableDefs.Count - 1

If InStr(db.TableDefs(i).Name, "MSys") = 0 Then

db.TableDefs(i).Connect = "ODBC;DSN=" & database & ";Trusted_Connection=Yes;APP=Microsoft Office;DATABASE=" & database
db.TableDefs(i).RefreshLink

End If

Next i


In der lokalen DB gibt es mehrere Instanzen, die dann entsprechend mit anderen Parametern connected werden.
Das ganz wird nur einmal pro Session aufgerufen und klappt fehlerfrei.
Liegt das Ganze auf dem Server werden vermutlich Userid und PW dazu kommen, wenn ich das richtig verstanden habe.

Die Benutzer sollen die DB mit Select, Update, Insert und delete Befehlen nutzen können, aber z.B. kein Alter Table oder ähnliches absetzen können.
Da die Oberfläche ja fast identisch geblieben ist, sollen sie im Grunde gar nicht merken, dass sie jetzt auf einem Server arbeiten.
Allerdings habe ich bei den relevanten Formularen den Datensatzmarkierer auf "ja" gestellt, der anzeigt, ob einen Datensatz grade in Bearbeitung ist. Bei "Datensätze sperren" habe ich "bearbeiteter Datensatz" aktiviert.

Danke für Hilfe!

Martin
 
Kurze Frage vorweg: Deine 4 Benutzer verbinden sich von ihren Arbeitsplätzen zu dem Stratoserver, korrekt? Wenn ja, dann erstmal folgendes einrichten:
1. VPN Verbindung vom Client zum Server,
2. SSL Verschlüsselung für die SQL Server Verbindung einrichten. Mit einem offiziellen Zertifikat.
3. Genau so machst Du es. 4 Accounts auf dem Datenbankserver für die 4 User. Die Rechte für Select, Update, Insert und delete können problemlos pro User vergeben werden.
 
Hi T-Sql,

danke für deine Mail.
Ja, so wird es sein mit den Usern.

Ich habe gestern auf dem SQl Server den sa user so eingerichtet, das ich mit ihm eine lokale zertifizierte Anmeldung manchen kann und das hat auch geklappt. SSMS habe ich da auch dafür eingerichtet und eine Datenbank mit einer Tabelle angelegt.
Dann habe ich den Port 1433 eingerichtet und die Firewall entsprechend angepasst. Aber Verbindung zu dem externen SQL-Server von dem SSMS von meinem PC aus klappt noch nicht.
Aber ich pausiere jetzt erstmal. ich bin grade in SE-Asien und die Internetverbindung ist hier wie zu ISDN-Zeiten.
Geh dann mal lieber schnorcheln im Pazifik, haben hier grade 32 Grad...bitte nicht neidisch werden!
Anfang Juli bin ich wieder in D, dann geht es weiter.

Nochmals danke und bis dahin!

Martin
 
Hallo,

ich kann es kaum fassen, es funktioniert!
Ich sehe die Daten 10.000 km weit weg auf dem externen Server in Berlin mit einem lokalen Access Client.
Das ich das noch erleben darf...
Es ist allerdings noch tierisch langsam und läuft auch nur, wenn ich die Firewall auf dem Server ausknipse.
Aber der Durchbruch ist geschafft!
Auch Dank der Hilfe des Forums!

Ih nutze hier in Asien für Internet eine VPN-Verbindung über meine Fritzbox in D, das mag ein Nadelöhr sein.
Bzgl. der Firewall melde ich mich dann noch, falls ich es nicht selbst hin bekomme.

Kruhay!

Martin
 
das weiß ich auch...aber ohne Firewall wäre auch schlecht. Davor lauert das Böse!
Die Welt ist so schlecht...
Ist es auch Wahnsinn, so hat es doch Methode!
 
Du hast einen Server im Internet stehen und drehst erstmal die Firewall ab?

Zum einen solltest du den Port 1433/tcp freigeben und nicht die komplette Firewall abdrehen.
Zum anderen würde ich keine DB frei im Internet erreichbar lassen.
 
Werbung:
Selbstverständlich nicht!, Aber ich hatte es sonst nicht anders hinbekommen und damit den Fehler eingegrenzt, ich kann da jetzt gezielt auf die Suche gehen.
Die Firewall ist jetzt natürlich wieder an! Und bleibt auch an!
 
Zurück
Oben