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.
Don’t forget Idera, Quest, AvePoint or Axceler’s user management capabilities. All solid toolsets to investigate that go well beyond just security management.
Hey Marc, I was one that commented to you that this is an issue I have researched extensively too and I’ve never found anything useful as a solution. From an end/power user perspective using AD groups creates a serious blind spot for checking permissions. My AD guy is fantastic about sending me reports, but they outdate and every permissions issue was sending me to him to verify inclusion in a group. Our solution has been a shared drive acceess file so that I can run the reports myself and verify members. Most of my AD groups are built on job code, so I’m willing to sacrifice the blind spot for the ease in never having to manage permissions on new hires.
It is a pretty serious trade off.
Kerri:
In this instance, our time was short and we needed a quick way to move forward. I really wish I had come up with a better answer, but the fact that there were so many different approaches suggested says that there isn’t really a good one. I’d love to be able to come up with a reliable, low cost solution somehow.
M.
Marc,
My department had this discussion a while back. Our solution is a combination of mail enabled security groups and SharePoint groups. One person in our department managers the memberships of our distribution lists for each team within the department, all of which are MESGs. We also have SP groups for each team that she manages as well. The SP groups have individual members, and they also include the DL for that team. This provides some redundancy if a DL is updated but the SP group is not (or vice versa). She audits the DLs and groups every few months to make sure the individual members are up-to-date. It’s far from the ideal solution of SP simply showing members of AD groups OOTB, but it gets the job done.
An added benefit is that any of the MESG DLs can be entered into a People Picker field in SP.
Josh:
Sounds like we both ended up at a similar sub-optimal solution, though it’s workable. Let me know if you ever improve on it!
M.
Hi,
i already have contact access table and its use also in other table too. its connect to the sharepoint views but now i want to use Active directory for all users. i don’t have any idea about this situation. i dont want to miss my all data too.
shruti
Hi,
I created timer job to add users to a SharePoint Group it is deployed successfully but when it runs it doesn’t add users in the group. I new to SharePoint 2010 dev. Can anyone suggest what to could be the reason.
Thanks
Hi
Marc
A interesting discussion. I am in the process of defining our strategy with regards how we provision users onto AD (OUs and AD Groups) and SharePoint + password reset self-service; using 3rd party tools.
Now, cleanly separating my clients into AD Groups is tempting. As I can add these directly to SharePoint as is, or embedded within a SharePoint Group. Thereafter, when anyone leaves I just delete from AD.
Not sure why I would want to expand these AD groups with a timer job tho unless this was for display purposes.
I guess what really concerns me is any gotchas if think of my SP groups being entirely defined by AD groups:
– Will user alerts work
– Again with task assignment emails
– Any issues with audiencing
-?????
Would be interesting to hear from anyone
We mostly use AD groups that are based on job codes that are then put into SharePoint groups (Owners, members, visitors, etc).
There have been a couple of occasions where we had to use a mail enabled AD group because I wanted to subscribe a group of people to some announcements. Using SP2007, I was unable to subscribe a SharePoint group to the announcements and I didn’t want to manage it several times on the site (announcements, document repository, discussions).
Marc,
I totally agree with your position on prefering AD to a decentralized SharePoint group model in theory but the practicality of dealing with years of AD mismanagment can hinder that possibility. One solution that worked very well at a recent client was that we wrote a slick and simple web-based app for site owners that simply allowed them to modify memberships of the AD groups for which they were delegated access. The SharePoint admins set up the initial AD Group-to-SharePoint object permission levels and then the “user admins” could add/remove people from the AD groups using the web tool. We even put the link to the tool on their sites. In cases where the existing groups were too much of a mess, we started anew with a proper naming convention ,description, and setup delegation groups for the user admins. This way, you’re taking advantage of AD delegation, removing low-value requests to the help desk for updating group memberships, maintaining the overal integrity of the Sharepoint site by not allowing users to medal with sharepoint object security and finally, you can move closer to centralized auditing of security across the enterprise.
The biggest challenge was setting up the web-app such that we could prove it was using AD delegation to the management team and the architects. Once that passed inspection, everyone loved it.
Nick:
Reality so often gets in the way of the right solution, doesn’t it?
M.
We are having a similar issue. Currently our sites are controlled with SP security groups, but the IT manager wants everyone to eventually be AD group controlled.
Our technical IT department has given one site owner AD group management rights so she can view/add/delete users into the security groups – these groups were specified by her and created by the technical team. So she only has to approach them if she wants new/delete groups.
Except, I read with unease today that audience targetting does not work with AD groups, only with SP security groups? Has anyone experienced this?
We would have to place AD user groups inside SP security groups which seems kind of like a double up of work.
Candice:
Hopefully you also read the preceding post to this one. Unfortunately, there simply doesn’t seem to be an answer to this that meets everyone’s needs.
M.