|
|
|
|
|
|
by josteink
1280 days ago
|
|
|
> I'm not sure who's to blame here. I would venture to say perhaps AzureAD? When a OS receives an instruction from the router/DHCP server that no proxy should be used on this network, and the OS adheres to that… And that alone just breaks AzureAD, that’s clearly a point where AzureAD needs to be made more resilient. |
|
|
The bug was in WinHttpAutoProxySvc, but at some point ASUS (et al) must have noticed it and chose to send the blank Option 252 to take advantage of the result, without realizing that the result is poor behavior and reporting it to Microsoft.
EDIT: More specifically, it was that a service running on the client was told, in a weird way, that there was no proxy to use. This weird way triggered a bug, so it kept using that setting even after it no longer received that signal (different DHCP on a different network) and a there-is-now-a-proxy setting was available (via DNS).
EDIT 2: To be more clear, Azure AD needs access to the internet, uses WinHTTP (because this is Windows' standard HTTP libraries), and when a bug in one part of this stack was exposed, AAD didn't work. There were no problems with AAD here, even though that's where the user saw the error.