MIT Kerberos Client and MSLSA Cache

[Benjamin Kaduk]

On Mon, 20 Apr 2015, Meike Stone wrote:

> Hello Benjamin,
>
> 2015-04-17 22:18 GMT+02:00 Benjamin Kaduk <kaduk at mit.edu>:
>
> >
> > However, with the currently released versions, if you have UAC enabled,
> > the non-SSPI clients will not work.  If you do not have UAC enabled, they
> > will not work very well (they will wait for some DNS timeouts) unless you
> > set
> > HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains\REALM.NAME\KdcNames
> > to a multi-string entry with the DNS names of the KDCs for the realm's
> > KDCs.
>
> I've seen this before, that's what Microsoft does if ksetup.exe is invoked!
> But on a test PC, I dropped that configuration and it works as well,
> no (appreciable) timeout seen, but I haven't sniffed.
> I'll digging deeper soon!

Ah, I failed to say that this is only needed if the realm in use is not an
AD realm.  The LSA will use AD-specific DNS queries to locate KDCs in AD
realms, but will not use the standard SRV lookups to locate KDCs for Unix
realms.

Furthermore, the timeout behavior is subject to some caching, IIRC.  The
full situation is difficult to characterize externally.

> > There are several improvements on master that have not made it into a
> > release yet; I hope to put out a KfW 4.1 release in the next couple of
> > months which includes them.
>
> What improvements?

It boils down to using the proper interfaces to have the LSA get service
tickets, instead of retrieving the TGT and doing it ourself.  Also some
changes to not try to get the TGT when it is not needed.

> >> Using ksetup and logon to the kerberos real works, but I don't can
> >> make that deep changes on the  Windows workstations (e.g. ne
> >> userprofile, etc ....).
> >
> > I'm not sure I understand this paragraph.
>
> I mean the using of Microsofts Kerberos Client (W7 included / W2k3 in
> support tools),
> configured by ksetup.exe - Installation without MIT-Kerberos Client!
> That solution is working as well, but the user must logon to the
> Kerberos "domain" and
> the user gets a new profile! Microsofts "kinit" is only invoked during
> the logon process.

I believe that is correct, that using only the Microsoft tools it is only
possible to convert a password into a Kerberos TGT at logon time.

> >> Main cause it to get running the SAP-GUI, using Kerberos to authenticate!
> >> Mayby someone has an idea to get this running on a simple workstation
> >> without domain or Kerberos membership.
> >
> > I am surprised that it is not working; maybe the version of SAP GUI that
> > MIT distributes internally has some custom config in place.  In any case,
> > you should be able to set SNC_LIB to point to the gssapi32.dll library and
> > avoid the MSLSA: cache.
>
> Yes, now It works - Thanks!

I'm glad that you have things working (in two different ways, if I
understand correctly?).

> But one question. I tried the same on Windows 2003, But it didn't work.
> We have a few stand alone Terminal servers, managed from other
> departments (same with the Windows 7 PC's)
> Is it possible to do that with Windows 2003 too - would be very nice!

I don't remember anything offhand that would prevent SNC_LIB=gssapi32.dll
from working on Windows Server 2003.  The code first tries to use some
modern API calls which are not provided on systems that old, but should
have fallbacks to older APIs which should be present there.

I do note that Windows Server 2003 goes out of support in just a few
months, so hopefully those machines will not be in service for much longer
anyway.

-Ben