search for: netrgetanydcname

...request, that lists (in order) DEADDOMAIN1, DEADDOMAIN2, WRONGDOMAIN, and DOMAIN (where WRONGDOMAIN is the NT4 domain, DOMAIN is correct, and DEADDOMAINs are trusted domains that no longer exist - I'm not sure why they're still trusted, but I'm told it's necessary) - send a NetrGetAnyDCName request for WRONGDOMAIN to correct DC - get a NetrGetAnyDCName response listing NT4DC (the correct domain controller for WRONGDOMAIN, but not what it should be talking to at all) - attempt RPC connections to NT4DC, which fail with protocol errors - second NetrGetAnyDCName cycle, same results - SA...

...ns a failure instead: > > > NT_STATUS_NO_SUCH_DOMAIN > > > FWIW, I think this is down to a difference in handling NetGetAnyDCName on Windows Server 2025 compared to 2022. On 2025, I see this in netlogon.log (nltest /dbflag:ffffffff): + 04/23 20:00:38 [CRITICAL] [2268] DOMTEST: NetrGetAnyDCName: domtest: No such trusted domain ... which matches up with a log entry in log.winbindd-DOMTEST + [2025/04/24 01:00:39.489494, 10, pid=694, effective(0, 0), real(0, 0), class=rpc_cli] ../../source3/rpc_client/cli_pipe.c:1028(rpc_api_pipe_got_pdu) + rpc_api_pipe: host WIN-NAFS39H19IE.domtest.howe...

...1:389 10.236.113.21:389 10.236.114.21:389 10.91.160.40:389 10.236.94.22:389 10.236.92.22:389 10.236.112.22:389 10.236.112.21:389 10.154.110.21:389 10.154.110.22:389 10.91.157.132:389 10.236.62.22:389 10.236.30.21:389 10.236.100.21:389 In Wireshark, I can see this request being made by the NetrGetAnyDCName call and the response from a local domain controller, but the contents of the packet are encrypted. This time the IP addresses for the domain controllers on the LPS domain are returned (so presumably the local domain controller Winbind is querying at this point knows about the LPS domain controller...