MIT Kerberos Client and MSLSA Cache

[Benjamin Kaduk]

On Tue, 21 Apr 2015, Meike Stone wrote:

> 2015-04-20 21:29 GMT+02:00 Benjamin Kaduk <kaduk at mit.edu>:
> > 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.
>
> Ah, ok ... if configured in registry, it will use that values, else it
> will try DNS SRV lookup ...
>
> All clients here that will use the MIT-Kerberos client are belonging
> an other department, not administrated by us.
> So maybe it is wise to configure the KDC and default realm in the registry!

It sounds like configuring the KDC entries would be reasonable.  There's
not really a "default realm" setting in the registry, though.

> >> 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.
>
> It does not work at the moment...
> Look at the following commands, invoked on the (test-) Windows2003:
> =========================================================
> # get a TGT for the default cache:
> C:\Programme\MIT\Kerberos\bin>kinit -c API: MSTONE at CORP.ORG
> Password for MSTONE at CORP.ORG:
>
> # show the TGT
> C:\Programme\MIT\Kerberos\bin>klist
> Ticket cache: API:Initial default ccache
> Default principal: MSTONE at CORP.ORG
>
> Valid starting     Expires            Service principal
> 04/21/15 15:29:15  04/22/15 01:29:19  krbtgt/CORP.ORG at CORP.ORG
>         renew until 04/22/15 15:29:15
>
> # Every thing is working as expected with default (MIT) ccache!
> # show the MSLSA cache:
> C:\Programme\MIT\Kerberos\bin>klist -c MSLSA:
> klist: Matching credential not found while retrieving principal name

This is one of the bugs I fixed on master -- the routine to get the
principal name from the cache attempts to get the full TGT, which is
(frequently, in most configurations) denied by security policy.  My new
code will just request a list of the tickets present (and not the secret
keys), which should always succeed and be able to determine the principal
name.

There are some related codepaths that fail if there is only a TGT in the
cache, but would succeed if there was a service ticket present (since the
session key can be retrieved for a service ticket), but I don't think this
is actually relevant in this particular case.

> # now I try to copy the TGT in the MSLSA cache
> C:\Programme\MIT\Kerberos\bin>mit2ms.exe
> mit2ms.exe: Ccache function not supported: read-only ccache type while
> copying default MIT ccache to MSLSA ccache
>
> # MSLSA ccache is readonly?
> # this procedure works for me on Windows 7

This is going through a different (open-coded) version of the
principal-detection logic, so it is unsurprising that it fails.

The KRB5_CC_READONLY error is only generated in a small number of places,
though it's not 100% clear which one would be at fault.  krb5_lcc_store()
would make the most sense, since we first try the KerbSubmitTicketMessage,
which is not supported on XP and Server 2003.  Since that works on all
newer systems, the fallback codepath is poorly tested.  The fallback goes
through the KerbRetrieveEncodedTicketMessage, which IIRC will fail if the
target realm is a non-AD realm and there are no registry settings for the
KdcNames.

> Now I try the get the TGT direct in the MSLSA ccache:
> =========================================================
> # destroy Initial default ccache
> C:\Programme\MIT\Kerberos\bin>kdestroy
>
> # get TGT for MSLSA ccache (works on Windows 7), no error shown
> C:\Programme\MIT\Kerberos\bin>kinit -c MSLSA: MSTONE at CORP.ORG
> Password for MSTONE at CORP.ORG:
>
> # show the TGT, nothing shown ...
> C:\Programme\MIT\Kerberos\bin>klist -c MSLSA:
> klist: Matching credential not found while retrieving principal name
>
> # try default ccache, same result, nothing shown ...
> C:\Programme\MIT\Kerberos\bin>klist -c API:
> klist: No credentials cache found (ticket cache API:Initial default ccache)
> =========================================================

The TGT was obtained and inserted into the MSLSA cache, but is not being
displayed because of the interaction between the windows security measures
and the KfW code.  For security, the session key in the TGT is zeroed out
in the returned data structure, but the (old) KfW code treats the
all-zeros session key as meaning that the ticket should be ignored, and
displays nothing.  If there was a service ticket in the cache, the KfW
code would retrieve that successfully, and infer that a TGT existed for
purposes of display (blech).

> Is there a possibility to debug this, or do you have a hint?

Well, I do not think there is much point in trying to debug the lack of
klist output.  It might be worth debugging the mit2ms.exe failure, but it
is hard to conjure up energy to care about Server 2003, if things work on
the newer systems.

> Before I can test SAP with SNC_LIB=gssapi32.dll I should have a TGT in
> the MSLSA ccache?!

When using the KfW 4.0.x gssapi32.dll, there should not be a need to
already have a TGT -- I believe the library can launch MIT Kerberos.exe
and pop up a "Get Ticket" window.  However, having a TGT present will
eliminate the need for that popup, and is the mode I normally operate in.

> > 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.
>
> Oh Yes, I know, but like mentioned, we do not administrate this
> Servers, we only provide the
> SAP services and can provide suggestions (for the other department)
> howto do the SSO to our services...

I would recommend making the API: cache the default and having SAP use
that, if there is no external need for using the LSA cache.  Getting
things working properly with the LSA cache can be very frustrating, and
the API: cache should be much simpler to set up.

-Ben