Skip to content

Setting Up Fortigate for Access Control Integration

EDAMAME Dev Local edited this page Jul 27, 2026 · 2 revisions

Overview

This guide provides step-by-step instructions to configure a Fortinet FortiGate appliance for use with the EDAMAME access control system. It covers creating the REST API administrator EDAMAME authenticates as, creating the address group EDAMAME maintains, and referencing that group from a firewall policy.

FortiGate differs from the other integrations in one important way: it identifies devices by MAC address, not by IP. EDAMAME keeps a FortiGate address group in sync with the set of devices that currently satisfy your policy, and your own firewall rules decide what membership of that group grants. EDAMAME only maintains the group — enforcement stays in FortiGate.

Prerequisites

Before proceeding, ensure that you meet the following requirements:

  • FortiGate appliance running FortiOS 6.4 or later, with an administrator account that can create REST API administrators and firewall objects.
  • Management interface reachable from EDAMAME. The EDAMAME backend calls the FortiGate REST API directly, so the management interface must be reachable from the internet, or exposed through whatever ingress path your network uses.
  • Devices on a Layer 2 segment the FortiGate sees. MAC address objects only match when the FortiGate observes the device's MAC directly — that is, on a directly attached interface or VLAN. Devices behind another router present that router's MAC and will not match.

Step 1: Create a REST API Administrator

EDAMAME authenticates with an API token belonging to a dedicated REST API administrator, rather than with a person's credentials.

  1. In the FortiGate UI, go to System > Admin Profiles and create a profile for EDAMAME. Grant read-write access to Firewall (address and address-group objects) and leave everything else at None. EDAMAME writes nothing outside firewall address objects, so a narrower profile is safer and works identically.
  2. Go to System > Administrators and click Create New > REST API Admin.
  3. Set:
    • Username — for example edamame
    • Administrator profile — the profile from step 1
    • PKI Group — disabled
    • Trusted Hosts — restrict to the addresses EDAMAME calls from if your policy requires it, otherwise leave permissive
  4. Save. FortiGate displays the API key exactly once. Copy it and store it securely — you will need it in Step 4, and it cannot be retrieved later.

Step 2: Create the Address Group

  1. Go to Policy & Objects > Addresses.
  2. Click Create New > Address Group.
  3. Give it a name — for example edamame-compliant. Note this name down; it is the Group Name you enter in Step 4.
  4. Leave the members list empty. EDAMAME populates it.
  5. Save.

The group starts empty, which means it matches nothing until the first compliant device reports in. Keep that in mind when writing the policy in Step 3: a rule that allows traffic from the group fails closed, whereas a rule that denies traffic from everything except the group would block all devices until the group fills.


Step 3: Reference the Group From a Firewall Policy

EDAMAME never edits your firewall policies — it only maintains the group's membership. Create or edit a policy that uses the group as its criterion:

  1. Go to Policy & Objects > Firewall Policy.
  2. Create or edit the policy that should apply to compliant devices.
  3. Set Source to the address group from Step 2.
  4. Configure the action and destinations according to your own access requirements.
  5. Save.

From this point on, a device joining the group gains whatever this policy grants, and a device leaving it loses that access, with no further manual steps.


Step 4: Configure the Integration in EDAMAME Hub

  1. Visit EDAMAME Hub.

  2. Select your domain.

  3. Navigate to the Access Control section.

  4. Open the Integrations tab.

  5. Select the Conditional Access tab.

  6. Click Add Conditional Access.

  7. Choose Fortigate as the provider and enter the following details:

    • Fortigate URL — the management host, without a scheme and without a trailing path. Enter firewall.example.com or firewall.example.com:8443, not https://firewall.example.com/.
    • Access Token — the API key from Step 1
    • Group Name — the address group name from Step 2
  8. Click Create Integration.

  9. If the credentials are correct, the integration will be successfully established.


How It Works

Once the integration exists, EDAMAME maintains the address group as device compliance changes:

  1. A device satisfies your EDAMAME policy.
  2. EDAMAME creates a FortiGate MAC address object for it, named after the device's EDAMAME identifier, holding that device's MAC address.
  3. EDAMAME rewrites the address group's member list to the full set of currently compliant devices.

Step 3 is a whole-list replacement, not an incremental add. Every compliance change pushes the complete membership. That has a practical consequence: any member you add to this group by hand will be removed on the next update. If you need to allow a device permanently, use a separate address group and a separate policy rule rather than editing this one.


Troubleshooting

The integration was created but the group never fills. Confirm the REST API administrator's profile grants read-write on Firewall objects, and that its Trusted Hosts setting does not exclude the addresses EDAMAME calls from. A permissions failure surfaces as a group that stays empty.

A device is compliant in EDAMAME but its traffic is not matched. Check that the FortiGate sees the device's own MAC. If the device is on a segment reached through another router, the FortiGate sees the router's MAC and the address object cannot match. This is a property of MAC-based address objects, not of the integration.

A device I added to the group by hand disappeared. Expected — see How It Works above. Use a separate group for manual entries.

The appliance uses a self-signed certificate. This is supported: the FortiGate configuration accepts the appliance's certificate without validating it, because management interfaces commonly serve a self-signed certificate. No action is needed on your side.

Clone this wiki locally