Designing GLPI profiles and permissions for least privilege
A GLPI instance drifts toward broad rights when profiles are assigned to make a request work today and never reviewed afterward. Designing least-privilege profiles means deciding, for each IT role, which objects a person must read, create, update or delete, and which administrative actions they never need. In GLPI, a profile is a named set of rights over features such as tickets, assets, contracts, configuration and administration. A profile does nothing on its own: it is granted to a user together with an entity assignment, so the same person can hold a helpdesk profile in one entity and a read-only profile in another. Your effective access is the intersection of those two decisions, which is why a reviewer must check both rather than the profile name alone.
The seven default profiles are a reasonable starting point for a small team, but they are built for generic roles. Teams should redesign profiles when the organization has separate duties that the defaults merge, such as a service desk that should not edit asset records, a finance reviewer who needs contract visibility without configuration rights, or a regional team that must stay inside its own entity. Before changing anything, export the current assignments, list every user holding an administrative profile, and record who approved each one. Then draft the target roles on paper and map each one to the rights it needs. Test the draft on a staging copy of the instance, because profile edits take effect immediately for the users who hold them and mistakes are easy to miss in a long rights screen. Confirm the exact right names and their behavior in the version you run, using the GLPI user documentation as a starting reference and your own test results as the final word.
Most of the risk sits in a few places: the Super-Admin profile, recursive assignments that carry rights into child entities, and the life cycle matrix that governs what a ticket or asset can do at each stage. Each needs its own review step, covered in the sections that follow. Keep one named owner for the profile design, a short written rationale for every administrative profile, and a scheduled access review. Those three controls cost little to run and make later audits and leaver checks far easier to answer.
Profile design options and when each fits
This table compares the main ways to assign GLPI rights, from editing a default profile to restricting by group or authorization rule. Read each row for the situation it suits and the risk it carries, then check the chosen option against your entity tree and administrator roster before you assign it.
| Option | When it fits | Main risk |
|---|---|---|
| Edit a default profile in place | Small instance with one administrator team and few differences between user groups | Changes reach every account already assigned that profile, so a single edit can widen or narrow access for people you did not mean to affect |
| Clone a default profile into a custom profile | Your role needs differ from a default, and you want the original kept as a reference point after upgrades | Clones drift from the defaults over time, and new rights added in a later GLPI version may not appear in your copy without review |
| Assign at the root entity | Global roles such as platform administrators or auditors who need to see every entity | Rights are granted across all child entities, which can expose client or division data to people who only need one site |
| Assign at a child entity | Site, department or client teams who should only work inside their own branch of the entity tree | Users may need access to records in a parent or sibling entity, and missing assignments create gaps that look like broken workflows |
| Recursive assignment | Managers or leads who must see their entity and every entity beneath it | Adding a new child entity later automatically extends the access, so new sites may expose data without anyone reviewing the change |
| Non-recursive assignment | Staff whose work stays in one entity, such as a local helpdesk team with no cross-site duties | Users who expect to see subentities will be blocked, which often leads to requests for broader rights rather than a fix to the design |
| Restrict by group | Teams whose membership is maintained in a directory and matches a clear function | Group membership changes outside GLPI can shift access without a profile change, so group sync and leaver handling must be checked |
| Restrict by authorization rule | Access that depends on directory or SSO attributes such as department, title or site, applied on each sign-in | Rules that overlap or conflict are hard to trace, and a rule that no longer matches leaves users with the wrong profile or none |
Build the profile model in sequence
This sequence turns a list of IT roles into a tested set of GLPI profiles, assigned at the right entity level. Each step ends with a check you can repeat after any change, so the model stays least-privilege as roles and entities change.
Inventory roles and the tasks each performs
Start by listing every role that touches GLPI, such as service desk agents, field technicians, asset managers, approvers, auditors and self-service requesters. For each role, write down the concrete tasks it performs, including the item types it creates, edits, closes or only reads. Involve the people who do the work, not only the administrators. The step is done when every role has a written task list and a named owner who confirmed it. Anything without an owner is a permission you will be tempted to grant by default later.
Map each role to the closest default profile
Compare each task list against the seven default profiles that ship with GLPI, and record the nearest match for each role. Do not choose a profile by its name alone. Check its rights in your installed version, because the defaults are a starting point and may grant more than a role needs. Note where a role needs something no default covers. The step is done when you have a one-line mapping per role and a short list of gaps, which will drive the cloning in the next step.
Clone the profile and trim rights
Duplicate each closest default profile rather than editing the default itself, so the original stays available as a reference. Remove every right that does not appear in the role's task list, then add back only the specific rights for the gaps you recorded. Work through rights by object type, such as tickets, assets, administration and configuration, and record the reason for each retained right in your change log. The step is done when each custom profile has a documented reason for every non-default right it holds.
Restrict and document the Super-Admin profile
Limit the Super-Admin profile to a small named group of accounts, and keep day-to-day work out of it. Confirm that no service or integration account uses it, and that each member has a separate, non-privileged account for routine tasks. Record who holds it, why, and how a grant is approved and removed. Check the result by listing the users assigned to Super-Admin and comparing that list with your approved register. The step is done when the two lists match exactly.
Test each profile with a non-admin account
Create a standard user account for each custom profile, and sign in as that user in a separate browser session or private window. Walk through the task list from the first step and confirm that each task works and that each prohibited action is refused. Repeat the test after every profile change, not only the first time. Keep a short test record with the date, the profile version and the result for each task. The step is done when every task passes and every refused action is recorded as expected.
Assign profiles recursively to child entities
Assign each profile to the entity where the role operates, and enable recursive assignment only where the role should reach child entities. Confirm the entity tree first, because recursive rights apply to every child below the chosen point. Avoid assigning at the root unless the role truly spans all entities. Then sign in as a test user in a child entity and confirm that items in sibling entities are not visible. The step is done when the test user sees the expected child entities and nothing outside them.
Check ticket and asset transitions in the life cycle matrix
Open the life cycle matrix for tickets and for assets in your installed version, and list the transitions each role needs, such as assigning, pending, solving, closing and reopening tickets, or moving assets between states. Compare that list with the rights in each profile. Pay attention to transitions that a role can trigger but not reverse, because those can leave records stuck. Confirm the result with a test ticket and a test asset per role. The step is done when each role can complete its required transitions and no unexpected transition is available.
Review the model on a fixed schedule
Schedule a recurring review of the profile model and assign an owner to it. At each review, compare the current user-to-profile assignments with the role register, remove access for people who changed roles, and rerun the test accounts after any GLPI upgrade, since profile rights can change between versions. Ask your team to confirm the review interval in your own policy. The step is done when the review record shows the assignments, the test results and any changes approved by the owner.
Using the life cycle matrix to limit ticket and asset actions
The life cycle matrix in GLPI adds a second layer of control on top of profile rights. Where a standard right says whether a profile can read or write ticket or asset objects, the life cycle matrix decides which actions remain available as an object moves through its states, such as a new ticket being processed, a closed ticket, or an asset that is in stock, deployed or retired. Use it when you want a technician to edit an open ticket but not reopen or alter a closed one, or to keep retired assets read-only for audit purposes. Before you rely on it, list the states your organization uses and decide, for each profile, which transitions must stay open and which must be blocked.
The difference matters in practice. A read or write right is granted per object type, so a profile with write access to tickets can change any ticket it can see, whatever its status. A life cycle restriction narrows that write access by status, so the same profile may be able to add a followup to a ticket but not delete it, or may be able to change an asset in use but not one marked as disposed. Teams often over-grant because they set the broad write right, test it with an open ticket, and never test the closed or retired state. Others copy a permissive profile from a default and assume the matrix matches their process. Build a test matrix with one user per profile and one object per state, then record what each user can do.
Treat the matrix as configuration that changes with the GLPI version and with your process. The behavior, the available transitions and the labels can differ between releases, including the 11.x line and the 12.0.0 release, so confirm the matrix behavior in the exact version you run against the GLPI documentation for that release before you write it into your access design. Also confirm whether plugins for ticket or asset types honor the same restrictions, because a plugin object may not follow the core matrix. Keep the matrix under change control, and re-run your test matrix after every upgrade.
Protecting the Super-Admin profile
The Super-Admin profile in GLPI can change every other profile, entity and rule, so it is the highest-value target in the instance. The controls below work together: keep few accounts, use them rarely, record what they change, and make sure nobody can grant themselves that power unnoticed.
Limit Super-Admin accounts
Keep the number of accounts holding the Super-Admin profile as small as your change process allows, usually one or two named people plus the break-glass account. Every additional holder widens the set of people who can disable logging, reassign profiles or export data. Review the holder list on a fixed schedule and compare it with your joiner and leaver records. Ask your implementation partner to show where the profile assignments and their entity scope are reviewed in your configuration.
Keep a break-glass procedure
Plan for the case where the directory, SSO provider or assignment rules fail and nobody can sign in with a normal account. A break-glass account is a local Super-Admin login with a long, stored credential, used only under documented conditions and reset after each use. Test the procedure in a non-production copy so the steps work under pressure. Confirm how the account interacts with any SSO enforcement you configure, since a bypass that is too broad defeats the rest of the design.
Avoid Super-Admin for daily work
Administrators should work from a profile that covers their duties, such as ticket management or asset administration, and switch to Super-Admin only for tasks that require it. Daily use of the top role means routine clicks carry full rights and that logs mix ordinary work with privileged changes. Define which tasks genuinely need Super-Admin, such as core configuration or some plugin actions, and write that list into the operating runbook. Check the list against the real profile rights in your instance.
Log and review profile changes
Any change to a profile, its rights, entity assignment or the users holding it should produce a record that someone reviews. Export or retain these records outside the GLPI database if your policy requires tamper resistance, because a Super-Admin can alter local history. Set a review cadence, assign an owner, and compare recent changes against approved change tickets. Ask your partner which GLPI logs and history views are available in your version and how they are retained during backups and upgrades.
Restrict who can edit profiles
Editing a profile is itself a privileged action, so the right to modify profiles, rights and authorization rules should sit with a small group that is separate from the people who manage tickets or assets. Without this split, an administrator who can create users can also grant them the top role. Document the separation of duties, test that a non-privileged administrator cannot raise their own rights, and include the check in each post-upgrade validation. Newer GLPI releases add session and step-up controls for sensitive administrative actions, so confirm which of them apply to your version.
Security and operational considerations for profile design
A profile design is only as safe as the process that keeps it current. The cards below cover the controls a team needs to run after go-live: who reviews access, how leavers lose rights, how changes move between environments, and how the Super-Admin profile is guarded.
Privilege creep after role changes
When someone moves teams, the old profile and entity assignments often stay in place and stack on top of the new ones. Treat every role change as an access request: the new profile should be granted on purpose and the old one removed in the same change. In GLPI, check each user's profile and entity assignments after a move, and compare them with the role the person now holds rather than with what they used to do.
Leavers keeping access
Deactivating a directory account does not by itself reveal what a local GLPI account can still do, and local accounts may sit outside the joiner and leaver process entirely. Define an offboarding step that disables the GLPI account, removes profile assignments and reassigns open tickets and owned assets. Ask who runs this step and how it is checked each month against the HR leaver list.
Configuration drift between environments
Profiles edited by hand in a production instance can differ from the ones tested in staging, and the gap is hard to see from the user interface alone. Keep one written profile matrix as the source of truth, apply changes through the same steps in every environment, and record who approved each change. Confirm with your implementation partner how profile exports or database comparisons will be handled during upgrades.
Scheduled profile reviews
Permissions that were right at go-live drift as teams, plugins and workflows change. Set a recurring review, with a named owner per profile, that compares each profile against the life cycle matrix and the list of people assigned to it. Record the outcome, including profiles removed or narrowed, so the review itself can be shown to auditors later.
Protecting the Super-Admin profile
The Super-Admin profile can change almost any setting, so the number of holders should be small and each account should be named and traceable. Keep a break-glass account with a strong, separately stored credential, and use day-to-day administrative profiles for routine work. Review Super-Admin membership more often than other profiles, and check the GLPI security hardening guidance for session and re-authentication settings before granting it.
Audit trail for permission changes
A permission review is only useful if changes to profiles, rights and assignments can be traced to a person and a date. Confirm which GLPI history records are kept for profile and user changes, where logs are stored, and how long they are retained in your environment. Export or forward those records to a system your security team controls, so an administrator cannot quietly alter the evidence.
Questions teams ask before designing GLPI profiles
How much effort does a GLPI profile redesign take?
The effort depends mainly on how many distinct roles exist, how many entities the profiles must span, and how much of the current access is inherited from the default Super-Admin or Admin profiles. A small organization with a handful of roles and one entity is a short exercise, while a multi-site deployment with many teams and delegated administrators takes longer because each role must be tested against each entity tree. Ask any partner to show how the scope breaks down by role count, entity count and number of test cases, and to state which parts are one-time (the design and the first rollout) and which recur (new roles, new sites and periodic access reviews).
Can an internal administrator design GLPI profiles without a partner?
Yes, a capable internal administrator can design profiles, provided they have time to read the rights matrix for each of the seven default profiles, test changes in a non-production copy and document the result. The harder part is usually not the screens but the decisions: which tasks belong to which team, who may approve changes to rights, and how exceptions are recorded. Teams that lack a second reviewer, or that have no test instance, often find that a partner adds value mainly as an independent check on the design and as a tested runbook.
What does the business need to provide before profile design starts?
The design needs an inventory of real roles and the tasks each one performs, not job titles alone. Expect to provide the list of teams that use GLPI, the entities or sites they work in, the actions they must take on tickets, assets, contracts and reports, and the people who approve access changes. Named approvers matter because every profile that grants write access, or that touches financial or asset data, needs a decision owner. Without these inputs, profiles tend to copy the Admin profile and grow over time.
How do GLPI upgrades affect custom profiles?
Custom profiles are stored in the database, so they survive normal application updates, but new rights added in a release are not automatically granted to your custom profiles. Each upgrade therefore needs a review of the rights matrix for every custom profile, because a new feature may be invisible to a role that should use it, or a role may gain access to a new object type by default. Plan this review as part of each upgrade and keep a record of the rights each profile held before the change so you can compare them afterwards. Confirm the exact behavior for your target release against the official update documentation before the upgrade.
Which parts of GLPI profile work should be tested before go-live?
Test each profile against a realistic set of tasks, such as creating a ticket in a child entity, changing an asset in a different entity, and reading a contract that should be hidden. Include negative tests as well, confirming that a helpdesk agent cannot edit configuration and that a site administrator cannot reach another client's data. Record the results so that auditors and internal reviewers can see that access was checked against the intended design.
What does a fixed-scope DeployOpen engagement cover for profiles?
DeployOpen works from a written scope that states which roles, entities and GLPI versions are included, and the deliverables are agreed before work starts. For this topic, that typically means reviewing the current profiles, drafting a least-privilege design, configuring the profiles and recursive assignments in your instance, protecting the Super-Admin profile, testing the outcome and handing over documentation. The scope excludes ongoing reviews unless you add a retainer, and it does not include audit reports or certifications, which independent auditors issue. Ask for the quote to list each deliverable and the cost components separately.
Which costs should a buyer ask about in a GLPI profile quote?
Ask the quote to separate the one-time design and configuration work from any recurring review, retesting after upgrades and support for new roles. Also ask who pays for the test environment, whether licensing applies to the GLPI version in use, and what happens if the role inventory changes during the work. Because GLPI is open source, the software itself carries no license fee for self-hosted use, but the subscription and plugin costs listed on the vendor's subscription page apply only if you choose those products. Confirm each of these items in writing before the work begins.
How DeployOpen scopes and delivers GLPI access design
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For GLPI profiles and permissions, we start from written requirements for who needs what, then build and test the profiles, entity assignments and protected administrator accounts before handover.
How we scope
- Engagements are fixed-scope, with the profile list, entity structure and deliverables agreed in writing before work starts.
- We inventory the roles in your organization and map each one to the GLPI functions it needs to use.
- Scope records which lifecycle actions, entities and recursive assignments each profile covers, and which are out of scope.
- Ask for the written scope to name every profile, the Super-Admin handling and the testing evidence you will receive.
How we build
- We start from the seven default GLPI profiles and remove or narrow rights rather than adding broad ones by default.
- Recursive assignment to child entities is configured and tested against sample accounts in each branch of your entity tree.
- The life cycle matrix for tickets, assets and other item types is set per profile and checked against real user journeys.
- Super-Admin access is restricted to named accounts and documented, with testing of each profile against its intended permissions.
How we hand over
- Handover includes a profile reference listing each profile, its rights, its entity scope and its owner.
- Your team receives the test cases used to confirm each profile grants what it should and nothing more.
- Runbooks cover how to add a profile, change an entity assignment and review Super-Admin accounts over time.
- Ask whether handover includes a walkthrough session with administrators who will maintain the profiles after go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial work is complete.
- Retainers can cover re-testing of profiles when GLPI releases change rights, including the GLPI 11 and 12 upgrade path.
- Periodic reviews can compare current profile assignments against the documented design and flag drift.
- Confirm with DeployOpen the retainer scope, response expectations and how profile changes are requested and recorded.
