1

I have an environment with 12 VM's all running Windows Server 2016. One is a domain controller, all others joined to the domain. When I login via RDP to any of the computers it takes 2+ minutes. Most of the time displaying "Other User" and a loading graphic. Then it shows the Username with loading icon for a shorter period. Then finally logs in.

Multiple users multiple machines. Today I found that if I disable the windows firewall on the Domain controller, logins are super fast. As soon as I re-enable the firewall they are slow again.

I've found many questions with similar symptoms but none of the solutions have helped. After identifying the firewall seems to be the culprit I imagine its as simple as knowing what port to open.

Anyone have any ideas?

BYoung
  • 13
  • 3
  • A closed or blocked port wouldn't cause a slow connection, it would cause a "no" connection. If the port is blocked it's going to prevent communication with that port, not slow down communication with that port. – joeqwerty Sep 06 '19 at 23:49
  • 1
    But a blocked connection could cause slowing down on anything that tries to connect until it timeouts. A client processing group policies does exactly that. It might be that the starting session is processing some user policy. – Esa Jokinen Sep 07 '19 at 08:08
  • 1
    @joeqwerty, there's at least one counterexample to that - if the remote management firewall exceptions aren't in place on the remote machine, the `psexec` command will be slow to run but will eventually succeed. I haven't investigated this closely, but I think it is trying to connect over RPC and then falling back to using IPC$ after the RPC connection times out. It is plausible that the OP has run into a similar scenario. – Harry Johnston Sep 07 '19 at 21:43
  • BYoung, you might try using `psexec` to run the `netstat` command on the target computer while the logon is hung. It would look something like `psexec -s \\computername netstat -n` and you would be looking for connections that say `SYN_SENT` ... Process Monitor might be another option. Both psexec and Process Monitor are available from the Microsoft web site. – Harry Johnston Sep 07 '19 at 21:49
  • @HarryJohnston, Thank you this is just the ticket. Running netstat Identified a SYN_SENT to the domain controller for port 88. Adding a firewall rule in for Kerberos Key Distribution Center has resolved the issue. All clients now authenticate to RDP almost instantly. If you can past this comment in as an answer I'll happily mark it as Accepted. Thanks everyone for your helpful comments. – BYoung Sep 09 '19 at 13:55
  • I find it quite bizarre that a port required for proper DC operation was closed by the DC's firewall; the DC promotion process should take care of opening all required ports. – Massimo Sep 09 '19 at 18:59

2 Answers2

1

One often useful troubleshooting approach when you suspect a firewall issue is to use the netstat command, specifically

netstat -n

to look for connections that are in the SYN_SENT state. In this case, since the interactive user is logging in when the problem occurs, you would need to run the command remotely,

psexec -s \\computername netstat -n

Another option would be Process Monitor. Both the psexec command and Process Monitor are available free of charge from the Microsoft web site, and of course netstat is built into Windows.

In this particular case, the OP has confirmed that the problem was a failure to connect to the Domain Controller on port 88, and that adding a firewall exception for the Kerberos Key Distribution Center has resolved the issue.

Harry Johnston
  • 6,005
  • 4
  • 35
  • 52
0

It really sounds like there's a DNS issue with resolution or perhaps a site traversal/route issue. What are the results of an Active Directory health check?

Here's an AD health check example

  • Thanks for your valuable input, I was not familiar with the Best Practices Analyzer the article pointed out. I was able to resolve this with particular issue with a firewall adjustment, but I'm also digging into some of these results as well. – BYoung Sep 09 '19 at 13:57