Question

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?

Answer 1

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 current WindowsPrincipal 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)