RE: [ActiveDir] Deny permissions in AD

[Grillenmeier, Guido]

... because there could be other explicit rights on the objects further below in the tree that do allow to view all kind of objects and properties.  For example: Authenticated Users.  Unless you've removed these rights, it is likely that if you search for objects in you the OU (if it has sub-OUs), you'll still be able to find many and view their properties...   /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitri Gavrilov Sent: Montag, 26. Juni 2006 21:49 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Deny permissions in AD The cleanest way is not to deny permissions but to revoke permissions. In other words, you should remove ACEs that are granting access that you don’t need.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Coffman Sent: Monday, June 26, 2006 11:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Deny permissions in AD   I think you are correct.   I started looking into this immediately after posting.   Looks like domain admins, Self, and account operators have hard-coded rights to the object.   This would be applied before the inherited deny ACE.   Thanks!   Josh Joshua M. Coffman [EMAIL PROTECTED] Cell:(970) 402-3457 Subject: RE: [ActiveDir] Deny permissions in AD Date: Mon, 26 Jun 2006 13:50:13 -0400 From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org 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: ActiveDir@mail.activedir.org 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