Posted on 17/11/2025 16:33:59
Hi
A quick one from the GPT. See if this gives you any pointers:
That error message is a sly little chameleon — it looks like a Windows authentication (Kerberos/NTLM) negotiation issue, but in a BC/Dynamicweb context it usually points to something far simpler: the request isn’t using Basic authentication at all, even though you think it is.
Let’s walk through this step by step and untangle the likely culprits.
🔍 What the error really means
The BC SOAP/OData endpoints for OnPrem do not use Negotiate/NTLM unless you explicitly run them in Windows authentication mode.
Dynamicweb Connector only supports Basic authentication against BC OnPrem.
If the server responds with:
…then BC is telling you:
“I didn’t receive a valid Authorization header. So I’m falling back to Windows auth.”
This happens when your tester sends a request without any Basic Auth header — usually because the authentication is not correctly set up.
🧩 Why your Tester Tool seems to "ignore" the secret
This is actually the biggest clue.
If the Tester Tool:
…that means:
➤ Your Tester Tool never sends Basic authentication at all
Which is typically because one of these is true:
-
The wrong BC URL is used → calling the normal web client URL instead of the SOAP or OData service endpoint.
-
BC is configured for Windows authentication instead of NavUserPassword.
-
The web.config of BC still has Windows as enabled auth instead of NavUserPassword.
-
The username is not provided in the correct form for BC OnPrem Basic Auth.
🧪 Things to verify (the practical checklist)
1. Check the BC authentication mode
On the BC server, open:
C:\inetpub\wwwroot\BC190\Web.config (path may differ)
Find the <authentication> section.
You should see NavUserPassword, like:
If it says Windows, BC will respond with Negotiate → and reject Basic auth.
2. Use the correct BC service URL
For SOAP, should look like:
For OData:
If you accidentally point to:
then BC serves the web client → and uses Windows auth → → → Negotiate error.
3. Ensure the username format is correct
BC OnPrem requires:
or
even when using NavUserPassword.
If the username is provided as simply “username”, BC will not generate a Basic auth header.
4. Check if SSL offloading is altering the headers
Some load balancers, proxies, or reverse proxies strip Authorization headers unless explicitly allowed.
This leads right back to the Negotiate error.
🧠 Why the Connector Service works differently than your local Tester Tool
Your local Tester Tool can access BC directly, likely inside the LAN or VPN.
The Connector Service sits in the Dynamicweb App Pool on the website — and uses a different security context and network routing.
If BC is expecting Windows authentication, the web app pool identity won’t match, and BC will fall back to Negotiate → unauthorized.
🎯 The most likely fix
Given all the symptoms, the strongest candidate is:
👉 BC is running in Windows authentication mode
and therefore refuses Basic Auth, so both the Tester Tool and Connector never send your credentials.
Switch to NavUserPassword authentication in Web.config
and restart IIS:
Then retest.
✨ A final little sanity check
Open a browser in Incognito mode and manually hit the BC SOAP endpoint:
If the browser triggers a Windows auth popup, you have Windows authentication active → the connector won't work until changed.
