locked
RDP issues, remote computers requires network level authentication RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    First of all, please note this: 

    • Network level authentication IS supported on all machines as per the About Remote Desktop Connection. So please don't ask me to check this on the about remote desktop connection window.
    • All clients are set per GPO to use the Remote Setting of the "more secure" option:
    • The problem is on random machines, all windows 7. We only have a few windows 10 machines but no issues found on those so far. 
    • It doesn't matter if the RDP connection is initiated from a windows 7, windows 10 or Windows Server 2012 R2. The problem remains and is exactly the same.
    • The problem exists when attempting to connect RDP from personal home PCs (not managed by company GPOs and MS update schedules) over VPN

    So the problem is this, first comes the first message and then the second.

    It seems to have started after we deployed some Microsoft server updates, but its very inconsistent, some sites seems worse off then others, but its not all machines at any site. We haven't even done client updates yet.

    Again, please don't give me a link to an old post or blog saying that I need to enable network level authentication, as shown by the top screenshot, it is already enabled/supported.

    I already spent hours googling this. Please, I want responses from people who have actually had the exact same symptoms and issues or someone who has an idea that I haven't already clearly stated that I've checked above already.

    Thank you.

    • Moved by Amy Wang_ Tuesday, January 19, 2016 3:08 AM RDS related from Windows Server General forum
    Tuesday, January 5, 2016 9:30 PM

Answers

  • Question
    Sign in to vote
    2
    Sign in to vote
    We deleted that RDS cert on the problem destination/remote/host PCs (even though they looked fine) and requested a new one. All good now. 
    • Marked as answer by Trana010 Sunday, January 31, 2016 10:38 PM
    Sunday, January 31, 2016 10:38 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello Trana010,

    As you stated it seems like the computer configuration on both sides are correct so this could be something between them that is not correctly configured or it is simply working as expected but we are not aware of it.

    As far as I can understand this is happening using a VPN, it means that the RDP is working fine within the same network (Workplace)
    If this is correct then you could check if there is a security mechanism on your network like a Proxy, Firewall, or maybe a Network Policy Server applying Network Access Protection to your network.

    Hope, this helps you to find more info related to this behavior. :D

    5ALU2 !
    Tuesday, January 5, 2016 9:53 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi YoElPirra, thanks for your response.

    Sorry if this was unclear, the problem is happening locally on the WAN and even on the LANs in each site as well as over VPN.

    For example,

    SiteTwoPC001 has the issue.

    SiteTwoPC002 doesn't have the issue.

    This is consistent when trying to RDP to these two PCs from: SiteTwoPC003 (same LAN), SiteTwentyPC001 (over the WAN), SiteOnePC001 (over the WAN) and HomePC001 (via VPN). 

    The same MS updates and GPOs should be in place on both SiteTwoPC001 and 002. Both are built using the same Windows 7 image via SCCM. No changes have happened on SiteTwoPC001 that hasn't happened on 002. 

    Tuesday, January 5, 2016 10:52 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    The problem is on random machines, all windows 7. We only have a few windows 10 machines but no issues found on those so far

    I assume that failed remote desktop connection issue only occurs on certain Windows 7 systems everytime a RDP request is made to these systems, is that correct?

    If that's correct, I suspect NLA might not be supported on the remote system, please open mstsc.exe, then right click on the top bar, select About, do you see NLA as supported or not?

    If NLA is not supported, please back up registry then modify registry entries on problematic system as this thread guides below:

    Network Level Authentication not supported on Windows 7

    https://social.technet.microsoft.com/Forums/windows/en-US/98f89f66-608e-4f6c-9417-67c1787457dc/network-level-authentication-not-supported-on-windows-7?forum=w7itprosecurity

    Best Regards,

    Amy

    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Edited by Amy Wang_ Tuesday, January 19, 2016 2:07 PM
    • Proposed as answer by Amy Wang_ Monday, January 25, 2016 8:44 AM
    • Marked as answer by Amy Wang_ Tuesday, January 26, 2016 3:11 PM
    • Unmarked as answer by Trana010 Wednesday, January 27, 2016 3:22 AM
    • Unproposed as answer by TP []MVP Wednesday, January 27, 2016 3:43 AM
    Tuesday, January 19, 2016 6:53 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Are there any updates at the moment?

    Best Regards,

    Amy

    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, January 25, 2016 8:45 AM
  • Question
    Sign in to vote
    2
    Sign in to vote

    I started responding but seems I got distracted and never submitted the reply.

    As clearly stated on the original post, NLA is supported according to this:

    I've already read 10 different versions of what you linked too. Their scenarios don't apply to my issue, NLA is supported on all systems, problem systems and non problem systems alike. These settings are handled by GPOs and MS patches deployed via SCCM and the update compliance is identical on all systems.

    Wednesday, January 27, 2016 3:25 AM
  • Question
    Sign in to vote
    2
    Sign in to vote

    Hi,

    Looking at your output, it appears the host PCs are not configured properly for NLA and/or NLA is "broken".  The error message is telling you the problem is with the client when in reality it is likely the host.

    1. On one of the problem Windows 7 hosts (not the client devices), please log on as an admin, open an administrator PowerShell prompt, and run the following:

    gwmi -Namespace root\cimv2\terminalservices -Class Win32_TSGeneralSetting

    Please reply with the output of the above command.  The output will have the name of the PC so you may want to obfuscate that part.

    2. Please open mmc, add Certificates snapin for Local Computer, and check to see if certificate in Remote Desktop store has expired or not.  Please reply with result.

    Thanks.

    -TP

    • Proposed as answer by Amy Wang_ Thursday, January 28, 2016 2:12 AM
    • Unproposed as answer by Trana010 Thursday, January 28, 2016 3:10 AM
    Wednesday, January 27, 2016 3:42 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi TP,

    Thanks for your response. 

    So by host, I believe you mean the remote system, if so I do agree, the problem is definitely on the remote system. Here is the gwmi output from one problem remote/host system

    And here is the cert:

    I can't really decipher much from the gwmi query but the cert looks fine obviously. Thoughts?

    Wednesday, January 27, 2016 5:42 AM
  • Question
    Sign in to vote
    3
    Sign in to vote

    Hi,

    Okay, that explains it.  It is set to RDP Security Layer for some reason, and this is incompatible with NLA.

    As a test, on this same machine, open up gpedit.msc and modify the following setting:

    Computer Configuration\ Administrative Templates\ Windows Components\ Remote Desktop Services\ Remote Desktop Session Host\ Security

    Require use of specific security layer for remote (RDP) connections     Enabled

    Security Layer:     SSL (TLS 1.0)

    After making the above change please test to see if the issue is resolved.  If it is fixed you might want to roll this out via domain GPO, or wmi, etc., to all workstations.

    NOTE:  You have two RDP listeners.  Is this intentional?  If not, if you could give me some history and/or an explanation of how you think the additional listener may have gotten there I would appreciate it.

    Thanks.

    -TP

    Wednesday, January 27, 2016 3:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi TP,

    Unfortunately that didn't help.

    new gwmi:

    I have absolutely no idea why we have two listeners, its old machines. Could it simply be from MS patches installing the new listener and not removing the old?

    Thursday, January 28, 2016 12:03 AM
  • Question
    Sign in to vote
    2
    Sign in to vote
    We deleted that RDS cert on the problem destination/remote/host PCs (even though they looked fine) and requested a new one. All good now. 
    • Marked as answer by Trana010 Sunday, January 31, 2016 10:38 PM
    Sunday, January 31, 2016 10:38 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Two RDP listener is definitely strange. Was this RDSH upgraded from 2003? This explains why NLA was failing as RDP 5.2 doesn't support NLA.

    Hari Kumar --- Disclaimer: This posting is provided AS-IS with no warranties or guarantees and confers no rights

    Monday, February 1, 2016 12:29 AM
  • Question
    Sign in to vote
    1
    Sign in to vote
    Hari, if you read the original post I clearly said the hosts are Windows 7. 
    Monday, February 1, 2016 9:34 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    This was a solution for me as well, where I had to apply the correct certificate to the listener. In my case, this was a server clone for testing and although it took a new certificate (server was renamed) it still had the old one listed in the RDP Listener properties.

    My solution:

    Windows 2008 Standard > Admin tools > Terminal Services > Terminal Service Configuration > Right click RDP-Tcp connection > Properties > General Tab

    The certificate showed as the old hostname even though the new certificate was showing under "select" . I clicked default > OK, then went back to the properties, which now showed no certificate under the general tab. I then clicked select, chose the same (new) certificate and hit OK. 

    Wednesday, February 1, 2017 5:11 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    The issue might be related to an expired machine certificate on the destination machine that you're trying to connect to. Use MMC to Add Certificates for Machine Snap-in to verify the expiration date of the certificate.

    Husam Hilal

    Friday, August 18, 2017 3:19 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    FWIW, we ran into the exact same issue as the OP (RDP didn't work after reboots after MS updates this month--with the same config/errors as the OP). Our "solution" was the same as the OP's:

    • Delete the personal computer certificate on the RDP-destination system
    • Run gpupdate /force in elevated cmd prompt (to obtain new computer cert from DC)

    It's important to note the existing computer certs were valid and supported "server authentication" (contrary to the verbiage in the "The identity of the remote computer cannot be verified" error message window. They were working for RDP fine prior to the reboots after the MS updates. Thus, I'm perplexed as to why they have to be renewed/re-obtained suddenly. 

    -- Jason



    • Edited by JasonBH Wednesday, September 27, 2017 10:22 PM
    Wednesday, September 27, 2017 10:21 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    To add to the thread, I had the same issue with none of the other solutions working.

    I ended up removing the machine from the domain then re-adding it. This got it working again for me.

    Friday, June 8, 2018 1:52 PM
  • Question
    Sign in to vote
    3
    Sign in to vote
    Just a note.  I just had same issue.  But after all my troubleshooting, I ended downloading the RD Connection Manager v2.7 and tested with and it worked.  So i further looked into and found a default.rdp file in my documents, which i deleted and then tested RDP and it worked!  Looks like there something being stored with that file that disabled NLA on the connections.
    • Proposed as answer by theSirk Sunday, August 26, 2018 6:32 PM
    Friday, July 27, 2018 4:46 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Yes You are Right !!

    1. Just Re Join machine in Domain 

    2. Or  delete existing rdp certificate from personal store certificate thru mmc and then restart machine ...

    Thursday, September 6, 2018 12:31 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thank you for sharing your solution!  I have been trying to figure out what the problem was for a few months now, come to find out it was as simple as deleting the default.rdp file out of my documents.  :)
    Friday, March 15, 2019 1:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Got the same kind of problem fixed with the help of these articles. Found the reason by checking the RDP host eventlog for errors and it had several from Key Storage provider.

    https://blogs.msdn.microsoft.com/kaushal/2012/10/07/error-hresult-0x80070520-when-adding-ssl-binding-in-iis/

    https://support.microsoft.com/en-ca/help/278381/default-permissions-for-the-machinekeys-folders

    Certificate store was missing privileges.

    Thursday, September 19, 2019 12:06 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    How did you request a new certificate?

    Monday, October 14, 2019 3:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    How did you request a new certificate?

    • Delete the personal computer certificate on the RDP-destination system's computer cert store
    • Run gpupdate /force in elevated cmd prompt (to obtain new computer cert from DC)

    -- Jason

    Monday, October 14, 2019 4:01 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Hi,

    I happened to have the problem you had, at least it looked like it from the symptoms. The topic is old, yet this could happen any time, so I will post what solved it in my case.

    As the systems except the server were freshly installed, I did not really trust all the certificate & registry issues to be the root cause.

    I was in the situation:

    A:

    - a bunch of new computers with Win 10 were added to a domain, controlled by a Server 2012. When the PCs were added to the domain, they were accessing the domain through a VPN from a foreign domain. This could be one of the essential circumstances in my scenario.

    - NLA clearly enabled on all, clients and servers. Enforced by group policy, including gpupdate /force etc. to make sure they get the settings. Here I had some strange observations already.

    - RDP at that point worked without any issues.

    B:

    - computers were relocated to the domain network.

    - from here: no RDP connection worked, all failed with the issue described in this thread.

    Solution:

     I removed a PC - just to test it - from the domain and tried to add it again. This failed as well. This is also how I googled and found out that in some cases, IPv6 can be part of the issue. So I disabled IPv6 on all clients, since then no further observations. It worked in the second I turned IPv6 off.

    I often hear that IPv6 does not hurt do be turned on, in this case it is cleary not true. I probably could have solved it by changing some kind of IPv6 things on the server (e.g. prefer IPv4 before IPv6, there are settings for this in the registry of the server), but this was the faster way for me (only few clients).

    Hope this helps the next person running into this problem.


    Monday, January 6, 2020 5:25 PM