Admin Tool not listing profiles

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

Post Reply
Perry
Posts: 110
Joined: Tue Dec 27, 2005 9:11 am

Admin Tool not listing profiles

Post by Perry » Fri Mar 10, 2006 3:45 pm

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.)

Perry
Posts: 110
Joined: Tue Dec 27, 2005 9:11 am

Post by Perry » Fri Mar 10, 2006 4:01 pm

BTW, I since realized that it isn't that the profiles are simply empty for the Admin Tool -- the entire profile section is disabled, and it's not apparent to me how to enable it.

mskrobul
Posts: 490
Joined: Wed Jan 14, 2004 10:22 am
Location: SourceGear
Contact:

Post by mskrobul » Fri Mar 10, 2006 4:09 pm

This is by design.

Using profiles in the admin tool would be a security risk.

You must supply a name password each time you log into the admin tool.
Mary Jo Skrobul
SourceGear

Perry
Posts: 110
Joined: Tue Dec 27, 2005 9:11 am

Post by Perry » Fri Mar 10, 2006 6:30 pm

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.

Perry
Posts: 110
Joined: Tue Dec 27, 2005 9:11 am

Post by Perry » Fri Mar 10, 2006 6:32 pm

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".

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Fri Mar 10, 2006 7:57 pm

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".
Passwords are secured as safe as can be expected through a symmetric encryption algorithm which is not ROT-13.
Last edited by jclausius on Fri Mar 10, 2006 8:03 pm, edited 1 time in total.
Jeff Clausius
SourceGear

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Fri Mar 10, 2006 8:02 pm

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.
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.
Jeff Clausius
SourceGear

Perry
Posts: 110
Joined: Tue Dec 27, 2005 9:11 am

Post by Perry » Sat Mar 11, 2006 4:44 pm

Is there really a way to use active directory authentication with remote clients who are not in a forest with the server?

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Sat Mar 11, 2006 9:44 pm

Perry wrote:Is there really a way to use active directory authentication with remote clients who are not in a forest with the server?
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.

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

GregM
Posts: 485
Joined: Sat Mar 13, 2004 9:00 am

Post by GregM » Sun Mar 12, 2006 4:44 pm

This was also requested here last year.

http://support.sourcegear.com/viewtopic ... ol+profile

Perry
Posts: 110
Joined: Tue Dec 27, 2005 9:11 am

Post by Perry » Mon Mar 13, 2006 12:53 pm

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.

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Mon Mar 13, 2006 2:03 pm

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?
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:I guess it sounds like it runs somewhat contrary to the idea of limiting privilege to what is required.
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'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.
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:snip ... I'm not sure it is entirely obvious why this should be required.
Just reiterating, Windows Admin privileges are not required for Vault Admin Tool installation.
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.
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.
Jeff Clausius
SourceGear

Perry
Posts: 110
Joined: Tue Dec 27, 2005 9:11 am

Post by Perry » Mon Mar 13, 2006 4:36 pm

> OK. I think things are becoming a bit murky here.

Yes, apparently I completely misunderstood, and you were not referring to either Domain or Local Admin groups at all...

Sorry about that.

Post Reply