Skip to content
Last update: 2021-10-21

Troubleshooting authentication

How to investigate and resolve common authentication issues.

See the troubleshooting topic for the authentication method you use. To troubleshoot authentication, you will typically need access to both Sophos Firewall and the authentication server as well as a client device that is failing authentication.

Thin Client (SATC) users can't sign in

Users of terminal servers such as Citrix must use a thin client (SATC) to sign in. If authentication fails, follow the steps below to troubleshoot the issue.

Condition

Terminal server users are unable to authenticate.

Cause

There can be a number of reasons that users are unable to authenticate. Follow the steps below to check that your systems are configured correctly and correct any issues you find.

Remedy

  1. Sign in to the Sophos Firewall command line interface.
  2. Select option 4. Device Console.
  3. Type the following command:

    system auth thin-client show

    This will list the IP addresses of your terminal servers. Make sure all expected IP addresses are shown.

  4. If the terminal server is not shown in the above steps, add it using the following command:

    system auth thin-client add citrix-ip IPADDRESS

    Replace IPADDRESS with the IP addresses of the server.

  5. On all terminal servers running SATC, open SATC, go to the Sophos Settings tab and verify that the correct IP address is configured for Sophos Firewall under Sophos IP Address. Also, check that the service is running in the Windows task manager.

  6. Check Authentication Server Settings in Sophos Firewall. Go to Authentication > Services and make sure the Active Directory server is selected under Firewall Authentication Methods.
  7. Check if there is any proxy software or security software installed on the server that might change the source port. If there is, Sophos Firewall has a port mismatch and the traffic is treated as unauthenticated.
  8. If you use Internet Explorer, do the following to minimize or disable User Account Control (UAC):

    User Account Control is a security component that allows an administrator to enter credentials during a non-administrator's session to perform administrative tasks.

    1. Log in to your Windows AD server. Click Start, and then click Control Panel.
    2. In Control Panel, click User Accounts.
    3. In the User Accounts window, click User Accounts.
    4. In the User Accounts tasks window, click Turn User Account Control on or off.
    5. Disable Use User Account Control (UAC) to help protect your computer and click OK.
    6. Click Restart Now to apply the change right away. If UAC is currently configured in Admin Approval Mode, the User Account Control message appears. Click Continue.

    If UAC is enabled, it doesn't allow the SATC client to send the traffic to Sophos Firewall. As SATC sends the username over port 6060, users don't appear in the live user list. This happens when the Thin Client user accesses the internet with Internet Explorer.

    SATC LSP registers with Winsock for Sophos Firewall to understand the user traffic. When UAC is enabled, Internet Explorer bypasses the LSP registration.

    Note

    There is no issue with UAC with the Firefox web browser.

  9. If you use Internet Explorer, do the following to disable Enhanced Protected Mode.

    1. Launch Run from Windows Start menu.
    2. In the Run window, type inetcpl.cpl and then click OK.
    3. In the Internet Properties window, click on the Advanced tab.
    4. Scroll down to Security and then turn off Enable Enhanced Protected Mode.
    5. Click Apply and then OK.
  10. If you use Google Chrome, do the following to update Runs network service in-process settings:

    1. Go to chrome://flags.
    2. Search for Runs network service in-process.
    3. Switch the setting to Enabled.

    Users will be able to authenticate via SATC as expected.*

NTLM and Kerberos troubleshooting

Troubleshoot common Kerberos and NTLM issues.

Condition

Client devices fail authentication when Kerberos and NTLM are configured.

Cause

Some common issues for authentication failure are: Configuration errors, domain join failures, and in the case of Kerberos the key version number (KVNO) not matching between endpoints and Sophos Firewall.

Remedy

  1. Go to Authentication > Servers.
  2. Click on your AD server and then click Test connection.

    If the connection fails, you must resolve the AD connectivity issues. If the connection is successful, continue the steps below.

  3. Check a firewall rule is in place to allow Kerberos and NTLM traffic for the affected clients under Rules and policies > Firewall rules.

  4. Go to Administration > Device access and make sure AD SSO is configured for the zone that clients are authenticating from. This will typically be your LAN zone.
  5. If you have configured Sophos Firewall as an explicit proxy, make sure the hostname has been used in the browser settings. If you have used an IP address, the client allows only NTLM authentication.
  6. Sign in to the Sophos Firewall command line interface.
  7. Select option 5. Device Management then option 3. Advanced Shell.
  8. Use the following command to check the nasm service is running: service -S | grep -i "nasm"
  9. If the proxy name doesn't match between the client and Sophos Firewall, make sure the host record in AD for Sophos Firewall matches the hostname configured under: Administration > Admin settings > Hostname.
  10. If the KVNO doesn't match, the user must sign out and back in to their account, or you must rejoin Sophos Firewall to the domain. This issue is normally caused when the hostname of Sophos Firewall is changed.
Endpoint computer can't authenticate via NTLM due to the redirection URL

Condition

When attempting to authenticate via Active Directory SSO using NTLM with the HTTP proxy in transparent mode, the NTLM authentication fails. The browser displays a pop-up asking for credentials or directs users to the captive portal.

Cause

Browsers will only automatically send login credentials (single sign-on) if they're sure that the site requesting them is local. So either the site requesting them must be a bare hostname (without the domain, for example, myfirewall), or the browser must trust the requesting site.

The default configuration is for the Sophos Firewall to redirect the proxy to a URL containing the IP. You must change this to use either a bare hostname or an FQDN.

Remedy

  1. Configure a hostname on Sophos Firewall. Go to Administration > Admin settings > Hostname.
    1. Enter a Hostname. You must use a fully qualified domain name (FQDN) that matches your organization domain. For example, myfirewall.mycompany.com.
  2. Select a certificate that browsers will automatically trust.

    Note

    The self-signed certificate that comes installed on Sophos Firewall doesn't come from a trusted certificate authority and doesn't cover the hostname or FQDN that you've configured. To remove browser warnings about certificates, the certificate must cover the hostname or FQDN that traffic is redirected to.

    1. If you need to install a new certificate that covers the hostname of Sophos Firewall, you can do this under the Certificates menu. For more information, see Install a subordinate certificate authority (CA) for HTTPS inspection.
    2. Under Admin console and end-user interaction > Certificate, select the certificate to use from the drop-down menu.

      The certificate can be one that has been purchased from a public certificate authority and is automatically trusted by all clients. Alternately, it can be a self-signed certificate from an internal certificate authority that the endpoint computers have been configured to trust.

  3. Set the proxy redirection URL.

    1. To use the configured FQDN of Sophos Firewall, go to Administration > Admin settings > Admin console and end-user interaction, and select Use the firewall's configured hostname.
    2. To use a different FQDN or a bare hostname, go to Administration > Admin settings > Admin console and end-user interaction, select Use a different hostname, and enter the hostname you want to use.

      Note

      Make sure the endpoint computer can resolve the Sophos Firewall by the method you select. You may need to add entries to your DNS server.

  4. If you're redirecting using a bare hostname, the browser will see that the requester is local and automatically trust it to perform SSO.

  5. If you're redirecting using an FQDN, configure your browser to trust the FQDN of Sophos Firewall using AD Group Policy. Alternatively, to manually add the FQDN to a browser, follow the steps below.

    Microsoft Edge and Google Chrome

    1. Open the windows control panel.
    2. Go to Internet Options > Security > Local Intranet.
    3. Click Sites, and then Advanced.
    4. Type the FQDN into the field Add this website to the zone and click Add.

    Firefox

    1. Type about:config into the Firefox address bar and press Enter.
    2. Enter the FQDN into network.automatic-ntlm-auth.trusted-uris.
Endpoint computer can't authenticate via Kerberos due to the redirection URL

Condition

When attempting to authenticate via Active Directory SSO using Kerberos with the HTTP proxy in transparent mode, the Kerberos authentication fails. As a result, the browser falls back to using NTLM or the captive portal for authentication.

Cause

Browsers will only automatically perform Kerberos login (single sign-on) if they're sure that the site requesting credentials is part of the Kerberos domain. The requesting site, in this case, Sophos Firewall, must be using a hostname or FQDN for redirection that matches the service principal name (SPN) of the firewall on the Active Directory (AD) server.

Remedy

  1. Configure a hostname on Sophos Firewall. Go to Administration > Admin settings > Hostname.

    Enter a Hostname. You must use a fully qualified domain name (FQDN) that matches your company domain. For example, myfirewall.mycompany.com.

    When the Sophos Firewall joins the AD Domain, it's given an AD computername, and two SPN entries are automatically created.

    • One SPN is created for the bare hostname. This is the first part of the FQDN that you configure in the Admin settings > Hostname field.
    • One SPN is created for the bare hostname, followed by the AD domain. Therefore, if you configure the Sophos Firewall Hostname field to be myfirewall.mycompany.com, and join the AD domain mycompany.local two SPNs are created: myfirewall and myfirewall.mycompany.local.

    Warning

    For many customers, the domain name used in DNS and Active Directory is the same, which means that the DNS FQDN and the Active directory computer name are the same. The automatically created SPN matches the Admin settings > Hostname field. If your DNS and Active Directory use different domain names (such as mycompany.com and mycompany.local), and you want to use the DNS name in redirection, you must manually create the SPN on your AD domain controller.

  2. Set the proxy redirection URL. This can be the configured FQDN, a different FQDN (such as the AD computername), or a bare hostname. Whatever you use must match an SPN.

    1. To use the configured FQDN of Sophos Firewall, go to Administration > Admin settings > Admin console and end-user interaction, and select Use the firewall's configured hostname.
    2. To use a different FQDN or a bare hostname, go to Administration > Admin settings > Admin console and end-user interaction and select Use a different hostname, and enter the hostname you want to use.

      Note

      Make sure the endpoint computer can resolve the Sophos Firewall by the method you select. You may need to add entries to your DNS server.

      When you're redirecting to perform AD SSO, the browser attempts to match an SPN and must trust it to perform Kerberos authentication.

      • If it's a bare hostname, it must match the bare hostname SPN that was created automatically.
      • If it's an AD FQDN, it must match the AD computername FQDN SPN that was created automatically.
      • If it's a DNS FQDN, it must match the DNS SPN that you created manually.
Back to top