Repository navigation
Authentication error connecting to Azure SQL Database. #3196
Description
Activity
Claude posting for Erik Darling
Thanks for the detailed report — the screenshots and the full error text made this diagnosable, which is not usually true of authentication failures.Here is what your error says, and then some questions, because the answers change what we do about it.
What is happening
When you pick Microsoft Entra MFA, Performance Monitor asks the Microsoft SQL client library to sign you in. On Windows 11 that library does not open a browser. It hands the sign-in to a Windows component called the Web Account Manager, or WAM — the same thing that manages the accounts under Settings → Accounts → Access work or school. WAM shows the account picker, talks to Entra, and returns a token.
In your case WAM was reached, it ran, and it refused. That is what
unknown_broker_errormeans, and the code beside it —0x80070520— is a Windows error meaning "a specified logon session does not exist."Two things follow, and I want to be straight about both:
It is not your server name, your database name, or your password. The failure happens on your machine before anything is sent to Azure. Those fields are not what is wrong.
There is nothing Performance Monitor can currently do about it. I checked the SQL client library's source rather than guessing. It routes Entra MFA sign-in through WAM and, for applications using the library's own Microsoft app registration, offers no way to switch to a browser instead — there is a setting that looks like it should, and it has no effect in that configuration. The library also only falls back to a browser when WAM is missing; when WAM is present and returns an error, as here, the error is passed straight through. So retrying as-is will fail the same way, and that is a limitation on our side, not impatience on yours.
Worse, Windows does not tell applications why WAM refused. The
Context: (pii)line in your error is where the reason would be — Windows withholds it, and the SQL client library gives us no way to turn it on. So the reason has to be narrowed down from the outside, which is what the questions below are for.Questions
1. Is Performance Monitor running as administrator? Right-click the shortcut you launch it from and check the Compatibility tab for "Run this program as an administrator", and check whether you see a UAC prompt at launch. WAM behaves differently for elevated and non-elevated programs, and an elevated program cannot always reach the signed-in user's account session — which is one way to get exactly this error. If it is running elevated, please try launching it normally; if it is not, and SSMS is, that is worth knowing too.
2. What does the sign-in prompt look like in SSMS — and does one appear at all? This is the most useful question here, so please answer it even if you skip the rest. When you connect in SSMS with the same settings, do you get:
- (a) a small Windows dialog listing your work accounts, that looks like part of Windows; or
- (b) a browser window, or a web page inside an SSMS window, where you type your address and approve MFA; or
- (c) no prompt at all — it just connects?
If the answer is (b) or (c), then SSMS is not using WAM the way we are, and "it works in SSMS" unfortunately does not tell us that WAM is healthy — it tells us SSMS takes a different route. If it is (a), WAM is working for SSMS and failing for us, which points somewhere quite different and is very much worth knowing.
3. Does anything else that signs in with a Windows account work? For example, open Settings → Accounts → Access work or school, click your work account, and see whether it reports an error or asks you to sign in again. If Windows itself is unhappy with that account, we have found it.
4. The logs. They should be at:
%LOCALAPPDATA%\PerformanceMonitorLite-Data\logsPaste that into the File Explorer address bar, not into PowerShell — PowerShell does not expand
%LOCALAPPDATA%and will just report that a folder by that literal name does not exist, which may be what you ran into. If the folder really is absent after the app has run, please say so, because the app creates it at startup and writes to it immediately, so its absence would be a separate bug and I would want to chase it.I should say: even if you find the log, for this failure it will not contain more than your screenshot already does. That is the gap PR #3201 closes — it makes the app record the full error chain and print the log location in the dialog — so next time there is something to send. It does not fix the sign-in.
Things worth trying
These are Windows-side, and they are the standard remedies for this error. Microsoft documents them for
0x80070520:- Sign the work account out and back in. Settings → Accounts → Access work or school → your account → Disconnect, then add it back. (Check with whoever manages your machine first if it is company-managed — disconnecting can affect other things.)
- Clear WAM's cached state. Close Performance Monitor, then in the File Explorer address bar go to
%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\LocalState, rename the folder namedWamDefaultSettoWamDefaultSet.old, and restart the machine. Renaming rather than deleting means it can be put back. - Credential Manager. Search for Credential Manager, open Windows Credentials, and remove entries for your organisation or for MicrosoftOffice/MicrosoftAccount. Then restart.
If your machine was recently re-joined to the domain, or your IT team has rebuilt a domain controller lately, that is a known trigger for this and worth mentioning to them.
If none of that works
There is one route available in the app today that avoids WAM completely: the Azure — Service Principal authentication option (that is its exact label in the connection dialog). It uses an Entra app registration with a client secret instead of an interactive sign-in, so there is no account picker and no MFA prompt. It does need someone who can register an application in your tenant and grant it access to the database, so it is not a one-click answer — but if you have that, it will work where Entra MFA currently does not.
Separately, I am looking at giving the app a proper WAM-free interactive option so this does not depend on the broker at all. That is a larger change and I do not want to promise a date, but your report is what put it on the list. I will keep this issue open until you have a working path.
- added a commit that references this issue
on Sep 9, 2026 
- Yes, I run it as local admin.
- SSMS starts a small browser window to enter the password. So (b).
- Everything in our org is Entra MFA so yes everything else works fine as far as I know.
Tried the "Settings -> Account --> Acces work or school" and it works. - I get "Windows can´t find C:\Users\MyUser\AppData\Local\PerformanceMonitoLite-Data/Logs", but after seeing the commit I guess that´s fixed.
Attached: Image of my Azure Cloud Settings.
I asked a LLM about the two settings for WAM and/or Browser and it says SSMS will fallback to Browser if WAM fails.
Dono if the LLM is guessing.My guess is that WAM is not possible, our IT department have probably implemented restrictions for windows apps using WAM.
If you want to you can close this Issue, I´ll talk to my IT department to verify if my theory is the reason and will open a new issue if needed.
Sorry for the hustle.Claude posting for Erik Darling
There is now a way in, and I would like you to try it.
What has changed
Performance Monitor Lite has a new option in the Authentication list on the Add
Server screen:Azure — Existing Sign-In (az login)
It exists specifically because Microsoft Entra MFA cannot be made to work in your
situation. As I said before, when you pick Entra MFA the Microsoft SQL client library
hands the sign-in to a Windows component called the Web Account Manager, and there is
no way for us to ask it not to. In your case that component ran and refused. Nothing
we can change in the app affects that.The new option takes a completely different route. It does not use the Web Account
Manager at all. Instead of signing you in itself, it uses an Azure sign-in you have
already made on that machine, from some other tool.What it needs from you, and this is the important part
It will never show you a sign-in prompt. Not a window, not an account picker,
nothing. If there is no Azure sign-in on the machine already, the connection simply
fails.The most straightforward way to give it one is the Azure CLI:
-
Install the Azure CLI if it is not already there — Microsoft's installer is at
https://aka.ms/installazurecliwindows -
Open a Command Prompt or PowerShell window as the same Windows user you run
Performance Monitor Lite as, and run:az login -
That opens a browser, and you sign in there with MFA the way you normally would.
This is the one and only sign-in step, and it happens in your browser rather than
through the Windows component that is failing. -
Leave that signed in. Then open Performance Monitor Lite, add the server, choose
Azure — Existing Sign-In (az login), fill in the server name and database the
same way you did before, and press Test Connection.
It also works from an Azure PowerShell sign-in (
Connect-AzAccount), or a Visual
Studio sign-in, if you already have one of those. Theaz loginroute is the one I
would try first because it is the easiest to check.Two things worth knowing before you try it:
- If your account can sign in to Azure but has no access to that particular database,
you will get a different error — a login failure naming a user rather than an
authentication failure. That is progress, not a regression, and it means the sign-in
worked and the database permission is the remaining step. - If you have more than one Azure identity set up on the machine, this connects as
whichever one it finds first, which is not necessarily the one you use in SSMS. It
searches, in order: environment variables, a managed identity, Visual Studio, VS
Code, the Azure CLI, Azure PowerShell, then the Azure Developer CLI. The connection
screen lists this too. If the wrong identity gets picked, the Azure — Service
Principal option is the one that lets you name an identity exactly.
Please tell me which of these you get
I have to be straight with you about something: nobody here has been able to test
this against a real Microsoft Entra tenant. We do not have one. Everything about
this option was worked out by reading Microsoft's published source code for the SQL
client library and its Azure sign-in library, and the app's own behaviour is covered
by automated tests — but "a real Entra tenant issues a real token through this path"
is not something we have been able to run. You are the first person who can.So whatever happens, it is useful. Please tell me which of these you see:
A. It connects. Best case. Please say so — it tells us the option works and I will
say so in the release notes.B. "This authentication mode signs in as an Azure identity that is already
established on this machine... it found nothing to use." Then the sign-in did not
take, or the app cannot see it. Please tell me:- whether
az loginreported success, - what
az account showprints (please remove the tenant id, subscription id and
your email address before pasting it — I only need to know that it printed
something rather than an error), - whether Performance Monitor Lite is running as the same Windows user you ran
az loginas. The Azure CLI keeps its sign-in in a folder under that user's own
profile (%USERPROFILE%\.azure), so if Lite runs under a service account or another
user it will not find it. Running Lite as administrator is fine here as long as it is
still you.
C. "An Azure sign-in was found on this machine but failed while being used." Then
it found one and something went wrong using it. Runaz loginonce more and try
again; if it repeats, the log will say why.D. A login failure naming a user, or a permissions error. The sign-in worked. What
is left is granting that identity access to the database, which is a normal Azure SQL
step and I can walk you through it.E. Anything mentioning a broker, or the same
unknown_broker_erroras before. This
one I would very much like to know about, because it should not be possible on this
route and it would mean I have missed something.In every case except A, please also attach the newest file from:
%LOCALAPPDATA%\PerformanceMonitorLite-Data\logsPaste that into the File Explorer address bar, not PowerShell — PowerShell does not
expand%LOCALAPPDATA%and will just tell you no such folder exists. The app now
writes the full error chain there and prints that same path in the error box, so
whatever comes back should be considerably more useful than last time.Where to get it
The option is not in 3.6.0. It is in tonight's nightly build, 3.6.0-nightly.20260909:
https://github.com/erikdarlingdata/PerformanceMonitor/releases/tag/nightly
Download
PerformanceMonitorLite-3.6.0-nightly.20260909.zip. Two things worth saying about
that plainly:- It is a pre-release. It has passed CI and it is running on our own monitoring fleet as
of tonight, but it is not the released 3.6.0 you have now. If you would rather wait for a
numbered release, that is entirely reasonable — say so and I will tell you when it ships. - I verified the option is actually in that specific download rather than assuming it,
because I would rather not send you looking for something that is not there: the archive's
checksum matches the published manifest, and the authentication mode and its exact list
entry are both present in the shipped binary.
Entra MFA itself is still broken for you and I am leaving this issue open. I am not
claiming this fixes it; I am claiming it is a route that avoids the part that is
failing, and asking you to find out whether that is true.-
Claude posting for Erik Darling
I posted that last comment without reading your reply first. Apologies — you answered all four questions five hours before I wrote it, and the most useful thing in your answers is one I asked for and then walked straight past.
Answer 1 is the lead: you run it as local admin. That is a known cause of exactly the error you are getting. An elevated process runs in a different context from your interactive sign-in, and the Web Account Manager cannot always reach the signed-in user's account session from there — which surfaces as
0x80070520, "a specified logon session does not exist." That is your error code, precisely.So before anything else, please try this, because it costs nothing and it may fix Entra MFA itself: close Performance Monitor Lite, then start it normally — not "Run as administrator", no elevation prompt — and try Entra MFA again. If the shortcut you use has "Run this program as an administrator" ticked on its Compatibility tab, untick it for the test. Lite does not need elevation to connect to a server.
If that works, your IT department has restricted nothing and the answer is simply not to run it elevated. If it fails identically, that removes elevation as the cause and your theory gets much stronger.
Answer 2 confirms the diagnosis rather than contradicting it. You said SSMS shows a small browser window — that is (b), and it means SSMS is not using WAM the way we do. So "it works in SSMS" tells us SSMS took a different route, not that WAM is healthy on your machine. Your LLM is right that MSAL can fall back to a browser; what it is missing is that the fallback fires only when the broker is missing, not when a broker that is present refuses. That is the difference between SSMS's behaviour and ours, and it is why yours fails where SSMS succeeds.
Answer 3 is useful in a way that is easy to overlook: Settings → Access work or school being healthy means the account itself is fine. Combined with (b), that narrows this to "the broker specifically refuses this specific caller" — which is consistent with your IT-restriction theory and with the elevation theory, and the elevation test is the one you can run in two minutes without involving anyone.
Answer 4 — one small thing. The folder is
PerformanceMonitorLite-Data; the path in your message readsPerformanceMonitoLite-Data, missing ther. That may just be a typo in the message. Either way it should exist and be written to from launch, so if it is genuinely absent after the app has run, that is its own bug and I would want to know.On closing it: please do not close it on my account, and no hustle at all. Your report was unusually good — full error text, screenshots, and you separated what you had verified from what you were guessing, which is more than most. It has already produced a fix for the missing diagnostics and a new sign-in route that avoids the broker entirely.
So: try it non-elevated first, since that is free and might solve the actual problem. If it still fails, the
Azure — Existing Sign-In (az login)option in the nightly is the route that avoids WAM regardless of what your IT department has configured. And if you do hear back from them, I would genuinely like to know what they say — a confirmed WAM restriction would be worth documenting for whoever hits this next.Tried to use the nightly release but due to very high IT security policies I cant run any of them. The only one that works is the portable.
Claude posting for Erik Darling
The portable ZIP is the right one, and you don't need the installer at all. The new sign-in mode is compiled into the same Lite binary that ships in the portable build, so everything I asked you to test is already in the copy you have running. IT blocking the Setup.exe changes nothing here.
The exact path, which deliberately avoids the Windows account broker that's failing for you:
- Open a terminal as the same Windows user you run Lite as (not elevated) and run
az login. Sign in there. That establishes the identity Lite will reuse. - In the portable Lite, Add Server.
- For authentication choose "Azure — Existing Sign-In (az login)" instead of Microsoft Entra MFA. Leave username and password empty.
- Enter the server and database and hit Test Connection.
That mode signs in as whatever identity
az loginjust established and never opens a prompt or touches the broker, so the0x80070520path is out of the picture entirely. If it fails it will tell you which of two things happened: nothing found (theaz logindidn't take, or Lite is running as a different Windows user than the one you ran it as), or an identity was found but the database refused it (a normal Azure access grant I can walk you through).Caveat I'll keep repeating because it's true: this mode still hasn't been confirmed against a live Entra tenant, so whichever way it goes is genuinely useful. If it connects, you're the first confirmation it works.
- Open a terminal as the same Windows user you run Lite as (not elevated) and run
I have to start any "Unknown" applications using my local admin account due to IT policy.
I used the wrong zip(sorry), but the Nightly still gets blocked by Windows security.
I guess the Portable version (3.6.0) does something different then the nightly because windows does not block it.Claude posting for Erik Darling
That is expected, and you did nothing wrong. It comes down to code signing, not anything the app does differently. The 3.6.0 you are running is Authenticode-signed through SignPath, so Windows recognizes the publisher and does not treat it as "Unknown." Nightly builds are shipped unsigned by design, so to Windows Security every nightly is an "Unknown" publisher, which is what your policy blocks and what forces the run-as-admin path.
The catch for you: the
az loginsign-in mode I asked you to test currently exists only in the nightly, and the nightly is the thing your environment blocks. So there is no way for you to run that fix from a nightly in your setup, and chasing it there was my mistake, twice.The real fix is the next numbered release, 3.7.0, which is in preparation. It contains the "Azure — Existing Sign-In (az login)" mode and is signed the same way 3.6.0 is. Two things fall out of that for you: Windows Security accepts it like it accepts 3.6.0 (no "Unknown" block, no forced run-as-admin), and not being forced to run elevated also removes the elevation mismatch that was breaking Entra MFA in the first place. The
az loginmode also avoids the Windows broker entirely, so it is a second, independent way around the original failure.Net: you will not be able to test this from a nightly in your environment, and you do not need to. It lands signed in 3.7.0, and I will follow up here when that ships.
Reacted by EpitomeOfDeathClaude posting for Erik Darling
3.7.0 is out, and it is signed, so it should run in your environment where the nightly was blocked as "Unknown": https://github.com/erikdarlingdata/PerformanceMonitor/releases/tag/v3.7.0
It includes the "Azure — Existing Sign-In (az login)" mode. Grab the Lite Setup.exe or the portable zip from that release. Run
az loginas your normal Windows user first (not elevated), then in Add Server pick "Azure — Existing Sign-In (az login)" instead of Microsoft Entra MFA and leave username and password empty. That mode never touches the Windows broker that was failing for you. If it still fails, the error text will say which of two things happened: nothing found (the az login did not take, or Lite is running as a different Windows user), or an identity was found but the database refused it, which is a normal Azure access grant I can walk you through.Hi, Tried 3.7.0 and it gets blocked.
3.6.0 still starts.Directory and Icons don´t
match.
Claude posting for Erik Darling
I owe you a correction. I told you 3.7.0 would run where the nightly did not, because it is signed and the nightly is not. I had not checked the artifacts, and the reasoning was wrong.
What I actually found
I read the certificate tables straight out of the published downloads:
file 3.6.0 3.7.0 current\PerformanceMonitorLite.exe(inside the portable zip)signed signed Setup.exenot signed not signed The app binary is signed in both releases, by the same certificate — same serial number, same fingerprint, same validity dates. So 3.7.0 is not less signed than 3.6.0. They are identical in that respect, which means signing is not what differs between the one that runs and the one that gets blocked, and my prediction was built on the wrong premise.
Two separate things fall out of that.
The installer genuinely is unsigned, on both releases, which I did not know and which is a real bug on our side — the packaging tool generates
Setup.exeafter the signing step runs, so the one file a person double-clicks is the one file that never gets signed. That is now #3288. You do not need the installer, so it does not block you, but you were right to be suspicious.The thing your IT policy is reacting to is reputation, not signature. Windows tracks these separately: a file can be correctly signed and still be treated as unknown until that specific file has been seen enough times. The 3.6.0 portable has been downloaded 74 times; the 3.7.0 portable, twice. Same publisher, same certificate, brand-new file.
The most useful thing I can give you, for your IT conversation
If your IT team allowlists by publisher, the publisher name is not mine. The certificate reads:
O = SignPath Foundation CN = SignPath Foundationissued by
GlobalSign GCC R45 CodeSigning CA 2020. SignPath Foundation provides free signing for open-source projects and signs with its own certificate, so that is the publisher Windows sees — not "Darling Data" or my name, which is what anyone would think to search for and not find.That is worth taking to them directly, because a publisher allowlist entry for SignPath Foundation would cover this release and every future one, rather than needing an exception per download.
What I need from you, and it is one line
What exactly does the block say? The wording tells us which mechanism it is, and they have different fixes:
- "Windows protected your PC" with a Run anyway under More info → SmartScreen reputation. Annoying, works around easily.
- "Your organization used Windows Defender Application Control to block this app", or a mention of an administrator or a policy → WDAC or AppLocker. No user-side workaround at all; only IT can allowlist it, and the publisher name above is what they need.
- Anything naming a virus or threat → Defender detection, which is a different conversation and one I would want to hear about immediately.
Two things worth trying while you wait on IT
Unblock the zip before you extract it. Right-click the downloaded
.zip→ Properties → tick Unblock at the bottom → OK → then extract. Windows tags downloaded files, and extracting propagates that tag to every file inside, so unblocking afterwards means doing it file by file. This is a two-click fix if SmartScreen is what is stopping you.Then run the app directly from
current\PerformanceMonitorLite.exein the extracted folder. That is the signed binary, and it is the same path in both releases — I checked the layout of both zips and it has not changed, so nothing about 3.7.0's structure should look different from 3.6.0's.On that: you mentioned the directory and icons do not match, with two screenshots. I could not tell from them what specifically differs, and since I have just confirmed the internal layout is the same in both, I would rather ask than assume — what did you expect to see and what did you get? If 3.7.0's portable really does unpack differently, that is a packaging regression and I want it.
Why this is worth pushing on rather than giving up
The elevation loop is still the heart of your original problem. Your policy forces unknown-publisher apps to run as local admin; running as local admin is what breaks the Entra MFA sign-in with
0x80070520. So getting the publisher recognised does not just get the app to start — it lets you run it non-elevated, which may well fix the authentication you originally reported, with no other change.And if IT confirms a WDAC or AppLocker policy, that is genuinely useful to know here: it would be the first confirmed instance, and it is worth documenting for the next person.
Claude posting for Erik Darling
Your "directory and icons don't match" observation was the useful one, and I have the answer. You were not confused — the two downloads really are different, and one of them is why you are being blocked.
The release contains two zips with different layouts
PerformanceMonitorLite-3.7.0.zipPerformanceMonitorLite-lite-Portable.zipstructure flat — every DLL sitting at the top level .portable,Update.exe, and acurrent\folderthe PerformanceMonitorLite.exeat the top levelthe real app, 182 kB, signed a 399 kB launcher shim, NOT signed where the real app lives at the top level inside current\So in the portable zip, the obvious thing to double-click —
PerformanceMonitorLite.exe, right there at the top — is not the application. It is a small unsigned launcher, and that is what Windows is refusing. The signed application is one folder down, incurrent\.That also explains the icons: a launcher shim and the real app are different binaries, so they do not have to look alike.
What to do
Run
current\PerformanceMonitorLite.exefrom the extracted portable folder. That is the signed 182 kB binary. Right-click it → Properties → Digital Signatures should show a signature; the top-level one will show no such tab at all, which is a quick way to confirm you are on the right file.Or use
PerformanceMonitorLite-3.7.0.zipinstead — the flat one. Its top-levelPerformanceMonitorLite.exeis the signed app, so there is nothing to get wrong. Given your environment I would use this one.Either way you never need
Setup.exe, which is also unsigned.I was wrong twice and want to be clear about it
Nothing changed between 3.6.0 and 3.7.0. I checked rather than assumed this time: the two portable zips contain 694 entries each, with zero files added, removed or renamed; the signing configuration is byte-identical at both release tags; and the certificate is the same one, same serial number, same fingerprint, same dates. There is no 3.7.0 packaging regression.
Which means your 3.6.0-works/3.7.0-blocked experience is almost certainly that you launched the signed app in one and the unsigned shim in the other. 3.6.0 has the same three unsigned executables — it was never safer, you just happened to open the right file.
And my earlier reasoning was doubly wrong: I told you 3.7.0 would work because it is signed, when the shim you were launching never was. The unsigned files are now #3288, along with a release-time check that would have caught this long before you hit it.
The part that may fix your original problem
If running
current\PerformanceMonitorLite.exestarts without the unknown-publisher block, you should also be able to run it without local administrator. That matters more than it sounds: being forced to run elevated is what breaks Microsoft Entra MFA with0x80070520, because an elevated process cannot reach your interactive sign-in session. So the Entra MFA option you originally reported may simply start working, with noaz loginand no IT involvement.Please try that first — plain Entra MFA, non-elevated, from
current\PerformanceMonitorLite.exe. If it connects, your original bug is solved and everything since has been my detour. If it still fails, theaz loginmode is there as the fallback and it is in this release.Hi Erik,
Tried to start it normally(without local administrator) but it gets blocked immediatly.Also tried to run it as local admin and it starts without blocking, used the new option for "Use existing az..." but still get a connection error when testing the connection as I should since there is not difference between the versions regarding that.
Attached is the latest .log file.
2 remaining items
- added 6 commits that reference this issue
on Sep 14, 2026 Claude posting for Erik Darling
There is now a third Azure option, and it is the one that should work regardless of which Windows account launches the app.
Azure — Device Code (browser on any device). Pick it in the Add Server dialog and press Test. A small window appears with a short code and a sign-in URL. Open that URL in any browser — this machine, your phone, whatever is convenient — type the code, and sign in exactly as you normally would, MFA included. The app never sees your password.
Why this should survive what the other two did not:
- It never asks the Windows account broker for anything, so the
0x80070520that Entra MFA hit cannot happen. That failure is the broker refusing to reach your sign-in session from an elevated process, and there is no broker in this path at all. - It reads no cached credential from any user profile, so it does not matter that
%USERPROFILE%is the admin account's when you launch elevated. That is why youraz loginwas invisible to the "Use existing Azure sign-in" option: the app was looking in the admin profile, and your token was in yours. There is nothing cached to find here — the code creates the credential on the spot, every time.
Two things to know before you try it:
- You have about three minutes from when the code appears. That limit comes from the SQL driver, not from us, and we cannot raise it. Have a browser tab ready.
- Closing the code window cancels the attempt and gives you the dialog back, so you are never stuck waiting.
Also: you can keep running elevated. Everything we have been trying to work around — the signing, the launcher, the profile — was in service of getting you non-elevated. This mode does not care. If it works, please stop fighting the elevation.
And please tell us what happens either way. Nobody here has an Entra tenant to test against, so you would be the first person to run this path. If it fails, the log line to look for starts with
[EntraDeviceCode]and will say whether the tenant issued a code at all — which is the one fact that splits "we could not reach your tenant" from "the sign-in did not complete in time".Your original report has now found three separate things: the unsigned launcher trap (#3288, fixed in 3.7.1), the
az login-under-elevation mode (#3214), and this. Thank you for staying with it.- It never asks the Windows account broker for anything, so the
Hi, Claude and Erik.
I tested version 3.7.1 Lite Portable and am still encountering a connection error.
Could not test with "Azure — Device Code (browser on any device)" but there is another option that I used "Azure — Existing Sign-In (az login").I suspect the issue is caused by launching the app under a local admin account (required by our internal IT policies). The error message indicates the app is attempting to authenticate with my standard Windows user account.
I ran "az login" and selected my Azure Admin account, which holds the necessary privileges for the Azure SQL databases that I need, but the connection still fails.
Maybe combing the new option with a input for the username?
If it helps:
Dono how Windows apps work but I have a Web App for running queries on multiple databases in Elastic pool.
I use "Microsoft.Data.SqlClient.SqlConnection" with a connectionstring like below and it works(I get a Web page for login name).
Server=tcp:somesqlserver.databse.windows.net,1433;Initial Catalog=aDatabaseInElasticPool;Persist Security Info=False;MultipleActiveResultSets=True;Encrypt=True;TrustServerCertificate=False;Authentication=Active Directory Interactive;Thanks for coming back with the exact setup details — the local-admin constraint is the whole story, and your suspicion is pointed at the right seam. The good news: your Azure permissions are fine, and nothing about the elastic pool matters here. This is purely about which Windows account owns which token cache.
Why "Existing Sign-In (az login)" fails for you specifically. That mode reads the token cache that
az loginwrites — and that cache lives in the Windows profile of the account that ran the command (%USERPROFILE%\.azure). Youraz loginalmost certainly ran in a shell owned by your standard Windows account, while IT policy launches the app under the local admin account. So the app looks in the admin's profile, finds no az sign-in there at all, and the credential chain falls through — which is why the failure surfaces mentioning your standard Windows account rather than the Azure Admin identity you picked in the browser. The account you choose in the browser lives inside the token; where the token is kept is decided by the Windows account, and those two never met.The immediate unblock: run
az loginas the same Windows account that launches the app. Open a prompt under that account —runas /user:<the local admin> cmd, matched to exactly how the app is launched — and runaz login --use-device-codethere (the device-code variant means that session never needs to open a browser; you complete sign-in on any device, picking your Azure Admin account). After that, the app's cache lookup and your sign-in are in the same profile, and Existing Sign-In should work as-is.On adding a username input — we looked at this and it's a documented dead end, not an oversight. On the az-login path, SqlClient forwards a
UserIDinto three different credential-source settings at once (managed-identity client id, shared-token-cache username, workload-identity client id) — a UPN typed there misconfigures two sources rather than acting as a hint. On the device-code path, the field never reaches the request at all; the browser asks who you are regardless. Your web app's connection string works becauseActive Directory Interactiveis a different flow — and on current desktop drivers that flow routes through the Windows account broker (WAM), which binds to the desktop session and is precisely what breaks under an elevated/cross-account process. That's the reason the Device Code mode exists.Which brings me to the thing I'd actually like to chase: you mentioned you could not test "Azure — Device Code (browser on any device)." That mode was built for exactly your situation — the process runs under an account that can't reach your browser session, so the app shows a code and you finish sign-in anywhere. What happened when you selected it — was the option missing, greyed out, or did it error? If the run-as-admin situation breaks the device-code window somehow, that's a real bug I want to know about, and your setup is the reproduction we couldn't manufacture ourselves.
If the
az login-under-the-right-account step doesn't unblock you, please paste the verbatim error text (redact your account names however you like) and we'll take it from there.One addition to make your next reply maximally useful: when Device Code mode fails or refuses, the app logs a line starting with
[EntraDeviceCode]— that line says whether your tenant issued a device code at all, which is the fork in the road diagnostically. If you can, when you get a chance to try that mode again:- paste the
[EntraDeviceCode]line(s) from the log, and - describe concretely what "could not test" looked like — option not in the dropdown, selectable but the code window never appeared, window appeared but closed, or a policy/error dialog.
"Not in the dropdown" and "window never appeared" are different bugs on our side; "tenant refused to issue a code" is a conditional-access policy on yours that we should document. Any of the three is worth knowing.
- paste the
Hi Erik,
Downloaded the 3.7.1 Portable , Unblocked the Zip and started teh App using "..current\PerformanceMonitorLite.exe".
I cant see the option "Azure — Device Code (browser on any device)" in the Add Server Dialog. Am I missing something?
Claude posting for Erik Darling
You're not missing anything — the option genuinely isn't in 3.7.1. I checked the release artifacts rather than guessing this time: "Azure — Device Code" was added after the 3.7.1 tag, so it exists only on our development branch and in the unsigned nightly builds — which are exactly the ones your IT policy blocks. So there is currently no signed release that contains it, and pointing you at it before it was in a build you can run was my mistake. It is built and merged; it will be in the next signed release, which is not immediate — a few other fixes are landing ahead of it. I'll follow up here the moment it ships, and you'd be the first person to confirm it against a real tenant.
In the meantime there is a path that works today, on the signed 3.7.1 Portable you already have running — no new download, nothing for your IT to unblock:
Azure — Service Principal (works now in 3.7.1)
This is the one mode that does not care which Windows account launches the app. It does not touch the Windows account broker (WAM) that fails under elevation with
0x80070520, and it does not read a cachedaz logintoken out of a user profile — so the fact that you launch Lite asadmmiutlacwhile youraz loginlanded in your normal profile stops mattering entirely. It authenticates with an app registration's client id + client secret directly.The cost is that it needs an Entra app registration in your tenant, which is where your IT comes in:
- Register an application in Entra ID (IT can do this in minutes) and create a client secret on it. Note the Application (client) ID and the secret value.
- Grant that app access to the database. In each target Azure SQL database, connected as an Entra admin:
(
CREATE USER [your-app-registration-name] FROM EXTERNAL PROVIDER; ALTER ROLE db_datareader ADD MEMBER [your-app-registration-name];db_datareaderplus VIEW-level permissions is enough for monitoring; your DBA can scope it.) - In Lite: Add Server → Authentication Azure — Service Principal → enter the Application (client) ID and the client secret, then the server and database as usual → Test Connection.
Because it's non-interactive, there's no account picker, no MFA prompt, and no dependence on your normal-vs-admin Windows account.
Or: az login, but run it as the admin account
If an app registration isn't easy to get, the "Existing Sign-In (az login)" mode you already tried can work — it just has to find the token in the profile of the account that launches Lite. Since your policy launches Lite as
admmiutlac, theaz loginhas to run asadmmiutlactoo:- Open a terminal running as
admmiutlac(e.g.runas /user:<the local admin> cmd, matched to how Lite is launched). az login --use-device-code— the device-code variant means that shell never has to open a browser; you complete sign-in on any device and can pick your Azure Admin account.az account showshould then print that account. Leave it signed in, start Lite the same way, and Test Connection with "Existing Sign-In (az login)".
The token cache lives under
%USERPROFILE%\.azure, so the only thing that ever mattered here is that the profile it's written to is the one Lite runs as.Summary
- Device Code — built, not yet in a signed release; coming in the next one (not immediate). I'll post here when it's out.
- Service Principal — works today in signed 3.7.1, account-independent, needs an app registration.
- az login — works today in signed 3.7.1, but only if
az loginis run as the sameadmmiutlacaccount that launches Lite.
Given your environment, Service Principal is the most robust of the three. Thanks for your patience through all of this — your report has already found the unsigned-launcher trap (#3288) and driven two new sign-in routes.
Hi Claude.
I guess this issue is resolved as far as you can take it.
I still have one issue and that is I start the App with local admin account admmiutlac but I log on to Azure SQL database with my Azure Admin account.To solve all issues for me I will add a SQL User with a strong password for Perfomancemonitor.
For me it´s ok to close this issue
Claude posting for Erik Darling
That's the right call for your setup, and it's the cleanest of all the options for exactly the reason the others fought you: a SQL user sidesteps the Windows-vs-Azure account question entirely. On Azure SQL Database, "SQL auth" is a contained database user with a password, created on the target database itself — Lite stores the password in Windows Credential Manager and connects with it directly, so it no longer matters which Windows account launches the app or which Azure identity you signed into. No WAM broker, no
az login, no profile mismatch.One thing to grant so you get data rather than empty tabs — the user needs read access to the monitoring DMVs. On each target database, connected as an admin:
CREATE USER [PerformanceMonitor] WITH PASSWORD = 'a-strong-password'; GRANT VIEW DATABASE STATE TO [PerformanceMonitor]; GRANT VIEW DEFINITION TO [PerformanceMonitor];VIEW DATABASE STATEis what lets thesys.dm_*DMVs return rows;VIEW DEFINITIONis what stopssys.tables/sys.indexesfrom returning zero rows to the index/object collectors (those catalog views hide rows rather than erroring without it). That's the full set for Azure SQL Database — the SQL Agent / msdb collectors are skipped automatically there.Closing this out per your note. Thank you for staying with it — your report was unusually good, and it directly produced the unsigned-launcher fix (#3288, signed from 3.7.1 onward) and two new sign-in routes:
az loginand Device Code. The Device Code mode lands in the next signed release, if you ever want an Entra path back without a SQL user. If anything about the SQL-auth setup snags, reopen and we'll pick it up.
Component
Lite
Performance Monitor Version
3.6.0
SQL Server Version
Microsoft SQL Azure (RTM) - 12.0.2000.8 Aug 19 2026 09:20:28 Copyright (C) 2026 Microsoft Corporation
Windows Version
Windows 11 Enterprice
Describe the Bug
Adding New server. setting connection parameters the same way I do in SSMS (see attached image).
I get a "Connection Failed" error (See Actual Behavior).
Steps to Reproduce
Expected Behavior
Expecting a connection to be established.
Actual Behavior
Error dialog:
Error Messages / Log Output
Screenshots
Connection dialog entry and settings.
Error dialog.
Additional Context
Attached SSMS Connection dialog that works.