我熟悉按系统 (系统 DSN) 划分的 ODBC 和按用户 (用户 DNS) 划分的 ODBC。我希望按应用程序划分 ODBC。我希望将可用的 ODBC 连接限制到特定应用程序 GP 2010。我在终端服务器上安装了多个 GP 应用程序 (Program Files 中的多个 GP 目录存储了多个 Dynamics.exe 应用程序)，并且我有多个 ODBC 可以从 GP 2010 连接到。
我想强制执行一条规则，即只有特定的 GP 2010 应用程序 (Dynamics.exe) 才能启动并连接到特定的 ODBC。换句话说，我想实施一条规则，在以下各项之间建立 1:1 的关系：
- GP 2010 应用程序 (Dynamics.exe)，以及
- ODBC（支持 GP 的 SQL 实例）
环境信息：
- Windows Server 2012 标准版 64 位
- SQL 2008 R2 SP2
- GP 2010 SP3
到目前为止我已经尝试过/学到的是：
我曾看到有人尝试在某些 GP 环境中使用组策略来通过使用用户 DSN 来限制 Windows 用户可用的 ODBC。但是，当 Windows 用户合法访问多个 GP 应用程序时，这种方法毫无用处。当他们启动 GP 应用程序时，他们可以选择其 Windows 用户可用的任何 ODBC。
我尝试过使用 GP 2010登录宏尝试解决此问题。但是，这种方法不安全且无法扩展。首先，它假设管理员知道用户名和密码，并且通常保持不变。如果是这种情况，则凭据（连同 ODBC）可以嵌入到登录宏中（以纯文本形式存储在某处）。即使如此，为了使用，登录宏必须传递给用户启动的 GP 2010 快捷方式。为了能够为每个 GP 应用程序指定通用目标路径，每个用户的登录宏必须存储在每个用户的公共位置（例如，在其用户的桌面上）。由于这必须按用户配置，因此这种管理开销限制了可扩展性。
答案1
我认为您不会有太多运气获得您想要的东西，因为您尝试做的事情与 Windows 安全模型的工作方式不相符。
ODBC DSN 存储在注册表中（对于系统 DSN，存储在 HKEY_LOCAL_MACHINE 中；对于用户 DSN，存储在 HKEY_CURRENT_USER 中）。可以在注册表中设置引用安全主体（用户或组）的权限，但不能设置引用应用程序软件的权限（因为应用程序软件不是安全主体）。同样，用于访问注册表的 API 不具备根据执行访问的应用程序实现权限的功能。安全性基于用户及其组成员身份，而不是他们正在运行的应用程序。
删除用户对 ODBC DSN 的访问权限实际上并不会阻止用户访问后端数据库（如果他们有访问权限）。您只是通过模糊 DSN 来“隐藏”访问权限，而不是真正保护任何东西。通过模糊实现的安全性并不是真正的安全性。
我没有使用过 Great Plains，但由于它的后端存储似乎是基于 SQL Server 的，我认为限制用户访问后端数据库的正确方法是SQL Server 安全性。假设您在 ODBC DSN 上使用 Windows 身份验证，访问托管 Great Plains 数据的 SQL Server 实例的用户将被 SQL Server 通过其 Windows 用户上下文“看到”。您可以创建与用户（或更好的是，用户所属的组）相对应的 SQL Server“登录名”，并使用内置的 SQL Server 功能限制他们的访问权限。这似乎是很多限制用户访问的更好的地方，特别是因为数据库本身将强制访问。
（之前没有使用过 Great Plains，并且接受该软件可能甚至很可能使用 SQL Server 本机身份验证等丑陋的东西。如果是这样的话，那么您就麻烦了。）
答案2
不是，但是如果这是一个大问题，只需在 Hyper-V 下的自己的虚拟机中运行每个应用程序即可。