[01/10] secur32: Implement AcquireCredentialsHandle for Kerberos.
dmitry at baikal.ru
Thu Oct 19 10:57:31 CDT 2017
Hans Leidekker <hans at codeweavers.com> wrote:
> On Mon, 2017-10-16 at 17:55 +0800, Dmitry Timoshkov wrote:
> diff --git a/wine/dlls/kerberos/kerberos.spec b/wine/dlls/kerberos/kerberos.spec
> > diff --git a/wine/dlls/kerberos/kerberos.spec b/wine/dlls/kerberos/kerberos.spec
> > index d277cee..e92516f 100644
> > --- a/wine/dlls/kerberos/kerberos.spec
> > +++ b/wine/dlls/kerberos/kerberos.spec
> > @@ -1 +1,3 @@
> > @ stdcall SpLsaModeInitialize(long ptr ptr ptr)
> > +@ stdcall InitSecurityInterfaceA()
> > +@ stdcall InitSecurityInterfaceW()
> The Windows 10 version doesn't export these functions. It does export a
> SECPKG_USER_FUNCTION_TABLE via SpUserModeInitialize but that doesn't give
> us everything we need.
dlls/schannel stub in Wine has the same problem.
I guess that George Popoff (the author of this code) added these exports
to make Wine SSP loader work. I have to admit that I haven't verified
this part of the code myself against kerberos.dll in Windows, and assumed
that Wine SSP loader code does the correct thing. Please give me a bit of
time to investigate this matter once again.
> > diff --git a/wine/loader/wine.inf.in b/wine/loader/wine.inf.in
> > index 787ad7f..0a9f8c3 100644
> > --- a/wine/loader/wine.inf.in
> > +++ b/wine/loader/wine.inf.in
> > @@ -683,6 +683,8 @@ HKLM,Software\Policies,,16
> > HKLM,Software\Registered Applications,,16
> > HKLM,System\CurrentControlSet\Control\hivelist,,16
> > HKLM,System\CurrentControlSet\Control\Lsa\Kerberos,,16
> > +HKLM,System\CurrentControlSet\Control\Lsa\Kerberos,,16
> > +HKLM,System\CurrentControlSet\Control\SecurityProviders,"SecurityProviders",,"kerberos"
> I don't see "kerberos" listed under SecurityProviders. There's just one
> entry called "credssp" on Windows 7 and 10.
There is no msv1_0 (NTLM provider) there either, probably Windows loads
them from the Control\Lsa key.
> So I'm inclined to keep the Kerberos SSP in secur32 for now. Would you agree?
No, I don't agree. Windows definitely has all the providers in separate
dlls - msv1_0 (NTLM), kerberos, schannel, etc. We need to find out how
to properly implement kerberos support as a kerberos.dll. This will also
help to move NTLM code to msv1_0.dll.
More information about the wine-devel