Let me be a little more specific.
I'm working on a web app that provides management of documents and we need to apply security settings to the folders and documents. The folder structure exists entirely in the app (so there is no folder structure on a disk anywhere).
Now, assume that I have a folder structure like this ...
root
-- DirA
---- DirA1
-- DirB
----DirB1
If this were windows, and a user had rights to change the security settings on all folders in the structure except DirA and opted to make a change to root and all its children, what folders would be effected?
My gut feeling is root, DirB and DirB1 but I'm not sure.
The point is, I want to duplicate the functionality - in terms how /how/ settings are applied - to my app. So, I'm just looking for a simple explanation.
--
Simple of Grantham
When you to set security rights for a user/group in Windows, you also specify whether those rights are inherited to all subfolders. So, if you give the user the right to modify rights in root, you would have to make those rights non-inheritable or they could modify DirA as well. However, Windows doesn't grant rights to modify security settings for a folder unless the user has "Full Control" over that folder. I believe this means that if the user has full control to root, he could delete DirA and add a new DirA, with whatever rights he chooses. To get a better feel for how directory rights work, right-click on various folder icons in Windows XP, choose Properties, then select the Security tab. Study this pane, and then click on the Advanced button to see how rights are inherited. By clicking on the various buttons you will see that by selecting certain rights, such as Full Control or Modify, all other rights are automatically included.
Related
I have used a tool to move over 20 folders into a document library. The tool also moved over the read only rights for the folders.
Now I have 3 users I need to add so that they have contribute access to all of the folders on that library. But when I go to people and groups all I see is stuff for the home page. I only want to give rights to this document library. Do I break inheritance and give individual permissions to everyone listed in the contribute and read only groups?
I am unsure of how to give contribute rights ONLY to 3 people for 1 document library?
You will have to break inheritance for the Document Library and configure the permissions for that Document Library the way you want. These permissions will flow down to all of the folders in the Document Library, unless you break inheritance at the folder level.
You may want to consider creating a SharePoint Group, to which you can add the 3 people, and grant the group Contribute rights to the Document Library. That way if you need to change who can access the Document Library, you can just edit the Group membership. I believe that this is best practice.
What I intend to do is lock the whole release branch down so nobody can do check-in.
But there's one developer that does a lot of installer changes, so he has to be able to submit changes.
Is there a way to do it?
Assuming you are an admin for the project: right-click a folder (in your case, your branch root) in source control explorer, click "Advanced/Security" in the menu, and then choose your settings. You may wish to create a new user group, or just add the user individually.
As a side note, it's often more user-friendly if you deny lock and check-in rights (rather than denying check out): if a developer is browsing the code, VS will often try to check out various files, and the error dialogs this shows when security-blocked can be quite intrusive.
I've create a role and added to it read, write and create permissions inside the folder /Sitecore/System/Aliases for users that need to create or edit aliases to web pages. However, when editing those permissions, the security editor shows the System folder grayed out and i can't set it to read. When i log as an user with this role, i cannot navigate to the alias folder
What permissions/role do i need to add to this role in order that it can access the Aliases folder?
I'm working with sitecore 6.5.0
The System item is Protected by default, so you'll need to log in as the root admin and Un-protect it before making those changes. Once you make the changes though, I recommend you protect it again.
The System Folder should remain protected and only accessible to Admins and Developers IMHO. For controlling access to creating Aliases, you should control the Alias menu item in the presentation ribbon instead. To do this, deny access to the following chunk in the CORE DB for the given Role...
/sitecore/content/Applications/Content Editor/Ribbons/Chunks/Page Urls
I have a document structure where I would like to grant read-only permission to specific group on a sub folder within a document library.
I am using SharePoint 2007
For example:
Folder : Business <--- Document Library under business I have two sub folder.
---> 2009 --> Sub Folder --> store all docs
-----> 2010 --> Sub Folder --> store all docs
Now, I have two groups: Group A, Group B. I would like to grant read-only permission for the 2009 folder to Group A and grant read-only permission for the 2010 folder to Group B. I want to make sure Group A people cannot access the documents under the 2010 folder and vice versa.
I have tried to setup a target audience on Business folder. But I am unable to find a way to setup permissions on the sub folder level. Please let me know how can I achieve this.
This is just configuration:
In the document library, hover the mouse over the folder to see the drop down menu.
Activate the drop down menu by pressing the down arrow
Choose Manage Permissions
Click the Actions menu and choose Edit permissions. Confirm that you want to break inheritance of permissions from the parent.
Edit the permissions as required.
Obviously, you need to be logged in as someone who can change permissions (a site owner or similar) to be able to do this.
If you need a way of progamatically doing this you can modify this script to suite your needs: powershell-to-get-a-list-of-all-folders-in-downloads-pivots
I suggest creating groups for each folder you want to set permissions and then put the people in there. If manual is all you need, then Chris' soulution is perfect :)
On the "My site" feature of Sharepoint there is a "memberships" Web part that shows the distribution list that the user is a member of.
This is picking up several groups that we would rather not be shown e.g. some that have been set up for administrative purposes only.
Is there any way to control which groups are shown; ideally this would be using another AD group and setting that only members of this group are shown.
I'm fairly sure this won't be possible without a custom web part that is deployed instead of the official part. The reason the Exchange solution doesn't work is because it's going the wrong way (from group to member instead of member to group).
To deploy it you can look at feature stapling... you would need to update the existing sites as well.
This is not an easy answer. I don't believe there is an easy answer.
The best solution would be to set a Deny Access Right for the distribution lists in Active Directory; follow these steps:
1) Open Active Directory Users & Computers as an admin (any user with access to creating groups and modify distribution list security settings).
2) Go to the View menu and make sure that there's a check-box next to Advanced Features.
Create a new security group in Active Directory (call it HideFromSharePoint or something) and add the SharePoint Content Access account (in my case DOMAIN\sa_spcontent) to that group (has to match the account used in step 4).
3) For all of the distribution lists that you don't want to show up in SharePoint do the following:
3a) Open the distribution list and select the Security tab (Advanced Features must be checked for this tab to be shown).
3b) Click on Add and type in the name of the security group that you created in step 3 (HideFromSharePoint); click Check Names and click Ok.
3c) Under Permissions for HideFromSharePoint; check the Deny box next to Read (it's set to Allow by default) and click Ok and Ok again at the prompt.
You've just denied any members of the HideFromSharePoint group read access to the distribution list.
4) Go to SharePoint Central Administration; SharedServices1; User Profiles and Properties; Configure Profile Import and under Specify Account enter the credentials of the account that you added to the HideFromSharePoint-group in step 3. (For some reason if you leave this to using the Default Content Access account SharePoint will use some other account to access Active Directory and thereby being allowed access to the distribution lists. You could experiment with adding other SharePoint service accounts to the HideFromSharePoint group but I think it's safer to specify an account explicitly so that you know which account is accessing AD and importing the data.) Also make sure the "Import Connection" for your Active Directory is set to "Use Default Account" (thereby "inheriting" the account used for Profile Imports).
5) Go to SharePoint Central Administration; SharedServices1; User Profiles and Properties and click on Start full import. (You can't do an incremental import because nothing has changed for the users in terms of group membership; it's just the access rights that have changed.) After completion of the full import (click Refresh until "Import time:" says "Started full import at 11/25/2009 ##:## AM - Ended import at 11/25/2009 ##:## AM")
The distribution lists should now no longer show up under Memberships.
A couple of things to note:
You have to set the Deny Access Right explicitly and individually on all of the distribution lists that you don't want showing up in SharePoint. That's because the special AD-group "Authenticated Users" has read access to every object in the directory by default and explicit Allow Access Rights trump Deny Access Rights set (for example) at the organizational unit level.
While you could skip the step of setting up the HideFromSharePoint-group and set the Deny Access Right directory for the SharePoint Content Access account Active Directory administration best practices is to use a group when configuring security permissions. (Then you can add additional members to that group and have those denied read access too.)
You might have to wait a while (5+ minutes or so) between setting the the Deny Access Rights for the changes to replicate to all of you domain controllers. Otherwise the import might read from a domain controller where the Deny hasn't yet come into effect.
Be careful adding any other accounts to the HideFromSharePoint-group because this might break your distribution lists. For example; if Exchange can't read the groups mail won't work. As long as you just add the SharePoint Content Access Account you're safe.
Also (and this has nothing to do with SharePoint or the solution above) be aware that any user in your domain can fire up ADUC or a LDAP tool and see the members of your distribution lists that way. If you have anything "Top Secret" you need to experiment further with setting access controls in Active Directory.
I assume that your "memberships" web part is using the SharePoint people picker functionality internally.
If that's the case, then the following stsadm command should help you scope your AD lookup the way you want it:
stsadm -o setsiteuseraccountdirectorypath -path <name of OU> -url <URL name>
You could try editing the Distribution List on the Exchange Advanced tab, selecting the "Hide group from Exchange Address lists" check box.
I have not tested this but in theory it would stop the Distribution List from appearing the the list of groups.
Easy fix: add a JavaScript to the page on which those appear that targets and then hides the specific items by applying a CSS style.
I don't have an exact answer, but here's how I would think through the problem. Perhaps you have already answered some of these questions, but it might help to go through them again. I would look at the questions in the following order:
Is there an option in Active Directory to hide a group from SharePoint? (sounds like no)
Is there an option in SharePoint administration (either through stsadm or the actual administration site) to exclude certain users or groups in AD from SharePoint?
Is there a way to configure the web part to exclude certain users or groups from the web part itself?
Is the source code to the web part available such that you can compile the web part to exclude certain groups in the list?
Can you use javascript (as Josh mentioned) in conjunction with the webpart to hide the Distribution Lists from the webpart? (Here's a site with an example of how to use JavaScript to Hide SharePoint's Quick-Launch bar. Maybe that will help).
Those questions are in order from the widest scope and easiest to implement to the narrowest scope that is more difficult to implement. Obviously, you'd like to implement a solution that is easiest to implement, but perhaps you find yourself farther down in the list.
In the last two examples, the solution may appear quite complex, but you may be able to write code that references an XML file of sites to exclude. That way, if your list of Distribution Lists changes, all you have to do is edit the XML file and not edit the source code (of either the javascript or the webpart).
If there's not a simple solution, you'd have to make the painful choice of either 1) letting the problem remain or 2) implementing a hack that adds a dependency to your solution.
I think Distribution Groups that aren't security enabled don't show up in SharePoint. Have you checked AD to see if these groups are security enabled? This may be only for permissions purposes, so I could be wrong.
You will probably need to do a profile import before you see any changes.
You can turn off Distribution Lists entirely, which is what we are doing at my company. This is done by going to the Profile Services Policies in the SSP and disabling the Distribution List feature.
Now if you want to pick and choose the Distribution Lists, it's not that simple, but hopefully this will help someone.