Since updating SG210 to v 18 EAP 2 we constantly get a default Sophos captive portal when Chrome users browse to sites

Hi Gemma,

Thanks for reporting. We have not heard of this problem before, and it sounds like you have a complex setup. Most customers (AFAIK) use either STAS or AD SSO and not both. I want to understand your configuration a bit better.

You report it "with xstream". In the firewall rules for web, is "Use proxy instead of DPI mode" checked or unchecked? Does it work if you switch back to proxy mode?
You report it failing after upgrading to EAP2. Was this working in EAP1? Or was this a 17.5 to 18.0 EAP2 upgrade?
You report it failing with Chrome. Is this relevant? In other words does it fail in Chrome but succeed in other browsers?

The normal flow for your config would be:
Users are authenticated with STAS.
If that fails, it will fallback to authenticating with AD SSO (NTLM/Kerberos)
If that fails, it will fallback to authenticating with Captive Portal
Within the Captive Portal settings there is configuration about when to detect the user is logged out and needs to be authenticated again.

When it was working, were all users authenticated with STAS?
In other words, did it ever need to fallback to AD SSO?
If you always used STAS, then it could be that the reason AD SSO is failing is because AD SSO has never been configured properly.
The main fix would be repair whatever is causing STAS to stop working. Separately, fixing the configuration for AD SSO would allow that fallback to work.

If in the past you were doing AD SSO, then there could be problems in AD SSO.
Between 17.5 and 18.0 we've made many changes. However there were none between EAP1 and EAP2.

1) It sounds like first STAS is failing.
I'm not an STAS expert so I cannot help with that.
community.sophos.com/.../123022
community.sophos.com/.../123156
www.fastvue.co/.../

2) Then it sounds like AD SSO is failing.
This could be configuration (how XG talks to AD server) or it could be configuration (how XG talks to clients).
Knowing if this was previously being used would help.

3) Then it sounds like Captive Portal is asking for authentication every time you open up new web pages.
It sounds like the configuration for Captive Portal is not what you want for how you use the system. By default, Captive Portal will log you out when you close the Captive Portal page. This can be changed to an inactivity detector. Look at Authentication > Web authentication > Captive portal behavior. This configuration page is new to v18.0 and is clearer than it was in 17.5, however the backend is the same. I know that ultimately you don't want to be using captive portal, so it is up to you whether you want to fix the behavior when it is being used.

Log files:
/log/nasm.log
/log/access_server.log
The stas log is on the AD server, see the KB above.

If you want, you can also open a support tunnel which will allow us to log into your device and look at it.

Diagnostics > Support Access > Grant Access.  Tell us the Access ID.

Hi Gemma,

Thanks for reporting. We have not heard of this problem before, and it sounds like you have a complex setup. Most customers (AFAIK) use either STAS or AD SSO and not both. I want to understand your configuration a bit better.

You report it "with xstream". In the firewall rules for web, is "Use proxy instead of DPI mode" checked or unchecked? Does it work if you switch back to proxy mode?
You report it failing after upgrading to EAP2. Was this working in EAP1? Or was this a 17.5 to 18.0 EAP2 upgrade?
You report it failing with Chrome. Is this relevant? In other words does it fail in Chrome but succeed in other browsers?

The normal flow for your config would be:
Users are authenticated with STAS.
If that fails, it will fallback to authenticating with AD SSO (NTLM/Kerberos)
If that fails, it will fallback to authenticating with Captive Portal
Within the Captive Portal settings there is configuration about when to detect the user is logged out and needs to be authenticated again.

When it was working, were all users authenticated with STAS?
In other words, did it ever need to fallback to AD SSO?
If you always used STAS, then it could be that the reason AD SSO is failing is because AD SSO has never been configured properly.
The main fix would be repair whatever is causing STAS to stop working. Separately, fixing the configuration for AD SSO would allow that fallback to work.

If in the past you were doing AD SSO, then there could be problems in AD SSO.
Between 17.5 and 18.0 we've made many changes. However there were none between EAP1 and EAP2.

1) It sounds like first STAS is failing.
I'm not an STAS expert so I cannot help with that.
community.sophos.com/.../123022
community.sophos.com/.../123156
www.fastvue.co/.../

2) Then it sounds like AD SSO is failing.
This could be configuration (how XG talks to AD server) or it could be configuration (how XG talks to clients).
Knowing if this was previously being used would help.

3) Then it sounds like Captive Portal is asking for authentication every time you open up new web pages.
It sounds like the configuration for Captive Portal is not what you want for how you use the system. By default, Captive Portal will log you out when you close the Captive Portal page. This can be changed to an inactivity detector. Look at Authentication > Web authentication > Captive portal behavior. This configuration page is new to v18.0 and is clearer than it was in 17.5, however the backend is the same. I know that ultimately you don't want to be using captive portal, so it is up to you whether you want to fix the behavior when it is being used.

Log files:
/log/nasm.log
/log/access_server.log
The stas log is on the AD server, see the KB above.

If you want, you can also open a support tunnel which will allow us to log into your device and look at it.

Diagnostics > Support Access > Grant Access.  Tell us the Access ID.