MACOS fails with --proxy-negotiate or --proxy-ntlm while windows succeed.

[lisalisal]

I did this

I setup a wingate proxy server in a windows server which join our domain, and the proxy server enables negotiate and NTLM authentication.
I have a windows machine which also join domain, and run following commands, both succeed.
'curl --proxy proxy-server-address:port https://connection-server-address:443 --proxy-negotiate --proxy-user : -v'
'curl --proxy proxy-server-address:port https://connection-server-address:443 --proxy-ntlm --proxy-user : -v'

Attached the windows curl output for both '--proxy-negotiate' and '--proxy-ntlm', it worked as expected.
'curl --proxy proxy-server-address:port https://connection-server-address:443 --proxy-negotiate --proxy-user : -v'

'curl --proxy proxy-server-address:port https://connection-server-address:443 --proxy-ntlm --proxy-user : -v'

But in macos, my mac machine also join the same domain, I login machine with a domain user, but when run following curl commands, both failed with a 2nd ' 407 Proxy Authentication Required', where above windows returns 'HTTP/1.1 200 Connection established', in macos, it returns a 2nd ' 407 Proxy Authentication Required', then the authentication failed.
Attached the mac curl output for both '--proxy-negotiate' and '--proxy-ntlm', it failed.
'curl --proxy proxy-server-address:port https://connection-server-address:443 --proxy-negotiate --proxy-user : -v'

'curl --proxy proxy-server-address:port https://connection-server-address:443 --proxy-ntlm --proxy-user : -v'

I expected the following

I expect in macos, with same curl command, the proxy authentication should return '200 Connection established'.

curl/libcurl version

MAC output for 'curl --version'
curl 8.7.1 (x86_64-apple-darwin23.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.61.0
Release-Date: 2024-03-27
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL threadsafe UnixSockets

Windows output for 'curl --version'
curl 8.7.1 (Windows) libcurl/8.7.1 Schannel zlib/1.3 WinIDN
Release-Date: 2024-03-27
Protocols: dict file ftp ftps http https imap imaps ipfs ipns mqtt pop3 pop3s smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM SPNEGO SSL SSPI threadsafe Unicode UnixSockets

operating system

MACOS 14.6.1 (23G93)

[icing]

That sounds tricky to analyze. Is 8.7.1 also the curl version on Windows that succeeds?

[lisalisal]

Yes, windows curl version is also '8.7.1'.

For MAC machine, I just join the domain, and logged with domain user, and I check the 'klist', there is valid credential. And didn't do other configurations on macos.

Proxy server is in the same domain.

In this case, should curl do the proxy authentication successfully with following curl command ? I am afraid I miss some configurations on macos.
'curl --proxy proxy-server-address:port https://connection-server-address:443 --proxy-negotiate --proxy-user : -v'
and
'curl --proxy proxy-server-address:port https://connection-server-address:443 --proxy-ntlm --proxy-user : -v'

[icing]

Windows domain authentication is beyond my knowledge. curl seems to obtain a token from the local host (gssapi/kerberos, I assume?) for answering the server's challenge, which is not accepted by your proxy. This points to a failing in the macOS domain setup, but I am not sure.

[pkropachev]

@lisalisal, could you check logs of WinGate? Why does WinGate reject HTTP CONNECT (response to NTLM challenge) came from Mac? Perhaps logs contain some useful information.

[michael-o]

Man (@lisalisal), Kerberos relies on hostnames and SPN, not IP addresses this is why it fails for you and falls back to NTLM. Fix your setup and macOS Heimdal will be able to obtain a service ticket for your HTTP (!) proxy server.