GLPI’s profile system is the access control layer for the entire application. Every action a user can take — creating a ticket, viewing an asset, modifying a business rule, accessing admin settings — is governed by a permission set defined in a profile. Most GLPI deployments start with the default profiles and never revisit them. This leads to the single most common security problem in GLPI: too many people with too much access.
How profiles work
A profile is a collection of rights. Each right controls access to a specific object type (Tickets, Computers, Changes, Problems, Knowledge Base, etc.) or a specific feature (Admin menus, Rules, Dictionaries, Transfers, Entity management). Rights are granular — you can grant read-only access to tickets but deny the ability to delete them, or allow creating changes but not approving them.
A user gets a profile assigned within a specific entity. The same user can hold different profiles in different entities — for example, a Team Lead profile in their home entity and a read-only Observer profile in a sibling entity they need to monitor.
Designing profiles for a 4-tier support structure
Most IT organizations operate with some variation of end users, first-line support, second-line specialists, team leads, and administrators. Here is a practical profile design for this structure.
Self-Service (end users)
Can create tickets. Can see only their own tickets. Can access the knowledge base (read-only). Cannot see assets, changes, problems, or any admin menus. Cannot see other users’ tickets. This is the default for anyone who logs issues but does not work in IT.
L1 Agent
Can see all tickets in their assigned entity. Can take ownership of tickets, add followups, add tasks, and propose solutions. Can view assets (read-only) to check the requester’s equipment. Cannot create or approve changes. Cannot access admin settings, business rules, or SLA configuration. Cannot delete tickets.
L2 Specialist
Same as L1, plus: can create and manage changes (but not approve them — that goes to the Team Lead). Can view and edit problems. Can access the CMDB with write permissions for their asset scope. Can manage knowledge base articles in their category. Still no access to admin menus, user management, or business rules.
Team Lead
Same as L2, plus: can approve changes. Can view statistics and reports. Can assign tickets to technicians. Can manage groups within their entity. Can view (but not modify) SLA configurations. Still no access to global admin settings, entity management, or profile management.
Administrator
Full access. This profile should be held by one or two people per GLPI instance. They manage entities, profiles, business rules, SLA definitions, plugins, and system configuration. This is not a daily-use profile — administrators should have a separate personal account with a lower-privilege profile for routine work.
Common mistakes
Everyone is Super-Admin
This happens in small teams where "we all trust each other." The problem is not trust — it is accountability. When everyone can change anything, you cannot determine who changed a business rule that broke ticket routing, or who deleted an asset record. Audit trails show the action but cannot distinguish intentional changes from accidents when everyone has identical permissions.
Profiles are never reviewed
A user gets promoted from L1 to L2 and receives the L2 profile — but the old L1 profile is never removed. Over time, users accumulate profiles. Review profile assignments when roles change, and remove profiles that no longer match the person’s responsibilities.
Feature rights are overlooked
Administrators focus on object permissions (who can see tickets, who can edit assets) and forget about feature rights. Business rules, dictionaries, automatic actions, and transfer settings are powerful features that can silently alter how GLPI behaves. Restrict these to administrators only.
Testing your profile design
GLPI lets administrators impersonate any user via the "Test" button in the profile management screen. Use this to verify what each profile can actually see and do. Log in as a test user with each profile, try to access menus that should be hidden, try to perform actions that should be denied. Do this before deploying profile changes to production.
Profile design is not glamorous work, but it is the foundation of GLPI security. Get it right once, review it periodically, and most access control problems disappear.