Active Directory Groups vs. SharePoint Groups for User Management: A Dilemma
<UPDATE date=”2011-02-22″>
If you find this topic interesting, you might also like to read my follow up post Active Directory Groups vs. SharePoint Groups for User Management: The Denouement
</UPDATE>
I’m working with a small municipality and, like I always do, I recommended that they manage user groups in Active Directory as much as possible. Then they can add those AD groups as “users” to their SharePoint groups and inherit all the AD goodness.
In doing some research on this, I found a nice post by Alexander Brütt that does a good job in painting the differences between the two approaches in a nice little table, which I’m lifting and showing below. Note the bullet that I’ve highlighted; I’ll talk about it more below.
Source: SharePoint Groups vs. Active Directory Groups by Alexander Brütt
But wait a second. It’s not that simple. In thinking about this, I’ve been blessed in the past by IT inability to manage AD effectively. What I mean is that I’ve always recommended that groups from AD be used for things like department membership. However, in EVERY SINGLE CASE that I can remember, the answers were things like “But all of the data in AD is wrong” or “IT won’t let us do that”. So I suggest that the fix the data: “Too hard – we’d rather maintain our own data.” (What??? It’s easier to create your own data than fix what’s basically already there?) Talk to IT about making this work: “Forget it, that’ll never happen.” (What??? That’s your IT department’s service message?)
Listen up, IT folks: making your AD a walled fortress doesn’t serve you at all well. You don’t want people saying things like “those idiots in IT can’t manage data” (someone really said this to me once). Active Directory is supposed to be the one place that manages user identity and demographic data. At least that’s its intent. In most cases, there are 3 or 4 or even a dozen other systems stitched together to manage some aspects of user information instead because AD or its guardians are seen as too hard to work with. As much trouble as the User Profile Service seems to be to work with in SharePoint 2010 (see Spence Harbar’s articles before you even think about setting up UPS), AD is still the best source for user information.
So, the reason for the bit of a rant above is that now that I’m in an environment which is small enough and smart enough that AD is in great shape, we’re trying to use AD groups and there’s one hitch. SharePoint doesn’t give us a way to display the members of an AD group in any straightforward way. (I know, with code all things are possible, but we’re trying to go as out of the box here as possible.) A simple example is that we’d like to display the site members on each departmental site. Basically, it’ll be a department directory of sorts. You can easily do this with a SharePoint group using the Site Users Web Part. However, since SharePoint sees the AD group as a “user”, you just get one “user” listed when you’ve added the Site Users Web Part and asked it to “Show people in this site’s member group”.
I turned to Twitter and #SPHelp on this one and the responses I’ve gotten are more of the “tell me how you do this when you figure it out because we need it, too” variety. I’ve had some suggestions that seem too convoluted to me. This seems like it *should* be such a common thing, but apparently it’s not. Maybe my prior experiences with AD are indeed the norm and no one ever really ends up using AD groups so this rarely.comes up.
So, no answers here to my actual dilemma. I’m wondering if this might be a nice little piece of functionality to wrap up as a jQuery plugin, but I’m not sure how to do it. I’d prefer to avoid deploying code to the server in this instance, but I’m open to it if anyone has anything useful.
I’d appreciate your thoughts in the comments!
Mark,
What about using SharePoint groups and making them distribution groups in AD? I’m not an admin, but I think that that might allow you to manage the memberships in AD or in SP – and might even be able to reuse them in other applications. You could then use ‘group manager’ groups for the sp group management by end user(s).
Marc,
There is really no easy answer to this question — I can understand why the names wouldn’t be enumerated easily as groups can be nested quite deeply in Active Directory (as you mention) and the code to find all of the users in those groups makes use of a lot of recursion.
However, if you automatically expanded all users from an active directory group into a SharePoint group would you be required to manage memberships in two places? It might be possible for a timer job to synchronize those groups, but I imagine there would be a good deal of overhead in performing that operation.
It seems that Active Directory has been a hidden component of the IT world for a long time. I cannot tell you how many times I hear clients express the same phrases you mention in your post, especially the one on how the information is not accurate. Most likely, the reason IT departments wall up AD and place it into a fortress has more to do with perceived security threats. After all, it is the identity service of your organization. The challenge arises when the information is no longer managed. Why organizations do not see this as a valid data store is beyond my comprehension at times. Aside from your HR system, this would be the most authoritative system of record about a user at an organization.
I think that SharePoint should give the IT department a new chance to look at the role of Active Directory in their organization. You clearly outline the overall purpose of AD very well — and this is missed by most organizations.
Now, back to the enumeration of users — I believe the only way to accomplish this would be the introduction of server side code. Since AD is a pretty tight fortress in most organizations, you will most likely need to perform some queries about AD using a privileged account — I’ve had organizations that blocked the ability for users to enumerate groups — and server side code will most likely be the way to accomplish the goal. With that stated, I haven’t managed Active Directory in over 6 years, so I don’t know what changes have been made that could be handled from a client side solution such as jQuery.
Chris:
The nice thing in this situation is that these guys are managing AD well, and the people managing it are the same people managing SharePoint. It’s a three person IT department! So we can do whatever we need to do that makes sense. The goal in this instance is purely display at the moment, not management. From what I understand, that is something like 10 lines of C# packaged up into a Custom Web Part. Maybe that’s a good way to go, though it might be nice to have a client-side option as well.
M.
Here’s a bit of hotness in the latest version of Windows Servers: http://technet.microsoft.com/en-us/library/dd391908(v=ws.10).aspx. It’s not clear whether or not you can query for user info, but AD having it’s own web services, seems like it would be able to.
Cheers,
Matt
Matt:
That’s worth pursuing on my end. The link you posted doesn’t seem to give any information about what the Web Service operations even are, of course!
M.
I appreciate the stance that you take in attempting to stay with OOTB features as much as possible, I try to do the same. For me, the next step is custom web parts that are packaged up nicely as solutions or features. In this case there are 3rd party web parts available to allow you to manage AD users from SharePoint, but I don’t know if they will DISPLAY the AD group members.
I guess I have to add myself to that list of “tell me how…” responders.
It *should* be easier, and that would make it a more common thing.
I think the biggest thing besides the administrative decision is the possible impact on performance. I remember reading an article that MSFT suggests using AD groups as the mechanism, because every time a SharePoint group is edited the search ACLs have to be updated. In large deployment scenarios where that is happening a lot it becomes a bigger problem.
I recently went through a battle royale with the IT department at the place I just left about this exact thing (and that IT department was OUTSOURCED, no less, so we were their customer and I had to fight to get this!). So I totally feel your (and everyone else’s) pain. :-/
Thanks for trying to show them the light! It certainly doesn’t help that in the 2007 MOSS Best Practices book, it says this method of management is NOT a best practice based on a very narrow usage example (IMHO).
Hi,
I know you want to do this out of the box. However, we offer an inexpensive solution to this problem. DeliverPoint will provide Site Owners and Site Collection Owners with the ability to see exactly who has prmissions to their sites, lists, folder, list items etc, the permissions that they have, and also how they were granted the permission. e.g. User -> Domain Group -> SharePoint Group.
I don’t mean to pimp a product here in response, but it is a solution that I would recommend even if it wasn’t my own :)
http://www.lightningtools.com/sharepoint-user-management.aspx
Feel free to remove my response if you don’t want vendors here.
Brett
No worries about the pimping at all, Brett. Your stuff is always highly rated! We’re more interested in simply seeing who’s in an AD group representing the department memebership than management of the data. But I’ll definitely take a look at DeliverPoint.
M.
Have you seen this article: http://sharepointrookie.wordpress.com/2008/07/13/display-site-members-from-ad-groups/ ?
It’s for SP2007, but the principle seems right.
Thanks, Claire. That code does indeed look useful. It’s going into the bucket of possibilities.
M.
I have recently seen a hybrid approach: Portal access is governed by AD, but collaboration sites use SP Groups, controlled by Site Owners.
Because of the bottle-necks with asking IT to make many, many small changes to ad-hoc groups, even in well run and cooperative IT shops, I think it’s much more reasonable to devolve this maintenance headache to the Site Owner. The added benefit is that group membership now works properly.
WDYT of this mix-n-match approach?
Ruven
Well, as you know, Ruven, it depends. ;+) In this situation, IT is well-used to managing the AD data and isn’t concerned about the burden.
I think the hybrid approach tends usually to swing a bit too far toward SharePoint groups simply because no one can get at AD to keep the data up to date and the processes are broken. There’s absolutely no sense, though, in maintaining department groups in SharePoint if the data is good in AD, IMO. Sure, the Site Owners can add or subtract individuals in an ad hoc way to meet specific business needs, by why not take advantage of the good AD data if we can?
So we should be able to have a SharePoint group called “Assessing” which has as its members the domainname\assessing group from AD as well as domainname\BobBuilder and domainname\BettyBoop, if needed. Then we ought to be able to show the superset of the members of domainname\assessing + Bob + Betty in the UI on the Assessing home page. Make sense? It’s not about permissions in the latter case, but membership. I think that the distinction between permissions and membership is important.
M.
I’m with Ruven on this, at least for where I work. AD is pretty up-to-date for departments, but they don’t want to manage all the project groups (ad-hoc, temporary) in AD. So SP Groups come in really handy for that. And we try to put AD groups inside SP groups, too, because we like (in MOSS, anyway) the ability to see where that SP group has permissions. I’ve seen this is much improved in SP 2010, so even better. But in MOSS, SP groups are the way to go for an OOTB way to see what permissions and where the group has them throughout the site collection. We have a smaller number of SCs and therefore a lot of inheritance breaks. I LOVE that I can see permissions at all levels when using SP groups…
But, I can totally see how this would vary wildly depending on the company size, governance, budget, AD management ability, etc.
Marc, I know I did not contribute much to this this morning! Got busy on something. I unfortunately could not locate much except for some vbscript code that was severely outdated! We are in an environment where we actually use AD groups for most of the access and they want to see this as well. I still think there might be a way to do this, but it might take more time than you have!