Folder Permissions

toddg · Post by **toddg** » Mon Dec 20, 2004 9:38 am

I am using Vault server 3.01 on Server 2003and am having problems changing the server's config. My goal is to use my Active Directory for authentication so I have Vault impersonating a domain user (which I created specifically for Vault). I have also created a web server instance specifically for Vault.

The problem I am having is whenever I go to make a change on the "Server Options" tab I get:
Access to the path "<Vault Web Server Directory>\Vault.config" is denied.

I have managed to change items in there by granting everyone full permission to the entire directory that the web server runs out of. What are the correct permission on this directory supposed to be? Better yet, when the Vault Admin Tool goes to write to the Vault.config, what user does it do this as?

Thanks in advance for any ideas.

lbauer · Post by **lbauer** » Mon Dec 20, 2004 9:58 am

This would be the custom account you're using for identity impersonation.

That account needs access to the same directories as an account used for Shadow Folders, so this KB article should help:

http://support.sourcegear.com/viewtopic.php?t=188

Your custom account also needs full control of this directory:

%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys

toddg · Post by **toddg** » Mon Dec 20, 2004 12:58 pm

I am running vault on a server that is not a domain controller (it is however a member server). When that article refers to the IIS_WPG group, is it referring to the local group or the domain group?

lbauer · Post by **lbauer** » Mon Dec 20, 2004 1:29 pm

Do you have both groups on your machine?

We'd suggest using the local group.

toddg · Post by **toddg** » Mon Dec 20, 2004 2:02 pm

Well one is a domain group and one is a local group. So only one lives on the same machine as vault. There are other web servers that live on our domain controllers that are unrelated to Vault, that could be why they exist in both places.

I'll try local group and see what happens.

toddg · Post by **toddg** » Mon Dec 20, 2004 3:13 pm

Ok, I followed everything in that article to a T. I tried using either the local or domain IIS_WPG groups and neither way works.

What I have found is that if I give everyone full access to the Machine Keys dir (C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys) and the directory the website runs out of everything works fine.

So it sure seems like my problem is a permissions problem on both of these directories. So doesn't it make sense that just adding full access for the user who needs access to these directories would solve all of the problems? The answer to my question of who Vault uses to write to / read from these directories seems like it would solve all of my problems. Or maybe there's more to it that I'm missing....

Post by **jclausius** » Mon Dec 20, 2004 4:26 pm

Todd:

Did you delete the file - %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys\edb3f753ca89beb7d17f32a80a447d7_* as described in step 2 of http://support.sourcegear.com/viewtopic.php?t=231?

If the file is created with incorrect permissions, those incorrect permissions remain on the key file. The trick is to delete the file while IIS / Vault is stopeed, and then restart. This will recreate the file with the permissions of the current impersonator.

toddg · Post by **toddg** » Mon Dec 20, 2004 6:24 pm

That article tells me to put the machinekeys directory at everyone with full control. That's what I'm trying to avoid. I'd rather just give the appropriate permissions to the user/group that needs access to the files.

The procedure described in that article only works if you grant everyon full permissions on the machinekeys directory.

I granting the appropriate permissions (not full to everyone) to the machinekeys and website directories the recommended way to do it? Or is there any way you can tell me who is accessing these directories?

Post by **jclausius** » Mon Dec 20, 2004 9:21 pm

Actually, I was just referencing step 2 - deleting the file. My guess is the file itself has different rights, as it would have been created while running under a different Windows based account.

If you give the impersonated account full control to the machine keys directory that Linda mentioned, and also delete the file, does that work?

toddg · Post by **toddg** » Tue Dec 21, 2004 4:06 pm

The only way that it will create the key is if I give everyone full access to the machinekeys directory. I have given the user that vault is using for impersonation full priveledges to the machinekeys directory and it won't work. I don't see a new key created and also therefore see the trouble getting machine key error.

Post by **jclausius** » Tue Dec 21, 2004 4:31 pm

Is your web.config empty of any impersonation, and you've configured the Application Pool to use the identity?

Is there something else that I'm missing ( like not allowing anonymous ) access to the virtual directory?

If impersonation is setup, then the first access to the machine keys should be through that impersonated account. I wonder if sysinternals file monitoring would help identify the user accessing the directory?

toddg · Post by **toddg** » Tue Dec 21, 2004 6:27 pm

That was the problem. I had read in somewhere that you're just supposed to uncomment a line in the web.config file. I did that and what was there was improper syntax. Thanks for the help and quick responses.

Post by **jclausius** » Tue Dec 21, 2004 10:28 pm

Are you using an impersonated account for an Application Pool? If so, you could try removing the impersonation settings from web.config, and strictly use App Pool impersonation.

toddg · Post by **toddg** » Wed Dec 22, 2004 7:25 am

I have an application pool set up for the vaultshadowfolder which runs as my vault user. This is how I have had it both before and after I was experiencing these problems.

Post by **jclausius** » Wed Dec 22, 2004 7:39 am

OK. When using an application pool identity, the identity impersonation in web.config is a non-issue. IIS 6 will override that setting with the identity of the identity in the Application Pool.