Ich bin mit ODBCs nach System (System-DSNs) und ODBCs nach Benutzer (Benutzer-DNSs) vertraut. Ich möchte ODBCs nach Anwendung haben. Ich möchte die verfügbaren ODBC-Verbindungen auf eine bestimmte Anwendung, GP 2010, beschränken. Ich habe mehrere GP-Anwendungen auf einem Terminalserver installiert (mehrere GP-Verzeichnisse in Programmdateien, die mehrere Dynamics.exe-Anwendungen speichern) und ich habe mehrere ODBCs, mit denen ich von GP 2010 aus eine Verbindung herstellen kann.
Ich möchte eine Regel erzwingen, wonach nur bestimmte GP 2010-Anwendungen (Dynamics.exe) bestimmte ODBCs starten und eine Verbindung zu ihnen herstellen können. Mit anderen Worten möchte ich eine Regel erzwingen, die eine 1:1-Beziehung zwischen Folgendem erstellt:
- eine GP 2010-Anwendung (Dynamics.exe) und
- ein ODBC (eine SQL-Instanz, die GP unterstützt)
Umweltinfo:
- Windows Server 2012 Standard 64-Bit
- SQL 2008 R2 SP2
- GP 2010 SP3
Was ich bisher versucht/gelernt habe:
Ich habe in bestimmten GP-Umgebungen Versuche gesehen, Gruppenrichtlinien zu verwenden, um die für Windows-Benutzer verfügbaren ODBCs durch die Verwendung von Benutzer-DSNs einzuschränken. Ein solcher Ansatz ist jedoch nicht hilfreich, wenn ein Windows-Benutzer legitimen Zugriff auf mehrere GP-Anwendungen hat. Wenn er eine GP-Anwendung startet, kann er jedes für seinen Windows-Benutzer verfügbare ODBC auswählen.
Ich habe mit der Verwendung von GP 2010 experimentiertLogin-Makrosum dieses Problem zu lösen. Diese Methode ist jedoch unsicher und nicht skalierbar. Erstens wird davon ausgegangen, dass Benutzername und Passwort dem Administrator bekannt sind und normalerweise unverändert bleiben. Wenn dies der Fall ist, können die Anmeldeinformationen – zusammen mit dem ODBC – in ein Anmeldemakro eingebettet werden (das irgendwo im Klartext gespeichert ist). Um verwendet zu werden, müssen die Anmeldemakros dennoch an die GP 2010-Verknüpfung übergeben werden, die Benutzer starten. Um einen allgemeinen Zielpfad für jede GP-Anwendung angeben zu können, muss das Anmeldemakro für jeden Benutzer an einem gemeinsamen Ort pro Benutzer gespeichert werden (z. B. auf dem Desktop des Benutzers). Da dies pro Benutzer konfiguriert werden muss, begrenzt dieser Verwaltungsaufwand die Skalierbarkeit.
Antwort1
Ich glaube nicht, dass Sie Ihr Ziel erreichen werden, denn Ihr Vorhaben steht nicht im Einklang mit der Funktionsweise des Windows-Sicherheitsmodells.
ODBC-DSNs werden in der Registrierung gespeichert (entweder HKEY_LOCAL_MACHINE für System-DSNs oder HKEY_CURRENT_USER für Benutzer-DSNs). In der Registrierung können Berechtigungen festgelegt werden, die auf Sicherheitsprinzipale (Benutzer oder Gruppen) verweisen, jedoch nicht auf Anwendungssoftware (da Anwendungssoftware kein Sicherheitsprinzipal ist). Ebenso verfügen die APIs, die zum Zugriff auf die Registrierung verwendet werden, nicht über die Funktion, Berechtigungen basierend auf der Anwendung zu implementieren, die den Zugriff durchführt. Die Sicherheit basiert auf Benutzern und ihrer Gruppenmitgliedschaft, nicht auf der Anwendung, die sie ausführen.
Das Entfernen des Benutzerzugriffs auf ODBC-DSNs hindert die Benutzer nicht wirklich daran, auf die Back-End-Datenbank zuzugreifen, wenn sie Zugriff haben. Sie „verstecken“ den Zugriff nur, indem Sie den DSN verschleiern, sichern aber nichts wirklich. Sicherheit durch Verschleierung ist keine wirkliche Sicherheit.
Ich habe keine Erfahrung mit Great Plains, aber da der Back-End-Speicher auf SQL Server basiert, würde ich denken, dass der richtige Weg TM zur Beschränkung des Benutzerzugriffs auf die Back-End-Datenbank die SQL Server-Sicherheit wäre. Ein Benutzer, der auf die SQL Server-Instanz zugreift, die die Great Plains-Daten hostet, würde, vorausgesetzt, Sie verwenden Windows-Authentifizierung auf dem ODBC DSN, von SQL Server mit seinem Windows-Benutzerkontext „gesehen“. Sie könnten SQL Server-„Anmeldungen“ erstellen, die den Benutzern entsprechen (oder, noch besser, Gruppen, denen die Benutzer angehören) und ihren Zugriff mithilfe der integrierten SQL Server-Funktionalität beschränken. Dies scheint einevielbesserer Ort, um den Benutzerzugriff zu beschränken, insbesondere da die Datenbank selbst den Zugriff erzwingt.
(Ich habe Great Plains noch nie zuvor verwendet und akzeptiere, dass es möglich und sogar wahrscheinlich ist, dass die Software hässliche Dinge wie die native SQL Server-Authentifizierung verwendet. Wenn das der Fall ist, dann haben Sie einfach ein Chaos.)
Antwort2
Nein, aber wenn es so ein großes Problem ist, führen Sie einfach jede Anwendung in ihrer eigenen VM unter Hyper-V aus.