Locking down settings so users cannot change them

Written for Synergy 1 (v1.22.3) and Synergy 3 (v3.8.4), checked 17 October 2026.

Note - locked settings are part of Synergy Business Advanced (previously called Business Team) and Synergy Enterprise.

Use Synergy 1 (v1.22.3 or later) on every computer whose settings you lock. Earlier versions don't hold every lock against a standard user. The details are in our advisories: Synergy security advisories

How locked settings work

To fix settings on a computer so the people using it cannot change them, set them with Group Policy on Windows, a configuration profile on macOS, or a policy file. Synergy 1 and Synergy 3 apply them every time sharing starts, however the app is started, and gray out each locked control. In Synergy 1, pointing at a locked control shows Locked by your administrator. In Synergy 3, a locked control says Set by your administrator for this computer.

• A setting is locked because its key is present, whatever the value. Only include the keys you want to enforce.
• Remove a key, and the person's own setting is back the next time sharing starts.
• A lock applies to the computer that has it. In Synergy 3 that holds even for settings it keeps in step between your computers, so set the policy on every computer you want locked.
• The policy is a control for standard users. A local administrator can still change or remove it.

The policy is not the text-based server configuration file (the .conf file that describes your screen layout). That file is covered in: Creating and using text config files

Where the policy goes

Windows: Group Policy

For Synergy 1, use our Group Policy template, which puts every setting it can lock into the Group Policy editor and Intune: Synergy 1 Group Policy template

1. Download the template and extract it.
2. Copy Synergy1.admx into the PolicyDefinitions folder of your Central Store (or C:\Windows\PolicyDefinitions on a single computer).
3. Copy en-US\Synergy1.adml into the en-US folder inside it.
4. In the Group Policy editor, open Computer Configuration, then Policies (in a domain GPO), then Administrative Templates, then Synergy 1.
5. Set each policy you want to lock.

For Intune, import both files as an imported ADMX template instead of copying them. The policies are grouped under Security, Network, Privacy, Logging and System. An on or off policy locks the setting either way: Enabled locks it on, Disabled locks it off, and only Not configured leaves it to the person. A policy that holds a value, such as the port, removes its lock when it's Disabled. Allow only approved computers takes the list of approved fingerprints with it.

For Synergy 3, or without the template, set the policy under the product's registry key, with Group Policy Preferences (Computer Configuration, then Preferences, Windows Settings and Registry), Intune, or any tool that writes the registry:

• Synergy 1: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Synergy\Synergy 1
• Synergy 3: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Synergy\Synergy 3

Each section in the tables below is a subkey, and each key is a value in it: tlsEnabled in the security subkey, for example. For an on or off setting, use a REG_DWORD of 1 or 0. For any other setting, use a REG_SZ string. This turns encryption on and copy and paste off in Synergy 1:

reg add "HKLM\SOFTWARE\Policies\Synergy\Synergy 1\security" /v tlsEnabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Synergy\Synergy 1\core" /v clipboardSharing /t REG_DWORD /d 0 /f

Synergy 3 reads Group Policy only on Windows. Synergy 1 also reads a policy file there, covered below; where both set a key, Group Policy wins.

macOS: configuration profile

Deploy a configuration profile from your device management (MDM) tool, with a custom settings payload for the product's preferences domain:

• Synergy 1: com.symless.synergy
• Synergy 3: com.symless.synergy-3

Each section is a dictionary holding its keys, as true or false, a number or a string. Only values the profile manages count, so a preference someone writes to the same domain themselves is ignored. This turns encryption on and copy and paste off:

<key>security</key>
<dict>
  <key>tlsEnabled</key>
  <true/>
</dict>
<key>core</key>
<dict>
  <key>clipboardSharing</key>
  <false/>
</dict>

Without device management, use a policy file instead. Where a profile and a file both set a key, the profile wins.

Policy files

• Synergy 1 on Windows: C:\ProgramData\Synergy\Synergy.policy.ini
• Synergy 1 on macOS and Linux: /etc/xdg/Synergy/Synergy.policy.ini
• Synergy 3 on macOS: /Library/Application Support/Synergy 3/policy.ini
• Synergy 3 on Linux: /etc/synergy-3/policy.ini

Create the folder if it does not exist. On Linux the file name is case-sensitive. The Flatpak builds of Synergy 1 and Synergy 3 can't read a policy file, so install the DEB, RPM or Arch package on a Linux computer you want locked.

A Synergy.locked.ini file deployed for an earlier version of Synergy 1 keeps working where it is: C:\ProgramData\Synergy on Windows, /etc/xdg/Synergy on macOS and Linux, /Library/Synergy on macOS, or /etc/Synergy on Linux. Synergy 1 reads only the first file it finds, Synergy.policy.ini first, so keep one file on each computer.

Make the policy file changeable only by administrators

Set the file's permissions before Synergy 1 or Synergy 3 first runs. Both check who can change the policy file before they share, and if anyone other than an administrator can change, replace or delete it, sharing doesn't start:

• macOS and Linux: the file, and every folder above it, must be owned by root and not writable by anyone else.
• Windows (Synergy 1): the file and its folder must be owned by Administrators or SYSTEM, and only they may change or delete the file. Standard users can still create files in the folder, which Synergy 1 needs.

When the check fails, Synergy 1 shows Sharing can't start, naming the file other people can change. Synergy 3 shows Can't start, with "Sharing is stopped because your administrator's settings can't be trusted. Ask your administrator to check them." The steps for each system are under Deploying a policy file.

Settings you can lock

Synergy 1 and Synergy 3 lock the same settings, and these are the controls each one grays out. Every key goes under the section heading shown.

Security, under [security]

The certificate file must hold both the certificate and its private key. In Synergy 3, an empty certificate value locks the computer to the certificate Synergy 3 generates.

Copy and paste

The lock holds whichever role the computer has: a computer with copy and paste locked off shares no clipboard, whatever computer it connects to. Synergy 1 also reads clipboardSharing under [internalConfig], as earlier versions of this article gave it. The clipboard size limit can't be locked, so it is not a way to turn copy and paste off.

Logging, under [log]

Network

Locking remoteHost keeps a computer connecting to the server you choose. In Synergy 3 it sets the primary computer this one connects to, which Server IP shows when Synergy 3 is configured with an external config file.

Background service (Windows)

In Synergy 1, locking processMode grays out the whole background service group, Always run as system included.

Other settings

Synergy Enterprise never checks for updates, so it has no Check for updates on startup to lock. In Synergy 1, Restore Defaults in Preferences is grayed out while anything is locked.

No other setting can be locked. A key that isn't in these tables is ignored, with a warning in the log.

Files written for Synergy 1.20 and earlier keep working: Synergy 1 also accepts the old names, such as cryptoEnabled, tlsCertPath and tlsKeyLength under [General], and reads them as the settings above.

Approve the computers that can connect

To let only the computers you approve connect, set lockTrustedFingerprints to true and list their fingerprints in trustedFingerprints, both under [security]:

[security]
lockTrustedFingerprints=true
trustedFingerprints=fingerprint-of-computer-1,fingerprint-of-computer-2

Each fingerprint is a computer's SHA-256 certificate fingerprint, with or without its colons, and the list is separated by commas. The lock turns encryption and certificate checking on by itself. With the lock on and an empty list, no computer can connect, so check the list first when nothing connects.

A computer that isn't on the list can't connect, and nobody is asked to trust it. In Synergy 1 the person sees Computer not approved, showing the computer's fingerprint to give you. In Synergy 3, the list of other computers on the Security page says Chosen by your administrator, and Forget and Compare again are grayed out. Each Synergy 3 computer shows its own fingerprint on its Security page.

File format rules

• Every key sits under its section heading, such as [security], [core], [log], [client], [server], [daemon] or [gui], as in the tables above. The old 1.20 names are read from [General], or from before any heading.
• For on or off settings use true or false (1 and 0 also work). Do not use no, off or disabled: Synergy 1 reads these as true, and Synergy 3 ignores them.
• Save the file as UTF-8. A byte order mark and Windows line endings are both fine, so Notepad's defaults work.

Example policy file

This file requires encryption, lets only two approved computers connect, turns copy and paste off and fixes logging:

[security]
tlsEnabled=true
checkPeerFingerprints=true
lockTrustedFingerprints=true
trustedFingerprints=fingerprint-of-computer-1,fingerprint-of-computer-2

[core]
clipboardSharing=false

[log]
level=INFO
toFile=false

Deploying a policy file

Windows (Synergy 1)

Group Policy needs none of these steps. To deploy Synergy 1's file instead, create the folder and the file from your deployment tool (Intune, SCCM and GPO startup scripts all run as SYSTEM) or from an administrator account, before Synergy 1 is installed or first launched. Windows lets any standard user create folders under C:\ProgramData, and whoever creates one becomes its owner. So if a standard user launches Synergy 1 before C:\ProgramData\Synergy exists, that user owns the folder, and sharing doesn't start until an administrator takes it back.

Then lock the file itself down, so that only SYSTEM and Administrators can change it and standard users can only read it. In your deployment step, after writing the file:

icacls "C:\ProgramData\Synergy\Synergy.policy.ini" /inheritance:r /grant:r "SYSTEM:F" "Administrators:F" "Users:RX"

Leave the folder's own permissions as Windows sets them. On Windows, Synergy 1 keeps more than the policy file in C:\ProgramData\Synergy, whichever settings profile is in use: it rewrites the server configuration (synergy-server.conf) there every time the server starts, and keeps its TLS certificate and fingerprints in the tls folder inside it. Standard users need to be able to create files there, so read-only access on the folder stops the server from starting. With the "All users" settings profile, the shared Synergy.conf lives there too. The profiles are described in: Configure Synergy 1 for multi-user support

On a computer where the folder already exists, check who owns it and what standard users can do with the file:

icacls "C:\ProgramData\Synergy"
icacls "C:\ProgramData\Synergy\Synergy.policy.ini"

On the file, Users should show (RX) or (R) only, with (F) for SYSTEM and Administrators. If a user account shows (F) on the folder, that user created it. To give the folder back to administrators, open a command prompt with Run as administrator and run these commands, in this order:

icacls "C:\ProgramData\Synergy" /setowner *S-1-5-32-544
icacls "C:\ProgramData\Synergy" /reset
icacls "C:\ProgramData\Synergy\Synergy.policy.ini" /setowner *S-1-5-32-544
icacls "C:\ProgramData\Synergy\Synergy.policy.ini" /inheritance:r /grant:r "SYSTEM:F" "Administrators:F" "Users:RX"

The first command makes the Administrators group the folder's owner; *S-1-5-32-544 names that group in any language of Windows. The second removes the full control Windows gave the user who created the folder, and gives it to whoever owns the folder at that moment, which is why the owner changes first. The last two do the same for the file and lock it down again. A prompt opened without Run as administrator can't hand ownership to Administrators.

Fleet-wide deployment steps, including where this step goes in an Intune, SCCM or Group Policy rollout, are in: Deploying across your organization, including silent install on Windows

macOS and Linux

Create the folder and the file as root, so a standard user cannot change them. Synergy 1 on macOS or Linux:

sudo mkdir -p /etc/xdg/Synergy
sudo tee /etc/xdg/Synergy/Synergy.policy.ini > /dev/null <<'EOF'
[security]
tlsEnabled=true

[core]
clipboardSharing=false
EOF
sudo chmod 644 /etc/xdg/Synergy/Synergy.policy.ini

For Synergy 3, use the same commands with its paths: /Library/Application Support/Synergy 3/policy.ini on macOS and /etc/synergy-3/policy.ini on Linux. Quote the macOS path, since it contains spaces.

Checking that the lock is applied

Start Synergy 1 or Synergy 3 and open the settings. Each locked setting is grayed out, in the place the tables above give.

To see exactly what a computer has locked, run the Core with --locked-settings. It prints one line listing every locked setting and its value, where the policy came from, any problem with it, and any key it ignored. Synergy 1 on Windows:

"C:\Program Files\Synergy\synergy-core.exe" --locked-settings

• If a setting is missing from the list, check its spelling and that it sits under the right section heading.
• If a key is listed as ignored, it isn't one of the settings that can be locked.
• If a problem is listed, or sharing says it can't start, check the file's permissions as described above.
• If a control is grayed out but shows the wrong value, check the value: in Synergy 1, anything other than true, false, 1 or 0 is read as true.

Related articles

• Business & Enterprise Hardening Guide
• Configure Synergy 1 for multi-user support
• Deploying across your organization, including silent install on Windows