SureSync supports the copying of NTFS file permissions between machines when a synchronization is performed. The copying of NTFS permissions is enabled by default on the root path level, all you have to do is configure your Rule to copy security. You can disable the copying of permissions on the Path Options tab for an individual root path but there is generally not a reason to do this.
For security copying to function, you must be synchronizing between two NTFS drives running Windows NT 4.0 or higher. The machines involved must be in the same domain or have a trust relationship established between multiple domains. Security can't be copied between FAT or FAT32 volumes; these file systems do not support security.
Synchronizing security between machines is extremely useful but the concept of copying security can be complex at first. Please be aware of the following important notes:
Permissions are only copied when a file is replaced or a file or directory is added unless you explicitly choose otherwise in your Rule by selecting the 'Copy folder security objects to existing folders' and 'Copy file security objects even if the file is not copied' options on the 'Copy Security' tab of the Rule in question. These options can have a negative performance impact on your synchronization. Please see the Copying Security without Copying Files topic for more information.
Obtaining and updating permissions is a slow process. SureSync does not compare existing permissions to see if they are different. A change in the file date would trigger a copy operation, which would then copy permissions.
When copying security, the user account which SureSync is running under needs to have permissions to access all of the files involved in the synchronization. The user account needs at minimum read access on the source and modify permissions on the destination(s).
If the SureSync user has add and delete permissions in the destination directory then the files and permissions can be copied even when the user does not have permissions to access individual files. SureSync will simply copy the file to a temporary file in the receiving directory, delete the old file, and rename the temporary file to the real file name. This means that the ACL on the receiving end for that file has been changed without the user actually having permission to change it. This can happen in the same way if the user copied manually, but it can happen on a much larger scale when done automatically.
If you are copying ownership or auditing, special permissions need to be granted to the SureSync user account. That account must have the 'Take ownership of files and other objects' right to copy ownership and the 'Manage auditing and security log' right to copy auditing information.
Due to the slow speed of security copying, you should only configure your jobs to copy the necessary security items. For example, you can copy permissions while not copying auditing and ownership. As a best practice, do not copy security objects which aren't needed to get the best performance.
Understanding Inheritance
The end result of security copying is not always what you're expecting. When SureSync copies security, the entire Access Control List (ACL) is copied to the destination machine(s). This includes a flag which determines if inheritance is turned on or off and any explicitly defined permissions on the file. The inheritance flag is what can make the end result of a security copy look different than what you expect.
For example, say you have a file named TestData.doc and it has the Administrators Group, a group named Sales, and a group named Marketing specified on the source via inheritance. That file also has domain\User1 and domain\User2 specified explicitly on that file. On the destination side the file has only the Administrators group applied from inheritance. When the file is copied with security to the destination machine the end result would be the Administrators group, domain\User1 and domain\User2 being set as the security on the destination file. The inheritance flag is copied as being on so the security is inherited down the tree on the destination to the file. The explicitly set permissions are also copied. In short, if most of your permissions are inherited from parent folders, you need to make the security on the source and destination root folders match to see the results you are expecting.
Issues with Multiple Domains
If your environment contains multiple domains, you should be aware of how SureSync will process security between the domains. The ACL which is copied to the destination machine includes the domain name associated with the account. For example, copying the user JohnDoe from Domain1 results in Domain1\JohnDoe being copied to the remote machine. If the destination machine is in the same domain or in a second domain with a trust relationship this will work fine. However, if you copy between machines that reside in different domains with no trust, you will see an unknown user listed on the Permissions tab of the folder or file.
In short, security copied from a source machine in one domain to a destination machine in another domain without a trust will be meaningless to the destination machine.
Issues with Local User Accounts
Local user accounts have a similar issue as domain accounts copied between domains without a trust. The machine's SID is included as part of the account information in the ACL. When a local account is copied to another machine, it will appear as an unknown user on the permissions tab of the destination folder or file.
Whenever ownership is successfully copied an entry is automatically logged into the Windows Security Event Log if your NT Security Logging is enabled. This can result in a lot of informational messages being placed in that log.
For security copying to function, you must be synchronizing between two NTFS drives running Windows NT 4.0 or higher. The machines involved must be in the same domain or have a trust relationship established between multiple domains. Security can't be copied between FAT or FAT32 volumes; these file systems do not support security.
Permissions are only copied when a file is replaced or a file or directory is added unless you explicitly choose otherwise in your Rule by selecting the 'Copy folder security objects to existing folders' and 'Copy file security objects even if the file is not copied' options on the 'Copy Security' tab of the Rule in question. These options can have a negative performance impact on your synchronization. Please see the