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!
So this is in the classic world… toss all out the window if you’re considering claims auth. :)
Very timely- this is a hot button issue for us right now too. Add to the mix IT factions not willing to play nicely, and you get even more pepper in the pot.
Bottom line- Leveraging an existing store of data (regardless of where it is), vs building and maintaining a new, “separate-but-equal” store is just the right way to do things. The time and effort should be spent on the existing store, since it’s not going anyywhere and it’s, oh, integral to just about every other company system. To tell the SharePoint team, “No, sorry, YOU have to build a side list until we can get around to fixing all these outdated job titles and phone numbers” is a crock.
That people who HAVE managed to get this right still can’t deliver what they need without jumping through (possibly costly) hoops is sort of depressing, though.
Marc,
I go through this pain on a regular basis. The “walled off” nature of AD implementations usually makes AD groups a no-go for my clients when I’m trying to sell what is ultimatley a rapid collaboration environment for cross departmental teams to work together. AD usually requires change management of some sort and in the organisation I currently work for, CR’s such of these carry a 7 day lead time. As such I find clients tend to want the quick win of being able to spin up a site, add the users they need and collaborate.
Saying that, I’m coming off the back of one project whereby we have had a really good relationship with the keepers of AD. In this instance they acknowledged that AD was in a poor state and we worked with them to improve it. I intend to blog about it at some point but essentially we used the UPS to cleanse the AD data and push it back bringing wins all across the board (but I digress)
For your specific need I would say a timer job would be the only real way of doing this, processing the group membership out of process over night and allowing for any resursive group membershihps. The data may be a little out of date when the user consumes it but at least it will be responsive.
Hope you find a solution.
Terry
We have successfully utilized AD for all MOSS 2007 access. The main reasons were
1. When upgrading from SP 2003 to 2007 the security groups did not port over properly, know issue. The AD groups should always be ok.
2. IT helpdesk does not have security access to MOSS; they do have the ability to update AD groups.
3. We have some SOX data in MOSS and must segregate security control from the user community for compliance reasons.
How we did it
• Only IT (MOSS Admins) edits security configurations on low security sites assigned department users can edit group members.
• Create AD security/distribution groups with descriptive names (site/sub-site/library/access level) that all start with SP.
• Create MOSS groups to match except the SP and insert the AD group.
• Change the design right to include the ability to view security configuration but not edit. Design is the highest level the users get there are 2 to 3 designers per work group or site.
• Now the work group site designers can view the security config but not edit.
• The designers request security reconfiguration as needed for new/changed sites or libraries
• High security sites; the designers request AD group changes through the helpdesk. in the format add user1 to AD groupA because they can view the configuration. The helpdesk can confirm the requestor is a designer by looking at the members of the site designers group in AD or Outlook because they are also distribution groups. The helpdesk retains the emails for SOX audit.
• Low security sites; In AD any user can be granted the right to edit the members of specific distribution groups via Outlook again because they are also distribution groups.
• Any user can view the member of all the AD groups in Outlook and they are easy to find because they all start with SP.
• Produce a training document and train the designers & assigned department users
• Configure MOSS to send those access requests directly to the site designers via the distribution group
The user can now use the distribution groups to contact the designers and all other members of the site via email.
We have AD in good shape and most group changes are completed the same day. Security reconfigurations can take 5 days as per IT SLAs
I’m not seeing this as a positive point “Can contain SharePoint Users that do not exist in Active Directory” (Not talking about Federation/claims accounts)
Does this not create a massive administrative nigthmare? If person A leaves the company a workflow will started by HR to disable all his/her access. If all accounts are centralized in AD you can have IT do it. If you use non-AD accounts who whil do the clean-up? Who will check security policies? Who will guard naming conventiosn,…..etc…
The idea of Active Directory is/was to manage all accounts centrally.
Bart:
I’m sure that if you have a well-maaged and accessible AD, then the separation seems like a bad idea. One of the point is that rarely is that the case. IT departments typically make user management such a mess of a process that it just plain doesn’t work. (I’m an IT guy from way back, so this isn’t a “they” slam.)
I think at the root of it, SharePoint allows for self-administration, which all in all is a good thing.
M.
Thanks, Marc. As always, you cover topics relevant to SP admin and developers. As a noob, this site always helps.
Our company policies require me to use AD groups to manage permissions, and I’m having the same problem as everyone else with displaying group membership. I’ve found several decent solutions that I’d like to share though, in case they help others:
1) Use Outlook directory
Make the AD groups e-mail enabled (so they’re mail distribution groups as well as security groups), and include them in the company directory. Then folks can look them up in outlook (as mentioned in a previous post), and expand the group to see membership. You’ll need the AD groups e-mail enabled anyway if you’re going to use them to send alerts from SharePoint.
Pros: easy to set up, no extra coding, everyone already has outlook.
Cons: site owners have to go someplace other than SharePoint to see membership. “Clutters up” your company email directory with a bunch of sharepoint groups. We’re not using it for exactly that reason – we’ve got a lot of groups.
2) Make the AD group a SharePoint Data Source
This makes use of the fact that AD can be queried as a “linked server” from SQL Server. You set up a view on the SQL server for your group, then use it as a regular data source in sharepoint designer. Complete instructions for this are here
Pros: Displays everything nicely in one place, using the standard SharePoint Data View
Cons: Kind of fiddly to set up, since there are so many pieces (SQL Server, Linked Server to AD, sql view, SharePoint Data Source, SharePoint Data View, page to display it on)
3) Write VB code to query AD directly
Just write the vbscript code (using an ADODB.Connection) to connect to AD and display the data you want. Instructions (including querying a multi-value field to get group members) are here. Note: to use this on a webpage, use response.write instead of WScript.echo for output.
I just dropped the code (with a little more pretty formatting) on a asp vbscript page and viola…group members displayed.
Pros:Simple, easy solution
Cons:SharePoint doesn’t allow server-side code blocks in user-created pages by default. So you either need to host your .asp page on another web server and just link from sharepoint, or change the sharepoint web.config to allow server-side code…which probably isn’t a great idea from a security perspective
Hi,
i am working on ipad application,its transferring data from ipad device to sharepoint list.
my question is:
How to sharepoint list reconize Active Directory Users Name as Responsible party?
Thanks
Shruti
I would imagine that allowing a SharePoint group to contain another SharePoint group as member would not be a technically difficult enhancement for MS? This would help in some scenarios?
Stanley Teo:
Whatever the reason, that’s how it works, and it’s been the case since SharePoint 2003, at least. I think the reason is that AD groups give a very strong infrastructure for group management and SharePoint (at least historically) slaves to AD.
M.