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: “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.