Hi all,
I have created a frontend which makes PowerCLI scripts usable via web browser (IIS, ASP.NET).
Until now users logged in providing their domain credentials which were used to connect to
the VirtualCenter servers.
Now I'm trying to use integrated security so that users can call the webpage without
entering username and password and Kerberos takes care about authentication
(via impersonation and delegation) in the background.
ASP.NET user impersonation and delegation is already correctly implemented as it works
in some other parts of the frontend, e.g. when connecting to databases.
With the following command I make sure that impersonation works inside PowerCLI scripts
directly before the Connect-VIServer command is invoked:
Command:
[Security.Principal.WindowsIdentity]::GetCurrent() | ft Name, AuthenticationType, ImpersonationLevel, IsAuthenticated -AutoSize
Output:
Name AuthenticationType ImpersonationLevel IsAuthenticated |
------------------------------------------------------------------------------------------------------ |
DOMAIN\myuser Kerberos Impersonation True |
But the cmdlet Connect-VIServer somehow doesn't use the impersonated user:
Command:
try {
Connect-VIServer -Server XXX -Verbose
} catch {
$_.Exception; Exit
}
Output:
System.Management.Automation.Host.HostException: A command that prompts the user failed because the host program or the command type does not support user interaction. The host was attempting to request confirmation with the following message: Please specify server credential
at VMware.VimAutomation.ViCore.Cmdlets.Commands.ConnectVIServer.HandleConnectError(List`1 connectExceptions)
at VMware.VimAutomation.ViCore.Cmdlets.Commands.ConnectVIServer.ProcessRecordErrorHandled()
at VMware.VimAutomation.Sdk.Util10Ps.BaseCmdlet.ErrorCallbackCmdletBase.ProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()
When I call the cmdlet via command line on the same server everything works as expected:
> Connect-VIServer -Server XXX -Verbose
VERBOSE: Attempting to connect using SSPI
VERBOSE: Reversely resolved 'XXX' to 'XXX'
VERBOSE: SSPI Kerberos: Acquired credentials for user 'DOMAIN\myuser'
VERBOSE: SSPI Kerberos: Successful call to InitializeSecurityContext for target 'host/XXX'
VERBOSE: Connected successfully using SSPI
VERBOSE: Attempting to connect using SSPI
VERBOSE: Connected successfully using SSPI
The cmdlet uses Kerberos to authenticate the already logged in user without asking for any other credentials.
Did someone manage to make Connect-VIServer use the impersonated user the same way when called on an application server?
The already logged on user is afaik not the same as an impersonated user.
Can you check the following:
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Under cmd.exe with runas Connect-VIServer runs as expected
without asking for credentials and using Kerberos authentication.
There seems to be a difference between a "real" user,
e.g. when called with RUNAS /USER:myname powershell.exe above,
and a impersonated and delegated user for this cmdlet.
All other cmdlets, e.g. from the AD module, in my solution can handle
these users like real users. Connect-VIServer obviously can't.
I'm not sure if this is a bug or on purpose.