Hi orian.
Since I do not know your setup, this is a little bit of guessing. But I run into a simlar problem for Windows.
For a user (who runs the workflow) to logon to the guest operations. The user must be allowed to access guest operations. This means a user must have access in vCenter to use guest operations, AND have access inside the VM aswell. If you run with root (linux) or administrator (Windows) you sorta buypass the OS level, and only need the vCenter access (You still need the password).
I'm guessing it's working on Windows because the user who runs the workflow is using the same LDAP credentials for both vCenter and for the OS (using same Active Directory) and is member of the local administrator group.
When running a workflow on the vCenter (connected to one AD) and the VM is joined another AD) you end up with the same trouble.
What you need to do is to get a SSO ticket from the vCenter. You need to use SOAP to get a ticket from your vCenter on port 9443 (https://{FQDN of vCenter}:9443/sts/STSService).
Then you need to map the vCenter user to the local user, and use this ticket when you access guest operations.
To be blunt, this is hell. Mostly because you cannot use the builtin SOAP "plugin" i vRO. Because it's not compatible with vCenter soap API. (Yeah it's kinda funny when vmware products are not compatible...)
You can make your own Soap parser in vRO but it's a lot of work.
Have a look at vSphere Automation SDK for more details.
If your Linux VM can be joined to the same AD as the vCenter, you should be able to avoid this. (easiest solution). However I never tried this.
