Web filtering not picking up user

Is this a Server Protection Client? So there is Intercept X for server installed? Check if this server is in the Best Protection EAP. 

Have installed v19 and then followed this article https://docs.sophos.com/nsg/sophos-firewall/19.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Authentication/HowToArticles/AuthenticationConfigurePerConnectionAuth/index.html#create-firewall-rules-for-multi-user-host-traffic

I've attached web policy under the firewall rule - copy of the web policy below - but Auto-IT Admins are still blocked

Ok. But web filtering rules are not working on a per user basis using that config. It’s not recognising who is logged in to the terminal server.

So you are not seeing the user in Live Logging? 

Correct. No username is attached to anything.

I thought that was live logging. Where do I need to go to see live logging?

You need to look for current activities and live users. 

I disconnected all users from Sophos live users and also from the terminal server.

I logged in the to the server as "User1" and browsed the web but User2 popped up in the live users section on the sophos for that server.

Client type is STAS

Any ideas on this LuCar?

STAS? If you have a terminal server, STAS should exclude this terminal server. Essentially the best way is always to have one mechanism per client. So exclude in STAS your terminal servers. 

Excluded terminal server from STAS but still not picking up logged in user

Excluded terminal server from STAS but still not picking up logged in user

Do you see any AD SSO authentication requests in authentication log? 

I can't see anything at all in the authentication log - it just sits there with the wheel spinning forever and nothing loads

So likely there is no entry? Could the NASM be dead in your scenario? You should check access_server.log and nasm.log if you see any problems there. 

Don't really know what I'm looking at, but here they are

nasm.log:

SFV1C4_AZ01_SFOS 19.0.0 GA-Build317# tail nasm.log                              
Jun 04 13:57:47.107957Z  [ntlmserver]  fasm_processor(): AD channel is UP so inf
orming client now                                                               
Jun 04 13:57:47.107994Z  [ntlmserver]  inform_channel_status(): sumit DATA to pr
oxy='0 0 0 0 0 0 0 0 5 8 0 0 '                                                  
Jun 04 13:57:47.108000Z  [ntlmserver]  inform_channel_status(): informing channe
l status to http proxy, channel status=1                                        
Jun 04 13:57:47.108003Z  [ntlmserver]  fasm_processor(): AD channel is UP so inf
orming client now                                                               
Jun 04 13:57:47.108438Z  [ntlmserver]  inform_channel_status(): sumit DATA to pr
oxy='0 0 0 0 0 0 0 0 5 8 0 0 '                                                  
Jun 04 13:57:47.108450Z  [ntlmserver]  inform_channel_status(): informing channe
l status to http proxy, channel status=1                                        
Jun 04 13:57:47.108454Z  [ntlmserver]  fasm_processor(): AD channel is UP so inf
orming client now                                                               
Jun 04 13:57:47.108488Z  [ntlmserver]  inform_channel_status(): sumit DATA to pr
oxy='0 0 0 0 0 0 0 0 5 8 0 0 '                                                  
Jun 04 13:57:47.108494Z  [ntlmserver]  inform_channel_status(): informing channe
l status to http proxy, channel status=1                                        
Jun 04 13:57:47.108501Z  [ntlmserver]  fasm_processor(): domain informed by nasm
 is 'xxxx'                                          

access_server.log

SFV1C4_AZ01_SFOS 19.0.0 GA-Build317# tail access_server.log                     
MESSAGE   Jun 05 10:09:51.572706Z [CAA]: (CA_keep_alive): Next CA batch in 45 se
conds                                                                           
MESSAGE   Jun 05 10:10:03.115783Z [access_server]: tlvserver_process_request: GO
T ALERT.EXECUTE_HEARTBEAT                                                       
MESSAGE   Jun 05 10:10:36.616862Z [CAA]: (CA_keep_alive): access_server heartbea
t                                                                               
MESSAGE   Jun 05 10:10:36.616883Z [CAA]: (CA_keep_alive): Next CA batch in 45 se
conds                                                                           
MESSAGE   Jun 05 10:11:03.396166Z [access_server]: tlvserver_process_request: GO
T ALERT.EXECUTE_HEARTBEAT                                                       
MESSAGE   Jun 05 10:11:21.660407Z [CAA]: (CA_keep_alive): access_server heartbea
t                                                                               
MESSAGE   Jun 05 10:11:21.660441Z [CAA]: (CA_keep_alive): Next CA batch in 45 se
conds                                                                           
MESSAGE   Jun 05 10:12:03.611785Z [access_server]: tlvserver_process_request: GO
T ALERT.EXECUTE_HEARTBEAT                                                       
MESSAGE   Jun 05 10:12:06.704338Z [CAA]: (CA_keep_alive): access_server heartbea
t                                                                               
MESSAGE   Jun 05 10:12:06.704360Z [CAA]: (CA_keep_alive): Next CA batch in 45 se
conds                                                                 

Check the nasm log for anything, which looks like an error. Basically the nasm should be joining. 

Potentially this could be an error: https://community.sophos.com/sophos-xg-firewall/sfos-v18-early-access-program/f/feedback-and-issues/117669/adsso-ntlm-bug-in-v18-eap3/426421

Have run these commands but authentication log still not loading

service -ds nosync nasm:stop
rm -rf /content/nasm
service -ds nosync nasm:start

You should not run some random comments without verifying the issue first. 

The reporting issue seems to be a database issue with logviewer (Garner). 

Would recommend to create a support case, so this can be verified. 

According to support I have to reconfigure all my servers and set them up to use a proxy server.

Surely this isn't required and Sophos is able to identify users just as it used to do?

Actually it is? 

So to recap: 

You can do two different things to authenticate a terminal server: 

You can use Intercept X for Server, which uses a component like SATC. So no changes in behavior there.

You can use no software on the server and resolve this with the explicit proxy + kerberos. This is the new feature of V19.0. See: https://docs.sophos.com/nsg/sophos-firewall/19.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Authentication/HowToArticles/AuthenticationConfigurePerConnectionAuth/index.html#create-firewall-rules-for-multi-user-host-traffic  You can use per-connection AD SSO authentication for multi-user hosts configured to use the Firewall as a direct proxy.

Using a proxy is not an option for the client, so I talked to them and convinced them to purchase Intercept X which is now installed, but there is still no authentication happening.