kerberos authentication with neon 0.29.3

Danil Shopyrin danil at visualsvn.com
Thu Mar 18 14:45:08 EDT 2010


Hi All!

> Thanks for that.  Yes, I presume it's Danil's change to stop sending the
> SSPI token which causes the issue here.
>
> Danil: the issue you saw with resending the SSPI token, was that only
> with an NTLM exchange, or a Negotiate exchange?  It doesn't really make
> sense to be resending the SSPI token in either case, but clearly it's
> making a difference somehow.

We're looking into this issue.

> I notice that the SSPI code does not
> process the server's response token in the 2xx response as the GSSAPI
> code; maybe this is the issue but I can't fathom how.

Thanks for notice.

> We could do something like this which partially reverts the behaviour:
>
> Index: src/ne_auth.c
> ===================================================================
> --- src/ne_auth.c       (revision 1792)
> +++ src/ne_auth.c       (working copy)
> @@ -1468,8 +1468,8 @@
>  #endif
>
>  #ifdef HAVE_SSPI
> -    /* whatever happens: forget the SSPI token cached thus far */
> -    if (sess->sspi_token) {
> +    /* For an NTLM exchange: forget the SSPI token cached thus far */
> +    if (strcmp(sess->protocol->name, "NTLM") == 0 && sess->sspi_token) {
>         ne_free(sess->sspi_token);
>         sess->sspi_token = NULL;
>     }

This change can avoid the problem. But I think it will be better to
process 2xx response just like the GSSAPI does.

I hope we will be able to provide an appropriate patch in the
beginning of the next week.

-- 
With best regards,
Danil Shopyrin
VisualSVN Team



More information about the neon mailing list