
我熟悉系統 ODBC(系統 DSN)和使用者 ODBC(使用者 DNS)。我想要按應用程式擁有 ODBC。我想限制特定應用程式GP 2010 可用的ODBC 連線。連接的ODBC來自 2010 年大獎賽。
我想強制執行一條規則,只有特定的 GP 2010 應用程式 (Dynamics.exe) 才能啟動並連接到特定的 ODBC。換句話說,我想施加一條規則,在以下各項之間建立 1:1 關係:
- GP 2010 應用程式 (Dynamics.exe),以及
- ODBC(支援 GP 的 SQL 實例)
環境資訊:
- Windows Server 2012 標準版 64 位
- SQL 2008 R2 SP2
- 大獎賽 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 的,因此我認為限制使用者存取後端資料庫的正確方法TM將是 SQL Server 安全性。假設您在 ODBC DSN 上使用 Windows 驗證,則存取託管 Great Plains 資料的 SQL Server 執行個體的使用者將被 SQL Server 及其 Windows 使用者上下文「看到」。您可以建立與使用者(或更好的是,使用者所屬的群組)相對應的 SQL Server“登入名稱”,並使用內建 SQL Server 功能限制他們的存取。這似乎是一個很多限制用戶訪問的更好地方,特別是因為資料庫本身將強制存取。
(以前從未使用過 Great Plains,並且接受該軟體有可能甚至很可能使用 SQL Server 本機身份驗證等醜陋的東西。如果是這樣,那麼您就會一團糟。)
答案2
不需要,但如果有那麼大的問題,只需在 Hyper-V 下在各自的虛擬機器中執行每個應用程式。