是否可以使用Active Directory用户设置Access权限?
修改:总体目标是允许某些用户查看某些表并拒绝其他用户的此权限。我想知道是否可以使用活动目录用户完成。
答案 0 :(得分:5)
取决于访问权限的含义。访问用户级安全性不以任何方式与Active Directory交互。 ACC: Microsoft Access Security FAQ Available in Download Center建议您多次重读此常见问题解答。我必须承认我从未完全理解它。另请参阅ACC2000: Overview of How to Secure a Microsoft Access Database
现在您可以做的是读取登录用户和组等的Active Directory数据。然后使用一些本地表将各种AD组和登录用户ID映射到Access中的各种对象和菜单项,您可以以这种方式控制访问。但是请注意,本地表可能会被精明的用户等等混淆。
我找到的最有用的网址是以下新闻组发布need help on get list of W2K ad Domain (fqdn) by using VB Options我在处理此主题时保留了一页注释,但它们可能有用也可能没用。如果需要,我可以发布它们。
答案 1 :(得分:3)
我同意Tony和Philippe发布的内容。我只想补充一点:
如果你真的需要安全性,那么Jet / ACE后端不会为“安全”这个词的任何重要定义做任务。对于任何拥有基本编程排序的人来说,Jet ULS都是易于破解的。因此,如果您正在寻找形式的数据安全,那么Philippe应该选择不同的数据库引擎。
但是,如果您只想在前端应用程序中控制ACCESS,则有三种选择:
在您的用户数据库中维护几个表以及每个对象的权限。
实现Jet用户级安全性。
使用AD用户/组代替Jet ULS。
这些选择都不是无缝的。
所有这些都意味着你的前端必须被编程来处理问题。
如果出于安全原因限制访问,那么使用与Windows安全性集成的数据库引擎(即SQL Server)是有意义的。
如果您只是为了简化程序流程,并在运行时根据特定用户的需求调整应用程序,那么您不一定需要数据存储的安全性,因为您需要一种方法来保持跟踪谁在使用数据库以及他们属于哪些组,然后跟踪他们应该访问的应用程序的哪些部分(其次,访问级别,读/写,只读等)。
我多年来一直使用Jet ULS作为最后一个目的,但从来没有完全满意它,因为用户可以管理它并不容易。与AD集成将是一个不错的选择,但这意味着管理您的应用程序的任何人都需要拥有管理AD用户的权限。这可能不是您的友好邻居系统管理员愿意同意的事情。
另一方面,如果您最终需要后端安全性和前端访问控制,则无法使用Windows安全性通过AD一站式购买SQL Server后端。
答案 2 :(得分:1)
根据您在Access的最后几天发布的几个问题,我觉得您应该考虑将表(而不是表单)从Access / mdb文件切换到SQLExpress服务器,其中所有这些安全问题都可以易于管理。升级您的数据库,将您的连接字符串作为公共变量添加到您的客户端应用程序中(或者在xml文件,本地表或任何其他可以保存字符串的地方,甚至您的访问文件的额外属性也可以通过currentDb执行此操作) .createProperty方法),并进行真正的客户端 - 服务器配置。