Admin Tool not listing profiles
Moderator: SourceGear
Admin Tool not listing profiles
I just installed SourceGear Vault Admin Tool 3.1.6 (I'm aware that 3.1.8 just came out, but the SourceGear doc pages recommending staying with the version to match the server). As described in another thread, the installation had some bugs, but I finally manually copied a shortcut into the SourceGear program group in the All Users Start menu.
Now when I run the Admin Tool for the first time, it doesn't find any profiles?
Shouldn't it find the profiles I have already set up and which I use with the Vault IDE client?
(I don't want to have to maintain a separate storage of repository and credential information from the one I already have to manage -- that is, I already have to maintain credentials for the Vault Client IDE on every client machine -- I don't to have to maintain another duplicate set in the Vault Admin Tool.)
Now when I run the Admin Tool for the first time, it doesn't find any profiles?
Shouldn't it find the profiles I have already set up and which I use with the Vault IDE client?
(I don't want to have to maintain a separate storage of repository and credential information from the one I already have to manage -- that is, I already have to maintain credentials for the Vault Client IDE on every client machine -- I don't to have to maintain another duplicate set in the Vault Admin Tool.)
One might cynically suggest that security is being lessened everytime you push the user towards taping a password to a monitor, because the software won't remember it (and put it somewhere like DPAPI storage, which might well be more secure than taped to aforesaid monitor), and the user doesn't want to have to go keep asking the admin staff for it over and over -- and perhaps the user's brain RAM is overflowed with 100 other passwords already, so the user's brain cache is not helping.
Passwords are secured as safe as can be expected through a symmetric encryption algorithm which is not ROT-13.Perry wrote:Uhoh, it just occurred to me that maybe this means I should ask, are the passwords in the Vault profiles secured?
I was simply assuming they were protected by DPAPI.
I hope they're not "protected" by a ROT-13 "encryption".
Last edited by jclausius on Fri Mar 10, 2006 8:03 pm, edited 1 time in total.
Jeff Clausius
SourceGear
SourceGear
Or you could use Active Directory authentication, disable the Admin account from using the Vault client, and add users who need rights Administrative rights to the Administrative group.Perry wrote:One might cynically suggest that security is being lessened everytime you push the user towards taping a password to a monitor, because the software won't remember it (and put it somewhere like DPAPI storage, which might well be more secure than taped to aforesaid monitor), and the user doesn't want to have to go keep asking the admin staff for it over and over -- and perhaps the user's brain RAM is overflowed with 100 other passwords already, so the user's brain cache is not helping.
Jeff Clausius
SourceGear
SourceGear
If the Vault server can authenticate against the AD server that is all that is required. Any remote Vault clients do not require AD connectivity as only the Vault server queries the AD server for authentication.Perry wrote:Is there really a way to use active directory authentication with remote clients who are not in a forest with the server?
Regardless of authentication method, instead of writing down the Admin Password or bothering someone for a login, a valid user of the Admin Tool should be a member of the Administrators group.
Jeff Clausius
SourceGear
SourceGear
I'm not sure if I'm entirely following, because, well, I got confused, but it sounded like you were advocating something that sounds a bit odd to me:
Are you saying that Vault administrators should (or must) also be administrators on the machine running Vault? Or are you saying that they should (or must) also be Domain Administrators on the domain where the Vault server sits?
Especially the second sounds a bit odd to me -- I guess it sounds like it runs somewhat contrary to the idea of limiting privilege to what is required. Um, especially as I think I've just learned that you also advocate making people who will administer Vault also use local administrator accounts on client machines -- so this would imply they're supposed to be using local admin credentials in order to have access to run the admin tool, and they're supposed to be using credentials of an admin on the remote box (or domain, I'm not sure) in order to administer the vault server. That sounds like you're expecting them to be using a lot of administrative power over several different boxes, just in order to administer a vault database.
If the company is a bit larger, and the person administering Vault isn't on the network admin staff, then this philosophy may be less appropriate, I think. I mean, not just that requiring someone to log in to windows with local admin credentials is a danger (it kind of encourages browsing the internet as a local admin, which can be viewed as a bad idea), but also that it requires granting the vault administrator a lot of authority over multiple windows boxes--and I'm not sure it is entirely obvious why this should be required.
But, I may have gotten confused and be misunderstanding--for some reason I'm not following clearly today, or not thinking clearly, or something.
But in any case, it sounds like you're saying that remote users can use credentials from the domain of the server machine, just by typing them into the credentials box on the client? I was entirely ignorant of this, and it sounds nifty.
Are you saying that Vault administrators should (or must) also be administrators on the machine running Vault? Or are you saying that they should (or must) also be Domain Administrators on the domain where the Vault server sits?
Especially the second sounds a bit odd to me -- I guess it sounds like it runs somewhat contrary to the idea of limiting privilege to what is required. Um, especially as I think I've just learned that you also advocate making people who will administer Vault also use local administrator accounts on client machines -- so this would imply they're supposed to be using local admin credentials in order to have access to run the admin tool, and they're supposed to be using credentials of an admin on the remote box (or domain, I'm not sure) in order to administer the vault server. That sounds like you're expecting them to be using a lot of administrative power over several different boxes, just in order to administer a vault database.
If the company is a bit larger, and the person administering Vault isn't on the network admin staff, then this philosophy may be less appropriate, I think. I mean, not just that requiring someone to log in to windows with local admin credentials is a danger (it kind of encourages browsing the internet as a local admin, which can be viewed as a bad idea), but also that it requires granting the vault administrator a lot of authority over multiple windows boxes--and I'm not sure it is entirely obvious why this should be required.
But, I may have gotten confused and be misunderstanding--for some reason I'm not following clearly today, or not thinking clearly, or something.
But in any case, it sounds like you're saying that remote users can use credentials from the domain of the server machine, just by typing them into the credentials box on the client? I was entirely ignorant of this, and it sounds nifty.
OK. I think things are becoming a bit murky here. In those previous posts, when I mentioned the "Administrators" group, I was referring to the Vault Administrators group.Perry wrote:Are you saying that Vault administrators should (or must) also be administrators on the machine running Vault? Or are you saying that they should (or must) also be Domain Administrators on the domain where the Vault server sits?
This is incorrect. The Vault Administrators group allows you to login to the Vault Admin Tool along with some other features. Normally, you wouldn't assign any other rights to the Vault Administrators group. This way privileges are not escalated while using Vault.Perry wrote:I guess it sounds like it runs somewhat contrary to the idea of limiting privilege to what is required.
This is also incorrect. You can be a normal "Windows user" and install the Vault Admin Tool. When installing as a local account, you will need to install to a directory in which your Windows account has read/write privileges. You will also receive a warning message about the Uninstall Key. Click "Ignore" to go past this Installer dialog. This is just a warning, and the Vault Admin Tool works as expected.Perry wrote:I've just learned that you also advocate making people who will administer Vault also use local administrator accounts on client machines -- so this would imply they're supposed to be using local admin credentials in order to have access to run the admin tool, and they're supposed to be using credentials of an admin on the remote box (or domain, I'm not sure) in order to administer the vault server. That sounds like you're expecting them to be using a lot of administrative power over several different boxes, just in order to administer a vault database.
Just reiterating, Windows Admin privileges are not required for Vault Admin Tool installation.Perry wrote:snip ... I'm not sure it is entirely obvious why this should be required.
Basically, if the user has an account on the AD (in which the Vault Server communicates), the user types in those credentials in the Vault GUI/Admin Tool, which is then passed to the Vault Server. The Vault Server in turn queries the AD Server for authentication.Perry wrote:But in any case, it sounds like you're saying that remote users can use credentials from the domain of the server machine, just by typing them into the credentials box on the client? I was entirely ignorant of this, and it sounds nifty.
Jeff Clausius
SourceGear
SourceGear