Session Recording is designed to be deployed within a secure network and accessed by administrators, and as such, is secure. Out-of-the-box deployment is designed to be simple and security features such as digital signing and encryption can be configured optionally.
Session Recording components is achieved through Internet Information Services
(IIS) and Microsoft Message Queuing (MSMQ). IIS provides the web services
communication link between each Session Recording component. MSMQ provides a
reliable data transport mechanism for sending recorded session data from the
Session Recording Agent to the Session Recording Server.
security recommendations when planning your deployment:
- Session Recording records session graphics activities without regard to the sensitivity of the data. Under certain circumstances, sensitive data (including but not limited to user credentials, privacy information, and third-party screens) might be recorded unintentionally. Take the following measures to prevent risks:
+ Disable core memory dump for VDAs unless for specific troubleshooting cases.
To disable core memory dump:
1. Right-click My Computer, and then click Properties.
2. Click the Advanced tab, and then under Startup and Recovery, click Settings.
3. Under Write Debugging Information, select (none).
See the Microsoft article at https://support.microsoft.com/en-us/kb/307973.
+ Session owners should notify attendees that online meetings and remote assistance software might get recorded if a desktop session is being recorded.
+ Ensure that logon credentials or security information does not appear in all local and Web applications published or used inside the corporation or they are recorded by Session Recording.
+ Users should close any application that might expose sensitive information before switching to a remote ICA session.
+ We recommend only automatic authentication methods (for example, single sign on, smartcard) for accessing published desktops or Software as a Service (SaaS) applications.
- Session Recording relies on certain hardware and hardware infrastructure (for example, corporate network devices, operation system) to function properly and to meet security needs. Take measures at the infrastructure levels to prevent damage or abuse to those infrastructures and make the Session Recording function secure and reliable.
- Properly protect and keep network infrastructure supporting Session Recording available.
- Citrix recommends using a third-party security solution or Windows mechanism to protect Session Recording components. Session Recording components include:
- On Session Recording Server
- Processes: SsRecStoragemanager.exe and SsRecAnalyticsService.exe
- Services: CitrixSsRecStorageManager and CitrixSsRecAnalyticsService
- All files in Session Recording Server installation folder
- Registry keys at HOTKEY_LOCAL_MACHINE\Software\Citrix\SmartAuditor\Server
- On Session Recording Agent
- Process: SsRecAgent.exe
- Service: CitrixSmAudAgent
- All files in Session Recording Agent installation folder
- Registry keys at HOTKEY_LOCAL_MACHINE\Software\Citrix\SmartAuditor\Agent
- Set the access control list (ACL) for Message Queuing (MSMQ) on the Session Recording Server to restrict VDA or VDI machines that can send MSMQ data to the Session Recording Server and prevent unauthorized machines from sending data to the Session Recording Server.
1) Install server feature Directory Service Integration on each Session Recording Server and VDA or VDI machine where Session Recording is enabled, and then restart the Message Queuing service.
2) From the Windows Start menu on each Session Recording Server, open Administrative Tools > Computer Management.
3) Open Services and Applications > Message Queuing > Private Queues.
4) Click on the private queue citrixsmauddata to open the Properties page and select the Security tab.
5) Add the computers or security groups of the VDAs that will send MSMQ data to this server and grant them the Send Message permission.
- Properly protect the event log for the Session Record Server and Session Recording Agents. We recommend leveraging a Windows or third-party remote logging solution to protect the event log or redirect the event log to the remote server.
- Ensure that servers running the Session Recording components are physically secure. If possible, lock these computers in a secure room to which only authorized personnel can gain direct access.
- Isolate servers running the Session Recording components on a separate subnet or domain.
- Protect the recorded session data from users accessing other servers by installing a firewall between the Session Recording Server and other servers.
- Keep the Session Recording Admin Server and SQL database up to date with the latest security updates from Microsoft.
- Restrict non-administrators from logging on to the administration machine.
- Strictly limit who is authorized to make recording policy changes and view recorded sessions.
- Install digital certificates, use the Session Recording file signing feature, and set up TLS communications in IIS.
- Set up MSMQ to use HTTPS as its transport by setting the MSMQ protocol listed in Session Recording Agent Properties to HTTPS. For more information, see Troubleshoot MSMQ.
- Use TLS 1.1 or TLS 1.2 (recommended) and disable SSLv2, SSLv3, TLS 1.0 on the Session Recording Server and Session Recording Database. For more information, see the Microsoft article at http://support.microsoft.com/default.aspx?scid=kb;en-us;187498.
Disable RC4 cipher suites for TLS on the Session Recording Server and Session Recording Database:
- Using the Microsoft Group Policy Editor, navigate to Computer Configuration > Administrative Templates > Network > SSL Configuration Settings.
- Set the SSL Cipher Suite Order policy to Enabled. By default, this policy is set to Not Configured.
- Remove any RC4 cipher suites.
- Use playback protection. Playback protection is a Session Recording feature that encrypts recorded files before they are downloaded to the Session Recording Player. By default, this option is enabled and is in Session Recording Server Properties.
- Follow NSIT guidance for cryptographic key lengths and cryptographic algorithms.
- Configure TLS 1.2 support for Session Recording.
- Citrix recommends using TLS 1.2 as the communication protocol to ensure the end-to-end security of the Session Recording components.
To configure TLS 1.2 support of Session Recording:
- Log on to the computer hosting the Session Recording Server, install the proper SQL Server client component and driver, and set strong cryptography for .NET Framework (version 4 or later)
a. Install the Microsoft ODBC Driver 11 (or a later version) for SQL Server.
b. Apply the latest hotfix rollup of .NET Framework.
c. Install ADO.NET - SqlClient based on your version of .NET Framework. For more information, see https://support.microsoft.com/en-us/kb/3135244.
d. Add a DWORD value SchUseStrongCrypto = 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFramework\v4.0.30319 and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319.
e. Restart the computer.
- Log on to the computer hosting the Session Recording Policy Console to apply the latest hotfix rollup of .NET Framework and set strong cryptography for .NET Framework (version 4 or later). The method for setting strong cryptography is same as substeps 1-d and 1-e. You can omit these steps if you choose to install the Session Recording Policy Console on the same computer as the Session Recording Server.
To configure the TLS 1.2 support for SQL Server with versions earlier than 2016, see https://support.microsoft.com/en-us/kb/3135244. To leverage TLS 1.2, configure HTTPS as the communication protocol for the Session Recording components.
For information about configuring the Session Recording security features, see Knowledge Center article CTX200868.