Power BI Desktop Login Failure - "Connection to the service was prematurely closed"

[IsaacT]

Hi, I am experiencing a persistent sign-in issue with Power BI Desktop on a corporate/municipal network. When attempting to sign in, I receive the following error message:

"Unable to sign in. An error occurred while contacting the service (the connection to the service was prematurely closed). Please contact your IT administrator if this issue persists."

Environment Details:

• Application: Power BI Desktop (Version: 2.154.956.0 64-bit - May 2026)

• OS: Windows 11

• Network: Corporate network behind a firewall/proxy.

Issue Description & IT Findings: Our IT department investigated the issue and monitored the network traffic. They confirmed that the outbound login request is successfully sent to the authentication servers. However, the connection drops prematurely when the system attempts to read the authentication token back to the application.

Troubleshooting Steps Already Taken (Without Success): To rule out local application issues, we have already performed the following steps:

1. Verified that TLS 1.2 is enabled in the Internet Options.

2. Cleared the WebView2 / CEF cache  folders.

3. Changed the Authentication Browser setting in Power BI Desktop Options from the internal browser to "Use my default web browser".

4. Verified with IT that the standard Microsoft authentication endpoints are reachable, yet the handshake fails specifically for Power BI Desktop.

Since the standard workarounds (clearing cache and switching the authentication browser) did not resolve the issue, it appears to be a deeper protocol or network handshake conflict with the internal Power BI Desktop authentication mechanism.

Could you please advise on what specific endpoints, ports, or certificate pinning exclusions our IT needs to configure on the firewall to prevent this premature drop? Alternatively, are there any specific Registry Keys or Environment Variables (like proxy bypassing) that can force Power BI to accept the returning token properly in this environment?

Thank you in advance for your assistance.

[v-aatheeque]

Hi @IsaacT 

Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.

[v-aatheeque]

Hi @IsaacT 

We wanted to follow up to check if you’ve had an opportunity to review the previous responses. If you require further assistance, please don’t hesitate to let us know.

[Kagiyama_yutaka]

Turning on PBI Desktop → Options → Diagnostics → Enable tracing. The log from that will let IT see which PBI and MS365 sign‑in endpoints on port 443 need to go through without inspection. It also shows where the TLS inspection or the OAuth redirect is getting dropped, so they can track down the exact point.

[Kedar_Pande]

@IsaacT 

For the registry workaround, try forcing MSAL auth by adding this DWORD:

HKEY_CURRENT_USER\Software\Microsoft\Microsoft Power BI Desktop
EnableMSALAuth = 1

If this answer helped, please click 👍 or Accept as Solution.
-Kedar
LinkedIn: https://www.linkedin.com/in/kedar-pande

[Ghrieb]

Hey, That's almost always one of two things: proxy not passing default Windows credentials back to the app, or TLS inspection breaking the auth token on the way back.

Steps:

1. Registry fix for proxy credential passthrough (most likely the culprit)

2. Firewall/proxy allowlist — three domains IT must whitelist
- app.powerbi.com - api.powerbi.com - *.analysis.windows.net (wildcard — all subdomains) Port: TCP 443 only. No need to open anything else for authentication.

3. Check for TLS inspection / certificate interception
Ask IT to explicitly exclude those three domains above from SSL/TLS deep inspection, not just allow the TCP connection.
4. Enable tracing to confirm the exact error

Check the Full official troubleshooting reference from Microsoft if IT wants the source :
learn.microsoft.com/en-us/power-bi/connect-data/desktop-troubleshooting-sign-in/?wt.mc_id=studentamb... 

Good luck!

[oussamahaimoud]

Hi @IsaacT,

Hope you're doing well!

According to the description, I think the root cause is a firewall performing TLS inspection (SSL interception) that breaks the WebView2/MSAL token redirect, or a proxy that does not pass the authentication response back intact. It is not a missing endpoint; it's a broken return path.

So, you should disable TLS inspection on Auth Endpoints. Why ? This is the most likely fix given the symptom description. Corporate next-gen firewalls (Palo Alto, Zscaler, Fortinet, etc.) performing deep SSL inspection will break the OAuth2 token response because the WebView2 component inside Power BI Desktop validates the certificate chain natively. When the firewall re-signs the certificate with its own CA, WebView2 sees a chain mismatch and drops the connection.

IT action required: Create a SSL/TLS inspection bypass rule (also called "decryption exclusion" or "SSL offload exemption") for:

login.microsoftonline.com

login.microsoft.com

aadcdn.msauth.net

sts.windows.net

These must pass through end-to-end without interception, not just allowed, but excluded from re-encryption.

If a proxy is also swallowing the response, please register the key :

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft Power BI Desktop]

"UseDefaultCredentialsForProxy"=dword:00000001

Hope this helps! Don't forget to accept as solution ✅ and give kudos 👍 in order to keep helping others.

Best regards,

Oussama (Data Consultant - Expert Fabric & Power BI)

[trivedisunita]

Hi  ,The premature token drop in Power BI Desktop sign‑in is almost always caused by firewall/proxy restrictions on Microsoft authentication endpoints or certificate trust issues. Since you’ve already tried TLS, cache clearing, and browser switching, the next you can try to configure network rules-

Whitelist these endpoints (HTTPS only):

• app.powerbi.com

• api.powerbi.com

• *.analysis.windows.net

• login.microsoftonline.com

• aadcdn.msftauth.net

  Allow ports:

  • TCP 443 (HTTPS) must be open for all above domains.

    Ensure no SSL inspection or packet rewriting is breaking the handshak.

    Certificates:

    • Trust Microsoft root and intermediate CAs.
    • Disable deep packet inspection for these endpoints if your proxy re‑signs certificates.

      Proxy bypass:

      • Add exclusions for the domains above in Internet Options → LAN Settings → Advanced.

        Environment variable option: PBI_EnableProxyBypass=true (forces bypass for trusted endpoints).

        Validation:

        • Run a Fiddler trace during sign‑in to confirm the token response is reaching the client.

        • If the drop occurs after the redirect, it’s usually SSL inspection or proxy authentication interfering.

          If the issue persists after whitelisting and bypassing proxy inspection, the only reliable workaround is to test sign‑in outside the corporate firewall, capture a trace, and escalate with Microsoft Support using those logs. This ensures the root cause (SSL inspection, proxy auth, or certificate pinning) is identified and resolved.

          Next You can check-

          • if all network and client fixes fail, open a support ticket with Microsoft. Provide the Fiddler trace and IT’s firewall logs.

          • Microsoft can confirm if a certificate pinning or token replay issue is specific to your tenant.

            If this helped, a kudos would mean a lot! It encourages me contribut continously and keeps the community strong.

            Thank You

            Sunita

@IsaacT

[krishnakanth240]

Hi @IsaacT 

Can you check whether a web proxy, firewall, or endpoint security solution is terminating OAuth redirect flow before token is returned to Power BI Desktop. 

Try signing in from a different network like mobile hotspot if it succeeds that would indicate corporate network issue rather than Desktop bug