In our Sharepoint implementation users have been granted site collection admin rights. On a few occasions they've managed to delete a subsite or even the entire site collection. I'd like to be able to block this but not being a developer I'm finding it pretty tricky.
I've had a look at the MSIT site delete capture tool to try to understand how that's working and it seams fairly straight forward. I want to override the delete function and either block it entirely or have the user type a password. What I can't see is any way to fully override the default behavior as it looks like the MSIT tool simply adds some functionality (backs up the site) then falls back into the default behavior.
So my question is, can I prevent the default behavior or can I only add actions before or after it fires?
Thanks in advance
Change the user permissions may be the best way to go. site collection admin is a crazy level of access for normal users.
Two answers:
You cannot prevent site deletes without either coding up something yourself, or buying a product to help you with "site lifecycle management" or "site governance" or some other vague term they use to describe this sort of thing.
The Site Delete Capture Tool may be good enough for you. It doesn't prevent any kind of deletions, but it does take a crude backup that (hopefully) allows you to restore anything they delete. We're using this tool in production and it works.
You could try to edit the site settings aspx file and comment out the delete site link, don't have a setup around to try that. While users could delete the site in other ways it would prevent the most common method.
Other option for important sites would be to make sure the site has a sub-site, if one does not already exist create one and don't user any access. The site would not be seen by the users and it would prevent them from deleting the parent site.
As for programming, in the before behavior you can return a false to stop the action. Just be sure to place a work around so you can delete a site.
A Site Collection administrator has the permission to delete sites and it should stay that way. We have modified MSIT to do additional stuff
The best way to limit user privileges is to put users in the right SharePoint group (ie) Owners, Members, Visitors or you could create a new group with right permission/permission levels.
Related
I have two reports that I need to build. One that has a dozen or so columns. The other has the same columns + 2 extra. The first one is aimed at employees the second with the additional columns is aimed at Sr. Management.
I have a windows group set up for the proper Sr. Mgt users.
I am using SQL 2012.
I've done some SSRS stuff, but not enough to say I'm competent to do more difficult reports.
The problem I'm having is that we do not want the employees to see the sensitive information in those two columns. Frankly, we don't even want them to know the existence of a different report.
Option 1: I was thinking I can just create a folder in SSRS and add the report there and hide the folder. I created it and applied the security but it seems that everyone can see the folder. Maybe they can't edit anything in it or even maybe they can't read anything in it, but this solution, if unchanged, will not meet the goal of having them not even see it exists.
Option 2: I was thinking that I can use the UserID condition to hide the columns in the report and just create one report that differs depending on who was viewing. There are two issues that surfaced in my research. First, there is no facility for using Windows Groups instead of userid. That would mean I have to maintain the list of people inside the report and boy would that be a pain. And second, my understanding is that the export facility does not respect the column actions -- like hiding.
Am I making this too complicated? Is there an easier way to do this? With no other solution, so I need to put up another instance of SSRS for management and make them go back and forth?
Thanks for your time
Option1: You should not be able to 'browse' for folders unless the 'parent' level permission has an 'everyone' user set up to browse on the higher level. Set up a test account and RDP to a box you can use the test account on. Generally under 'Folder Settings' you set up permission and it cascades down until interupted. If you have a parent permission to browse and a lower one not to, they may be able to browse directories. You can ensure that the directory has ONLY dedicated users and the inherited settings are removed manually.
Option2: I would NOT do this. You will have a maintenance nightmare on your hands as you would have to determine in code who was what and update a list that would probably need to be updated somewhere in SQL or a service. As far as I know SSRS does not work with getting parameters and such directly from AD so you would have to code this time and again. For this reason and security context I would avoid this.
Option3: Set up a 'Subscription' to save the report to a file format(excel, pdf, word, etc) or email on a scedule and turn off permission for everyone but admins. If someone can still see the report or directory there is most likely a security context issue.
Option4: You can do a cheapy 'Hide in tile view' move that for most users will hide the directory unless they go to the URL directly and have access. Click on a folder then choose 'Folder Settings' then check 'hide in tile view' and hit okay. Directory is now gone for most part for regular users browsing in default mode.
I think we can just fix your problem, and avoid inventing a complicated and unnecessary solution:
Option 1: I was thinking I can just create a folder in SSRS and add the report there and hide the folder. I created it and applied the security but it seems that everyone can see the folder. Maybe they can't edit anything in it or even maybe they can't read anything in it, but this solution, if unchanged, will not meet the goal of having them not even see it exists.
Chances are that either you set up the security settings wrong, or there's a bigger configuration nightmare to worry about. What you should do is create the folder, go into the settings of the folder, and edit the security (thus breaking inheritance from the parent folder). Before even adding groups, you need to remove anyone that doesn't belong - namely entries like "YOU\Domain Users" - that gives access to anyone on your domain. Once you've cleaned out whomever shouldn't have access, you can add the users/groups that should. Problem solved.
Now, if that doesn't work, then it would seem to me that your SSRS instance is somehow granting everyone sysadmin access - check the Site Settings to see what users and groups are in the System Administrator role. Investigate any groups thoroughly - is BUILTIN\Administrators a sysadmin in SSRS? Check the group locally on the computer - is there another blanket domain group shown there?
If everyone on your domain has complete access to the SSRS instance, then your goal of "hiding" things is impossible.
I need the ability for users to add, edit, and delete lists/libraries but not have the ability to edit web part pages or delete web part pages. I am boggled that the Edit Items permission allows for editing and deleting web part pages. The alternative I see at the moment is setting Read permissions across the entire site, and then setting specific permissions on each individual List/Library. The problem with this is that I have site templates, so the security does not remain in the site template (it inherits from the parent). Can someone clarify this for me? Or suggest what permission level I should use to accomplish my goal stated above? Thanks.
I had a similar issue at a client site. The workaround I found that worked out rather well was to break the permissions on the 'Pages' document library and set that to read only (with the exception of the groups that actually needed rights to edit pages).
HTH
-CK
How can I disallow adding item or document to a list or document library? Due to some other feature scenario I cannot break role inheritance and have custom permission set for the list. Today, we restrict the addition using event handler (Item adding) – but this leads to poor UX.
Is there a way to have Role inheritance for a list and still have a base permission mask? Something like, allow everything that parent web offers but not X,Y,Z. Breaking role inheritance in the traditional way introduces the problem of explicit User and role management. Having a SPGoup hold an another SPGoup could help here, but that too is not possible. Let me know your suggestions.
I think you are asking to allow a user to have add permissions to the list but not actually be allowed to add to the list. Event receiver is going to be the best way. The only other solution I can think of is to use a custom item form that will do the check.
You can solve your problem by creating a webpart with the below functionality.
Identify the logged user is in admin group. If he is not in that group ganarte a javascript alert that "you have no permission for add new item" and redirect to (location.href="") allitems.aspx page.
And place this webpart in Newform.aspx page.
(add &toolpaneview=2&sharedview=true in in Newform.aspx url for editing page)
Hope this helps. Let me know if you need more help.
Create an IHTTPModule and subclass the context AuthenticateRequest event.
In the AuthenticateRequest routine you can inspect what type of action is happening and then redirect the user to the SharePoint "Access Denied" page. This is exactly how SharePoint does this functionality so the UX experiance would be the same.
If you want my opinion I would go with the way SharePoint handles permissions out of the box and break role inheritiance. Sure it will add new complexities to your life. But, I think you can better manage these complexities with the SharePoint Admin Toolkit and some custom built utilities for managing permissions. I think that is a better solution than what you are trying to do.
Am I missing something here when I suggest: Just hide the toolbar (or specific button) in the view page? That's an painless CSS hook done in the view page or SharePoint Designer
If you are using a custom List Template, you could create a custom View Toolbar Template. However, you probably will not want to use this on an OOTB List Template and it doesn't look like this will work on an existing list.
Even if you implement this, I would still leave the Event Receiver in place in order to prevent URL spoofing.
I have a case where if a SharePoint site owner decides to break permissions inheritance and directly manage site membership, I'd also like to correspondingly modify view permissions on items in a specific list in the top-level site.
How can I best catch those changes so I know when to apply the appropriate changes to the list items?
I'd like to have some C# code be notified when a site's permissions are changed so I can programmatically modify the appropriate list item permissions.
The best way to do this (unfortunately) is to periodically query all of the sites and check to see if inheritance is disabled. I had a similar problem and used powershell scripting to create a report on site security. If you haven't used Powershell before, don't be intimidated. The syntax is VERY similar to C#.
You can use SharePoint auditing to monitor permission changes. It will track changes down to item level. The downside is that you have to turn this feature on and it will hurt performance somewhat.
As for notification, I don't think auditing tells you about changes. I'm pretty sure you would need to poll the audit log.
There's heaps of information about auditing in this article on MSDN.
Another approach which I think might do a very good job of this is to use the SharePoint ChangeLog. Bascially, this is used by SharePoint during indexing, with the log telling the gatherer exactly what has changed, and what should be indexed during an incremental crawl.
When you have a permission change, then this should be picked up during an incremental crawl. The ChangeLog has specific parameters that can be passed to identify changes to permissions. Take a look here at the SPChangeQuery Class:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spchangequery.aspx
Specifically you can look for ChangeTypes:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spchangetype.aspx
Including:
AssignmentAdd
AssignmentDelete
MemberAdd
MemberDelete
...and more
I am working on a project that is replacing an old portal system (Plumtree) with sharepoint and we want to make the transition as smooth as possible.
One thing we are look at currently is taking all the gadgets (Plumtree term for WebParts) and making sure they appear in the same place on the users new MySite.
Plumtree holds this information in a simple table containing the user, page, gadget and position information. I want to find a way to automate reading this table and putting the new WebParts on the users MySite and not have to manually set it up for hundreds of users.
I'm told modifying Sharepoint tables in SQL Server directly is not a good option as it may affect our support arrangements, but if it saves doing this by hand then I would concider it.
Other options that spring to mind are creating a equivalent table and using API calls to load the WebParts the first time the user accesses their MySite.
Any better suggestions?
You are right, messing directly with databases are not supported nor recommended.
Unfortunately, there are not much ways to modify MySites, the best way I know come from the MOSS Team Blog: http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx
The way we did it was pretty much what is described in the link above (http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx).
Your best bet is probably to staple a Feature to MySite creation and have it poll the plumtree database, find the gadgets for that user, and add a 'Page Viewer' web part for each, pointing to the gadget's location. That said, you may want to reconsider blindly migrating all your plumtree gadgets into SharePoint. There may be much better 'SharePointy' ways to provide the functionality that your gadgets are currently providing.