---
locale: "en"
updated_at: "2025-10-30T14:42:52.332Z"
canonical: "https://www.isdecisions.com/en/userlock/docs/reference/server-settings/permissions"
---

# Permissions

Define UserLock administration rights.

> **Note**
>
> - To access this page, go to **Server settings ▸ Permissions**.
> - You need at least *read* [permission](/userlock/docs/reference/server-settings/permissions) on **UserLock permissions** settings to view this page.

## Overview

The Permissions page defines **who can administer UserLock** and **what scope of actions they are allowed to perform**.
Permissions are assigned to **user accounts or groups from the Active Directory domain**, with each permission granted in **read** and/or **write** mode.

This allows you to:

- Apply consistent permissions to AD groups and users (e.g., Administrators, Helpdesk).
- Restrict access to sensitive features by limiting write permissions.
- Ensure accountability by defining exactly which AD accounts can perform which actions.

The *Details* column in the interface describes the exact scope of each permission.

![](https://a.storyblok.com/f/122374/899x911/4c489d35c0/server-settings-permissions.png)

## Default configuration

- At installation, the **Administrators** group is automatically added with **all permissions**.
- When you add a new operator, the **Activity / Reporting (read)** permission is enabled by default.

## Managing operators

- Use the **Add** button to add users or groups as operators.
- Use the **Delete the operator** button to remove an operator (changes take effect after saving).
- The **Update authorizations** button provides shortcuts to allow all, deny all, or set read-only permissions.

## Permission rules

- If you check **Denied** for a read permission, the related write permission is automatically set to Denied.
- If you check **Allowed** for a write permission, the related read permission is automatically set to Allowed.
- If you check **Denied** when adding or updating an operator, a warning is displayed.

> **Important**
>
> ⚠️ **Deny always takes precedence**, even if the operator belongs to another group that grants the same permission.

## Best practices and warnings

Because operator permissions grant administration rights in UserLock, you should handle them with caution.

- **Follow the principle of least privilege**
Assign only the permissions strictly necessary for each operator. Avoid granting Write rights if Read is sufficient.
- **Separate roles by responsibility**
For example:
  - Helpdesk: Read on sessions, Write on session actions
  - Security team: Write on access policies and MFA
  - Reporting/Compliance: Read-only on reporting and logs
- **Use groups whenever possible**
Assign permissions to groups rather than individuals. This simplifies maintenance and avoids forgotten accounts with excessive rights.
- **Review permissions regularly**
Audit operator permissions to ensure they still match your internal roles and responsibilities.
- **Be careful with Deny**
Deny overrides any Allow, even if granted through another group. Use it sparingly and only when you need to explicitly block an operator.