ubuntu
Broker sometimes needs to be restarted for the provider to be reachable again
While testing the new force_provider_authentication option, I encountered the issue that the broker would consistently fail to connect to the provider after the network connection had been restored:
authd-msentraid[25920]: Could not connect to the provider: Get "https://login.microsoftonline.com/03c73201-ef9e-4182-ae04-0adb51f4a0b6/v2.0/.well-known/openid-configuration": context deadline exceeded. Starting session in offline mode.
I repeatedly toggled the network connection on and off in GNOME's system menu but the broker kept failing to connect to the provider. I was able to open the same URL (https://login.microsoftonline.com/03c73201-ef9e-4182-ae04-0adb51f4a0b6/v2.0/.well-known/openid-configuration) in a browser on the same machine.
Restarting the broker via sudo snap restart authd-msentraid fixed the issue.
Adding additional logs here for another example occurrence of this:
Related: #929
The logs also repeatedly mention: Authentication mode "device_auth" is not supported by the UI
Hey @adombeck ! Just checking in to see if there have been any updates regarding this issue.
Hi @JordanMG13! I didn't encounter the issue again (or maybe I just didn't notice it because I'm usually not using the force_provider_authentication option), so I didn't investigate further. Do you see or get reports about the issue?
Hey @adombeck ! Yes, we've gotten two pretty similar reports about this issue, both in regards to the msentraid broker being used, as this doesn't seem to happen with the google one.
FTR, we talked about the the two cases @JordanMG13 mentioned in a call today. We found that the first was caused by a misunderstanding on how authd works: the customer wants to enforce 2fa instead of local password. The force_provider_authentication should provide them with what they need.
For the second case, Jordan is still waiting for the logs. We can look into that once we got the logs.