How GLPI Jamf Pro integration keeps Apple device inventory current
The GLPI Jamf plugin is the supported route for bringing data from Jamf Pro into GLPI, so Apple devices stop living in two inventories. According to the plugin documentation, it maps Jamf Pro computers to GLPI computers, mobile devices to phones (iPhone and iPad), Apple TV to computers, Jamf Pro software to GLPI software with its versions and installations, and extension attributes to searchable plugin tables. Those mappings define what you can search, report on and link to users in GLPI. They do not make Jamf Pro the place where devices are enrolled, configured or wiped. Jamf Pro remains the management system of record, and GLPI becomes the asset and service view that tickets, contracts and reports draw from.
The synchronized fields are the ones that drive asset decisions: model identifiers, UDID, serial numbers, Wi-Fi and Bluetooth MAC addresses, OS versions, purchase orders, warranty dates, AppleCare IDs, Activation Lock, supervision and Lost Mode status, and links to GLPI users. Before you rely on any of this, confirm in a test instance which fields your Jamf Pro version exposes and how often the plugin refreshes them, since the documentation describes what is mapped rather than a sync schedule. Check also that the GLPI user links match your directory identities, because a device assigned to the wrong user will produce confident but misleading reports.
Plan the mapping before the first full sync. Decide which Jamf Pro extension attributes should become searchable GLPI data, who owns each attribute, and whether fields such as purchase orders are maintained in Jamf Pro or in GLPI. Two-way editing is a design choice to verify, not an assumption: confirm with the plugin documentation which direction each field flows. Keep a reconciliation check for devices that exist in both systems under different names, and record the agreed field ownership in your runbook so that later plugin upgrades do not silently change who is the source of truth.
What you need before connecting Jamf Pro to GLPI
The Jamf plugin depends on three things lining up: a GLPI instance on a supported version and database, a Jamf Pro API account with the right read access, and a network path from GLPI to the Jamf Pro server. Check each one before any sync is configured, because a gap in any of them usually shows up as failed or partial inventory.
GLPI version and database
Start with the GLPI version, since the Jamf plugin must match it. The GLPI installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, and state that only MySQL and MariaDB are supported. GLPI 12.0.0 was released on October 7, 2026 and its README lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later. Confirm the target version and its database minimums with your own platform team before you build anything on top of it.
Plugin version matched to GLPI
Confirm in the Jamf plugin documentation which plugin release supports your exact GLPI version. A plugin built for one major version may not load on another, so pin both versions in your change record. Ask the plugin maintainers how they handle the 11 to 12 transition before you schedule the upgrade.
Plugin installation and activation
Install the Jamf plugin into the GLPI plugins directory and activate it from the plugin management screen. Since GLPI 11.0, plugins are suspended when a new version is detected, and they must be reactivated after major updates. Add a reactivation and sync check to every GLPI upgrade runbook, or your Apple inventory will stop updating without an obvious error.
Jamf Pro API account permissions
Create a dedicated API client or service account in Jamf Pro rather than reusing a personal administrator login. Grant only the read privileges the plugin needs for computers, mobile devices, software and extension attributes, and confirm the exact privilege set with Jamf and the plugin documentation. Record who owns the account and how its credentials are rotated, since a disabled or expired account will stop every sync.
Network path to the Jamf Pro server
GLPI must reach the Jamf Pro server over HTTPS from the host or container that runs the plugin's sync jobs. Check firewall rules, proxies and DNS from that exact host, not from a workstation, and confirm whether your Jamf Pro instance is cloud hosted or on premises. Ask your network team to confirm any egress allowlists before the first run.
Data handling and ownership decisions
Decide which fields will reach GLPI before the first sync. The plugin can carry serial numbers, UDIDs, MAC addresses, warranty dates, AppleCare IDs and links to GLPI users, so agree with privacy and security owners who may read that data. Also decide who maintains the mapping rules when Jamf Pro administrators add new extension attributes.
How to configure the Jamf plugin in GLPI in order
This sequence connects Jamf Pro to GLPI in a controlled order: protect the GLPI instance, connect with a read-only API client, then prove the mapping on three known records before widening scope. Each step closes with a check you can perform yourself, so problems surface on a few devices before they reach the whole fleet.
Back up GLPI before any change
The administrator who owns the GLPI server takes a full backup before touching the plugin layer. Back up the database, the application files and the config directory, including glpi.key and glpicrypt.key, so the instance can be restored if the synchronization writes unexpected data. Store the copy outside the GLPI server and confirm that a restore is possible. Done when the backup files exist in a separate location and the database dump opens without errors.
Install and activate the Jamf plugin
The GLPI administrator installs the Jamf plugin into the GLPI plugins directory and activates it from the plugin list. Before installing, confirm in the plugin documentation that the release supports your GLPI version, and check the install notes for any required PHP extensions. Done when the plugin shows as active and the GLPI logs show no errors after a page reload.
Create a read-scoped Jamf Pro API client
A Jamf Pro administrator creates an API client limited to read scope, so GLPI can pull inventory without the ability to change devices in Jamf Pro. Store the client credentials in your secrets store, not in tickets or shared notes. Ask the Jamf administrator to confirm which privileges the read scope includes in your Jamf Pro version. Done when the client authenticates from a test call made outside GLPI and returns computer and mobile device records.
Enter the Jamf Pro URL and credentials
The GLPI administrator enters the Jamf Pro base URL and the API client credentials in the plugin configuration. Use the exact hostname Jamf Pro is served from and an HTTPS address. Restrict access to the configuration to a small group of administrators, because the stored credentials allow reading device inventory. Done when the settings save without error and the secret no longer appears in plain text on the configuration screen.
Run the connection test
Run the plugin's connection test before enabling any synchronization. A failure at this point usually traces to the URL, the API client scope or network reachability from the GLPI server to Jamf Pro, so check them in that order. Confirm that your firewall rules allow the GLPI server to reach Jamf Pro. Done when the test reports a successful connection and the plugin log shows a completed authentication.
Configure synchronization tasks and scope
Enable the synchronization tasks for computers, mobile devices and software, and limit their scope to the Jamf Pro groups or device sets you plan to manage. Confirm in the plugin documentation which identifiers the plugin matches on, and check how Jamf Pro users map to GLPI users. Run each task manually once. Done when the task log reports processed records for each object type and the count of unmatched items is small enough to review by hand.
Validate one computer, one iPhone or iPad and one software item
Choose one Mac, one iPhone or iPad and one application that you can check directly in Jamf Pro. Compare the serial number, model identifier, OS version and warranty or AppleCare fields in GLPI with the values in Jamf Pro, and confirm that the software item links to the correct installation on the Mac. Done when the serial numbers match exactly, the last-inventory date in GLPI reflects a recent Jamf Pro check-in, and the iPhone or iPad appears under phones.
Widen synchronization to the full fleet
After the three sample records match, extend the scope to all managed devices and schedule the recurring synchronization. Review the unmatched items and duplicates that the first full run reports, and resolve them in Jamf Pro or GLPI before the schedule runs unattended. Record the scope, the owner of the API client and the schedule in your runbook. Done when a full run completes, every unmatched item has an explanation, and the schedule is documented.
How Jamf Pro computers, phones and software map to GLPI objects
The Jamf plugin for GLPI maps each Jamf Pro record to a GLPI object type, and the mapping decides where every later sync, report and duplicate check lands. Jamf Pro computers become GLPI computers. Mobile devices become GLPI phones when they are iPhones or iPads, while Apple TV devices are stored as computers, not phones, so reports that count phones will not include them. Software titles, their versions and their installations map to GLPI software, software versions and installations. Before go-live, export a sample of each Jamf device type and confirm with the plugin documentation which GLPI type each one produces, so that a fleet report filtered by asset type returns what the security team expects.
The identifier you rely on for matching matters more than the object type. The plugin synchronizes model identifiers, UDID, serial numbers and Wi-Fi and Bluetooth MAC addresses, and these fields are the natural keys for finding an existing GLPI record. If GLPI Agent, an SCCM feed, a manual import or another source has already created a computer with the same serial number but a different name, or if a Mac reports a MAC address that changes between sources, the result is a second record for one machine. Duplicates split warranty dates, owner links and installed software across two assets. Run a duplicate search on serial number after the first sync, decide which source is authoritative for each field, and set the matching and merge rules before enabling scheduled sync.
Extension attributes are the Jamf fields your organization defines for its own data, such as a department code or an encryption status script result. The plugin stores them in searchable plugin tables rather than in core asset fields, so they can be filtered and reported on without changing the GLPI asset schema. The trade-off is that these tables are separate from the standard asset views, so teams need a short list of attributes that matter and a named owner for each one. Confirm with the plugin documentation which attribute types are read, how often they refresh, and how removed attributes are handled, because stale values in these tables can look current in a report.
Which Jamf Pro fields land in which GLPI fields
This table lists the Jamf Pro data the GLPI Jamf plugin documents as synchronized, the GLPI item or field where each lands, and what to confirm in your own plugin version. Read it as a checklist for a pilot: map each field, then check it on a sample Mac, iPhone and iPad before you rely on the inventory. The main takeaway is that user links depend on identity matching, so plan that step before the first sync.
| Jamf Pro data | GLPI destination | What to confirm |
|---|---|---|
| Model identifiers | Computer or phone model and type, by device class | Confirm the model naming for Macs, iPhone and iPad in your Jamf Pro version |
| UDID and serial number | Device identifiers on the GLPI computer or phone item | Confirm which identifier is used as the match key when an existing asset already exists |
| Wi-Fi and Bluetooth MAC addresses | Network port records on the matched item | Confirm whether both addresses are created for mobile devices and how duplicates are handled |
| OS versions | Operating system and version fields on the item | Confirm that iOS, iPadOS and macOS versions update on each sync cycle |
| Purchase orders and warranty dates | Purchase and warranty fields, or linked contract records | Confirm whether warranty dates write to the item or to a contract, and check date formats |
| AppleCare IDs | Warranty or support identifier on the item | Confirm the field exists in your GLPI version and is populated by Jamf Pro |
| Activation Lock, supervision and Lost Mode status | Status values stored with the device record | Confirm how each status is displayed and whether it is searchable in plugin tables |
| Installed software, versions and installations | Software, version and installation records linked to the item | Confirm software naming matches your existing catalog to avoid duplicate software entries |
| Linked GLPI users | User field on the item, set only when an identity matches | Confirm the match rule (for example, username or email) and review unmatched devices before go-live |
Security settings for the Jamf to GLPI connection
A Jamf to GLPI sync moves device identity, ownership and security state into a second system, so the account that reads Jamf Pro and the account that writes into GLPI each need narrow rights. The cards below cover the Jamf API account, the secrets and encryption keys GLPI holds, who can see mobile records, and how Lost Mode and Activation Lock data is handled.
Scope the Jamf Pro API account
Create a dedicated Jamf Pro API client for the GLPI plugin instead of reusing an administrator login. Grant read access only to the object classes the sync maps, such as computers, mobile devices, software and extension attributes, and deny write and management actions. Ask the Jamf plugin documentation which privileges each object type requires, then test the account against a sample of records before the first full run.
Protect the API secret in GLPI
The Jamf credentials are stored in the GLPI database, so anyone with database or configuration access can read them. Store the secret only in the plugin configuration, rotate it on a schedule and on staff changes, and record the rotation date in your password manager. Confirm with the plugin documentation whether the secret is encrypted at rest and how it is handled in exports and logs.
Back up glpi.key and glpicrypt.key
GLPI uses the files glpi.key and glpicrypt.key to protect encrypted values. If they are lost, stored secrets such as the Jamf credentials may not be recoverable from a restored database. Back them up with the database and the config directory, store the copies separately from the database backup, and restrict read access to the operators who need them. Test a restore on a non-production instance to confirm the secrets still work.
Restrict GLPI profiles to sync and reporting
Give the account that runs the synchronization and the staff who read reports separate GLPI profiles with only the rights they need. Keep configuration rights for the Jamf plugin with a small administrator group, and remove delete rights on computers and phones for reporting users. Review the profile matrix after each plugin upgrade, because new object types can add rights to existing profiles.
Handle Lost Mode and Activation Lock data
Lost Mode, supervision and Activation Lock status show whether a device is missing or locked, and they can be linked to a named user through the user mapping. Treat these fields as sensitive personal and device data, decide who may read them, and set a retention rule for records of devices that have been retired. Confirm with your privacy team which fields your jurisdiction and internal policy classify as personal data.
Limit mobile records by entity
GLPI entities separate records by business unit, site or customer. Map Jamf sites or device groups to GLPI entities so that phones and tablets are visible only to the teams responsible for them. Check how the plugin assigns entities during sync, since a mapping error can place records in a broader entity than intended. Test with one entity and a restricted user before enabling the full sync.
Common Jamf Pro to GLPI sync failures and fixes
This table lists the sync failures we most often expect to see when Jamf Pro data reaches GLPI, with a likely cause and a check to run for each. Treat the causes as starting points for diagnosis rather than guaranteed results, and work through the rows in order because early failures such as connectivity or permissions hide later ones.
| Failure | Likely cause | Check and fix |
|---|---|---|
| API authentication or permission errors | The Jamf Pro API client or account lacks read access to computers, mobile devices, software or extension attributes, or the credentials have expired or been rotated. | Confirm the account used by the plugin has the read privileges listed in the plugin documentation, then test the credentials directly against the Jamf Pro API from the GLPI server before editing plugin settings. |
| Jamf Pro URL unreachable from the GLPI server | The GLPI server cannot resolve or reach the Jamf Pro hostname, usually because of firewall rules, proxy settings, DNS differences between networks or a certificate the GLPI host does not trust. | Run a connection test from the GLPI host itself, not from an administrator workstation. Check DNS resolution, outbound firewall rules to the Jamf Pro port, proxy configuration and whether the internal certificate authority is trusted by the PHP and operating system stack. |
| Duplicate computers in GLPI | The Jamf record and an existing record, often created by GLPI Agent or another tool, do not share a serial number or UDID, so matching rules create a second asset. | Compare serial and UDID for a sample of duplicates. Decide which tool is the authoritative source for each device, then align matching rules or clean up the older records before the next full synchronization. |
| iPhones or iPads missing from GLPI | Devices are not supervised, were enrolled with a method that does not expose the fields the plugin reads, or are filtered out by the scope of the synchronization. | Check supervision and enrollment type for a missing device in Jamf Pro. Confirm that the device appears in the scope the API user can see, and review which mobile device fields the plugin maps before assuming the device was skipped by error. |
| User links not created | The Jamf Pro user or email does not match the GLPI user record, for example because of different usernames, missing email addresses or directory accounts that exist in only one system. | Pick a few devices with no linked user and compare the Jamf Pro username and email with the GLPI account. Align the identifier used for matching, or correct the GLPI user records, and then run the synchronization again to confirm the link. |
| Software duplicated across versions | Software names vary between installations, or each version is stored as a separate software item, so one application appears several times in the inventory. | Review a few duplicated titles and their versions. Decide how the software catalogue should group versions, normalize names where the plugin allows it, and check software reports before treating the counts as accurate. |
| Plugin suspended after a GLPI update | Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so the Jamf plugin stops running until someone enables it. | After every GLPI update, check the plugin list in the GLPI administration area and reactivate the Jamf plugin. Confirm the plugin version is compatible with the GLPI version before reactivating, and review the update procedure in the installation documentation. |
Questions buyers ask before connecting Jamf Pro to GLPI
What drives the effort of connecting Jamf Pro to GLPI?
The main drivers are the size of your Jamf Pro estate, the mix of device types, how cleanly identities match between Jamf Pro and GLPI, how many extension attributes you want searchable, and which GLPI version you run. A fleet of mostly Macs with clean user records is a very different job from a mixed estate of computers, iPhones, iPads and Apple TV devices where user names do not match. Ask for a scoping step that inventories these factors before any quote is written.
Which device types does the Jamf plugin map into GLPI?
According to the GLPI Jamf plugin documentation, Jamf Pro computers map to GLPI computers, mobile devices map to phones for iPhone and iPad, and Apple TV devices map to computers. Software maps to software, with versions and installations, and extension attributes map to searchable plugin tables. Confirm with your own device inventory whether every device class you need is covered by these mappings before you agree on scope.
What data does the Jamf plugin synchronize?
The plugin documentation lists model identifiers, UDID, serial number, Wi-Fi and Bluetooth MAC addresses, OS versions, purchase orders, warranty dates, AppleCare IDs, Activation Lock, supervision and Lost Mode status, and links to GLPI users. Review this list with your security and asset teams, because some fields such as Activation Lock and supervision state may matter for audit or offboarding, and others may not be needed in your GLPI instance.
What access do we need to provide for the integration?
You need a Jamf Pro account with enough privilege to read the inventory data the plugin uses, and a GLPI administrator account to install, configure and activate the plugin and to set mapping rules. Your team also needs to approve a test scope and sign off on the field mapping before production sync starts. Ask the partner to write down the exact Jamf Pro permissions requested so your Jamf administrators can review them against least-privilege policy.
Can our internal team do this without a partner?
Yes, for a small pilot. A team with Jamf Pro and GLPI administration experience can install the plugin, connect a test Jamf Pro instance, check mappings against a limited device group and review the results, using the plugin documentation as the guide. The harder parts are identity matching for user links, extension attribute design, and agreeing a mapping that your audit and asset owners accept. Many teams bring in a partner for those design decisions and for the production rollout.
How is the cost of a Jamf Pro to GLPI integration structured?
DeployOpen works to a fixed-scope quote based on written scope, deliverables and timelines agreed before work starts. The one-time part usually covers discovery, plugin installation and configuration, mapping design, test runs and handover. Ongoing costs are separate and depend on whether you want support, upgrades or continuous checks, which DeployOpen offers as retainers. Ask any provider to split the quote into setup and recurring items, and to state what happens if the Jamf Pro estate or device scope changes during the work.
How long does the integration take?
No duration is given here because none has been established for this scope. The timeline depends on the factors above, especially the Jamf Pro scale, identity matching quality and how many review rounds your mapping sign-off needs. Ask for a scoping step that produces a written plan with a schedule, and treat any timeline offered before that step as provisional.
Which GLPI version should we run before connecting Jamf Pro?
Confirm the Jamf plugin's compatibility with your GLPI version before you plan the work, since the plugin documentation and plugin release notes are the authority for that. GLPI 12.0.0 was released on October 7, 2026, and GLPI 11.0.11 on October 1, 2026, according to the GLPI releases page. If you plan a GLPI 11 or 12 upgrade, sequence it before or after the Jamf work so the plugin is not reconfigured twice, and remember that plugins are suspended after a new version is detected.
How DeployOpen scopes and delivers the Jamf Pro integration
DeployOpen plans, implements, tests and documents self-hosted GLPI integrations inside your own infrastructure, and the Jamf Pro work is scoped the same way. The written scope comes first: which Jamf Pro instances and GLPI entities are in play, which Apple device types (Macs, iPhones, iPads and any Apple TV devices) are mapped to which GLPI item types, which Jamf Pro data is synchronized, and who owns the decisions about user mapping and extension attributes. Most engagements are fixed-scope, so deliverables, acceptance checks and timelines are agreed in writing before build work starts. The scope also records what the client provides, such as Jamf Pro API access, a test GLPI instance, and named contacts on the identity and endpoint teams.
Delivery follows the sequence that the integration itself requires. DeployOpen configures the Jamf plugin in a non-production GLPI, runs an initial synchronization against a representative set of devices, and checks the results field by field: serials, UDIDs, MAC addresses, OS versions, warranty dates, Activation Lock and supervision state, and the links to GLPI users. Extension attribute mappings and any GLPI upgrade or plugin reactivation steps are validated in the same test cycle. Documentation covers the configuration, the synchronization schedule, the rollback steps and the operator runbook, and is handed over with the environment. Testing and documentation are deliverables in their own right, not side effects of the build.
Pricing is not published as a list. A quote follows from the written scope, so the figures you receive depend on the device count, the number of Jamf Pro and GLPI environments, the extension attribute work and the test effort required. Ongoing support, plugin and GLPI version upgrades, and periodic re-testing of the synchronization are available as a retainer, which is often the right choice once the integration is running. Ask any partner, including DeployOpen, to state in writing what is included, what is excluded, and which costs recur after go-live.
