FortiGate

Connect a Fortinet FortiGate firewall to Oleria to see who can manage it and who can authenticate through it. Oleria reads the FortiGate’s administrators (local, directory-backed, SAML and FortiCloud single sign-on (SSO)), their admin profiles and VDOM scope, local, guest, and PKI peer users, user groups and the directory groups they reference, REST API administrators and other non-human identities, and activity from the event logs. You connect with a REST API administrator that you create for Oleria. Oleria can also disable, enable, create, and delete local users, change group membership, end a local user’s firewall sessions, and move a REST API administrator onto a no-access profile.

​

What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your FortiGate:

• Administrators - every administrator under System > Administrators, as an account with its admin profile as its role:
  • Local administrators and administrators who authenticate against LDAP, RADIUS, or TACACS+. FortiOS has no disabled state for administrators, so they always show as enabled. Oleria records each one’s trusted hosts, schedule, password expiration, whether a password change is forced, FortiToken serial and status, and profile and VDOM overrides.
  • The email address comes from the administrator’s email setting, or from the name if it’s an email address. FortiOS doesn’t require an email address for administrators, so it’s often empty.
  • Multi-factor authentication (MFA) shows as required when two-factor authentication is on. For a directory-backed administrator without FortiGate two-factor authentication, MFA shows as unavailable, because the directory may enforce it. Directory-backed administrators show SSO as required.
  • Sign-in methods include password, FortiToken (unless the token is locked), FortiToken Cloud, email, or SMS codes, SSH keys, and certificates.
• SSO administrators - SAML SSO administrators, FortiCloud SSO administrators (FortiOS 7.0 and later), and FortiGate Cloud SSO administrators (FortiOS 7.2.4 and later). They show SSO as required and MFA as unavailable, because the identity provider decides MFA.
• Wildcard administrators - an administrator entry that lets every member of a remote group sign in appears as a group named Wildcard administrator <name> (synthesized), with the entry’s admin profile as its role and the referenced user group nested inside it. It doesn’t appear as an account, because it represents many people.
• Central management - when the FortiGate is managed by FortiManager or FortiGate Cloud, a group named FortiManager central management (synthesized) or FortiGate Cloud central management (synthesized) holds the super_admin role. Those services can push configuration with full rights, and their operators aren’t listed as FortiGate administrators.
• Local users - firewall and VPN users under User & Authentication > User Definition, in each VDOM. A local user is enabled or disabled according to its status. Users of type LDAP, RADIUS, TACACS+, or SAML show SSO as required. Oleria records each user’s type and authentication server, and for password users, when the password was last changed.
• Guest users - accounts in guest groups, as external users. A guest is enabled until its expiration date, which is the account’s expiration date. Oleria records the sponsor and company.
• PKI peer users - users under User & Authentication > PKI, who sign in with a certificate, in each VDOM. FortiOS has no disabled state for them, so they always show as enabled. Oleria records each one’s certificate subject and the CA that issued it.
• User groups - every user group in each VDOM, with its local users, guests, and PKI peer users as members. On a FortiGate with more than one VDOM, the group name includes its VDOM. FSSO, RSSO, and SCIM groups are marked as synced from an external source.
• Remote directory groups - when a user group references an LDAP, RADIUS, TACACS+, SAML, or FSSO server, Oleria adds a group for that server, such as LDAP corp-ldap: CN=FW-Admins,OU=Groups,DC=corp, or LDAP corp-ldap: any user when the group accepts every user of the server. It’s nested inside the FortiGate group. FortiGate doesn’t list remote users, so the people come from your directory’s own integration, which you can match by group name.
• Roles - every admin profile, with a description of its permissions, its scope, and whether the FortiAI assistant is enabled. super_admin, prof_admin, and super_admin_readonly are built-in roles; other profiles are custom.
  • Each role assignment carries the VDOMs the holder can manage, plus Global for a profile with global scope.
  • An account is flagged as an administrator when its profile is super_admin or grants Read/Write on any System permission. Other profiles, including read-only ones, aren’t.
  • If a profile is assigned but FortiOS doesn’t return it, the role is still shown, its permissions are listed as unknown, and its holders are flagged as administrators.
• Non-human identities (NHIs):
  • REST API administrators - as machine accounts with API access, their admin profile as their role, and their VDOMs, trusted hosts, schedule, CORS origin, and certificate settings. Each one’s API key appears as a credential scoped to its profile and VDOMs, or with full authority when the profile is super_admin.
  • Administrator SSH keys - each SSH public key on an administrator, named <admin>_sshkey<slot>, with its key type and SHA-256 fingerprint, linked to the administrator.
  • Stored integration secrets - credentials the FortiGate holds to connect to other systems, by kind:
    • LDAP bind passwords (servers with a regular bind only);
    • RADIUS shared secrets and TACACS+ keys;
    • FSSO collector agent passwords;
    • SCIM client secrets (FortiOS 7.6 and later);
    • SDN connector credentials: access keys for AWS and Alibaba Cloud, client secrets for Azure, service account keys for Google Cloud, API tokens for OCI, IBM Cloud, Nutanix, Kubernetes, and SEPM, and passwords for other connector types. Connectors that use the cloud’s metadata identity hold no secret and don’t appear;
    • FortiClient EMS cloud access keys;
    • the Security Fabric group password;
    • LLM server API keys (FortiOS 8.0).
    An SDN connector, SCIM client, or EMS connector that’s disabled shows as disabled. Oleria never reads the secret values, only that the secret exists and which server it’s for. The administrator who created a stored secret is shown as its owner, from the configuration-change events. The Security Fabric group password and Fabric devices have no owner.
  • Security Fabric devices - downstream devices authorized in the Security Fabric with an admin profile on this FortiGate, as service accounts with that profile as their role. A device denied in the Fabric’s trusted list shows as disabled.
• Activity - events from the FortiGate event logs:
  • administrator sign-ins, failed sign-ins, sign-outs, lockouts after failed attempts, and expired passwords;
  • configuration changes, including objects created and deleted, local users disabled and enabled, changes to the admin profile assigned to an administrator, SSO administrator, or REST API administrator, password changes, two-factor authentication changes, REST API key changes, group members added and removed, admin profiles created, changed, and deleted, and password policy and SAML setting changes;
  • firewall user sign-ins and failed sign-ins;
  • SSL VPN sign-ins, sign-outs, and failed sign-ins;
  • REST API requests, when REST API logging is turned on in the FortiGate’s log settings.
  Oleria keeps every other event too, under its FortiOS log ID and description. Events are linked to the administrator, SSO administrator, REST API administrator, local user, or PKI peer user who acted, and configuration changes to the account, group, or role they changed. Events by the REST API administrator this integration uses are Oleria’s own and aren’t imported.

Last activity for administrators, SSO administrators, local users, PKI peer users, and guests comes from their most recent successful sign-in in the event logs, including SSL VPN sign-ins. For REST API administrators, it comes from their most recent REST API request, which also sets when their API key was last used. Creation dates, and who created each account, come from configuration-change events. See Known limitations. Oleria reads activity from one log device. With Log source set to Automatic, it uses the first one available in this order: disk, FortiAnalyzer, FortiGate Cloud, memory. Disk is the fastest. FortiAnalyzer usually keeps the longest history. Oleria refreshes this data on its regular sync schedule.

​

Prerequisites

• A FortiGate running FortiOS 7.2 to 7.6. FortiOS 7.0 and 8.0 are best effort. A FortiGate in FIPS-CC mode isn’t supported, because FortiOS doesn’t accept REST API tokens in that mode.
• A FortiGate administrator with the super_admin profile, to create the REST API administrator. Only a super_admin can create one.
• Network access from Oleria to the FortiGate’s management interface:
  • The interface must be reachable over public HTTPS on port 443, by hostname. The FortiGate’s administrative HTTPS port must be 443 on that interface. IP addresses aren’t supported, and a hostname that resolves to a private or loopback address is refused.
  • Contact support@oleria.com to allowlist the FortiGate’s hostname, and to get Oleria’s egress IP addresses. You add those addresses to the REST API administrator’s trusted hosts.
• A trusted TLS certificate on the management interface. Oleria always verifies it. A publicly trusted certificate, such as one from Let’s Encrypt, works as is. If the interface uses FortiGate’s self-signed certificate or a private CA, export that certificate or its issuing CA certificate in PEM format, for example from System > Certificates.
• Admin access on the Oleria platform to add a new integration.

Each integration connects one FortiGate, or one high-availability (HA) cluster. Oleria identifies a cluster by its lowest member serial number, so a failover keeps the same integration. To connect more FortiGates, add an integration for each. See Multi-instance support.

​

Create a REST API administrator

​

Connect FortiGate to Oleria

If Authenticate fails, the message says what’s wrong:

• FortiOS rejected the token (HTTP 401) - check the REST API token. Oleria doesn’t retry, because repeated failures lock out the source IP address.
• FortiOS denied the request (HTTP 403) - add Oleria’s egress IP addresses to the REST API administrator’s trusted hosts, and check its admin profile.
• the source IP is locked out after failed logins (HTTP 429) - wait for the FortiGate’s lockout to expire, then check the token.
• The REST API administrator cannot read administrator users - give its admin profile Global scope and Administrator Users Read.
• No REST API administrator named … exists - enter the name of the REST API administrator that owns the token.
• has scope vdom - change the admin profile’s scope to Global.
• VDOM … does not exist - check the VDOMs you entered. The message lists the FortiGate’s VDOMs.
• The FortiGate’s TLS certificate is not trusted - install a publicly trusted certificate on the management interface, or paste the FortiGate’s certificate or its issuing CA certificate into Trusted certificate (PEM).
• is not reachable from Oleria - check that the management interface is reachable over public HTTPS on port 443 by hostname, that Oleria support has allowlisted the hostname, and that Oleria’s egress IP addresses are in the REST API administrator’s trusted hosts.
• FortiOS REST API not found (HTTP 404) - check that the FortiGate URL is the management interface’s address.

​

Edit the integration

When you edit the integration, you can change every field except FortiGate URL. To connect a different FortiGate, add a new integration.

• Leave REST API token blank to keep the stored token. To replace it, regenerate the REST API administrator’s API key in FortiGate and enter the new key.
• Clear an optional field to remove its value.

Select Update to save. Oleria runs the same checks as Authenticate. If the FortiGate’s certificate changes, update Trusted certificate (PEM). A pinned FortiGate certificate stops matching when it’s replaced.

​

Verify the integration

Confirm the FortiGate appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, review the discovered administrators, users, groups, roles, NHIs, and activity in your Oleria workspace. In the integration’s Capabilities and operation readiness section, Read users, Read groups, and Read roles show Available. Oleria checks the REST API administrator’s own admin profile for these permissions, and reads a sample of each: If one is missing, the row shows Needs permission.

​

Remediation actions

Oleria can take these actions in FortiGate: Before it offers an action, Oleria checks that the REST API administrator’s admin profile has the permission the action needs: If Oleria can’t read its own admin profile, or the profile lacks the permission, the action isn’t offered. Keep these limits in mind when you use these actions:

• Oleria reads the user, group, or REST API administrator before it makes a change. If it’s already in the requested state, Oleria makes no change, and reverting the action makes no change either.
• After each change, Oleria reads it back to confirm it. If the change isn’t there, the action fails.
• Reverting an action changes only what the action changed. If the user, group, or REST API administrator no longer exists, or someone changed it since, the revert makes no change and says why.

Disable user accounts, Enable user accounts, Revoke user sessions, and Delete user

• These actions apply to local users only. Oleria refuses administrators, SSO administrators, FortiCloud and FortiGate Cloud SSO administrators, and PKI peer users, because they have no disabled state. It refuses REST API administrators: use Disable NHI accounts instead. It refuses guest accounts, because they expire on their own.
• Disable user accounts changes only the user’s status. To end the user’s firewall authentication sessions, run Revoke user sessions. SSL VPN tunnels aren’t ended: disconnect them in FortiGate.
• Revoke user sessions makes no change if the user has no active firewall sessions.
• Delete user first removes the user from every user group in its VDOM, because FortiOS doesn’t delete a user that a group references. If FortiGate then refuses the delete, for example because a firewall policy references the user, the action fails. If Oleria already removed the user from groups, the action partially completes and lists those groups.

Add user to group and Remove user from group

• These actions apply to local users and to user groups in the same VDOM. Oleria refuses a user and group in different VDOMs.
• Oleria refuses the synthesized remote directory, wildcard administrator, and central management groups, which have no members to change, and guest groups, which hold guest accounts instead of members.
• Only direct membership changes. Access through a remote directory server listed in the group isn’t affected.
• If FortiGate doesn’t answer, Oleria reads the membership again. If the change is there, the action succeeds.

Disable NHI accounts

• This action applies to REST API administrators only. Administrator SSH keys, stored integration secrets, and Security Fabric devices can’t be disabled: removing an SSH key edits the administrator, FortiOS has no disabled state for stored secrets, and deauthorizing a Fabric device changes the Fabric topology.
• Oleria refuses the REST API administrator this integration uses, and any REST API administrator with the super_admin profile. Change a super_admin REST API administrator’s profile in FortiGate first.
• Before each change, Oleria checks that the no-access profile exists and that every permission is None. Otherwise it refuses.
• Reverting restores the previous profile only if the REST API administrator still has the no-access profile.
• On FortiOS 7.6.5 and later, Oleria refuses the action. See Create a REST API administrator.

Create user and Create group

• Oleria creates the user or group in the VDOM the request names, or else the first VDOM in the integration’s VDOMs field, or else root.
• The name can be up to 64 characters, with no spaces, quotes, or slashes. If a user or group with the same name already exists in that VDOM, the action fails and changes nothing.
• Create user needs a password, or needs Oleria to generate one. Oleria doesn’t return a generated password, so set the user’s password in FortiGate before they sign in. The user is created disabled unless the request asks for an active user.
• Create user can add the user to groups by group name or Oleria group ID. The groups must be in the same VDOM. If adding the user to a group fails, the action fails but the user still exists. Delete it in FortiGate, or run Delete user on it.
• Oleria sends a create once and doesn’t resend it. If FortiGate doesn’t answer, Oleria checks for the name. If the user or group now exists, the action succeeds.

​

Known limitations

• Administrators can’t be disabled. FortiOS has no disabled state for administrators, SSO administrators, or REST API administrators, so they always show as enabled, and Oleria can’t disable or enable them, or add them to or remove them from roles. Workflows that disable dormant accounts work on local users only.
• Last activity depends on log retention. FortiOS 7.x doesn’t store a last sign-in time. Oleria uses sign-in events from the last 98 days of the event logs, so last activity goes back at most 98 days, or less if the log device keeps fewer. Creation dates and creators go back only as far as the log device keeps configuration-change events. Memory logs keep the least. Oleria reads a limited number of events in each VDOM, so on a busy FortiGate a last-activity date may be up to two weeks older than the latest sign-in, and older creation dates may be missing. Last activity for REST API administrators needs REST API logging.
• 30 days of activity. When you connect, Oleria reads up to the last 30 days of events. Each sync leaves out the most recent five minutes, which the next sync reads, because FortiAnalyzer indexes events with a delay.
• REST API activity needs logging. REST API requests appear only when REST API logging is turned on in the FortiGate’s log settings. REST API events include an IP address only when FortiOS records one in the event.
• Remote users have no account. FortiGate doesn’t list users who authenticate against LDAP, RADIUS, TACACS+, SAML, or FSSO, so they appear only through the remote directory groups, and their events have no actor. Their sign-in name is kept with the event.
• Admin email and password dates. Administrators often have no email address. An administrator’s last password change is calculated from their password expiration and the admin password policy’s expiry period, so it’s available only when the policy has password expiry turned on, and not for directory-backed administrators. Password changes and resets look the same in activity.
• Dates are read as UTC. FortiOS doesn’t report its time zone, so dates such as password expiration and guest expiration are read as UTC.
• No resources. Firewall policies, addresses, VPN tunnels, interfaces, and VDOMs aren’t inventoried. VDOMs appear only as the scope of role assignments and as the container of users and groups.
• Not inventoried. FortiTokens appear only in MFA details. SNMP users and communities, automation identities, and certificates aren’t discovered.
• No AI agents. FortiOS has no AI agent catalog. In FortiOS 8.0, FortiAI acts as the signed-in administrator, so no AI agents appear.
• Public management interface. Oleria connects only to a management interface it can reach over public HTTPS on port 443 by hostname. A FortiGate whose management interface is private can’t be connected.

​

Contact us

For questions about this integration, contact us at support@oleria.com.