NexTool Solutions

In GLPI, a permission is not an on/off switch: it is the product of three axes that multiply together - profile, entity and interface. Getting that combination wrong is the number one cause of "access vanished" tickets and of visibility leaking between departments. This guide shows the real model, where the rights actually live in the database, and the pitfalls that only surface in a multi-entity environment.

The RBAC model on three axes

GLPI access control (RBAC, Role-Based Access Control) combines three independent dimensions that many people treat as one:

• Profile - the set of rights, that is, what the person can do (open, edit, delete, configure).
• Entity - the data scope, that is, where they can see: which organization, branch or department.
• Interface - how they navigate: Helpdesk (simplified, for the end user) or Central (full, for the operation).

The confusing part is that the three combine by assignment, not by automatic inheritance. The glpi_profiles_users table links a user to a profile inside an entity, with an is_recursive flag that decides whether the access cascades down to sub-entities. That is why the same user can be a Technician in the "IT" entity and Self-Service in the "HR" entity: two distinct rows in that table, each with its own scope.

The baseline profile matrix we use

Instead of customizing GLPI's seven factory profiles at random, we start from a lean matrix and clone from it. Fewer profiles with clear boundaries generate fewer incidents than ten nearly identical profiles nobody remembers the difference between.

Field rule of thumb: if two profiles differ by a single permission, they should probably be one. Profile proliferation is security technical debt: every extra profile is one more thing to audit.

Where the rights actually live

The Profiles screen (Administration > Profiles) is just a shell over the glpi_profilerights table. Each row holds the (profile, object) pair and a rights column that is an integer bitmask. Understanding this changes the game for auditing: instead of clicking through dozens of tabs, you read the right straight from the database.

-- Rights of a profile over key objects (the bitmask is an integer)
SELECT p.name    AS profile,
       pr.name   AS object,
       pr.rights AS bitmask
FROM   glpi_profilerights pr
JOIN   glpi_profiles p ON p.id = pr.profiles_id
WHERE  p.name = 'Technician'   -- match the name in your install language
  AND  pr.name IN ('ticket', 'computer', 'config', 'user', 'entity')
ORDER  BY pr.name;

-- Decoding the base bits (valid for most itemtypes):
--   READ = 1, UPDATE = 2, CREATE = 4, DELETE = 8, PURGE = 32
-- E.g.: bitmask 15 = READ+UPDATE+CREATE+DELETE (CRUD, no purge)

The base bits apply to most itemtypes, but objects like the ticket (ticket) pack extra flags into the same integer: visibility "own / own group / all", assign, steal, change priority. Do not guess those bits from memory - confirm them in the interface and validate with a test session before calling it done.

Quick diagnosis: who has what

Before touching any profile, snapshot the current state. This query answers "who has which profile, in which entity, and whether it cascades to the children" - exactly the picture that is most often missing in an access audit:

-- Who has which profile, in which entity, with or without recursion
SELECT u.name          AS user,
       p.name          AS profile,
       p.interface     AS interface,
       e.completename  AS entity,
       pu.is_recursive AS cascades_to_subentities
FROM   glpi_profiles_users pu
JOIN   glpi_users    u ON u.id = pu.users_id
JOIN   glpi_profiles p ON p.id = pu.profiles_id
JOIN   glpi_entities e ON e.id = pu.entities_id
WHERE  u.name = 'john.doe'
ORDER  BY e.completename;

Running this periodically - monthly at the very least - is the cheap way to catch privilege accumulation: former members of a group who are still Supervisor, or an administrative profile assigned "just to test" that nobody removed. In serious sustaining work, this SELECT becomes a scheduled report, not a manual hunt after the problem has already blown up.

Field pitfalls

While sustaining multi-entity client environments, the recurring "my permission vanished" ticket is almost never a bug: it is the session cache. GLPI loads the profile rights into $_SESSION at login time. If you adjust the bitmask while the technician is logged in, they keep the old rights until they switch entity in the selector or log in again. We learned to put "ask the user to log out and back in" right into the validation script, and to always test in a fresh or private session - otherwise you swear you configured it right and the user swears it does not work, both correct at the same time.

The others that generate the most incidents:

• "All" visibility for technicians - granting "see all tickets" makes the technician see tickets from every entity they have access to, not just their own. In a client with sensitive areas (HR, Legal) this is a silent leak. Prefer "own group".
• Forgetting is_recursive - assigning the profile on the root entity without ticking recursion means the user sees no sub-entity at all. The classic symptom is "I log in but I see nothing". The opposite, unwanted recursion, grants far too broad an access without anyone noticing.
• Central rights on a Helpdesk profile - the Helpdesk interface ignores most Central rights. Ticking asset permissions on a helpdesk profile does nothing; the menu simply does not exist in that interface.
• Assignment rules out of order - anyone using LDAP or SSO assigns profiles via Authorization assignment rules (RuleRight). The generic "assign Self-Service" rule must come last; if it sits at the top without "stop processing", it beats every specific rule and everyone lands as Self-Service.
• Not testing as Self-Service - many defects only show up in the Helpdesk interface. Keep one test user per profile and walk the real journey before releasing to production.

Profile hardening checklist

1. Start from the minimal matrix; clone profiles instead of editing the factory defaults.
2. Set ticket visibility to "own group" by default; "All" only with a written justification.
3. Review the is_recursive flag on every entity assignment.
4. Run the diagnostic SQL monthly and remove accumulated privilege.
5. Keep one test user per profile and validate in a fresh session after any change.
6. Restrict who edits Profiles and Rules: UPDATE on profile and rule is, in practice, an administrator right.

Need access control to external screens and systems from inside GLPI itself, with an auditable matrix? Take a look at the Access Matrix module. And if you would rather outsource the design and sustaining of the profiles, NexTool deploys and maintains multi-entity GLPI environments with access governance reviewed on a regular basis.

Reviewed by the NexTool Solutions team.