AD SSO - Cannot establish NTLM authentication channel with xxx
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..............?
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.
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/.../