How Owners Are Assigned and Changed

Every object, whether it is in Active Directory or in an NTFS volume, has an owner, usually the user who created the object. The owner has an implied right to allow or deny other users permission to use the object, and this right cannot be withdrawn. Among other permissions, owners can give other users permission to Change Permissions (WRITE_DAC). This permission, unlike the owner's inherent right, can be withdrawn.

By default, a new object's owner is the security principal identified as the default owner in the access token attached to the creating process. When an object is created, the SID stored in the access token's Owner field is copied to the security descriptor's Owner field. The default owner is normally an individual—the user who is currently logged on. The only exceptions occur when the user is a member of either the Administrators group or the Domain Admins group. In both cases, the Owner field in the user's access token contains the SID for the group, not the SID for the individual user account. The assumption is that administrative accounts are used only to administer the system and not for any individual purpose. As a result, objects created by one administrator can be managed by other administrators in the same group.

If an administrative group such as Administrators owns an object, all members of the group share the owner's inherent right to change permissions for the object. This fact frequently surprises administrators. For example, suppose Alice logs on to an account in the Administrators group, creates a file, and then denies Bob permission to modify it. Because Alice is a member of the Administrators group, the group owns the file. If Bob is also a member of the Administrators group, he automatically has Change Permissions authority and can give himself permission to modify the file—despite Alice's effort to prevent him from modifying it.

Owners of NTFS objects can allow another user to take ownership by giving that user Take Ownership permission. Owners of Active Directory objects can do the same thing by giving another user Modify Owner permission. (Both permissions map to the same access right, WRITE_OWNER. The only difference between the two permissions is what they are called in the user interface.) In addition, certain users can take ownership without having permission if they have been assigned the Take ownership of files or other objects (SeTakeOwnershipPrivilege) privilege. By default, this privilege is assigned only to the Administrators group.

When a user takes ownership of an object, the default owner SID in the user's access token is copied to the owner field of the object's security descriptor. If a member of the Administrators group takes ownership (or, for Active Directory object, a member of the Domain Admins group), the default owner is the group, not the individual user. For example, Figure 12.19 shows the Owner tab for a Folder object created by Bob, a member of the Administrators group.

Figure 12.19 Owner Tab for a Folder Object

Even though Bob created the folder, the Owner tab shows the object's current owner as Administrators. When the object was created, the SID in the Default Owner field of Bob's access token was placed in the Owner field of the object's security descriptor. Because Bob is a member of Administrators, his access token specified Administrators as the default owner, so Administrators became the owner of the object. Figure 12.19 also shows that Bob has the option to take ownership of the object himself. He can simply select his name in the Change owner to list and then click Apply . However, if Bob takes ownership, another member of Administrators can always retake ownership on behalf of the entire group. In fact, members of Administrators can always take ownership of any object, no matter who originally owned the object. This capability is built into the operating system and cannot be removed.

Note that the Owner tab shown in Figure 12.19 also includes a checkbox for Replace owner on all subcontainers and objects. If Bob takes ownership of this folder, he can take ownership of all subfolders and files at the same time. Bob has this option because he is a member of Administrators. Ordinary users have the option only if, in addition to having Take Ownership permission for the parent object, they also have Take Ownership permission for all child objects.

The Owner tab shown in Figure 12.19 has no option for giving ownership to another individual. If that were possible, an unscrupulous user could take ownership, do something wrong, and then cover his tracks by giving ownership to someone else. To prevent that from happening, the operating system does not support a give ownership operation at any levelnot in the user interface, not in application programming interfaces. It is true that a program can write new information in the Owner field of an objects security descriptor if the process has WRITE_OWNER access to the object, but WRITE_OWNER access permits the caller to change ownership only to the user SID in the callers access token or, if the user is a member of the Administrators group, to the Administrators SID. Thus it is never possible to give ownership of an object to another user. If you want to transfer ownership of an object, you must give another user permission to take ownership and then wait until the other user takes it.

You can track which users take ownership of objects by setting an audit control on take ownership events. For example, Figure 12.20 shows that auditing is enabled for all Take Ownership access to the top-level folder, Public$, and all subfolders and files. Whenever a user or group takes ownership of the parent object or any child object, the event is recorded in the security log.

Figure 12.20 Auditing tab for a Folder Object

For information about how to enable auditing, see Windows 2000 Server Help.