> ## Documentation Index > Fetch the complete documentation index at: https://docs.oleria.com/llms.txt > Use this file to discover all available pages before exploring further. # FortiGate > Connect a FortiGate firewall to Oleria to bring its administrators, admin profiles, local and guest users, user groups, REST API administrators, stored integration secrets, and event-log activity into your identity graph. 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 \ (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 `_sshkey`, 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](#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](/integrations/overview.md#sync-model). > [!NOTE] > > This integration covers the FortiGate's management access, users, groups, roles, NHIs, and activity. Firewall policies, addresses, VPN tunnels, interfaces, and VDOMs aren't inventoried as resources, so Oleria doesn't populate resource-level Access Graph or Access Inventory data for FortiGate. ## 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](mailto: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](/integrations/overview.md#multi-instance-support). ## Create a REST API administrator **1. Create an admin profile for Oleria** In FortiGate, go to **System** > **Admin Profiles** and create a custom profile with **Scope** set to **Global**. Set these permissions, and set every other permission to **None**: | Permission | Setting | Used for | | :- | :- | :- | | System | **Custom**: **Administrator Users** Read, **Configuration** Read, other System permissions None | Administrators, SSO administrators, REST API administrators, and admin profiles. Oleria also reads its own REST API administrator's profile to check its permissions. Configuration covers system settings, VDOMs, HA, the admin password policy, SAML, and central management. Required to connect. | | User & Device | **Read** | Local users, guests, PKI peer users, user groups, FortiTokens, and the LDAP, RADIUS, TACACS+, SAML, FSSO, and SCIM settings. | | Log & Report | **Custom**: **Configuration** Read, **Data Access** Read | Choosing the log device and reading event logs for activity, last activity, and creation dates. | | Security Fabric | **Read** | SDN connectors, EMS connectors, the Security Fabric group password, and Fabric devices. | Only **System** is required. Without **User & Device**, **Log & Report**, or **Security Fabric**, Oleria still connects, but doesn't read the data in that row. To use [remediation actions](#remediation-actions), set **User & Device** to **Read/Write**. > [!WARNING] > > Don't use the **super\_admin** profile. A profile with **Scope** set to **VDOM** can't read administrators, which are global, so Oleria refuses it when you connect. **2. Optional: create a no-access profile** The **Disable NHI accounts** action moves a REST API administrator onto an admin profile you create. To use it, create a second admin profile with every permission set to **None**, and set **Administrator Users** to **Read/Write** in Oleria's profile. > [!NOTE] > > FortiOS 7.6.5 and later require an administrator password to change a REST API administrator, which a REST API token can't provide. On those versions, Oleria refuses **Disable NHI accounts** before it changes anything. **3. Create the REST API administrator** Go to **System** > **Administrators**, select **Create New** > **REST API Admin**, and: 1. Enter a name, such as `oleria`. 2. Select the admin profile you created for Oleria. 3. Leave all VDOMs selected. 4. Under **Trusted Hosts**, add Oleria's egress IP addresses. Select **OK**, and copy the API key. FortiGate shows it only once. ## Connect FortiGate to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations** -> select **FortiGate**. **2. Complete the connection form** Provide the following: | Field | Notes | | :- | :- | | FortiGate URL | Required. The HTTPS address of the management interface, by hostname, without a path, for example `https://fortigate.example.com`. It must use port 443. It can't be changed after you create the integration. | | REST API token | Required. The API key of the REST API administrator you created. | | REST API administrator name | Required. The name of that REST API administrator. FortiOS can't report which administrator a token belongs to, so Oleria uses the name to recognize its own account and activity, and to refuse actions on it. | | VDOMs | Optional. A comma-separated list of VDOMs, such as `root, branch`. Oleria reads local users, guests, groups, per-VDOM integration secrets, FortiToken statuses, and activity only from these VDOMs. Administrators, REST API administrators, and admin profiles are always read in full. Last activity, creation dates, and creators come from the event logs of these VDOMs only. Include the management VDOM (usually `root`), or administrators and REST API administrators show no activity, creation dates, or creators, and administrators' FortiToken statuses may be missing. Leave blank to read all VDOMs. | | Trusted certificate (PEM) | Optional. Paste one certificate in PEM format. If it's a CA certificate, Oleria trusts certificates it issued and checks the hostname. If it's the FortiGate's own certificate, Oleria accepts only that exact certificate, while it's valid, and doesn't check the hostname. Leave blank if the interface uses a publicly trusted certificate. | | Log source | Optional. Where Oleria reads activity from: **Automatic** (the default), **Disk**, **FortiAnalyzer**, **FortiGate Cloud**, or **Memory**. | | No-access admin profile | Optional. The name of the admin profile with every permission set to **None**. Required for **Disable NHI accounts**. | **3. Confirm the connection** Select **Authenticate**. Before it saves anything, Oleria: * reads the FortiGate's status with the token. If FortiOS rejects the token, Oleria doesn't try again, because FortiOS locks out an IP address after repeated failed sign-ins; * finds the REST API administrator you named, and checks that its admin profile has **Global** scope; * reads the system settings and the VDOM list, and checks that every VDOM you entered exists. If the no-access profile you named doesn't exist or grants any permission, the connection is still saved, and **Disable NHI accounts** refuses to run. Find the newly connected FortiGate on the **Connected** tab of your Oleria **Integrations** page. It's named **FortiGate** followed by the FortiGate's hostname. 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: | Row | Permissions | | :- | :- | | Read users | **Administrator Users** Read, **User & Device** Read, and **Global** scope | | Read groups | **User & Device** Read | | Read roles | **Administrator Users** Read and **Global** scope | If one is missing, the row shows **Needs permission**. ## Remediation actions Oleria can take these actions in FortiGate: | Action | What it does | Revert | | :- | :- | :- | | Disable user accounts | Sets a local user's status to disabled. | Supported - enables the user again. | | Enable user accounts | Sets a local user's status to enabled. | Supported - disables the user again. | | Add user to group | Adds a local user to a user group as a direct member. | Supported - removes the user from the group. | | Remove user from group | Removes a local user who's a direct member of a user group. | Supported - adds the user back to the group. | | Revoke user sessions | Ends a local user's firewall authentication sessions in its VDOM. SSL VPN tunnels aren't ended: disconnect them in FortiGate. | Not supported - the user signs in again. | | Disable NHI accounts | Moves a REST API administrator onto your no-access admin profile, so its API key can no longer do anything. Other NHIs can't be disabled. | Supported - restores the REST API administrator's previous profile. | | Create user | Creates a local user with a password, with the username, email address, and password you provide or a password Oleria generates, and can add it to groups. | Supported - deletes the user the action created. | | Delete user | Removes a local user from its user groups, then deletes it. | Not supported - the user's password, FortiToken, and group memberships are lost. | | Create group | Creates a firewall user group with the name you provide. | Supported - deletes the group the action created. | > [!NOTE] > > The **Remediations** page offers **Revert** only for **Disable user accounts** and **Remove user from group**. The integration supports the other reverts in this table, but the Remediations page doesn't offer them yet. Oleria can revert only an action that completed or partially completed, never one that failed. Before it offers an action, Oleria checks that the REST API administrator's admin profile has the permission the action needs: | Action | Permission | | :- | :- | | All actions except Disable NHI accounts | **User & Device** Read/Write | | Disable NHI accounts | **Administrator Users** Read/Write, and **No-access admin profile** filled in on the integration | If Oleria can't read its own admin profile, or the profile lacks the permission, the action isn't offered. > [!WARNING] > > Administrators can't be disabled, enabled, or moved between groups or roles. FortiOS has no disabled state for administrators. To remove an administrator's access, change or delete the administrator in FortiGate. 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-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](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.