Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Site Group Configuration

  Asked By: Caitlin    Date: Jun 06    Category: Sharepoint    Views: 730

I have a portal site that looks like the below. I want to give a group of user rights to Home, Services, News and Sites which I am able to do fine. I create a site group, and remove its rights on the Office and Department areas

My problem comes in when I want to give another group of users rights to only Office 1 or Department 2 areas but NOT the Home site areas. It seems that if I create a site group, it is created in the home site area and I cannot remove the rights from that (home) area without removing the site group from the entire portal.

Am I crazy or just don't know what I'm doing?

Home site
--->Office-->Office 1, Office 2
-->Department-->Department 1, Department 2
--Services
--News
--Sites

Share: 

 

8 Answers Found

 
Answer #1    Answered By: Adrienne Greene     Answered On: Jun 06

You can use Manage Security for that area/subweb and add the group  to just that area  and remove  it from all others. Doing so will break all of your permission inheritances in the portal  for each area that you do that to. It will also create  a bit of a quagmire for the user  who can only go to level 3, but not level 2 or home. Or you could create WSS sites  for your areas  instead and control permissions and usability easier that way.

 
Answer #2    Answered By: Joshuah Huber     Answered On: Jun 06

My problem  is that when I create  a site  group, the group  is created  for the entire  portal. I don't see anywhere to create a group in an area, I only have New User. The area  that I am looking at is not inheriting permissions from the parent.

So my question now is add the group to just that area and remove  it from all others. At what level is this supposed to be done?

Also, I do have two site wide groups that are allowed to 'see' all areas  of the portal. We are compartmentalizing the permissions for each area tho as each department  and office  will control the content for their area, but are not allowed to add/edit outside of that single spot.

 
Answer #3    Answered By: Gopal Jamakhandi     Answered On: Jun 06

For your requirement, I think it is better to create  the group  directly in Active Directory .
While adding users, you will get new user. Here itself add the group you have created  in Active Directory.
Then this group will be added to that area  only.

 
Answer #4    Answered By: Keenan Whitehead     Answered On: Jun 06

See comments inline below.
My problem  is that when I create  a site  group, the group  is created  for the entire  portal. [Reply] Yes, it will be. I don't see anywhere to create a group in an area, I only have New User. [Reply] You don’t create the group here, you add it. Select New User, and there you can enter in a user  name, or a group name. The area  that I am looking at is not inheriting permissions from the parent. [Reply] After you create the site group in the portal  settings, you can add it to this area, and remove  it from any area that is inheriting permissions from the portal parent. When you create a new site group, all areas  that inherit permissions from the portal parent, will now have that new group in it’s security.

So my question now is add the group to just that area and remove it from all others. At what level is this supposed to be done?[Reply] if after reading above you still have some confusion, let me know and I can further clarify.

Also, I do have two site wide groups that are allowed to 'see' all areas of the portal. We are compartmentalizing the permissions for each area tho as each department  and office  will control the content for their area, but are not allowed to add/edit outside of that single spot.[Reply] Understood. Depending on how many users  you plan on including in these new site groups, it may be easier to directly add the individual users to each area instead of creating site groups. Moving forward as your site expands, using site groups to handle pockets of people for specific areas will become a large maintenance pain. You can also do what Rahul suggested and maintain the groups of people via AD groups. I would do this if you plan to have the same exact group of people edit multiple areas of your portal. If not, and the group of people will only have access to one or two areas, and a different group of people have access for another area, so on and so forth, I would just add the users directly to the area security.

 
Answer #5    Answered By: Damon Garner     Answered On: Jun 06

That is how portal  works but I don't fully understand your situation.

site  group is a collection of rights. Did you mean to say cross site
group, a collection of people (AD users  and groups)?

 
Answer #6    Answered By: Dameon Dejesus     Answered On: Jun 06

The problem  is that we are using groups within groups from Active Directory, and the membership should be dynamic based upon what is going on within AD.

So I have two sitewide groups that can read every area  of the portal  which work fine. Now I need additional groups that do NOT have rights  to the main portal area, just various sub-areas. How do I create  a site  group that does not have rights to the 'root' of the portal?

 
Answer #7    Answered By: Tejaswani Barve     Answered On: Jun 06

Have you considered using a Cross Site Group.

A Site group  is a collection of rights  to which we associate people.
A Cross Site Group is a collection of people (similar to an AD group but
managed at the Site Collection level by SharePoint administrators).

 
Answer #8    Answered By: Harshita Padwal     Answered On: Jun 06

Keep in mind that in an area  (unlike a site) you can add an Active Directory group  and give  it permissions directly without adding it to a site  group. In this manner, you can use your AD group at the area level and not have to add it to the Home area.

If a site group is created  in the Home area, there is no way to remove  the group’s access to Home (and any areas  inheriting from Home) without completely removing  the group. Also, if a group has access because of inheritance, there is no “deny” permissions in SharePoint.

I recommend creating an OU in the AD where SPS admins have been delegated the right to create  groups only. Then they can create AD groups which they now own and can add the appropriate existing users  to their groups.

It is not a security weakness because they do not have the rights  to create users or add them to existing AD groups only the specific ones created for use in SPS. Also keeps the SPS Admins from driving the AD Admins nuts with requests for unique groups.

 
Didn't find what you were looking for? Find more on Site Group Configuration Or get search suggestion and latest updates.




Tagged: