When GLPI password policy settings matter and who they apply to
GLPI applies its local password rules only to accounts authenticated against its internal database. Directory and single sign-on users are governed by their source system, so a length or expiration rule set in GLPI does nothing for someone whose password lives in Active Directory, Google Workspace or an identity provider. Before you write a policy, list every account type in your instance and record where each one authenticates. That inventory decides how much of your password standard GLPI can enforce at all.
The GLPI user documentation describes the authentication order as the internal database first, then LDAP directories, then IMAP mail servers, then other external methods such as REMOTE_USER. An account reaches the database step only when earlier methods do not accept it, which matters for break-glass administrators and for any user who exists in both the database and a directory. Confirm this order in the documentation for your installed version, then test one account of each type after a change so you can see which rules apply to it. Confirm the exact setting names and menu paths for password length, complexity, expiration, notice periods, reuse prevention and inactive-account handling in your version too, because these have moved between releases.
Decide early which group of local accounts the policy must cover. In many regulated teams that is a short list: emergency administrators, service or integration accounts that cannot use single sign-on, and a few contractors. Document the reason each local account exists and who approves it, then write the password standard for that list rather than for the whole user base. Review the list at each access review, since a local account that was meant to be temporary often outlives the project that created it.
Password rule options and when each fits
This table compares the four password rule areas available for local GLPI accounts, with the setting to confirm in your running version. Read each row against your user mix: local-only administrators, mixed directory and local accounts, or service-style accounts. The main takeaway is that local rules only govern accounts GLPI authenticates itself, so directory-backed users depend on the source system's policy.
| Rule area | When it fits | What it protects against | What to verify in the running GLPI version |
|---|---|---|---|
| Minimum length and complexity | Small teams where a few local administrators sign in directly, or any instance where local accounts remain as break-glass access | Guessing and dictionary attacks against local credentials | Confirm which length and character class options the admin console exposes, the current minimum, and whether the rule applies to every local profile |
| Expiration and notice periods | Teams with rotation requirements for local administrators, or where a policy document mandates periodic change | Credentials that stay valid after staff change roles or leave, and long-lived exposure of a leaked password | Confirm whether expiration is enforced at login, how far ahead users are warned, and whether notices reach users by email |
| Reuse prevention | Instances where administrators tend to alternate between two or three passwords across rotations | Recycling of known or previously exposed passwords after a forced change | Confirm how many previous passwords GLPI stores, whether the check covers all local accounts, and how the history is kept |
| Deactivation of stale local accounts | Instances with contractors, former staff or vendor accounts that were created locally and never removed | Dormant accounts that remain valid and can be used without an active owner | Confirm whether GLPI can disable accounts by inactivity or only manually, and whether a scheduled action or report flags stale users |
| Directory-backed accounts | Mixed environments where most users sign in through LDAP, Active Directory, CAS or SSO | Duplicate policies that conflict with the directory's rules and leave users with two passwords to manage | Confirm which local settings apply to directory users at all, and align expiration and lockout with the identity provider |
| Break-glass administrator accounts | Any instance that relies on an external sign-in method, so an administrator can still log in if the directory is unavailable | Lockout during an identity outage and unmanaged shared administrator access | Confirm the local account is excluded from directory-only enforcement, its password is stored in a controlled vault, and its use is logged |
Which accounts local password rules actually cover
Accounts that exist only in GLPI's internal database are the simplest case. The GLPI user documentation describes the internal database as the first authentication method tried, so for these users the local password rules are the sign-in control. Every length, complexity, expiration and reuse setting applies directly, and no outside system can change or reset their credentials.
- Full policy coverage: length, complexity, expiration, notice and reuse settings apply to the password stored in GLPI, with no second source to reconcile.
- Reset ownership: administrators or users change passwords inside GLPI, so the process for lost passwords and forced changes must be written down.
- Lifecycle control: deactivation of stale users has to happen in GLPI, because no directory will disable these records for you.
- Typical population: service and vendor accounts without a directory identity usually fall here, and they deserve the closest review.
Confirm that each local account is intentional, check the password settings in the administration console for your installed version, and test a rejected password before you rely on the rule.
Directory users are checked against LDAP after the internal database, according to the authentication order in the GLPI user documentation. For users who sign in through the directory, the password is normally maintained in the directory, so GLPI's expiration and complexity settings may not describe what those users actually face. The directory's own policy decides how passwords are built, reused and locked.
- Directory governs the password: the directory's policy controls complexity, history and lockout for users who authenticate through LDAP.
- Local shadow records: a user created locally, or one who existed before the directory link was configured, can keep a local password. That is a second credential to manage, and it may be the one checked first.
- Leavers: disabling a directory account does not automatically disable the matching GLPI record. Confirm how your synchronization and deactivation settings handle it.
- Mixed populations: some users are local and others are directory-backed, so a single policy description will not fit both groups.
Build a list of every login name that exists in both the directory and GLPI's database, then decide which credential is authoritative for each one.
When sign-in goes through web server SSO or REMOTE_USER, the identity provider or web server authenticates the user before GLPI receives the request. The password is never typed into GLPI, so GLPI's local rules do not govern this path. A local record that shares the login name can still be tried in the authentication order, so the two paths need to be checked together.
- Upstream credential: password length, rotation and lockout come from the identity provider or web server.
- Local password still exists: SSO users with a local record keep a password that can authenticate through the database path.
- Trusted login name: GLPI accepts the login name that the web server passes in, so the component that sets that value must be controlled.
- Expiry happens upstream: a password change or account disablement in the identity provider does not change the GLPI record by itself.
Test a sign-in for a user whose upstream account is disabled, then check whether the local password still allows access to GLPI.
Break-glass accounts exist for the case where the directory, the SSO provider or the network path to them fails. They are usually local records, so local password rules are their main protection. Because they hold administrative rights, they are among the most sensitive accounts in any GLPI instance. Placing them in the internal database means they remain usable during a directory outage, since that database is tried first.
- Local by design: these accounts should authenticate against the internal database so that access survives an outage of the directory or SSO provider.
- Strong, unique secret: set length and complexity to reflect administrator risk, and keep the credential under your own custody.
- Expiration decision: a forced change can lock out the only administrator able to respond, so decide deliberately whether expiry applies.
- Monitoring: review sign-in activity for these accounts and confirm that alerts reach your logging or security team.
- Scheduled testing: test the break-glass sign-in on a fixed schedule, so it is not tried for the first time during an incident.
Document the account names, where the credentials are held, who may use them and how each use is reviewed afterward.
Setting up local password rules in order
This sequence moves from knowing which accounts sign in locally to a written policy, configured and tested rules, and a recheck after upgrades. The result is a password policy you can explain to an auditor and show working on a test account.
Inventory accounts that sign in locally
Start by listing every GLPI account that authenticates against the internal database rather than an external source. GLPI tries authentication methods in a set order, starting with the internal database, then LDAP directories, IMAP servers and other external methods, so a user can be matched to a local account even when a directory exists. Export the user list and mark each account by authentication source, including the built-in administrator accounts and any service or API accounts. The step is done when you have a reviewed list with a count for each source, and the owner of each local account is named.
Agree the policy with the security owner
Before changing any setting, the security owner and the GLPI administrator should agree in writing on minimum length, character requirements, expiration interval, notice period, reuse prevention and the inactivity threshold for deactivating stale accounts. Record which accounts the policy covers and which are exempt, and confirm whether any sector rule or internal standard sets a value you must meet. Ask the owner to approve the values and the reason for each one. The step is done when a signed policy record exists and every setting in the later steps traces back to it.
Configure length, complexity and expiration
In the GLPI setup area for authentication, open the password security settings and enter the minimum length, the character classes required and the expiration interval agreed in the policy. The exact menu labels and option names differ between GLPI versions, so check them against the documentation for the version you run before saving. Keep a copy of the previous values so you can reverse the change. The step is done when you reload the settings page and the saved values match the policy record exactly.
Set notice periods and reuse prevention
Configure how far ahead of expiration users receive a warning and whether GLPI blocks reuse of earlier passwords, using the values from the policy. Notices are delivered by email, so confirm that GLPI's outgoing mail configuration works and that the notification template for password expiration is enabled before you rely on it. Send a test message to a mailbox you control. The step is done when the notice arrives, its content matches the policy, and you have confirmed how many previous passwords GLPI compares against in your version.
Configure deactivation for stale accounts
Set the inactivity rule so that local accounts unused beyond the agreed threshold are deactivated, and confirm in the documentation how GLPI measures inactivity for your version. Decide who receives a report of deactivated accounts and whether service accounts are excluded. Exclusions should be listed by name in the policy record so they are deliberate. The step is done when a stale test account is deactivated automatically and the deactivation appears in your logs or notifications.
Test each rule with non-production users
Create a set of test accounts in a non-production instance and try to set a password that breaks each rule in turn: too short, missing a required character class, expired, reused and, for the stale rule, unused past the threshold. Sign in with each test account to confirm the expected result. Confirm that the expiration notice reaches the test mailbox and that the stale test account is deactivated. Keep the results in a table with the rule, the test, the expected result and the observed result. The step is done when every rule has a passing test and any failure has a documented fix.
Recheck settings after every upgrade
Each GLPI upgrade replaces application files and runs database updates, so the password settings and their notices can change or revert. After any upgrade, follow the vendor's update procedure, including the database and configuration backups it requires, then compare the saved password settings with the policy record. Rerun the test accounts from the previous step and confirm that any plugins involved in authentication are reactivated, since GLPI suspends plugins when it detects a new version. The step is done when the recheck results are filed with the upgrade record and match the policy.
Security and operational considerations for local password rules
Password rules only protect local accounts when they sit inside a wider access design. The cards below cover the risks that tend to appear once rules go live, and the check to run for each one.
Keep break-glass access available
Strict expiration, lockout and deactivation rules can lock out the only administrator who knows how to fix them. Keep at least one local administrator account excluded from the stricter rules and store its credentials under your own offline control. Before enabling enforcement, test that this account can still sign in, reset another user's password and reach the console from your admin network. Record who holds the credentials and when they were last tested.
Protect glpi.key and glpicrypt.key
The GLPI update procedure requires backing up the config directory, including glpi.key and glpicrypt.key. A database dump without these keys cannot decrypt stored secrets, and a backup copy of the keys held beside an unencrypted dump gives an attacker both halves. Store key backups separately from database backups, restrict read access to the config directory, and test a restore on a non-production host to confirm the keys match the data.
Use session review and step-up authentication
Password rules do nothing about a session that is already open on a shared or unattended workstation. GLPI 12.0.0 adds a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Confirm which actions in your GLPI version require step-up, decide who may revoke sessions, and include session revocation in the procedure for leavers and suspected compromise.
Decide on two-factor authentication
Two-factor authentication adds a second check that a stolen password alone does not satisfy. Review the GLPI feature documentation for how the option is enabled, which accounts it can be required for, and how users enroll and recover a lost device. Decide whether it applies to all profiles or only administrative ones, and test the recovery path before rollout so that a lost device does not become a helpdesk ticket for every user.
Monitor failed sign-in attempts
Lockout thresholds only slow an attacker down if someone notices the attempts. Decide where GLPI sign-in failures are recorded in your deployment, how often they are reviewed, and who receives an alert when one account accumulates failures or when a dormant account signs in. Check that these logs reach the same place as your other authentication records and that the retention period meets your internal policy.
Align with directory password policies
Local GLPI rules apply only to accounts stored in its database. Users authenticated through LDAP or Active Directory follow the directory's password policy, and GLPI's expiration settings do not govern them. Map which accounts are local and which are directory-backed, then confirm that the two sets of rules do not conflict, for example a directory password that expires on one schedule while a local break-glass account follows another. Document the owner of each rule set.
Limits to confirm in your environment before you rely on these settings
The settings below are only as dependable as the GLPI version and configuration behind them. Each card names a point the supplied sources do not settle, so the reader knows what to test or ask before writing a password standard into policy.
Exact password options in your version
The set of password rules, length and complexity controls, and expiration fields can differ between GLPI 10, 11 and 12. Confirm which options appear in the exact version you run, including whether any are hidden behind a configuration page or a permission. Ask the vendor or check the documentation for that release, then record a screenshot or export of the settings in your own test environment so the baseline is documented.
Expiration notice delivery
Expiration reminders are only useful if they leave GLPI. Confirm whether notices are generated through the notification queue, which mail configuration sends them, and whether the mail server accepts messages for accounts that are not yet expired. Test with a short-lived account in a lab instance and check the queue, the sent mail and the recipient's inbox before relying on the notice period.
Reuse history storage and retention
Preventing reuse of recent passwords requires GLPI to keep a record of past credentials. Confirm where that history is stored, whether it holds hashes or other values, how many entries are kept, and whether it is removed when a user is deleted. Ask the vendor how the history is handled during database updates and backups, since restored data may bring back older entries.
Stale user deactivation
Deactivating accounts that have not signed in is a separate control from password expiration. Confirm whether the behavior runs through an automatic action, which task performs it, how it defines inactivity, and whether it disables or deletes accounts. Test it with a dormant account in a non-production instance, and confirm that it does not disable the local administrator accounts you need for recovery.
Fit to a named control standard
Whether these settings satisfy a specific internal policy or an external standard is a determination for your auditor, not for the configuration. Map each setting to the control titles your assessor uses, document how each one is enforced, and record the evidence that proves it. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certifications.
Questions teams ask before setting GLPI password rules
Can our own team configure GLPI password rules without a partner?
Yes, for simple cases. A team with administrator access to GLPI can review the local account settings, set minimum length and complexity, configure expiration and notice periods, and decide how stale accounts are handled. The risk lies in the details: a rule applied to a live instance can lock out administrators, break scheduled jobs that rely on service accounts, or affect accounts that actually sign in through LDAP, CAS or another external source. Build the change on a test instance restored from a recent backup, record the settings you chose, and confirm that a local administrator can still sign in before you touch production. Teams with a single authentication source and few local accounts usually find this manageable. Teams with mixed sources or strict audit needs often benefit from a second pair of eyes on the design.
What drives the effort of a GLPI password policy project?
Effort follows the shape of your user base more than the number of settings in the console. The main drivers are the number of local accounts that GLPI authenticates itself, the mix of authentication sources such as LDAP directories, CAS, x509 or web server SSO, and whether those sources bypass the local policy entirely. Notification requirements add work because expiration reminders must reach users reliably, and audit requirements add work because you need to show who changed which setting and when. Upgrade cadence matters too. A policy that is simple today must survive the next GLPI release, and each release needs a regression check against your rules. Ask for each of these items to be listed separately in any scope you review.
How long does a GLPI password configuration and test cycle take?
The duration depends on scope, and no fixed figure applies to every organization. A small instance with one authentication source and a handful of local accounts can be configured and tested quickly, while an instance with several sources, notification routing and audit evidence needs more time for design, testing and sign-off. Test cycles also depend on how many user types you must verify, such as administrators, service accounts, external users and users who reset passwords. Any timeline should be written into the agreed scope, with the tasks, the test cases and the acceptance criteria listed. Ask any partner to show how the schedule maps to those items rather than accepting a single estimate.
What do we need to provide before a partner starts this work?
A partner needs four things from you. First, an inventory of local accounts, including which ones are administrators, service accounts or shared accounts, and which ones should be deactivated when stale. Second, a named policy owner who can approve the length, complexity, expiration and reuse rules and who signs off on exceptions. Third, a test instance that matches production closely enough to reproduce sign-in behavior, ideally restored from a recent backup. Fourth, access to the administrator console with a role that can change the authentication settings and view the relevant logs. Without these items, the work either stalls or moves into guesswork, so confirm each one during scoping.
Does a GLPI password policy alone satisfy a compliance requirement?
No. A password policy is one control among several, and an assessor will look at how it fits into the wider access model. Strong rules on local accounts do not cover users who sign in through a directory, a single sign-on provider or a client certificate, because those sources enforce their own rules. Auditors also look for evidence that accounts are reviewed, that leavers lose access, that privileged actions are logged and that administrators can explain the configuration. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask your assessor which controls they expect to see before you finalize the policy.
Which upgrade and maintenance risks should we plan for?
Password settings can change behavior across GLPI upgrades, so each release needs a regression check. Follow the update procedure in the installation documentation, which requires backing up the database, the application files and the config directory, including the glpi.key and glpicrypt.key files. Keep in mind that since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so a plugin that enforces its own authentication rules may stop working until someone reactivates it. Record your password settings in a change log, and repeat your sign-in test cases after each update before you return the instance to users.
What should a partner quote for GLPI password rules include?
A useful quote lists the scope as deliverables rather than hours alone. Ask for the account inventory review, the written policy design with each setting and its reason, the test instance configuration, the test cases for each authentication source, the change steps for production, the rollback procedure and the handover notes for your administrators. Also ask what is one-time work, such as design and testing, and what recurs, such as review after upgrades or periodic access reviews. Confirm which items depend on your side, including the policy owner and test environment, and state how changes to scope will be handled in writing. DeployOpen plans and delivers fixed-scope work agreed in writing before it starts, and it provides a quote from that written scope.
How DeployOpen scopes and delivers GLPI password policy work
DeployOpen approaches GLPI password policy and expiration settings as a scoped configuration and verification workstream inside your own infrastructure. We start from your written requirements for local accounts, then configure, test, document and hand over the result, with ongoing support available as a retainer.
How we scope
- Confirm which accounts are local to GLPI and which authenticate through LDAP, CAS, x509 or web server SSO.
- Record the required length, complexity, expiration and notice periods, reuse rules and stale-account deactivation thresholds.
- Agree the written scope, deliverables and timeline before work starts, with clear boundaries on what is excluded.
How we build
- Apply the agreed local password rules in a non-production GLPI instance that mirrors your production configuration.
- Test expiration notices, forced password changes, reuse blocking and deactivation behavior with representative user accounts.
- Check that external directory accounts are excluded from local rules so sign-in paths keep working as designed.
How we hand over
- Document every setting, its owner, the reason for the value chosen and the steps to change it later.
- Provide a test record showing which rules were verified, with the evidence collected for your internal reviewers.
- Walk your administrators through the configuration and the user-facing messages so support staff can answer common questions.
How we support
- Offer ongoing support as a retainer for policy reviews, GLPI version upgrades and changes to your identity setup.
- Re-test password settings after each GLPI update, since upgrades can change defaults and require a verified baseline.
- Prepare control evidence for your assessors, while noting that independent auditors and certification bodies issue any attestation.
