AD SSO - Cannot establish NTLM authentication channel with xxx

AD SSO (NTLM or Kerberos) is generally incompatible with STAS as the two systems effectively fight each other for who is performing the authentication.

If you are using STAS you should remove AD SSO from Device Access.

If you are using AD SSO, make sure STAS is disabled.

Although the message you are getting is different, if this started occurring with an upgrade you might be hitting a problem with Connection Security - which AD SSO started following in  19.0.  Please see https://support.sophos.com/support/s/article/KB-000043818?language=en_US

Unfortunately, it started before then.

We have however fixed the issue by removing the FW object from the AD and re-authenticating the FW to the AD domain to recreate the object. We suspect however it was because the FW was using external DNS rather than internal DNS to do lookups which for some reason caused this issue. Even thou it is simply the logs messages that were of annoyance, the rest of the services appeared to be working perfectly fine. Well as fine as they can do for the Sophos FW.

We are using STAS as well because otherwise we have no way of knowing when people are logging off otherwise. We need AD SSO for the users' traffic and content etc and we need STAS to identify when things have logged on and more to the point off..............?

The AD SSO method handles logoffs.  Specifically what it does is re-authenticated the user every ~4 minutes.  Or rather, it reauthenticates the user if the last authentication was more than 4 minutes ago.  If reauthentication fails (cannot authenticate or authenticates as different user) then the existing user is logged off.

There is a chance that in a system which has multiple users (eg Fast User Switching) that the XG will not pick up on the new user for up to four minutes (worst case), however that is generally not a problem for customers.  If you are using multi-user systems then potentially the AD SSO multi-user host option (introduced in 19.0) might be something you are interested in because that authenticates every single HTTP/HTTPS connection.

The problem with AD SSO + STAS is that once an IP has ever done AD SSO in the past, the AD SSO system will then assume that the IP always does AD SSO and it always looks for "is reauthentication required".  What can occur then is STAS logs in a user and then AD SSO sees there is traffic when its last login was hours ago so it then runs and also logs in a user.  The two systems end up both trying to do logins and logouts for the same IP and the result can be problematic.  If it works for you then okay, but I would not recommend it and will not support it if there are issues.

AD SSO can have problems if the DNS is incorrect.  In general the AD server should be specified by FQDN and should be resolvable.  There are some special DNS records that computers (including the XG) need to have in order to join the domain.

See here for some examples:
servergeeks.wordpress.com/.../

Many thanks - I will look into the AD SSO and STAS. It was during COVID I was testing that implementation and there became an apparent reason why we need to run it, but I can't right now remember what it was. When I remember I will update this post as to why we end up with AD and STAS. We have quite a mixed enviroment.

All the AD is setup correct with correct DNS records. We believe it happened after we wiped the FW as part of testing. We did use the FQDN and all tested and resolved hence we did not clock the DNS issue. As I said, it appears to be simply entries in a log file, none of the services reliant on the AD seemed to be actually affected that is what was odd about it.

Many thanks - I will look into the AD SSO and STAS. It was during COVID I was testing that implementation and there became an apparent reason why we need to run it, but I can't right now remember what it was. When I remember I will update this post as to why we end up with AD and STAS. We have quite a mixed enviroment.

All the AD is setup correct with correct DNS records. We believe it happened after we wiped the FW as part of testing. We did use the FQDN and all tested and resolved hence we did not clock the DNS issue. As I said, it appears to be simply entries in a log file, none of the services reliant on the AD seemed to be actually affected that is what was odd about it.