Reset Search
 

 

Article

KB21244 - NLA (Network Level Authentication) is not supported via Terminal Services (Windows Server 2012)

« Go Back

Information

 
Last Modified Date2/1/2016 9:27 AM
Synopsis
NLA (Network Level Authentication) is not supported via Terminal Services
Problem or Goal

NLA (Network Level Authentication) is not supported via Terminal Servers. This technology requires the connecting user to authenticate them before a session is established with the server. Originally, if you open an RDP (Remote Desktop) session to a server it will load the login screen from the server for you. This uses up resources on the server and is a potential area for denial of service attacks.

  1. When user tries to connect to the Terminal servers without PCS device, they are prompted for authentication window:

  2. But this feature of popping up for an additional authentication is not supported and users will get an error message.

    Error messages:
    "The remote computer requires that authentication be enabled to connect.
    Remote computer :10.130.35.226
    The connection cannot proceed because authentication is not enabled."


     
    "An internal state error has occurred.  The remote session will be disconnected.  Your local computer might be low on memory.  Close some programs, and then try connecting to the remote compter again"

  3. User debug logs report the following errors:
    dsTermServ.exe dsTermServProxy p6656 t1F60 dsWorkerThread.cpp:421 - 'DSWORKERTHREAD' onIOEvent( pTask=00B6CF90, TSIO_FD_CLOSE )
    dsTermServ.exe dsTermServProxy p6656 t1F60 dsWorkerThread.cpp:1217 - 'DSPORTMAPCONNECTION' [conn=00b6cd10] --> DoTX: saw FD_CLOSE, no data pending, tearing down...
    dsTermServ.exe dsTermServProxy p6656 t1F60 dsWorkerThread.cpp:941 - 'DisconnectFromServer' [conn=00b6cd10] disconnecting from destination 10.130.35.226:3389





    From the User Access Log:
    testuser(Users)[Users] - Logout from 10.9.222.167 (session:00000000)
    testuser(Users)[Users] - Closed connection to 10.130.35.226 port 3389 after 0 seconds, with 19 bytes read (in 1 chunks) and 19 bytes written (in 1 chunks)
    testuser(Users)[Users] - Connected to 10.130.35.226 port 3389
    testuser(Users)[Users] - Login succeeded for testuser/Users (session:00000000) from 10.9.222.167.
    testuser(Users)[] - Primary authentication successful for testuser/System Local from 10.9.222.167

    From the policy trace:
    testuser(Users)[Users] - Start Policy [HOSTPORT/WINTERMSERV] evaluation for resource 10.130.35.226:3389
    testuser(Users)[Users] - Applying Policy [test]...
    testuser(Users)[Users] - Action [Allow access] is returned
    testuser(Users)[Users] - Policy [test] applies to resource

    From the Wireshark capture:
    363 10.9.222.14 10.130.35.226 TCP 5840 34397 > ms-wbt-server [SYN] Seq=0 Win=5840 Len=0 MSS=1460 34397 ms-wbt-server
    366 10.130.35.226 10.9.222.14 TCP 8192 ms-wbt-server > 34397 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 ms-wbt-server 34397
    367 10.9.222.14 10.130.35.226 TCP 5840 34397 > ms-wbt-server [ACK] Seq=1 Ack=1 Win=5840 Len=0 34397 ms-wbt-server
    370 10.9.222.14 10.130.35.226  X.224 5840 Connection Request (0xe0) 34397 ms-wbt-server
    371 10.130.35.226 10.9.222.14 TCP 64240 ms-wbt-server > 34397 [ACK] Seq=1 Ack=20 Win=64240 Len=0 ms-wbt-server 34397
    372 10.130.35.226 10.9.222.14 X.224 64240 Connection Confirm (0xd0) ms-wbt-server 34397
    373 10.9.222.14 10.130.35.226 TCP 5840 34397 > ms-wbt-server [ACK] Seq=20 Ack=20 Win=5840 Len=0 34397 ms-wbt-server
    377 10.9.222.14 10.130.35.226 TCP 5840 34397 > ms-wbt-server [FIN, ACK] Seq=20 Ack=20 Win=5840 Len=0 34397 ms-wbt-server
    379 10.130.35.226 10.9.222.14 TCP 64240 ms-wbt-server > 34397 [ACK] Seq=20 Ack=21 Win=64240 Len=0 ms-wbt-server 34397
    380 10.130.35.226 10.9.222.14 TCP 0 ms-wbt-server > 34397 [RST, ACK] Seq=20 Ack=21 Win=0 Len=0 ms-wbt-server 34397

    where 10.130.35.226 is the Terminal server and 10.9.222.14 is the PCS internal interface.
     
Cause
Solution
This issue is resolved in 8.1R7+ and 8.2R1. See also KB40180 for more information on the new behavior.

If an upgrade is not possible, the workaround is to use Network Connect, WSAM / JSAM or Pulse Secure Desktop client with the native Windows remote desktop client.  If Terminal Services is needed, it is recommended to contact your regional sales representative to request to file an enhancement request.






 
Related Links
Attachment 1 
Created ByData Deployment

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255