16

In my Sharepoint code I display a list of all defined users via:

foreach (SPUser user in SPContext.Current.Web.AllUsers)
{
    ...
}

The great part is, I can add a domain security group to a Sharepoint group (like Visitors) thus adding many users at once (simpler administration). But my code doesn't see those users at least not until they log-in for the first time (if they have sufficient rights). In this case I can only see the domain security group SPUser object instance with its IsDomainGroup set to true.

Is it possible to get domain group members by means of Sharepoint without resorting to Active Directory querying (which is something I would rather avoid because you probably need sufficient rights to do such operations = more administration: Sharepoint rights + AD rights).

ekad
  • 14,436
  • 26
  • 44
  • 46
Robert Koritnik
  • 103,639
  • 52
  • 277
  • 404

2 Answers2

33

You can use the method SPUtility.GetPrincipalsInGroup (MSDN).

All parameters are self-explaining except string input, which is the NT account name of the security group:

bool reachedMaxCount;
SPWeb web = SPContext.Current.Web;
int limit = 100;
string group = "Domain\\SecurityGroup";
SPPrincipalInfo[] users = SPUtility.GetPrincipalsInGroup(web, group, limit, out reachedMaxCount);

Please note that this method does not resolve nested security groups. Further the executing user is required to have browse user info permission (SPBasePermissions.BrowseUserInfo) on the current web.

Update:

private void ResolveGroup(SPWeb w, string name, List<string> users)
{
    foreach (SPPrincipalInfo i in SPUtility.GetPrincipalsInGroup(w, name, 100, out b))
    {
        if (i.PrincipalType == SPPrincipalType.SecurityGroup)
        {
          ResolveGroup(w, i.LoginName, users);
        }
        else
        {
          users.Add(i.LoginName);
        }
    }
}

List<string> users = new List<string>();
foreach (SPUser user in SPContext.Current.Web.AllUsers)
{
  if (user.IsDomainGroup)
    {
      ResolveGroup(SPContext.Current.Web, user.LoginName, users);
    }
    else
    {
      users.Add(user.LoginName);
    }
}

Edit:

[...] resorting to Active Directory querying (which is something I would rather avoid because you probably need sufficient rights to do such operations [...]

That's true, of course, but SharePoint has to lookup the AD as well. That's why a application pool service account is required to have read access to the AD. In other words, you should be safe executing queries against the AD if you run your code reverted to the process account.

eXavier
  • 4,821
  • 4
  • 35
  • 57
Stefan
  • 14,530
  • 4
  • 55
  • 62
  • 1
    Ok. but does it flat out nested groups? Because inner members are also principals. – Robert Koritnik May 27 '11 at 14:54
  • No, nested groups won't be resolved. If performance is not relevant, recursive calls to this method should not be such a big deal. Nested groups will be returned as principal infos as well. – Stefan May 27 '11 at 15:04
  • Ok so if I enumerate `SPContext.Current.Web.AllUsers` and get to domain groups I can use that name to use with `GetPrincipalsInGroup`? I haven't tested so I'm just asking an additional Q. – Robert Koritnik May 27 '11 at 15:13
  • 1
    Yes, use `SPUser.LoginName` for the `input` parameter. – Stefan May 27 '11 at 15:21
  • 1
    If think there is an error in your code exmaple. Line "if (i.Type == SPPrincipalType.SecurityGroup)". It should be "i.PrincipalType" and not "i.Type" (at least in SharePoint 2010). – Patric Feb 21 '13 at 14:01
  • thank you .it also works for simple sharepoint group which i was looking for – Iman Apr 30 '14 at 09:43
  • This answer worked gloriously for me until I deployed to an environment using Claims Authentication. It seems others have had problems with querying AD from SharePoint that's using Claims Auth, too: https://sharepoint.stackexchange.com/questions/13223/sputility-getprincipalsingroup-and-claims-authentication-issue – lance Nov 05 '15 at 16:00
6

I would suggest you just query Active Directory directly. You are spending a lot of effort to try to get SharePoint to make this call to AD for you. Every account that has Domain User access should be able to query the AD groups you have nested in SharePoint. I would just go to the source.

This way you don't have to worry about Browse User Permissions or anything else. In my opinion trying to proxy this through SharePoint is just making your life more difficult.

Mizzle-Mo
  • 598
  • 2
  • 5
  • 11
  • 4
    Care to add some c# code how to do it? I know I can find it on the net but supporting your answer with some code would be better. – Robert Koritnik May 29 '11 at 05:00
  • 1
    Sorry, I am still new here. Looks like you could easily modify this to implement a robust solution to your issue. [link](http://www.codeproject.com/KB/sharepoint/Sharepoint__User.aspx) – Mizzle-Mo May 31 '11 at 01:31