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=acme\mary
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.