Microsoft SSO login to ChromeOS - was working, now not

[3s-gtech]

Wonder if anyone else has seen this?

 

We've been successully using Microsoft accounts to SSO onto our Chromebooks. Works fine - enter username and password, on you go.

 

Until this week. It just started looping back to the login screen. Checked the services portal - fault with some applications, so waited for that to be fixed. No change.

 

Now started into the black hole of changing how SSO works on them. I have setup and approved OIDC (Open ID Connector) instead of the old application setup, which should be good, but now we just get 'cannot verify that this account is yours'. Kind of makes sense - we're trying to get into the same accounts with a different credential provider now.

 

Thankfully my admin accounts were not included in the SSO scope, so I can get into Google Workspace. No one else can.

 

Any ideas?

[FN-GM]

Have you checked the logs under the user sign in activity? Is anything hitting conditional access?

[3s-gtech]

In Entra? They're logging in successfully. CA is off/bypassed within this IP range.

[willtech]

Is it using the legacy SSO ?

[steveg]

Have you checked filtering?  Try one on an unfiltered connection and see if the problem persists, we get this sometimes, they change the urls that need to bypass filtering.  

[BKGarry]

Weirdly mine is working and I am not using OIDC, I did have to change a SSO setting in the Entra ID Application to use UPN rather than email, due to historical reasons though

[3s-gtech]

I'm now in with a test user.

 

Couple of things:

I've changed to OIDC rather than legacy. Legacy stopped working for the above reason - the Unique User Identifier was set as user.mail and this stopped working for us very recently (login loop) for all users.

 

The test user I was using had a correctly formed UPN field, but no email address set in AD. Grrrrr. Only spotted that in Entra. Tested back with another user and it let me in.

 

OIDC isn't as slick on desktop now - when I click on the Google Workspace icon in the Micorosoft 365 portal it doesn't go straight in, but asks for the email address again (not the password). I suspect this is a quirk with the redirect URL in Entra but it's a turnkey solution and you can't easily edit anything.

I've actually kept the old legacy SAML application running in Entra because if I disable it, users sometimes can't log on to ChromeOS. Might be solved if I delete that application but I'd rather not!

[BKGarry]

ah, I am not using Legacy, I setup this summer and used a new one with EntraID from here https://cloud.google.com/architecture/identity/federating-gcp-with-azure-ad-configuring-provisioning-and-single-sign-on

(I did not do the provisioning, as that is running through GCDS or whatever the server application is called) but then I had the UPN fun which I changed from email and removed all the other claims in Entra

[speakercon]

I've seen this before and it was a web filtering issue same as @steveg

[3s-gtech]

It was fixed by changing the unique identifier from user.mail to UPN. It's worked with mail for years, but not this week!

[mjhardisty]

Had lots of issues with this with EXA filtering. 

[Patrick_Exa]

@mjhardisty Sorry to hear you have had issues with Exa around the Chromebook sign-in via Entra.

 

I have been looking at a ticket that was raised with us in January, which I believe is one of your schools, and I can confirm that we are still investigating the root cause of the problem, which is that Google does not like it when traffic to www.google.com is decrypted, which breaks the communications and results in the sign-in failing. But if we stop decrypting this, then keyword filtering on Google search pages would be redundant.

 

If you would like to discuss this issue further, please feel free to get back in touch with our Helpdesk via email ([email protected]), or you can email me directly ([email protected])