FAQ: Shadow Folders with UNC Paths / Windows Server 2003

mskrobul · Post by **mskrobul** » Mon Feb 16, 2004 10:58 am

If a folder is shadowed on a machine other than the Vault Server machine, it usually won't work with the default settings because of permission problems to network resources. Vault Shadow folders actually run as a .Net Web Service on the same IIS installation as the Vault server. Default permissions do not allow the Shadow Folder web service access to other machines on your network.

This can be fixed by using ASP.Net process identity impersonation for the Vault Shadow Folder service, which causes the shadow folder service to run under a custom .Net account on your Domain, instead of the default ASP.Net process account. You can then give the DOMAIN custom .Net account access to the folder on a networked machine. Note, due to security constraints of ASP.Net impersontation, you cannot use "mirrored" accounts to have one machine access another. The same account must be used for both the Vault server and the Shadow Folder destination, thus the need for a Domain account.

Note that the following steps should be performed before making any shadow folder associations. If you change the identity impersonation configuration after you make a shadow folder association, you must redo the shadow folder association in the Admin Tool.

Determine the Shadow Folder Impersonation .Net Domain Account -
If you do not already have a domain account available for use with Shadow Folder impersonation, create a new DOMAIN Account. A domain account is necessary since UNC resources are not accesible to non-Domain based accounts.

To Create an account:
From the Computer's User Manager, create an account for the Domain - for example, "DOMAIN\VaultShadowFolderAccount".
- Make sure to use a strong password for the account.
- Clear the User must change password at next logon option.
- Select the Password never expires option.
- Add DOMAIN\VaultShadowFolderAccount to the Domain Users group. This will give the Custom .Net account sufficient permissions in order for Shadow Folders to operate correctly.
- Finally if the Vault server is running on IIS 6.0 (Windows Server 2003), add the DOMAIN\VaultShadowFolderAccount to the IIS_WPG group (which has been replaced with IIS_IUSRS group in later versions of IIS). This will give the Custom .Net account additional permissions required in Windows Server 2003 / IIS 6.0 to correctly switch identies.
Verify Minimum Privileges for ASP.Net-
This procedure assigns the minimum set of privileges necessary to run ASP.Net. Note, if you are configuring a Windows Server 2003, you may want to substitute Local Security Policies if the Vault server is not on a domain, or the destination shadow folders will not use UNC paths ( shadow to local disk only ).

To verify minimum privileges :
1. From the Administrative Tools programs group, start the Domain Security Policy tool.
2. Expand Local Policies, and then select User Rights Assignment. A list of privileges is displayed in the right pane.
3. Verify the following privileges have been granted to the domain account:
  - Access this computer from the network
  - Log on as a batch job.
  - Log on as a service
  - (Allow) Log on Locally - if the Domain Users Group is not already in the Access Control List.
  Note - To assign a privilege to an account, double-click the privilege, and then click Add to select the required account.
4. Close the tool.
Create Local File Structure -
Log on to the same machine hosting the Vault Server. Use the Vault Shadow Folder Domain account. This will ensure that all normal folders are created for that user's %APPDATA% setting (ie. C:\Documents and Settings\VaultShadowFolderAccount\Application Data).

Note, the .Net Domain account must have security permissions permission to both the Vault Server machine (see below) as well as on the networked machine's UNC resource.

Once you have logged in as the impersonated user, you can safely logout and finish Shadow Folder configuration.
Security permissions must be placed on folders for the ASP.Net impersonated account access.

The following permissions must be added to the permissions on the following folders for the impersonated account:
- FULL CONTROL - %WINDIR%\Microsoft.NET\Framework\<version>\Temporary ASP.NET Files
- READ - .Net Framework hierarchy (%WINDIR%\Microsoft.NET\Framework\<version>)
- READ - %WINDIR%\assemblyï¿½
- FULL CONTROL - %SYSTEMDRIVE%\Inetpub\wwwroot\VaultService
- FULL CONTROL - %SYSTEMDRIVE%\Inetpub\wwwroot\VaultService\VaultShadowFolder
- READ / WRITE / MODIFY - %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
The last step in this process is to configure Vault Shadow Folder with Identity Impersonation. You can either set up an Application Pool with a separate identity, or modify Shadow Folder's web.config file for this setting. Please refer to IIS 6 documentation for more information on steps on identity impersonation.

UPDATE for users on Windows Server 2003: In an effort to reduce the errors associated with configuration, SourceGear has developed a tool to help automate with the last two steps- IdentitySwitcher. Again, this is for users on Windows Server 2003.

It is recommended that you use that to set impersonation in your web.config file. You must make sure to specify the location of the VaultShadowFolder web.config file in step 2 of the identity switcher (C:\Inetpub\wwwroot\VaultService\VaultShadowFolder\web.config, by default).

Using the IdentitySwitcher program will assign the correct NTFS permissions and set the identity impersonation in the web.config.

After completing the above steps, you should be able to create Shadow Folder associations in the Admin Tool using UNC paths.

------------------

ï¿½ - text adapted from http://msdn.microsoft.com/library/defau ... etHT01.asp

ï¿½ - This is the global assembly cache. You cannot directly use Windows Explorer to edit ACLs for this folder. Instead, use a command Windows and run the following command:

Code: Select all

cacls %windir%\assembly /e /t /p domain\useraccount:R

Alternatively, prior to using Windows explorer, unregister shfusion.dll with the following command:

Code: Select all

regsvr32ï¿½u shfusion.dll

After setting permissions with Windows explorer, re-register shfusion.dll with the following command:

Code: Select all

regsvr32 shfusion.dll