# Protected Group Members and Role Assignments

In environments where SessionLimit is integrated with Active Directory, you may run into the following situation:\
a user is a member of a protected group, but does not receive SessionLimit role permissions through an AD group.

### Protected Group Members Cannot Inherit Roles from Groups

If a user is a member of a **Protected Group** (SeProtectedGroup), such as:

* Domain Admins
* Enterprise Admins
* Schema Admins
* Account Operators
* Administrators
* Backup Operators
* Print Operators

this user will **not** be able to receive SessionLimit role permissions through an AD group assignment.

**Example:**

* You assign a SessionLimit role to an AD group.
* The user is a member of that AD group.
* But the user does not see or get the expected SessionLimit permissions.

**Reason:** this is caused by **protected account behavior** in Windows, not by a SessionLimit bug.

### Correct Solution

For users who are members of protected groups:

* **Do not rely** on AD group-based role inheritance for SessionLimit.
* Instead, **add the user directly to the desired SessionLimit role**.

In other words:\
**AD Group → Role mapping works for normal users, but protected users must be added directly to the role.**

### Why Does This Happen?

For protected accounts, Windows applies additional security restrictions, for example:

* Prevents automatic permission inheritance for some scenarios.
* Applies SID filtering and token cleanup.
* Only trusts **explicit** (direct) permissions instead of group-based inheritance in certain contexts.

Because of these mechanisms, SessionLimit role permissions:

* **Can** be granted to a protected user via **direct role assignment**.
* **Cannot** be reliably inherited via **group membership**.

**Important:** This is expected behavior in Active Directory and Windows security design.\
SessionLimit simply reflects what the OS and directory services provide; it does not override protected account handling.

### Practical Administration Tips

* For any admin-level user, first ask: *“Does this account really need to be a member of a protected group (e.g., Domain Admins)?”*
* Where possible, create a dedicated **SessionLimit admin account** that is **not** a member of protected groups.
* For accounts that must remain in protected groups (e.g. Domain Admins):
  * Assign the SessionLimit role **directly to the user**, not via group.

#### Troubleshooting Checklist

If a user cannot see or use a SessionLimit role you expect them to have, follow these steps:

1. Check which AD groups the user is a member of.
2. Compare those groups with the known **protected groups** list.
3. If the user is a member of a protected group:
   * Add the user directly to the relevant SessionLimit role.
   * Do not rely on group-based inheritance for this user.

### Common Real-World Scenario

**Scenario:**\
\&#xNAN;*“John is a member of the Domain Admins group. I added her to the ‘SessionLimitAdmins’ AD group, which is mapped to the SessionLimit Admin role, but she still doesn’t see admin permissions in the UI.”*

**Resolution:**\
Add John **directly** to the `SessionLimit Admin` role inside the SessionLimit UI.

### Summary

| Case                          | Role via AD Group Membership   | Direct Role Assignment |
| ----------------------------- | ------------------------------ | ---------------------- |
| Standard (non-protected) user | ✅ Works                        | ✅ Works                |
| Protected Group member        | ❌ Not reliable / Does not work | ✅ Works (recommended)  |

You can place this guide under the **“Tips & Tricks”** section of your SessionLimit documentation, wiki, or knowledge base.