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
