|
Executive Summary: The Windows DAC model and its "ownership is power" concept can threaten security and compliance for organizations that must ensure the continuous availability of company data. But in the classic DAC model, there's no way to block users from deleting objects they’ve created. Now a feature in Vista and Server 2008 can help you regain control of ownership. It's a security principal called Owner Rights (SID S-1-3-4). You can use this SID and other methods such as command-line tools, to control ownership and better manage your Windows resources. |
In Windows, ownership is power—a user who creates an object automatically becomes its owner and can set permissions at his or her discretion. This authorization model, known as discretionary access control (DAC), means an object owner can control access to a file, folder, registry key, or Active Directory (AD) object, affecting the availability of that data as well as your organization's efforts to comply with regulatory requirements.
Windows Vista and Windows Server 2008 offer administrators the ability to completely change the way Windows assigns permissions to object owners. If you regularly deal with administrative delegation on Active Directory (AD) and file servers, the Owner Rights SID in Vista and Server 2008 can help you reduce the powers of Windows object owners. I'll define Windows ownership in more detail, then discuss how you can use the Owner Rights SID and other methods to control ownership of your Windows resources.
Ownership As We Know It
Windows implicitly grants an object owner read permissions and change permissions on the object, which means that the owner is always allowed to access the object, regardless of what the object's ACL says. These implicit permissions don't show up in the object's ACL. Even if the object's ACL includes an explicit deny Access Control Entry (ACE) for the owner’s user account, the owner can still access the object’s ACL and override or simply remove the deny ACE. If you do detect explicit ACEs for the object owner in the object's ACL, these aren't related to the implicit owner permissions but to ownership inheritance.
Even though ownership is a powerful thing, the Windows ownership model is a bit crippled: this is because Windows doesn't implement a pure DAC model. Besides object owners, Windows also allows other accounts to control the permissions on Windows objects: the almighty Windows administrator accounts. These include the members of the local Administrators group, the domain-level Domain Admins and Enterprise Admins groups, and the Local System account. I will expand on this in the section on the managing ownership.
Windows typically assigns ownership to the user account of the object creator. If you create a new Microsoft Word document for example, your user account becomes the owner of the document. The owner of an object is represented by the owner’s user account SID in the object’s security descriptor. An object’s security descriptor is the Windows construct that holds an object’s access control and auditing settings, which also include the object’s ACL. You can see the object owner in the Windows GUI from the Owner tab in the Advanced Security settings of an object, which Figure 1 shows.
One notable exception to the rule of granting ownership to the user account of the object creator is when the creator is a member of the Administrators group. In that case, the group account rather than the user account is the owner of the object.
Assigning ownership to a group rather than to the individual who created the object isn't good from an accountability and traceability point of view. An admin could leverage it to hide his or her object creation tracks. That's why Windows XP and Windows Server 2003 include a configurable option to control such behavior. The setting is included in the Security Options Group Policy Object (GPO) and is called System objects: Default owner for objects created by members of the Administrators group. The allowed settings for this option are Administrators group or Object creator. This GPO setting affects the nodefaultadminowner (REG_DWORD) registry value located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa registry key. The supported values are 0 for Administrators group, or 1 for Object creator. When you change this setting, a Windows restart is required to effectively apply it. The default setting on XP is to grant ownership to the object creator. The default on Windows 2003 is to grant ownership to the Administrators group.
In Windows 2003, XP, and Win2K, the Administrators group is also the default owner of Windows files and folders. These include all files and folders that are created as part of the Windows installation process.
The New Owner Rights SID
The legacy Windows DAC model and its associated notion of ownership are often inappropriate for organizations that must ensure the continuous availability of company data. Often this availability is required for reasons of regulatory compliance. But in the classic DAC model, there's no way to block users from deleting objects they’ve created because owners control the permissions of the objects they created and can access an object’s ACL to remove a deny delete ACE. This is where a feature in Vista and Server 2008 comes to the rescue. Known in various beta versions of the OSs as Owner Access Restrictions (OAR), the enabling technology behind this feature is a security principal called Owner Rights (SID S-1-3-4). This technology lets Windows administrators override the classic Windows DAC and ownership model for specific resources and remove the object owner’s ability to manage the object’s permissions or to delete the object.
Like any other SID, the Owner Rights SID can be assigned object permissions. The Owner Rights SID and its associated ACEs are applied when an object is accessed by the owner of the object. If the object has explicit permissions for the Owner Rights SID, these Owner Rights permissions will override the implicit owner Read permissions and Modify permissions.
Owner Rights can further restrict what the owner can do with an object. For example, let’s say a system administrator creates an explicit Create files permission for the Owner Rights SID in the ACL of a folder named Alice’s Documents. Alice can copy her files into the folder, but after she drops them in, she isn’t allowed to change the files’ permissions—even though she’s the owner of the files. Figure 2 illustrates the ACL of the Alice’s Documents folder. Note the special ACE entry defined for the Owner Rights SID. To specify permissions for the Owner Rights SID, click Advanced in the ACL Editor, which lists the individual permissions you can allow or deny. Figure 3 shows the permission Create files / write data set to Allow for the Owner Rights SID for Alice’s Documents folder.
Owner Rights offers new administrative delegation opportunities for your Windows file servers and AD domain controllers (DCs). For example, you can leverage it to let users create files and folders on a file server without allowing them to delete these files and folders. In an AD environment, you can use it to let branch administrators create user or group accounts in their branch OUs without giving them the permission to modify the ACLs of these user and group accounts.
Server 2008 and Vista also include other important but less visible ownership changes. One change is that the default owner is no longer the Administrators group but the TrustedInstaller account. TrustedInstaller is a highly-privileged predefined account used by the Windows installer service. Vista also always assigns ownership to the user account of the object creator. In the case of an administrator, ownership is assigned to the administrator’s individual account, and not the Administrators group. Strangely, this isn’t true for Server 2008—and Microsoft didn’t include a nodefaultadminowner registry switch to reverse this behavior.
Managing Ownership
A Windows account can take ownership of an object if the account has the Take Ownership permission on the object or the Take ownership of files or other objects user right. A user granted Full Control permission on an object is also explicitly granted Take Ownership permission.
The Take ownership user right is given by default only to members of the Administrators group so they can take ownership of an object in the absence of explicit administrator object access permissions. It’s typically used to bypass permissions when someone has intentionally or accidentally removed an administrator’s access permissions. It also ensures that files can be recovered by an administrator if a user leaves the company. It’s a highly sensitive user right that you shouldn’t give to ordinary users or services.
Note that the actual change of ownership—whether you leverage the Take Ownership permission or user right—is instigated by the future owner of the object. Typically the actual owner of the object gives another user (the future owner) the Take Ownership permission on an object by using the advanced view of the object’s ACL editor. You can use the same interface to seize ownership of an object after you’ve been give the Take Ownership permission. For example, to transfer ownership of a folder named New Folder to the Alice user account, you select Edit in the ACL editor’s Advanced view of the Owner tab, select the Alice account as the new owner, which Figure 4 shows, then click Apply.
If an administrator wants to assign ownership directly to other account users, the admin must have not only the Take Ownership permission or user right but also the Restore files and directories user right. This right is given by default to the Administrators, Backup Operators, and Server Operator groups. Administrators can use this ability if they don’t trust their users to actually seize ownership of an object. This direct assignment of ownership from the Windows GUI is possible in Server 2008, Vista, Windows 2003, and XP, but not in Win2K (with the exception of an administrator assigning ownership to the Administrators group). On Win2K you can however use freeware command-line tools such as chown to do this.
You can also change an object’s ownership from the command line using tools that are included in the Windows OS: for example, icacls or takeown. Icacls (the latest version of the cacls tool) transfers ownership to any account (provided this account and the account you use to transfer ownership have sufficient privileges). Takeown can only be used to seize ownership for your personal account or the Administrators group (If you are a member of this group). In Server 2008 and Vista, you must run these commands from an elevated administrator-level command prompt (because of User Account Control—UAC) to make the commands work properly. Figure 5 shows the icacls and takeown syntax for transferring and seizing ownership on a file named test.txt.
Ownership Inheritance
Inheritance is a mechanism in the Windows authorization model that lets container objects pass access control information to their child objects. For administrators, ACL inheritance simplifies access control management: An administrator can set the ACL on a parent object and, if inheritance is enabled, not need to set ACLs on each individual child object, because the Access Control Entries (ACEs) are automatically acquired by the child objects.
Windows offers two special predefined SIDs for facilitating the inheritance of ownership permissions between parent and child objects: Creator Owner (S-1-3-0) and Creator Group (S-1-3-1). They both act as placeholders in the ACL of a container object for setting ownership permissions on newly created child objects.
• An ACE granted to Creator Owner in the ACL of a container object is replaced in the ACL of newly created objects by an ACE for the object creator’s SID.
• An ACE granted to Creator Group in the ACL of a container object is replaced in the ACL of newly created objects by an ACE for the object creator’s primary group SID. The primary group SID is another ownership-related item that’s stored in an object’s security descriptor and that refers to the object owner’s primary group. Windows uses the concept of a primary group for compatibility with POSIX and Mac OS.
You can leverage the Creator Owner SID to set permissions on folders that contain public information. In such a scenario, you typically give a user the ability to read the information and only allow the user to edit or delete certain information objects (typically the information the user created in the folder). You do this by granting Domain Users the Read permission and the Create files permission and granting the Creator Owner the Modify permission. For example, if Alice and Bob both have normal user access to a folder named Public Info and this folder’s ACL also has a modify ACE for the Creator Owner SID, Bob could read all files created by Alice, but only Alice could edit and delete the files she created —and the other way around.
Windows also leverages Creator Owner for setting default permissions on files and folders. For example, the ACL of your C drive contains a Full Control ACE for Creator Owner, which Figure 6 shows. This use of Creator Owner explains why explicit ACEs for your owner’s user account show up in the ACL of newly created objects. Also remember the point I made earlier on in this article that these explicit ACEs have nothing to do with the implicit owner permissions.
You can leverage the Creator Group SID for setting permissions on folders that contain information from the different departments of your organization. In this scenario, you typically allow all users to read existing files and add new objects, and allow only users from the same department to edit or delete objects created by the members of that department.
To set this up, you first create a special group for every department in your company. You then assign the respective group to all users of a department as their primary group by using the Active Directory Users and Computers (ADUC) Microsoft Management Console (MMC) snap-in. At the Member Of tab of the user properties, which Figure 7 shows for a user named Joe, select the group from the user’s list of groups, then click Set Primary Group to assign it as the user’s primary group. In this case, Joe’s primary group is now Sales Department.
Finally, you need to set specific permissions on your file server’s information folders. You again grant Domain Users Read permissions and Create files permissions and grant the Creator Group Modify permissions. As a result, whenever our user, Joe, creates a new file, the Sales Department group gets the permissions granted to the Creator Owner group, granting all users from the Sales Department (including Joe) Modify permissions on the file, but restricting other domain users to normal Read permissions.
Critical Information for Administrative Delegation
Ownership is certainly not the easiest concept to understand within the Windows security model. But given the new SID in Server 2008 and Vista, and careful consideration of the concepts behind ownership, you’ll be better able to take control of it.