Could you please help triage ?

Krishna mentioned that they haven't been able to repro

I've the policy from the customer: https://drive.google.com/open?id=16xnRU-cZjkWyDtF0tBq20KpIGqBMux87
and the version: https://drive.google.com/open?id=1j92wUmP0_sek3NdUarrdw7ixWT7xLZKj

Drew: Do you know who can help on this one ?

Pavol, PTAL at the logs. I couldn't see anything - looks like the user session is starting correctly.

marcore: what error is the user seeing?

when adding a new user they have this screens:
after click on enter button: https://drive.google.com/open?id=12_DksDExVTmcyFgZw0GNu97nC50Q7taR
the startup page: https://drive.google.com/open?id=1d8buyZLWe-HIXy3Yqja91PGRUO5-YNIt

Hrm, I can see errors such as:

[1105:1330:1108/085227.006734:ERROR:cert_verify_proc_nss.cc(902)] CERT_PKIXVerifyCert for accounts.google.com failed err=-8172
[1105:2640:1108/085231.055595:ERROR:cert_verify_proc_nss.cc(902)] CERT_PKIXVerifyCert for ssl.gstatic.com failed err=-8172

in e.g. chrome_20171108-085219

8172 = SEC_ERROR_UNTRUSTED_ISSUER

Are you sure that accounts.google.com is whitelisted, i.e. no SSL inspection is being performed? Because it looks like chrome sees a certificate it doesn't trust.

@pmarko
https://sfstory.googleplex.com/50060000017xE2lAAE#02sf2000014XozOAAS
the answer from the customer:
Hello <Cloud Support>,
I am really sorry but I won't be in until Monday. The ISP said that Google
Hostnames were whitelisted for the IP range 172.23.XX.1 to 172.23.XX.255.
The Chromebooks are getting IPs in that range. Thank you very much for your
help. Let me know if you get any ideas.

they have also upgraded the firewall, and checked again the rules.

the command network_diag --hosts is giving all PASS

That's strange -- do they give a proxy server to network_diag --hosts?

Also, can you forward the policy they have shared? I can't seem to access attachments on the link you posted.

Thanks!

For now I'm assuming that the SSL cert issue was appearing on 08 november 2017 (from when I guess the screenshots in Comment #9 are from) and should be fixed.

I checked the 09 november 2017 11:25 logs again.

I can see what looks like a successful online sign-in in the chrome_20171109-085405 log. This seems to be done on the 172.23* network.
I can see no (successful?) sign-in attempt in the chrome_20171109-094902 log.
I can see no (successful?) sign-in attempt in the chrome_20171109-112534 log.
I can see what looks like a successful offline sign-in in the chrome_20171109-112624 log. This seems to be done on the 172.23.* network.
I can see what looks like a successful online sign-in in the chrome_20171109-112812 log. This seems to be done on a 192.168.* network.

The only worrying things in logs from 11/09 seem to be
That CERT_PKIXVerifyCert for www.googleapis.com failed err=-8172 in the ui.20171109-085404 log around 09:01:14.

So I'm not exactly sure what's happening. Do they always reproduce the behavior seen in the screenshots from Comment #6? Or does it work sometimes and sometimes it doesn't work?
(the latter could be a sign of filtering by IP address and resolving the same hostnames to different IP addresses in subsequent sign-in attempts).

I've called the customer, and it's always not working.
it was working in the summer when the "firewall" configuration was based on the Mac address of the ChromeBook.
I've advised the customer not to use a transparent proxy.

I've another customer with a similar issue:
I've adviced to:
check whitelist
run network_diag --hosts --proxy http://172.XX.YY.ZZ:8080
customer info: https://drive.google.com/open?id=1axdon-x1yVVXAOc34nFq-b18r31Ks3OzATt44OkCdpw
case#: 14232259
debug logs: https://drive.google.com/open?id=1UTSxx7xdNMhYDmTe5VDs_Miy5o-oS35q

In this case, we also have:
[4484:4644:1117/145925.976651:ERROR:cert_verify_proc_nss.cc(921)] CERT_PKIXVerifyCert for www.google.com failed err=-8179
[4484:4585:1117/145926.143552:ERROR:cert_verify_proc_nss.cc(921)] CERT_PKIXVerifyCert for accounts.google.com failed err=-8179
[4484:4484:1117/145927.020400:VERBOSE1:gaia_screen_handler.cc(516)] OnPortalDetectionCompleted Offline

Can they access accounts.google.com from a guest session?
If not, chrome should display why and it should be possible to get the certificate details. It would be helpful to know if this is the certificate they use for SSL MITMing.

Then, we'd need to find out why network_diag --hosts does not show errors (I assume it ran without errors)?

Thanks.

@pmarko
- the network diag was/is giving errors
checking accounts.google.com... FAIL: non-Google SSL/TLS certificate
the customer is configuring correctly the MITM firewall
thanks for the debugging procedure (guest session then go to accounts.google.com), it's more easy that mine. (developer mode curl verbose command)