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.
Inheritance
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.
Effective Permissions
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.
Recommendations
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 (roger@banneretcs.com) is a security consultant. He is a CPA, a CISSP, a CEH, a CHFI, a TICSA, and an MCSE: Security.