Use of -u : in Windows builds of curl with WinLDAP and SSPI

[jay]

In #22196 I am proposing to restore the old behavior of empty username and password for builds of curl with WinLDAP support, which is to send those empty credentials to the server (when default basic authentication). However, I notice it is documented that builds of curl with SSPI support have a special meaning of -u : to send the "environment" credentials for some types of authentication, as described in the doc:

If you use a Windows SSPI-enabled curl binary and perform Kerberos V5, Negotiate, NTLM or Digest authentication then you can tell curl to select the username and password from your environment by specifying a single colon with this option: "-u :".

For builds of curl with WinLDAP and SSPI support, AFAICT it does not do this. Wireshark:

NTLM Secure Service Provider
    NTLMSSP identifier: NTLMSSP
    NTLM Message Type: NTLMSSP_NEGOTIATE (0x00000001)
    Negotiate Flags: 0xa2088207, Negotiate 56, Negotiate 128, Negotiate Version, Negotiate Extended Security, Negotiate Always Sign, Negotiate NTLM key, Request Target, Negotiate OEM, Negotiate UNICODE
    Calling workstation domain: NULL
    Calling workstation name: NULL

I do not have a LDAP test server to test this type of authentication though I tried in a VM. If something other than basic auth is specified (like --negotiate -u : then curl ldap_win_bind calls ldap_win_bind_auth which uses the empty credentials, rather than I think it should be using the user's default credentials? In the below code you can see, that for example if the method is set to LDAP_AUTH_NEGOTIATE with an empty username and password then the SSPI identity is created from that.

curl/lib/ldap.c

Lines 187 to 202 in 68720b4

	if(method && user && passwd) {
	CURLcode result = Curl_create_sspi_identity(user, passwd, &cred);
	if(!result) {
	rc = ldap_bind_s(server, NULL, (TCHAR *)&cred, method);
	Curl_sspi_free_identity(&cred);
	}
	else {
	rc = LDAP_NO_MEMORY;
	}
	}
	else {
	/* proceed with current user credentials */
	method = LDAP_AUTH_NEGOTIATE;
	rc = ldap_bind_s(server, NULL, NULL, method);
	}
	return rc;

So what I do not understand is whether this is a bug or not. It seems to me that if -u : is special for SSPI then it should be using that else block to let Windows negotiate with the user's default credentials:

Or, in other words, if it's a bug this should fix it.

diff --git a/lib/ldap.c b/lib/ldap.c
index ae12727..a1b420f 100644
--- a/lib/ldap.c
+++ b/lib/ldap.c
@@ -184,7 +184,7 @@ static ULONG ldap_win_bind_auth(LDAP *server, const char *user,
     /* required anyway if one of upper preprocessor definitions enabled */
   }
 
-  if(method && user && passwd) {
+  if(method && user && passwd && (user[0] || passwd[0])) {
     CURLcode result = Curl_create_sspi_identity(user, passwd, &cred);
     if(!result) {
       rc = ldap_bind_s(server, NULL, (TCHAR *)&cred, method);

Since there is no testing on this, and I don't have authentication to actual LDAP servers I can't be 100% about this. If I'm wrong let me know and if not I'll open a PR.