Skip to content

[New Package] Add Fortinet Fortiauthenticator package#18502

Open
dot-mike wants to merge 2 commits intoelastic:mainfrom
dot-mike:fortinet_fortiauthenticator
Open

[New Package] Add Fortinet Fortiauthenticator package#18502
dot-mike wants to merge 2 commits intoelastic:mainfrom
dot-mike:fortinet_fortiauthenticator

Conversation

@dot-mike
Copy link
Copy Markdown

@dot-mike dot-mike commented Apr 17, 2026

New integration for collecting syslog from Fortinet FortiAuthenticator instances (8.0.2+). Includes an ingest pipeline handling both RFC3164 and RFC5424 syslog data, four Kibana dashboards covering the main event categories, and pipeline tests using data captured from a real FortiAuthenticator 8.0.2 instance.

It's important that version 8.0.2+ is used, previous version on 8.0.x had a bug with malformed log-messages. And version 7.x may differ from log-id events and or format of the message.

Proposed commit message

This adds a new fortinet_fortiauthenticator integration package with
a single data stream: log.

The log data stream accepts syslog over UDP (default port 9025), TCP,
or filestream. The ingest pipeline parses both RFC3164 and RFC5424
frames, maps each Fortinet log ID to an ECS event.action /
event.category, and populates a structured
fortinet.fortiauthenticator.log.* namespace alongside standard ECS
fields (event.*, user.*, source.*, observer.*, log.level).
Authentication events get additional enrichment for source.ip,
user.name, event.outcome, and MFA method.

Four Kibana dashboards are included: Overview, Authentication, Admin
Configuration Audit, and System and HA.

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.
  • I have verified that any added dashboard complies with Kibana's Dashboard good practices

Author's Checklist

  • [ ]

How to test this PR locally

  1. clone integrations repo.
  2. Install elastic package locally.
  3. Start elastic stack using elastic-package.
  4. Move to integrations/packages/fortinet_fortiauthenticator directory.
  5. Run the following command to run tests: elastic-package test

Screenshots

fortinet-fortiauthenticator-overview fortinet-fortiauthenticator-authentication fortinet-fortiauthenticator-admin-audit fortinet-fortiauthenticator-system

@dot-mike dot-mike requested a review from a team as a code owner April 17, 2026 13:18
@elastic-vault-github-plugin-prod
Copy link
Copy Markdown

Reviewers

Buildkite won't run for external contributors automatically; you need to add a comment:

  • /test : will kick off a build in Buildkite.

NOTE: https://github.com/elastic/integrations/blob/main/.buildkite/pull-requests.json contains all those details.

Comment on lines +107 to +111
- set:
tag: set_outcome_dot1x_success
field: event.outcome
value: success
if: ctx._tmp?.dot1x_outcome == 'successful' && ctx.event?.outcome == null
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Medium ingest_pipeline/pipeline_authentication.yml:107

The grok pattern at line 19 captures _tmp.dot1x_outcome with values partially successful, successful, and failed, but the set_outcome_dot1x_success processor only matches ctx._tmp?.dot1x_outcome == 'successful'. The partially successful value never maps to event.outcome, so 802.1x "partially successful" events silently drop their outcome information when _tmp.dot1x_outcome is removed at line 140.

-      if: ctx._tmp?.dot1x_outcome == 'successful' && ctx.event?.outcome == null
+      if: (ctx._tmp?.dot1x_outcome == 'successful' || ctx._tmp?.dot1x_outcome == 'partially successful') && ctx.event?.outcome == null
🤖 Copy this AI Prompt to have your agent fix this:
In file packages/fortinet_fortiauthenticator/data_stream/log/elasticsearch/ingest_pipeline/pipeline_authentication.yml around lines 107-111:

The grok pattern at line 19 captures `_tmp.dot1x_outcome` with values `partially successful`, `successful`, and `failed`, but the `set_outcome_dot1x_success` processor only matches `ctx._tmp?.dot1x_outcome == 'successful'`. The `partially successful` value never maps to `event.outcome`, so 802.1x "partially successful" events silently drop their outcome information when `_tmp.dot1x_outcome` is removed at line 140.

return (((Map) o).size() == 0);
} else if (o instanceof List) {
((List) o).removeIf(v -> drop(v));
return (((List) o).length == 0);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Critical ingest_pipeline/default.yml:581

The drop function in script_drop_null_empty uses ((List) o).length to check if a List is empty. Painless Lists don't have a .length property — only arrays do. This causes a runtime script error whenever the function encounters any List in the document (e.g., event.category, tags, related.ip), which are populated by earlier append and split processors. The on_failure handler will catch it, but the document is marked pipeline_error and null/empty cleanup is aborted. Change ((List) o).length to ((List) o).size().

🤖 Copy this AI Prompt to have your agent fix this:
In file packages/fortinet_fortiauthenticator/data_stream/log/elasticsearch/ingest_pipeline/default.yml around line 581:

The `drop` function in `script_drop_null_empty` uses `((List) o).length` to check if a List is empty. Painless Lists don't have a `.length` property — only arrays do. This causes a runtime script error whenever the function encounters any List in the document (e.g., `event.category`, `tags`, `related.ip`), which are populated by earlier `append` and `split` processors. The `on_failure` handler will catch it, but the document is marked `pipeline_error` and null/empty cleanup is aborted. Change `((List) o).length` to `((List) o).size()`.

@andrewkroh andrewkroh added New Integration Issue or pull request for creating a new integration package. dashboard Relates to a Kibana dashboard bug, enhancement, or modification. documentation Improvements or additions to documentation. Applied to PRs that modify *.md files. labels Apr 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dashboard Relates to a Kibana dashboard bug, enhancement, or modification. documentation Improvements or additions to documentation. Applied to PRs that modify *.md files. New Integration Issue or pull request for creating a new integration package.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants