> ## 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.
# Block Users
> Syteca lets you block users on Windows Clients — manually while viewing their session, or automatically when an alert triggers — with a configurable forced-logout window, custom warning message, and central Blocked Users list.
## When detection isn't enough — stop the activity in 15 seconds
Detecting an incident is necessary; *stopping* it is harder. Most monitoring tools alert you when a user does something forbidden — at which point the user is still doing it, and your security team has to manually call IT to disable the account, while the data is already on its way out the door. By the time the response chain completes, the damage is done.
Some platforms support automated response, but they mostly require a separate SOAR product and a workflow that crosses two or three vendors. **Syteca user blocking** is the same idea, built into the same Client you're already running. Block manually while watching a session in progress (with a 15-second warning the user sees on their screen), or configure any alert to **automatically block on trigger**. The user is forcibly logged out across all Clients, can't log back in, and stays on the Blocked Users list until an admin manually removes them. No second product.
**Use Syteca user blocking when you need to:**
* Cut off **insider threats in real time** — credential abuse, privileged data theft, evidence destruction in progress.
* Stop **session-level incidents** instantly while you investigate — no waiting on IT to disable the AD account.
* Build **automated response into your alert rules** — define what triggers immediate blocking (specific file uploads, prohibited applications, time-of-day violations) and have it happen without human latency.
* Enforce **emergency access revocation** for contractors, terminated employees, or compromised accounts across every Client at once.
* Document **a complete incident-response audit trail** — who blocked whom, when, why, and from which Client.
**Pair it with [Alerts](/docs/session-monitoring/alerts)** — alerts detect the trigger, blocking is the response. Together they're the full detect-and-stop pipeline.
**Windows Clients only.** User blocking is not currently supported on macOS or Linux Clients.
Blocking users requires the [administrative Client Installation and Management permission](/docs/administration/users/administrative-permissions). The **Block User** button is disabled for users already on the Blocked Users list and for administrators without this permission.
## How blocking works
When you block a user — manually or via alert — three things happen:
1. **A warning message appears** on the user's Client desktop (for live sessions), and the desktop is blocked.
2. **After a configurable forced-logout time** (default: 15 seconds for live sessions), the user is forcibly logged out.
3. **The user is added to the [Blocked Users list](#the-blocked-users-list)**, either for the current Client only or for all Clients in the system.
If the user tries to log in again, they see: *"You have been blocked. Contact your system administrator."*
The Blocked Users list is stored on the Application Server. When you edit the list, every Client receives the update immediately. If a Client is offline at the time, it doesn't enforce blocking for new entries until the connection re-establishes — at which point it receives the latest list.
## Block a user manually
Manual blocking is for the moment you're watching a session and need to stop what you're seeing — either it's live and you intervene in real time, or it's a finished session and you want to prevent the user from doing it again.
On the **Activity Monitoring** page, click the live session to open it in the [Session Viewer](/docs/session-monitoring/player/overview).
In the main **Session Player** pane, click the red **Block User** button at the top.
In the **Block User** pop-up, configure:
| Option | Effect |
| ------------------------ | --------------------------------------------------------------------------------- |
| **On all computers** | Block this user on every Client in the system. User is logged out of all of them. |
| **On the computer** | Block only on the current Client. |
| **Forced logout time** | Seconds before the forced logout. Default: 15 seconds. |
| **Message** *(optional)* | Custom message displayed on the user's screen before logout. |
| **Reason** *(optional)* | Free-text reason for the block, shown on the Blocked Users list. |
Click **Block**. The warning message and blocked desktop appear on the Client immediately; the forced logout follows after the configured time.
On the **Activity Monitoring** page, click the session to open it in the Session Viewer.
In the **Session Player** pane, click the red **Block User** button at the top.
If the user is currently logged in to a Client computer, the blocking process is the same as for live sessions — they see the warning, get the configurable forced-logout window, and are logged out.
In the **Block User** pop-up:
* **On all computers** — block on every Client in the system. The user is logged out of all of them.
* **On the computer** — block only on the current Client.
Click **Block**. The user is added to the Blocked Users list.
## Block automatically when an alert triggers
The more powerful pattern: configure an [alert rule](/docs/session-monitoring/alerts) to automatically block the user the moment it triggers. No human latency — the response happens at machine speed.
Sign in to the Management Tool as a user with the [Client Installation and Management permission](/docs/administration/users/administrative-permissions), then click **Alerts** in the left navigation.
Click **Add Alert** in the top right, or click the **Edit Alert** icon next to an existing alert.
On the **Edit Alert** page, scroll to the **Assigned Clients** (or **Assigned Client Groups**) section and add the Clients the alert applies to.
Scroll to the **Actions** section. Select **Show warning message to user**, and optionally edit the warning text shown to the user.
In the **Additional Actions** drop-down, select **Block user on all computers**.
"Block user on all computers" applies the broadest possible block — useful for high-confidence alerts. For lower-confidence cases, consider notification-only first, then add blocking once the rule is well-tuned to minimize false positives.
Click **Finish** in the bottom right.
Now, whenever a user on the assigned Client(s) triggers this alert, they're automatically blocked across all Clients — no human intervention required.
## What the user sees on a secondary-authentication Client
If a Windows Client has [secondary user authentication](/docs/administration/access/two-factor-authentication) enabled, the system blocks the **primary-secondary user combination**, not just the primary user.
The flow:
1. The user logs into the Client with their primary credentials normally.
2. The Secondary User Authentication login window appears.
3. The user enters their blocked secondary credentials.
4. The system rejects the secondary credentials with: *"You have been blocked. Contact your system administrator."*
The block applies only to that specific primary-secondary user combination — other secondary users using the same primary credentials (or vice versa) are unaffected unless they're also explicitly blocked.
## The Blocked Users list
The Blocked Users list is the central record of every block in effect across your deployment — who's blocked, where, when, by whom, and why.
### Open the Blocked Users list
Click **Clients** in the left navigation, then click the **Clients** drop-down arrow at the top of the page and select **Blocked Users List** from the menu.
### The grid
| Column | Shows |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **\[Windows] User** | The blocked user — formatted as `\`, or `\()` for Clients with secondary user authentication. |
| **Blocked On** | A specific computer name, or "all computers". |
| **Blocked By** | The Syteca user who applied the block. |
| **Date** | When the block was applied. |
| **Reason** | The reason text entered when blocking (if provided). |
| **Remove** *(icon, per row)* | Unblock this specific user. |
| **Remove All** *(column header)* | Unblock every user on the list. |
### Unblock users
When the user is unblocked, they can immediately log back into Clients again.
On the Blocked Users list, find the row for the user.
Click the **Remove** icon next to the user.
Click **Remove** in the confirmation message.
In the column header on the right, click **Remove All**.
Click **Remove** in the confirmation message.
## Related
Define the alert rules that can trigger automated blocking.
Triage and update the status of every alert event.
Secondary user authentication — how blocking applies to the primary-secondary combination.
Where manual blocking starts — from the live or finished session you're viewing.