My failed attempt to break aDDS using oWNER RIGHTS

By | April 22, 2008

Windows Server 2008 introduces a new security principal called OWNER RIGHTS.  It was introduced to fill a security and delegation loophole in previous versions of Windows whereby creators of objects potentially inherit more permissions than are intended.  For detailed information on how the new feature works in the context of AD, see Jorge’s blog entry here.

Having learned about OWNER RIGHTS, I had a thought that there was perhaps some potential for organisations to snooker themselves through over-enthusiastic (or downright stupid) delegation.  Taking an extreme example, was it possible to completely block administrator access to domain objects through willful abuse of OWNER RIGHTS?  Here’s how I approached the task.

First, I checked the current owner of the top of the domain tree (domainDNS object).  In my lab the domain is named DC=ad,DC=fisheagle,DC=net and the owner is set to the default Administrators group.  The only account in the Administrators group is the default Administrator account.

OR1

I then set explicit Deny entries for everything for the OWNER RIGHTS security principle and applied it to “This object and all descendant objects”.  An explicit Deny beats an Allow entry, so my thinking was that the effect would be to block the Administrator account from having any permissions on any objects in the domain.

OR2

After setting the security in this way, I tried to launch Active Directory Users and Computers (DSA.MSC) while logged in with the Administrator account and was encouraged to see the following error. 🙂

OR3

When the snap-in opened, it looked very much like my Administrator account was indeed denied access to anything in the domain.  If this were a live environment with no other admin accounts, I thought, there would be some sweaty palms right about now!

OR4

That’s when I tried a few things and found a workaround.  I ran the following DSACLS command while logged in with the Administrator account:

          dsacls “DC=ad,DC=fisheagle,DC=net” /takeOwnership

It applied successfully and the effect of this was that I could then immediately get back in to manage objects in the domain.  I hadn’t expected this to work, because one of the Deny entries I had set was for “Modify permissions”.  When I had a look at the security descriptor afterwards, I saw that the OWNER RIGHTS permissions had been changed.  The explicit Deny entries were still there, but it now applied to “Nothing” instead of “This object and all descendant objects”.

OR11

I don’t usually try to break things, but sometimes it helps when learning new product features.  In this case, it was reassuring to discover that there are ways to recover from badly implemented delegation using OWNER RIGHTS.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.