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:
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.Access to the path "C:\Inetpub\wwwroot\VaultService\Vault.config" is denied.
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