Cross forest WinRM failures

[robjstacey]

Thanks for the fantastic toolset! We have multiple domains and found that on some test Sources we get an error connecting to the DCs in a trusted forest from where we are running the tools, error like below: Connecting to remote server COMPUTERNAME failed with the following error message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer COMPUTERNAME. Verify that the computer exists on the network and that the name provided is spelled correctly. I've investigated and found that this happens only in some test and they appear to use the NETBIOS name, I've replicated the issue using the following against the external forest:

Invoke-Command -ComputerName DC1 {
Resolve-DnsName -Name DC2 } 

When I use the FQDN, the command works but when using the NETBIOS name it fails with the same error. Therefore is it possible to update the tests to use FQDN only or to have a switch to be able to choose between FQDN and NETBIOS names? Unless I've missed a way of doing this!

[PrzemyslawKlys]

Can you provide in which tests do you see this problem?

[robjstacey]

Sure: DCDnsResolveInternal DCDFS DCDiagnostics DCTimeSynchronizationInternal Looking at some of the code (I'm no expert @ PowerShell but can work things out a little), I think it's when any test uses the DC info from 'invoke-testimo' as it grabs the NETBIOS name: $Script:Reporting['Domains'][$Domain]['DomainControllers'][$DC.Name]

[robjstacey]

Forgot to put: The tests that call ADEssentials modules appear to grab the FQDN already.

[PrzemyslawKlys]

I'll do some debug on whether invoke-testimo fix would be sufficient or I need to fix specific functions. Not yet sure when as I am currently pushing GPOZaurr, but should get around it pretty soon.

[robjstacey]

Great thanks, if I can help let me know.

[PrzemyslawKlys]

You can always try to do it yourself ;-) Most likely changing it to $DC.HostName should do the trick.

https://github.com/EvotecIT/Testimo/blob/bc2c9500c408a61a936434e48765ae252830bc00/Public/Invoke-Testimo.ps1#L108-L118

You can test how it looks like yourself:

$test = Get-WinADForestDetails -Extended
$test['domaindomaincontrollers']['ad.evotec.xyz']

Domain                 : ad.evotec.xyz
HostName               : AD2.ad.evotec.xyz
Name                   : AD2
Forest                 : ad.evotec.xyz
Site                   : KATOWICE-2
IPV4Address            : 192.168.240.192
IPV6Address            :
IsGlobalCatalog        : True
IsReadOnly             : False
IsSchemaMaster         : False
IsDomainNamingMaster   : False
IsPDC                  : False
IsRIDMaster            : False
IsInfrastructureMaster : False
OperatingSystem        : Windows Server 2016 Standard
OperatingSystemVersion : 10.0 (14393)
OperatingSystemLong    : Windows Server 2016 (Long-Term Servicing Channel) 1607
LdapPort               : 389
SslPort                : 636
DistinguishedName      : CN=AD2,OU=Domain Controllers,DC=ad,DC=evotec,DC=xyz
Pingable               :
WinRM                  :
PortOpen               :
Comment                :

Domain                 : ad.evotec.xyz
HostName               : AD3.ad.evotec.xyz
Name                   : AD3
Forest                 : ad.evotec.xyz
Site                   : KATOWICE-2
IPV4Address            : 192.168.240.236
IPV6Address            :
IsGlobalCatalog        : True
IsReadOnly             : False
IsSchemaMaster         : False
IsDomainNamingMaster   : False
IsPDC                  : False
IsRIDMaster            : False
IsInfrastructureMaster : False
OperatingSystem        : Windows Server 2019 Standard Evaluation
OperatingSystemVersion : 10.0 (17763)
OperatingSystemLong    : Windows Server 2019 (Long-Term Servicing Channel) 1809
LdapPort               : 389
SslPort                : 636
DistinguishedName      : CN=AD3,OU=Domain Controllers,DC=ad,DC=evotec,DC=xyz
Pingable               :
WinRM                  :
PortOpen               :
Comment                :

So HostName would be there to pick instead of DC.Name.

I've fixed it in code, whether or not it's going to resolve your issue permanently - I believe so, but would require testing

[robjstacey]

Thanks, I've updated it locally and all seems to be working correctly! I'll carry on testing to see if anything else doesn't work, got plenty of other domains and forest :-(

[robjstacey]

DCDiagnostics and DCDFS still have some issues and I'm checking to see if it's something local.

[robjstacey]

I've managed to fix these two, when it calls the commands to do the actual test it doesn't pass the forest information on. I'm new to github so excuse shabby formatting and I'm not sure I can directly edit your code. Details below: DCDFS, current:

$DFS = @{
    Enable = $true
    Source = @{
        Name           = "SYSVOL/DFS Verification"
        Data           = {
            Get-WinADDFSHealth -Domains $Domain -DomainControllers $DomainController
        }

Proposed:

$DFS = @{
    Enable = $true
    Source = @{
        Name           = "SYSVOL/DFS Verification"
        Data           = {
            Get-WinADDFSHealth -Forest $ForestName -Domains $Domain -DomainControllers $DomainController
        }

DCDiagnostics, current:

$Diagnostics = @{
    Enable = $true
    Source = @{
        Name           = 'Diagnostics (DCIAG)'
        Data           = {
            Test-ADDomainController -ComputerName $DomainController -WarningAction SilentlyContinue
        }

Proposed:

$Diagnostics = @{
    Enable = $true
    Source = @{
        Name           = 'Diagnostics (DCIAG)'
        Data           = {
            Test-ADDomainController -Forest $ForestName -ComputerName $DomainController -WarningAction SilentlyContinue
        }

Updating these locally with the same fix you've done above on a test machine seems to have fixed the cross forest issues on the test sources I'm currently using.

[PrzemyslawKlys]

Good find. I've probably forgot to update all tests when I added support for it in testimo. WHile I can update it myself, don't you want to try and do a PR? Just make a fork/pr? I would love more people involved in this project.