SSL VPN users on a FortiGate can be authenticated with client certificates only, and still checked against LDAP for group membership and enabled status. Or, they can be required to provide a certificate as well as LDAP username and password.
Certificates with the "Smart Card Logon" application policy are on a YubiKey or other smart card & require a PIN with strict attempt limits that lock the card. They are already "something you have" + "something you know" and are considered strong MFA.
User certificates without the "Smart Card Logon" application policy can exist for various other use cases and be stored on laptops and other devices in software. These certs are only worth 1 factor, using one does not prove strong MFA. They chain to the same enterprise root as the smart card certs.
Is there any way to distinguish by application policy, so smart cards can be accepted without the hassle of an LDAP password, without opening it up for weaker-protected certs to be used without MFA?
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hello merica,
Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.
Thanks,
Hello merica,
We are still looking for someone to answer your query and will respond to you as soon as possible.
Thanks,
Hi merica,
for the FortiGate there is no difference of the certificate being on a smart card or not.
The smart card contains minimum the private key of a certificate. The private key is used to identify the holder of the certificate since only the holder can do certificate related actions, signing stuff, decrypting data encrypted against the public key.
Without the private key, the certificate is mostly useless. The smart card is just a certificate storage that provides the private key, completing the certificate when required. If there is no smart card and no private key, the certificate is unusable, and the end user cannot authenticate with it (not even select it).
Obviously the key takeaway for a smart card is that if the computer/laptop is stolen and the password would be known, the additional factor of the certificate would not be stored on the stolen machine as well and would be accessible with the password.
With the certificate's private key on the machine, the password would again become the single factor of breach, compromising the second factor, rendering the second factor a false security.
So if the client authenticates, the client must have the private key and the FortiGate will not see a difference in the certificate stored with private key on the machine or on a smart card. There might be no difference at all in certificates of computer/user store or the smart card, but usually there would be a "smart card logon" key usage extension. As far as I know FortiGate cannot read that specific extension, such that you could match it in a "config user peer" object. Happy to stand corrected, of course.
I think the best course of action would be username+certificate+password for all users here, smart card owners or not. Smart cards like FTK300 would then be preferred.
Best regards,
Markus
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1692 | |
1087 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.