Fallback from RPC_C_AUTHN_GSS_NEGOTIATE to RPC_C_AUTHN_WINNT if no SPNEGO package available

[Stefan Kuhr]

Hello rob,

On 7/2/08, Rob Shearman <robertshearman at gmail.com> wrote:
> <snip>
> That may be so, but it won't work for servers that only register the
> RPC_C_AUTHN_GSS_NEGOTIATE authentication scheme. So the patch should
> include a FIXME to warn users about this. Otherwise, the patch is
> fine.

Good to hear you think the patch could be accepted with a minor
modification. However, with "servers that only register the
RPC_C_AUTHN_GSS_NEGOTIATE authentication scheme", do you refer to an
RPC server that makes a single call to RpcServerRegisterAuthInfo(..,
RPC_C_AUTHN_GSS_NEGOTIATE,...)? If so, I assume you are wrong: I just
made a test between two XP boxes in a non-domain environment and the
server did a single call to RpcServerRegisterAuthInfo with
RPC_C_AUTHN_GSS_NEGOTIATE. The client successully invoked an RPC on
the server after having called RpcBindingSetAuthInfoEx with
RPC_C_AUTHN_GSS_NEGOTIATE. However, if I change the server's code so
it makes a single call to RpcServerRegisterAuthInfo with
RPC_C_AUTHN_GSS_KERBEROS, the client fails with 1747
(RPC_S_UNKNOWN_AUTHN_SERVICE), but not in the call to
RpcBindingSetAuthInfo but instead as the return value from the RPC
that it calls immediately after RpcBindingSetAuthInfo.

So I think, it is not the responsibility of RpcBindingSetAuthInfoEx at
this point to deal with a server only accepting Kerberos or Negotiate.
Without knowing really too much how Windows actually implements this,
my guts tell me that this is then the server's responsibility to
reject a connection during the SSPI handshake which in WINE's code
immediately follows the code that my patch would insert into
RpcBindingSetAuthInfoEx.

What do you think?

Cheers,

-- 
Stefan