Security Considerations when Configuring Folder Redirection

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

When creating the redirection share, limit access to the share to only users that need access.

Because redirected folders contain personal information, such as documents and EFS certificates care should be taken to protect them as well as possible. In general:

  • Restrict the share to only users that need access. Create a security group for users that have redirected folders on a particular share, and limit access to only those users.

  • When creating the share, hide the share by putting a $ after the share name. This will hide the share from casual browsers; the share will not be visible in My Network Places.

  • Only give users the minimum amount of permissions needed. The permissions needed are shown in the tables below:

Table 12 NTFS Permissions for Folder Redirection Root Folder

User Account Minimum permissions required


Full Control, Subfolders And Files Only



Security group of users needing to put data on share.

List Folder/Read Data, Create Folders/Append Data - This Folder Only


No Permissions

Local System

Full Control, This Folder, Subfolders And Files

Table 13 Share level (SMB) Permissions for Folder Redirection Share

User Account Default Permissions Minimum permissions required


Full Control

No Permissions

Security group of users needing to put data on share.


Full Control,

Table 14 NTFS Permissions for Each Users Redirected Folder

User Account Default Permissions Minimum permissions required


Full Control, Owner Of Folder

Full Control, Owner Of Folder

Local System

Full Control

Full Control


No Permissions

No Permissions


No Permissions

No Permissions

Use at least Windows 2000 servers to host redirected file shares.

Because a users redirected files contain personal information which is copied to and from the client computer, and the server hosting the redirected folders, it is important to ensure that data is protected as it travels over the network.

The biggest potential threats to the privacy and integrity of a users data come from intercepting the data as it passes over the network, tampering with the data as it passes over the network, and spoofing the server hosting the users data.

Several features of Windows 2000 and Windows Server 2003 can help to secure a users data:

  • Kerberos - Kerberos is standard on all versions of Windows 2000 and Windows Server 2003, and ensures the highest level of security to network resources. While NTLM authenticates the client only, Kerberos authenticates the server and the client. When NTLM is used, the client doesn't know whether the server is valid this is particularly important if the client is exchanging personal files with the server, as is the case with Roaming Profiles. Kerberos provides better security than NTLM and is not available on Windows NT version 4.0 or earlier operating systems.

  • IPSec- The IP Security Protocol (IPSec) provides network-level authentication, data integrity, and encryption ensuring that roamed data is:

    • Safe from data modification while enroute.

    • Safe from interception, viewing, or copying.

    • Safe from being accessed by unauthenticated parties.

  • SMB Signing- The Server Message Block (SMB) authentication protocol supports message authentication, which prevents active message and "man-in-the-middle" attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by both the client and the server. In order to use SMB signing, you must either enable it or require it on both the SMB client and the SMB server. Note: SMB signing imposes a performance penalty; although it doesn't consume any more network bandwidth, it does use more CPU cycles on the client and server side.

Always use the NTFS Filesystem for volumes holding users data.

For the most secure configuration, configure servers hosting redirected files to use the NTFS File System. Unlike FAT, NTFS supports Discretionary access control lists (DACLs) and system access control lists (SACLs), which control who can perform operations on a file and what events will trigger logging of actions performed on a file.

Do not rely on EFS to encrypt users files when transmitted over the network

When using the Encrypting File System (EFS) to encrypt files on a remote server, encrypted data is not encrypted when in transit over the network, but only when stored on disk.

The exceptions to this are when your system includes Internet Protocol security (IPSec) or Web Distributed Authoring and Versioning (WebDAV). IPSec encrypts data while it is transported over a TCP/IP network. If the file is encrypted before being copied or moved to a WebDAV folder on a server, it will remain encrypted during the transmission and while it is stored on the server.

Encrypt the Offline Files cache

While the Offline Files cache is protected on NTFS partitions by ACLs by default, encrypting the cache enhances security on a local computer. By default, the cache on the local computer is not encrypted, so any encrypted files cached from the network will not be encrypted on the local computer. This may pose a security risk in some environments.

When encryption is enabled, all files in the Offline Files cache are encrypted. This includes existing files as well as files added later. The cached copy on the local computer is affected, but the associated network copy is not.

The cache can be encrypted in one of two ways:

  1. Via Group Policy, by enabling the Encrypt the Offline Files Cache setting, located at Computer Configuration\Administrative Templates\Network\Offline Files, in the Group Policy editor.

  2. Manually, by selecting Tools and then Folder Options in the command menu of Windows Explorer. Select the Offline Files tab, and check the Encrypt offline files to secure data checkbox.


Encryption of the Offline File cache is only available on Windows XP and above, it is not possible to encrypt the cache on Windows 2000 computers.

For more information about encrypting the Offline files cache, see How to Encrypt Offline Files at:

Let the system create folders for each user.

To ensure that Folder Redirection works optimally, create only the root share on the server, and let the system create the folders for each user. Folder Redirection will create a folder for the user with appropriate security.

If you must create folders for the users, ensure that you have the correct permissions set, also note that if pre-creating folders you must clear the "grant the user exclusive rights to XXX checkbox on the settings tab of the Folder Redirection page. If you don't clear this checkbox, then Folder Redirection will first check a pre-existing folder to ensure the user is the owner. If the folder is pre-created by the administrator, this check will fail and redirection will be aborted. Folder Redirection will then log an event in the Application event log:

Error: Folder Redirection

Event ID: 101

Event Message:

Failed to perform redirection of folder XXXX. The new directories for the redirected folder could not be created. The folder is configured to be redirected to \\server\share, the final expanded path was \\server\share\XXX .

The following error occurred:

This security ID may not be assigned as the owner of this object.

It is strongly recommended that you do not pre-create folders, and allow Folder Redirection to create the folder for the user.

Ensure correct permissions are set if redirecting to a users home directory.

Windows Server 2003 and Windows XP allow you to redirect a users My Documents folder to their home directory. When redirecting to the home directory, the default security checks are not made - ownership and the existing directory security are not checked and any existing permissions are not changed - it is assumed that the permissions on the users home directory are set appropriately.

If you are redirecting to a users home directory, be sure that the permissions on the users home directory are set appropriately for your organization.