FortiToken in a-p HA environment

[Toshi_Esumi]

Does anybody know if anything has just changed on FTNT side in case FortiToken/FortiToken Mobile is deployed on FGTs in a-p environment?

We've been deploying FortiToken Mobile to multiple customers with our a-p HA FGT environment for at least last 5 years or so. When we get a new licenses for 10, 20, 100 tokens we just activated it at the primary FGT without registering it to any one of FGT at the support site. It had been working fine until recently when a customer couldn't assign an available tokens to any SSL VPN users because it errors out. With a TAC ticket we found those licenses were registered to the secondary unit somehow. So we had to get them moved to the primary unit by CS and removed "Error" tokens and reapplied the activation-key to recover them.

However, we never registered them at the secondary unit, or even at the primary, as I said above and we haven't seen those licenses at the asset page before. Now the biggest problem is when a-p swapover happens, we have to get all of them moved to the new primary in a hurry. Is this the intended new token operation in HA?

Obviously doubling token licenses and registering at all secondary units would not work because those would have different token numbers from the primaries'.

This would half-kill the purpose/benefit of a-p HA and everybody who use a-p HA, regardless how small the units are, and tokens would be forced to deploy ForetiAuthenticator. So I'm hoping this is some kind of error happened at FortiGuard, which does the license/token validation, and soon go back to previous state.

Toshi

[Debbie_FTNT]

Hey Toshi,

FortiGate speaks to FortiGuard twice for mobile tokens - once when activating the licence (at which time the licence, if not already done, will also be registered to a specific FortiGate) and a second time when assigning a token.

There can sometimes be issues with clusters under the following circumstances:
- the licence is activated while unit1 is in charge (token licence will be registered with unit1 S/N in our system)

- a failover occurs, and unit2 is in charge

- tokens are assigned to users

-> this requires communication with FortiGuard again, but the FortiGate doing the communication (unit2) is NOT the FortiGate the licence is technically registered to (unit1)

Any tokens already assigned to a user are completely unaffected by failover; either unit can verify a token code just fine. It is the licence activation and assigning a token to a user that can be a bit finicky if a cluster failed over for whatever reason.

As long as the same unit is in charge while the token licence is registered and tokens are assigned, you shouldn't encounter any issues whatsoever.

You also should not have been required to move the tokens to the other serial number; a simple failover should have been sufficient to assign the tokens to the users.

[apatadia_FTNT]

What if the FortiGate unit which registered the Tokens gets RMAed, will the new FortiGate unit not be able to issue tokens ?

[Update] Never Mind I got the Answer https://community.fortinet.com/t5/FortiGate/Technical-Tip-FortiToken-register-and-provision-process-...

[Toshi_Esumi]

The main issue with this operation is not how to transfer the tokens to the new unit. But all users, regardless just one or hundreds of them, have to re-activate the new token after the swap was done. 

It's extreamely painful in case the unit is >1000D/1100E, which accomodate more than/closer to a hundred of customers with VDOMs with hundreds of SSL VPN users.

Toshi

[Toshi_Esumi]

Even with session sync, some things sometimes would drop for short time period when switchover happens. We definitely don't want to do that in day time ONLY because the token licenses are registered on the current secondary unit.

FTNT should have designed in a better way sharing the license ownership among HA units when it's activated like certificates.

But I know yelling out loud in this community wouldn't change anything what/how FTNT develop the features like FortiToken. So I'll take your explanation as is and try our best not for our customers to get suffered because of this design when switchovers happen.
Besides, we're getting FortiAuthenticator at least for ourselves now (somehow got stuck inbetween TD-SYNNEX and FTNT at this moment). So we'll consider migrating existing customer's tokens to the FAC. Only concern is the downtime for the current VPN services when/after CS group moves licenses, which happens only day time unpredictably, before we can finish configuring them at the FAC.

Thanks Debbie anyway for explaining it.

Toshi