Open Bug 1860604 Opened 1 year ago Updated 4 months ago

Unable to log in to George Brown College’s Office 365 instance with a Yubikey on Linux (UA-string dependent)

Categories

(Web Compatibility :: Site Reports, defect, P2)

Product:
Web Compatibility
Component:
Site Reports
Platform:
x86_64
Linux
Type:
defect

Tracking

(Not tracked)

People

(Reporter: overholt, Unassigned)

References

(
URL
)

Details

(Keywords: webcompat:contact-ready, webcompat:needs-sitepatch, webcompat:site-wait)

User Story

platform:linux
impact:workflow-broken
configuration:general
affects:some

(I'm filing on behalf of someone else and I don't have a George Brown account to verify, sorry)

STR

  1. Go to outlook.office365.com and enter username for georgebrown.ca
  2. Get redirected to authentication page for georgebrown.ca and enter username and password
  3. Get redirected back to login.microsoftonline.com for 2FA (via a Yubikey)

Expected

  • able to use the Yubikey and log in via the drop-down PIN prompt like in Chrome

Actual

  • Microsoft “Verify your identity” elements remain greyed out with an infinite progress animation

Modifying the UA string from a. to b. below (to essentially s/Linux/Windows) allows things to work:
a. "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0"
b. "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0"

Thank you for filing on my behalf overholt.

I might be able to do more testing as required. For the failing case, while I clicked "Use a security key", I checked the Console and Debugging Developer Tools tabs, and the strace of the tab's PID from about:processes. There was nothing relevant/remarkable. I also configured about:logging based on https://wiki.allizom.org/Security/CryptoEngineering to "webauthnmanager:5, webauth_u2f:5, webauth_u2f:5, u2fkeymanager:5, u2fhidtoken:5, u2fmanager:5". Again, I saw no relevant log messages. That is why I suspect the JavaScript is in an infinite loop. I left it running for about two minutes during my longest attempt. I also tried setting to true all about:config ".webauth." hits. They were all set to true during the successful workaround attempt.

To me this seems like a server-side issue, not a Firefox bug, given that it is trivial to work around it with the UA modification.

This is probably just server-side UA sniffing, yeah. The problem here is that the sign-in page is hosted on a non-Microsoft domain, in this case adfs.georgebrown.ca. We can't possible ship a User Agent override to all externally-hosted Active Directory setups, as we don't know their domains.

I'll reach out to Microsoft and let them know about this issue - hopefully they can release an update to the software running there.

Flags: needinfo?(dschubert)

Just to be clear, the URL where the spinner spins indefinitely is "https://login.microsoftonline.com/login.srf", not any URL associated with George Brown. The username/password authentication to georgebrown.ca seems to be working fine. As I recall, I switched the user agent after the redirect from georgebrown.ca back to microsoftonline.com, which would suggest the UA sniffing only affected the latter site. If it is useful I can retest to confirm that. I would post the spinner video but it has the username in it.

I re-tested and I only needed to switch the user agent string while the spinner was spinning indefinitely on "https://login.microsoftonline.com/login.srf". Then some reloading happens (I did not catch specifics in the devtools Network tab, sorry), and the PIN drop-down is displayed. After login, I disable the user agent string switcher extension, and everything still works. So it seems like only "https://login.microsoftonline.com/login.srf" is affected.

Oh, that is super helpful! In that case, we totally can (and most likely will) ship a UA override specific to that.

Would you be available to help test a custom Firefox build, just to make sure our intervention works as we hope? This looks a bit hard to test ourselves, and we'd rather not ship something like this "blind".

Yes, I can try to fit in a testing window. Is the UA override list something I can tweak in my local Firefox, rather than you needing to do a complete build? I can do technical stuff like changing databases with the sqlite3 command line utility, or any about:* twiddling, if required.

I have both the latest Firefox from mozilla.org, and Debian's latest-ESR115 to test with. Both failed with the infinite spinning last I tested.

If providing a complete build works best for you, then yes, please do so, and I will test the entire authentication process with a new profile.

An Yubikey is needed for this issue. Dennis, any chance we can test this?

I could reproduce this in another environment, so this is a valid issue.

Severity: -- → S3
Flags: needinfo?(dschubert)
Keywords: webcompat:needs-diagnosis
Priority: -- → P2
URL: https://login.microsoftonline.com
Severity: S3 → S4
User Story: (updated)
Keywords: webcompat:contact-ready, webcompat:needs-sitepatch
Flags: needinfo?(dschubert)

Okay, it took me a while to test this, because hardware key support isn't enabled by default and it's a bit of a process to get it enabled for a M365 tenant. However, after some fiddling, I can confirm what's reported here.

Adding and using a hardware key works fine on macOS and Windows, but not on Linux. This support article confirms that - but it's probably worth noting that they also do not support hardware keys on Edge on Linux?!

I'm not aware of any platform differences on our end. I've sent them an email about this, and will update this bug if I hear back.

Flags: needinfo?(dschubert)
Keywords: webcompat:needs-diagnosis → webcompat:site-wait

That is great Dennis, thank you for confirming you were able to reproduce the issue, and for following up with the service provider. The George Brown student is hoping to eliminate her dependence on Chromium before the September 2024 term. This is the only academic service for which she does not/cannot use Firefox.

You need to log in before you can comment on or make changes to this bug.