Hi,

Please avoid top-posting, it make sit hard to follow.
See etiquette link below.

On Wed, Nov 30, 2016 at 5:22 PM, Lutfi Dwedari <lutfi.dwedari_at_pds.nl> wrote:
>
> Hi again.
>
> I implemented a setting to indicate that I want to persist the connection on the next perform call. I see that connection is persisted but libcurl does not send an Authenticate header, so basically the server returns a not authorized forcing to negotiate again.

Yes, that's because negotiate always probes without auth headers (a
bug in my opinion).

> Can this be overcome?

Not easy to solve, you can search the mailing list and pull requests
about negotiate issues to get a better idea.
Perhaps, if you are on linux, you might be better off issuing the
authentication blob yourself with gss_init_sec_context and adding it
to each request.

> -----Original Message-----
> From: Lutfi Dwedari
> Sent: 30 November 2016 11:57
> To: libcurl development
> Subject: RE: Kerberos connections are not left open
>
> Hi Isaac:
>
> This is the sequence of messages:
>
> > POST /service/authenticate HTTP/1.1
> > Host: xxx.xxx.xxx.xxx
>
> < HTTP/1.1 401 Unauthorized
> < Server: Apache-Coyote/1.1
> < WWW-Authenticate: Negotiate
>
> > POST /service/authenticate HTTP/1.1
> > Host: xxx.xxx.xxx.xxx
> > Authorization: Negotiate YIIULAYGK...
>
> < HTTP/1.1 401 Unauthorized
> < Server: Apache-Coyote/1.1
> < Set-Cookie: JSESSIONID=k8TXA...; Path=/xxx; Secure
>
> > POST /service/authenticate HTTP/1.1
> > Host: xxx.xxx.xxx.xxx
> > Authorization: Negotiate oYIT8z...
>
> < HTTP/1.1 200 OK
> < Server: Apache-Coyote/1.1
> < Set-Cookie: JSESSIONID=BEmL....; Path=/recall; Secure
> < WWW-Authenticate: Negotiate oW0wa6JpB...
>
> There are three exchanges. Not sure if it is being using Ketberos or NTLM based on the last WWW-Authenticate reply that starts with oW0 instead of YII. At the other hand the second message do include start with YII (Kerberos). Do you think is it NTLM?

Looks like NTLM, those are base64 encode of mostly binary blobs, best
viewed with wireshark dissectors.

> I understand that libcurl does not have a way to know whether it should keep a connection open. Would it be handy to add yet another setting to let the client to keep the connection open?

Maybe, but the hope was that we fix negotiate code to query the gss
credentials for the username and use that information to reuse the
connection and to understand what underlying mechanism is used to
behave accordingly (although we could silently deprecated such option
when we fix negotiate properly).

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-11-30