Access to vault.config denied

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Locked
mabster
Posts: 12
Joined: Wed Dec 15, 2004 9:53 pm

Access to vault.config denied

Post by mabster » Thu Dec 16, 2004 3:44 pm

Hi all,

After some initial hiccups with public keys, I have a fresh install of Vault server up and running.

I can connect to the server with the admin client. However, when I try to change anything on the Server Options tab I get an error when I hit Apply:
Access to the path "C:\Inetpub\wwwroot\VaultService\Vault.config" is denied.
Now, my first thought was to check that the user I told Vault to impersonate when I set it up (QAFMEATS\VaultService) has access to the file in question. He does - he has full control rights to the VaultService folder.

The setting I was trying to change on the tab was the Active Directory Domain (I was trying to set it to 'QAFMEATS'). So out of desperation I manually changed vault.config to use this value (stuck QAFMEATS in between the <ActiveDirectoryDomain> and </ActiveDirectoryDomain> tags).

Restarted the default web site on IIS, and when I looked in the admin client that setting was there. Great! Now I should be able to connect using my domain-login's password. Tried ... no luck.

So I had a look at web.config in the VaultService folder. Here's the weird part. Even though I told Vault to impersonate QAFMEATS\VaultService at install-time, the 'identity' setting in web.config was commented out. Should that be the case?

I tried uncommenting that line so that it read:

<identity impersonate="true" userName="QAFMEATS\VaultService" password="xxx"/>

(where "xxx" is a plain-text password for the vaultservice user)

... and that stopped me from being able to access the /VaultService/VaultService.asmx URL on my server completely.

Am I missing something? Should my web.config file have that identity line uncommented? And why doesn't Vault have access to its own config file? I'm sure that the two problems are related!

Thanks in advance,
Matt Hamilton

mabster
Posts: 12
Joined: Wed Dec 15, 2004 9:53 pm

Post by mabster » Thu Dec 16, 2004 3:59 pm

A bit more info:

This morning I gave NETWORK SERVICE full-control of the VaultService folder under wwwroot, and I am now able to apply updates to the Server Options in the admin client. So the service mustn't have been impersonating.

I then tried adding this line to web.config:

<identity impersonate="true" />

... so it impersonates whoever it is that's trying to connect. That works! I can now log in via the windows client using my domain password.

That, at least, gets us going. I'm not sure whether it's gonna come back to bite me later on, though.

Matt

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Thu Dec 16, 2004 4:01 pm

I'm assuming that you are using Vault 3.0.1, which should have straightened out most of the install issues. If you're not, uninstall the Vault server, and install 3.0.1.

If that isn't true, then email me your phone number using the button below this post.

mabster
Posts: 12
Joined: Wed Dec 15, 2004 9:53 pm

Post by mabster » Thu Dec 16, 2004 5:01 pm

Email sent. Did you get it? I ticked the 'send me a copy as well' checkbox but didn't get it. Weird.

mabster
Posts: 12
Joined: Wed Dec 15, 2004 9:53 pm

Post by mabster » Sun Dec 19, 2004 6:14 pm

Ok, this is weird.

I can log in fine using my Active Directory password, but no-one else can.

At the moment I'm unchecking the 'Active Directory' checkbox against other users and giving them passwords, but this is not ideal.

So I'd like to resolve this one. It definitely has to do with the fact that the 'identity' tag in my web.config won't allow me to impersonate a user.

Matt

mabster
Posts: 12
Joined: Wed Dec 15, 2004 9:53 pm

Post by mabster » Sun Dec 19, 2004 7:03 pm

Hey! I think I have it!

I looked at this kb entry:

http://support.sourcegear.com/viewtopic ... web+config

... and discovered that my 'VaultService' user did not have rights to the 'Temporary Internet Files' folder.

Switching off custom error messages helped diagnose this.

So after lunch I will get the other users to try connecting with their domain passwords!

Locked