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
