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. Shoul开发者_如何学God I nest more groups?
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
IsInRole
method on the currentWindowsPrincipal
to 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)
精彩评论