PowerCLI 11.x gives "Get-Tag vSphere single sign-on failed for connection Future operations which require single sign-on on this connection will fail."

[MadiTriv]

While invoking a tag command from a remote server ( Using PowerCLI 11.x installed in remote server) We get below issue in our HCI environment and NOT in Vblock.

"Get-Tag  vSphere single sign-on failed for connection

Future operations which require single sign-on on this

connection will fail. The underlying cause was: The requested operation cannot be completed. The computer must be

trusted for delegation and the current user account must be configured to allow delegation."

Please advice how to address this issue, we tried enabling CredSSP and it did NOT resolve our issue. Any help will be appreciated.Thanks

[LucD]

That is not what the error message is saying.
It states that Get-Tag caused an error

[Levin1]

I'm facing the same issue with PowerCLI 11.1 and 11.5. But on some vCenters (same Version) it is working and on some not.

Maybe it is something related to vCenter?

[NelsonCandela]

Dear MadiTriv​ and others,

I had the same problem recently.

A script that generated a HTML output and sent it via e-mail on a daily basis returned no information anymore.

Digging into this I found my filter

Get-VM -Tag "Production"

gave me 0 results and an error message in PowerCLI windows instead:

PS H:\> Get-VM -Tag "Production"
Get-VM : 4/15/2020 11:00:39 AM    Get-VM        Value cannot be null.

I used to connect to the vCenter with the FQDN and saved XML credentials.

The before situation: vCSA 6.0 U3

The after situation: vCSA 6.7 and renamed the FQDN to give it a new domain name.

Testing a simple command like Get-Tag resulted in the following error:

PS H:\> Get-Tag
Get-Tag : 4/15/2020 11:00:44 AM    Get-Tag        vSphere single sign-on failed for connection 'https://vcxxx.yyy.zzz.zone:7444/sts/STSService/vsphere.local'. Future operations which require single sign-on on this connection will fail. The underlying cause was: Could not establish trust relationship for 
the SSL/TLS secure channel with authority 'vcxxx.yyy.zzz.zone:7444'.    
At line:1 char:1
+ Get-Tag
+ ~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-Tag], CisException
    + FullyQualifiedErrorId : VMware.VimAutomation.ViCore.Impl.V1.Service.Tagging.Cis.TaggingServiceCisImpl.GetTag.Error,VMware.VimAutomation.ViCore.Cmdlets.Commands.Tagging.GetTag

Strange. Trust relationship?

Anyhow I disconnected and re-connected using the IP address instead (not using the credentials but manual login).

That gave me a new, different error message:

PS H:\> Connect-VIServer 10.xxx.yyy.zzz -User xxxxxx
Connect-VIServer : 4/15/2020 11:06:18 AM    Connect-VIServer        Error: Invalid server certificate. Use Set-PowerCLIConfiguration to set the value for the InvalidCertificateAction option to Prompt if you'd like to connect once or to add a permanent exception for this server.
Additional Information: Could not establish trust relationship for the SSL/TLS secure channel with authority '10.xxx.yyy.zzz'.    
At line:1 char:1
+ Connect-VIServer 10.xxx.yyy.zzz -User xxxxxx
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [Connect-VIServer], ViSecurityNegotiationException
    + FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_CertificateError,VMware.VimAutomation.ViCore.Cmdlets.Commands.ConnectVIServer

OK ... Certification issue of some sort.

Could be, as we changed the FQDN of the vCSA recently. But we also generated new certificates and I don't exactly know where this comes from.

So the next step was to change the certificate handling accordingly:

PS H:\> Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false
Scope    ProxyPolicy     DefaultVIServerMode InvalidCertificateAction  DisplayDeprecationWarnings WebOperationTimeout
                                                                                                  Seconds            
-----    -----------     ------------------- ------------------------  -------------------------- -------------------
Session  UseSystemProxy  Multiple            Ignore                    True                       300                
User                                         Ignore                                                                  
AllUsers

And that solved my issue!

I have been able to connect to the vCenter with the IP address and with the FQDN successfully and was able to run my report script again.

Of course this could be problematic when it comes to auditing and it might raise the question if this didn't bypass some other important settings. But seriously ... there are some certification issues that the vCSA handles internally only and some certificates are not to be replaced ... honestly I'm not in the mood to dig into this more deeply but if someone has the same error and finds out how this can be corrected in a proper way is welcome to do so.

BR

NC