How Graylog Microsoft 365 and Okta audit log ingestion works
If you need Microsoft 365 and Okta audit trails in the same Graylog that holds your server, network and application logs, the work is set up two documented inputs: the Office 365 input and the Okta Log Events input. Both are Enterprise-licensed features, so they are not available on Graylog Open, which is licensed under SSPL-1.0 and is not an OSI-approved open source license. Neither input waits for the SaaS vendor to push events to a port. Each one polls the vendor's API on a schedule and pulls new records into Graylog, which means the design questions are about credentials, permissions, network egress and polling behavior rather than syslog listeners. This page covers the prerequisites for each input, the Azure and Okta credentials they depend on, polling interval choices, and the version issues to check before you upgrade.
The Office 365 input reads the Office 365 audit log through a client application that your organization authorizes in the Azure portal. Before configuring the input, confirm that the subscription behind the tenant includes audit log access. The Graylog documentation says E5 and A5 accounts typically have it, so check your own license assignments rather than assuming they match. The Okta Log Events input pulls Okta System Log events using an Okta API key, and that key's owner and scope determine what events you can read. Treat both credentials as secrets: decide who creates them, where they are stored, how they are rotated, and which Graylog role can view the input configuration. Ask your Microsoft and Okta administrators to confirm these items in writing before anyone opens a ticket for the input.
Version choice matters for the Okta input. The Graylog docs warn that it does not work in Graylog 7.1.0, 7.1.1 and 7.2.0 is not listed as affected, but 7.1.0 through 7.1.2 are affected because of Okta SDK changes, so plan your target release before building. The Graylog 7.2 upgrade notes also state that the Okta input now serializes securityContext.userBehaviors as an array of objects instead of strings, which breaks any custom parsing built on the 7.1 workaround. Read the Graylog docs: Microsoft Office 365 input and the Graylog docs: Okta Log Events input pages for the current settings, and confirm the exact version statements against the release you plan to run.
What you need before creating the Office 365 and Okta inputs
Both inputs depend on access granted outside Graylog: an Azure client application for Microsoft 365 and an Okta API key for System Log events. Confirm these, the license and the Graylog version before you open the input configuration, because a missing permission usually shows up later as an input that starts but returns no events.
Azure client application
The Office 365 input polls the audit log through a client application that your organization authorizes in the Azure portal. Register it in the tenant that owns the Microsoft 365 audit data, record the tenant ID, client ID and secret, and keep the secret in a store you control. Confirm who approves app registrations, because that approval is often the longest step.
Audit log access on the subscription
The tenant needs a subscription with audit log access. The Graylog docs say E5 and A5 accounts typically include it, so check the license assigned to the tenant rather than assuming it. If audit logging is switched off or the subscription lacks the capability, the input will have nothing to read, and no error in Graylog will explain why.
Okta API key with System Log rights
The Okta input pulls System Log events with an Okta API key. Create the key from an account whose role can read System Log events, and record which admin owns it. If that account is later disabled or its role is reduced, polling stops silently, so plan an owner and a rotation date for the key.
Enterprise license
Both the Office 365 and Okta inputs are Enterprise-licensed features on top of Graylog Open, which is licensed under SSPL-1.0. Confirm the license is installed and active on every Graylog node that will run these inputs before you plan the build. Ask the vendor how the license is counted against your daily volume, since the pricing page licenses processed data.
Network reachability to vendor APIs
Graylog nodes that run these inputs must make outbound HTTPS calls to Microsoft and Okta endpoints. Check egress from every node, including proxy rules and firewall allowlists for your Okta tenant domain and Microsoft sign-in and management endpoints. Test from each node itself, since a single test host can pass while the cluster fails.
Graylog version to confirm
Do not run the Okta input on Graylog 7.1.0, 7.1.1 or 7.1.2, because the docs say it does not work there due to Okta SDK changes. Confirm your running version on every node and plan the upgrade path before creating the input. The docs also flag that Graylog 7.2 changes how the Okta input serializes security context fields, which affects custom parsing.
Configure the Office 365 and Okta inputs in sequence
This sequence takes the Azure client application and the Okta API key from identity provider settings through to two running Graylog inputs whose first events are visible in search. Each step ends with a check so a failed prerequisite is caught before the next input is built.
Confirm the Microsoft 365 audit subscription
Before touching Graylog, the Microsoft 365 administrator confirms that the tenant has a subscription with audit log access. The Graylog Office 365 input documentation says E5 and A5 accounts typically include it, so ask your Microsoft licensing contact to verify this for your tenant rather than assuming it. Done means the administrator can see audit search results in the Microsoft Purview portal for a recent test action, which proves the source is producing events before Graylog is involved.
Register the Azure client application
In the Azure portal, a team member with rights to register applications creates an app registration for Graylog. The Graylog Office 365 input authenticates through a client application authorized in your Azure portal, so the registration must be created in the tenant that owns the audit log. Record the tenant ID, the application (client) ID, and the client secret value at creation time, because the secret cannot be read again later. Done means the registration appears in the Azure app registrations list with those three values stored in your secrets vault.
Grant audit log access to the application
Under the app registration's API permissions, the administrator adds the permission the Graylog documentation lists for reading the Office 365 management activity, then grants admin consent for the tenant. Without admin consent the application cannot poll, and the input will show authorization errors. Confirm the exact permission name in the current Graylog Microsoft Office 365 input documentation before adding it. Done means the permission shows as granted with a green consent status in the Azure portal.
Create the Office 365 input in Graylog
A Graylog administrator with an Enterprise license opens System, Inputs, selects the Office 365 input type, and launches it on a Graylog node. Enter the tenant ID, client ID and client secret from the earlier registration, then save. Keep the polling interval at the value the documentation recommends until you have measured event volume. Done means the input shows as running in the Inputs page with no error message in its status panel.
Create an Okta API key
An Okta administrator creates an API token for Graylog from the Okta admin console, under the security API settings. The Okta Log Events input uses this key to read System Log events, so the token should belong to a dedicated service account with the minimum administrative rights needed to read logs. Store the token in your secrets vault and record the Okta org URL it belongs to. Done means a test call from a host you control to the System Log endpoint with that token returns events rather than an authorization error.
Create the Okta Log Events input
In Graylog, the administrator creates an Okta Log Events input on a node, supplying the Okta domain and the API key. Confirm first which Graylog version you run, because the Okta input does not work in Graylog 7.1.0, 7.1.1 and 7.1.2 due to Okta SDK changes. Done means the input reports running status and no connection errors appear in the node logs for the first polling cycle.
Assign both inputs to a stream and index set
Route the events from each input into a dedicated stream with its own index set, so retention and access can be set for identity audit data separately from other logs. Use a stream rule that matches the input or source name so that later changes do not affect unrelated data. Done means each stream lists the correct input as its source and the index set is shown with the retention settings your policy requires.
Confirm the first events appear in search
Wait for the first polling cycle, then run a search over the new stream for the last few minutes, filtering on the input source. Open a sample message from each input and check that timestamps, user fields and action names are populated. Also perform a known action in Microsoft 365 and in Okta and find it in search. Done means both sources return the test events, which is the point where you can start building dashboards and alerts on them.
How polling intervals and the audit trail affect what you see in search
Both the Office 365 and Okta inputs pull events on a polling interval, so every audit event reaches Graylog after a delay. An action taken in Entra ID, Exchange, SharePoint or Okta is not searchable until the next poll completes and the messages are indexed. For an investigation, that means a search run seconds after an admin change may return nothing even though the change happened and the input is healthy. Before you set alert thresholds or tell responders how fresh the data is, confirm the polling options available in each input's settings and measure the real lag in your own tenant by comparing a test action's timestamp with the time it appears in search.
The volume of audit events drives index storage, and the interval only changes how those events arrive, not how many there are. A large Microsoft 365 tenant or an Okta org with heavy sign-in activity can generate far more System Log or unified audit records than its administrators expect, and every record lands in an index set governed by your rotation and retention settings. Estimate daily volume from a representative day of events, not from user counts, and feed that figure into the storage sizing formula in the system architecture guidance. Ask the vendor about per-request and per-day API limits for your tenant, because throttling or a backlog can make the delay grow and then catch up in a burst.
Lookback behavior also determines what you see after the input starts or restarts. Confirm in the input configuration how far back the first poll reads and whether the input resumes from its last position after a restart, since a gap or a duplicate burst in search usually traces back to that setting. Record the answers in your runbook so that analysts know the expected lag and any blind spot around input restarts, upgrades or outages.
How Office 365 and Okta audit fields map to Graylog data
This table compares the main audit identifiers you will filter on in Microsoft 365 and Okta with where they appear in Graylog. Use it to build searches and streams, and confirm each field name against a sample message from your own version before you write rules. The most important takeaway is that Okta's securityContext.userBehaviors changed type in Graylog 7.2, so parsing built on earlier releases must be reviewed before upgrading.
| Audit identifier | Office 365 input | Okta Log Events input | What to confirm |
|---|---|---|---|
| Tenant identity | Tenant or organization identifier from the audit record, used to scope searches to one Microsoft 365 tenant | Okta org or domain context carried in the System Log event | Confirm the exact field name in a sample message from your version, since tenant fields can be nested or renamed |
| User identity | UserId or user principal name recorded for the operation | actor fields identifying the user who performed the event, plus target fields for the affected user | Confirm whether your searches should use the actor or the target field for account changes |
| Operation or event type | Operation name such as the audited action, which varies by workload (Exchange, SharePoint, Azure AD) | eventType value such as user session or policy events | Confirm operation names per workload, since they differ between Microsoft 365 services |
| Client application | Client application or client IP fields recorded with the operation | client fields including user agent and IP address, where Okta supplies them | Confirm whether the client app field is populated for every workload you collect |
| Result and outcome | Result status recorded for the operation, such as success or failure | outcome result and reason values on the System Log event | Confirm the result field name and the values your version emits before building failure alerts |
| Timestamp | Creation time of the audit record, used for ordering and time-based searches | published timestamp of the System Log event | Confirm which timestamp Graylog uses as the message time and whether the vendor time is kept as a separate field |
| securityContext.userBehaviors (Okta) | Not applicable | Graylog 7.2 serializes this value as an array of objects, where earlier releases used strings | Flag for upgrade review: custom parsing or pipeline rules built on the 7.1 workaround must change before or during the 7.2 upgrade |
Securing the Azure app registration and Okta API key
The Office 365 and Okta inputs both hold credentials that can read sensitive audit trails, so their scope and storage matter as much as the input setup. The cards below cover the Azure client application, the Okta API key, how secrets are rotated and stored, who can edit inputs, and how the Graylog backends are protected.
Scope the Azure client application
The Office 365 input relies on a client application authorized in your Azure portal to read the Office 365 audit log. Grant only the permissions the input needs, consent to them deliberately, and record who approved them. Review the registration whenever the input configuration changes, and confirm the exact permission names with the Graylog Office 365 input documentation before you grant anything. Avoid reusing an application registered for another integration.
Rotate and store the Azure secret
The client secret that the Office 365 input uses is a credential that must be rotated on a schedule your security team sets. Confirm the secret lifetime offered by Azure for your tenant, since the maximum depends on your tenant policy. Store the value in the Graylog configuration only through an approved secret handling method, and keep a record of when each secret was issued so rotation does not break polling unexpectedly.
Limit the Okta API key to a service account
The Okta input authenticates with an Okta API key. Create a dedicated service account in Okta for Graylog instead of tying the key to an administrator's personal identity. Give that account read-only access to the System Log, so a leaked key cannot change users, policies or applications. Document the account owner so offboarding of a staff member does not stop log collection.
Restrict who can edit inputs
Anyone who can edit an input can view or replace the stored credentials, change the polling target, or redirect events. Limit input management to a small group of platform administrators, and give analysts search and dashboard roles only. Review the membership of that group on a regular cadence and after staff changes, and confirm the role model available in your Graylog edition before you design it.
Protect the Graylog backends
Credentials in Graylog are only as safe as the storage that holds them. Restrict network access to the MongoDB configuration store and the Data Node or OpenSearch cluster, keep those services off public networks, and make sure backups of the configuration are encrypted and access controlled. Treat a backup restore as a credential exposure event and plan for rotating the Azure secret and Okta key after any suspected leak.
Common failures when Microsoft 365 or Okta events stop arriving
This table lists the failures that most often stop Office 365 or Okta events from reaching Graylog, with the likely cause and the fix for each. Check the rows in order, since the Graylog version and licensing problems are quick to rule out before you inspect credentials or network paths.
| Symptom or failure | Likely cause | Fix |
|---|---|---|
| Okta input produces no messages on 7.1.0, 7.1.1 or 7.1.2 | The Okta SDK changes in these releases break the Okta Log Events input | Upgrade to a release outside 7.1.0 to 7.1.2 before troubleshooting further, following the Graylog 7.2 upgrade notes if you move to 7.2 |
| Office 365 input connects but returns no audit records | The subscription lacks audit log access, which the docs say E5 and A5 accounts typically have | Confirm audit logging is enabled and the licence includes audit log access, then test with an account that has that access |
| Authentication errors from the Office 365 or Okta input | Expired or mistyped Azure client secret or Okta API key, or the key belongs to an account without log read rights | Generate a new secret or key, update the input configuration, and confirm the account or app has permission to read audit or System Log events |
| Inputs time out or fail to connect to the provider | Outbound HTTPS from the Graylog nodes is blocked by a firewall, proxy or egress policy | Allow outbound HTTPS from every Graylog server node to the Microsoft and Okta endpoints your tenant uses, and confirm proxy settings in the server configuration |
| Okta events parse incorrectly or custom rules stop matching after 7.2 | The 7.2 release serializes securityContext.userBehaviors as an array of objects, not strings | Review extractors and pipeline rules that handled the 7.1 workaround, and update them to read the object structure before relying on the fields |
| Events arrive from only one node, or a node shows no input activity | The input was created on a single Graylog node in a multi-node cluster, or the node is not running it | Check input status on each node, run the input on the intended node, and confirm the cluster is healthy so polling is not duplicated or missed |
| Events arrive late or in gaps | Polling interval is too long for the event volume, or the provider or API rate limits are reached | Review the polling interval and the provider's API limits with your tenant administrator, and watch input throughput after changes |
What to check before upgrading Graylog with these inputs in place
Check the Okta input before any Graylog upgrade that touches the 7.1 line. The Okta Log Events input pulls System Log events with an Okta API key, and the Graylog docs warn that it does not work in Graylog 7.1.0, 7.1.1 and 7.1.2 because of Okta SDK changes. If your cluster runs one of those releases, Okta events may be missing from the period it was affected, so confirm which version each Graylog node reports and plan the move off that range as a separate step. Keep the Office 365 input under the same review, since it shares the same upgrade window and the same stream and pipeline configuration.
The larger risk is parsing. The Graylog 7.2 upgrade notes say the Okta input now serializes securityContext.userBehaviors as an array of objects instead of strings. If you wrote pipeline rules, extractors or dashboard queries on top of the 7.1 workaround, those rules will read a different shape after the upgrade. Inventory every rule that references userBehaviors and mark each one for rewrite or removal before you schedule the production change. Confirm the exact field names and behavior against the Graylog 7.2 upgrade notes rather than relying on this summary.
Test both inputs on the target version in a non-production cluster before moving production nodes. Create the Office 365 and Okta inputs with the same configuration you use in production, let them poll for a full working day, then compare the stored messages field by field against a sample of events you can confirm in the Microsoft and Okta consoles. Repeat the comparison on the pre-upgrade version so differences are visible. Only after the field output, stream routing and alert conditions match should you upgrade production, and record the results so an auditor or engineer can see what was verified and when.
Questions teams ask before connecting Microsoft 365 and Okta to Graylog
Do the Microsoft 365 and Okta inputs need an Enterprise license?
Yes, the Office 365 and Okta inputs are covered by Graylog Enterprise or Graylog Security, not Graylog Open. Graylog Open is free with no volume limits and community support, and it supports syslog, GELF and Beats inputs, search, dashboards and alerting. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security starts at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees, according to the Graylog pricing page. Confirm with Graylog which license covers each input in your version, and ask whether the minimum volume applies to your ingest.
How long does Microsoft 365 and Okta log ingestion take to set up?
Duration depends on how quickly the Azure and Okta administrators can create the required registrations and keys, how many tenants or Okta orgs you connect, and whether the Graylog version you run has a known Okta input issue. Most of the work is access and permissions, not Graylog configuration. Test in a non-production Graylog first, confirm the Okta input works on your exact release, and plan a verification window for events to appear in search. Ask any partner for a written timeline tied to the agreed scope, and treat any duration without that scope as a guess.
What do the Azure and Okta administrators need to provide?
The Azure administrator needs to register a client application in the Azure portal, grant it the access the Office 365 input requires to read the audit log, and confirm the organization's subscription includes audit log access. The docs say E5 and A5 accounts typically have it. The Okta administrator needs to create an API key with rights to read System Log events. Plan how those secrets are stored and rotated, and confirm with the administrators which tenants, orgs and permissions they can approve before the Graylog team starts configuration.
Can one internal engineer set up both inputs alone?
A single experienced Graylog engineer can often configure both inputs, but the work crosses three teams: Graylog operations, Azure administration and Okta administration. The bottleneck is usually getting approvals and access, not the Graylog settings themselves. A solo engineer should confirm access to the Azure portal and Okta admin console early, document the registrations, and agree who owns secret rotation after go-live. DeployOpen plans, implements and documents this work in client infrastructure under a written scope, so a partner can cover gaps in Azure or Okta knowledge if your team lacks capacity.
How do polling intervals and storage volume affect cost?
Polling interval shapes how quickly events arrive and how many API calls the inputs make, while event volume determines how much data Graylog stores and processes. Identity and audit logs can grow steadily across many users, so the storage cost depends on daily ingest and retention. The Graylog architecture guidance advises sizing storage as daily ingest times retention days times 120 percent, and giving the message journal 3 to 5 times daily ingest on SSDs. Estimate your daily volume from a sample export, then ask for a sizing review that covers Enterprise license minimums, storage and any Okta or Microsoft API limits you need to respect.
Which Graylog version should I check before upgrading with these inputs?
Check the Okta input before any upgrade. The Graylog docs say the Okta input does not work in Graylog 7.1.0, 7.1.1 and 7.1.2 because of Okta SDK changes. In Graylog 7.2, the Okta input serializes securityContext.userBehaviors as an array of objects instead of strings, so any custom parsing built on the 7.1 workaround must change. Read the Graylog 7.2 upgrade notes, test parsing rules and dashboards against sample events in a staging cluster, and confirm the target version with Graylog before scheduling the change.
What does ingesting audit logs into Graylog change for security and compliance review?
Centralizing Microsoft 365 and Okta audit trails gives your security team one place to search sign-in, administrative and configuration events alongside other sources. It does not, by itself, satisfy any framework requirement. Retention, access control to the logs, and review evidence depend on how you configure roles, index retention and archiving. Ask your auditor or compliance lead which records they need, and confirm with the vendor and your own policies what Graylog must keep and for how long before you finalize the design.
Where to confirm input behavior and version notes
Before you build either input, confirm its behavior in the Graylog documentation for the exact version you run. The Office 365 input page is the reference for what the client application needs in your Azure portal, which API permissions it must hold, and what subscription your tenant needs for audit log access. Read it alongside your own Microsoft 365 licensing, because the docs note that E5 and A5 accounts typically include audit log access, and your tenant may differ. Treat that page as the source for the permission list, not a copy of it in your runbook.
The Okta Log Events input page settles how the input authenticates with an Okta API key and which Okta System Log events it pulls. The same page records known breakage: the input does not work in Graylog 7.1.0, 7.1.1 and 7.1.2 because of Okta SDK changes. Check that note against your installed release before you schedule a rollout, and confirm the API key scope and token ownership with your Okta administrator.
The Graylog 7.2 upgrade notes cover the parsing change that affects custom Okta logic: the input now serializes securityContext.userBehaviors as an array of objects instead of strings. If you built a parsing workaround on 7.1, plan to revise it as part of the upgrade, and test it against a copy of recent Okta events. Confirm the current documentation version and the upgrade steps for your starting release on the Graylog docs site, since the version you run determines which notes apply.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Graylog. For Microsoft 365 and Okta audit log ingestion, we start by confirming licensing, tenant access and the Graylog version you run, then build and hand over the inputs against that written scope.
How we scope
- Confirm your Graylog edition, since the Office 365 and Okta inputs need an Enterprise license.
- Confirm the Graylog version and check the Okta input version notes before any build starts.
- Agree in writing which tenants, audit log types, polling intervals and destination streams are in scope.
How we build
- Register the Azure client application and confirm audit log access on the subscriptions you hold.
- Create and scope the Okta API key, then configure the Okta Log Events input in your Graylog environment.
- Test polling end to end, check parsed fields and stream routing, and record results against the agreed scope.
How we hand over
- Document app registration, API key ownership, rotation steps and where each secret is stored.
- Provide input configuration, polling settings, stream mappings and an upgrade checklist for your version.
- Walk your operations team through troubleshooting for failed polls and missing audit events.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer.
- Confirm with your team and vendor which support terms and retainer scope apply to your environment.
