I'm working with v.4 SP1 and trying to trim some controls from the master pages of a site collection. Specifically the "Site Actions" menu (that's the most important one) and the social tags (less important), as well as trying to clean up the tree view navigation (I understand this may require a completely separate fix involving JS but I thought I would ask just in case security trimming can do the job).<---Update: Solved this by switching to flyout menus.

I've found lots of what seems to be very clear evidence online that this should be easy to do, just find the specific control in the default.master and v4.master and wrap it with the security trim like this (using "Site Actions" menu as an example):

<Sharepoint:SPSecurityTrimmedControl runat="server" PermissionsString="ManageWeb">
    <SharePoint:SiteActions id="SiteActionsMenuMain" runat="server">

So I do that, save it, publish and approve the page as a major version, and go to take a look on the site with a "contribute" or "read" account (that should be trimmed by ManageWeb). But absolutely nothing is trimmed. I've tried using different PermissionsString variables, tried doing it to different controls, even tried doing it to specific menu items within "Site Actions" but nothing ever changes on the site.

I feel like there's something very basic that I'm leaving out or not taking into consideration. Can anyone give me a face-palm solution? Or at least point me in the right direction?


Update: I've run into situations where changes made to the tree view delegate control of a site not based on the blank template don't take effect because, as Microsoft explains it, at runtime the server ignores the control and overrides it with a different one, and their solution to this is to change the ControlId to make it look at the one you want. Could it be a feature similar to this that's preventing the SPSecurityTrimmedControl wrap from being published at runtime?

The Microsoft article is here: http://support.microsoft.com/kb/2558891

2 Answers 2


A few possibilities come to mind :

  1. Are you sure that the site is using the exact same master page you are modifying? It sounds obvious but it is an easy mistake to make.
  2. Does your site have Output Caching enabled? If so, it is conceivable that you could be looking at a cached copy of the page when you are testing the change
  • Hi Dave, thanks for the response. Output Caching is not enabled on any level, but good thinking. The master page I'm editing is the one loaded by SharePoint Designer when on the page I choose "Site Actions -> Edit in SharePoint Designer" and open the default.master or v4.master from the "Master Pages" category in the object navigator. I would assume this is the correct one, have you ever run into an instance where it is not? You just made me think it could be Windows caching it too, but then again any other changes to the site show up correctly. Any more ideas? Thanks again for your help!
    – thanby
    Oct 29, 2012 at 15:57
  • Just a shot in the dark but can you check the permissions of one of your Read-Only accounts using the permission checker for the site in SharePoint? It is possible that the Read-Only accounts are being granted higher permissions through some other mechanism. it is also worth checking that they aren't being granted full control through a Web Application Policy (in Central Admin)
    – Dave Wise
    Oct 29, 2012 at 21:15
  • Permission checker showed the accounts I'm testing as having read-only access. At Central Administration they have no extra permissions and all the permissions levels (like read only) are at their defaults. The accounts are also not being given permissions by another vector like "Authenticated users". To be completely sure, I created a new AD account with no special permissions anywhere and granted it read-only permissions directly in SharePoint. Same results there. Double-checked the master pages to make sure the security trimmed controls were set to ManageWeb, in case I had that wrong.
    – thanby
    Oct 30, 2012 at 15:37
  • I feel like it's just something simple I'm doing wrong, but I can't find a flaw anywhere in the process o.O Is there some other OOB setting in SharePoint that prevents security trimming? I've made sure it's enabled at the site collection level.
    – thanby
    Oct 30, 2012 at 15:38
  • You didn't change the Impersonation settings in the web.config did you?
    – Dave Wise
    Oct 30, 2012 at 16:28

Closing this question down - I've managed to work around the issue.

Instead of trying to customize the master page I've created a more complicated security structure, "partitioning" some users off to a different page that is locked down so the problematic controls aren't even available. Not a perfect solution, but it does the job.

However if someone stumbles across this and happens to know the direct answer, please feel free to add it, because it would still be useful to me (and maybe others!) in the future.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.