Re: Fallback from RPC_C_AUTHN_GSS_NEGOTIATE to RPC_C_AUTHN_WINNT if no SPNEGO package available
2008/7/1 Stefan Kuhr <winesku(a)googlemail.com>:
Hello everyone,
Hi Stefan, Thank you for your contribution.
please find attached a patch for Bug #14222 (which I just submitted to bugzilla). I think that this patch is not a hack, because even if someday a Negotiate package is available in WINE, this code won't break the Negotiate package.
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.
Oh, and there was no rpcrt4 component to be selected for this bug in bugzilla, you might consider to add one.
Currently, we are using the "ole" component for RPC bugs, including rpcrt4 and widl, but I agree that this isn't clear. I think we should probably split the ole component up into rpc (which would be a container for rpcrt4 & widl issues), ole32 and oleaut32.
Please let me know if I did something obvious wrong since this is the first time I submit a patch to WINE.
-- Rob Shearman
Hello rob, On 7/2/08, Rob Shearman <robertshearman(a)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
2008/7/2 Stefan Kuhr <winesku(a)googlemail.com>:
Hello rob,
On 7/2/08, Rob Shearman <robertshearman(a)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?
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
Hi Rob, On Wed, Jul 2, 2008 at 11:51 PM, Rob Shearman <robertshearman(a)gmail.com> wrote:
<snip> 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.
Ok, I'll do that and resend the modified patch. It probably also needs a fixme for an entire different reason: Once a Negotiate provider is available in WINE, my patch won't do any harm, but it is going to be dead code that can be removed then. Cheers, -- Stefan
Hi Rob, On Thu, Jul 3, 2008 at 10:20 AM, Stefan Kuhr <winesku(a)googlemail.com> wrote:
<snip> Ok, I'll do that and resend the modified patch. It probably also needs a fixme for an entire different reason: Once a Negotiate provider is available in WINE, my patch won't do any harm, but it is going to be dead code that can be removed then.
I already sent a revised patch to the patch mailing list a week ago. Do you think that one is now acceptable? Cheers, -- Stefan Kuhr
participants (2)
-
Rob Shearman -
Stefan Kuhr