vim.fault.invalidticket exception when passing AcquireTicket value to vmware-vmrc (remote console)

[vSlapp]

I have written an app that opens the vmware remote console (vmware-vmrc.exe) by passing it the VirtualMachineTicket value from the AcquireTicket method (see vSphere API for more details).

The problem I am having is that when I pass the ticket value to the vmware-vmrc.exe application I receive a vim.fault.invalidticket. Here is what the command looks like:

vmware-vmrc.exe -h 192.168.1.10:443 -p VCT-52d576c5-b292-681a-40f8-f06cf9d7b926 -M "vm-18273"

I was able to determine this was the format VMware was using by running process explorer while logging into the vSphere Web Interface. The process explorer shows exactly what the command looks like at the time it is called. So the 192.168.1.10 address is the vCenter server in this case, the password is the ticket value preceded by a "VCT-" prefix (perhaps standing for VMware Console Ticket), and finally the ManagedObject ID of the virtual machine I am trying to connect to.

So after passing the ticket value to the vmware-vmrc application, the error is generated... but if I do this from the web interface directly, there is no invalidticket exception. The only way I can get the vmware-vmrc to work is to exclude the VCT-Ticket info and call the vmware-vmrc application with the vCenter host address and the MOID value for the virtual machine. Then the console opens up, asks for the username and password, and then allows access to the vm console.

Of course the idea is to bypass having to login by supplying the ticket information on behalf of the user that is already authenticated.

Does anyone have experience with this? There is almost nothing on google about how to handle VirtualMachineTicket information with regards to the vmware-vmrc console application.

[vSlapp]

Finally figured this one out. Forgot to post the resolution.

Originally, I was using the following code to obtain the MKS ticket:

MksInteraction mks = new MksInteraction(vimSvc, svcRef, sc, uuid);
VirtualMachineTicket returnMksTicket = mks.GetMksTicketForVirtualMachine();

This obviously was the wrong approach (or more specifically the wrong ticket). The solution lies in using the following code:

string ticket = vimSvc.AcquireCloneTicket(sc.sessionManager));

After user login, the vimSvc object stores the UserSession data related to the current user session. By calling the AcquireCloneTicket method and passing the already existing ServiceContent.sessionManager ManagedObjectReference, the proper VCT ticket is returned. This ticket (which is a string) can then be passed the vmware-vmrc.exe executable to open the console without requiring further login by the user.

Further reference to the AcquireCloneTicket can be found here: http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.SessionManager.html

[BKeadle]

Thanks for posting the resolution, but I don't understand how/where you're using the code found to pass to the vmware-rc.exe.  Is there a complete script you can share that I can use to launch vmware-rc to a specified VM?

[vSlapp]

I first started by running FileMon (now apart of Process Monitor) to capture the exact EXE call that was being made when the remote console was being invoked through the standard VMware Web Interface. FileMon revealed the following structure:

vmware-vmrc.exe -h {host} -p {vmTicket} -M {vmID}

In this case I am using vCenter, so the {host} address is actually the vCenter server address. Once the vmware-vmrc application receives the handshake from vCenter, vCenter then returns the actual physical host address within the vCenter cluster based on the location of the VM you are trying to remote console to.

In order to achieve this, since I am using a Silverlight interface, I first needed to write some custom javascript (that is called from Silverlight/C#) to call a Java app to call the vmware-vmrc.exe executable (since Silverlight doesn't allow direct file system access).

That's pretty much it.

[Coldblooded]

Keep in mind that AcquireCloneTicket() on the SessionManager returns the session for the entire vsphere and may pose security vulnerabilities, such as being able to access any vm. The AcquireMKSTicket() on the VirtualMachine Managed Object is more appropriate for accessing a single VM's Console. I'm not sure why this does not work, as this way is more secure, and makes the most sense.