Backing up and Restoring NTFS Permissions on a Specified Volume
A set of NTFS permissions can be complicated for an administrator to deal with. The Microsoft utility SubInACL is a command-line tool that you can use to obtain security settings on files, registry keys, and services, and transfer this information from user to user, group to group and from domain to domain.
Here is a list of functions that you can perform with SubInACL:
- Display security information associated with files, registry keys, or services. This information includes owner, group, permission ACL (Access Control List), DACL (Discretionary ACL), and SACL (System ACL).
- Change the owner of an object.
- Replace the security information for one identifier (account, group, well-known SID (Security Identifier)) with that of another identifier.
- Migrate security information about objects. This is useful if you have reorganized a network's domains and need to migrate the security information for files from one domain to another.
You can download SubInACL from Microsoft website.
SubInACL is a powerful tool, so it would be a good idea to evaluate whether it is right for your situation before you actually use it on a live system. It is also advisable to use the /testmode parameter to test changes before bringing them into the live operating system.
SubInACL syntax
SUBINACL [/option...] /object_type /object_name [/action[=/parameter]...]
-
/option — There are 18 options to choose from and this document describes two. The /verbose option specifies how much information is to be displayed upon execution. Besides /noverbose, there are two levels of verbosity to choose from (/verbose=1 and /verbose=2). Level 2 (most information displayed) is the default.
-
/object_type — There are 13 types of Windows objects. Available objects are /service, /keyreg, /subkeyreg, /file, /subdirectories, /share, and /printer, as well as a few others. There is no default option for this parameter, and it is required in order to execute. /object_name — This is the name of the object, whose type is identified in the previous variable. For example, if it is a file object type, this would be the path to the file.
-
/action specifies what SubinACL is to do. The default action is to display the appropriate information for the specified object. Options include /display, /replace, /changedomain, /migratetodomain, /findsid, /grant, /deny, /revoke, /accesscheck, and /ifchangecontinue, among others.
To get more detailed information about SubInACL, type the following command:
SUBINACL /help /full
NTFS backup using SubInACL
If you are testing different possible NTFS security combinations for folders or objects, it would be a good thing to be able to restore the system to a known good state.
NTFSBKP is a batch script to back up the NTFS permissions on a folder or an entire drive. You can use this script to back up everything before you make any changes.
Source: Jerold Schulman International Inc. (JSI), in Atlanta, Ga.
The syntax for the script is:
NTFSBKP drive-or-folder destination-folder BKP|RST
BKP backs up NTFS security settings, in this case:
drive-or-folder is the name of the drive or folder whose permissions you are saving; to back up the ACL (Access Control List) for an entire drive, you must specify the drive name with a double slash (for example, drive C: appears as "C:\")
destination-folder is the folder where you are writing the backed-up permission information.
RST restores NTFS settings from a previous backup; in this case:
drive-or-folder is the name of the drive or folder whose permissions you are restoring; to restore the ACL (Access Control List) for an entire drive, you must specify the drive name with a double slash (for example, drive C: appears as "C:\")
destination-folder is the folder that contains the backed-up permission information
If you want to redirect the results to a file, add a redirect:
NTFSBKP drive-or-folder destination-folder BKP|RST > output.txt
The complete batch script listing appears in the Appendix of this guide.
Other notes about NTFSBKP
-
If you back up permissions on a folder then create new objects in that folder with non-inherited permissions, the restore process will not overwrite the non-inherited permissions.
-
You can use this script on multilingual systems without compatibility problems.
-
NTFSBKP stores security information by name, not by SID (Security Identifier). Suppose you have a folder with permissions explicitly set for User A. If you back up these folder permissions, and then you delete User A, the restore operation will not restore User A's permissions. However, if you create a new account (different SID) with the same name (User A), that account will be used as the permissions-holder for the restore operation on that folder. Maps the hash to the security descriptor's storage location within the $SDS data attribute.
-
If a match is not found for the map, NTFS assigns a new unique Security ID to the security descriptor and adds the new ID to the $SDS data attribute. When an entry references this security descriptor in the $SDS data attribute, NTFS adds appropriate entries to the $SDH and $SII indexes.
-
Writes the Security ID corresponding to the security descriptor in the $SDS attribute to the $STANDARD_INFORMATION attribute of the file or folder.
When NTFS searches $SDH, it looks for a match for both the hash and the security descriptor.
When an application attempts to open a file or a folder, the following happens:
- NTFS reads the internal Security ID for the file or folder from the MFT entry's $STANDARD_INFORMATION attribute.
- In the $Secure file, NTFS opens the $SII index and looks up the appropriate security descriptor that for that file or folder.
- If NTFS finds the security descriptor, it locates the Security ID entry in the SDS attribute.
- In the SDS attribute, the offset allows NTFS to read the security descriptor and complete the security check.
NTFS does not delete entries in the $Secure file, even if no file or directory on a volume references the entry. The fact that NTFS only adds these entries does not significantly decrease disk space because most volumes, even those used for long periods, have relatively few unique security descriptors.
Two Security Indexes
Entries in the $SDH index map the security descriptor hashes to the security descriptor's storage location within the $SDS data attribute.
$Secure:$SDH index entry layout
$SDH Entry Field | Description |
---|---|
DataOffest | The value of an offset variable indicates the location of a based variable within an area variable relative to the start of the area. |
DataLength | Size of data string. |
ReservedForZero | Padding with zeroes. |
IndexEntryLength | Size of index entry. |
IndexKeyLength | Size of index key. |
Flags | Arguments that that specify a type of security information. |
Pad | Padding to help with alignment of fields. |
KeyHash | Key: Hash of the security description |
KeySecurityId | Key: The SecurityID assigned to the descriptor |
Hash | Data: Hash of the security descriptor |
SecurityID | Data: The Security ID assigned to the descriptor |
Offset_in_SDS | Data: Offset of the security descriptor in $SDS data stream |
Size_in_SDS | Data: Size of the descriptor in $SDS data stream |
Reserved_II | Data: Padding - always Unicode "II" |
$Secure:$SII index entry layout
$SII Index Entry Field | Description |
---|---|
DataOffset | Offset to data. |
DataLength | Size of data. |
ReservedForZero | Padding with zeroes. |
IndexEntryLength | Size of Index Key. |
Flags | Arguments that that specify a type of security information. |
Pad | Padding to help with alignment of fields. |
KeySecurityId | Key: The Security ID assigned to the descriptor |
Hash | Data: Hash of the security descriptor |
SecurityID | Data: The Security ID assigned to the descriptor |
Offset_in_SDS | Data: Offset of the security descriptor in $SDS data stream |
Size_in_SDS | Data: Size of the descriptor in $SDS data stream |