我熟悉系统（系统DSN）的ODBC和用户（用户DNS）的ODBC。 我想通过应用程序获得ODBC。 我想限制一个特定的应用程序，GP 2010可用的ODBC连接。我有一个terminal服务器上安装了多个GP应用程序（Program Files中存储多个Dynamics.exe应用程序的多个GP目录），我有多个ODBC连接到从GP 2010。
我想执行一个规则，只有特定的GP 2010应用程序（Dynamics.exe）可以启动并连接到特定的ODBC。 换句话说，我想强加一个规则，在以下之间build立1：1的关系：
环境信息：
我到目前为止所尝试/了解到的：
我曾经在某些GP环境中看到尝试使用组策略来限制Windows用户通过使用用户DSN可用的ODBC。 但是，在Windows用户合法访问多个GP应用程序的情况下，这种方法是无用的。 当他们启动一个GP应用程序时，他们可以select任何可供其Windows用户使用的ODBC。
我已经尝试过使用GP 2010 loginmacros来尝试解决这个问题。 但是，这种方法是不安全的，不能缩放。 首先，假定pipe理员知道用户名和密码，并且通常保持不变。 如果是这种情况，证书和ODBC一起可以embedded到一个loginmacros中（它以某种forms存储在纯文本中）。 即使如此，为了使用，loginmacros必须传递给用户启动的GP 2010快捷方式。 为了能够为每个GP应用程序指定一个通用的目标path，每个用户的loginmacros必须存储在每个用户共同的位置（例如在用户的桌面上）。 由于这必须针对每个用户进行configuration，因此这种pipe理开销限制了可伸缩性。
我不认为你会得到你想要的东西，因为你试图做的事情不会与Windows安全模型的工作方式有关。
ODBC DSNs存储在registry（HKEY_LOCAL_MACHINE，系统DSN或HKEY_CURRENT_USER，用户DSNs）。 可以在引用安全主体（用户或组）的registry上设置权限，但不能在参考应用程序软件（因为应用程序软件不是安全主体）上设置权限。 同样，用于访问registry的API不具有基于执行访问的应用程序来实现权限的function。 安全性基于用户和他们的组成员，而不是他们正在运行的应用程序。
删除用户对ODBC DSN的访问实际上不会阻止用户访问后端数据库。 你只是通过模糊DSN来“隐藏”访问，而不是实际上确保任何东西。 默默无闻的安全并不是真正的安全。
我没有Great Plains的经验，但由于后端存储似乎是基于SQL Server的，所以我认为限制用户访问后端数据库的正确方法是SQL Server安全性。 假设您在ODBC DSN上使用Windows身份validation，访问承载Great Plains数据的SQL Server实例的用户将被其SQL用户上下文“看到”。 您可以创build与用户对应的SQL Server“login”（或更好的用户所属的组），并使用内置的SQL Serverfunction来限制其访问。 这似乎是一个更好的地方限制用户访问，特别是因为数据库本身将强制访问。
（之前没有使用过Great Plains，并且认为软件使用了像SQL Server本地authentication这样的丑陋的东西是可能的，甚至有可能，如果是这样的话，那你就是一团糟。
不，但如果这是一个大问题，只需在Hyper-V下的各自虚拟机上运行每个应用程序即可。