2008/7/2 Stefan Kuhr <[EMAIL PROTECTED]>: > Hello rob, > > On 7/2/08, Rob Shearman <[EMAIL PROTECTED]> 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?
Interesting analysis and I'm sure you're right. However, the patch is still making up for a deficiency in another piece of code so it either needs a FIXME comment or a fixme to be printed to the debug log. -- Rob Shearman