ODATA Feed : credentials error

[G_CR_23]

Hi everyone,

I'm facing a classic but stubborn authentication issue with an on-premises OData feed from Dynamics 365 Business Central. I hope someone can confirm my findings.

The Setup:

• Data Source: Business Central On-Premises OData Feed (http://<servername>:<port>/...).

• Connectivity: Requires a VPN connection.

• Power BI Desktop: Works perfectly. I can connect, refresh data, and credentials (Basic authentication) are accepted.

• Power BI Service: Fails consistently.

The Problem:
When I publish the semantic model and try to configure the credentials in the Power BI Service (mapped to a gateway), I always receive an "Invalid Credentials" error.

What I've Tried (Exhaustively):

1. Gateways: I've tried both a Personal Gateway and a Standard Gateway installed on a machine that has direct access to the OData feed via VPN. The result is the same.

2. Credentials: I've tried every possible username format (user, domain\user, user@domain.com) with both Basic and Windows authentication methods.

3. Troubleshooting: I've cleared permissions in Desktop, cleared the cache, tried from a clean PBIX file, and even used the Web connector instead of OData—the error is always the same.

The Key Finding (Fiddler Analysis):
After all the failed attempts, I ran a Fiddler trace and this has confirmed the root cause.

• Power BI Desktop (Successful Request): Sends an Authorization: NTLM TlRMTVNTUA... header. The server accepts it.

• Power BI Service via Gateway (Failed Request): Sends an Authorization: Bearer eyJ0eXAiOiJKV1Qi... header (an Azure AD JWT token). The server rejects this, leading to the "Invalid Credentials" error.

My Conclusion / The Question:
My diagnosis is that the on-prem Business Central server is only configured to accept Windows Authentication (NTLM/Kerberos), and it cannot process the Azure AD token sent by the Power BI service.

This leads me to believe that the only solution is to have our IT department configure a Standard Gateway with Kerberos Constrained Delegation (KCD) to allow the gateway service to impersonate the user and perform a Kerberos/NTLM authentication against the BC server.

Can anyone with experience in this specific scenario confirm if my conclusion is correct? Is requesting IT to set up KCD the definitive and only way forward, or are there any other workarounds I might have missed?

Thanks in advance for your help!

[V-yubandi-msft]

Hi @G_CR_23 ,

We are still waiting for your update on the reported issue. Please let us know if it has been resolved or if you need any further help from us.

Thank you.

[G_CR_23]

Hi @V-yubandi-msft , @Ritaf1983  thank you for your precious answer.

Fortunatelly, IT provides me another url endpoint where i can access with basic access, in power bi desktop and also in pwoer bi service. This allows me to configure a normal gateway in personal mode and just only insert basic credentials in the connection configuration.

So, if anyone has my same problem, ask your it if they can provide you an url endpoint where you can access with basic credentials. In this way, you resolve your problem. On the contrary yes, kerberos delegation is the only way to configure it.

Thank you!

[V-yubandi-msft]

Thank you for your response and for sharing the workaround. It’s truly appreciated and will be helpful for others experiencing similar challenges.

Looking forward to your continued participation in future community discussions.

[V-yubandi-msft]

Hi @G_CR_23 ,

@Ritaf1983 , has correctly pointed out the issue and shared a few steps to follow. Have you tried those steps, and did they help? If you are still facing any issues or need additional information, please let us know

Thanks for your valuable response @Ritaf1983  .

Regards,

Yugandhar.

[Ritaf1983 · Accepted solution]

Hi @G_CR_23 

You're spot on—your Fiddler trace caught the exact root cause. The "Invalid Credentials" error isn't about the wrong password; it's an authentication protocol mismatch.

The Diagnosis
You are 100% correct. Power BI Desktop works because it uses your local Windows session (NTLM) via the VPN. However, the Power BI Service is a cloud-native entity. When it talks to your Gateway, it passes an Azure AD Bearer token (JWT). Your on-prem Business Central server, which is expecting a Windows-based challenge (NTLM/Kerberos), simply doesn't know what to do with a cloud token, so it rejects the request.

The Solution: Kerberos Constrained Delegation (KCD)
Requesting IT to set up KCD on a Standard Gateway is indeed the definitive and most professional way forward. It acts as the "translator" between the cloud and your local domain.

What IT needs to do:

SPNs: Ensure Service Principal Names (SPNs) are correctly registered for the account running the Business Central service.

Delegation: Configure the Gateway service account in Active Directory to "Trust this user for delegation" to the BC service.

SSO settings: Once the AD work is done, you’ll need to tick the "Use SSO via Kerberos for OData queries" box in the Gateway cluster settings in Power BI.

Are there workarounds?
If your IT department pushes back on KCD (which happens often due to the complexity of AD configurations), you have one "Plan B":

Web Service Access Key (Basic Auth): In Business Central, you can generate a specific "Web Service Access Key" for your user. In the Power BI Service, you can then switch the authentication method to Basic and use that key as the password. It bypasses the NTLM handshake entirely.

Note: This is less secure and many modern IT policies are deprecating Basic Auth, so KCD remains the superior choice.

Verdict: Your conclusion is solid. KCD is the "right" way to handle identity flow from the cloud to an on-prem OData feed. Stick to your guns with IT.

If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly