Appearance
Application Security
Use this page to harden application servers and control how users run Turbo applications.
What You'll Learn
- Network protections for application servers
- How to enforce application allowlisting with AppLocker
- Answers to common Turbo Server security questions
Overview
Application servers run containerized applications for users. Containers limit changes to the host file system and registry, but you still need to restrict network access and executable access to prevent misuse. Combine network controls with application allowlisting to enforce your security posture.
Network Protections
Limit application server access to only the resources users should reach. If WinPcap is not installed, users cannot capture traffic with tools like Wireshark inside the virtual runtime. When you isolate application servers on their own network, ensure two-way HTTPS access to the Hub server and SQL Server so services remain available.
Securing Remote Access
Turbo uses temporary profiles on application servers: anonymized local accounts with randomized passwords that do not require domain authentication. NTLM is the default authentication method for these accounts when connecting over RDS.
If you need to disable NTLM for compliance, configure the settings under admin/general/streaming.aspx in the Network Security section:
- Require Network Level Authentication: Custom – Not enabled
- Restrict NTLM: Incoming NTLM traffic: Custom – Deny all accounts
- Restrict NTLM: NTLM authentication in this domain: Custom – Deny all
The default Windows values for these settings are Not Configured, Allow all, and Disable, respectively.
Use the table below to understand how EnableCredSSPSupport is applied by the native client when connecting to cloud RDP sessions.
| Require NLA | Restrict NTLM Traffic | EnableCredSSPSupport |
|---|---|---|
| false | false | false* |
| false | true | false* |
| true | false | true |
| true | true | true* |
| not set | any | true |
*Native clients always set EnableCredSSPSupport to true when you use Kerberos login mode. Temporary profiles do not work if both Require NLA and Restrict NTLM traffic are set to true; use Ask or Kerberos login modes instead. The HTML5 client also fails when both settings are true, so disable Run in Cloud (HTML5) to force Run in Cloud (Windowed) via the Turbo Client.
If Require NLA is not set, EnableCredSSPSupport remains true because modern operating systems enforce NLA by default. Group Policy follows the local computer setting when the policy is not explicitly configured.
Securing Execution With AppLocker
Use AppLocker or another application allowlisting tool to control which executables run on application servers. The following AppLocker policy allows only the Turbo Client to execute.
xml
<AppLockerPolicy Version="1">
<RuleCollection Type="Appx" EnforcementMode="NotConfigured" />
<RuleCollection Type="Dll" EnforcementMode="NotConfigured" />
<RuleCollection Type="Exe" EnforcementMode="Enabled">
<FilePathRule Id="921cc481-6e17-4653-8f75-050b80acca20" Name="(Default Rule) All files located in the Program Files folder" Description="Allows members of the Everyone group to run applications that are located in the Program Files folder." UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePathCondition Path="%PROGRAMFILES%\*" />
</Conditions>
</FilePathRule>
<FilePathRule Id="a61c8b2c-a319-4cd0-9690-d2177cad7b51" Name="(Default Rule) All files located in the Windows folder" Description="Allows members of the Everyone group to run applications that are located in the Windows folder." UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePathCondition Path="%WINDIR%\*" />
</Conditions>
</FilePathRule>
<FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">
<Conditions>
<FilePathCondition Path="*" />
</Conditions>
</FilePathRule>
<FilePublisherRule Id="a7863604-0cfa-429d-b8b0-3a9716e75757" Name="Signed by O=CODE SYSTEMS CORPORATION, L=SEATTLE, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-5-32-555" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=CODE SYSTEMS CORPORATION, L=SEATTLE, S=WASHINGTON, C=US" ProductName="*" BinaryName="*">
<BinaryVersionRange LowSection="*" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
<RuleCollection Type="Msi" EnforcementMode="NotConfigured" />
<RuleCollection Type="Script" EnforcementMode="NotConfigured" />
</AppLockerPolicy>Install the policy from an elevated PowerShell prompt:
powershell
Set-AppLockerPolicy -XMLPolicy c:\<path-to>\applocker-turbo-server-working.xmlThen open Group Policy Editor and navigate to Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker > Executable Rules to confirm the rules imported successfully. Restart the AppIDSvc Windows service after you apply the policy.
To view blocked executable events, open Event Viewer and browse to Application and Services Logs > Microsoft > Windows > AppLocker > EXE and DLL.
The allowlist above applies to the Remote Desktop Users group and does not block executables inside the Turbo virtual environment. To deny specific executables in the virtual environment, add additional FilePathRule entries such as:
xml
<FilePathRule Id="b68894c7-ecc7-4cc0-abe9-2317221bf221" Name="EXE Name Block: C:\*\minergate*.exe" Description="" UserOrGroupSid="S-1-5-32-555" Action="Deny">
<Conditions>
<FilePathCondition Path="C:\*\minergate*.exe" />
</Conditions>
</FilePathRule>FAQ
How are Turbo applications verified when users launch them?
You configure applications in the workspace, and those configurations are hashed with SHA-256. The Turbo Client verifies the hash before launch and refuses to start the application if a user tampers with the configuration.
What is a device key and why is there a local private key?
The device key registers the machine to Turbo Server for a specific user. The local private key signs the device identity for validation. Keep the private key secure on the device. If it is leaked, delete the device key registration from the administration site at admin/users/devicekeys.aspx.
Can end users modify the system drive on application servers?
Not by default. Turbo uses low-privilege local users to run applications, and those users do not have write access to the system drive. In Merge isolation mode, write attempts pass through and fail. In full or write-copy isolation modes, writes stay within the virtual environment so users perceive a writable drive without changing the host. You can also block drive modifications with Windows ACLs; see the Microsoft Windows documentation.
How are Turbo applications verified before they run on end-user devices?
Users must trust a domain before running an application from the Turbo Server portal. After the domain is trusted, the Turbo Client verifies the application image and settings with SHA-256. If the hash does not match, the client blocks the launch.
