Does authentication replace the source address in a policy?

No. A policy with a user group still needs a source address (often the LAN subnet). Both must match: the traffic must come from that address range and from an authenticated member of the group.

Why do users on a shared PC get the wrong access?

Authentication is tracked per IP address. If one person logs off Windows and another logs on, the FortiGate keeps the first user until it learns of the new logon (FSSO) or the session times out. Terminal servers, where many users share one IP, need a dedicated agent.

FortiGate Firewall Authentication: Users, Groups, LDAP, Captive Portal and FSSO | FortiGate Course

A real-life situation

Staff and contractors sit in the same open-plan office on the same LAN subnet. Contractors should reach the Internet but not the finance server in the DMZ. Addresses can't tell them apart: PCs move, and DHCP hands out addresses from one pool. Policies based on who is at the keyboard can.

Users and groups

config user local
    edit "carol"
        set type password
        set passwd <a-strong-password>
    next
end
config user group
    edit "Contractors"
        set member "carol"
    next
end

Local users suit a handful of accounts and labs. Policies can name single users (set users), but referencing groups keeps the rule base manageable.

For real companies, users live in a directory. The FortiGate checks them against it:

config user ldap
    edit "AD"
        set server "10.0.1.5"
        set cnid "sAMAccountName"
        set dn "dc=example,dc=com"
        set type regular
        set username "CN=fgt-bind,OU=Service,DC=example,DC=com"
        set password <bind-password>
    next
end
config user group
    edit "Staff"
        set member "AD"
        config match
            edit 1
                set server-name "AD"
                set group-name "CN=Staff,OU=Groups,DC=example,DC=com"
            next
        end
    next
end

The FortiGate binds to Active Directory with a service account, finds the user by sAMAccountName and checks group membership. Staff contains only AD users who are members of that AD group. Use LDAPS (port 636) in production so passwords aren't sent in clear text.

Using a group in a policy

Simplified illustration of the FortiOS 7.4 GUI · not a screenshot

FGT1Policy & Objects › Firewall Policy

Edit Policy: Staff-to-Finance

Incoming Interface: port2 (LAN)
Outgoing Interface: port3 (DMZ)
Source: LAN-subnet Staff An address and a user group: both must match.
Destination: FIN-SRV
Service: HTTPS
Action: ACCEPT DENY

config firewall policy
    edit 8
        set name "Staff-to-Finance"
        set srcintf "port2"
        set dstintf "port3"
        set srcaddr "LAN-subnet"
        set dstaddr "FIN-SRV"
        set groups "Staff"
        set action accept
        set schedule "always"
        set service "HTTPS"
    next
end

Active authentication: the captive portal

When an unauthenticated user's traffic matches a policy that requires a group, the FortiGate can ask them to log in. For HTTP and HTTPS it redirects the browser to its login page; after a successful login the user's IP address is marked as that user until the authentication times out.

The user's DNS must work before they log in, or the browser never sends the request that triggers the portal. Put a policy allowing DNS without a group above the authenticated policies.
Only some protocols can show a login page (HTTP, HTTPS, FTP, Telnet). Other traffic is simply dropped until the user has logged in some other way.

Passive authentication: FSSO

Asking for a password again after Windows logon annoys users. With FSSO, a collector agent (installed on a server, or agentless polling from the FortiGate) watches domain controller logon events and tells the FortiGate "user alice is on 10.0.1.23, in groups Staff and VPN-Users". Policies then match without any prompt. FSSO groups are selected under config user adgrp and added to user groups of type FSSO.

Who is logged in?

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version

FGT1 # diagnose firewall auth list
10.0.1.23, alice
        type: fsso, id: 0, duration: 1825, idled: 12
        server: AD-collector
        packets: in 3121 out 2988, bytes: in 2810311 out 401227
        group_id: 3
        group_name: Staff

----- 1 listed, 0 filtered ------

Each authenticated IP, the user, how they were identified and their groups. (Example output, trimmed.) In the GUI: Dashboard › Users & Devices (Firewall Users widget).

Why it works this way

A firewall sees packets, and packets carry addresses, not names. Authentication links a name to an address for a while, so policies can use names. Active authentication proves the link with a password; passive authentication borrows the proof from the Windows logon. Either way, the FortiGate still enforces the policy on the IP address.

Common mistakes

No DNS policy without authentication, so the captive portal never appears.
Putting an address-only accept policy above the group policy: it matches first and nobody is asked to log in.
Using plain LDAP (389) over an untrusted network instead of LDAPS.
Expecting user-based policies to work on terminal servers without a terminal server agent.

Key takeaways

✅ Key takeaways

Policies reference user groups; groups hold local users or map to LDAP/RADIUS groups.
A user policy matches address and group together.
Active authentication uses a captive portal; FSSO identifies Windows users passively.
diagnose firewall auth list shows which user the FortiGate links to each IP.

Check yourself

Predict · scenario 1

Users never see the login page when they open a website. A policy requiring group Staff is in place. What is most likely missing?

Predict · scenario 2

What do you need so domain users are recognised without typing a password into the FortiGate?

Predict · scenario 3

A policy has source LAN-subnet and group Staff. A contractor (not in Staff) on 10.0.1.40 logs in on the portal. Does the policy match their traffic?

Users and firewall authentication

What you will learn