Shadow Folder Service uses ASPNET account

[TeamWiSE]

Hello!

We're having a problem with the impersonation of the Shadow Folder Service. Although everything seems to be installed and configured as described in the various topics of this forum, the service seems to be performing partly under the ASPNET account, partly under the domain-account created for this service.

The shadow folders are configured with a UNC on a machine different from the one where the VaultService is running. Thus the need for impersonation under a domain-account.

First of all, the TEMP directory used by the Shadow Folder Service is C:\<docandsettings>\<machinename>\ASPNET\<localsettings>\Temp\, instead of the %SYSTEMROOT%\Temp as configured in the Vault Admin Tool. If only the domain-account had been used here, instead of ASPNET, it still would have been wrong, but better. In this case, in order to get on, we issued some additional rights to the ASPNET-own TEMP-directory.

The second problem (and the one which we cannot circumpass) is, that the ASPNET account, not the domain-account, is trying to access the fileshare on the remote machine. The security protocol on the file-server shows, that the domain-account succesfully logs in, but that also the ASPNET-account of the Vault-Server is trying to login.

Perhaps the VaultShadowFolderService logfile attached sheds some light on the problem. To me it looks as though certain classes/threads "forgot" to use the proper security token.

Hope you can help us out here.

[jclausius]

Are you using IIS 5.0 (Windows 2000 / XP) or IIS 6.0 (Windows 2003 Server)?

The manner in which the process model is configured is different under the different IIS servers.

[TeamWiSE]

We're using IIS 5.0 with XP.

[jclausius]

What does Shadow Folder's web.config look like? You can attach it to this post or send it in an email (using the email button in my post).

[TeamWiSE]

Here's the web.config. Ofcourse some information has been --snipped-- or --replaced--.

[TeamWiSE]

Apparently the shadow folder service works with two threads, one impersonating the sgVaultShadow user, the other impersonating no-one, thus running as aspnet. The aspnet-thread checks, whether the target directories exist, and whether the target files are out of date. The sgVaultShadow thread then gets the files that are out of date or non-existent.

Since the shadow folder resides on a network drive, the aspnet-thread gets no access and deducts that all directories and files are non-existant. Thus, the shadow-thread gets all files and (successfully) stores them on the network drive, since this account is allowed to do so.

This greatly impacts our environment, because the fileserver responds to new files with an automated build, currently triggered by every single change-set. The automated build leads to new versions of executables, that are used as generators and compilers in other application build steps. These new versions of those tools again trigger automated builds of end-user application components. All in all a lot of work is being triggered, although no changes justifying all these rebuilds and new versions were made.

We're still evaluating Vault and to us this is a critical issue. Could you give me some more on how to proceed from here?

[jclausius]

Apparently the shadow folder service works with two threads, one impersonating the sgVaultShadow user, the other impersonating no-one, thus running as aspnet. The aspnet-thread checks, whether the target directories exist, and whether the target files are out of date. The sgVaultShadow thread then gets the files that are out of date or non-existent.

That is incorrect.

The Vault Shadow Folder's account runs under the identity impersonation account in web.config. In your case, all resource security checks should be made under the sgvaultshadow domain account. With identity impersonation, IIS will not use the ASPNET account for the process.

Note, for IIS 6.0 users, the previous paragraph does not apply. The Identity Impersonation is handled under the App Pool's Identity for the Vault Shadow Folder service.

Another thing to check would be the permissions on the share as well as permissions on the folders.

Within your Share on the destination, open up the properties of the folder. Next go to the sharing tab. On the dialog with the share name, you should see a button for "Permissions". Click the button and verify the DOMAIN\sgvaultshadow has full access on the share.

After verifying the user on the Share's permissions, check the security of the folder itself. Make sure DOMAIN\sgvaultshadow has full access to the Security ACL's on the folders/sub folders as well.


A couple of things to note.

a) Running Vault on an Win-XP Pro box can be problematic. Windows XP will only allow 10 incoming connections to within IIS. Since the Vault Server is an IIS / ASP.Net web service it too is constrained by this limit.

Vault itself will use one connection, but when adding / downloading the Vault client uses threads to do multiple uploads / downloads from the Vault Server. This is usually not a problem in a one to two user environment. But when multiple people start using Vault they will encounter problems.


b) Shadow Folder is a service which synchronizes folders on disk to folders within a repository. If anything is changing the files on disk after a Shadow Folder Get, the Shadow Folders service will replace those files on the next transaction.

Does your build environment change any of the files within Shadow Folders, or make modifications to files which would cause Shadow Folder to re-download / replace, thus starting another build?

[TeamWiSE]

First of all, we're still evaluating and not running with tons of users. There are in fact only two users involved in this evaluation. If we are going to use vault productively, we'll be using a "proper" windows 2003 server ofcourse. The XP-box was just handy and available.

We monitor the security log on the file server and see, that with every checkin the machine running vaultservice is doing two logins at the fileserver, one with the machines aspnet account, one with the domains sgvaultshadow account. Ofcourse the security settings both in NTFS and in the share have been checked and are properly set for the domain account. I've attached two screenshots of the securitylog and the aspnet login. carmen is the fileserver, waldo is the vaultserver.

[TeamWiSE]

We've moved the VaultService to another machine (from XP/IIS 5.0 to win2003Srv/IIS 6.0). This worked really well and posed no greater problems. In moving to this server, the shadow folders do not reside on a network drive anymore, and thus the shadow service operates without problems now. Ofcourse that does not mean, that the problem as such has been solved, it's just not relevant to us anymore. What's more, we are considering migrating our own triggered build environment to cruise control. In that case the whole shadow folder principle will be solved differently and the odds are, that the shadow folder will always reside on the same server as the Vault service.

In migrating to this win2003srv server we had to make one minor change, that may or may not be related to the cause of this problem: in our XP/IIS 5.0-configuration the Shadow service ran under a different account from the Vault service. Since under IIS 6.0 these two run under one ApplicationPool, they are configured to run under the same user account. Perhaps a hint to the cause of the problem?

[jclausius]

We monitor the security log on the file server and see, that with every checkin the machine running vaultservice is doing two logins at the fileserver, one with the machines aspnet account, one with the domains sgvaultshadow account.

I see the confusion. I assumed earlier you were referring to two Vault login attempts.

In any case, IIS 6.0 does use a different identity impersonation model than IIS 5.0. By default, the Vault Server installer creates a Vault Application Pool for IIS 6.0 based installations.

In most cases, when Shadowing to a network UNC is used, we recommend installing the Vault Server using the process model of the user of the Domain based, Custom .Net account.

If user's do not install with that model, they are free to create a new Shadow Folder Application Pool, and re-assign the identity under that new App Pool.