|
Posted by Joe Richards [MVP] on May 1, 2007, 11:22 pm
Please log in for more thread options Not sure if we are saying the same thing yet Roger... On this piece
>> If you slap a deny on L1, a grant on L2, L3, or Object will
>> override the deny.
>>
>
> Again, because the deny when calculating on L1 is explict,
> but when calculating on L2, L3, or Object it is inherited
>
But consider if you have the Deny on L1 and the Grant on L2... At
Object, both of those ACES are present and inherited. The only way to
sort that out is with hierarchical precedence of the inheritance which
is represented by the ordering of the ACEs in the ACL.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net
---O'Reilly Active Directory Third Edition now available---
http://www.joeware.net/win/ad3e.htm
Roger Abell [MVP] wrote:
>> Roger Abell [MVP] wrote:
>>>> If a user on my Windows Server 2003 SBS domain is a member of 2
>>>> different
>>>> security groups that have overlapping permissions, would the allowed
>>>> permissions of one security group override the denied permissions of the
>>>> other security group? Or would the denied permissions override the
>>>> allowed
>>>> permissions?
>>>>
>>>> Though it may not be as cut and dry as that. Does the scope of the
>>>> security
>>>> groups (i.e. universal, global or local domain) play a factor?
>>> It is in fact not that cut and dry, but at least how the principal is
>>> indicated in the grant or deny (as user or as some form of group)
>>> makes no difference.
>>>
>>> Denies overrule their respective category of Grants.
>>> The categories are inherited or explicit.
>>> Explicit overrules inherited.
>>>
>>> So, how that adds up is
>>>
>>> inherited grants are least potent
>>> (either kind of deny can overrule and inherited grant )
>>>
>>> explicit grants can overrule inherited denies
>>>
>>> explicit denies are most potent
>>> (explicit denies can overrule either kind of grant)
>>>
>> And it isn't even entirely this cut and dry. ;o)
>>
>> Not only do you have inherited and explicit, you have a concept of the
>> level of inheritance.
>>
>
> But you do not really need to consider "levels", just inherited or not.
>
>> So if you have
>>
>> L1
>> L2
>> L3
>> Object
>>
>> If you slap a deny on object (explicit deny), it will override anything
>> granted at any of the levels or directly on object.
>>
>> If you slap a deny on L3, it will override grants from Levels 1-3 but a
>> grant on Object will override the deny.
>>
>
> the deny on L3 is explict there, but that same deny is inherited
> when calculating on Object where your (explicit) grant overrides
>
>> If you slap a deny on L1, a grant on L2, L3, or Object will override the
>> deny.
>>
>
> Again, because the deny when calculating on L1 is explict,
> but when calculating on L2, L3, or Object it is inherited
>
> One set of rules, but if your intent is to indicate that an ACE is not
> absolutely an explicit or inherited, you have a good point, that any
> ACE is only explicit at its point of definition and if it indicates an
> inheritable that same ACE is present subsequently as an inherited.
>
>> There is also of course one other case, IMO, that can come up and since it
>> isn't described whether this is permissioning on AD or the file system or
>> what not... This is the case of a corrupt ACL in my opinion but it is
>> something that is done on purpose with Exchange. This the case of an
>> incorrectly ordered ACL, or the fancy term Exchange gave to it to make you
>> think it wasn't so bad - non-canonically ordered ACL. With this they edit
>> the raw ACL and place an explicit grant ahead of explicit deny in the ACL
>> chain so that an explicit grant will actually override an explicit deny.
>>
>
> That is absolutely gross !!!
> More strikes against what Ex does to AD environment.
> (how many does it take to make and out ??)
>
> At least for NTFS, which we have been illustrating, where the explict
> precedes inherited, deny precedes grant ordering semantics is used,
> the UI tools do reorder ACLs that are found misordered.
>
>> This comes down to the raw implementation of ACLs and how they work. The
>> whole thing described above is based on correct ordering of the ACL, it
>> isn't that the security system is validating all of that all of the time.
>> It is assumed, that every process that edits an ACL will order it properly
>> when writing it back. If this doesn't occur, the rules go out the window
>> and you get to the pure real rules... Which are
>>
>> 1. If a security principal isn't specifically listed in an ACE with the
>> appropriate access right, they are denied access (passive deny)
>>
>> 2. If a grant ACE for the security principal and access request is found
>> BEFORE a deny ACE is found, then the access is granted.
>>
>
> 3. If a deny ACE is found for the principal and (any part of the) access
> demand before grant ACEs sufficient for the access demand then access
> is denied
>
> Ex !!#!,
> Roger
>
>
| 
XML Sitemap