Kerberos for Windows & MSLSA Cache

[Christopher Penney]

I run a Linux environment that's setup in an MIT Kerberos Realm. That realm
has a one way trust setup that allows tickets for Active Directory
principals (from Windows 7 clients) to be accepted as authentication (for
SSH and ODBC for Hadoop/Hive). I'm having two problems.

The first problem I'm having is that Windows 7 users using Kerberos for
Windows 4.01 do not seem to be able to use their AD ticket in the MSLSA
cache. If I set KRB5CCNAME to a file and obtain an AD ticket independently
of MSLSA everything works fine. With KRB5CCNAME set to MSLSA: it does not
work. I did find a note about setting AllowTGTSessionKey to 1, but that's
already been done (and rebooted).

Is there a way to use the AD tickets stored in MSLSA using MIT KfW? I
assumed it was possible looking at the release notes where it says
"Integration with the Windows LSA credentials cache", but maybe that's not
the case.

I'm also experiencing a problem where (using either MSLSA: or a file for
the CC) I can renew tickets just fine from a cmd window using '"kinit -R",
but the MIT Kerberos.exe sys tray tool crashes when it tries to renew. I
get the following in event viewer:

> Faulting application name: MIT Kerberos.exe, version: 4.0.1.2, time stamp:
> 0x50c22fb6
> Faulting module name: MSVCR100.dll, version: 10.0.40219.325, time stamp:
> 0x4df2bcac
> Exception code: 0xc0000005
> Fault offset: 0x000000000003c560
> Faulting process id: 0x1828
> Faulting application start time: 0x01d05782975e269d
> Faulting application path: C:\Program Files\MIT\Kerberos\bin\MIT
> Kerberos.exe
> Faulting module path: C:\Windows\system32\MSVCR100.dll
> Report Id: 631e69e6-c3c7-11e4-92c0-180373cb2112


The exception code points to some kind of access issue, but I can't seem to
see what it is. Watching it with Process Monitor wasn't very interesting,
but I'm not an expert.

If I run "MIT Kerberos.exe" -renew it gives the message "There was an error
renewing tickets!".

Thanks,

Chris

[Benjamin Kaduk]

Hi Chris,

On Fri, 6 Mar 2015, Christopher Penney wrote:

> I run a Linux environment that's setup in an MIT Kerberos Realm. That realm
> has a one way trust setup that allows tickets for Active Directory
> principals (from Windows 7 clients) to be accepted as authentication (for
> SSH and ODBC for Hadoop/Hive). I'm having two problems.
>
> The first problem I'm having is that Windows 7 users using Kerberos for
> Windows 4.01 do not seem to be able to use their AD ticket in the MSLSA
> cache. If I set KRB5CCNAME to a file and obtain an AD ticket independently
> of MSLSA everything works fine. With KRB5CCNAME set to MSLSA: it does not
> work. I did find a note about setting AllowTGTSessionKey to 1, but that's
> already been done (and rebooted).
>
> Is there a way to use the AD tickets stored in MSLSA using MIT KfW? I
> assumed it was possible looking at the release notes where it says
> "Integration with the Windows LSA credentials cache", but maybe that's not
> the case.

There are several bugs in KfW 4.0.1 (previous versions) with the MSLSA
handling; several operations on the cache ("lcc_resolve()" and
"lcc_get_principal()", at least) were attempting to retrieve the full TGT
in order to get the client principal's name in the cache. However, the
full TGT is not actually necessary to obtain the client's name.

When UAC is enabled, attempting to retrieve the TGT from the LSA fails, so
the cache is essentially unusable. Disabling UAC is a (not very
appealing) workaround.

I believe I have fixed these bugs in the krb5 development branch, but they
have not made it into a new KfW release yet. If you are interested in
building KfW from the latest sources, I would be interested to hear if
that resolves your problems.

> I'm also experiencing a problem where (using either MSLSA: or a file for
> the CC) I can renew tickets just fine from a cmd window using '"kinit -R",
> but the MIT Kerberos.exe sys tray tool crashes when it tries to renew. I
> get the following in event viewer:
>
> > Faulting application name: MIT Kerberos.exe, version: 4.0.1.2, time stamp:
> > 0x50c22fb6
> > Faulting module name: MSVCR100.dll, version: 10.0.40219.325, time stamp:
> > 0x4df2bcac
> > Exception code: 0xc0000005
> > Fault offset: 0x000000000003c560
> > Faulting process id: 0x1828
> > Faulting application start time: 0x01d05782975e269d
> > Faulting application path: C:\Program Files\MIT\Kerberos\bin\MIT
> > Kerberos.exe
> > Faulting module path: C:\Windows\system32\MSVCR100.dll
> > Report Id: 631e69e6-c3c7-11e4-92c0-180373cb2112
>
>
> The exception code points to some kind of access issue, but I can't seem to
> see what it is. Watching it with Process Monitor wasn't very interesting,
> but I'm not an expert.
>
> If I run "MIT Kerberos.exe" -renew it gives the message "There was an error
> renewing tickets!".

I am less sure about this issue. It is possible that it is related to the
UAC permissions mentioned above, but it may be a different issue.

-Ben Kaduk

[Christopher Penney]

On Fri, Mar 6, 2015 at 12:44 PM, Benjamin Kaduk <ka...@mit.edu> wrote:

>
> I believe I have fixed these bugs in the krb5 development branch, but they
> have not made it into a new KfW release yet. If you are interested in
> building KfW from the latest sources, I would be interested to hear if
> that resolves your problems.
>
>

That's good to know, thanks. I might try that though I'm not much of a
developer. Is there any ETA (even if rough) for when this would make it to
a "released" version?

> > I'm also experiencing a problem where (using either MSLSA: or a file for
> > the CC) I can renew tickets just fine from a cmd window using '"kinit
> -R",
> > but the MIT Kerberos.exe sys tray tool crashes when it tries to renew. I
> > get the following in event viewer:
>

> I am less sure about this issue. It is possible that it is related to the
> UAC permissions mentioned above, but it may be a different issue.
>

I should have noted this in the original note, but it seemed like it used
to work (we've been using KfW for about 6 months), but recently broken.
The user sample size is really small here though so it's hard to tell. Is
there anything I can do to help pin it down (e.g. debugging flags I'm not
aware of)?

Chris

[Benjamin Kaduk]

On Fri, 6 Mar 2015, Christopher Penney wrote:

> On Fri, Mar 6, 2015 at 12:44 PM, Benjamin Kaduk <ka...@mit.edu> wrote:
>
> >
> > I believe I have fixed these bugs in the krb5 development branch, but they
> > have not made it into a new KfW release yet. If you are interested in
> > building KfW from the latest sources, I would be interested to hear if
> > that resolves your problems.
> >
> >
> That's good to know, thanks. I might try that though I'm not much of a
> developer. Is there any ETA (even if rough) for when this would make it to
> a "released" version?

It seems that some demand from this is appearing from other places as
well, so it will make its way higher on my priority list. There is
another feature wanted for the next KfW release (better screen reader
support), so the ETA is still measured in months; I would ballpark 2
months until a beta release, but that is a very rough estimate and could
change a lot.

> > > I'm also experiencing a problem where (using either MSLSA: or a file for
> > > the CC) I can renew tickets just fine from a cmd window using '"kinit
> > -R",
> > > but the MIT Kerberos.exe sys tray tool crashes when it tries to renew. I
> > > get the following in event viewer:
> >
> > I am less sure about this issue. It is possible that it is related to the
> > UAC permissions mentioned above, but it may be a different issue.
> >
>
> I should have noted this in the original note, but it seemed like it used
> to work (we've been using KfW for about 6 months), but recently broken.
> The user sample size is really small here though so it's hard to tell. Is
> there anything I can do to help pin it down (e.g. debugging flags I'm not
> aware of)?

Most of the debugging flags are set at compile time. The KRB5_TRACE
environment variable does work (as on Unix krb5), but I don't expect it to
provide any useful output for this situation.

Debugging runtime crashes is usually easiest with the help of a debugger,
but the release versions do not include debugging symbols. If you want
have visual studio around and want to try, I can see about sending the
debug symbols to you.

-Ben