我的公司相當廣泛地使用 Access + MySQL 應用程序，如果我發布原始程式碼，該應用程式可能會在 Daily WTF 上看到一些顯著的流量。使用者及其權限的管理正在失控，我似乎花了越來越多的時間來調整這些或試圖找出為什麼有人看不到他們應該看到的內容。
它最初被設定為供一個倉庫中的三個使用者使用。現在，它已被四個州的20 多個用戶使用，並且很快就會添加更多用戶，並且添加的功能與用戶的比例大致為10 比1...實際的核心應用程式還不錯，但管理使用者是一種痛苦。 Access 為資料本身提供了一個很好的前端，資料儲存在我們總部的 MySQL 後端上。用戶在衛星分支機構擁有 Cisco VPN 盒子，這也很可靠。範圍已從簡單的倉庫運輸記錄擴展到成熟的 CRM/ERP ...好吧，我不認為您可以將其稱為解決方案。也許是乳液。如果我有預算，我會打電話給 SAP 並告訴他們要這樣做。恐怕在可預見的將來這是不可能的。
按照Google 的指示（並不總是最安全的做法），我使用Access 中的「用戶級安全嚮導」為各個用戶分配用戶名和密碼，當我一開始總共有4-5 個用戶和3 個活躍用戶時，這很好。但現在已經很不方便了。我最深切的願望和願望是有某種方法可以根據 Active Directory 使用者名稱和密碼對使用者進行身份驗證並指派權限角色。我聽說這是不可能的。一些谷歌搜尋沒有發現任何值得注意的事情。
我推測應該可以使用 Active Directory 來獲得某種身份驗證框架，因為 VBA 具有到 Windows 中各種 API 的連結。然而……值得花時間和麻煩嗎？有沒有人曾經讓它工作過，或者我是否不僅會毀掉我那該死的應用程序，還會毀掉域名？
答案1
我知道這是可能的，但似乎很少有 Access 開發人員這樣做。如果其他人編寫了程式碼，我會自己使用它，但不需要它來自己寫它。
關鍵概念是您可以使用 ADO 透過 LDAP 查詢存取 AD 資訊。沒有辦法用它來強制存取物件的權限，但您當然可以根據 AD 成員身份控制應用程式流程/表示。看這個線程為起點。另外，還有微軟知識庫關於此的文章解釋了 LDAP 方法。
順便說一句，只要您不需要 AD 特定的功能（例如組織單位），您就根本不需要使用 AD。您可以使用常規 API 呼叫來取得群組成員資訊。看這個 Stackoverflow 帖子對於一些建議前進方向的程式碼（我無法驗證該程式碼，因為它看起來相當省略，即不是 API 聲明，但它給出了基本概念）。
答案2
無法在該層級直接與 AD 互動。您可以直接執行的最佳操作是根據 AD 帳戶指派檔案權限。透過 VBA 來完成它需要一些努力，但肯定不會超出理解範圍。我想說，在解決這個問題之前，你應該對其進行非常可靠的投資報酬率分析。