Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Replies 4 replies
  • Subscribers 41 subscribers
  • Views 1179 views
  • Users 0 members are here
Options
Suggested

Sophos Connect Provisioning File Userauthentification error

IT Hoschi

Hello,

we build a Sophos Connect Provisioning File for our XGS 3300 on FW 20MR1. We have the following Problem. If the Users "starts" the provisioning File and Enter his Credentials for log in, he gets an UserAuthentification error - with the Correct Credentials. After checking the SSL-VPN Client we can see that the process worked - the Users has the new .ovpn config after login.

My Problem is that there is always an error displayed and no success information when the new config is downloaded. So our users dont get the Displayed Information that the renewal is done. When they now click on abort/cancel they can connect with the new/latest config. Is there any way that the user gets an information that the config Update was successful?



Added TAGs
[edited by: Erick Jan at 11:08 AM (GMT -7) on 2 Aug 2024]
Parents
  • 0

    In the Logs i find the folowing Entry for the login. Seems like the provisioning Process does 2 Login´s to different Services


  • +1 in reply to IT Hoschi

    Moin!
    We stumbled across this as well. It's actually really straight forward what creates this problem but it's really annoying.

    The client performs two logins in a row and if you don't use OTP it works fine. Without OTP enabled the SCC asks for username and password and uses those to log into the VPN portal to download the configuration. Next it installs the configuration and tries to establish the connection with the cached credentials. So the user is asked for credentials once but there are two authentications happening. Try it with a user without OTP and it just works. I assume this is done for convenience so the user doen't have to log in twice in a row.

    With OTP however it's a mess. The SCC does not know or care if OTP is enabled for a user on the firewall. So you load the provisioning file and enter username and password followed by the OTP code. If these are correct the configuration is downloaded to the SCC and again the SCC tries to connect with the cached credentials but since the cached password is actually password+OTP it's no longer valid as OTP codes can only be used once - even within the timestep.

    Login fails with correct passwords and incorrect OTP codes are handled like logins with incorrect passwords so there is no feedback to the SCC. It's just "wrong username or password". So the only way to solve this problem is to change the behaviour of the SCC regarding provisioning files and this means to ditch the automatic login with cached credentials.

Reply
  • +1 in reply to IT Hoschi

    Moin!
    We stumbled across this as well. It's actually really straight forward what creates this problem but it's really annoying.

    The client performs two logins in a row and if you don't use OTP it works fine. Without OTP enabled the SCC asks for username and password and uses those to log into the VPN portal to download the configuration. Next it installs the configuration and tries to establish the connection with the cached credentials. So the user is asked for credentials once but there are two authentications happening. Try it with a user without OTP and it just works. I assume this is done for convenience so the user doen't have to log in twice in a row.

    With OTP however it's a mess. The SCC does not know or care if OTP is enabled for a user on the firewall. So you load the provisioning file and enter username and password followed by the OTP code. If these are correct the configuration is downloaded to the SCC and again the SCC tries to connect with the cached credentials but since the cached password is actually password+OTP it's no longer valid as OTP codes can only be used once - even within the timestep.

    Login fails with correct passwords and incorrect OTP codes are handled like logins with incorrect passwords so there is no feedback to the SCC. It's just "wrong username or password". So the only way to solve this problem is to change the behaviour of the SCC regarding provisioning files and this means to ditch the automatic login with cached credentials.

Children
  • 0 in reply to Björn Vermöhlen

    Glück auf!

    yes the behavior isn´t nice for the users. We cant´t disable OTP because of security purpose. Now we wrote a User "Walkthrough" how to do and how to check if it was successful. Hopefully there won´t come as much helpdesk calls when the certificate is changed the next time Slight smile.
    For the future i hope there will be a solution that the scc gives the correct feedback or does only the desired task(download config or login vpn).

Unfiltered HTML