On-Prem RDS NLA troubleshooting

[gregcharland]

Hi, I'm working to support integration of my customer with a new parent company.

Our environment, we'll call this Site A: Windows Server 2016 w/Essentials Role, Windows 2016 w/MultiPoint Role, Windows 10 Pro desktops (1909). Local AD Domain runs AAD Connect using password hash sync.

Is now connected using site-to-site VPN and 2-way forest trust to....

(We have site-to-site VPN to both Site 1 and Site 2 below)

Their environment:

Site 1:

2x DCs Windows Server 2016 Std

1x Terminal Server running Windows Server 2016 DC *this is just a Windows Server 2016 set up as a Session Host, there's no RD Gateway, Broker, etc because those things are hard <shrug>

Site 2:

1x DC Windows Server 2012

Mostly people connecting into our Multipoint server

Our users connect from the Windows 10 desktops and MultiPoint server (joined to our domain) into the Site 1 Terminal Server (joined to the remote domain) and primarily run an Access app there.

On a frequent basis our users get disconnected - they usually get the generic disconnected message....when they try to re-connect they generally get an NLA error. Anecdotally it appears to happen when Site A - Site 2 VPN connection drops.

I understand using NLA the RDS server tries to communicate back to the domain to authenticate the machine that's trying to connect.....but every article I find about RDS and NLA is "how to disable NLA," which we don't want to do.

Any resources or links discussing how to troubleshoot NLA in the RDS context? 

Beyond that....would the RDS be trying to authenticate the client PCs via the trust through its own domain, or contacting our DC directly? Which domain should we be nltest-ing?

Thanks in advance!

-Greg C

[#2]

---

try to re-connect they generally get an NLA error.

---

What error?

[#3]

@Dave Patrick 

Thanks....I don't have the initial disconnect error message handy but it did not reference NLA. 

But when trying to reconnect they see:

Remote Desktop Connection

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.

[#4]

From a windows perspective NLA uses port 389 to connect to domain controller so I'd check that port is open and that problem members have a healthy domain controller listed for DNS on connection properties and no others such as router or public DNS.

 . 

[#5]

@Dave Patrick 

Thanks, but I'm not quite there.

I understand in the NLA part the client PC negotiates a connection with the RD server and uses CredSSP to authenticate the user before allowing the full RDP protocol connection.

But who's trying to connect, and to which DC?

Is the client PC negotiating with the local DC for a Kerebos ticket to present to the remote RDS server which then needs to traverse the domain trust back to the local DC to authenticate it?

I understand how everything fails when the VPN drops but I'd like to see if there's a way we can recover faster from VPN flaps....

Thanks in advance,

Greg C

[#6]

---

But who's trying to connect, and to which DC?

---

Client trys connecting to any domain controller. NLA = network location awareness so it can properly set the windows firewall profile.

[#7]

That doesn't line up with what I'm seeing....
the VPN drops for a minute
he local clients get disconnected from the remote domain RD server
VPN comes back up
local clients can't reconnect to the remote domain RD server for several minutes due to the NLA error

These same clients can access files and RDS servers on the in-house domain the entire time, so I don't think they have lost sight of their own DC or are re-configuring their firewall policies.

I'd really like to find a way to make the reconnection & re-authentication faster when the VPN comes back up....

Thx!

Greg C

[#8]

I'd suggest starting a case here with product support.

https://support.microsoft.com/en-us/hub/4343728/support-for-business