Active Directory Groups vs. SharePoint Groups for User Management: The Denouement
Last week I did a post about when you might decide to use Active Directory groups versus SharePoint groups. It was less about managing the security, and more about understanding the membership of the groups.
I got a *lot* of comments, emails, tweets, grumbles, and groans about the post. This seems to be a really common question, and while there are some possible answers, they aren’t all straightforward or cheap. Here are a few of the suggestions that I received:
- Run a timer job off hours to expand the Active Directory groups into SharePoint Groups
- Use the Active Directory Web Services – This was appealing, of course, but I found the documentation to be fairly indecipherable, as is the case with too many technical docs, IMHO.
- Use DeliverPoint from LightningTools ($1500 license)
- Write a custom Web Part a la this blog post
- VBScript!
- Other third party possibilities: Quest, EmpowerID, or Bamboo User Management Solution Accelerator
- Read only view of Active Directory Users and Computers (ADUC)
- Added from @usher‘s comment below: Idera, AvePoint or Axceler’s user management capabilities
And the warnings:
- Watch out for performance
- Nested Active Directory groups means that you could get into infinite loops in expanding them (This seems like it would be the developer’s fault for not handling the possibility to me, though.)
- Issues with the information in SharePoint groups and Active Directory groups being out of synch
- and on and on…
So what did we decide to do? We chucked the idea of using Active Directory groups in favor of the ease of use of SharePoint groups. No, we didn’t like this answer, either. I would posit that there needs to be a SIMPLE way to expand an Active Directory group within SharePoint that doesn’t involve custom coding. While there are many third party tools out there that sort of tackle this, they are mostly overkill and in most cases, it’s not even clear if they would do the simple thing we were looking for.
My client may at some later point decide to buy one or more of the third party tools for other reasons, which may give them a solution for this as well. It just didn’t make sense at this juncture.
So the score of the game for this one was SharePoint: 1, client requirements: 0. I feel that it was an unfortunate outcome, but one that we couldn’t improve upon.
p.s. At least I got to use the word denouement in a post about SharePoint. There’s always that.
Reading the effort here I don’t understand the purpse of placing an AD group into a sharepoint group? Why not just assign the AD group the permission, what value is generated by creating a sharepoint group with the same name and adding the AD group into it?
Does Microsoft have a best practice document on AD versus Sharepoint permissions? If not it would seem that they intend Sharepoint to be more of a workgroup installation than an enterprise installtion. Why leave that critical information out of Sharepoint unless it truely still is just Frontpage on steroids. And if that is the case it would seem fundamentally wrong to even install Sharepoint into an enterprise situation. The ROI would be chalk full of unanticiapted costs.
dg:
I certainly can’t defend all of this; you make some valid points. However, the ability to separate or combine SharePoint groups with AD groups is a great basic idea. It lets you have your cake and eat it, too. With a collaboration platform like SharePoint, the permissions model often doesn’t mirror the network security model, which is the way many organizations see AD. SharePoint groups also put management of permissions where it belongs (unless you choose not to allow it): with the people who own the content. At the other end of the spectrum, tightly coupling AD and SharePoint permissions is also possible by linking SharePoint groups to AD groups.
M.