Ticket #7891 (new defect)
VBox doens't handle the user account correctly on Windows Hosts
|Reported by:||romut||Owned by:|
Host : Windows 7 Pro 64 bits
Context : VBox is called by a PowerShell script. At development time, this script is run by me, manually. At production time, this script is run by a scheduled task or through an ASP.Net web interface.
I wrote a little PowerShell script to illustrate the defect:
"Windows 1: $([Environment]::UserDomainName)\$([Environment]::UserName)" | Out-File "out.txt" "Windows 2: $([Security.Principal.WindowsIdentity]::GetCurrent().Name)" | Out-File "out.txt" -Append $vBox = New-Object -ComObject VirtualBox.VirtualBox "VirtualBox: $($vBox.HomeFolder)" | Out-File "out.txt" -Append
If the script is run manually by me, the result is:
Windows 1: <my domain>\robot Windows 2: <my domain>\robot VirtualBox: C:\Users\robot/.VirtualBox
To me, this is the CORRECT result.
If the script is called through the computer ASP.Net web interface, the result is:
Windows 1: <my domain>\robot Windows 2: <my domain>\robot VirtualBox: C:\Windows\system32\config\systemprofile/.VirtualBox
Here, the ASP.Net engine is setup with impersonation to enforce the user with the "robot", as shown with the 2 first lines, this works, so the VBox result is WRONG.
If the script is run through a scheduled task, the result is:
Windows 1: <my domain>\Robot Windows 2: <my domain>\Robot VirtualBox:
Here again, the scheduled tasks enforces the user account to "robot", so here again, the VBox result is also WRONG.
I've found a tricky workaround to run from the web interface by backuping/copying VBox files from/to the robot/systemprofile accounts, so yes, really tricky.
For the scheduled task, as VBox returns nothing, I have no solution, until to hope to see this defect fixed.