I have a Sitecore application, and some of my content authors want to work on some "secret pages" that should not be available to anyone else, including other content authors. Only a few of the content authors should have access to these "secret pages" as well as page.

What I've done so far...

Let's say the item is


and the website url is:


All content Editors are part of the role sitecore\MySite Content Editors.

Since some of them need special privileges, I created a special role. Before doing so, I went to the Access Viewer and marked the myLocked-Item as Requires Login. Then I made sure that I removed the read, write, rename, create, delete, administer properties to the following roles

  • Defaut/Anonymous
  • Extranet/Anoymous and
  • sitecore/MySite Content Editors

Now, when I log in as a content author, I am neither able to see the item in Sitecore nor am I able to see the page on the website - I am instead redirected to the Sitecore login page. This is all the expected behavior.

The next part is to make a role that grants the authors who will be editing the "secret pages" the necessary permissions to access and edit those pages.

I first created a role called sitecore\Special rights. I then went into the Security Editor and provided all rights for read, write, rename, create, delete, administer for the mylocked-item for this role.

For the last step, I went to the users who will be editing the "secret pages" and gave them the sitecore\Special rights role. The problem is that I am still not able to provide them with access.

The Content Authors who will be editing the "secret pages" are members of 2 groups:

  • sitecore\Special rights
  • sitecore\My Site Content Editor

Whereas everyone else is part of just one the group sitecore\My Site Content Editor.

What am I missing?

  • When you say that you removed read, write, rename, delete and administer access to these items for the specified users (including sitecore\My Site Content Editor) did you apply the "Deny" access right (the little red "X") or did you simple remove the "Grant" access right (the little green checkmark)? Sep 8, 2017 at 19:15
  • i applied the Deny (Red) Sep 8, 2017 at 19:20
  • You need to break inheritance of of read access, and don't forget to break read inheritance for the Everyone role as well: stackoverflow.com/questions/26979521/…
    – jammykam
    Sep 8, 2017 at 20:26

3 Answers 3


The Problem

The problem is that the "Deny" access right trumps the "Grant" access right. For this reason, if neither the "Deny" or "Grant" have been applied, then the "Deny" access right is assumed. It is only in this case (i.e. no access right explicitly assigned) that subsequently applying the "Grant" access right will trump the "Deny" access right. In other words, the "Grant" access right only works if there is no explicit "Deny" access right that is also assigned and conflicts with the "Grant".

The following diagram is from Sitecore's official documentation and illustrates how access rights are calculated when there are conflicts between them:

enter image description here

Access rights – Denied overrides Allowed.

Security accounts– Access rights assigned to a user account override access rights assigned to a role.

Item – Access rights assigned specifically on an item override access rights specified for the descendants on the parent item. Access rights assigned specifically on an item or on the descendants of an item override the Inheritance access right.

This means that explicitly assigning the "Deny" access right to a permission means that that access right will ways trump the "Grant" access right for that permission.


Rather than applying the "Deny" access right, open up the Security Editor (it is recommended that you make all security changes in the Security Editor, not the Access Viewer) and remove the "Deny" access right, as well as the "Grant" access right from each of the items in question. The roles for which you wish to allow access should be given the explicit "Grant" access right for each of the desired permissions, which will give them (and administrators, by default) access.

The Challenges with Permission Inheritance

Permission inheritance makes things tricky, here. In order to do what you are attempting, what you need to do, conceptually, is to deny inheritance for the permissions on the sitecore/content/home/mysite item (the parent item), and re-apply the permissions (with inheritance allowed) on each of the sibling items to sitecore/content/home/mysite/myLocked-item. Doing this manually would work, but it could be a lot of work and expose long-term maintenance challenges.

Alternatively, you should be able to avoid having to assign access rights on all of the siblings by explicitly denying the "Inheritance" property of the permissions for the mylocked-item and its descendants (unless they should be available for some other reason). This should save you some time and make long-term maintenance easier.

These steps are a bit tedious, but it is the way to get you what you want. Unfortunately, permissions are not all that straightforward, and though the system may seem a bit "hacky" it is actually the industry standard (OSX, Ubuntu, and Windows permissions work this way, as well, to name a few).

More Information

Unfortunately, without being able to see your content tree, the Access Viewer for each of the roles that you mentioned before applying permissions and the Security editor for each of the roles that you mentioned before applying permissions, there's not much more direct instruction that I can give you. However, I highly recommend that you thoroughly review each of the following articles from Sitecore's official security administration documentation, as they explain everything that you need to know to achieve what you are attempting:

  • i agree on the tricky part.. .. but did not understand your note . So are you telling me that i need to deny inheritance for the "my lockeditem" for Content editor role and then apply grant with "Special user" ? Sep 8, 2017 at 19:32
  • No, you need to remove both "Deny" and "Grant". The default will be "Deny", so if you remove both the explicit "Deny" (the red X) and the explicit "Grant" (the green checkmark) then the default permission is effectively "Deny". If you explicitly assign the "Deny" permission (the red X) then account that has that explicit deny (be it on the account itself, on a role, etc.) will never be able to have the "Grant" permission because the "Grant" permission will always be ignored. Sep 8, 2017 at 19:35
  • i just removed deny. and when i see to access viewer, i see that item has grant access because of inheritance. should i remove the deny and grant for all items in the parent? that will be huge because the parent has 1000 + items Sep 8, 2017 at 19:37
  • That's the problem that I mentioned in the section on permission inheritance challenges. There is one thing that you can try and I will update my answer with it: you can try to explicitly deny the "Inheritance" property of the permissions for the item with or without descendants on the mylocked-item. That may do the trick without you having to change a ton of other permissions. Sep 8, 2017 at 19:43
  • I went back and re-read and found a couple of typos that may have caused confusion before. I tried to clean it up a bit and add a little more detail. Let me know if you have any other questions. Sep 8, 2017 at 19:49

As Zach said the key for this to know is that a deny will override granting access. That is the reason that denying and then trying to give access with a different role (while using the role that denies) does not work. You have 2 options:

  1. You can invert the logic. Remove the deny access given to the content editor role and let accessing those items be the norm for a content editor. Make a restricted content editor role and deny read access to the secret items there. Then apply this role to the editors that should not be able to see it. I don't think Zach's answer goes over this option directly. You can use this if the norm will be that content editors can see the hidden pages.
  2. Deny inheritance to the items for the content editor role instead of denying read access. This will cause a "soft" read denial because the content editor no longer inherits read access to that item. Then in your special role you can explicitly grant read access.

Regardless of the choice, denying read access at the base content editor role shouldn't be done if these editors will end up inheriting that role.


You have setup access deny to main content editor role (sitecore/MySite Content Editors) for read, write, rename, create, delete and administrator.

Now for \Special rights, you have inherited the same role, that may be the cause of this issue - overriding the inheritance access

Can you please try the below steps:

  • Create a duplicate role same as (sitecore/MySite Content Editors)
    – Without any access deny – let’s say (sitecore/MySite Content Editors Secure)
  • Provide role to user - Special rights and (sitecore/MySite Content Editors Secure)

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.