microsoft
Can't sign into Azure from VS Code with the new authentication. VPN blocking native auth flow
I need to sign in to Azure from browser for my company VPN to work properly. I was using browser sign-in page until a couple of weeks.
When I needed to login a couple of days ago I tried as usual but VSCode now opens azure login in a internal view / internal window. I can't sign into my company VPN account this way.
I believe this is because of the new Microsoft authentication method.
Using Azure CLI in a terminal to login doesn't integrate with the azure extensions, and the only way for me now to work is using the classic Microsoft authentication and I can't rely on that because it's going to disappear in the future.
Is there any way to force a "browser login" or login with device code with the new authentication method? If not, could it be added before removing the "classic" option?
What platform are you on?
I need to sign in to Azure from browser for my company VPN to work properly
Can you explain this some more? When you say you have to sign in from your browser, what would the alternative be? The native auth prompt?
Windows 11
I am not sure of the logistics behind the VPN but I can explain the process.
For the VPN to work and be able to have access to my company's Azure resources and such I need to start a private tab / incognito mode and start the connection there. And while I am logged into that session, I can access Azure.
So what we usually did from VSCode before was try to sign in into azure. This opened a tab on the browser for credentials. You copy that url into the private tab and enter your credentials there, the credentials that have Azure access.
With the new authentication method, no tab is opened on the browser so I can't login with this usual method we were using.
I was told that we should require signing in via the Broker whenever possible because that's the future. I'll ask the Identity folks if I can provide an opt-out mechanism... but they may very well say that this is not something we should allow.
I have the exact same issue in my company. If I'm at work, not using the VPN, the sign in pop up works. Because the native network is used.
But when in remote, I use my own WiFi + VPN and the pop up fails to connect to azure. Because the VPN dose not apply to Vscode. Making all our developers in remote unable to connect to Azure (machine learning in our case).
I'll try to install an older version, but this popup is not a good idea for us. Or at least we should have an option to keep using the default browser.
Edit: Version 1.96 works correctly for us with the VPN. It opens the browser instead of an internal popup.
The real fix for this is that the native window that pops up should play nice with your VPN. Full stop.
@Uranium2 saw that it doesn't:
I'll see who to engage here because VS Code is just a user of the native auth flow.
@RaulCorrero @Uranium2 if you could give me any information that could be useful for me about your VPN setup... or your organization's auth setup that would help me here that'd be great.
On my side, my company is using Cisco VPN
This is the default parameters of the VPN. The settings does not save over time (restart of VPN or computer restart)
In my case, we are using connect tunnel as VPN from home, then access a special corporate account from a cyberark vault. From this special account we can access microsoft services, as azure, on the browser.
I didnt have much luck trying to use this account on vscode with the new auth method, it doesnt connect correctly. Thats why I would need the browser login to stay, hopefully.
Technically we also have a corporate WebSSO before any connection to Azure Auth page. So i'm not sure if it's the VPN or the SSO that is not taking into account (or both) inside the Vscode popup.
Similar issue here, in the sense that the new authentication popup makes it unable for us to sign in to our elevated accounts. We have never been able to use our separate elevated accounts in Edge, but it will work in other browsers. I assume this built-in popup is using Edge in the backend, because we are no longer able to log in.
Thanks all, I'll try to find the right folks to look at this since we're just using the native broker library and the issue has something to do with that.
Hi, while I track down the right folks... I got a suggestion from someone.
Can you all check with your IT department to see if the VPN is routing different apps through the VPN?
WAM uses backgroundtaskhost.exe & Microsoft.AAD.BrokerPlugin.exe and both of these need to go through the VPN otherwise you will have a bad time.
Likely unrelated: Fiddler will break WAM unless you enable the correct loopback permissions... in case anyone had Fiddler running at the same time.
Likely unrelated: Fiddler will break WAM unless you enable the correct loopback permissions... in case anyone had Fiddler running at the same time.
According to your tips, I enabled all uwp's loopbacks and now work fine, can you tell me which uwp is responsible for WAM?
@lvzhenbo don't worry. Classic won't go away for now. It will, in the future, but I need to see this volume of issues come down and a defined process in place for these kinds of issues that are outside of VS Code's control.
@edjia I'm not 100% sure... but I would guess Microsoft.AAD.BrokerPlugin.exe... let me know if it's not and I can dig further.
@edjia I'm not 100% sure... but I would guess Microsoft.AAD.BrokerPlugin.exe... let me know if it's not and I can dig further.
yes, everything works fine after adding Microsoft.AAD.BrokerPlugin.exe to exemption list with fiddler's AppContainer Loopback Exemption Utility.
Solved this by turning off the VPN while login. Don't know if this is the limitation for login, or for the sync, hope it will be the first.
@edjia I'm not 100% sure... but I would guess Microsoft.AAD.BrokerPlugin.exe... let me know if it's not and I can dig further.
yes, everything works fine after adding Microsoft.AAD.BrokerPlugin.exe to exemption list with fiddler's AppContainer Loopback Exemption Utility.
This method solved my issue. I was experiencing the same problem as mentioned in the topic: I couldn't log in to my Microsoft Account when the system proxy was active (I received error code HTTP return 404). This could be temporarily resolved by using these two methods:
- Turn off the proxy/VPN first, then start VS Code or log in.
- Change the login implementation from MSAL to classic (though it is stated that this method is deprecated and will be removed in the future).
I need to do this every time after restarting the system.
This issue occurred on both my VS Code and my Windows Store, and the method mentioned by TylerLeonhardt actually solved both issues. P.S.: I called this AppContainer Loopback Exemption Utility from V2rayN, and I checked every package with "Microsoft" in its name.
@TylerLeonhardt I noticed the recent announcement about removing the classic login, yet this issue remains unresolved. Does this mean there is no solution other than manually removing the loop restriction?
@lvzhenbo from the release notes:
We will remove the
classicoption since it's usage is very low and most issues with themsaloption are due to the brokering, which is remedied withmsal-no-broker.
I expect msal-no-broker to be fine for this issue and it isn't going away any time soon.
Solution is to open User settings > microsoft-authentication.implementation > Microsoft-authentication -> msal-no-broker Then your sign in attempts will open the browser instead of the integrated login window.
