FortiAuthenticator DRC Best Practices

Hello sroman1,

it depends on what do you expect from DR to do and how complex it supposed to be.

I would expect fully transparent fallbacks without any noticeable impact for end users.

Most of the authentications you mentioned are client-server stateless things, like RADIUS Access-Request followed by Access-Accept (in OK scenario).

Therefore I do not see any reason to sync any dynamic states on FAC besides the user base, and so related config parts. Dynamic states are caught and maintained as auth sessions on devices like FortiGate. Not on FAC, except some SSO, which was not mentioned as it seems to me.

Therefore I would simply extend existing FAC HA A-P cluster with load balanced slaves.

Those LB slaves are A-A cluster, single units as there is no support to chain A-P cluster to another A-P cluster in FAC.

LB slave sync mainly just user base and related data. More details on what is synced can be seen from FAC config, as it actually shows synced status for each data category, or it is in documentation (admin guide on https://docs.fortinet.com ). Otherwise it is standalone unit. And you can hook up to 10 of those LB slaves to a LB master (which could be standalone unit or A-P cluster {your case}).

So if, for example, your FortiGate's RADIUS server config would use master from HQ FAC cluster as primary server, and LB slave FAC as secondary inside same server config, then you will have automatic redundancy in case none of primary cluster FAC servers is accessible, and fall back to LB slave.

Hey sroman,

if you want to dig into setting up a load-balancing node with your A-P pair as primary, we have a KB for this: https://community.fortinet.com/t5/FortiAuthenticator/Technical-Tip-How-to-configure-FortiAuthenticator-load-balancing/ta-p/190416

Let us know if you have any questions :)