TSA: How Does SonicWall Terminal Services Agent (TSA) Work?

03/26/2020 1142 15976

DESCRIPTION:
TSA: How Does SonicWall Terminal Services Agent (TSA) Work?

RESOLUTION:

Platforms and Supported Standards

The SonicWall TSA is supported on SonicOS Enhanced 5.6 and higher, running on SonicWall NSA Series and TZ 210 Series appliances and SonicWall TSA must be installed on any terminal servers in the domain.

Prerequisites

The following requirements must be met in order to run the SonicWall TSA:

• UDP port 2259 (by default) must be open on all terminal servers on which TSA is installed; the firewall uses UDP port 2259 by default to communicate with SonicWall TSA; if a custom port is configured instead of 2259, then this requirement applies to the custom port

• Windows Server, with latest service pack 
• Windows Terminal Services or Citrix installed on the Windows Terminal Server system(s)

SonicWall TSA Authentication Process

For users logged in from a Terminal Services or Citrix server, the SonicWall TSA takes the place of the SSO Agent in the authentication process. The process is different in several ways: 

• The TSA runs on the same server that the user is logged into, and includes the user name and domain along with the server IP address in the initial notification to the SonicWall UTM appliance.

• Users are identified by a user number as well as the IP address (for non-Terminal Services users, there is only one user at any IP address and so no user number is used). A non-zero user number is displayed in the SonicOS management interface using the format "x.x.x.x user n", where x.x.x.x is the server IP address and n is the user number.

• The TSA sends a close notification to the UTM when the user logs out, so no polling occurs.

Rather than being polled by the SonicWall UTM appliance, the TSA itself monitors the Terminal Services / Citrix server for logout events and notifies the SonicWall UTM appliance as they occur, terminating the SSO session.

How Does SonicWall Terminal Services Agent Work?

The SonicWall TSA can be installed on any Windows Server machine with Terminal Services or Citrix installed. The server must belong to a Windows domain that can communicate with the SonicWall security appliance directly using the IP address or using a path, such as VPN.

(1) A client logs into the network via the Terminal Services or Citrix server and attempts to access the Internet or other network resources for the first time.

(2) The TSA on the Terminal Services or Citrix server notifies the SonicWall UTM of the user’s name,
domain, the session ID, the connection IP address, port, and protocol. The UTM sends a reply.

(3) The SonicWall UTM queries the LDAP server or the local database for the user’s group memberships.

(4) The SonicWall UTM checks the groups against Firewall,CFS, and App FW policies, and grants access accordingly, allocates a user number for the user on the terminal server,and logs the user in.

(5) The user closes the Internet connection and the TSA notifies the UTM of the close.

(6) The user opens further connections, and steps (2) and (5),but not (3) and (4), are repeated for each connection.

(7) When the user logs out of the terminal server, the TSA notifies the SonicWall UTM of the logout and the user is logged out on the UTM.

Installing and Configuring SonicWall TSA

For Installing and Configuring the SonicWall TSA, please refer KBID 7996

Additional Info:

Multiple TSA Support

To accommodate large installations with thousands of users, SonicWall UTM appliances are configurable for operation with multiple terminal services agents (one per terminal server). The number of agents supported depends on the model, as shown in Table 3.

 Please Note: For all SonicWall UTM models, a maximum of 32 IP addresses is supported per terminal server.

Encryption of TSA Messages and Use of Session IDs: 

SonicWall TSA uses a shared key for encryption of messages between the TSA and the SonicWall UTM appliance when the user name and domain are contained in the message. The first open notification for a user is always encrypted, because the TSA includes the user name and domain.

Note: The shared key is created in the TSA, and the key entered in the SonicWall UTM appliance during SSO configuration must match the TSA key exactly. The TSA includes a user session ID in all notifications rather than including the user name and domain every time. This is efficient, secure, and allows the TSA to re-synchronize with Terminal Services users after the agent restarts.

Connections to Local Subnets
 
The TSA dynamically learns network topology based on information returned from the appliance and, once learned, it will not send notifications to the appliance for subsequent user connections that do not go through the appliance. As there is no mechanism for the TSA to “unlearn” these local destinations, the TSA should be restarted if a subnet is moved between interfaces on the appliance.

Non-Domain User Traffic from the Terminal Server

The SonicWall UTM appliance has the Allow limited access for non-domain users setting for optionally giving limited access to non-domain users (users logged into their local machine and not into the domain), and this works for terminal services users as it does for other SSO users. If your network includes non-Windows devices or Windows computers with personal firewalls running, check the box next to Probe user for and select the radio button for either NetAPI or WMI depending on which is configured for the SSO Agent. This causes the SonicWall UTM appliance to probe for a response on the NetAPI/WMI port before requesting that the SSO Agent identify a user. If no response occurs, these devices will fail SSO immediately. Such devices do not respond to, or may block, the Windows networking messages used by the SSO Agent to identify a user. 

Non-User Traffic from the Terminal Server 

Non-user connections are opened from the Terminal Server for Windows updates and anti-virus updates. The TSA can identify a connection from a logged-in service as being a non-user connection , and indicates this in the notification to the appliance. To control handling of these non-user connections, an Allow Terminal Server non-user traffic to bypass user authentication in access rules checkbox is available in the TSA configuration on the appliance. When selected, these connections are allowed. If this checkbox is not selected, then the services are treated as local users and can be given access by selecting the Allow limited access for non-domain users setting and creating user accounts on the appliance with the corresponding service names.