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.
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.
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. 🙂
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!
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”.
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.