Control ACEs and ACLs with Subinacl

In "Edit Permissions with Subinacl," October 2002, InstantDoc ID 26362, I introduced you to Subinacl, a great security and migration tool that's in the Microsoft Windows 2000 Server Resource Kit and the Microsoft Windows NT Server 4.0 Resource Kit. Although I usually cover resource kit tools in This Old Resource Kit, Subinacl does so much that I'd have to devote half a year's columns to the program if I covered it in that column. But this tool is so useful that not talking about it somewhere would be criminal, so I'm using the longer Inside Out columns to explain it.

In "Edit Permissions with Subinacl," you saw that Subinacl lets you create and delete permissions in an Xcacls-like fashion and swap SIDs to make migrations much easier. Subinacl also lets you change owners, change access control entries (ACEs), test access, and back up and restore ACLs.

Changing Owners
For years, many Windows NT security sources (including me) taught people that the trick to NTFS ownership is to take ownership but not to give ownership. This trick lets users protect their home directory from prying eyes. Users just need to take ownership of their home directory, then give themselves full control of the directory and lock out everyone else. When users take that approach, the only way an errant administrator can look at users' files is to take ownership of the file, then give himself or herself permission to peek. But that administrator would leave telltale fingerprints behind, because he or she would now own the file and couldn't change that ownership because the administrator can only take ownership, not give it.

I guess the sources said that you can take but not give ownership because the GUI supports only taking ownership. But under the hood, NT clearly supports both giving and taking ownership because Subinacl can do both. By using the Subinacl command with the /setowner parameter (i.e., option), you can change a file's owner. For example, to change the ownership of the testfile.txt file to Mary in a domain named ACME, you use the command

subinacl /file c:testfile.txt /setowner=acmemary

The /setowner parameter works with wildcards and the Subinacl command's /subdirectories option, so the /setowner parameter is quite useful for creating a home directory. You just create the directory, copy the user's files to it, then use Subinacl to give the user ownership of the directory.

Subinacl's ability to give as well as take ownership doesn't mean that you can't protect your home directory from the errant administrator. To protect your directory, you can enable auditing for the directory. I'd like to tell you that you can use Subinacl to set auditing ACEs, but oddly enough, you can't. Subinacl will clear all auditing ACEs if you use the /audit parameter in a command such as

subinacl /file testit.txt /audit

Subinacl doesn't include a command that sets auditing ACEs.

Changing ACEs
I gather from Subinacl's brief documentation that its main goal is to simplify migration (i.e., to move users from one domain to another). Although you can find far more complex and complete migration tools on the market, Subinacl doesn't do badly for a basically free tool.

Suppose that you find yourself the unfortunate newly appointed administrator of a multidomain mess—a company with 5000 employees and 40 NT 4.0 domains. Some domains are account domains; others are resource domains.

You convince your boss to let you reorganize the enterprise into a master domain and a few resource domains. You want to carry out this reorganization gradually so that you always have a fallback position. You start by creating a new Win2K master domain called ALLOFUS. Now you have to get all the user accounts in the enterprise on that server and build trust relationships to the old NT 4.0 domains that contain resources. Take, for example, the old ENGINEERING domain that contained both servers and user accounts. You need to duplicate the ENGINEERING domain's user accounts in the ALLOFUS domain, then build a trust relationship so that the ENGINEERING domain's servers trust the user accounts in the ALLOFUS domain.

The ENGINEERING domain's servers all have ACLs on their shares. For example, one ACL gives only Gordon permission to write to his folder. However, this ACL refers to Gordon's user account in the ENGINEERING domain, not his new account in ALLOFUS. So, to give Gordon access to his folder, you must visit every NTFS permission on all the servers in the ENGINEERING domain and replace the ACL that refers to Gordon's ENGINEERING account with one that refers to Gordon's ALLOFUS account. Hundreds of people had accounts in the ENGINEERING domain, so the task of changing the ACLs is going to be long and tedious—unless you use Subinacl's /changedomain and /migratetodomain options.

The idea is to run either of these options against a directory tree. Subinacl then examines every NTFS ACE, changing all the old domain SIDs to their corresponding SIDs in the new domain. For example, suppose that Mary has full-control access, William has read access, and Amy has modify permissions on the same folder. Although the ENGINEERING domain identifies Mary, William, and Amy by their SIDs, the domain also knows their usernames of Mary, William, and Amy, respectively. When the ENGINEERING domain finds the ACE that says, "The person with SID such-and-such has full control," Subinacl looks at the SID and sees that it's from the ENGINEERING domain. Subinacl then contacts the domain controller (DC) in the ENGINEERING domain and asks, "What's the username for SID such-and-such?" to which the DC responds, "Mary." Subinacl then contacts a DC in the ALLOFUS domain and asks, "Do you have any accounts with the username Mary?" Presuming that the new DC does, Subinacl then removes the old full-control ACE that refers to Mary's SID in the ENGINEERING domain and creates a new one that gives full control to the SID that corresponds to Mary's new account in the ALLOFUS domain. Subinacl performs this routine for every ACE that it can find on an entire directory structure, as long as a username on the new domain matches the username on the old domain.

The syntax for the /changedomain parameter is

subinacl [object] /changedomain=olddomainname=newdomainname

where object is the type and name of the item for which you want to change the ACEs and olddomainname and newdomainname are the names of the old and new domains, respectively. Recall from the October column that the object type can be a file (/file), subdirectory (/subdirectory), registry key (/keyreg), share (/share), or other value. So, for example, to examine every file and folder on the C drive and change any SIDs from the ENGINEERING domain to their corresponding SIDs on the ALLOFUS domain, you use the command

subinacl /subdirectories c:* /changedomain=engineering=allofus

The /migratedomain parameter has the same syntax and behavior as /changedomain, with one exception: Instead of replacing ACEs that refer to the old domain with ACEs that refer to the new domain, the /migratedomain option supplements ACEs that refer to the old domain with ACEs that refer to the new domain. In other words, if an old domain account has full-control access to a folder and you run the /changedomain option, the old domain account doesn't have access to that folder any more. Only the new domain account has full-control access. But if you run the /migratedomain option, both the old domain account and the new domain account have full-control access to the folder.

Testing Access
You can use Subinacl to make sure that the user accounts in a newly migrated master domain have access to resources in the old domains. The Subinacl command's /accesscheck parameter lets you test access. This parameter answers the question, "Can person X access object Y?"

The syntax for the /accesscheck parameter is

subinacl [object] /accesscheck=domainnameusername

where object is the type and name of the item to which you're checking access, domainname is the name of the user's domain, and username is the name of the user. So, for example, to determine whether Mary can access the C:testit.txt file from her account in the ALLOFUS domain, you run the command

subinacl /file c:testit.txt /accesscheck=allofusmary

Subinacl then asks you for Mary's password. How do you get your hands on Mary's password? Remember that the /accesscheck option is a postmigration test tool. If you used a program such as addusers.exe to migrate user accounts, you assigned a temporary password, which the users will change when they log on for the first time after the migration. But until Mary logs on, you'll know her new account's password.

Backing Up and Restoring ACLs
I saved one of the best options for last: ACL backup and restore. The Subinacl command's /noverbose and /output parameters let you take a snapshot of the ACL on an object or group of objects, and the /playfile option lets you restore the ACL. The syntax for the /output parameter is

subinacl /noverbose /output=filename subinacl command

where subinacl command is a set of Subinacl object types and actions—basically any Subinacl command that you've seen in this column or the October column. So, for example, to back up the NTFS ACLs on all the files in the root directory of the C drive to a file called C:aclbackups.txt, you use the command

subinacl /noverbose /output=c:aclbackups.txt /file c:*

If you run this command without the /output parameter, you'll see that it just reports on (but doesn't store) the ACLs. The /output parameter prompts Subinacl to store the output to a file.

To reapply a file's ACLs and wipe out any ACL changes that you've made since the backup, you use the /playfile option. Just invoke the Subinacl command with the /playfile parameter followed by the name of the backup file. For example, the command

subinacl /playfile c:aclbackups.txt

fully restores the NTFS ACLs on all the files in the C drive's root directory.

Don't Kick Yourself Later
The more I use Subinacl, the more I find use for it—and the more I kick myself for not having learned it earlier. Learn from my experience and start using Subinacl now.