I have also run into this issue running Heimdal 1.0 and fbopenssl 0.0.4 for GSSAPI and SPNEGO support. I want to support Negotiate against an IIS6 server using Integrated Windows Authentication that instead of allowing "NTLM" or "Negotiate,NTLM" has the NTAuthenticationProviders set to "Negotiate". Negotiate can negotiate to Kerberos or NTLM.
 
Specifying CURLOPT_USERPWD does not seem to work for Negotiate. Only the default cached credential which if not present will cause gss_init_sec_context() to fail on opening KRB5CCNAME environment variable file (defaults to /tmp/krb5cc_%d where %d is a generated number). An error message is printed about this in verbose mode. This does not make great sense because KRB5 has not even been negotiated yet and NTLM/KRB4 could still be chosen...
 
Question: Why are there no SPNEGO verbose messages when the code for this is right above the code that spits out the gss_init_sec_context() error (cURL -V shows SPNEGO and GSSAPI support) and should always generate a success or fail message? Also should SPNEGO build the credentials for GSSAPI?
 
Do I even need SPNEGO for what I am doing or is SPNEGO only needed for getting current credentials of the running user (not for building credentials based on arbitrary CURLOPT_USERPWD)? My main confusion is what and why SPNEGO is needed for.
 
I just want to make sure I am bumping into an unimplemented feature as opposed to a bug since I read nowhere that CURLOPT_USERPWD does not work with Negotiate/SPNEGO but based on discussion this might be known. If it is a bug I will provide test server and scripts (same ones I provided the other day in fact, there are no changes just make sure to link cURL with Heimdal 1.0 and fbopenssl 0.0.4).
 
Thanks,
 
-Greg
_________________________________________________________________
Local listings, incredible imagery, and driving directions - all in one place! Find it!
http://maps.live.com/?wip=69&FORM=MGAC01
Received on 2007-08-02