Hello rob,
On 7/2/08, Rob Shearman robertshearman@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,