The Identity Awareness blade has the capability of associating an IP address and a user.
Terminal Servers / Citrix communicate with the Security Gateway through a single IP. However, they are used to host multiple users. This new feature aims to provide the Security Gateway with the capability of identifying the originating user behind each connection that comes from these multi-user hosts.
This page provides answers to frequently asked questions (FAQ) regarding installation and operation of Identity Awareness support for Terminal Servers/Citrix.
All Windows Server versions from Windows Server 2008R2 and above (both 32 bit and 64 bit) are supported. From R77.20, Windows 8.1 is supported. In addition, the following desktop Operating Systems are supported - Vista, Win7, Win8.
Yes, installation of an Identity Agent is required. The Terminal Servers (TS) Identity Agent will control the connections from the TS/Citrix in a way that will allow the Identity Gateway to identify the user behind each connection. The agent will also install a TDI driver.
The TS Identity Agent can be downloaded from a link provided in the SmartDashboard. Open the gateway object of the Identity Server and you should be able to see the link.
Enable the TS/Citrix feature in SmartDashboard, from the 'Gateway Properties > Identity Awareness' tab. After the feature is enabled, configure the pre-shared secret and also set it in the TS Identity Agent Controller on the terminal server[s]. Detailed installation steps can be found in the R75.40 Identity Awareness Administration Guide.
The solution works by identifying the owner of the source process of each connection and controls the connection in a way that identifies the source user to the Identity Gateway. As a result, any remote application server software should work just fine.
It is highly recommended to reboot the system, but it is not mandatory
Once the installation of the TS Identity Agent is complete, all new connections will be identified and properly enforced. All other connections that were already opened, will not be under the control of the TS Identity Agent, and thus it cannot detect from which user they originated.
Therefore:
Rebooting will insure that the origins of all connections will be detected since the TDI driver will exist before the creation of these connections.
User logouts close all connections and terminate processes. The TDI driver catches users upon their next login to the system.
It is highly recommended to reboot the system, but it is not mandatory.
After the uninstall process ends, the TDI driver remains resident, but functions as a pass-through driver to allow the system to function properly without interruption. After rebooting, the TDI driver is removed. If an installation is initiated before the reboot, the TS Identity Agent will refuse to complete and request a reboot.
Agent compatibility: there is full compatibility between agents of version R76 or newer and gateways of version R76 or newer. For example: R77.20 agent will work with R76 gateway, and R77.20 gateway will work with R76 agent. In the same way, agents and gateways of R75.4x versions are compatible (e.g. R75.47 gateway with R75.40 agent).
The MUH agent can be installed either by using the prepackaged muhAgent.exe binary available on the gateway, or by using the MSI file with the “Terminal Server” flavor. Notice that MUH agent installation requires an additional step of configuring a shared secret used for safe communication with the gateway.
To explain it simply, the TS Identity Agent that is installed on the Terminal Server communicates to the Identity Server how it will control the connections for each user (explained below). This information is later used when the traffic reaches the Identity Gateway.
The TS Agent communicates with the gateway over SSL (usually port 443 unless configured differently).
The solution is in fact based on source ports. The TS Identity Agent installs a TDI driver that intercepts all requests from any process that requests a new connection. Once the request reaches the TDI driver, it queries the system to fetch the requesting user behind this new connection and chooses a source port from a pool of port ranges that is allocated for this specific user.
Two different users will have two different port range pools, thus allowing the Identity Gateway to distinguish between the different connection owners.
For unsupported protocols, the TS Identity Agent won't be able to control the network connections and therefore the Identity Server will not be aware of the user that is initiating these connections.
The Endpoint Identity Agent authenticates to the Identity Server either with a username and password or via a Kerberos Ticket. For the TS Identity Agent, the authentication of users is not issued the same way, and thus for the Identity Server to trust the other end, a shared secret is used. This is to remove the possibility that a user may use this ability to claim that he is running a Terminal Server and indicate a false user.
Non-admin users can access the Controller of the TS Identity Agent, but only in read-only mode. Thus, they will be able to see the connection statistics and port assignment information, but won't be able to change anything.
The solution supports TCP and UDP protocols only, therefore it will not support other protocols like ICMP, file shares, etc.
There is a limited number of users that can use the TS server at the same time and have network access. The number of users varies, and depends on the maximum number of ports the system is configured to assign to a user. In any case, the upper boundary is 1024 users per Terminal Server.
Yes. If you decide to use AD Query for users’ PCs, the best practice is to exclude the Terminal Servers’ IP addresses from AD Query. This will prevent unexpected agents’ disconnections and PDPD daemon high CPU utilization (see: sk86560 for instructions).
Processes running under SYSTEM and other local user accounts are all assigned source ports within a special port range that is not assigned any user identity. Enforcement for those users can be done through the machine identity (available through Kerberos SSO authentication). Any user accounts that belong to an Active Directory domain, including service accounts, can be identified by the TS agent.
Monitoring information is sent from each TS Identity Agent to the gateway. The information includes the following: IP, Version, Next Keep Alive, number of Connected Users, number of Authenticated Users and Number Of Assigned Ranges.
Monitoring capability is not enabled, by default. To enable it, please add a registry key named "MUHMonitoringEnabled" and set it to "1" (DWORD). The default frequency of sending the data is 15 seconds. Frequency is configurable by a registry key named "MUHMonitoringInterval" (for example, set as "60" to achieve a frequency of 1 minute). This is done under the following location:
For 32-bit machines:HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\IA\
For 64-bit machines:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CheckPoint\IA\
To apply these changes, reboot the machine (or restart the ‘Check Point Managed Asset Detection‘ service).
The capability was added in R80.20.
There are 2 options to query the data:
SNMP: The SNMP Object Identifiers (OIDs) that point to this information are found in $FWDIR/conf/identity_server.cps
Command Line:
Via cpstat cli: "cpstat identityServer -f muh"
Via pdp cli: "pdp muh status" - available only since R80.30.
If there is software used on the Terminal Server that uses a certain range of ports, there is a chance that it will conflict with our mechanism. Once you exclude those from this feature's usage (and the TS is rebooted), those ports will not be used.
Applies To:
muhagent
Multi-User Host Agent
Multi User Host Agent
MUH Agent
Terminal Servers Identity Agent
Give us Feedback
Thanks for your feedback!
Are you sure you want to rate this stars?
