Using network-level authentication (NLA), instead of the older terminal services method, is quicker and more secure.
Moving from Windows Server 2003 Terminal Services to Windows Server 2008 R2 Remote Desktop Services has become a fairly common upgrade path. As people make this upgrade, you’ll often hear them wondering why the user connection experience between the two versions is so different.
When connecting to a 2003 Terminal Server, a user starts a session and types in their credentials. When using an RD Session Host server, a user typically enters credentials into a client-side dialog box. By default, clients that don’t support a technology called network-level authentication (NLA) can’t connect. Why the difference? There are reasons why Microsoft introduced network-level authentication, and reasons why it’s indeed a good thing.
NLA forces the client computer to present user credentials for authentication before the server will create a session for that user. Because of that process, it’s sometimes called “front authentication.” Servers that are running Windows Server 2008/Vista or later, and clients running Windows XP SP3 or later, support NLA. Because NLA relies on a technology called Credential Security Support Provider (CredSSP) Protocol, if you’re using a Remote Desktop Protocol (RDP) client for another OS, you’ll need to ask its developer if it supports NLA.
So why is presenting credentials before session creation such a good thing? There are two primary benefits to not creating a session until you’re sure the person attempting to connect is authorized to do so: it offers a layer of defense against Denial of Service (DoS) attacks and it speeds the brokering process.
Starting a session—even just presenting a logon screen—requires the server to create many of the processes required to support a session, such as Csrss.exe and Winlogon.exe. Because of this, session creation is expensive and relatively time-consuming. If a number of unauthorized users attempted to connect to a session at the same time, they could potentially block others from using that server because it created sessions to accept those false login credentials.
The performance issue is more critical. In Windows Server 2003, farms were relatively rare. Beginning with Windows Server 2008, farms became more common. Remember that each server in an RD Session Host farm is potentially a redirector. If the host server must create an entire session before redirecting a connection request to the RD Connection Broker, this slows down the connection time.
NLA uses CredSSP to present the user credentials to the server for authentication before creating a session. This process avoids both of those issues. Using CredSSP has other benefits as well. CredSSP can reduce the number of logons a user must make by storing credentials for a particular connection.
The first time a user connects to a new server, virtual machine (VM), or even another PC, they’ll need to provide their credentials. However, they’ll also have the option to save them. If they do, they won’t need to provide credentials again for that connection until they change their password.
The CredSSP Protocol helps applications securely delegate user credentials from a client to a target server. This protocol first establishes an encrypted channel between the client and the target server using Transport Layer Security (TLS) (as specified in [RFC2246]).
When you connect to an RD Session Host server with an RDC 6.x or later client, you might have noticed you don’t connect directly to the RD Session Host server logon screen to provide your credentials. Instead, a local dialog box pops up to take your credentials on the client. This dialog box is the front end of CredSSP.
When you type your credentials into this dialog box, even if you don’t choose to save them, they go to CredSSP. This then passes the credentials to the RD Session Host server via a secure channel. The RD Session Host server will only begin building a user session once it accepts those credentials.
Clients that support CredSSP and RDP 6.x and later will always use NLA if it’s available. Because CredSSP (the technology that supports NLA) is part of the OS and not part of RDP, the client OS must support CredSSP for NLA to work.
Therefore, although there’s an RDC 6.0 client available for Windows XP SP2, this doesn’t let Windows XP SP2 use NLA. Clients running Windows XP SP3, Windows Vista and Windows 7 all support CredSSP. Also, RDC will tell you if it supports NLA in the About screen. To see this, click the Computer icon in the upper-left corner of the RDC and choose About. This will indicate whether it supports NLA.
Windows XP SP3 supports CredSSP, but doesn’t have it enabled by default. To enable it, Microsoft released a knowledge base article with a Fix It for Me link. The article also explains how to enable CredSSP manually. Once you enable CredSSP, restart the computer.
If your client machine isn’t set up to properly support NLA you’ll get a message saying so when you attempt a remote connection to a machine that requires NLA. For example, if your Windows XP SP3 client doesn’t have CredSSP enabled, you’ll get this error when you attempt a remote connection to an RD Session Host server that required NLA: “The remote computer requires Network Level Authentication, which your computer does not support.”
RD Session Host servers don’t require NLA by default. You can configure them to permit connections only from computers that support NLA, either through Group Policy or on a per-server basis from RD Session Host Configuration.
To require NLA for connecting to the RD Session Host server on a per-server basis, open RD Session Host Configuration. Double-click RDP-Tcp (under the Connections section) and on the General tab select the checkbox next to Allow Connections Only From Computers Running Remote Desktop with Network Level Authentication. This will prevent any clients that don’t support NLA (namely, any client running RDC prior to version 6.x and any OS not supporting CredSSP) from connecting to the server.
To enable NLA via Group Policy, enable the following policy and apply it to the RD Session Host server OU: Computer Configuration | Policies | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Security | Require User Authentication For Remote Connections By Using Network Level Authentication.
Disabling or not configuring this policy means that NLA isn’t required.
For virtual desktop infrastructure (VDI) deployments, you can also restrict Windows Vista and Windows 7 to accept connection requests only from clients that support NLA. Go to Control Panel | System | Remote Settings. From the Remote tab of the System Properties dialog box, select the option to Allow Connections Only From Computers Running Remote Desktop With Network Level Authentication (More Secure).
This should explain why enabling NLA on your RD Session Host servers and VDI VMs is a good idea. You should understand how to require NLA on your servers and VDI VMs and how to setup your client computers to support NLA.
Certificates, while mentioned only briefly, are an essential piece of any RDS deployment. And that’s not just for NLA, but also Server Authentication, using RD Gateway, RD Web Access and even RD Connection Broker. Next time I’ll delve more into certificate requirements for RDS deployments.
Q. I am running Windows XP SP3. I’ve enabled CredSSP, but I still get the following error when connecting to an RD Session Host server that requires NLA: “An authentication error has occurred.”
A. There’s a hotfix that addresses this issue on my blog.
This error will also occur under this specific circumstance with these factors present:
Because NLA requires a secure channel over which it receives credentials, and it can’t create this tunnel if it doesn’t trust the certificate, NLA won’t work. To fix this,make sure the XP client machine has the certificate used to sign the RD Session Host server’s SSL certificate installed in its computer Trusted Root Certification Authorities certificate store folder.
Note: this specific error may vary slightly from RDC 6.x to RDC 7.0. If you install RDC 7.0, you might see this error message: “The connection has been terminated because an unexpected server authentication certificate was received from the remote computer.”