How GLPI authorization assignment rules decide who gets which profile and entity
GLPI authorization assignment rules decide, at sign-in, which profile and which entity a user receives, so an administrator does not have to set access by hand for each account. Teams need them when user access follows the organization's structure (departments, sites, client accounts) and that structure changes faster than an administrator can keep up with. The rules run against the external authentication source that verified the user, such as an LDAP directory or an SSO connection, and they read attributes returned by that source, such as a department, job title, group membership or location, to decide the outcome.
The attributes are the core of the design. Each rule compares one or more attributes from the authentication source with a condition you define, and when the condition matches, GLPI assigns the profile (what the user may do) and the entity (which part of the data tree the user may see). These are separate decisions. A user can have a broad profile limited to one entity, or a narrow profile across several. Before building any rule, confirm which attributes your directory or identity provider actually sends to GLPI, because a rule cannot match on a value that never arrives. Your own environment, and the GLPI authentication documentation for your version, are the right sources to check the exact attribute names and matching behavior.
Plan the inventory of profiles and entities before writing rules. List each department, site and client boundary, the profile each group needs, and which group owns the decision when a person changes role. Rules are easier to audit when each one maps a clear source attribute to one outcome. The detailed configuration steps, combining several matching rules and handling department changes and leavers are covered in the sections below.
Which attribute source and rule approach fits your directory
This table compares the four common inputs for assigning GLPI profiles and entities automatically: directory group membership, directory attributes, SCIM-provisioned groups and SSO header or claim values. Read each row for when the input fits, what must stay stable in the source system, and the main risk to plan for before rules go live.
| Input source | When it fits | What must be stable | Main risk |
|---|---|---|---|
| LDAP or Active Directory group membership | Your organization already manages access through security groups that mirror roles or sites | Group names and membership are maintained by a defined owner with a joining and leaving process | Nested or stale groups grant access nobody reviewed, so confirm how nested groups are resolved in your setup |
| Directory attributes such as department or title | Teams are organized by department or location and those fields are kept current by HR | Attribute values use one consistent format and are populated for every user | Free-text values drift (for example, spelling or abbreviations), so matches silently fail or hit the wrong entity |
| SCIM-provisioned groups | Users and groups are pushed from an identity provider and you want group changes applied without a directory query | The identity provider owns group definitions and the provisioning connection is monitored | A broken or paused provisioning job leaves leavers active and movers in old profiles |
| SSO header or claim values | Sign-in passes through a web server or identity provider that already sends role or organization claims | The claim is issued only by a trusted identity provider and cannot be set by the end user | Spoofable or missing headers can elevate access, so confirm the header source and proxy trust before relying on it |
Setting up authorization rules step by step
The sequence below takes a GLPI instance from an unconfigured authentication source to a documented, tested set of rules that place each user in the right profile and entity without manual changes. Each step ends with a check you can repeat after any later change.
Confirm the authentication source and sample attributes
Confirm which directory or identity source signs users in, such as LDAP, Active Directory, CAS, x509 or a web server SSO header, and check that GLPI reads it. Pick three or four sample accounts that cover a standard user, a manager and a user in a sub-department, then record the exact attribute names and values each one carries, such as department, group membership, title or organization unit. Ask your directory team which attributes are maintained by HR and which are manual, because that decides what you can safely rely on. The step is done when you have a written table of sample users and their attribute values, and a test login for each sample account succeeds in GLPI.
Define target profiles and entities from the least-privilege design
Using your least-privilege profile design, list each profile a user category needs and the entity or entities where that category should see data. Decide whether each assignment should be recursive to child entities, and identify which profile must never be assigned by a rule, such as Super-Admin. Agree the list with the security owner and the entity owner before you write any rule. The output is a short register of profile, entity, recursion setting and the attribute condition that should select it. The step is done when every planned rule target exists in GLPI and each profile has been reviewed against its intended permissions.
Draft the rules and fix their order
Write the rules as a list in the order GLPI will evaluate them, with the most specific conditions first and any fallback rule last. Give each rule a name that states its purpose, such as the target profile and the attribute it matches, so that an administrator can read the list later. Avoid conditions that match broad groups by accident, and decide in advance what happens to a user who matches no rule, which should normally be a default profile with no access to business data. The output is a written rule order with the condition and action for each rule. The step is done when a reviewer can trace every sample account from the draft to exactly one expected outcome.
Enter the rules and check the sample accounts
Enter the drafted rules in the authorization rules section of GLPI for the chosen source, following the order you fixed in the previous step. Sign in with each sample account and open the user record and session details to confirm the profile and entity that GLPI assigned. Compare each result with the expected outcome in your draft, and correct the rule or its order if a sample account lands in the wrong place. The step is done when every sample account shows the profile and entity you expected, and you have recorded the result of each check.
Test edge cases with pilot accounts
Ask a small group of pilot users from different departments to sign in and report what they can see and do. Include users who have just moved departments, users with several group memberships, and users whose attributes are incomplete, because these cases reveal rule overlaps and gaps that sample accounts miss. Confirm that a user who changes department loses the old access after the next sign-in, and that a user removed from the directory cannot sign in. Confirm this against your own directory and GLPI settings, because the exact behavior depends on how each source refreshes user data. The step is done when pilot users have reported expected access, and each edge case has a recorded result.
Document the rule order and the review process
Write down the final rule order, the attribute each rule depends on, the sample accounts and pilot results, and the name of the person who owns each change. Include a short procedure for adding or changing a rule, which requires a test login before and after the change. Store the document where your change records are kept so that auditors and future administrators can see how access is assigned. The output is a versioned document that matches the live configuration. The step is done when someone who did not build the rules can read the document and predict the profile and entity of a new test account.
How to combine multiple rules without granting too much access
The main risk in GLPI authorization assignment rules is not a single bad rule but several correct-looking rules that match the same user. When more than one rule matches a login, the combined result can give a user a profile or entity that no single rule was meant to grant. A broad rule, such as one that matches every member of a large directory group, can assign a profile with wide rights to users that a narrower rule was written to restrict. Before you add rules, decide how GLPI processes matching rules in the version you run, including whether every match is applied, whether the first match wins, and how profile and entity assignments accumulate. Confirm this against the installed GLPI version and its documentation, because evaluation behavior is the part most likely to differ between releases and it is the part your access model depends on.
Plan the default before writing any allow rule. A minimal default profile that grants only self-service access, with no entity rights beyond the user's own, means a login that matches nothing receives little. The alternative, a default that grants an operator profile, turns every unmatched account into a privileged one. Document the intent of each rule in a short record: the attribute and value it matches, the profile and entity it assigns, the owner who approved it, and the population it is supposed to include. Name the excluded population too, such as service accounts, contractors or staff in a restricted division. Overlaps are easiest to find when each rule's purpose is written down, because you can then test whether a user in one group also satisfies a second rule that grants something the first rule did not intend.
Review overlaps after every change, not only at go-live. Export or list the rules in their current order, then test representative accounts from each population, including a user who belongs to several directory groups, a user recently moved between departments, and a disabled account. Record the resulting profile and entity for each test account and compare it with the documented intent. Keep a change log of rule edits and rerun the same test accounts after each edit. A reviewer who can explain every grant from the rule text and the test results is in a much better position to pass an access review than one who relies on the rules looking correct in isolation.
Handling department changes and leavers
Users who change departments, move between entities or leave the organization are where authorization rules most often drift. The cases below cover what GLPI does by default, what to confirm in your directory and rule set, and the check that shows whether access is still correct.
Department move keeps old access
When a user moves from Finance to Operations, the Finance profile can stay in place if it was assigned manually or by an earlier import. Rule-assigned profiles are the ones a changed attribute can replace, so confirm which of the user's profiles come from rules and which were set by hand. Test a move in a staging directory, then compare each user's GLPI profiles with their current directory groups on a regular schedule.
Transfer between entities
An entity rule decides the new scope, but a profile's recursive setting or a manually added entity can leave the former entity visible. Decide whether the person loses access to the old entity at once or after a handover period, and confirm the order in which your rules assign entities. Sample a few transferred accounts and confirm they see only the new entity's tickets and assets.
Removed from a directory group
Removing someone from a directory group does not always remove the matching GLPI profile. Confirm whether the rules run at the next sign-in and during directory synchronization, and whether the sync removes rights or only adds them. Test by removing a test user from the group, running a sync from the console and checking the profile list before and after.
Disabled in directory, still in GLPI
An account disabled in Active Directory can remain active in GLPI, with its profiles intact, until a synchronization handles it. Confirm the setting that controls users who are disabled or missing from the directory, and whether the scheduled synchronization task runs as expected. Compare disabled directory accounts with active GLPI users each week and attempt a sign-in with one disabled test account.
Contractor end date
GLPI does not expire a rule-assigned profile on its own unless the identity source supplies an end date that a rule reads. Confirm where the contractor's end date lives (directory attribute, HR feed or SCIM attribute) and who owns deactivation when it passes. Keep a dated review of external accounts and test an account with a past end date to confirm it cannot sign in.
Rule silently stops matching
A rule that matches on a department name stops matching when the directory renames the value, and affected users fall through to the default profile or lose access without any error. Confirm the attribute each rule reads, how the value is compared and the profile given to users no rule matches. Alert when the count of unmatched users changes unexpectedly, and review the GLPI authentication documentation when you add or change a rule.
Security and audit considerations for automatic access
Who should be allowed to edit GLPI authorization rules?
Only a small, named group of GLPI super-administrators should be able to create, change or reorder authorization rules, and that group should be separate from people who manage daily tickets or assets. Rules decide which profile and entity a user receives at sign-in, so an edit is effectively a change to who can see and do what. Confirm in your version which profiles hold the rights to manage authorization rules and directory settings, and check that the Super-Admin profile is assigned to as few accounts as your operating model allows. Review that list whenever an administrator changes role, and record the reason for every grant.
How do you log and review changes to automatic access rules?
Treat every rule change as a controlled change with a ticket, a before and after copy of the rule, and a named approver. Confirm which GLPI log entries record changes to rules, directory connections and profile assignments in your version, and whether those entries are retained long enough for your audit cycle. Export or forward those logs to your central logging platform so administrators cannot quietly remove their own trail. Schedule a periodic review in which someone who did not write the rules compares the live configuration against the approved change records.
Can a broad rule accidentally give someone a privileged profile?
Yes, and this is the most common risk in attribute-based assignment. A rule that matches on a loose value, such as a shared department name, a wildcard, an empty attribute or a group that contains more people than intended, can grant an administrative profile to a large population. Use the most specific match you can, prefer group membership maintained by a trusted directory team over free-text attributes, and keep privileged profiles behind a separate rule that requires an explicit administrative group. Order rules so that restrictive rules are evaluated first, and test each rule with a sample of real accounts before enabling it.
Should authorization rules be tested in a non-production GLPI instance first?
Yes. Build the rule set in a non-production GLPI instance connected to a test directory or a copy of the production directory structure, then run sign-in tests with accounts that represent each department, role and leaver state. Check the profile, entity and recursive assignment each test user receives, and confirm that accounts outside the expected population receive nothing. Keep the test instance on the same GLPI version as production, because rule evaluation and profile handling can change between releases. Promote the approved configuration through a documented export or manual replay, and record which test cases passed.
How do you keep automatic rules aligned with the documented access model?
Write down the access model first: which profile each job family should hold, which entity each department should see, and which cases need manual approval. Then map each automatic rule to one line of that model, so that a reviewer can trace any assignment back to a documented decision. Revisit the model when the organization restructures, when GLPI releases a new version that changes profile rights, and when the directory group structure changes. Rules that no longer map to the model should be removed rather than left disabled, since disabled rules are easy to re-enable by mistake.
How do you confirm that disabled directory accounts lose GLPI access?
Automatic assignment only runs when a user signs in, so a disabled account can keep its existing GLPI rights until the record is updated or deactivated, depending on how your directory connection and synchronization are configured. Confirm the behavior in your version with a disabled test account: attempt sign-in, check the account state in GLPI, and check whether the profile and entity remain attached. Make sure the directory connection excludes disabled accounts or that a scheduled synchronization deactivates them. Also review active sessions and API tokens, which are separate from the sign-in path.
What should an auditor ask to see for automatic access controls?
An auditor will usually ask for the approved access model, the current rule configuration, the change history with approvals, evidence of testing, and a sample of users showing that their profiles match their roles. Prepare these as exported or screenshotted evidence dated to the review period. DeployOpen can prepare systems, controls and evidence for a compliance assessment, but the assessment itself is performed by an independent auditor or certification body. Confirm with your auditor which control framework applies and which evidence format they accept before you collect it.
Who is responsible for the security of GLPI authorization rules?
The organization owns the rules, the access model and the approval decisions, while the platform and directory teams own the systems that supply the attributes and groups. Define a single accountable owner for the rule set, plus named backups, and document how requests for changes move from the requester to the approver to the GLPI administrator. If you engage a partner, the written scope should state who approves changes, who performs the testing, and who keeps the evidence. Confirm those responsibilities before the first rule goes live.
Limits to confirm in your environment
Authorization rules are only as reliable as the attributes they read and the version that evaluates them. The six items below are the points where a design that looks correct on paper can assign the wrong profile or entity, so confirm each one against your GLPI version and directory before rules reach production users.
Rule criteria by GLPI version
Not every rule criterion, action or attribute mapping is available in every release, and the exact set can change between the 11 and 12 lines. Ask the vendor or check the release notes for the version you plan to run, then test each criterion you depend on in a staging instance. Record the version in your design so a later upgrade triggers a retest of the rules.
Nested group resolution
Rules that match on group membership depend on whether the chosen source expands nested groups or only returns direct memberships. A user who inherits access through a group inside another group may be missed entirely. Test with a nested member from each source you use, and confirm whether the directory query or the GLPI side resolves the nesting.
Attribute refresh at login
Confirm when GLPI re-evaluates assignment rules: only at first sign-in, on every login, or on a scheduled sync. A department change in the directory has no effect on profile or entity until the refresh runs, so a transferred user may keep the old access. Test a move between departments and time how long the old assignment persists.
Multiple entities and rule order
When one user matches rules that point to several entities or profiles, the outcome depends on rule order and on whether assignments are added or replaced. Confirm how GLPI combines matches, which rule wins on conflict, and whether a user can end up with access to an entity you did not intend. Document the expected result for each overlapping group.
SCIM and SSO provider changes
Changing an identity provider claim name, group format or SCIM mapping can silently stop rules from matching while logins still succeed. Ask how your identity provider sends attributes after a change, and whether GLPI rejects, ignores or defaults users whose attributes no longer match. Re-run your test users after each provider change.
Local administrator fallback
If a rule removes the only administrative profile from every account, or a directory outage blocks the rule source, you can lose access to the instance. Confirm that a local administrator remains available, that its authentication does not depend on the rules, and that the recovery steps are written down and tested before go-live.
Questions buyers ask about GLPI authorization rules
How long does it take to design GLPI authorization rules?
The duration depends on how many profiles, entities, identity sources and exceptions the design has to cover, and no single figure applies to every organization. A design with one directory, a handful of profiles and a flat entity structure is a much smaller piece of work than one that maps several directories or SSO providers to a multi-level entity tree. Before any quote, ask for the written scope to list each source attribute, each target profile and entity, and each exception case such as contractors, shared accounts and users who hold more than one role. Those lists are what make a timeline credible. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote follows from that list.
What drives the cost of a GLPI authorization rule project?
Cost follows the design surface more than the number of users. The main drivers are:
- The number of GLPI profiles that must map to distinct job functions, since each profile needs a clear entitlement and a test case.
- The number of entities and the depth of the entity tree that rules must place users into.
- The number of identity sources, such as LDAP, Active Directory, SSO attributes or SCIM feeds, and how consistent their attributes are.
- The number of exceptions, including manual overrides, legacy accounts and leavers handled outside the directory.
One-time work covers design, rule build and testing. Recurring work covers rule changes when departments or products change. Ask any provider to price these components separately.
What does the work need from our directory and security teams?
The directory team needs to confirm which attributes hold department, job title, location and employment status, and how reliably they are maintained. The security team needs to approve the mapping of directory groups to GLPI profiles, because each profile grants access to assets, tickets and administration. Both teams should agree who can change a group membership that drives a privilege, and how that change is logged. Test accounts with representative attribute values are needed in a non-production GLPI instance. Access to the directory for read-only queries and an account for testing the LDAP bind are also required. Confirm these with your own directory administrators before scoping.
Can our own staff build GLPI authorization rules without a partner?
Yes, if the team has someone comfortable with GLPI's administration console, the directory schema and a disciplined test process. GLPI's authentication documentation describes the order in which sources such as the internal database, LDAP directories and external methods like REMOTE_USER are tried, and that ordering affects how rules behave. Internal staff usually handle the simpler designs well. A partner adds most value when the design spans several sources, many entities or sensitive administrative profiles, and when the team needs an independent review of the privilege model before go-live. Either way, write the rule set down before building it, because the document is what allows anyone to review it later.
How are GLPI authorization rules reviewed after go-live?
Rules should be reviewed on a fixed schedule and whenever the directory structure, the organization or the GLPI version changes. A review checks that each rule still maps to an existing profile and entity, that leavers lose access at the expected point, and that no user holds an unexpected combination of profiles. The GLPI update procedure requires a backup of the database, the files and the config directory, and GLPI 11.0 suspends plugins after a new version is detected, so authorization behavior should be retested after upgrades. Ask for the review cadence, the test cases and the audit evidence to be included in the delivery. Confirm with your own team who owns the review after handover.
How do department changes and leavers get handled by rules?
Rules should move a user into the new profile and entity when the source attribute changes, and remove prior access so that privileges do not accumulate. A common failure is a rule that adds new access but never removes the old entitlement. A second risk is a leaver whose directory account is disabled while the GLPI session or local account remains active. The design should state which system is authoritative for employment status, how quickly removal must take effect, and what happens to tickets and assets owned by the leaver. Test these transitions with a dedicated set of accounts before go-live.
How do multiple authorization rules combine in GLPI?
When more than one rule matches a user, the outcome depends on rule order and on the criteria each rule uses, so overlapping rules are a frequent source of unexpected access. The design should avoid two rules granting different profiles for the same condition unless the intent is explicit. Document the order, the criteria and the expected result for each combination. Include a deliberate default for users who match no rule, and confirm that the default grants the least privilege required. Check the exact behavior against the version you run, since the rule engine is part of the application and can change between releases.
Which GLPI version should we plan rules around?
Plan against the version you intend to run for the next several years, not the one you have today. GLPI 12.0.0 was released on October 7, 2026, GLPI 11.0.0 on October 1, 2025, and GLPI 10.0.0 on April 20, 2022, according to the GLPI releases page. Check the prerequisites page for supported PHP and database versions before you commit to a design. If you are moving from GLPI 10, confirm how authorization settings and plugins carry across, because the upgrade changes parts of the core. Ask the provider to show which rule behaviors were tested on your target version.
How DeployOpen scopes and delivers GLPI access rules
Delivery starts with a written scope, not with rule configuration. Before any work begins, DeployOpen and your team agree in writing which directory sources feed GLPI (Active Directory, LDAP, SCIM or SSO attributes), which GLPI profiles and entities each population should receive, and what happens to users who match no rule. Most engagements are fixed-scope, so the agreed document also fixes the rule set to be delivered, the test cases used to accept it and the environments involved. Ask for that document to name the attributes in use, the profiles in scope and the owner of each attribute, since unclear ownership is the most common reason rule sets drift after go-live.
The attribute and profile mapping is done with your identity and GLPI owners in the room. DeployOpen works through the attributes your directory actually holds, such as department, job title, office or group membership, and matches each value to a target profile and entity. Where a value is ambiguous, for example one department spanning two sites, the decision is recorded as a rule priority or exception rather than left to the rule engine's default order. Build and testing then take place in your own infrastructure, using a non-production GLPI instance and a set of representative test accounts, including a department change and a leaver. Results are reviewed against the agreed test cases before anything is promoted.
Handover is where the rule set becomes something your team can run. DeployOpen documents each rule, its source attribute, its order, its test evidence and the steps to add a department or retire a profile, so changes do not depend on the person who built them. Ongoing support, rule reviews and upgrade checks after GLPI version changes can be covered by a retainer, which is worth raising at scoping if your directory changes often. Confirm with DeployOpen which of these items are included in the fixed scope and which are optional, and check the GLPI version and documentation references against the GLPI user documentation before the design is signed off.
