在 .Net 中使用 Active Directory 进行授权
除了使用 System.DirectoryServices.AccountManagement 执行基本 AD 功能的简单代码示例之外，是否有通用指南或者有人可以发布自己的关于将 .net 与应用程序集成的指南？我有一个独立的项目数据库。
可以将项目分配给用户。我应该将 UserPrincipleName、专有名称、GUID 或 SID 存储在数据库中吗？
项目的某些部分仅限于特定部门的员工。我是否为每个部门创建一个简单的AD组？我应该支持某种本地缓存还是多个 IsMemberOf 调用？
我应该如何处理更细粒度的权限，例如 CanDoSomething。我应该嵌套更多组吗？
Beyond the simple code samples for doing basic AD functions using System.DirectoryServices.AccountManagement, are there general guidelines or could somebody post their own on integrating .net with an application? I have a standalone database of projects.
Projects can be assigned to a user. Should I store the UserPrincipleName, the Distinguished name, the GUID, or the SID in the database?
Parts of a project are restricted to employees in a particular department. Do I create a simple AD group for each department? Should I favor some sort of local caching or multiple IsMemberOf calls?
How should I handle more granular permissions like CanDoSomething. Should I nest more groups?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的应用程序和使用它的用户都在同一 LAN 上，我绝对建议使用直接 Windows 身份验证。
也就是说：
对于应用程序中的每组用户（普通用户、演示用户、管理员），创建一个 Windows/AD 安全组 - 这些组可以由任何 Windows/AD 管理员管理和处理（无需特殊工具/UI） /
在你的代码中，使用当前
WindowsPrincipal上的IsInRole方法要确定当前用户是否处于更细粒度的权限：这完全取决于您；有一些“开箱即用”的解决方案，例如 AzMan，但似乎没有一个真正被广泛使用 - 我们大多使用某种两层或三层方法（用户 - 配置文件 - 权限）来“推出我们自己的”解决方案在数据库中进行管理，并在我们的应用程序中进行管理
AD 对象的名称可能会更改 - 所以我不会将其用作我独特且稳定的参考。 GUID 或 SID 都是固定的并且不会更改 - GUID 更是如此（SID 在某些情况下可以合并，因此可能会更改 - 对于组而言更多，但仍然有可能）
If your application and the users using it are all on the same LAN, I would definitely recommend using direct Windows Auth.
That is:
for each group of users in your app (regular users, demo users, admins), create a Windows / AD Security groups - those can be administered and handled by any Windows/AD admin (no special tools / UI stuff needed)
in your code, use the
IsInRolemethod on the currentWindowsPrincipalto figure out if that current user is in a particular role (or not)more granular permissions: that's entirely up to you; there are some "out of the box" solutions like AzMan, but none really seem to be used a lot - we mostly "roll our own" with some kind of a two- or three-layer approach (user - profile - permission) that is managed in the database and adminsitered within our apps
The name of an AD object could change - so I would not use that as my unique and stable reference. The GUID or the SID are both fixed and don't change - the GUID even more so (SID's can be merged under certain circumstances and thus might change - more for groups, but it's still possible)