VMware {code} Community
cli4
Contributor
Contributor

VixHost_Connect fail with NULL username and password

I'm working on VMware Server 2.0. In Vix API document, it says that if you want to connect to localost with current login, then you can use NULL for hostname, username and password. I just want so. But when I use NULL for host name, VixHost_Connect fails with error message:

18002 Malformed hostname parameter. For the given service provider, the hostname must be a URL, in the form

I have to change host name to . But this is ok for me. All I want is to use NULL for user name and password, because I don't want to hardcode root's password in my program.

But when I use NULL for user name and password, I get error message:

1 Unknown error

What's the problem? How to solve it?

Thanks in advance!

0 Kudos
12 Replies
dblock
Enthusiast
Enthusiast

If your server has a username/password, you have to supply it. You can't login to a system that requires a password with a blank one just because you're "local". I would supply the server password in the application's configuration file.

0 Kudos
fixitchris
Hot Shot
Hot Shot

I remember this. Supposedly you should be able to use your Windows credentials to connect via VIX. From what I remember this functionality never worked... There might be a workaround since the new VI client supports this with the "use Windows credentials" checkbox.

0 Kudos
cli4
Contributor
Contributor

userName

Username to authenticate with on remote machine. Use NULL to authenticate as current user on local host.

password

Password to authenticate with on remote machine. Use NULL to authenticate as current user on local host.

This is quoted from VIX API's document. So, is this a bug of VIX API or VIX API's document?

0 Kudos
cli4
Contributor
Contributor

I'm sorry I didn't mention clearly. My post OS is Linux, RHEL5.

0 Kudos
dblock
Enthusiast
Enthusiast

I think I read your post correctly so my answer makes sense Smiley Wink Unless your VM is a Windows server on the same domain and your local machine and you're logged in with credentials that work for both machines (client and guest), you must supply credentials. It would be a security hole otherwise.

0 Kudos
admin
Immortal
Immortal

I'm not sure which version of the documentation you're looking at, but if you read the current version on-line, it says (http://www.vmware.com/support/developer/vix-api/vix17_reference/):

login

Username for authentication on the remote machine. With VMware Workstation and VMware Server 1.0.x, use NULL to authenticate as the current user on local host. With ESX/ESXi and VMware Server 2.0, you must use a valid login.

password

Password for authentication on the remote machine. With VMware Workstation and VMware Server 1.0.x, use NULL to authenticate as the current user on local host. With ESX/ESXi and VMware Server 2.0, you must use a valid login.

So yes, you need to provide credentials when connecting to VMware Server 2.0. I know this can be far from ideal, but you can use techniques to work around this. For instance, on Windows you can ask the OS to store the credentials securely using the Data Protection API (http://msdn.microsoft.com/en-us/library/ms995355.aspx), so you're program could simply ask the OS to fetch the credentials from a secure store every time it ran using the program's user's credentials. I'm not sure if these is a similar facility for Linux OSes. You could at least store the credentials in a file only readable by your user, for instance.

0 Kudos
dblock
Enthusiast
Enthusiast

> So yes, you need to provide credentials when connecting to VMware Server 2.0. I know this can be far from ideal, but you can use techniques to work around this.

Flankly, this was a good design decision. If you could workaround this you could give us some business. We would appreciate <grin />. An increasing number of people host their databases on virtual machines, so if a hacker could hit someone's OS bypassing login via VMWare infrastructure, we would be attacking the VMWare servers instead. It's much more efficient since you get a bunch of servers right away and most admins use the same usernames and passwords across multiple hosts. Plus it's all new and I am sure there're some security vulnerabilities waiting to be found Smiley Happy

0 Kudos
fixitchris
Hot Shot
Hot Shot

dblock, can you draw a picture... i'm curious what you mean.

0 Kudos
dblock
Enthusiast
Enthusiast

I am bad at pictures. I'll give an example.

Heartland was attacked (and the largest credit card breach in US history was successful) by a classic layered approach. A vulnerability in a web application (SQL injection) was exploited to execute malicious code on the operating system followed by hacking more machines that lead to more databases with more customer data.

Now, imagine all that ran on VMWare. I have one more thing to exploit: the VMWare host. The VMWare host communicates with the OS directly and VixCOM, for example, is an API to do that. If I could do anything to the OS without authentication, then I'd rather hack the host - it gives me access to dozens of virtual machines - a goldmine. Essentially VMWare is an additional major security risk in the already very complicated picture of interconnected machines.

0 Kudos
fixitchris
Hot Shot
Hot Shot

So you want to breach the host from the guest?

0 Kudos
dblock
Enthusiast
Enthusiast

No, first the host, then all its guests.

0 Kudos
fixitchris
Hot Shot
Hot Shot

How is the authentication handled server-side within VixHost_Connect()?

0 Kudos