Cut through the complexity with this field guide to Windows object access
Windows controls how users access files and folders through a detailed and complex system of permissions. In fact, Windows has one of the most granular object-access control mechanisms of any popular OS. Files and folders have at least 14 NTFS permissions that can be allowed or denied—and audited. You can set these permissions on a per file or folder and per user or group basis. You can also set permission inheritance on a per file or folder and per user or group basis. It's easy to get bogged down in a quagmire of permissions complexity. Here's a quick guide to how Windows file and folder permissions work and how to use them more effectively.
Object Access Basics
A user never directly "touches" any Windows object. All object access is done through programs (e.g., Windows Explorer, Microsoft Office) or processes. A program accessing a local resource on behalf of the user is called impersonation . A program accessing a remote resource is called delegation.
After a user logs on, the user's own System Identifier (SID) and group SIDs are collected by the lsass.exe process to create the user's security access token. Other information is added to the security access token, including the user rights assignments (also called user privileges), the user's session ID (unique for every session), a rights mask detailing the type of access being requested, and other information. You can see the user rights assignments by typing
When a program accesses a protected resource on behalf of a user, the Windows security reference monitor asks the program for the user's security access token. The security reference monitor then examines the token to determine the user's effective permissions and allows or denies the operation the user has requested. (I'll describe how effective permissions are arrived at in more detail in a moment.)
Every protected object in Windows—including files, folders, shares, printers, and registry keys—has security permissions. Any Windows folder can be shared to allow remote access. You can set Share permissions on any folder or printer object in Windows, but the permission applies only when the object is accessed over a network share. Folder Share permissions are Full Control, Change, and Read.
Security principals given Full Control of an object can do nearly anything they want to the object. They can delete, rename, copy, move, and modify the object. Full Control also allows a user to change the object's Share permissions and take ownership of the object (if the user doesn't already have ownership and the Take Ownership privilege). This means that any user with Full Control can remove other people's—including the administrator's—permissions, (although the administrator can always reassume ownership and reassign permissions). The ability to change permissions is actually a requirement of any discretionary access control—DAC—OS such as Windows.
In most cases, the main access that nonadministrative users need to a share is Change permission. Change permission allows a user to add, delete, modify, and rename any resource in the covered folder. The Read permission allows a user to view, copy, rename, and print the object. A user with Read permission can often copy the object to a new location, and in the new location, the user has Full Control permission.
If the Windows file system is NTFS (rather than FAT), all files, folders, registry keys, services, and many other objects have NTFS permissions. NTFS permissions apply whether the object is accessed remotely or locally. To view or modify a file or folder's NTFS permissions, simply right-click the object, choose Properties, then go to the Security tab.
Table 1 shows 7 summary NTFS permissions. These summary permissions are created by various combinations of 14 more-granular permissions, which Table 2 shows. You can view the more-granular permissions by clicking Advanced on the Security tab to open the Advanced Security Settings dialog box for the object, then clicking Edit on the Permissions tab. Reviewing the more-granular permissions of an object, even though it takes more effort, is a good habit to get into, especially for objects that need heightened security. The summary permissions sometimes don't accurately reflect the more-granular permission settings. For example, I've seen summary Read permission displayed when the user really had Read & Execute permission.
Similar to Full Control Share permission, Full Control NTFS permission gives a lot of authority to the holder. Nonadministrative users often have Full Control permission to their home directory and other files and folders. As I mentioned earlier, this permission level allows the holder to change the file permissions and take ownership, if they so choose. Instead of giving users Full Control permission, consider giving only Modify permission. (Then, if the user is the file owner, you can manually take away his or her ability to change permissions, if necessary.)
Note that NTFS permissions are technically known as discretionary ACL (DACL) permissions. Auditing permissions are known as system ACL (SACL) permissions. Most NTFS-protected objects have both.
The Effect of Windows Trusts
By default, all domains in Windows 2000 and later forests have a two-way transitive trust to all other domains in the forest. When a domain trusts another domain, all users in the trusted domain have the same security permissions in the trusting domain as the Everyone group and Authenticated Users group in the trusting domain. Because many permissions in any given domain are assigned to both those groups by default, a trust implicitly gives a lot of permissions that would otherwise not be granted. Be aware that unless you use a selective trust, any permission you give to the Everyone group or Authenticated Users group is also granted to every other user throughout the forest.
Checking Permissions from the Command Line
Administrators often use command-line tools such as subinacl.exe, xacls.exe, and cacls.exe when checking NTFS permissions. Subinacl is part of the Windows Server 2003 Resource Kit Tools, or you can download it separately at http://www.microsoft.com/downloads/details.aspx?familyid=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&displaylang=en. You can use Subinacl on Windows 2000 and later to view and modify NTFS permissions on files, folders, objects, registry keys, and services. Most importantly, you can use Subinacl to copy the permissions of one user, group, or object and apply them to another user, group, or object in the same or another domain. For example, if you move a user from one domain to another, Windows creates a new user account; any previously existing SIDs or permissions attached to the original user are gone. You can use Subinacl to copy permissions to the new user account to make them identical. Xcacls, which functions similarly to Subinacl, is available in the Windows 2000 Server Resource Kits, or you can download it separately at http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/xcacls-o.asp.
Cacls, described in the Microsoft article "Undocumented CACLS: Group Permissions Capabilities" (http://support.microsoft.com/?kbid=162786) is an older tool that has been present in Windows since Windows NT. Cacls isn't as useful as Subinacl or Xacls, but it's always available on a Windows system. You can use Cacls to view or modify files or permissions by user or group. You can't use it to create the more-granular NTFS permissions. Currently, Cacls is limited to working with permissions called No Access, Read, Change, and Full Control, which translate into NTFS permissions, not Share permissions. Also, Cacls's Read permission translates to the NTFS Read & Execute permission.
By default, all files, folders, and registry keys inherit their permissions from their parent container. You can turn inheritance off or on for individual files, folders, or registry keys and for individual users or groups. As Figure 1 shows, the Apply To field on the Permissions tab of the Advanced Security Settings dialog box shows whether a particular permission is confined to the current container or whether it flows down to subfolders and files. An administrator can set a permission (on a per-user basis) that does or doesn't flow downward. In this example, the Everyone group has Read & Execute permission to the current folder, and the permission doesn't flow down.
If a file or folder is inheriting most of its permissions but also has explicitly set permissions, the explicitly set permissions will always override the inherited permissions. For example, you can give a user Full Control-Deny permission at the root of a particular drive volume and specify that the permission flow down to all files and folders on the drive. Then, for any file or folder on the drive, you can give a user access that overrides the Full Control-Deny inherited setting.
The Windows security reference monitor calculates the effective permissions of users (i.e., their real permissions in practice) by using several factors. As I mentioned above, the security reference monitor first collects the user's individual account and all the groups to which he or she belongs and assembles all the permissions assigned to all the user and group SIDs. If a Deny permission is set at the same level as an Allow permission, the Deny typically wins. If a Full Control-Deny wins, the user typically can't access the object.
By default, when NTFS and Share permissions are involved (i.e., the user is connecting to the resource over a network share), the security reference monitor must collect all the Share and NTFS permissions. A user's effective permissions, then, are the set of permissions granted by both the Share and NTFS permissions.
For example, suppose a user ends up with Read and Change Share permissions and Read and Modify NTFS permissions. The effective permissions are the most restrictive set of permissions. In this case, the permissions are nearly identical. The effective permissions are Read and Change/Modify. Many administrators mistakenly believe the effective permissions are Read only because of poor, overly simplified examples or past instructions.
In Windows XP and later, Microsoft has included an Effective Permissions tab in the Advanced Security Settings dialog box, which Figure 2 shows. Unfortunately, the Effective Permissions tab reflects only NTFS permissions. The effects of Share permissions, action-based groups of which the user isn't a member, and other factors such as the Encrypting File System (EFS) aren't considered. If EFS is enabled on a folder or file, a user who otherwise has the appropriate NTFS and Share permissions to the object can be prevented from accessing it if they don't also have EFS access to the file or folder.
Now that you have a better understanding of Windows permissions, let me leave you with some file and folder recommendations:
- Give Full Control permission sparingly to nonadministrative users. Consider giving Modify permission instead. Most of the time, this approach will give users all the permission they need, without giving them the ability to change permission or take ownership.
- Use the Everyone group sparingly; instead, use the Authenticated Users (or Users) group or a custom, more limited group. (The Authenticated Users group doesn't contain the Guest or null session user, both important omissions.)
- Frequently, network administrators are asked to add guest accounts for visiting users (e.g., onsite consultants, contractors, external programmers). But adding a guest as a regular user often gives far more access than is necessary. Create and use a group that is highly restricted by default (i.e., Full Control-Deny permission to root directories), then explicitly allow permission only to the files and folders the guest account needs. The explicitly set permissions will override the inherited permissions, giving guest users just the permissions they need to do their job, and no more.
- Be cautious about denying anything to the Everyone or Users groups because administrators belong to those groups, too.
- When trusting other domains, consider using a one-way or selective trust to limit the permissions given to the trusting domain's users.
- Periodically audit your NTFS and Share permissions to verify that permissions are appropriately configured to the fewest possible privileges.
With these recommendations to guide you and with the tables outlining each permission in hand for easy reference, you're ready to navigate the jungle of file system access. You'll be able to set permissions on files and folders and users and groups with confidence.
Roger A. Grimes (firstname.lastname@example.org) is a security consultant. He is a CPA, a CISSP, a CEH, a CHFI, a TICSA, and an MCSE: Security.