Re: Unable to prevent OU deletion by Domain Admins?

From: ptwilliams (ptw2001_at_hotmail.com)
Date: 11/03/04 

Date: Wed, 3 Nov 2004 20:53:53 -0000

A couple of points if I may...

> Not sure what you mean by your "other post," but what I'm pointing out is
> that the behaviour is improper.

I made another post earlier on; perhaps you cannot see this -I've been
seeing this behaviour when posting through the communities website,
sometimes the posts don't show up when I access these groups from a
newsreader...

> It is even worse when Microsoft's own guidelines for parsing ACLs states
> that DENY ACLs trump any allow ACLs

That's not entirely accurate. Deny permissions take precedence over allow
permissions with one exception: inherited deny permissions don't take
precedence over non-inherited allow permissions.

The SRM (Security Reference Monitor) evaluates an access request by parsing
the list of permission entries in the DACL. It does this starting at the
top of the list and working its way down until it finds enough entries to
allow or deny permission. Which means that there is an order to what the
effective permission are. This is as follows:

Non-inherited deny entries, non-inherited allow entries, inherited deny
entries and inherited allow entries.

> If you explicitly remove permission inheritance on an object, then
> explicitly set DENY ACLs on that object for a group, then the denied user
> or group should not be able to perform the action that the ACL forbids.
> That's how ACLs work, or at least how they are supposed to work.

The problem here is that the Delete Subtree permission isn't inherited
per-se. That is, this is a folder (container) permission not a file (child)
permission. Which means even if inheritance is not enabled, this permission
on the parent container is still in effect. If you consider what I've said
above, the deny permission set lower down doesn't come into it because the
right at a higher level is enforced.

However, bear in mind that the delete subtree permission goes hand-in-hand
with the delete permission on the root level of the subtree.

D
|
-- OU
      |
      -- obj
      |
      -- obj

You could modify the default domain admins permissions so that they no
longer have the Delete subtree permission. Or you could remove the delete
permission from the domain level, and reintroduce it lower down.

Delete Subfolders, and delete at the D level will delete all underneath. I
believe this was implemented for POSIX compatibility.

(Hopefully I've got all that right ;-) 

-- 
Paul Williams
http://www.msresource.net
http://forums.msresource.net
______________________________________
"Josh" <joshuabrown@gmail.com> wrote in message 
news:e7d88c81.0411030934.7977ae61@posting.google.com...
Paul,
Not sure what you mean by your "other post," but what I'm pointing out
is that the behavior is improper.  If you explicitly remove permission
inheritance on an object, then explicitly set DENY ACLs on that object
for a group, then the denied user or group should not be able to
perform the action that the ACL forbids.  That's how ACLs work, or at
least how they are supposed to work.  It is even worse when
Microsoft's own guidelines for parsing ACLs states that DENY ACLs
trump any allow ACLs; when you look at the ACLs on an object, it even
appears that you have accomplished what you want to
accomplish--protecting the object from deletion.
I understand that domain admins have the delete and delete subtree
rights at the domain level.  But think of this in terms of files and
folders:  I have a folder where Domain Users have Full control rights.
 Inside that folder I have a file, and onto that file I place a Deny
Delete ACL for Domain Users (or even for just a single user who is a
member of the Domain Users group).  That ACL works as advertised, and
will deny that user/users the ability to delete the file.  There
shouldn't be anything about a group--even a builtin group--that
overrides local security settings like that.
This isn't about trusting an admin.  It's about the possibility that
something could be accidentally deleted (everyone makes mistakes,
especially during after hours recovery sessions, etc.).  We should be
able to protect against that possibility, and Microsoft is removing
control from our hands and ignoring explicit security settings in a
very odd way.
"ptwilliams" <ptw2001@hotmail.com> wrote in message 
news:<O6ioUWRwEHA.1396@tk2msftngp13.phx.gbl>...
> As I said in my other post, this behaviour occurs because the domain 
> admins
> group has the delete and delete subtree permission at the domain
> level -which overrides lower-level container object permissions -just like
> NTFS file and folder permissions.
>
> Trust is the issue here.  And if anybody make the mistake of deleting an 
> OU
> twice...well....
>
> Where's the change control processes, eh??  <g>
>
> -- 
>
> Paul Williams
>
> http://www.msresource.net
> http://forums.msresource.net
> ______________________________________
> "Josh" <joshuabrown@gmail.com> wrote in message
> news:e7d88c81.0411020810.12f124a3@posting.google.com...
> Mark,
>
> Thanks, but that doesn't really answer my question.  We have a
> situation where we want to prevent a particular OU from being
> accidentally deleted.  Trusting our domain admins doesn't prevent them
> from making very human mistakes.  This looks like a bug to me--why can
> I not create an OU that denies deletion rights to domain admins, when
> the ACL appears that is should do precisely that?
>
> I challenge anyone to try what I have outlined above and get it to
> properly deny deletion rights.  If this right is not working properly,
> how am I to have confidence in any of our settings?  Deny rights is as
> important as allow rights, if not more so, since deny rights are
> supposed to trump allow rights.
>
> Josh
>
> "Mark Renoden [MSFT]" <markreno@online.microsoft.com> wrote in message
> news:<uP56r$FwEHA.1988@TK2MSFTNGP12.phx.gbl>...
> > Hi Josh
> >
> > It's better practice to give rights to a group of users rather than take
> > them away from Domain Admins.  You should never alter the rights of a
> > builtin group or user.  You're better off creating a group for the 
> > purpose
> > of administering OU's, delegating permissions to this group and keeping
> > your
> > Domain Admins group to a very select few that can be trusted.
> >
> > Kind regards
> > -- 
> > Mark Renoden [MSFT]
> > Windows Platform Support Team
> > Email: markreno@online.microsoft.com
> >
> > Please note you'll need to strip ".online" from my email address to 
> > email
> > me; I'll post a response back to the group.
> >
> > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> >
> > "Josh" <joshuabrown@gmail.com> wrote in message
> > news:e7d88c81.0411011409.c1d654b@posting.google.com...
> > >I am trying (unsuccessfully) to prevent accidental deletion of several
> > > OUs by our domain admins.  For testing purposes, I have done this:
> > >
> > > 1) Create new OU, removed inheritance of permissions.
> > > 2) Removed all groups from the permissions
> > > 3) Added Domain Admins with Full Control
> > > 4) Explicity set Deny rights for Domain Admins for Delete, Delete
> > > Subtree, and Delete Organizational Object.
> > >
> > > Create new user, add user to Domain Admins.  Log in with user, and the
> > > OU can be deleted without warning.
> > >
> > > The only way I have gotten this to work is by creating a user in the
> > > OU that I want to protect, and setting Deny All rights for the Domain
> > > Admins group on that user.  That prevents Domain Admins from deleting
> > > the parent OU, but it is a pretty bad solution...and it doesn't
> > > explain why the Domain Admins can delete the OU when all relevant
> > > deletion ACLs are set to Deny.
> > >
> > > Any thoughts?

Relevant Pages

  • Re: Unable to prevent OU deletion by Domain Admins?
    ... This posting is provided "AS IS" with no warranties, and confers no rights. ... >>>> It is even worse when Microsoft's own guidelines for parsing ACLs ... >>>> that DENY ACLs trump any allow ACLs ... >>> the list of permission entries in the DACL. ...
    (microsoft.public.win2000.active_directory)
  • Re: Unable to prevent OU deletion by Domain Admins?
    ... That's how ACLs work, or at ... Microsoft's own guidelines for parsing ACLs states that DENY ACLs ... I understand that domain admins have the delete and delete subtree ... I have a folder where Domain Users have Full control rights. ...
    (microsoft.public.win2000.active_directory)
  • Re: Unable to prevent OU deletion by Domain Admins?
    ... >> that DENY ACLs trump any allow ACLs ... Deny permissions take precedence over allow ... > the list of permission entries in the DACL. ... > You could modify the default domain admins permissions so that they no ...
    (microsoft.public.win2000.active_directory)
  • Re: Unable to prevent OU deletion by Domain Admins?
    ... What isn't fine is making it appear as if an ACL can be set a certain ... Deny permissions take precedence over allow ... >> the list of permission entries in the DACL. ... >> You could modify the default domain admins permissions so that they no ...
    (microsoft.public.win2000.active_directory)
  • Re: Joining Computers to Domain
    ... >>immediately indicate if you have a DENY somewhere. ... >>> is some permission that is blocking it. ... >>> Our problem is with student admins. ... >>> add computers to the domain. ...
    (microsoft.public.windows.group_policy)