Note also that there is a hierarchy in the inheritence as well...
 
If you have
 
L1
     L2
          L3
             U3-1
 
If you set an inheritable deny access for everyone to description at L1 that deny would apply all the way down to L3 and U3-1 (assuming no blocked inheritence). If you consequently grant an inhertable allow everyone for description at L2, L2, L3, and U3-1 would have an effective grant to description.  You could also set it at L3 or explicitely on U3-1.
 
However, if the inheritable grant and deny of description were applied at L1, the deny would win out.
 
 
  joe
        
 
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm 
 
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Monday, June 26, 2006 1:50 PM
To: [email protected]
Subject: RE: [ActiveDir] Deny permissions in AD

Probably order of inheritance…

 

1.     Noninherited Deny entries.

2.     Noninherited Allow entries.

3.     Inherited Deny entries.

4.     Inherited Allow entries.

 

 

:m:dsm:cci:mvp | marcusoh.blogspot.com

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Coffman
Sent: Monday, June 26, 2006 1:44 PM
To: [email protected]
Subject: [ActiveDir] Deny permissions in AD

 

I have an Active Directory 2003 domain that is used only as an LDAP User store for a 3rd party Identity Management Application.
 
There are no workstations or servers in the domain, other than the DCs themselves.
 
We are trying to lock down the domain, so that an ordinary user cannot read other user's attributes. For some special attributes, we have implemented the 2K3 SP1 "Confidential Attribute" function, and it is working well.
 
However, over the weekend, another administrator decided to try something that has me a little perplexed.
 
Here is what the Admin did:
 
Put a DENY ACE for the "Domain Users" group for "Read All Properties" (in advanced security settings) on an OU containing a lot of users.
 
Now, your average user account cannot read attributes, which is good. Domain Admins and Administrators can read the attributes of users in the OU, which is also good.
 
However, I am wondering, why does this work this way? Shouldn't the DENY ACE override all other permissions, including those inherited for domain Admins, which I believe is a member of the domain users group by default. Also, an additional group was created which allows read/write access to a single user attribute in the same OU. A non-administrative account, when added to this group, can read and write to the attribute, even though there is a deny on read all properties.
 
Can anyone tell me why this is working this way? It is contrary to what I thought I knew about Deny ACEs.
 
Thanks,
 
Josh 
 

Reply via email to