0

We have a client who has the following setup:

  • DC01 with AD/DC, RD Gateway, DHCP, DNS, etc.
  • DC02 with AD/DC, DHCP, DNS etc.
  • TS01 with RD Services

The issue randomly occurs when a user attempts to remote in using the NetBIOS name. According to the logs, the kerberos ticket is successfully created on the DC, and then moments later the session disconnects from the Gateway. No logs can be found on the TS that indicate that an attempt was even made to the TS. If we change from the NetBIOS to the IP address, or the internal FQDN it will resolve and the user can connect, but this does not always happen.

After rebooting the TS, and no other changes, the users can connect to the TS.

We are unsure how to troubleshoot this further, as a workaround, we have attempted to do a weekly reboot schedule and that is not working. If anyone has any ideas on what logs we can look for, or what we can check to see what is causing the issue, that would be greatly appreciated.

Improve this question
5
  • What is the RD Gateway using for short/single label name resolution?
    – Greg Askew
    Sep 5 at 6:35
  • DNS, the WINS service is not installed/enabled on any servers in the network. But, LLMNR has not been disabled by GPO/registry entries for any of the DNS clients.
    – SkywalkerIsNull
    Sep 5 at 7:34
  • How is DNS resolving short names? Have you configured the GlobalNames zone? DNS name suffix search order?
    – Greg Askew
    Sep 5 at 11:07
  • Get-DnsServerGlobalNameZone -> Enabled: false, GlobalOverLocal: false, PreferAAAA:false, EnableEDnsProbes: true. BlockUpdates: true. So this one is not configured. Get-DnsClientGlobalSetting -> UseSuffixSearchList: true, SuffixSearchList: <correct.domain>, UseDevolution: true, DevolutionLevel: 0 For the ClientGlobal settings, there is only the single internal name, and no others in the list.
    – SkywalkerIsNull
    Sep 5 at 22:18
  • Well this morning it occurred again, and I have updated the original post with a correction. Even the FQDN does not work, only the IP address.
    – SkywalkerIsNull
    Sep 7 at 23:08

1 Answer 1

Reset to default
0

The root of this issue was Kerberos PAC. DC02 was not as up to date as was expected, and in the event logs, we found multiple Error Event 37s on DC01.

I used the command:

wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-Kerberos-Key-Distribution-Center']]]"

From the primary Domain Controller, and then identified multiple Event 37's

The resolution to this was to update DC02 to the most current cumulative update, and then monitor the event logs for any additional Event 37's over the next week.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .