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. See How SonicWall Terminal Services Agent Works.

How SonicWall Terminal Services Agent Works

For installation instructions for the SonicWall TSA, refer to the Installing the SonicWall Terminal Services Agent.

Topics:
Multiple TSA Support

To accommodate large installations with thousands of users, SonicWall network security 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 Multiple TSA Support per Model.

 

Multiple TSA Support per Model

SonicWall Model

TS Agents Supported

NSA E8510

256

NSA E7500/E8500

256

NSA E6500

128

NSA E5500

64

NSA 5000

32

NSA 4500

16

NSA 3500

16

NSA 2600

8

NSA 2400

8

NSA 240

4

NSA 220

4

SOHO

Not supported

TZ 215 Series

4

TZ 210 Series

4

TZ 205 Series

Not supported

TZ 200 Series

Not supported

TZ 105 Series

Not supported

TZ 100 Series

Not supported

For all SonicWall network security appliances, a maximum of 32 IP addresses is supported per terminal server, where the server may have multiple NICs (network interface controllers). There is no limit on users 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 network security 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.

The messages between the appliance and the TS agent (and the SSO agent too) are DES encrypted (using triple-DES) and DES uses a numeric key that can be represented by a hexadecimal string. Each octet of the key requires two hex digits to represent its value, hence the key needs to be a even number of hex digits.

Using a hexadecimal key contributes to the encryption strength. For example, if a pass-phrase was used instead and converted to a numeric key, the end result would be no different than using the numeric-key directly and the pass-phrase would be more guessable than the hex representation of the key.

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, the TSA does 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 network security appliance has the Allow limited access for non-domain users setting for optionally giving limited access to non-domain users (those 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 network security 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 check box is available in the TSA configuration on the appliance. When selected, these connections are allowed. If this check box 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.