Client VPN using AnyConnect no pre-shared key needed

[Shinomen]

I recently setup our Meraki to allow users to do VPN connections from outside the office using the AnyConnect software.  I have it authenticating against the AD domain controller for the connection.  What I realized is that there is NO pre shared key that needs to be input on the client side in order to make the connection.

I'm used to VPN connections where you have to provide the host, pre-shared key, username, and password to connect.  I'm feeling a little vulnerable like a bad actor could try and use brute force to get into the vpn client. I know I could setup user lockout in AD but again, I feel like there should be that extra layer (pre-shared secret) to prevent just anyone on beating up on the system.

I know I could do 2FA with Duo as well which we might implement, but for now is there a way to do a pre-shared secret instead of just allowing the connection by providing only the username and password?

Maybe I'm overthinking it but again, it just seems less secure than my previous implementations of VPN where a pre-shared secret was needed.

[PhilipDAth]

99% of the deployments I do these days authenticate against Entra ID, and use the built in MFA.

https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance/AnyConnect_Azure_AD_SA...

You could also setup Microsoft Certificate server, deploy a certificate to every machine, and only allow machines with a username+password+certificate to connect.

https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance/Authentication#Certifi...

[AlexP]

If you don't want to, or can't implemented pushed MFA, another option is to enable certificate authentication as a second factor (or indeed third factor since it works with pushed MFA as well).

To do that, you'd need a local Certificate Authority (which your Domain Controller can serve as), then generate a self-signed root cert, which you'd upload to the MX. It doesn't need to be from a commercial or otherwise publicly trusted, so long as you trust your own organization to serve as a secure root for a chain of trust.

From there, you can then just start using that CA to sign certs, and install those onto your client hardware to serve as a means of authenticating your client devices to the MX. It's a bit more work, but I would also highly suggest you find a way to provide certs with unique Subjects/SANs to each of your client devices, that way you're not having to reissue a new one any time you need to terminate someone's VPN access.