Windows Azure VM- Error: The Remote Computer that you are trying to connect to requires Network Level Authentication (NLA)


 

Alright, this was an interesting issue! so thought of sharing with you all. It might come in handy!

I built my private domain controller and forest in Windows Azure IaaS named CORP. I created Affinity groups and a private network which helped with assigning static DNS IP for the DC. I also installed two member servers (VMs in Azure) with Windows 2012 R2 and SQL 2014 image from the Azure gallery. Attached them to the CORP domain and assigned the static DNS IP of the DC to the member server as it’s DNS Entry, though I kept DHCP IP for the member servers to use their own IP’s.

I had this limitation of 20 Procs in my subscription and I was running few Oracle, SQL and Windows VM’s, result I could only create the new SQL 2014 VM’s with minimum processors, and hence had to be satisfied with the bare minimum CPU cores and memory (2 Cores and 3.5 GB RAM).

Lately, I was asked to deliver a session on SQL 2014 In-Memory, MOA, Resource Governor and Cardinality Estimator for which I had no choice other than uplifting the infrastructure for one of the SQL 2014 VM’s (16GB RAM and 8 Cores).

Indeed it was easy to change right. Just go to the VM configuration and change the Virtual Machine size (See Figure 1):

image

Figure 1

So, I made the changes and the server was rebooted once the infrastructure uplift was done, and after the server came up I couldn’t connect with my domain credentials CORP\useraccount

I kept getting the following error:

[Window Title]
Remote Desktop Connection

[Content]
The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA. If you are an administrator on the remote computer, you can disable NLA by using the options on the Remote tab of the System Properties dialog box.

[OK]

Here is how the error looks like pictorially:

image

So, what is the solution? You will see numerous posts in the public domain asking for updating your RDP Client etc. and indeed that may apply (please verify if the above conditions are true to apply this solution

Solution:

For Azure VMs, when you increase the size of the VM (adding CPU and Memory), the network configuration is reset. This means that if you have a static DNS defined inside the VM, it would be set to DHCP assigned which is the public DNS in Azure.

Use local admin account to log on to the virtual machine and set the DNS to point to your DC. Alternatively, assign the IP address of the DC/DNS under DNS servers of virtual network.

Please let me know if you have any questions or concerns around this.


Comments (19)

  1. Lou Bergstrom says:

    I faced this issue today.  Your post resolved it for me!

  2. Rockett31 says:

    This happened to me regardless I had proper DNS setup in Azure. This happened when I was starting all virtual network servers in a row including AD DC server. Even when the DC was the first started server the subsequent servers didn't connect to AD properly as not the all DC services was already started. Then I got the error above.

    Solution: Just restart the server so it refreshes its connections to DC (there might be other better approaches than restart, would be interested 😉

  3. Jamesroxx says:

    Thanks for your post. I also had the same issue today and your post resolved it. 🙂

  4. Sandeep says:

    In my case the issue was resolved when following entry was added to registry;

    HKEY_LOCAL_MACHINESYSTEM CurrentControlSetControl

    Key: SecurityProviders

    Value credssp.dll

  5. Nicole Welch says:

    I had the same situation (resized my VM) and your post resolved the issue.  Thank you!

  6. Boleslaw says:

    I had same issue when I was manually changing ip configuration in my test environment and after installation of ADDS. Logging on local admin let me through 😉 Thanks!

  7. Noah Stahl says:

    I saw this with an Azure VM I had just created as a domain controller. Restarting the VM solved the problem in my case.

  8. Abhinav says:

    Thank you.

  9. Shashi says:

    I faced this issue just now.  Your post resolved it for me! Thanks!!!

  10. Michael says:

    I lost a connection to my RDS VM, its a shock, as it was working yesterday (ie I can logon locally). I tried downsizing , not working still asking for the NLA which I dont think I ever set. eventually set the dns in the network via Azure Portal  to the DC solved the issue. I kind of know I have to set my test DC and RDS to reserved IPs, unfortunately this happened before I tried to make changes. another rough learning day for me about Windows Azure

  11. Michele says:

    Each time I setup a static DNS and started an install I received an error stating that there was a pending reboot.

    I solved with Sandeep advise.

  12. Anonymous says:

    Indeed, not only that but it appears to reset the mac address too….!

  13. Anonymous says:

    also in my case, this was solved by rebooting the machine.. I had performed some changes on the VN

  14. Jody_WP says:

    Hey Tara ,

    Thanks a mill for the post. It resolved my problem.

  15. Sorin says:

    Another solution that worked for me, same error but in a slightly different scenario: I had a DC on-premises and a DC in Azure. Because the VPN connection between on-prem and Azure was broken and all the FSMO roles were on the on-prem DC, there was no possibility to access AD and verify credentials. I had to wait for the VPN connection to work and then everything went back to normal.

  16. Syed Arif says:

    I had the same issue in my environment. I have logged in locally as  administrator and found the server set to DHCP without DNS entries. then changed it to static IP with DNS.  thats it.. issue resolved !!

    Thanks,

    Syed Arif

  17. Brian Lilley says:

    Had this issue today, your post fixed it.  Thanks

    The clue was in the title!!  "cant connect to DC"

    If you didn't know that Azure's DHCP lease terms are so aggressive, we'd be stuck!

  18. Keith Lehman says:

    We have been facing the same issue since 3/27 at about 3 AM UTC, when two different AD servers in two different Azure data centers rebooted after Windows Update did its thing… This helps, in that it eliminates the NLA error. Unfortunately, after making the change none of the VMs have outbound or inbound internet access. I suspect it has to do with the DNS forwarding on the AD server, but do not know how to set that up. 🙁

    1. Interesting. Could you send me more details to tarasha@microsoft.com please?