Client Permissions

Client permissions define what a user can do with specific Clients — narrower scope than administrative permissions, which apply system-wide. They’re granted on the Client Access tab when adding or editing a user or user group.

​

The six permissions

​

Client Uninstallation

Windows and macOS Clients only. Allows the user to uninstall the Client (or all Clients in a Client group).

​

Client Configuration Management

Allows the user to define the Client configuration — every option except the license assignment, which is gated by License Management.

​

Viewing Monitoring Results

Allows the user to:

• View the list of monitored Client sessions and the forensic export history.
• View the Client configuration (read-only — modification requires Client Configuration Management).
• Generate reports for the Client.
• Generate dashboards containing data from the Client’s sessions.

​

Viewing Text Data

Windows and macOS Clients only. Allows the user to view clipboard text data recorded during Client monitoring. Without this permission, the user sees clipboard records exist but not their contents — useful for restricting investigators from seeing sensitive clipboard content while still letting them audit clipboard activity patterns.

​

Access to Endpoint via Secondary Auth

Windows and Linux Clients only. Allows the user to log in to a Client computer where secondary user authentication is enabled — using their Management Tool credentials as the secondary credential layer.

​

Example of permission inheritance

The clearest way to understand how Syteca combines user-level and group-level permissions is a worked example.

​

Setup

• Mark1 is a user who belongs to Group1 and Group2.
• Client1 and Client2 are Clients, both in the default All Clients group.

The administrator grants the following:

​

Result: Mark1’s effective permissions

Administrative:

• Management Tool Access — Mark1 belongs to Group1 and Group2, but also has it directly. Persists even if Mark1 leaves both groups.
• Client Installation and Management — granted directly to Mark1. Independent of group membership.
• Database Management — Mark1 has it directly and inherits it from Group2. Persists even if Group2 is deleted or edited.
• User Management — Inherited from Group1. Removed if Mark1 leaves Group1.

Client permissions for Client1:

• Client Uninstallation — Inherited from Group1.
• Viewing Monitoring Results — Granted directly to Mark1. Persists regardless of group membership.
• Client Configuration Management — Mark1’s “All Clients” grant covers Client1.

Client permissions for Client2:

• Viewing Monitoring Results — Inherited from Group2.
• Client Configuration Management — Mark1’s “All Clients” grant covers Client2.

​

Takeaways

• Direct grants persist — they’re independent of group membership.
• Group-inherited grants disappear if the user leaves the group.
• Both layers stack — a permission granted in multiple places isn’t compounded; it’s just present.
• All Clients grants cascade to every Client (current and future) in the deployment.

For most deployments, the operational pattern is:

1. Define typical roles as user groups (Investigators, Operators, Admins, PAM Users) with the appropriate inheritable permissions.
2. Assign users to one or more groups to give them their baseline access.
3. Use direct grants sparingly for one-off exceptions (“Mark1 also needs Database Management”) that shouldn’t be tied to a group.

​

Related