Disabling completely username, worked.

[johnkaku]

Disabling completely username, worked.
However disabling only on proxy and kipping enabled does not work, why?

Is there any way to configure the dataverse client to log verbosely the responses and requests to/from ADFS for debugging?

Originally posted by @johnkaku in #8 (comment)

[MarkMpn]

I'm not sure what you're asking here. In what way did you disable a username?

When using claims-based authentication, the client doesn't create the requests to ADFS directly but uses the WCF classes instead. If you're hitting problems during the ADFS authentication phase you might be better off looking at the event logs on the ADFS server itself for details.

[YechielLeader]

For us as well, Disabling the username endpoint completely solved the issue, but we are still not sure why the client try to connect to username endpoint using http, while the entire endpoints are configured https...

Also, if it try to connect using HTTP why would it fail if its reachable? Any debugging "utility" you can recommend or is it just Event viewer?

[MarkMpn]

I haven't seen the error message so I'm not really sure what problem you're having.

The client gets the ADFS details from the CRM WSDL - see

DataverseClient/Data8.PowerPlatform.Dataverse.Client/OnPremiseClient.cs

Line 233 in 8dc1083

private ClaimsBasedAuthClient ConnectFederated(string url, ClientCredentials credentials, List<Policy> policies)

This method loads the ADFS metadata to find the endpoint to use - I'd start off debugging through that method to identify the URLs that are being reported from the metadata and identify any that are incorrect.

[YechielLeader]

I got to this thread from here,
#8

This is the error:
Unhandled exception. System.ArgumentException: The provided URI scheme 'http' is invalid; expected 'https'. (Parameter 'via')

AD FS exposes two different “username/password” WS-Trust styles:

.../trust/2005/username
This is the “username” WS-Trust binding that uses WS-Security message security (SOAP-level signing/encryption). Historically, AD FS advertises this endpoint as HTTP in MEX/WSDL, because the security is expected to be on the SOAP message, not on the transport.

.../trust/2005/usernamemixed
This is the “mixed mode” binding (TLS transport + message credential). This one is advertised as HTTPS, and is the one many modern clients prefer/require.

Why do we need to disable username endpoint in adfs instead of the dll being able to utilize usernamemixed if username is http? or by default that is.

[YechielLeader]

Anything? :(

[MarkMpn]

I don't have access to an environment which exhibits this behaviour so I can't diagnose it directly. If you can debug through the method I mentioned previously you might be able to contribute a PR to resolve it.