Can we switch the system so that if an account has both allow and deny access rights that deny overrides allow. I thought it used to be this way.
Hi Chad,
As Brian notes, explicit denies always override explicit allows, and it always has. Are you seeing something different?
Note that this does NOT apply to rights scenarios that do not have a form of explicit deny, such as Feature Rights or Privileges.
Is there some privilege that overrides deny? I have run into this twice in the last couple weeks. A user is granted full rights at a top level folder and in a sub folder they are denied. Their effective rights show they have access anyways.
Here is an example I found where \Everyone is set to deny delete
Pulling up effective rights on a domain user, shows they have rights anyways
This is assigned and effective rights for the same entry? I can't reproduce it with a 10.3.1 test system, it shows delete being denied to a domain user as expected. And I am prevented from deleting folders within the folder where the ACL is applied. If it's not acting correctly, you should open a support case so we can investigate.
The domain user has inherited allowed rights, but yes, the same folder as I have explicitly denied the everyone account to.
Hi Chad,
There are some privileges that will bypass entry access rights, but only in limited scenarios. For example, 'bypass browse' will obviously bypass browse, and 'manage entry access' will grant sufficient rights to be able to access all entries to set security on them. Nothing will outright grant all rights when there is an equivalent deny though.
I was asked a similar question by Support today - I don't know if it's your scenario, but in that case the issue was that the deny was happening at a higher up area at the tree - say the root folder - and the user in question had an explicit allow later down on the folder in question. While in general deny's beat allow's, the one exception to that is where folder inheritence is concerned - an explicit allow at a subfolder will in fact replace an explicit deny earlier up in the tree. All that said, it sounds like you've checked this?
Have you tried running an explicit access rights report on the user or folder tree and seeing if anything unexpected is coming up?
Aha! you figured it out. That was exactly it, there was a group explicitly allowed on the same fold where we had the explicit deny. I never would have thought that made any difference, since I always thought inherited rights were equivalent to explicit.
As soon as I updated the group it shows the correct effective rights. This very likely explains the other case where this came up previously also where a weblink repository user could access all these documents it was explicitly denied to.
Thanks for the update
Deny always takes precedence over allow, and I think it always has. The advice would be to tweak security so that the deny is not needed, maybe by adjusting the scope of the ACL that grants the access in the first place.