credential or ssl vpn configuration is wrong (-7200) with Duo

Question

I've got a user who has had access to Forticlient (FC) for several months. We use Duo for our 2FA and he's been using it without issue until last night. We verified the user's domain account and password are not expired but we went ahead and reset it, just to be sure it wasn't some kind of glitch. This did not impact the error. The user is able to use Duo to login to other systems without issue so the hardware token appears to be working as expected in those situations.

As part of testing, I had the user attempt to login to FC on my computer, as I use it many times a week and had logged in this morning. This was an attempt to verify that there wasn't an issue with the installation of the software on his computer. The user got the same error on my computer. I subsequently logged into the VPN under his user profile using my credentials successfully. Therefore, I'm certain the issue is not with the software.

We have seemingly ruled out the user's Active Directory Account, Duo Account, and the software installation. As such, I'm at a loss for what the issue might be going forward. I've searched this forum along with other support repositories and I've not been able to find this specific issue described. And other instances of this specific error have multiple different solutions but they usually appear to be more widespread than a single user.

Has anyone else ran into this issue and found a solution?

Thank you!

Dozer

pminarik · Answer

I understand that you're using LDAP protocol for this authentication, is that right?

In that case, you can try to rule out SSL-VPN interference by running a test-authentication directly in the FortiGate's CLI:

diag test auth ldap <server-name> <username> <password>
Replace <server-name> with the name of the LDAP object in "config user ldap". Note that the password isn't obfuscated in any way when typing it on the command line.

If that fails as well, you know the SSL-VPN isn't involved in this failure, and for further troubleshooting you can run debug of fnbamd:

diag debug reset

diag debug console timestamp enable

diag debug app fnbamd -1

diag debug enable

#==> repeat the test

diag debug disable

You can then review the debugs, or ask for assistance here or in a TAC ticket (if the info in the debugs are too sensitive for you to share and you don't feel like redacting the values carefully).

You can also combine the debugs with a packet capture of the LDAP traffic, althogh this tends to be useful only if you're using plaintext, unencrypted, LDAP. (ports 389 or 3268 for plaintext, 636 or 3269 for encrypted LDAPS).

Sign up

Login with SSO

Login to the community

Login with SSO