Managing multiple customer FortiGates and MFA for login

[das998]

I am trying to come up with a solution that will allow us to manage hundreds of customers FGs MFA.

We currently manage 100's of customers firewalls and we want to start offering MFA for the users. I looked into FortiAuthenticator, but I don't want to hook into every customers LDAP setup. Is there another way to accomplish MFA without FortiAuthenticator, or needing to connect back to each customers directory service? I would prefer a Fortinet product/solution. But I am open to other suggestions as well, such as DUO.

Thanks

[Markus_M]

Hello das998,

the solution will come from how the implementation is to be done.

Understand that the second factor has to be either:

1) inserted into a successful authentication

2) is requested by the backend that is authenticating the user.

The flow is

- user trying to authenticate to an authenticator like a FortiGate.

- authenticator is asking a userDB.

- userDB returns OK and the authenticator returns the same to the end user.

The userDB can be on the same device (FortiGate) or on a remote device (FortiAuthenticator via RADIUS) or even behind the remote device (FortiGate to FortiAuthenticator via RADIUS, FortiAuthenticator to Active directory via LDAP).

One node is always asking one other node, but does not care what is behind it, only what the direct response is.

With this, you can design the second factor.

Either host it respectively on each FortiGate as per 1) insert it to the authentication, when FortiGate got its "OK" from its userDB or backend. This will of course be limited to a userDB on a single FortiGate with one Token per device. You will not have the same Token available for multiple FortiGates.

Or host the second factor on the userDB/backend of multiple FortiGates. Then the second factor/Token can be the same for each user on multiple devices.

A FortiAuthenticator will allow you do host a user DB and have the tokens stored per user with a per-user association. Important to be considered is when designing this is that the FAC will initially not know which backend to ask, unless you only have one backend, like local, or only one LDAP server. You may need to set up criterion to define this, like a user has to log in with its UPN as user@forti.lab, so the FortiAuthenticator knows "forti.lab" is the LDAP server/backend it has to ask.

A user can exist on multiple servers, or on none at all. For this case it is also important to make known to which server the authenticator and FortiAuthenticator will have to ask.

Best regards,

Markus

[Toshi_Esumi]

You kind of have to deal with each customer's LDAP set up. Many, if not most, customers have Windows AD for user authentication and they don't want to have dupulicate user DBs to maintain, or hand it off or migrate it to outside of the org.

FortiAuthenticator(FAC) itself doesn't have structure to have multiple orgs in local DB, no VDOM or no ADOM. Group definition might do something in a sense of separation but I abandoned it for some reasons, which I don't remember.

So practically only way to separate users by org in a FAC is to have separate remote authenticators per org then the FAC would ask user auth to them based on "realm" setting. With this way, even when two different companies have the same user name "JSmith" or "John.Smith", they can be treated as two different users since the remote auth request goes out to two different LDAP servers, or whatever the server is.

This isn't much different from each FGT connects to customer's LDAP/WinAD directly. Which has benefit not to have to come through FAC then go back. I would try this way if I were to manage 100s of them.

Toshi