Holy cow, I wrote a book!
A customer (via their customer liaison)
started by asking why they were seeing an unexpected
access control entry in the security descriptor of an object.
The ACEs on the parent grant access to
but the ACEs on the child object (which should simply have been
inherited from the parent) include an extra entry for Bob.
How did Bob get access to the child object?
When we view the details of the ACEs, it lists the Bob entry
as Inherited from parent.
But there is no Bob entry in the parent!
"Probably because Bob is the CREATOR OWNER."
Thanks for the explanation,
but even if Bob is the CREATOR OWNER,
how can we explain that the permission is inherited from the parent?
The permission is inherited from the parent because the parent has
specified the rights of the CREATOR OWNER,
and Bob is the creator/owner.
As part of the inheritance process, the rights of the
CREATOR OWNER get assigned to Bob.
CREATOR OWNER is not a real person.
It is a placeholder that
gets replaced with the actual creator/owner when the
object is created.
If Bob created the child object, then the permissions of
CREATOR OWNER will be given to Bob on the child object.
The CREATOR OWNER is not a live entry that dynamically
updates to match the current creator/owner.
It is a static entry that is assigned at the point of creation.
Changes to the owner in the future have no effect because
the identity has already been snapshotted.
(I think a less confusing name would have been simply OBJECT CREATOR,
since creation happens only once.)
(Note that there is a little extra weirdness here:
If the creator is a member of the Administrators group,
then the CREATOR OWNER rights get assigned to the
entire Administrators group instead of the specific user
who created it.
You can change this behavior by tweaking the
Default owner for objects created by members of the Administrators
The customer liaison conferred with the customer, and determined
that, at least in one of the cases they were studying,
Bob was not the original creator.
What actually happened was that at some point,
Bob was granted access to the
parent object and all its sub-objects.
Later, somebody went back to the parent object and told it to
revoke Bob's access to the parent object and all its sub-objects.
But "If we cancel the process fast enough, then we get the
strange behavior as originally described."
You asked for Bob's access to the parent object and all its
sub-objects to be revoked,
so the tool you used started a recursive tree walk from the parent
object looking for any objects that Bob has access to
and removing them.
But if you cancel the operation partway through, then that tool
didn't get a chance to finish the job,
and you obviously are left in a situation where Bob's access was
only partially revoked.
The customer liaison confirmed,
Yes, that's what happened.
It's nice of the customer liaison to confirm the diagnosis,
but it still baffles me that they were confused by this in the
To me this is one of those So what did you expect type of
You start an operation, then partway through, you cancel it,
and then you're surprised that the operation did not run to completion.