AD Groups / SharePoint Groups Affair

All replies

• 

  

  0

  Sign in to vote

  Hi

  the best solution is to apply AD groups to SHP already existing groups ( or create internal groups as necesarry )

  So

  in your company, you can  organise groups in Ad based on geographical, department, functional and so on.

  For ex you could have city groups , and alos dept groups, and also for a dept, you can have also project group also

  More infos regarding AD, users, and groups: http://technet.microsoft.com/en-us/library/bb727067.aspx

  In SHp , you will use existing SHP groups, or if necesarry you can create and customize permissions 

  More infos How to: http://technet.microsoft.com/en-us/library/cc263239.aspx

  Next you should apply these SHP groups to each list and library level

  If you make a good project about creating these groups and how you will apply permissions to resources on your SHP farm, each changes of user's role, function and duty will can be managed very very easy

  ---

  Romeo Donca, Orange Romania (MCSE, MCTS, CCNA) Please Mark As Answer if my post solves your problem or Vote As Helpful if the post has been helpful for you.

  Thursday, April 26, 2012 9:28 AM
• 

  

  1

  Sign in to vote

  I do appreciate the trickiness of the situation you're in. I always feel that you're specifying permissions in a SharePoint environment that have meaning there, but not necessarily (and usually) outside SharePoint. I wouldn't assume that an AD directory group always has meaning within SharePoint. I found that in large companies this usually isn't so and that the existing AD group structure isn't fine grained enough to port directly to SharePoint (rightly so, because they were designed with different intentions in mind). And certainly, the other way round is even unlikelier: SharePoint groups probably don't have much meaning outside SharePoint. I feel using AD groups instead of SharePoint groups is based on the idea that those can be used interchangeably, I don't think so. Therefore:

  - I prefer to create SharePoint groups for managing permissions in SharePoint. If AD groups can be used to put in these groups: great, if not, that's just too bad. I wouln't try to overload the meaning of an AD group (it has this meaning within our organization, that meaning within SharePoint, and that meaning in system X). I find it's usually more complicated (and fine grained) than that.

  I hope this is answer that has value to you, and I'd love to hear the opinion of others.

  ---

  Kind regards,
  Margriet Bruggeman

  Lois & Clark IT Services
  web site: http://www.loisandclark.eu
  blog: http://www.sharepointdragons.com
  

  
  
  

  • Edited by Margriet Bruggeman Thursday, April 26, 2012 9:33 AM

  Thursday, April 26, 2012 9:31 AM
• 

  

  0

  Sign in to vote

  Thanks Margriet and Romeo for your views on this.

  I forgot to mention that I have created an OU specifically for SP through IT Man request. Now the organisation has two similar AD groups. One for SP and the other for their normal IT stuff. I guess I can now add fine grained groups in AD if this is the best solution.

  For me its the fine grained access that I want to keep simple as possible. So access permissions is as transparent as possible.

  The other thing is about naming of access groups. If a group of people from the same department wants access to folder X, then what should i call this group ? I cant call it group x as the same group may want access to group Y at a later time. Is there a convention for this ?

  Any views on this and the initial question gratefully received ?

  
  
  

  • Edited by orange juice jones Thursday, April 26, 2012 10:02 AM

  Thursday, April 26, 2012 9:52 AM
• 

  

  0

  Sign in to vote

  SharePoint group will be more convenient if you enable SharePoint Directory Management service, which can sync a SharePoint 2010 group with an AD email distribution group:

  A typical directory management scenario proceeds in the following steps:

  1.                     A site collection administrator creates a new SharePoint group.
  2.                     The administrator chooses to create a distribution list to associate with that SharePoint group and assigns an e-mail address to that distribution list.
  3.                     Over time, the administrator adds users to and removes users from this SharePoint group. As users are added to and removed from the group, the SharePoint Directory Management service automatically adds and removes them from the distribution list, which is stored in the Active Directory directory service. Because distribution lists are associated with a particular SharePoint group, this distribution list is available to all members of that SharePoint group.

  from http://technet.microsoft.com/en-us/library/cc288433.aspx

  • Marked as answer by GuYuming Thursday, May 3, 2012 1:55 AM

  Friday, April 27, 2012 8:00 AM
• 

  

  0

  Sign in to vote

  Hi
  Very useful GuYuming

  What would happen if I added/deleted a user to the AD group ? Would it automatically be pushed to the SharePoint Group ?

  Also, as in my previous email, if I wanted to utilise AD for Sharepoint Access only and not Sharepoint groups (no permissions using Sharepoint at all apart form AD groups) is this a workable solution. Has anyone done this ?

  Thanks

  
  
  

  • Edited by orange juice jones Tuesday, May 1, 2012 9:02 AM

  Tuesday, May 1, 2012 9:00 AM
• 

  

  0

  Sign in to vote

  "What would happen if I added/deleted a user to the AD group ? Would it automatically be pushed to the SharePoint Group"

  Sorry, I just don't have the luxury of time to double check it this morning (and confirm the behavior for different service packs and cumulative update http://technet.microsoft.com/en-us/sharepoint/ff800847 ).

  suppose the synchronization is not bi-directional, you may create seperate OU for it so that administrators will not delete user from AD groups in this OU; suppose even seperate OU does not work, you can control it with naming conventions.

  Of cause, you can go without SharePoint group, only AD group. but you will sacrifice the convenience of membership control and process built in SharePoint group. You may find similar process in forefront product line http://www.microsoft.com/en-us/server-cloud/forefront/identity-manager-overview.aspx. But i think a lot of company don't have that infrastructure on hand.

  • Marked as answer by GuYuming Thursday, May 3, 2012 1:55 AM

  Wednesday, May 2, 2012 2:07 AM
• 

  

  0

  Sign in to vote

  I aggree with Romeo. You should convince him to use both groups, Ad groups shelled inside SP Groups is the best way to manage permissions in SharePoint. If you do not use AD you'll end up managing SharePoint when users leave-join-change. If you just use AD it would not make sense because the recommended way is to use Owners-Members-Visitors groups for each site.

  ---

  ceren

  Wednesday, May 2, 2012 8:24 AM
• 

  

  0

  Sign in to vote

  So suggestion is to create AD groups within SharePoint Groups. I will create a SharePoint Group  specifically for every AD Group. The admins can then add / remove users in AD Groups.  

  Apart form the usual Owners-Members-Visitors groups there will be fine grained permissions on individual folders, Though i'm trying to limit this its been found its a requirement (7 groups on some departments). In which case, using the above method I could have a lot more AD and SharePoint groups than originally anticipated.

  Is this the usual and accepted approach ?

  
  
  

  • Edited by orange juice jones Wednesday, May 2, 2012 10:47 AM

  Wednesday, May 2, 2012 10:39 AM
• 

  

  0

  Sign in to vote

  There is no need to create a SP Group for every AD group- this is not right.

  You need to use 'already there' AD groups, within the SharePoint groups you need.

  You'll need Site Owners, site members, site visitors groups for sites with unique permissions. Suppose you want Person a, b, c, d to be Site Owners. If there is already an AD group containing this people, use this group inside Site Owners group. If there is no AD group containing this people create a group in AD. Create a container for SharePoint in AD and create your groups in there.hope this helps!

  ---

  ceren

  • Marked as answer by GuYuming Thursday, May 3, 2012 1:53 AM
  • Unmarked as answer by GuYuming Thursday, May 3, 2012 2:03 AM
  • Marked as answer by GuYuming Thursday, May 3, 2012 2:08 AM

  Wednesday, May 2, 2012 10:42 AM
• 

  

  0

  Sign in to vote

  Hi

  What i understand is, for the Site SP groups ( Site Owners, site members, site visitors groups ) put in an equivalent AD group or create one.

  For other SP fine grained access (specific folders), dont create a SP Group, create a AD group and add this AD group directly to folder.

  Is this correct ?

  
  

  • Edited by orange juice jones Wednesday, May 2, 2012 11:40 AM

  Wednesday, May 2, 2012 11:32 AM
• 

  

  0

  Sign in to vote

  I agree with cerren in "There is no need to create a SP Group for every AD group- this is not right".

  There is just not so much doctrine when you begin to use a tool to make life easlier. Suppose you just begin to use SharePoint and assign permission, you can put the AD people or user you think to be owner into the out of box SharePoint owners group.  There is a description about the SharePoint owner group.

  OK, your information is really confidential and end users are just ruthless. you decide to dive a little bit deeper, you can study the permission levels (or roles, or collections of permissions, sets of permissions to be more mathematical) for the Owner's group. Most probably, you still does not know what the user can actually do now, you can then exam the permissions (what user can do on resource) for the permission level.

  OK, you suddenly find that the out of box SharePoint members group is not the "member" you understand. You can start to create your own SharePoint group now. But i suggest you not to delete the out-of-box one (hide them if they are really annoying). That may be the policy or doctrine you should remember.

  
  
  
  
  
  

  • Edited by GuYuming Thursday, May 3, 2012 3:06 AM

  Thursday, May 3, 2012 2:42 AM
• 

  

  0

  Sign in to vote

  Hi Orange Juice Jones,

  I do not know which is the best one, but I always use AD groups within SharePoint groups for sites.

  If there is a folder  or a document library, it is specific permission so I advise site owners to create SharePoint groups and put people inside this groups. If the sites are being owned by the users, not the IT, this is the best approach I saw so far. What I always do is, I ensure every site is being created with a visitors-members-owners group, with AD groups inside. Then you give site ownership to people. You need to train them to create SP Groups and put people inside this groups for the non-inheriting folder or doc library permissions. I think AD groups could work too, why not. The reason I do not use it is the site owners are not aware of AD groups (they have no access to Active Directory)

  Using AD groups everywhere in SharePoint means It people will be owning the sites and managing the permissions, which is not good to me (but of course it can change from organization to organization)

  I think basically what you need to do is avoid giving individual permissions. If you start to give people permission one by one without using any kind of group (ad or sharepoint) you'll end up lots of names appearing everywhere in permissions, a total mess.

  Also be careful not to use AD Distribution groups in sharePoint, use only security groups. hope this helps!

  ---

  ceren

  
  

  • Edited by ova c Thursday, May 3, 2012 8:18 AM

  Thursday, May 3, 2012 8:17 AM
• 

  

  0

  Sign in to vote

  This has been an interesting discussion, I think, I have promoted it to a Wiki page: http://social.technet.microsoft.com/wiki/contents/articles/10550.sharepoint-2010-best-practices-ad-groups-or-sharepoint-groups.aspx

  

  ---

  Kind regards,
  Margriet Bruggeman

  Lois & Clark IT Services
  web site: http://www.loisandclark.eu
  blog: http://www.sharepointdragons.com
  

  • Marked as answer by GuYuming Tuesday, May 8, 2012 1:53 AM

  Monday, May 7, 2012 8:46 AM