Solved

Why are SharePoint 2013 permission levels inherited on this subsite?

Posted on 2015-02-16
11
417 Views
Last Modified: 2015-02-19
Hi, first time poster in need of some advise :-)

I have a SharePoint 2013 Enterprise environment set up (one application server + another database server). One site collection with a few subsites.

Hierarchy:
* Top-level site
** Subsite #1
** Subsite #2
** Subsite #3
etc ...

Scenario
All subsites have their own unique permissions (SharePoint groups). I am administrating the site collection as a Site Collection Administrator. I'm able to create my own custom permission levels on all subsites as needed. I need to create a new custom permission level only available on this one specific subsite*.

Problem
*This is the one subsite where I cannot create my own custom permission level. I can confirm via the site settings that neither permissions nor permission levels are set to inherit anything. As far as I can tell this subsite isn't configured any differently than the other subsites.

The view from a subsite where I can create my own custom permission levels.The view from the subsite where I cannot create my own custom permission levels
Current workarounds
1. Go to the Top-level site and create a custom permission level which will be made available on the subsite. I would like to avoid this approach as it would no doubt lead to much "clutter".
2. Delete the entire subsite and create a new one, move all content here. I would also like to avoid this approach as I need to learn why it happened so I can avoid it in the future.

Can someone please help me understand why this is and how I can solve the problem? Feel free to ask me anything as I suspect I have overlooked something somewhere.
0
Comment
Question by:Auhn
  • 5
  • 4
  • 2
11 Comments
 
LVL 5

Expert Comment

by:tapiwab
ID: 40611832
its looks like the second subsite is still inheriting permissions from the parent

can you check on the ribbon if there is stop inheriting

Capture.JPG
or try  to stop inheritance with powershell If you have access to central admin

$url = http://SharePointSite.com/SubSite
$web = Get-SPWeb -Identity $url
$web.BreakRoleInheritance($true)
0
 

Author Comment

by:Auhn
ID: 40612135
Thanks for the reply, I did as you suggested.

Ribbon
The subsite isn't set to inherit permissions.I checked the "Show these items." link. The blurred location is a folder in a document library. But that shouldn't have any bearing in the case.PowerShell
I logged in as the farm administrator account on the application server and ran the following command via SharePoint's powershell:
I checked the subsite again and it appears unchanged. I'm still not able to change permission levels.
permission-levels-7.png
0
 
LVL 5

Expert Comment

by:tapiwab
ID: 40612331
can you try to open the addrole.aspx page of the subsite replacing your site urls below

sharepointURL/Subsite/_layouts/15/addrole.aspx

The previous versions of SharePoint it was not possible to change permission level from a subsite
0
 

Author Comment

by:Auhn
ID: 40612651
I accessed .../_layouts/15/addrole.aspx from two different subsites:
Subsite with problems: http://sharepoint/subsite1/_layouts/15/addrole.aspxWorking subsite: http://sharepoint/subsite2/_layouts/15/addrole.aspxHad to change diagnostic logging for Event Level from Warning to Information and Trace Level from Medium to Verbose just to get these messages from the correlation ID when I attempted to access the addrole.aspx on the subsite with problems.
Dug out the correlation ID with ULS Viewer:
0
 
LVL 5

Expert Comment

by:tapiwab
ID: 40614044
I checked from my side I am getting the same error on all subsites

You cannot customize permission levels in a web site with inherited permission levels. at Microsoft.SharePoint.ApplicationPages

I am sure the permission levels are inherited from the parent site even though the permissions are not inheriting from the parent.

are you sure the site you are referring to is not a subsite?  if you check In Central Administration, on the Application Management page, in the Site Collections section, click View all site collections.
The Site Collection List page lists all the site collections in the web application.

Do you see the site you are referring to as subsite there?
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 

Author Comment

by:Auhn
ID: 40614106
I did say I would double check everything anyone asked so here I go :-)
I logged in to Central Administration and navigated to Application Management \ Site Collections \ View all site collections:This is the complete Site Collection hierarchy illustrated. Green is Top-Level Site, blue are subsites with unique permissions and the red subsite, while having unique permissions, is the problem.This is what I'm talking about; as far as I can tell it should be working. The logs, configuration, everything is telling me that it should work. Except it doesn't, something, somewhere, somehow has caused an error to occur and I don't know what. Any new subsite I create works just fine, there's no hint of this error there. So I know it's not a general issue with our SharePoint environment. I think no one else has screwed anything up because only one person other than me has Full Control ownership of the subsite. That person swears on his family's grave he hasn't done anything.

Is there any way to check by powershell or other means how our SharePoint perceives its sites' inheritance? Kind of like the powershell script you asked me to run in order to certifiably break all inheritance for the subsite. Obviously the subsite is nonetheless inheriting from the TLS, and that has to be apparent somewhere in some configuration or information retrievable by powershell. Or even by venturing directly into the database.
0
 
LVL 14

Expert Comment

by:SneekCo
ID: 40614398
It seems that you are confusing permission levels with permissions. They are totally two separate things. Permissions levels should really not be messed with and only create a new one for special occasions, such as a permission named "Contribute minus Delete."

What you probably need to do, it approach your situation using the process of creating SharePoint groups, assign the appropriate "permission level" to it, then add users to that group. Then use those groups for your security structure. You could also grant a user a certain "Permission" from a "Permission Level".

Rethink your approach, it may need going back to the drawing board, maybe a review or security documentation for SharePoint.

Hope that helps
0
 

Author Comment

by:Auhn
ID: 40614438
Thanks for your reply and suggestion. I've begun to rethink my approach since I can't seem to get to the bottom of why the problem has occurred.

Considering the issues with permission levels on this specific subsite (Subsite 7 in the hierarchy picture) I'm leaning toward saving the content, deleting the subsite and recreating it. If there is this issues with permission levels then I can't trust there are no other errors lurking around that will cause me problems down the road. It's better to be safe than sorry.

I intend to do just that at this week's end unless anyone can help me find the problem's cause or how to solve it.
0
 
LVL 5

Accepted Solution

by:
tapiwab earned 500 total points
ID: 40618745
hi

breaking permissions levels you may use powershell

$web = Get-SPWeb "subsiteurl"
$web.RoleDefinitions.BreakInheritance($true,$true)

after running the command is should work

Reference
http://stackoverflow.com/questions/7038444/programatically-break-permission-level-inheritance
0
 

Author Comment

by:Auhn
ID: 40618994
I did as you suggested and that seemed to have resolved the inheritance issue. You solved the problem!Thank you very much for you help! I'll be sure to read up on those resources.
0
 
LVL 14

Expert Comment

by:SneekCo
ID: 40619012
You are making a serious mistake. You and the guy giving wrong advice are confusing permission levels with permissions.  I don't care about the points, but I have worries about how you are going down the wrong road. Just because you can do it in PowerShell doesn't make it right.

Best of luck and I really hope you don't have a major security breach in the near future.
0

Featured Post

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

SharePoint Designer 2010 has tools and commands to do everything that can be done with web parts in the browser, and then some – except uploading a web part straight into a page that is edited in SPD. So, can it be done? Scenario For a recent pr…
I thought I'd write this up for anyone who has a request to create an anonymous whistle-blower-type submission form created using SharePoint 2010 (this would probably work the same for 2013). It's not 100% fool-proof but it's as close as you can get…
Excel styles will make formatting consistent and let you apply and change formatting faster. In this tutorial, you'll learn how to use Excel's built-in styles, how to modify styles, and how to create your own. You'll also learn how to use your custo…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

759 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now