Troubleshooting authentication

Users of terminal servers such as Citrix must use a thin client 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 many 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 command lists the IP addresses of your terminal servers. Make sure you see all expected IP addresses.

4. If you don't see the terminal server in the previous step, add it using the following command:

   system auth thin-client add citrix-ip IPADDRESS

   Replace IPADDRESS with the IP addresses of the server.

5. Check Authentication Server Settings in Sophos Firewall. Go to Authentication > Services and make sure the Active Directory server is selected under Firewall Authentication Methods.

6. Check that your terminal server is configured to send SATC events to Sophos Firewall. See Set up SATC on a Windows server through the registry.
7. Check if any proxy or security software is installed on the server that might change the source port. If there is, Sophos Firewall has a port mismatch and treats the traffic as unauthenticated.

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.

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.

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.

Condition

An endpoint device's name is shown as the username in Live users.

Cause

Endpoint devices making operating system web requests when a user isn't signed in, such as Windows Update, may send the endpoint device's name in the SSO credentials rather than a username.

Remedy

Have a user sign in to the endpoint device.

Condition

Users are redirected to the captive portal when using NTLM authentication.

Cause

NTLM authentication failed. Some common reasons for NTLM authentication failure are as follows:

• The user's access time is restricted.
• The user's surfing or network traffic quota has been exceeded.
• The entered credentials are incorrect.

Remedy

• Check if an access time, surfing quota, or network traffic quota applies to the affected users. See Profiles.
• Make sure the user enters the correct credentials.

Condition

When the firewall detects traffic from an IP address, it sends a request to the STAS collector for user information. While it waits for a reply, the firewall drops the traffic generated by the address.

Cause

There are times when communication between the firewall and STAS collector times out.

Remedy

Check the following items on the endpoint computer that has the STAS collector:

• Ensure the endpoint computer is powered on.
• Ensure the STAS service is running.
• UDP ports 6060 and 6677 must be open on Windows Firewall.
• Ensure any antivirus programs on the endpoint computer aren't interfering with communications.
• If the endpoint computer has multiple NICs, check if STAS is bound to another interface.

Check the following items on the firewall:

• If the STAS collector is on the remote end of an IPsec tunnel, ensure that you configure the SNAT IP address for system-generated traffic.

Condition

STAS users either can't sign in through STAS, or users can sign in but don't appear on Live users.

Cause

There can be many reasons that you don't see some STAS users in Live users. Follow the steps below to check that you've configured your environment correctly and fix any issues you find.

Remedy

Check the following:

• Ensure you've entered the correct credentials of the external authentication server on Sophos Firewall.
• Ensure the firewall and the server can communicate.
• Ensure users only try to access the internet within the time configured in the access time policy.
• Check if the number of signed-in users reached the configured limit.
• If you've configured sign-in restriction for users based on an IP address, users can't sign in from a different IP address.
• Check if users have exceeded the configured surfing quota or network traffic quota.
• Go to Authentication > Servers, select your AD server, and ensure the Search queries are correct.

Condition

After installing STAS, Windows Event Viewer shows DCOM errors with Event ID 10009 or 10028.

Cause

STAS can't connect to an endpoint computer using WMI. WMI works on DCOM and RPC. If an endpoint computer doesn't respond to a WMI query, then Windows Event Viewer records Event ID 10009 or 10028.

Remedy

Make sure you allow WMI communication between STAS and the endpoint computers. See Configure system security.