How GLPI sends notifications through SMTP with OAuth
If GLPI notifications have stopped, or are about to, because your Microsoft 365 or Gmail mailbox no longer accepts basic authentication, the replacement GLPI supports for outbound mail is its SMTP+OAUTH sending method. Instead of storing a mailbox password in the notification settings, GLPI requests an access token from the identity provider and presents that token to the SMTP server. The mail provider still delivers through its own SMTP endpoint, so your existing sender address and routing stay in place, but the credential changes from a password to a token that expires and renews.
For Microsoft Entra, the documented procedure registers the application under App registrations, not Enterprise applications, and adds GLPI's callback URL as a web redirect URI. You then create a client secret with an expiry date. Put that expiry in your renewal calendar with an owner, because when the secret lapses notifications fail again even though nothing in GLPI changed. Confirm the exact redirect URI format, the required API permissions for SMTP sending, and whether your tenant needs admin consent in the GLPI Help Center guide for OAuth SMTP with Entra before you configure anything.
The supplied procedure covers Microsoft Entra only. The Gmail side, including how the Google Cloud client is created, which scopes GLPI requests, consent screen status for a Workspace domain, and how the sending account is authorized, is not covered by the source we used for this topic, so confirm each of those steps against Google's current documentation and GLPI's own settings screens before relying on them. Test a notification from a real ticket after each change, and check the GLPI notification queue for errors that name the authentication step.
What you need before configuring OAuth SMTP
OAuth SMTP for GLPI depends on four things lining up: the GLPI release, a public HTTPS address that matches the redirect URI, an Entra tenant where you can register an app, and a sending mailbox with a working network path. Confirm each one before you touch the notification settings, because a mismatch in any of them shows up as a failed send that looks like a credential problem.
GLPI release and procedure version
Confirm which GLPI release you run and open the GLPI Help Center procedure for OAuth SMTP with Entra before you start. The steps are tied to the documented setup, so a release gap can change field names or menu paths. Record the exact version in your change ticket, since the GLPI 11 and 12 lines are both in active use and upgrade timing may affect the steps. Plan any upgrade before the app registration so you do not configure twice.
Public HTTPS URL for the callback
The callback URL that GLPI generates must be copied exactly into the Entra app as a web redirect URI, so it must match the address users reach in the browser. Confirm the public hostname, the scheme and any path prefix behind your reverse proxy or load balancer. An internal name or a plain HTTP address will produce a redirect error during consent. Decide now who owns DNS and the certificate, because changing the hostname later means updating the registration again.
Entra tenant and app registration rights
The procedure registers an app under App registrations, not Enterprise applications, so the person doing the work needs permission to create app registrations in the tenant. Identify which tenant holds the sending mailbox and confirm whether your organization restricts app registration to administrators. Ask your Entra administrator to approve the registration in advance if a tenant policy blocks it. Record the tenant ID and who holds the administrative role.
Sending mailbox and its owner
Decide which mailbox will send GLPI notifications and confirm it is a licensed account that supports the sending path you intend to use. A shared or service mailbox is common, but the account must be allowed to send mail and must not depend on multifactor prompts that a background service cannot answer. Name an owner for the mailbox and for the notification sender address, because bounced messages and reply traffic land there. Check whether your mail policy requires a specific sender domain.
Client secret ownership and expiry
The client secret created in Entra has an expiry date, and when it lapses GLPI stops sending through OAuth without warning in the GLPI interface. Choose the expiry period with your security team, store the secret in your approved vault rather than in a ticket, and add the expiry date to your calendar and monitoring. Assign a named owner who receives renewal reminders. Renewal means generating a new secret and updating GLPI, so plan it as a routine change.
Network path to the SMTP endpoint
GLPI must reach the SMTP submission endpoint and the Microsoft or Google sign-in endpoints from the server that sends mail. Confirm outbound rules from the GLPI application server, any proxy it uses for external traffic, and DNS resolution for those hosts. Check that a firewall or egress policy does not inspect and break TLS to the mail provider. Test connectivity from the GLPI host itself, since a workstation test proves nothing about the server path.
Configuring the Entra app and GLPI sender in order
This sequence takes a Microsoft 365 tenant from no sending identity to a GLPI instance that sends notifications over SMTP with OAuth. Each step closes with a check, so the team knows the registration, the secret and the sender work before notifications depend on them.
Confirm the GLPI callback URL and sending mailbox
Before opening the Entra portal, the GLPI administrator and the Microsoft 365 administrator agree on two values: the exact callback URL that GLPI shows for OAuth SMTP, and the mailbox that will send notifications. The callback URL must match the public address users reach, including the scheme and path, because Entra compares it character by character. Record both values in the change ticket. The check is a written note, agreed by both administrators, that names the callback URL and the sending mailbox.
Register the app under App registrations
In the Microsoft Entra admin center, the tenant administrator creates a new registration under App registrations. Do not use Enterprise applications for this step, because the documented GLPI procedure relies on an app registration. Give the app a name that identifies GLPI and its purpose, and choose the supported account type that matches your tenant design. The check is an app registration with an Application (client) ID visible on its overview page, which you copy to the change record.
Add the GLPI callback URL as a web redirect URI
In the registration, open Authentication and add a web platform redirect URI. Paste the callback URL confirmed in the first step exactly as GLPI displays it. Save the change, then reopen the page to confirm the URI is stored without trailing spaces or a changed path. The check is a saved web redirect URI that matches the GLPI value character for character, verified by a second person reading both screens.
Create the client secret and record its expiry
Under Certificates and secrets, the administrator creates a client secret and selects an expiry date. Copy the secret value immediately, because Entra does not show it again after the page is left. Record the expiry date in your certificate or secret tracker with a named owner and a renewal reminder before that date. Store the value in your approved secrets store, not in a shared document. The check is a secret value stored securely and an expiry date entered in the tracker.
Grant the mail permissions and confirm consent
Under API permissions, the administrator adds the permissions that the GLPI documentation for the SMTP+OAUTH method specifies for sending mail, then grants admin consent for the tenant. Confirm the permission status shows as granted rather than pending. Check your tenant's own policies, since some organizations restrict consent or require approval workflows. The check is a permission list in which every required entry shows admin consent granted.
Enter the client ID, secret and sender in GLPI
In GLPI, the administrator opens the notification settings and selects the SMTP with OAuth option. Enter the Application (client) ID, the client secret value, the tenant information required by the form, and the sending mailbox confirmed earlier. Save the configuration and review each field against your change record before leaving the page. The check is a saved configuration that shows the expected client ID and sender, with no field left blank.
Send a test notification and confirm token refresh
Trigger a test notification from GLPI to a mailbox you control, and confirm that it arrives from the sending mailbox. Then review GLPI's logs for the token request and any refresh events, and confirm that the OAuth exchange completed without errors. Keep the test in the change record. If the test fails, check the redirect URI, the client secret and the consent status before changing anything else. The check is a delivered test message and log entries showing a successful token exchange.
Which Entra and GLPI values map to which settings
This table maps each value you collect in Entra ID to the GLPI notification setting that stores it, with the step where it is created and the team that owns it. Read it in order during setup, and keep the client secret expiry date recorded next to the secret so renewal is not missed.
| Value | Where it comes from | Where it goes in GLPI | Owner |
|---|---|---|---|
| Application (client) ID | Entra admin center, App registrations, the overview page of the GLPI app registration | SMTP+OAUTH sending method, client ID field in the notification mail configuration | Entra administrator who registers the app |
| Directory (tenant) ID | Entra overview page for the tenant that hosts the sending mailbox | Tenant identifier used in the OAuth token endpoint settings for the SMTP connection | Entra administrator |
| Client secret value | Certificates and secrets page, copied once at creation time | Client secret field in the GLPI SMTP OAuth configuration, stored encrypted by GLPI | Entra administrator creates it, GLPI administrator enters it |
| Client secret expiry date | Shown next to the secret in Entra when it is created | Not stored in GLPI, so record it in your renewal calendar with a reminder before expiry | Entra administrator, with a named backup owner |
| Redirect URI | GLPI callback URL shown in the GLPI OAuth SMTP setup page, added as a web redirect URI in the app registration | Must match the callback URL exactly, including scheme and path, in the Entra app | GLPI administrator supplies the URL, Entra administrator enters it |
| Sending mailbox address | Microsoft 365 or Gmail account that is permitted to send mail for the organization | From address in the GLPI notification sender settings, which must match the authorized mailbox | Mail administrator confirms the mailbox and its permissions |
| SMTP host and port | Provider SMTP submission endpoint for the sending account, confirmed in the provider documentation | SMTP server and port fields in the GLPI mail configuration, with encryption set to match | Mail administrator confirms, GLPI administrator enters |
Why basic authentication SMTP fails and what changes for senders
Basic authentication means the sending client presents a username and password each time it opens an SMTP session. Microsoft 365 and Google have both moved their mail submission services toward OAuth 2.0, where the client receives a token issued to a registered application after an administrator or user grants consent. Password-based SMTP sign-in is being restricted in both platforms. The exact dates, tenant-level switches and any remaining exceptions are set by each provider and change over time, so confirm current policy with Microsoft and Google before you plan. For GLPI, the practical risk is that a notification sender configured with a password can stop delivering mail with no change on the GLPI side.
Shared mailboxes and service accounts are where this change hits hardest. Many GLPI instances send notifications from a generic address such as a helpdesk or noreply mailbox, signed in with a password held by a service account. Under OAuth, the token belongs to an application that someone with the right administrative role must approve, and the application must be granted access to the sending mailbox. Confirm which identity will own the registration, whether the mailbox type supports the sign-in method you plan to use, and who approves the permissions. Record that ownership in your documentation so the setup does not depend on one person's memory.
The main operational change is the credential lifecycle. A password is rotated on the account's own schedule, while the OAuth setup relies on a client secret on the app registration, and that secret has an expiry date you choose when you create it. When it expires, outbound mail stops without any password change or visible error in the mailbox, so the expiry date belongs in your operations calendar and in your monitoring. Also plan for the consenting person leaving the organization. The Entra setup for GLPI is covered in the GLPI Help Center guide to OAuth SMTP with Entra, which is the natural next read.
Protecting the client secret and the sending mailbox
These controls keep the OAuth SMTP setup safe after the first test send succeeds. Each card covers one part of the setup that drifts over time: the secret, its expiry date, the sending mailbox, the people who can change mail settings and the record of failures. Review them together each time the client secret is rotated.
Store the client secret carefully
The client secret that GLPI uses to request tokens is a credential, so it should never sit in a ticket, a chat thread or a shared spreadsheet. Record it in the secrets store your team already operates, limit who can read it, and remove copies from setup notes once the mail settings are saved. Confirm with your GLPI administrator whether the stored configuration protects the value at rest, and how GLPI's key files relate to it on your version.
Track the secret expiry date
A Microsoft Entra client secret is created with an expiry date. When it passes, token requests fail and notifications stop, and GLPI may not explain the cause clearly. Add the date to a shared rotation calendar, set reminders well before it, and create the replacement secret in the app registration before the old one expires. Confirm the maximum lifetime your tenant allows when you create a secret.
Scope the sending mailbox
Send notifications from a dedicated mailbox so that a staff departure or password reset does not break alerts. Grant the app only the mail send permission that the setup procedure documents, and confirm the exact permission names, admin consent steps and any mailbox restrictions with Microsoft before you approve them. Keep the app registration owned by two named people so that changes have a clear approver.
Limit who edits mail settings
Anyone who can change GLPI's SMTP host, sending method or sender address can redirect notifications or send credentials to another server, so restrict those settings to a small administrator group. Keep mail administration in a separate profile from day-to-day ticket work, and review profile assignments on a regular schedule. GLPI 12.0.0 added step-up authentication for certain administrative actions, so check whether it covers mail configuration on your version.
Log token and send failures
Token refresh errors and rejected sends are often the first sign of an expired secret or revoked consent, so decide where they will be seen before go-live. Check GLPI's notification records, the web server and PHP error logs, and the sign-in records for the app in Microsoft Entra. Confirm which of these entries show SMTP OAuth failures on your version, and send an alert when failures repeat.
Common failures when GLPI notifications stop sending
This table pairs each common failure in GLPI SMTP with OAuth setups for Microsoft 365 with its likely cause and fix. Read it from the error or symptom you see in GLPI or the mail provider logs, then check the cause column before changing settings. Most failures trace back to the Entra app registration, the callback URL, or a secret that has expired.
| Symptom or error | Likely cause | Fix |
|---|---|---|
| AADSTS50011 redirect URI mismatch | The web redirect URI on the Entra app does not exactly match the callback URL shown in GLPI's SMTP+OAUTH configuration, including scheme, host, path or trailing slash. | Copy the callback URL from GLPI again, set it as a web redirect URI on the app registration, save, then retry the authorization step. |
| Authorization succeeds but sending fails after a period | The client secret has expired. Entra client secrets have an expiry date chosen at creation. | Create a new client secret, update it in GLPI, and record the new expiry date in your renewal calendar before the old one lapses. |
| Setup cannot find the app or sign-in is denied | The app was created under Enterprise applications instead of App registrations, so the client ID and secret GLPI needs are not available there. | Delete or ignore the Enterprise application entry, register a new app under App registrations, and use its application (client) ID. |
| SMTP authentication rejected for the sending mailbox | The account or mailbox has not been granted permission to send through SMTP for the app, or SMTP AUTH is disabled for the tenant or mailbox. | Ask the Microsoft 365 administrator to confirm the SMTP AUTH permission for the sending mailbox and tenant policy, then retest. Confirm the current permission names in Microsoft documentation. |
| Notifications still fail after a configuration change | A stale access token or cached authentication from the previous client ID, secret or redirect URI remains in use. | Clear the stored OAuth authorization in GLPI, run the authorization flow again, and send a test notification to confirm the new token is in use. |
| Gmail sending stops with an authorization error | The Google client was not configured for the callback URL or the consent step was not completed for the account that sends notifications. | Check the authorized redirect URI in the Google client, repeat authorization with the sending account, and confirm the sender address matches that account. |
Questions buyers ask before configuring OAuth SMTP for GLPI
Can our own team configure OAuth SMTP for GLPI without a partner?
Yes, if your team has administrator access to the Microsoft Entra tenant or Google Cloud project and someone who can administer the GLPI server and its notification settings. The work is a sequence of configuration steps: registering an app, setting GLPI's callback URL as a web redirect URI, creating a client secret, and entering the values in GLPI's notification configuration. The harder part is usually tenant policy, such as app consent rules and mailbox permissions, which often needs a second team to approve. A partner adds value when that approval path is slow, when several mailboxes or tenants are involved, or when you want the change tested and documented for audit.
What does the client secret expiry mean for ongoing operations?
A client secret created in the Entra app registration has an expiry date chosen when it is created. When it expires, GLPI can no longer obtain tokens, and outbound notifications stop being sent until a new secret is created and entered in GLPI. Treat the expiry as a recurring operational task: record the date, assign an owner, set a reminder well before it, and test notification delivery after each rotation. Confirm the maximum lifetime your tenant policy allows, because some organizations require shorter lifetimes or certificate-based credentials instead.
Does a Microsoft 365 or Gmail mailbox need a special account type for this?
The mailbox must be allowed to send mail over SMTP with OAuth, and that permission depends on your provider and tenant settings. For Microsoft 365, confirm that the mailbox and tenant allow authenticated SMTP submission and that the app registration is granted the permission needed to send mail. For Gmail, confirm the Google Workspace administrator permits the client and the sending account. Check these settings with your provider documentation and your tenant administrator before you start, because a blocked setting is the most common reason a configuration appears correct but fails at send time.
How long does the setup take in general terms?
The configuration itself is short once access is in place, and most of the elapsed time usually goes to approvals: tenant administrators reviewing the app registration, security teams accepting a client secret, and change windows for the GLPI server. Duration depends mainly on how quickly those approvals move and on how many mailboxes and GLPI instances share the setup. We do not give a fixed duration here. Ask any provider for a timeline in a written scope that lists the approval steps and the tests that close the work.
What does tenant policy change in the effort?
Tenant policy often decides the effort more than the GLPI configuration does. Conditional access, app consent restrictions, restrictions on which applications can read or send mail, and secret lifetime limits all change which steps are possible and who must approve them. In a tightly governed tenant, expect extra review of the app registration scope and the client secret policy. Ask your identity team to list these restrictions before scoping, so the approval work is planned instead of discovered during the build.
How do the number of mailboxes affect the work?
A single notification sender is a small task. Each additional sending mailbox, shared mailbox or GLPI instance adds configuration, permission review, and test runs, and it adds one more secret to track for expiry. Mailboxes that send from different domains or belong to different tenants usually need separate app registrations or separate reviews. Ask for the mailbox list, the tenants involved and the number of GLPI instances when requesting a quote, because those counts drive most of the effort.
What must our team provide before the setup starts?
You need tenant administrator access, or a named administrator who can create the app registration and grant the required permissions. You also need administrator access to the GLPI server and its notification settings, the sending mailbox details, the public URL that GLPI uses so the callback URL is correct, and a dedicated test mailbox that can receive and send notifications during verification. Agree who owns the client secret after handover, where it is stored, and who receives the expiry reminder.
How DeployOpen scopes and supports GLPI mail integrations
DeployOpen plans, builds and hands over GLPI email notifications over SMTP with OAuth for Microsoft 365 and Gmail inside infrastructure you control. Each engagement starts with a written scope that names the mail tenant, the GLPI instance and the notification types in use, so the work is agreed before any app registration or credential change is made.
How we scope
- Inventory which GLPI notification events and recipients depend on the current SMTP sending method today
- Confirm whether the tenant is Microsoft 365 or Google Workspace and who administers each side
- Record the public GLPI URL and the exact callback URL that the identity provider will redirect to
- Agree in writing which mail collectors and OAuth IMAP flows are in or out of the same engagement
How we build
- Register the Entra application under App registrations, not Enterprise applications, with GLPI's callback URL as a web redirect URI
- Create the client secret with a documented expiry date and store it in a controlled location, not in a ticket
- Configure the SMTP+OAUTH sending method in GLPI and send test notifications for each event type in scope
- Check notification queue behavior and mail logs so failed sends surface to the team that owns GLPI
How we hand over
- Deliver a runbook with app registration settings, redirect URIs, permissions granted and the secret expiry date
- Document who receives expiry reminders, how the secret is rotated and which GLPI settings change at rotation
- Provide a test log showing each notification type sent successfully through the chosen provider
- Walk your administrators through the rotation steps and record the sign-off in the agreed scope
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Re-check the mail flow when GLPI moves to a new major version or when plugins are reactivated after an update
- Ask any support provider to confirm response terms and mail-tenant access in writing before work starts
- Quotes follow from the written scope, so ask for each component, recurring work and any licensing your tenant requires
