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!
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.
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.
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?
I'm sorry I didn't mention clearly. My post OS is Linux, RHEL5.
I think I read your post correctly so my answer makes sense 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.
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.
> 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
dblock, can you draw a picture... i'm curious what you mean.
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.
So you want to breach the host from the guest?
No, first the host, then all its guests.
How is the authentication handled server-side within VixHost_Connect()?