> ## Documentation Index
> Fetch the complete documentation index at: https://syteca.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Client Permissions

> Reference for Syteca's six per-Client permissions — what each grants, OS scope, and a worked example showing how user-level and group-level permissions combine.

Client permissions define what a user can do with **specific Clients** — narrower scope than [administrative permissions](/docs/administration/users/administrative-permissions), which apply system-wide. They're granted on the **Client Access** tab when [adding](/docs/administration/users/users#add-a-user) or [editing](/docs/administration/users/users#edit-a-user) a user or [user group](/docs/administration/users/users#add-a-user-group).

<Note>
  Without the [administrative Client Installation and Management permission](/docs/administration/users/administrative-permissions), users only see the Clients they have at least one Client permission for. Otherwise, they see every Client in the deployment.
</Note>

<Note>
  Client permissions are granted **per Client or Client group individually** — there's no system-wide grant for these. To grant the same permissions across many Clients, use a [Client group](/docs/administration/clients/windows).
</Note>

## The six permissions

### Client Uninstallation

*Windows and macOS Clients only.*

Allows the user to [uninstall the Client](/docs/administration/clients/windows) (or all Clients in a Client group).

<Warning>
  If a user attempts to uninstall a Client they don't have this permission for, **the user is forcibly logged out** and the Client is not uninstalled.
</Warning>

### Client Configuration Management

Allows the user to define the [Client configuration](/docs/administration/clients/windows) — every option except the license assignment, which is gated by [License Management](/docs/administration/users/administrative-permissions#license-management).

### Viewing Monitoring Results

Allows the user to:

* [View the list of monitored Client sessions](/docs/session-monitoring/sessions-list) and the [forensic export history](/docs/session-monitoring/forensic-export#the-forensic-export-history-tab).
* View the [Client configuration](/docs/administration/clients/windows) *(read-only — modification requires Client Configuration Management)*.
* [Generate reports](/docs/session-monitoring/reports/ad-hoc-reports) for the Client.
* [Generate dashboards](/docs/session-monitoring/dashboards/user-activity-dashboards) containing data from the Client's sessions.

<Note>
  To actually **open** and play back the monitored sessions — viewing the screen captures and metadata — the user **also** needs the [administrative Viewing Monitoring Results permission](/docs/administration/users/administrative-permissions).
</Note>

### Viewing Text Data

*Windows and macOS Clients only.*

Allows the user to [view clipboard text data](/docs/session-monitoring/player/per-os-playback#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](/docs/administration/access/two-factor-authentication) — 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:

| User / Group | Administrative permissions                                                      | Client permissions              | For         |
| ------------ | ------------------------------------------------------------------------------- | ------------------------------- | ----------- |
| **Group1**   | Management Tool Access, User Management                                         | Client Uninstallation           | Client1     |
| **Group2**   | Management Tool Access, Database Management                                     | Viewing Monitoring Results      | Client2     |
| **Mark1**    | Management Tool Access, Client Installation and Management, Database Management | Viewing Monitoring Results      | Client1     |
| **Mark1**    | *(see above)*                                                                   | Client Configuration Management | All Clients |

### 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

<CardGroup cols={2}>
  <Card title="Administrative permissions reference" icon="key" href="/docs/administration/users/administrative-permissions">
    The seven system-wide permissions, granted alongside these per-Client ones.
  </Card>

  <Card title="Users and user groups" icon="users" href="/docs/administration/users/users">
    The day-to-day workflow for granting and revoking permissions.
  </Card>

  <Card title="Clients" icon="server" href="/docs/administration/clients/windows">
    The Client objects these permissions apply to.
  </Card>

  <Card title="Sessions list" icon="list" href="/docs/session-monitoring/sessions-list">
    What "Viewing Monitoring Results" actually unlocks.
  </Card>
</CardGroup>