Secure Vault for access from the web

[dorjem]

Hi there,

I've spent a few hours going through the doco and the forums plus a little trial and error on our Vault install [ Version 4.1.1.18060 ].

I'm trying to change our current install so that when users access the repository via https from the internet they're challenged for their Windows domain credentials before they're able to connect to Vault.

I'm an experienced intranet manager but am only just coming to terms with Vault.
Normally within IIS I'd diable anonymous and enable 'windows authentication' on the virtual folder's 'security' tab.
Then remove permissions on the folder's contents for the machinename\ groups and add in a domain security group, the members of which should have rights to the application / site etc
BUT
I believe because Vault is an ASP.NET application (which again I'm not too clued up on) this approach doesn't work , while it does then prompt users for their username and password it then breaks Vault. When users try to manipulate vault from within some development IDE they get a 401 authorization failed message.

I guess what I'm looking for is a tutorial - step by step - on how to modify an existing (out of the box) installation of Vault to ensure all users first provide username/password combinations that are valid and are members of a Vault users domain security group.
From this point I don't too much mind letting Vault do what it does.

I realise this is similar to what lovalvob , in the following post ,
[url]http://support.sourcegear.com/viewtopic.php?t=7395[/url]
was trying to do but I still don't see a simple , or even enough of the pieces, to answer the question.

I hope this is a 'see this post' question for the SourceGear folks who do such a great job answering the myriad of questions posted here.

[jeremy_sg]

dorjem,

What you're hoping to do doesn't come up all that often. Here's some of my ideas.

1. You could try setting up a "reverse proxy". A reverse proxy sits between the internet and the server, instead of a normal proxy which sits between clients and the internet. Vault can handle proxies that demand authentication.
2. A VPN is also a good solution, which has the additional benefit that no servers are visible to the internet.

[dorjem]

Hi Jeremy,

Reverse proxy suggestion - thanks for this but I think this will come up with the same issues. When using the Vault client from within Visual Studio changing IIS to 'windows authentication' and changing the file permissions on the 'VaultService' folder to allow only members of a specific group produces a 401 error within Visual Studio.
Using a web browser to access the site prompts for windows domain credentials then Vault credentials then shows you the site.

I've worked with some of the staff here and looked at Reverse Proxy - not tested but probably the same problem, Vault client wouldn't pass windows credentials so would still give 401 error within Visual Studio.
We've tried a windows tool which in some instances passes windows credentials when connecting to certain machine names - but the Vault client doesn't pick this up so we get the 401 error again.

You mention that this request "doesn't come up all that often" - I've found a couple of mentions
http://support.sourcegear.com/viewtopic.php?t=10450
and
http://support.sourcegear.com/viewtopic.php?t=8528
and
http://support.sourcegear.com/viewtopic.php?t=7395

One thing that may work is suggested by Beth in the following post
http://support.sourcegear.com/viewtopic.php?t=10450
Modify web.config to use 'windows' authentication, but this requires that the Vault process needs to run under an Active Directory account.

Could you or Beth confirm if we changed to run Vault under domain account that change would then allow us to run IIS in the 'windows authentication' security mode ?
What change would then be required for the Visual Studio users in their setup ?

Thanks for your time and effort on this

[jeremy_sg]

A reverse proxy is a different than using IIS windows authentication, since proxy authentication applies to even non-windows clients and servers. It's definitely worth a try, because the Vault client will prompt for proxy credentials. If these credentials are going through the internet, then SSL is a must.

Our Active Directory integration is limited to using AD as a password store. This causes the Vault server to verify the password that a user sent against active directory instead of the internally-stored Vault password. You should be able to set that up without running the Vault server under a domain account.