Chris Stankevitz's questions

Layout

Administration

• ForestA trusts ForestB
• ForestB trusts ForestA
• UserA is an administrator of ComputerA1 and ComputerA2
• UserB is an administrator of ComputerA1 and ComputerA2

Moving VMs with Hyper-V

I have Hyper-V running on ComputerA1 and ComputerA2. I have Hyper-V live migration configured so that users move VMs between the two computers. Users can use PowerShell cmdlet Move-VM to move a VM from ComputerA2 to ComputerA2. This cmdlet can be run from either ComputerA1 or ComputerA2. If running from ComputerA1 ("remotely") the -ComputerName argument must be provided.

Moving VM from ComputerA2 to ComputerA1 (locally from ComputerA2)

Move-VM -Name "VMNAME" -DestinationHost "ComputerA1" -IncludeStorage -DestinationStoragePath "c:\VMNAME"

Moving VM from ComputerA2 to ComputerA1 (remotely from ComputerA1)

Move-VM -Name "VMNAME" -DestinationHost "ComputerA2" -IncludeStorage -DestinationStoragePath "c:\VMNAME" -ComputerName ComputerA1 (note use of the -ComputerName argument)

Users

UserA or UserB could issue the commands above. But in my environment, UserB can only "locally" move the VM. When UserB tries to invoke Move-VM with the -ComputerName "remote" option, UserB gets this error:

Move-VM : Virtual machine migration operation failed at migration source.
Failed to establish a connection with host 'ComputerA1': No credentials are available in the security package (0x8009030E).
The virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: no suitable credentials available. Make sure the operation is initiated on the source host of the migration, or the source host is configured to use Kerberos for the authentication o fmigration connections and Constrained Delegation is enabled for the host in Active Directory.
Virtual machine migration operation for 'VMNAME' failed at migration source 'ComputerA2'.
The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host `ComputerA1`: No credentials are available in the security package (0x8009030E).
Failed to authenticate the connection at the source host: no suitable credentials available.

Results

Question

Q: Why does UserB get the error above when passing -ComputerName to the Move-VM cmdlet?

Non-Answers

UserB is not a domain admin of DomainA

If this were a problem, UserB would also FAIL when trying to use Move-VM without -ComputerName

You did not set up forest trust correctly

If this were true, UserB would also FAIL when trying to use Move-VM without -ComputerName

You didn't setup Constrained Delegation or Live Migrations properly

If this were true, no user would be able to move VMs.

Your CredSSP kerberos SPN name is invalid because NETBIOS didn't update the forest trust token before the tombstone lifetime expired on the PDCe

Well, maybe it's that.

While logged into HOST1, my user can successfully run this powershell command to move a running VM from HOST1 to HOST2:

Move-VM -Name DC02 -DestinationHost HOST2 -IncludeStorage -DestinationStoragePath "V:\Virtual Machines\DC02"

However, this command (which does the same thing because HOST1 is localhost) fails:

Invoke-Command {
  Move-VM -Name DC02 -DstinationHost HOST2 -IncludeStorage -DestinationStoragePath "V:\Virtual Machines\DC02"
} -ComputerName HOST1

The error is:

Move-VM : The operation on computer 'HOST2' failed: WinRM cannot process the request. The following error with
errorcode 0x8009030e occurred while using Kerberos authentication: A specified logon session does not exist. It may
already have been terminated.
 Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
 After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or
use HTTPS transport.
 Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config.
    + CategoryInfo          : NotSpecified: (:) [Move-VM], VirtualizationException
    + FullyQualifiedErrorId : Unspecified,Microsoft.HyperV.PowerShell.Commands.MoveVM

When enabling verbose Kerberos I see this in the System event log:

A Kerberos Error Message was received:
on logon session DomainY\UserY
Client Time:
Server Time: 20:40:44.0000 12/8/2022 Z
Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
Extended Error:
Client Realm:
Client Name:
Server Realm: DomainY
Server Name: krbtgt/DomainY
Target Name: krbtgt/DomainY@DomainY
Error Text:
File: logonapi.cxx
Line: e02
Error Data is in record data.

Q: Why does the command fail when wrapped in Invoke-Command?

Hint pointing to forest trust: the failure happens for UserY but not UserX:

• HOST1, HOST2, and UserX are on DomainX
• UserY is on DomainY
• DomainX trusts DomainY via Forest Trust
• DomainY trusts DomainX via Forest Trust
• UserX is a Domain Admin on DomainX
• UserY is a Domain Admin on DomainY (although this doesn't matter)
• UserY is a in the BUILTIN Administrators group on HOST1 and HOST2 (which are in DomainX)

Setup

All computers running Windows Server 2019.

Domain A

Domain B

Forest Trusts

• DomainA.local trusts DomainB.local
• DomainB.local trusts DomainA.local

Scenarios

I present two scenarios below. Scenario A works as expected. I have a question about Scenario B.

Scenario A

[email protected] logs into WorkStation.DomainB.local and then from the Run prompt tries to open \\FileServer.

Q: Which FileServer will appear?

• a) FileServer.DomainA.local
• b) FileServer.DomainB.local

A: (b) [obviously -- we are using a DomainB user on a DomainB workstation]

Scenario B

[email protected] logs into WorkStation.DomainB.local and then from the Run command prompt tries to open \\FileServer.

Q: Which FileServer's shares will appear?

• a) FileServer.DomainA.local (because we are logged in with a DomainA username)
• b) FileServer.DomainB.local (because we are logged in to a DomainB computer)

A: None of the above. Instead an error message will appear:

\\FileServer is not accessible.  You might not have permission to use this nework resource.  Contact the administrator of this server to find out if you have access permissions.

The target account name is incorrect

Question

Can someone explain technically why Scenario B fails? Specifically:

1. How does the string "\\FileServer" translate to a particular computer?

   • Is DNS used? If not, what is used?
   • Does it resolve to FileServer.DomainA.local or FileServer.DomainB.local?

2. How SPN is related, specifically the fact that setspn -L FileServer shows non-fully-qualified names such as HOST/FileServer as well as fully-qualified entries such as HOST/FileServer.DomainB.local

My Guess

1. DNS (and arguably common sense) resolves FileServer to FileServer.DomainB.local
2. However, \\FileServer (CIFS/double-back-slash) resolves to FileServer.DomainA.local.
3. SPN (whatever that is) is "resolving" to FileServer.DomainB.local
4. The DomainA/DomainB mismatch in (2) and (3) is the source of The target account name is incorrect

I created a subordinate "enterprise" CA server using ADCS on an active directory domain. The root CA that signed this subordinate CA's cert is not part of the windows domain.

Q1: Does the active directory domain automatically trust the root CA that signed the subordinate CA's cert? Microsoft ADCS has access to this root CA cert (when I loaded the signed subordinate cert into the CA) and there is no reason for ADCS to not send the cert out to all domain members.

Q2: If not, what is the canonical/proper way to get the domain members to trust the root CA?