for example, 2 extranet roles in sitecore Role1 and Role2
Role1 is block access to item, Role2 - allow access.
I need to have behavior that revers default sitecore behavior:
5.3 How Access Rights Affect Each Other In Sitecore, every user and role can be a member of several roles. When a security account has
been assigned several roles, the access rights that the different
roles possess are added together. The security account is therefore
assigned the accumulated access rights of all the roles that it is a
member of. However, if a security account is assigned two roles and
one of the roles is denied a specific access right to an item and the
other role is granted this access right to the same item, the access
right is denied for this security account. In other words, deny
always overrules grant when access rights are accumulated.
Is it possible to do via some sitecore settings or etc ?
Thanks.
What is the behaviour you want then? If someone has both Role 1 and Role 2 - Do you want that person to have see it?
In that case you'll be better off removing inheritance on Role 1 in stead of denying access. Denying access basically tells Sitecore to start over from a specific point. Role 2 can then get the access again.
Have a read through this: Best Practices from TheClientView. The very first example sounds like what you're trying to achieve:
There is a role A that denies a write access to a “/home/contact us”
item.
There is a role B that allows write access to the item. There is a user AB that
should have power of both roles A and B. But due to explicit deny permission on
the item, the user won’t be able to get write access on it. When you break the
security inheritance it sets permissions into default deny state, which could be
overridden, by setting up explicit allow access on a role. But explicit deny
access can never be overridden by explicit allow access.
Related
We have a few domain accounts that are used to do LDAP queries for various systems. We don't want these accounts to be able to query all of the OUs in our AD.
# domain level we have given Authenticated Users Read access to all OUs.
Created a Security group that these accounts are members of.
Granted Security Group Read access to the three OUs where we have Users that they should be able to query.
Issued Deny Full Control rights to all of the other OUs that contain Users.
One of the systems using an account is our Copiers. A global search of the directory is still pulling up Users that exist within the OUs that have denys configured.
Not sure how this could be happening.
Thoughts?
It's not enough to have a deny on just the OU the objects are in. The permission needs to be a deny for:
List Contents
Read All Properties
Read Permissions
And it needs to be applied for "This object and all descendant objects" on the OU in question.
Is there a way to combine access rights for a Sitecore item?
For example, I have a page that I would like to lock down to users who are a member of two different roles rather than just just one, and a user who has just one of the roles should be denied access.
I know you can have roles within roles but wondering if there was a simpler way to achieve this?
I'm using Sitecore 7.2.
If you are trying to check this in code, you can easily do so using
var user = AuthenticationManager.GetActiveUser();
return user.IsInRole("Role1") && user.IsInRole("Role2") ? "Granted":"Denied";
But if you are trying to achieve this in Sitecore Security on an item, then an AND of those 2 roles will be assigned. Ex: If I allow access to an item in Role1 but deny in Role2, the user with Roles 1 and 2 will have his/her access denied.
The simplest way to approach this is to define a new role with appropriate access rights and assign the relevant users to it, either manually or by script. That keeps your access rights transparent. You could code your way around the issue, but you could end up creating an admin nightmare, where it's near to impossible to see which roles and users have access to which items. E.g. what would you expect to see in the Access Viewer when looking at one of the roles, or at a user with one or both of the roles? There's a big difference between assigning access rights programmatically and evaluating them programmatically.
One way that you could achieve it via the Security Editor is by utilising Sitecore's Roles in Roles functionality.
Essentially you will want to create a New Role in the Role Manager that will contain the two roles, Role A and Role B. Select your New Role in the Role Manager and click Member Of button. In the modal click Add and select the two roles this New Role needs to contain.
In the Security Editor select the New Role and assign the read, write, create etc permissions to the required Items.
Now when users access those Items they must have Role A and Role B before given access - they will not need the New Role assigned to their account.
If you have a large number of roles to manage and combinations of those it will be very time consuming to manually create those combinations.
A user is added to 2 different groups. 1 group is provided author access and another group is provided with editor access. First group has user role 'A' and second group has user role ' A,B'. What is the access and role the user would have?
The user would have the highest access level of all groups (in this case editor access) and all roles assigned to groups (in this case A and B) in database's ACL.
There is only one exception: if the user is listed with his own name in ACL then only these rights the user would have, no matter which listed groups he's member of.
The access levels are combined. However, Deny access takes precedence over Allow access.
See the docs for more info: http://www-12.lotus.com/ldd/doc/domino_notes/7.0/help7_admin.nsf/b3266a3c17f9bb7085256b870069c0a9/52f8492cea3792698525706f0065c44b?OpenDocument
Also, as the doc states it is helpful to use the Effective access feature within the ACL dialog to see exactly what the user access is.
I have a browser:page setup in Zope, and I have:
permission="zope2.Public"
My question is what should I change this to in order to allow only Plone administrators access, and/or logged in (non-administrators) access to this page?
On Zope, you control access to views via permissions, but to permit someone to access a given permission, you must grant such permissions to a role.
Anyone in the Plone administrators group has been granted the Manager role (on Plone 4.2 that'll change to the SiteAdmin role) generally have access to most permissions. There is also the automatic Authenticated role, which is given to anyone that has been authenticated (has logged in). The latter doesn't have many default permissions though.
Permissions are generally named after the action you want to permit. If your view's goal is to manage some aspect of your Plone portal, then the cmf.ManagePortal permission is probably what you want. You can check the full list of default permissions if you need another one.
There is some excellent documentation on how security works in Plone, which includes information on how to define new permissions too, and how to assign existing permissions to roles.
permission="cmf.ManagePortal"
This setting is about permissions not about roles.
My team implemented a UI to assign/revoke permission levels to users on a certain SharePoint list. The UI supplies an "undo" feature to restore the rights the user had before they were changed through our UI.
Now there is a problem if the user had the "Limited Access" permission level: This permission level is removed when you do a change over the UI. When trying to Undo, the permission level should be added again, which leads to a
You cannot grant a user the limited access permission level.
SharePoint grants that permission level automatically when a user gets access to some entity beneath the site. It cannot be granted manually. This permission level is then inherited by all lists in the site. However, after breaking inheritance on a list, I can revoke the right manually, only, I cannot re-grant it afterwards.
So SharePoint treats that permission level quite particularly and I'm wondering how to work around that in our undo feature.
My questions:
Did I get it right that this "limited access" is granted by SharePoint on the site level only, and all the lists beneath only contain that accidentally through inheritance?
Does that permission level have any effect at all on a list, or does it only apply to the site itself?
So, would it be save to just remove it from a list and do not add it anymore when the user clicks "undo", since it has no effect anyway?
I dare to answer my own question just for reference for future readers:
According to Microsoft's article Permission levels and permissions,
The Limited Access permission level
cannot be customized or deleted.
and
(...) Windows SharePoint Services 3.0
automatically assigns this permission
level to users and SharePoint groups
when you grant them access to an
object on your site that requires that
they have access to a higher level
object on which they do not have
permissions. For example, if you grant
users access to an item in a list and
they do not have access to the list
itself, Windows SharePoint Services
3.0 automatically grants them Limited Access on the list, and also the site,
if needed.
In practice this means that:
If you can delete it, that's only because it has been inherited and has no meaning on that certain list.
If later on a user is granted some permissions to a certain list item, so that he needs the Limited Access on the list, SharePoint will take care of adding it again.
Summarized: No concerns to remove and not re-add that access level.
Removing a user with Limited access on the top level site should not actually remove their explicit access on the list or library below (with broken permissions) but MS do say in the above mentioned article:
However, to access a list or library, for example, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted.
This suggests that the user's Limited access should be declared on the site permissions. I think its always best to do a test on your site first before making any assumptions.