Edit Permissions with Subinacl

Subinacl is a powerful and useful command-line tool (available in the Microsoft Windows 2000 Server Resource Kit and the Microsoft Windows NT Server 4.0 Resource Kit) that lets you directly edit almost any security information—permissions, ownership, or auditing—on objects of all kinds. Not only can you use Subinacl to modify this information on files, directories, file shares, and printer shares, you can also use the tool to control permissions on registry keys, system services, and the Microsoft IIS metabase.

Viewing ACLs
Subinacl's strength is in its views of permissions and object security in general. ACLs govern permissions; each entry on an ACL is called an access control entry (ACE). If, for example, the permissions on a file in a domain give Full Control to administrators and to Mary and give No Access to Jack, the file's ACL contains three ACEs, which describe access for administrators, Mary, and Jack. To show a file's ACL, use the command

subinacl /verbose=1 /file c:testfile.txt /display

where testfile.txt is the filename. Figure 1 shows the output from this command. The output shows the filename, then the file owner's name. The primary group information typically is relevant only for POSIX applications. Next, the output shows the number of audit ACEs (i.e., aaces) and permission ACEs (i.e., perm. aces, or paces), then provides information about those ACEs. Win2K and NT let you specify in exacting terms what to audit—for example, whenever Mary fails to write to the file or whenever John fails to read the file. Subinacl expresses those terms as audit ACEs. Permission ACEs are the permissions that let users examine or modify a file or directory.

The example contains three permission ACEs because the ACL contains one ACE for administrators, one for Mary, and one for John. Each of the next three lines applies to a permission ACE. The Type value specifies whether the ACE is a Deny ACE or an Allow ACE: 0x1 represents a Deny ACE and 0x0 represents an Allow ACE. The AccessMask value defines the ACE's permissions. To decode the AccessMask value into specific permissions, you can examine the bits in the value or run the Subinacl command with the /verbose=2 option, which displays the permission as text, instead of the /verbose=1 option. Web Table 1 (http://www.winnetmag.com, InstantDoc ID 26362) lists the possible AccessMask values and the permissions they represent. These values represent the lowest-level permissions possible for files. Administrators tend to think in terms of more aggregate permissions, which comprise one or more low-level permissions. For example, the Read permission consists of the low-level permissions Read Data, Read Attributes, Read Extended Attributes, and Read Permissions. (To view low-level permissions through a file's ACL GUI, open Windows Explorer, open any NTFS file's or folder's Properties dialog box, and go to the Security tab. Click Advanced to open the Advanced Control Settings dialog box, click any ACE, then click View/Edit.)

Adding ACEs
You can use Subinacl to modify file and directory permissions. Subinacl can do everything that the Xcacls and Cacls tools can do; it can modify an existing ACE or create a new Allow or Deny ACE. The following command adds an ACE allowing the Read permission for a new user, Larry, in a company named Example.

subinacl /file c:testfile.txt /grant=examplelarry=R

In this command, the /file option tells Subinacl that the command will work on a file ACE. Other options are a system service (/service), a registry key (/keyreg or /subkeyreg), a set of folders and any subfolders within them (/subdirectories), a shared folder (/share), a cluster file share (/clustershare), a kernel object (/kernelobject), or the IIS metabase (/metabase). The c:testfile.txt parameter specifies the file the command will work on; you can use wildcards in the filename.

The /grant option tells Subinacl to create a new Allow ACE rather than create a new Deny ACE (/deny) or edit an existing ACE (/replace). The next parameter specifies the account name, and the final character specifies the permission to grant. Subinacl recognizes R (Read), F (full control), C (change, which is the same as modify), P (change permissions), O (take ownership), X (execute), E (read and execute), W (write), and D (delete). Notice that although Subinacl lets you view only low-level permissions, you can grant only high-level permissions. The sample parameter /grant=examplelarry=R instructs Subinacl to create an ACE that gives Read (R) permission to the account examplelarry.

To deny permissions, use the /deny command. For example, the following command prevents Larry from writing to the file.

subinacl /file c:testfile.txt /deny=examplelarry=W

You can specify multiple Allow ACEs or Deny ACEs. For example, to grant Read and Write access to Larry, simply tack the permission parameters together, as in examplelarry=RW. However, Subinacl can't handle both types of ACE for the same person—for example, you might want Larry to have Read access but not Write access, but you can't use a combination of Allow and Deny ACEs. (Xcacls and Cacls share this limitation, probably because all three tools first appeared in NT 4.0, in which the notion of Allow and Deny ACEs wasn't common. Perhaps the next crop of resource kit tools will fill this hole.)

You can use wildcards to change permissions on multiple files in a directory, but what if you want to make changes to an entire disk or a directory tree within a disk? In that case, use Subinacl's /subdirectories option. For example, suppose you want to grant Mary Full Control of all subfolders and files in C:testfolder. Type

subinacl /subdirectories c:testfolder* /grant=examplemary=F

Notice that you must include the slash and wildcard after c:testfolder, otherwise Subinacl will set the permission on the specified folder rather than on all files and subfolders in that folder.

Replacing, Deleting, and Cleaning Up SIDs
Suppose you have a bunch of files that only one employee—Laurie—can access. But Laurie leaves the company, and Janet takes her place. Janet needs access to all those files. Solving this problem is sometimes called re-ACLing because you typically must edit the files' ACLs one by one from the GUI—yuck. (I'm assuming that you own the files. If not, you'd need to take ownership—then wear out your mouse re-ACLing from the GUI.) Instead, you can use Subinacl to accomplish the task in just one line:

subinacl /file * /replace=examplelaurie=examplejanet

This command examines every ACE on every file in the current directory and replaces Laurie's SID with Janet's SID in every ACE that refers to Laurie. You can even use a replacement SID from another domain, as long as your domains trust one another.

Suppose that instead of substituting Janet's SID for Laurie's SID, you want to delete all the ACEs that refer to Laurie. You can use Subinacl's /revoke option. For example, to remove all traces of Laurie from a server's C: drive, type

subinacl /subdirectories c:* /revoke=examplelaurie

Subinacl also supports a nearly identical option, /suppresssid, which has an extra feature. With this switch, when the user account being revoked owns the file, Subinacl changes the file's owner to the Everyone group.

Have you ever looked at a file's permission list and seen not the usual user icon but an outline of a head with the name Account Unknown? That icon means that the account that held the permission has been deleted. For example, suppose that instead of disabling Laurie's user account, you deleted it. When you open the ACL GUI on a file that had an ACE for Laurie, Windows Explorer sees an ACE with a particular SID—the one from Laurie's old account—and asks the domain controller (DC), "Hey, I've got this SID ... what's the human name for this account?" (You might notice this behavior on a busy domain: When you open a file's Properties dialog box and go to the Security tab, at first all you see are SIDs, then after a few seconds you see the SIDs change to account names. The delay is the result of the time the server takes to ask the DC to look up the account names and the time the DC takes to respond.) Because Laurie's account is deleted, no name exists to go with the specified SID—thus the Account Unknown label. Over time, your organization's ACLs can become fraught with these leftovers. Subinacl can clean them up with the /cleandeletedsidsfrom option (which must specify the domain):

subinacl /subdirectories c:* /cleandeletedsidsfrom=example

More in Store
Subinacl is an extremely useful command—and it can do much more than what I've described so far. I'll cover more of the tool's abilities in my next column. But don't wait until then—use Subinacl's /help switch to find out for yourself. You can also use Subinacl's /testmode switch to try out the command in test mode:

subinacl /testmode /subdirectories c:testfolder* /grant=examplemary=F

This mode provides the same output as regular mode, but Subinacl doesn't make any changes to the disk.