4

When connecting to a remote PC, I get this error:

enter image description here

But if I walk to the remote PC, login (with the same credentials) and walk back, RDP suddenly works. This happens each day. The remote PC might be powered off in between (I'll check this in the future).

Details:

  • remote PC: Windows 10, member of a domain
  • client: Windows 10 (not member of domain, at least not the same one)
  • used login credentials: a domain user (from the joined domain, obviously)
  • time is correct on both (checked with https://time.is)

Walking to the remote PC defeats the purpose of remote access, so I'm looking for help. Also, I would rather not disable NLA.

EDIT:

Another workaround is to use another remote access software, and perform a "local" login (they usually just mirror the local screen and keyboard, so this is possible). After that the RDP login usually works.

5
  • Not sure but I think the Client (PC connecting from) needs to be able to communicate with the domain controllers as well. Try adding DNS or host entries to the client machine from the domain that point to the domain controllers. Additionally, confirm that the server machine (connecting to), can resolve all the Domain controllers. Do nslookup domain.com and then ping each of the answers from both client and server machines. Jun 22, 2020 at 21:39
  • @duct_tape_coder Both can ping the domain controller (the %USERDNSDOMAIN% to be precise). Jun 22, 2020 at 22:29
  • But does the domain resolve? It's trying to hit domain.com, if it can't get a DNS answer for that, it'll fail. If that answer isn't a Domain Controller, it'll fail. Have you tried doing the RDP request twice in a row from the client to see if maybe it's a long delay in DNS resolution as well? Jun 22, 2020 at 22:38
  • @duct_tape_coder If it pings, then it also resolves. At least that is what I thought. Should I do any more checks about that? Repeated attempts don't work. I tried it several times, in a span of several minutes. Jun 23, 2020 at 11:43
  • Try verifying/setting your Netlogon service to Automatic, instead of Manual. Also, are you able to successfully RDP to the remote machine using a local account, instead of the domain?
    – Ulfy
    Jul 9, 2020 at 19:28

1 Answer 1

5

I have the exact same issue for months and spent my Sunday morning looking for the answer. Most pages that attempt explaining NLA actually don't explain anything about it, except one particular page that I found interesting/useful to understand the protocol: https://syfuhs.net/how-authentication-works-when-you-use-remote-desktop

Here is what I understood:

  • Without NLA enabled, an RDP connection initiates a "desktop" instance on the host, with the login screen. This takes up memory, resources, and potentially exposes the host to some attacks.
  • With NLA enabled, the RDP connection only creates a desktop once authentication has completed.
  • There are several ways this authentication can complete.
  • The first and simplest scenario is your client is a member of the same AD than the server. A KDS will be involved and your client will receive a key or token that will prove you have authenticated. This token will be submitted to the RDP host.
  • Your scenario (and mine) involve a client computer that is not member of the AD. Therefore any authentication protocol that involves talking to a third-party will fail. In that case, the protocol will in some way involve challenging the RDP client to decrypt a secret that only proper user credentials can decrypt.
  • But to generate this challenge, the RDP host must also know the credentials. For this, it needs to have the user's credentials cached. This is not the same and has nothing to do with cached logons: the actual password must be accessible to the host through some session level mechanism.
  • As this has nothing to do with cached logons, it has also no reason to be persistent across reboots: once the machine reboots, this information is lost.
  • Consequently: for the RDP server to be able to generate a secret that only the proper user credentials can decrypt, it must receive the user credentials at least one time after it has rebooted.

This explains why you need to log in at least once locally every time you reboot your AD computer. I suspect there is also an automatic expiration if you never reboot the machine but from my experience, it takes more than a few days to happen.

I guess there are many technical ambiguities or errors in what I said. Please bear in mind that this is a naive understanding of something I am not specialized in at all :)

Cheers.

5
  • 1
    Thanks, this is great information. Does not really solve the problem, but I gave it an upvote anyway. Jan 4, 2021 at 13:36
  • @DavidBalažic : Sorry, indeed I just tried explaining the situation but forgot to mention how to disable this. I was assuming your computer is governed by a domain policy that you cannot bypass. If you have domain admin rights, then you should be able to disable it through a GPO. This link could help: social.technet.microsoft.com/Forums/windowsserver/en-US/… Jan 8, 2021 at 18:16
  • So basically the answer is to disable NLA May 28, 2021 at 21:00
  • With the caveat that the non-NLA mode is ridden with security bugs, almost one published per month. As in "everyone with a script can login" type of bugs. Sep 2, 2021 at 13:09
  • Thank you, disabling NLA fixed the issue for me. Nov 30, 2021 at 16:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.