none
Remote Desktop stopped working after disabling SSL 2.0 and TLS 1.0

    Question

  • I disabled SSL 2.0 and TLS 1.0 on our SBS 2008 server with SP2 (not R2).  We did this to make the Credit Card Vulnerability Scan people happy.  I used a Microsoft Fixit to do this, which edited the registry at HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols to do this.

    As soon as this change was made and the server was rebooted (reboot was required), then Remote Desktop connections to this server could no longer be made.  Previously we were connecting to the network with VPN then using the address 10.10.10.3 to connect to a Remote Desktop session with the server.

    LAN computers on the 10.10.10.0 subnet also cannot use Remote Desktop to connect to this server at address 10.10.10.3.

    I have tried the two RDP settings on the server "Allow connection from computers running any version of Remote Desktop" and "Allow connections only from computers runing Remote Desktop with Network Level Authentication", but neither setting makes a difference.

    I was worried disabling SSL 2.0 and TLS 1.0 would disable Outlook Web Access, but that still works fine.

    Thank you for your help.

    Monday, May 6, 2013 9:56 PM

Answers

  • Hi,

    Disabling TLS 1.0 will break RDP under default settings.  Did the security scan say specifically to disable TLS 1.0?  Normally you should be able to disable use of certain ciphers or prioritize ciphers.  You may want to try IISCrypto, on it you click the PCI button, then Apply button, then restart your server.

    Additionally there are still a substantial number of web browsers in use that do not support TLS 1.1/1.2.

    If you would like to continue with TLS 1.0 disabled you may change the RDP Security Layer.  To do this please open Terminal Services Configuration (tsconfig.msc), double-click RDP-Tcp, change Security Layer to RDP Security Layer.

    IMPORTANT:  You are vulnerable to MITM attack when using RDP Security Layer because there is no Server Authentication.  If you are running RDP over a VPN connection and there is no risk for interception then this may be okay.  I recommend you re-enable TLS 1.0 and have a ssl certificate from a public authority set on your RDP-Tcp listener.

    Thanks.

    -TP

    Sunday, May 19, 2013 8:36 PM
  • It's more likely something else as we have lots of other SBS boxes with these settings and rdp works fine.

    http://www.mywebhostingblog.net/hosting-security/check-list-for-remote-desktop-not-working/

    Check that out and what's the exact error message you are getting?

    Thursday, May 9, 2013 9:29 PM
    Moderator
  • I would set the 3389 back to the normal port and only use vpn to connect to the server.  Moving to another port doesn't really protect it, tsgrinder can check for rdp listening on another port.

    That said, this still isn't the issue and again, there's lots of others out here with pci adjustments made

    Do a netstat -ano is rdp listening on that port?

    Friday, May 10, 2013 8:59 PM
    Moderator

All replies

  • That shouldn't impact RDP.  Can you see if the firewall is blocking the connections?
    Wednesday, May 8, 2013 8:24 PM
    Moderator
  • I did check the Windows Firewall and the setting was correct.  Since we are connecting from the LAN, that should be the only firewall that could cause a problem.

    I had a remote connection when I disabled SSL 2.0 and TLS 1.0.  When the customer gave me the okay, I rebooted the server.  Ever since then I cannot use RDP to connect to that server and the local administrative user on that LAN who used to on the server each day via RDP can no longer connect either.

    Nothing else was changed.

    Thursday, May 9, 2013 9:17 PM
  • It's more likely something else as we have lots of other SBS boxes with these settings and rdp works fine.

    http://www.mywebhostingblog.net/hosting-security/check-list-for-remote-desktop-not-working/

    Check that out and what's the exact error message you are getting?

    Thursday, May 9, 2013 9:29 PM
    Moderator
  • When connecting from another comptuer on the LAN, it gives them message"This computer can't connect to the remote computer".  It gives this message immediately, with no delay whatsoever.

    I looked at the article you gave me.  Everything checks out fine according to that.  Remote Desktop is enabled on the SBS server, the port number is set fine, I can connect to the server from another computer with telnet using the RDP port number and the Terminal Server Service is running.

    I do have RDP on the SBS server set to an alternate port.  It has been set that way for at least two years (and working fine).  When I did the telnet connection I mentioned, I used the alternate port, and it connected fine, so I know the Windows Firewall is allowing the exception properly.

    I have dozens of servers set up like this at many different customer sites.

    Friday, May 10, 2013 8:43 PM
  • I would set the 3389 back to the normal port and only use vpn to connect to the server.  Moving to another port doesn't really protect it, tsgrinder can check for rdp listening on another port.

    That said, this still isn't the issue and again, there's lots of others out here with pci adjustments made

    Do a netstat -ano is rdp listening on that port?

    Friday, May 10, 2013 8:59 PM
    Moderator
  • I apologize.  Sometimes it is several days until I can get access to that server.  I hope to connect later today.

    I did to a netstat on Friday.  I found the process ID and the port was listed as "listening".  It listed svchost, I believe, and several processes were listed as part of that, including the terminal services service.

    I do realize that changing the RDP port is not helping the protection.  This port setting is left over from an earlier time when we did things differently and we were not using a VPN connection.

    I will try to switch it to the standard port later today.

    Tuesday, May 14, 2013 2:17 PM
  • I did set the port back to 3389 in the registry and rebooted the server, however we still cannot connect with Remote Desktop.  I can connect with Telnet to port 3389.

    The link you gave me for troubleshooting before just covered the simple things.  Do you have access to more troubleshooting steps for Remote Desktop?

    Wednesday, May 15, 2013 8:57 PM
  • Hi,

    Disabling TLS 1.0 will break RDP under default settings.  Did the security scan say specifically to disable TLS 1.0?  Normally you should be able to disable use of certain ciphers or prioritize ciphers.  You may want to try IISCrypto, on it you click the PCI button, then Apply button, then restart your server.

    Additionally there are still a substantial number of web browsers in use that do not support TLS 1.1/1.2.

    If you would like to continue with TLS 1.0 disabled you may change the RDP Security Layer.  To do this please open Terminal Services Configuration (tsconfig.msc), double-click RDP-Tcp, change Security Layer to RDP Security Layer.

    IMPORTANT:  You are vulnerable to MITM attack when using RDP Security Layer because there is no Server Authentication.  If you are running RDP over a VPN connection and there is no risk for interception then this may be okay.  I recommend you re-enable TLS 1.0 and have a ssl certificate from a public authority set on your RDP-Tcp listener.

    Thanks.

    -TP

    Sunday, May 19, 2013 8:36 PM
  • Thank you for a good response. 

    The security scan did specify that certain ciphers could be disabled, but the links they gave had no information on how to do this.  I also could not find Microsoft articles about how to do it (that would have been nice).  I did find a Microsoft FixIt that I used to disable SSL 2.0 and TLS 1.0, and from the information I was reading, it looked like both were outdated and not as secure as they should be. 

    Is IISCrypto a program that needs to be purchased?

    Apparently there is a lot of confusion on this issue.  Many, many people read my post and had no response.  Then when I did get responses I was made to feel that I had missed something and I should just check my settings again (I always check over settings very carefully before posting).

    I am disappointed at how long it took for someone to take me seriously.  In the past I have been asked to run a Microsoft tool to gather information from a Server when there is an issue, and that has been a very helpful thing in getting problems resolved.

    Thank you very much for your help.

    Tuesday, May 21, 2013 1:21 PM
  • I have TLS 1.0 disabled on mine. 

    http://social.technet.microsoft.com/wiki/contents/articles/853.adjustments-for-pci-dss-scan.aspx

    The post I follow is that one, not a fixit.  The Microsoft tool you are referring to is done by partner support, not out here in the public forums.  None of us have access to that.

    The setting for rdp on SBS is not negotiate, not on TLS 1.0

    Tuesday, May 21, 2013 1:46 PM
    Moderator
  • Hi,

    IISCrypto is free, you may download it here:

    https://www.nartac.com/Products/IISCrypto/

    -TP

    Tuesday, May 21, 2013 2:00 PM
  • Thanks for that article, that will be helpful.

    I actually thought I was using the Partner Forums, like I have in the past.  When I wanted to start this post, I am pretty sure that I was on the Partner Forums, but I could not find the Forum for Small Business Server.  I eventually found it, but I must have accidently switched over to the Public Forums.

    Thanks for your time!

    Tuesday, May 21, 2013 5:05 PM
  • www.sbspartnerforum.info  They redid the forums and it may be harder to find the SBS section.
    Tuesday, May 21, 2013 5:08 PM
    Moderator
  • Dear Andy,

    Thanks for providing good information.

    But Microsoft released below update to add TSL1.1 and TLS1.2 in Windows Server 2008 SP2.

    https://support.microsoft.com/en-us/help/4019276/update-to-add-support-for-tls-1-1-and-tls-1-2-in-windows-server-2008-s

    So I have performed all the steps with registry settings as per the above Microsoft article but still the RDP is not working on Windows 2008 SP2.


    Monday, November 20, 2017 6:41 AM