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=
domainname\username
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=allofus\mary
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.