![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ibnekoWeb Application > Site > List/Library > Document/Item
Adding a user in Central Administration > Application Management > Policy for Web Application will OVERRIDE any independent settings within that Web Application. Once revoked, their permissions goes back to what it was before they were added. (That is, if they existed at that site previously.)
A subsite to a site may use separate permissions if on creation of that subsite, you select "Use unique permissions". Or you choose to "Edit Permissions" from the 'Site Settings' > Permissions page, under the "Actions" menu. You can revert back to using the parent site's permissions by choosing "Inherit Permissions".
As long as an object (be it subsite, list/library, or document/item) is set to "Inherit Permissions", it will inherit permissions from the parent object. If "Inherit Permissions" is turned off in a child object, and a permission is granted in the parent object, that permission will not get passed down to the child object. Inherit permissions can be turned back on for all objects except in the original/root site collection.
Group management is important: If a user is in a group, they do not need to be explicitly given permissions for any object that grants that group permissions. Groups can be given specific permissions in relationship to specific objects, as well as a default set of permissions. (ie, normal read permissions site-wide, but write permissions for a certain library)
Also, the "Site Permissions" is the equivalent of a group that all offspring objects inherit, if they use "Inherit Permissions".
You can add more permissions (ie, write, delete) and override the group or site permissions by modifying an object's permissions directly and adding the user. However, there is no way to subtract permissions from a user that's in a group (and the group has been granted permissions to an object). (think colored glass - by adding different sheets of glass, you can change the colors and make things darker, but you can't add a sheet to remove a previously added color.)
There is one exception:
Permissions set on the Web Application are more powerful: one can use the "Manage Permission Policy" (from Policy for Web Application) to create specific policy levels - where specific permissions can be denied. Denying permissions prevents users from ever having that permission.
[edit 6/14 1PM] some clarification changes in the second to last paragraph. Also...
**DISCLAIMER** This information is not reliable. It's built from my trial and error, toying with SharePoint experience, as notes to myself.
Adding a user in Central Administration > Application Management > Policy for Web Application will OVERRIDE any independent settings within that Web Application. Once revoked, their permissions goes back to what it was before they were added. (That is, if they existed at that site previously.)
A subsite to a site may use separate permissions if on creation of that subsite, you select "Use unique permissions". Or you choose to "Edit Permissions" from the 'Site Settings' > Permissions page, under the "Actions" menu. You can revert back to using the parent site's permissions by choosing "Inherit Permissions".
As long as an object (be it subsite, list/library, or document/item) is set to "Inherit Permissions", it will inherit permissions from the parent object. If "Inherit Permissions" is turned off in a child object, and a permission is granted in the parent object, that permission will not get passed down to the child object. Inherit permissions can be turned back on for all objects except in the original/root site collection.
Group management is important: If a user is in a group, they do not need to be explicitly given permissions for any object that grants that group permissions. Groups can be given specific permissions in relationship to specific objects, as well as a default set of permissions. (ie, normal read permissions site-wide, but write permissions for a certain library)
Also, the "Site Permissions" is the equivalent of a group that all offspring objects inherit, if they use "Inherit Permissions".
You can add more permissions (ie, write, delete) and override the group or site permissions by modifying an object's permissions directly and adding the user. However, there is no way to subtract permissions from a user that's in a group (and the group has been granted permissions to an object). (think colored glass - by adding different sheets of glass, you can change the colors and make things darker, but you can't add a sheet to remove a previously added color.)
There is one exception:
Permissions set on the Web Application are more powerful: one can use the "Manage Permission Policy" (from Policy for Web Application) to create specific policy levels - where specific permissions can be denied. Denying permissions prevents users from ever having that permission.
[edit 6/14 1PM] some clarification changes in the second to last paragraph. Also...
**DISCLAIMER** This information is not reliable. It's built from my trial and error, toying with SharePoint experience, as notes to myself.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
The complexity of sharepoint model and security management burdens
Date: 2007-07-03 09:41 am (UTC)By the way, the object inheritance schema is available here (http://msdn2.microsoft.com/en-us/library/ms473633.aspx).
Re: The complexity of sharepoint model and security management burdens
Date: 2007-07-03 11:43 am (UTC)Re: The complexity of sharepoint model and security management burdens
Date: 2007-07-03 01:48 pm (UTC)That said, a quick google search for "dl.scriptlogic.com" revealed four other comments that appeared to push this "Security Explorer" tool, all in long-ish comments that didn't have any linebreaks. And each with different author names, such as "Paul Goldschmidt", "Michael Cox", and "Jim Bowell". They're all posted within days (June 20, 21, 22, then 28th, and on mine today...) of each other. Multiple commenters who all write in large blocks of text that only serve to promote one product? I don't know - smells fishy. Regardless, someone gets props for trying. So the comment will be unscreened, although it's right on that fine line of getting deleted for being unwanted advertising.
Re: The complexity of sharepoint model and security management burdens
Date: 2007-07-03 01:51 pm (UTC)http://www.michaelsampson.net/2007/06/response_to_ian.html#comment-73252658
http://www.moss07.org/Lists/Posts/Post.aspx?ID=89
http://weblogs.asp.net/soever/archive/2007/04/11/sharepoint-security-a-dedicated-site.aspx#2872712
http://blogs.msdn.com/not_only_technology/archive/2007/04/10/i-m-a-big-sharepoint-user-but-not-always-the-biggest-fan.aspx#3462918