How should I set up a secur Vault site for off-site users?

[lovalvob]

OK, after some trial and error, I have Vault up and running. I’ve been a user since 1.x, so I’m generally familiar with how things work.

I’ve been trying to make a secure installation for use by remote developers, and it’s pretty difficult. I’ve been through the forums, and there’s bits and pieces of what I need. I was hoping that there was a full document, but I haven’t found anything. If you have something, please direct me there.

The problem, and I see it is four-fold:
1) The Vault admin ID is well-known
2) The Vault server website is well-known.
3) The default page for the VaultService provides lots of useful information for crackers.
4) There appears to be no timeout or lockout for password mistakes on the admin id.

This makes it really easy to scan for web servers looking for Vault, and then crack them by brute force.

Here’s what I did to try to get around it:
1) Installed Vault to my W: drive, rather than C:
2) Put it on a SSL site
3) Set it in its own application pool
4) Remove the default landing page
5) Removed the VaultService and ValultShadowFolder applications from their default locations
6) Created new VaultService and ValultShadowFolder applications into a virtual directory.
At least the site isn’t well-known.

So, that should slow down the crackers for a bit, but I still feel really venerable. Here are some options that I’d like to be able to take. Please advise if any are currently available:
1) Disable or rename the Admin account
2) Protect the vault service(s) behind an authenticated web application.
I can do this now, but I haven’t found any way for the Vault client to sign in to the website. Since we’re using domain authentication for both the site and Vault, it seems that I should be able to tell the vault client to use the same ID/PW for the site and the server.

Any help would be appreciated. This type of security hole makes me nervous.

[jclausius]

3) The default page for the VaultService provides lots of useful information for crackers.

You can change or delete the ServerInstall.html page from the VaultService virtual directory as a post-installation step.

4) There appears to be no timeout or lockout for password mistakes on the admin id.

This makes it really easy to scan for web servers looking for Vault, and then crack them by brute force.

You may be using an older version of Vault. As of Vault 1.1 or 2.0 (memory fails me for the correct version), we added a 30 second timeout on incorrect logins to slow down brute-force attacks.


For your other questions:

1) I'll log a feature request for this.

2) Have you looked at restricting access through web.config - http://msdn.microsoft.com/library/rus/d ... cation.asp

The Vault clients all send their login credentials for any web access. If you configure the web.config file to check for those Windows credentials, you can restrict access to the Vault pages. Of course this has some other problems in non-Windows environments, as well as configuration when machines are on different network domains.


Some other suggestions:
1) Use strong passwords.
2) Firewalls to only allow known client requests.
3) Log file monitoring on web requests and login attempts.

[lovalvob]

Thank you for the response. I'm on 3.5.1. I didn't know that there was a timeout.

As per configuring authentication through the web.config, I'm not sure how that can help. I've familiar with and have tried those options. We use them to secure the site.

The integrated authentication only works on the intranet or through a VPN. The other options require that the client respond to the request for an ID/PW. IE does this by prompting with a dialog box.

Unfortunately, Vault client appears to ignore the request to supply and ID/PW. It's pretty easy to fix, since the .net http driver gives you a place to enter an ID/PW.

Perhaps I'm mistaken, and I've missed it. If so, please correct me. If not, please add this to the feature request list.

Also, in looking back at my comments on the Admin account, I missed a couple of options. Please add the following as options to the feature request list:
1) Change the name of the Admin account
2) Disable the admin account if other admin users exist
3) Put the admin calls into a seperate website (like IIS does). Then, we could use all of the IIS options (local IP only, filtering, turn off site) to control it.

Thank you.

Barry

[jclausius]

Unfortunately, Vault client appears to ignore the request to supply and ID/PW. It's pretty easy to fix, since the .net http driver gives you a place to enter an ID/PW.

The Vault client doesn't ignore it, but instead it sets the web request with the user/password of the currently logged in user's network credentials. I understand that doesn't help in the situation you described, but in some cases this does allow for Windows authentication to be set on the virtual directory.

Please add the following as options to the feature request list:
1) Change the name of the Admin account
2) Disable the admin account if other admin users exist
3) Put the admin calls into a seperate website (like IIS does). Then, we could use all of the IIS options (local IP only, filtering, turn off site) to control it.

No problem.

[lovalvob]

Actually, what you just described is exactly what I want. Each of the users is logged in to their own machine as a domain user. Vault is set up to use domain authentication.

I then configured IIS to require credentials. I tried basic over https, integrated, and digest. I set the authentication domain and/or realm to our full domain name (hq.armeta.com).

Generally speaking, it worked when I was on the LAN or VPN, but not when I was coming in from the outside. The error was a 401-unauthorize, so I assumed that the vault client wasn't trying the ID/PW that it had.

I attributed this to the fact that when the http driver (and IE) sense that you're accessing an intranet resource, the credentials are automatically supplied. It doesn't automatically do this on internet sites.

It could also be the fact that the certificate on IIS is a generic certificate, not a domian specific certification. That is, the domain is HQ.ARMETA.COM, while the certificate is for DALLAS.ARMETA.COM.

I suppose that I could create a completely new site, that uses a machine specific certificate (SPIDER.HQ.ARMETA.COM). That might get IE to automatically authenticate.

Is it possible that I just need to change the vault user name to include the domain (i.e. hq\barry.lovalvo)?

[jclausius]

Let me re-phrase my last post.

The Vault client doesn't ignore it, but instead it sets the web request with the Windows based user/password of the currently logged in user's network credentials. The Vault login/password are never used to access IIS, but the currently logged in Windows Network credentials *are* used.

With that said, the Vault user/password is irrelevant. What matters is the default Windows network credentials the .Net Framework provides to the Vault client.

We've never tested/configured "Windows Authenticated" web access using Windows auth's outside the domain, so this may or may not work. The IIS link I posted mentions using a VPN or PPTP, so that may have to be included in your configuration.

Also, I've logged a feature request to allow the Vault client to be configured with a DOMAIN\user (or user@domain) and password combo to be used for network credentials.

[Beth]

Just another side thought.

I believe one could make that server's address to only be accessible locally and then set up a secure VPN to the internal network and access it that way.

[lovalvob]

I seem to have lost my last post. Here goes again.

To review, I'm trying to set up Vault for users at remote locations. Those users are on domain machines, using domain user accounts, but they're not on a VPN.

After some research and testing, I've realized that we're talking about two different things. The fist is IIS authentication. The second is ASP.NET authentication.

The HTTP protocol provides for authentication. None and Basic are the defaults across all platforms and browser. Microsoft adds Integrated and Digest, but that's not really relevant because they're really designed for intranet use.

So, anyway, if you allow IIS to use anonymous authentication, then the user appears as the guest user (iis_user). A better way to to enable SSL and use basic authentication.

When the user agent (ie or Vault) attemp to connect to the site, the IIS response will include notification that credentials are required. If this is the first time that this domain is accessed, IE will prompt the user for ID/PW. If not, IE will get them from it's cached session credentials.

If the credentials pass, the page or ASP.NET application becomes aware that a request has been made. If the credentials don't pass, the ASP.NET application is never involved.

A this point, an ASP.NET application has some options. Using the WEB.CONFIG file with the 'authenticate="windows"' option, it can now SEE the credentials that IIS may have gathered. ASP.NET just gets what IIS gathered. If IIS allowed anonymous authentication, then the ASP.NET application will simply get 'IIS_USER....'.

So, to make this all work well, I would suggest the following:
1) Set IIS to use SSL, and require Basic authentication on the valut site.
2) Have Valut Client provide the ID/PW to IIS when requested.
3) Set Vault Server to use ASP.NET Authentication="windows'
4) Have Vault server get the user ID from IIS

Note that this gives you secure, centralized, domain authentication without the need for Vault server to access AD, or ever see a password. It's standards compliant, and will work with non-windows clients.

Frankly, I think that this would work today, except that the Vault client doesn't seem to provide the ID/PW to IIS when requested. This is a quick fix. Simply provide the CREDENTIALS to the WebRequest object when creating it.

Granted that there isn't any option for 'no password' in Vault, but setting it for domain authentication would work too. It's redundant, but won't hurt anything.

You did mention that the Vault client will provide the credentials of the network user when on the LAN, but I don't think that that is quite correct. I think that the HTTP layer in Windows will automatically provide those credentials before Vault client even sees the request.

Now, about that pesky Admin ID. A side benefit of this configuration is that the Admin ID would be automatically blocked from using the site from the outside.

Now, given the large number of requests that I've seen in the forum for configuring Vault in this type of environment, it would seem that this is a no-brainer (high demand, trivial implementation).

How can I help make sure that it gets into 3.5.2? May I offer some help:
1) I'll write the client code. I've written it before, it's about 4 lines
2) I'll volunteer to test it. I have the infrastruture, and I know what it needs to do.
3) I'll write the documentation, howto, help, or whatever you call it.
4) I'll stand on my head and count to 1,000,000 in multiples of 3/7th.

You name it, I'll do it.

Barry

[jclausius]

Barry:

Just to re-iterate my last post, the Vault client is *already* doing this. All web requests go through a method to send a call to the server. That client code looks like the following:

Code: Select all

HttpWebRequest request = (HttpWebRequest) HttpWebRequest.Create(uriFinal.ToString());
request.Proxy = _clientService.Proxy; // a static for firewall prcxying
request.Credentials = System.Net.CredentialCache.DefaultCredentials; // use the Windows login info for any IIS authentication

When you set up web.config for security, you'll need to use the login info from the client's machines. However, we never tested when one domain's users were configured in the web.config of another domain, so I have no idea if that would work.


Getting back to your post. What you're asking for is a configuration for the client to provide different authentication than the currently logged in user. I've created a feature request for this.

It's too late for 3.5.2, as the code is set for this release, but we'll see where things go in the following release.

[lovalvob]

Ah Ha!. That was the piece of information that I was looking for.

Default credentials don't work over the web. They're only used on an intranet because they require a direct connection to the domain controller.

From the documentation:
The supported values for authType are "NTLM", "Digest",
"Kerberos", and "Negotiate".
This method does not work for HTTP or FTP protocols.

Windows stores the credentials as a hash, and since BASIC and DIGEST security require a clear password, the DefaultCredentials won't work. Sad, because I am using AD security for everything (including Vault).

Also, specifcially applying the default creds to the web request is probably not the best way to do it. The credentialCache is designed to automatically apply credentials for requests. It considers the URI, and the order in which the credentials were added.

Anyway, the code that you probably need is this:

CredentialCache cc= new CredentialCache();
credCache.Add(new Uri("http://xxx"), "Negotiate", CredentialCache.DefaultNetworkCredentials);
credCache.Add(new Uri("http://xxx"), "Negotiate", CredentialCache.DefaultCredentials);
credCache.Add(new Uri("http://xxx"), "Digest" , new NetworkCredential("foo", "bar", "domain"));
credCache.Add(new Uri("http://xxx"), "Basic" , new NetworkCredential("foo", "bar", "domain"));


Then, any subsequent call sets up like this:
HttpWebRequest wreq= (HttpWebRequest)WebRequest.Create(uri);
wreq.Credentials = cc;


Now, if you just comment out the first line (where I use DefaultNetworkCredentials) it's backward compatible with the existing implementation, but also works for internet authentication.

Any chance of a 3.5.2a that I could test???

[jclausius]

But I believe it will also work with PPTP or a VPN. In the current version of Vault what is important is that the IIS Web Server can use that authentication. I think we talked about this in a previous post to this thread.

In regards to the change, I'm sorry to say Vault 3.5.2's features are already set. If we are ahead of schedule on the release date, we'll revisit the issue, but things are already tight as is.

[lovalvob]

You are correct it will work if the user is on a VPN because the user, the IIS server, and the domain controller can all communicate directly over windows protocols.

As for the release, of course, I'm teasing. If, however, someone is willing to make a proof-of-concept implementation after 3.5.2 gets out, I'd be very happy to test it out.

Thanks for the conversation. No need to reply.

Barry

[jclausius]

I received this post from Metro. Reposting on his behalf.

For whatever reason, I am not able to respond to this discussion directly. We have been experimenting with windows authentication for web sites and have determined that for windows authentication to work as expected, the web site needs to be in the user's trusted domain. If it is in Internet, the windows authentication does not happen. I would suggest that the other person try adding the url to his external vault server to the trusted domain of his users. Since this does send some credential information that could possibly be used to crack the user's userid and password, I would also suggest that the web site be configured to use ssl.

Best regards,

Metro Sauper
Sauper Associates, Inc.
856-228-5300 x112

[lovalvob]

So, did this get addressed in Vault 4. I really hope so, because it's very easy to fix, and would really benefit us a lot.

[jclausius]

Sorry, no.

I didn't state it at the time, but Vault 4.0's feature set was already set as well. I've bumped the bug up in priority to be looked at in a Vault 4.0.x maintenance release.