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=example\larry=R instructs Subinacl to create an ACE that gives Read (R) permission to the account example\larry.
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=example\larry=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 example\larry=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=example\mary=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=example\janet
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=example\laurie
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=example\mary=F
This mode provides the same output as regular mode, but Subinacl doesn't make any changes to the disk.
End of Article
Bob Sanderman May 12, 2004