Connection Security - Citrix MetaFrame XP

There are multiple options configured at the "connection layer.

Remember from Chapter 2 that "connections" in the MetaFrame XP environment refer to the groups of settings that apply to a specific Session Protocol / Network Protocol / Network Interface combination. There are multiple options configured at this "connection layer." Many of them directly impact the overall security of the system. Additionally, there are many neat tricks that you can do to provide different levels of security to different interfaces.

Connection Properties

When configuring the properties of a connection (Citrix Connection Configuration Utility | Right-click on connection | Edit | Advanced Button), it is important to remember that those properties will affect all users that connect to the MetaFrame XP server via that connection unless you check the box for each item that allows the server to use the settings in each user's profile. (Checking this box will actually allow the setting to be configured from the user's profile or by a Citrix user policy.)

Let's examine each of the following connection layer security settings:

  • Session timeouts.
  • Working with broken connections.
  • Auto session logon.
  • Limiting the number of sessions per connection.
  • Disabling logons.
  • Encryption.
  • Using default NT authentication.
  • Initial programs to be executed.
  • Forcing Users to Run Only Published Applications
  • Session shadowing.
  • ICA TCP port.

Session Timeouts

You can configure three different timeout periods for each connection: connection timeout, disconnection timeout, and idle timeout. Each of these choices allows you to specify the timeout in minutes. The checkbox allows the timeout settings of the connection to default to those specified in the user profile as opposed to by the connection itself. This allows for different settings on a user-by-user basis. Selecting "no timeout" disables that specific session timer for that connection.

The "Connection" timeout allows you to specify the maximum time that an ICA session can stay connected. After this time passes, the server either disconnects or terminates the session. (The decision to terminate or disconnect the session is determined by the connection property setting outlined later.)

The "Disconnection" timeout causes the server to reset a disconnected session after the specified time has passed. This will cause the current user to lose any work that was in progress. The disconnection timer is a good way clean up any disconnected sessions that users have forgotten about. Many companies set this to something like 2880 minutes (48 hours). If they have some situations that require less time, they configure those in the user profile. If you configure disconnection timeouts for users in addition to the connection properties, the more restrictive setting will always take precedence.

The "Idle" timeout specifies the amount of time that a live connection can stay in an idle state (no activity) before the server automatically disconnects or resets the session. From a security standpoint, the idle timeout works well as an "automatic lock-down." Many companies set their idle timeouts relatively low so that if a user leaves his desk with an active ICA session open, the server will disconnect the session after a few minutes. Then, when the user returns to his desk, he can conveniently reconnect to his disconnected session, without losing any work.

Extreme care must be taken when working with these connection timeouts. Almost all environments that utilize connection timeouts configure them as a property of the user account (at the "user layer"), instead of configuring them here as a property of a connection. The one exception is the disconnection timeout, which are used to clean up any old sessions.

Working with Broken Connections

The term "Broken Connection" is used to specify what happens when an ICA client stops responding to the MetaFrame XP server during an ICA session. There are many things that can cause broken sessions, including network failures, power failures, and crashed client devices.

At the connection layer, you can specify what action should be taken when a connection is broken. Choosing to have the server disconnect the session will allow the session to maintain its state on the server, enabling the user to reconnect and pick up right where they left off. This often happens when client computers crash. After the crash, the user reboots, mutters a curse word or two, and reconnects to his existing session that is still running on the server. The server will maintain the disconnected session as long as the timeout period allows, with the "timeout period" being the shorter of the connection-layer disconnection timeout or user-layer disconnection timeout.

From a security standpoint, the broken connection action does not pose much of a security risk because users must successfully authenticate before they are given the option to reconnect to a broken session.

Reconnecting to broken sessions generally works best with explicit connections because anonymous users are not guaranteed that they will authenticate with the same anonymous account each time. If this happens, the server has no way of knowing which disconnected session belongs to that user.

You might be wondering about the "Auto Client Reconnection" that is available with Feature Release 1 and 2 and how it relates to the broken connection detection of a MetaFrame XP server. Auto client reconnect allows ICA clients to automatically reconnect to a MetaFrame XP server if their ICA session is interrupted. Auto client reconnection is a property of the client devices themselves and cannot be configured at the connection layer. For details on configuring auto client reconnection, see Chapter 10.

Reconnecting From Any Client

You can also decide whether you want to allow users to reconnect to disconnected sessions from any client device or whether users should be restricted to reconnecting only from the client device on which their ICA session was originally established. Some people perceive the ability to reconnect from any client as a security problem. In actuality, the security consequences are not that great because the user must authenticate on the new client before being able to reconnect to a session. Also, the user can only reconnect if the disconnected session was started with the same credentials as the new user. This means that one user cannot reconnect to another user's disconnected session.

Potential security problems arise when multiple users logon with the same user account to access MetaFrame XP servers. This is common in many environments for kiosks, common applications, or task-based workers. If a user authenticates with credentials that were used to start multiple sessions (which have since been disconnected) on one server, the user will be presented with an option to choose the disconnected session to connect to. It is possible that the user might pick a session that does not belong to him and be able to view privileged information or data.

Auto Session Logon

The AutoLogon parameters of a connection's advanced configuration will use one set of credentials to automatically log on any user that attempts to start an ICA session via that connection. This can pose a tremendous security risk, as any person could access to the system without being officially set up or authorized. It is relatively simple for a user/attacker to download and install the Citrix ICA client software and then to "discover" the Citrix server, connect to it, and be automatically logged on.

The AutoLogon settings are intended for point-to-point connections, such as the asynchronous RAS. AutoLogon in these cases is nice because users usually need to authenticate at other levels, as when the RAS connection is established. In these cases, AutoLogon prevents users from having to log on twice.

Limiting the Number of Sessions per Connection

The maximum number of concurrent sessions can be limited per connection on the connection's main property page. In general, this is not used to limit user connections because this limit applies to all users, including administrators. More often, administrators will create a dedicated connection for their own use (over a specific network interface), and limit the number of sessions to one or two as an additional security precaution,

Disabling Logons

Disabling logons is useful if a custom connection is needed from time to time, but you do not want to have the connection open all the time or have to recreate the connection each time it is needed.

Remember that disabling the logons of a connection does not cause existing sessions to be broken-it merely prevents additional users from being able to log on.

Encryption

The required level of encryption can be set at the connection level, affecting all sessions on the connection. The encryption levels are self-explanatory, except for "Basic." Basic encryption is not really secure and should not be used if you care about protecting your environment. Encryption is detailed fully in the "Network Security" section of this chapter.

Use Default NT Authentication

Checking this box forces user authentication to occur through the standard Windows authentication DLL, msgina.dll.

For example, if you install the Novell NDS Client on your MetaFrame server, the Novell client authentication and logon DLL (nwgina.dll) will replace the Microsoft DLL. This is why the "Press CTRL+ALT+DEL" logon screen is a Novell screen instead of the standard Microsoft screen after you install Novell's NDS Client. Checking the "Use default NT Authentication" checkbox will force ICA sessions to be logged on via the Microsoft client when that connection is used.

This is useful if you have two groups of users that connect to the same MetaFrame XP server. You can create two separate connections-one for each group of users. One connection ("ICA-IPX") for users that use the IPX protocol, can have the "Use Default NT Authentication" box unchecked, allowing them to logon with the Novell authentication. The other connection ("ICA-TCP") will be for users connecting via the TCP/IP protocol. This connection should have the box checked, forcing users to authenticate via the Microsoft logon DLL.

It should be noted that the end user experience is the same, regardless of whether the "User default NT authentication" box is checked or unchecked. The ICA client only passes the basic authentication parameters to the MetaFrame XP, and this checkbox merely specifies which DLL handles those parameters after they are received by the server. See Chapter 8 for more information about the GINA DLL.

Specifying an Initial Program to be Executed

A MetaFrame XP server connection can be configured to set the initial program for every user that connects via the connection. Setting the initial program at the connection layer functions in the exact same way as setting it for one specific user, except that the connection layer setting applies to all users on that connection, without exception. As soon as the user logs on, the specified program is run. As soon as the user closes that program, he is automatically logged off. At no time will the user ever see a desktop unless the desktop is specified as the initial program to run.

Specifying an initial program that is executed is a good way to lock down your server if all users will only need to use one program. The nice thing about it is that users still need to authenticate before the program is run (unless the AutoLogon is configured).

The downside to it is that since this is set at the connection layer, the initial program will affect everyone who connects, including administrators.

In the real world, setting the initial program at the connection level is most useful for MetaFrame XP servers that serve as public terminals or kiosk devices. In these cases, administrators often connect via a different protocol (such as RDP), ensuring that it is not possible to run any other application from the kiosk client devices.

As an interesting side note, even if a user connects to a published application over a connection that has the initial program specified, the initial program will run, not the published application. When the user closes that initial program, the connection is terminated. As you can see, when an initial program is specified, it doesn't matter how the user connects (full desktop or published application), the user will always run the program specified in the initial program setting.

Only Run Published Applications

Instead of forcing all users on one connection to run one specific program, you can require that all users only run published applications. Checking this box will prevent users from connecting to the server's desktop directly, unless the desktop is a published application.

Checking this box does not set any file or system-level security. For example, if this box is checked, but explorer.exe is a published application, a user could use explorer to run additional, non-published applications.

Full details of the security of applications on MetaFrame XP servers can be found in the preceding section of this chapter, "Application Security."

Session Shadowing

Basic session shadowing parameters can be set at the connection layer, such as whether shadowing is enabled and what type of notification or input the shadowed sessions have. Many organizations choose to set different shadowing parameters for different connections. Refer to the "Administrative Environment" segment of this chapter for more information on session shadowing.

TCP Port Used for ICA Sessions

By default, MetaFrame XP servers accept inbound ICA sessions via TCP port 1494. For added security, some administrators like to change this port number. This port can be changed in the registry in the following path:

Key: HKLM\System\CurrentControlSet\Control\ Terminal Server\WinStations\ICAConnectionName\
Value: PortNumber
Type: REG_DWORD
Data: Port number in hex (default 1494 = 5D6)

The "ICAConnectionName" in the above registry path is the name of the ICA connection you would like to change, for example "ICA-TCP." Because the ICA port configuration is a connection layer setting, you can configure different ports for different connections. After changing this port number, you need to stop and start the IMA service.

Remember that if you change the ICA port on the server, you must also change the port that the ICA client looks for.

In the real world, very few people change the ICA port, mainly because there are plenty of other security measures that can provide excellent security without the need to change the ICA port and they don't want to deal with configuring all of their ICA clients to use a nonstandard port. "Security through obscurity" has never worked well for anything.

Connection Permissions

In addition to the parameters of server connections that we reviewed previously, you can set user permissions separately for each connection. (Citrix Connection Configuration Utility | Right-click on connection | Permissions)

This allows you to specify user and group permissions at the connection layer, with the permissions affecting the configured users for each connection. You can select any user or group and then give them Guest, User, or Full Control for a given connection. You can also give a user or group "No Access" by unchecking every box.

In the event of a conflict (one user belonging to multiple groups with different permission levels), the most restrictive permissions apply.

It is important to understand that these permissions only affect the one connection where they are applied. It is possible for one user to have "Full Control" rights on one connection and "No access" rights to another.

Clicking on the "Advanced" button allows you to create granular permissions as needed. This does not allow you to give any more permissions than you could with the regular guest, user, or full access checkboxes. The "Advanced" button simply allows you to select only the specific options you need. For example, you could give one group "shadowing" permissions without having to give them full access rights. This would be accomplished by clicking the "advanced" button, selecting the group, clicking the "view/edit" button, and selecting the rights needed for that group.

  • Logon Rights (basic session use)
    • Guest
    • User
    • Full Control
  • Query information about the session
    • User
    • Full Control
  • Send Messages
    • User
    • Full Control
  • Connect to a disconnected session
    • User
    • Full Control
  • Modify connection properties
    • Full Control
  • Delete the connection
    • Full Control
  • Reset ICA sessions
    • User
  • Log off ICA session
    • Full Control
  • Disconnect ICA session
    • Full Control
  • Shadow ICA sessions
    • Full Control

Figure 15.4: Basic connection permission levels

For each line-item property, there are two boxes: allow and deny. If you select the deny box, the option is explicitly denied for that user or group, and this "deny" takes precedence over any other allow permissions configured in any other group, similar to the "no access" NTFS permission.

Advanced Permission: Allows the User or Group to...

  • Query Information: Obtain information about the current session
  • Set Information: Configure connection parameters
  • Reset: Reset other peoples' sessions
  • Shadow: Shadow other users[1]
  • Logon: Connect via selected connection
  • Logoff: Log off other users
  • Message: Send popup messages to other sessions
  • Connect: Reconnect to disconnected sessions
  • Disconnect: Disconnect other peoples' sessions
  • Virtual Channels: Use ICA virtual channel in a session

[1]Note: If shadowing permissions are configured that do not give users shadow rights, the users can still shadow themselves. There have been instances where helpdesk personnel without shadowing rights would ask an end user for their name and password. With that, the helpdesk people could log on as that user and then shadow them, even though the user was not given shadow rights.

Figure 15.5: Advanced connection permission properties

In the past, some people have recommended that you disable the RDP connection. While doing this would minimize your security risk, it actually increases your overall risk, because if there is a problem with your MetaFrame XP server that prevents an ICA session from connecting, you have no recourse unless you are physically located near the server. In the real world, most people choose to leave the default RDP connection active, but to configure the permissions so that only administrators are able to connect. That way you protect the connection while giving your own group a back door connection in case of trouble. (Of course if your administrator account is called "administrator" and its password is "password," keeping RDP active is a valid risk. If this is the case in your environment, you should put this book down and pick up a copy of Security for Dummies.)

Strategies for Using Multiple Server Connections

MetaFrame XP server connections can be used in creative ways to provide different types of security. All security configuration settings that are applied at the connection layer apply to all users that connect via the same protocol pair. However, there is nothing to say that you can't have more than one connection for each protocol.

If you put multiple network cards in a MetaFrame XP server, you can create multiple ICA-TCP connections, one for each card. To do this, change the LAN adapter for the connection's properties (Citrix Connection Configuration | Right-click the connection | Edit). Change the LAN adapter from "All network adapters configured with this protocol" to just the network adapter that you want to use. Then create a new connection for the other LAN adapter. Because each network card will have a different IP address, each connection will be accessible via a unique IP address and therefore a unique DNS name.

This will allow you to have a completely different set of properties for the same server, each accessible via its own unique address. This is useful if you want to provide different groups of users access to the same server, but you want different connection-layer settings to apply to each group. One group could access server1.yourcompany.com and the other group could access server2.yourcompany.com. In reality each would be using a different connection of the same server.

Advantages of Configuring Multiple Connections

  • If you need different connection layer settings on one server, this is the only way to do it.

Disadvantages of Configuring Multiple Connections

  • You need one physical network card for each unique connection.
  • Applications can only be published to the server. You cannot specify the connection over which an application is available.

Connection Configuration in the Registry

Because the connection parameters are properties of the MetaFrame XP servers, these parameters are not stored in the IMA data store. Instead, all of the connection configuration information is stored in the registry in the following location:

HKLM\System\CurrentControlSet\Control\TerminalServer
\WinStations\ICAConnectionName

Because this configuration information is stored in the registry, you can allow or deny specific users access to the appropriate registry keys. If a user has the ability to write to this registry key, then he will have the ability to change the parameters of MetaFrame XP connections, regardless of the permissions that are configured in the connection configuration.

 

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close