Früher oder später kommt man an den Punkt wo man seine User zentral Administrieren will. Und so z.B. seine Admin-User in einem Radiusserver hinterlegt.

Für Fortigates sind die Eintragungen einfach:
Im Radiusserver hinterlegt man nur das für Fortigate gültige admin-profil (hier in /etc/freeradius/users):

"fortiadmin" Cleartext-Password:= "fortiadmin"
        User-Service-Type = Login-User,
        Fortinet-Access-Profile = super_admin
"fortiread" Cleartext-Password:= "fortiread"
        User-Service-Type = Login-User,
        Fortinet-Access-Profile = read_only

Jetzt muss man der Fortigate Konfigurationen vornehmen
Als erstes legen wir ein “read_only” Profile an und eins was garnichts darf (“noaccess”), das ist für gültige User, die keine Fortigate VSAs haben.

config system accprofile
    edit "read_only"
        set admingrp read
        set authgrp read
        set endpoint-control-grp read
        set fwgrp read
        set loggrp read
        unset menu-file
        set mntgrp read
        set netgrp read
        set routegrp read
        set sysgrp read
        set updategrp read
        set utmgrp custom
        set vpngrp read
            config utmgrp-permission
                set antivirus read
                set application-control read
                set data-loss-prevention read
                set ips read
                set spamfilter read
                set webfilter read
            end
    next
    edit "noaccess"
        unset menu-file
    next
end

Wir konfigurieren einen Radiusserver (172.16.1.32) mit PSK 12345678

config user radius
    edit "freeradius"
        set all-usergroup enable
        set auth-type chap
        set nas-ip 172.16.1.2
        set secret 12345678
        set server "172.16.1.32"
    next
end

Dann legen wir eine User Gruppe an die den Server abfragt:

config user group
    edit "radadmin"
    set member "freeradius"         
    next
end

Und ordnen nun eine “Wildcardadmingruppe” dieser Usergroup zu. Diese heißt hier “wildcard”

config system admin
    edit "wildcard"
        set remote-auth enable
        set accprofile "noaccess"
        set vdom "root"
        set wildcard enable
        set remote-group "radadmin"
        set radius-accprofile-override enable
        set radius-vdom-override enable
    next
end 

Jeder user (“wildcard enable”) wird gegen Radius geprüft hat aber standardmäßig “noaccess” als accprofile. Das verhindert das ein beliebiger gültiger Radiususer irgendwas auf der Fortigate darf.

Dieses accprofil kann (und muss) dann vom Radius überschrieben werden. Ebenso könnte man die vdom auf die ein User Zugriff hat spezifizieren. – Das wird hier aber nicht gemacht.

Lokale User werden lokal an der Fortigate verifiziert, alle anderen dank Wildcard im Radius nachgeschlagen.

Um bei einer Fortigate die 2. Firmware zu booten machte man folgendes:
diagnose sys flash list
Hier sieht man was in Partition 1 (primary) bzw 2 (Secondary) steht.
Um z.B. beim nächsten reboot aus der primary zu starten gibt man
execute set-next-reboot primary
ein.

Möchte man bei einer Fortigate zweit WAN Zugänge oder ISPs anschliessen, z.B. für Backup oder Lastverteilung kommt man zu dem Punkt: Wie geht das?

Szenario:
Einen Provider am WAN1 (schnelle Leitung)
zweiten Provider am WAN2 (langsamere Verbindung)

Wie kann man vorgehen?
Legt man zwei default Routen mit unterschiedlichen Metriken an ist nur die mit der besseren Metrik in der Routingtabelle, d.h. es wird nur die bessere Route genutzt, Verbindungen über die andere Leitung schlägt fehl (RPF wird das wohl verhindern).

Also trägt man zwei default Routen mit gleicher Metrik an!
Jetzt macht die Fortigate standardmäßig ECMP – also Lastverteilung. Beide Leitungen werden genutzt. Leider schert sich die Fortigate nicht um die Bandbreite (ggf kann man da in den aktuellen Versionen mit weightend ECMP was drehen), wird also recht fix die langsamere Leitung überlasten.

Die Lösung: Prioritäten für Routen. Das ist ähnlich wie Metriken, verhindert aber nicht das die Route aus der Routing Tabelle verschwindet. Sind zwei Routen zum Ziel da wird die mit der niedrigeren Priorität gewählt. bei gleicher Prio greift wieder ECMP.
Dadurch die Route in der Routing Tabelle vorhanden ist kann man Sessions über beide WAN Verbindungen aufbauen und mittel Policy Routing auch einzelnen Traffic über eine WAN Strecke forcieren (z.B. http Traffic über die langsamere Verbindung).

Die Prioritäten kann man nur über die CLI einrichten.
Beispiel:

config router static
show

Die entsprechenden Einträge anpassen
edit 1
" set device ""wan1"""
set gateway 192.168.1.100
set priority 1
next
edit 2
" set device ""wan2"""
set priority 5
set gateway 172.16.31.254
next
In diesem Fall würde der Traffic defaultmäßig über WAN1 gehen (niedrigere Priorität), aber eingehender Verkehr über WAN2 wird erlaubt. Fällt WAN1 weg geht der Verkehr über WAN2.

Natürlich muss man sich noch um passende VIPs/ACLs an den entsprechenden Interfaces kümmern und auch DNS im Hinterkopf behalten.

Die ASA von Cisco hat sowas meines Wissens nicht, es gibt immer nur eine aktive Defaultroute Loadbalancing kann sie nicht. Ein Failover kann man ggf mit SLAs.