Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 669
  • Last Modified:

Why are SharePoint 2013 permission levels inherited on this subsite?

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
Auhn
Asked:
Auhn
  • 5
  • 4
  • 2
1 Solution
 
tapiwabCommented:
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
 
AuhnAuthor Commented:
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
 
tapiwabCommented:
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
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
AuhnAuthor Commented:
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
 
tapiwabCommented:
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
 
AuhnAuthor Commented:
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
 
Walter CurtisSharePoint AEDCommented:
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
 
AuhnAuthor Commented:
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
 
tapiwabCommented:
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
 
AuhnAuthor Commented:
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
 
Walter CurtisSharePoint AEDCommented:
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

Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

  • 5
  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now