Let's say I have 2 AD security groups: "Access to SharePoint" and "Access to Archive".
How do I set the security in this way on a SPWeb that only people who are member of both groups, are allowed access?
Is this possible with out of the box AD tools?
Thanks!
I am making the assumption that you are using SharePoint 2007. With that being said, its best practice to only apply security at the site collection level. Everything under the site collection level should inherit that security [e.g. sites, lists, libraries, items, documents].
EDIT:
*#OedipusPrime brought up a good point that I overlooked in my original answer. The best thing I can think of now to ensure a SharePoint group only allows users that are comprised of two different Active Directory groups would require a custom script that would need to be run on a regular basis (at least daily I would assume).
You'd still create a new Active Directory group, but you'd populate the group with a C# console application that would query Active Directory and determine which users were in both Active Directory groups ("Access to SharePoint" & "Access to Archive"), then programmaticlly assign those users into the new Active Directory group ("Restricted Site Access") and remove any users that were no longer in both groups. Not the best option, but the best I can think of for now if you're not able to manually control the Active Directory group access. This link provides some useful samples for C# / Active Directory interactions: http://www.codeproject.com/KB/system/everythingInAD.aspx*
After this new Active Directory group is created you can add the group to your SharePoint site and provide the permission level the group will have to the site.
Site Actions -> Site Settings -> Advanced Permissions -> New -> Add Users
Type in the Active Directory group you created
Select Give users permission directly
Choose the permission level
Uncheck the box to send an email
Click OK
Related
Context:
I have recently been given the role as Azure Devops administrator in the small company I work in. I have no previous experience with this role, and I am currently reading through the extensive documentation on the topic.
What I've got:
An azure organization with several users, groups, permissions, and projects, some of which are up to 6-7 years old. Responsibility for the organization has been passed along several times without any clear plan or consequence, and I am attempting to get an overview and clean up the structure.
What I want to do:
I want to grant all users in the entire organization permission to read, comment on, tag people, and create new work items in Boards (especially backlog and sprint) in all projects, including the ones they are not a team member or user of themselves. I have tried several permission group setups, but I can't get anything to work. Suggestions are welcome.
Sorry but I'm afraid we don't support this feature.
We can't do this if the user is not a member of the project. (Unless he's a PCA, but it's not recommended to grant users as a PCA cause it'll make much risk).
So you need to add all users to projects first to give their permisions to boards. Here are detailed steps.
Create a new group Group1 in Organization Settings -> Security/Permissions. Add all users in the organization to this group.
Go to Project Settings -> General/Permissions and create a new group Group2. Set the Group1 as members of Group2.
Go to Project Settings -> Boards/Project configuration -> Areas. Choose the ... context menu for the node you want to manage and select Security.
Search Group2 and set 'Edit work items in this node' to Allow. Note that some important permissions should be set to Deny.
This solution needs you to add groups and set permissions in projects one by one.
I have created two groups in SharePoint Online
The following groups are:
Finance Group
HR Group
Added two users under Finance Group, they are like following:
a. John
b. Joe
Also added two users under HR Group, they are like following:
a. Margaret
b. Janet
Admin has created created a folder called Photos, I want the folder to be disabled for a Group/user(i.e the photos folder should not shown for a Group I chose (e.g Finance Group) or for a User (e.g John))
Is there a way in SharePoint Online to restrict read access for a User/Group?
Your best way to do this would be to use target audiences for your subfolder.
Within your library settings, go to audience targeting settings and enable audience targeting.
Navigate to your subfolder, open the subfolder, and edit the page, it will then appear similarly to a webpart.
Within the edit webpart dialog on the right, navigate to advanced and the last field is audience targeting.
You may need to make a new permissions group if using a group of people or simply select an individual person.
That's it.
We want some users of one of our SharePoint site to manage permissions on their site but do not want them to give the permission called "Manage Permissions". Because if we do so, the users start assigning the built in permission level “Full Control” to themselves. How can we achieve this?
Please note that the users with the permission level "Manage Permissions" can create and change permission levels on the Web site [Ref: Microsoft]. What we want for them to only be able to create users, groups, and assign certain permissions on the site to those users and groups.
"we want for them ... and assign permissions"
you DO realize that they can just as easily be assigning Full Control to these groups? isn't that what you say you want to AVOID?
manage the permissions for them, and allow them to self manage the GROUP MEMBERS. that way they can add people to the "publishers" group... and net result is that the user has "publish" permissions.
solution 2 can be extrapolated for some very granular needs, but I don't explain how because I wouldn't recommend it.
We've started to adopt SharePoint 2010, and are starting to manually migrate content from SharePoint 2007 sites to new sites we're rebuilding from scratch in SP2010.
One of the things we previously had supported was to delegate responsibility for managing some of our site columns to a member of the team. The team member is not familiar with SharePoint internals, and doesn't want the responsibility of full permissions to the site and all its objects.
We're now trying to figure out what the minimum permission is that we need to grant our team member, so they can continue to edit (& propagate) the content of the site columns we've defined.
Permissions he currently has (which are obviously insufficient):
Site permissions (according to _layouts/user.aspx): Read, Contribute, Manage Lists
Permissions for specific objects in the site (according to _layouts/people.aspxMembershipGroupId=xxx, then choosing Settings, View Group Permissions):
server/sites/[sitename]: Contribute
server/sites/[sitename]/Lists/[a list with columns that inherit from site columns]: "Contribute No Delete"
Note: the "Contribute No Delete" permission is a custom permission I designed by copying the SharePoint-native "Contribute" permission set and deselecting the Delete permission. The "Manage Lists" permission is a custom permission I designed that includes the following specific permissions: (List Permissions) Manage Lists, View Items; (Site Permissions) View Pages, Open.
Operations that are throwing access denied errors:
_layouts/mngfield.aspx: SharePoint returns the "Error: Access Denied" dialog, and provides three clickable options: "Sign in as a different user", "Request access", and "Go back to site"
_layouts/fldedit.aspx?field=Level%5Fx0020%5F3 [one of the site columns we've defined]: can load the page and type in changes to the textboxes "...but when I press OK (save changes) I get the same message above."
When our team member clicks the "Request access" link, the email I receive sends me to a page that recommends that I grant the user membership in the "[sitename] Users" group - of which he's already a member. So while SP2010 tries to request access, it doesn't actually direct me to either (a) a valid group that has the correct permissions or (b) the specific object to which I need to grant our team member access.
Also note: on the SP2007 (MOSS) site (where our team member was successful in managing Site Column edits), they had dozens of additional permissions throughout the site that we do not wish to blindly re-allocate in SP2010 until we know they're necessary.
Any help anyone can provide would be greatly appreciated.
There are two sets of permissions: one set of permissions that are set at the Site level, and another set of permissions that must be assigned on every List where the Site Column is being inherited (i.e. where it's been implemented as a List column):
Site-level Permissions
Manage Lists (labelled “List Permissions”)
View Items (labelled “List Permissions”)
Add and Customize Pages (labelled “Site Permissions”)
Browse Directories (labelled “Site Permissions”)
View Pages (labelled “Site Permissions”)
Open (labelled “Site Permissions”)
List-level Permissions
Manage Lists (individual permission – which includes View Items, View Pages and Open)
Contribute (permission set)
For details and the methodology on how I arrived at these permissions, you're welcome to rad the whole gory story here: http://paranoidmike.blogspot.com/2010/10/found-minimum-permissions-to-edit-site.html
My team implemented a UI to assign/revoke permission levels to users on a certain SharePoint list. The UI supplies an "undo" feature to restore the rights the user had before they were changed through our UI.
Now there is a problem if the user had the "Limited Access" permission level: This permission level is removed when you do a change over the UI. When trying to Undo, the permission level should be added again, which leads to a
You cannot grant a user the limited access permission level.
SharePoint grants that permission level automatically when a user gets access to some entity beneath the site. It cannot be granted manually. This permission level is then inherited by all lists in the site. However, after breaking inheritance on a list, I can revoke the right manually, only, I cannot re-grant it afterwards.
So SharePoint treats that permission level quite particularly and I'm wondering how to work around that in our undo feature.
My questions:
Did I get it right that this "limited access" is granted by SharePoint on the site level only, and all the lists beneath only contain that accidentally through inheritance?
Does that permission level have any effect at all on a list, or does it only apply to the site itself?
So, would it be save to just remove it from a list and do not add it anymore when the user clicks "undo", since it has no effect anyway?
I dare to answer my own question just for reference for future readers:
According to Microsoft's article Permission levels and permissions,
The Limited Access permission level
cannot be customized or deleted.
and
(...) Windows SharePoint Services 3.0
automatically assigns this permission
level to users and SharePoint groups
when you grant them access to an
object on your site that requires that
they have access to a higher level
object on which they do not have
permissions. For example, if you grant
users access to an item in a list and
they do not have access to the list
itself, Windows SharePoint Services
3.0 automatically grants them Limited Access on the list, and also the site,
if needed.
In practice this means that:
If you can delete it, that's only because it has been inherited and has no meaning on that certain list.
If later on a user is granted some permissions to a certain list item, so that he needs the Limited Access on the list, SharePoint will take care of adding it again.
Summarized: No concerns to remove and not re-add that access level.
Removing a user with Limited access on the top level site should not actually remove their explicit access on the list or library below (with broken permissions) but MS do say in the above mentioned article:
However, to access a list or library, for example, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted.
This suggests that the user's Limited access should be declared on the site permissions. I think its always best to do a test on your site first before making any assumptions.