MIT Kerberos Client and MSLSA Cache

[Meike Stone]

Hello dear list,

I have Windows 7 workstations, not joined to a AD Domain.
I like to use MIT Kerberos client to authenticate to a Kerberos server
and run several programs using Kerberos to authenticate.
The MIT client is installed and running, I get a krbtgt and if I use
Firefox with network.auth.use-sspi=false, Firefox uses Kerberos as
well.

But my problem are applications that using only the MSLSA Kerberos
cache (for example SAP-GUI via gsskrb5.dll) (SSPI)
Is is possible, to configure the MIT-Kerberos client to use this cache (too)?

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 ....).

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.

Thanks Meike

[Benjamin Kaduk]

On Fri, 17 Apr 2015, Meike Stone wrote:

> Hello dear list,
>
> I have Windows 7 workstations, not joined to a AD Domain.
> I like to use MIT Kerberos client to authenticate to a Kerberos server
> and run several programs using Kerberos to authenticate.
> The MIT client is installed and running, I get a krbtgt and if I use
> Firefox with network.auth.use-sspi=false, Firefox uses Kerberos as
> well.
>
> But my problem are applications that using only the MSLSA Kerberos
> cache (for example SAP-GUI via gsskrb5.dll) (SSPI)

SAP-GUI will use gssapi32.dll just fine, for what it's worth (we use it
that way at MIT).

> Is is possible, to configure the MIT-Kerberos client to use this cache (too)?

It is possible to configure MIT Kerberos to use that cache, though it is
not very well exposed in the GUI at the moment. You can set
HKCU\Software\MIT\Kerberos5\ccname to "MSLSA:" in the registry to make it
the default, or explicitly run kinit.exe -c MSLSA: <principal> from
cmd.exe to just get a ticket. (Once you have a ticket, the "make default"
button will set the registry entry for you.)

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.

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.

> 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.

> 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.

-Ben

[Meike Stone]

Hello Benjamin,

2015-04-17 22:18 GMT+02:00 Benjamin Kaduk <ka...@mit.edu>:
> On Fri, 17 Apr 2015, Meike Stone wrote:
>
>> Hello dear list,
>>
>> I have Windows 7 workstations, not joined to a AD Domain.
>> I like to use MIT Kerberos client to authenticate to a Kerberos server
>> and run several programs using Kerberos to authenticate.
>> The MIT client is installed and running, I get a krbtgt and if I use
>> Firefox with network.auth.use-sspi=false, Firefox uses Kerberos as
>> well.
>>
>> But my problem are applications that using only the MSLSA Kerberos
>> cache (for example SAP-GUI via gsskrb5.dll) (SSPI)
>
> SAP-GUI will use gssapi32.dll just fine, for what it's worth (we use it
> that way at MIT).
>
>> Is is possible, to configure the MIT-Kerberos client to use this cache (too)?
>
> It is possible to configure MIT Kerberos to use that cache, though it is
> not very well exposed in the GUI at the moment. You can set
> HKCU\Software\MIT\Kerberos5\ccname to "MSLSA:" in the registry to make it
> the default, or explicitly run kinit.exe -c MSLSA: <principal> from
> cmd.exe to just get a ticket. (Once you have a ticket, the "make default"
> button will set the registry entry for you.)

That works absolutely fine! Thanks :-D

>
> 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!

>
> 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?

>
>> 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.

>
>> 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!

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!

Thanks Meike

[Benjamin Kaduk]

On Mon, 20 Apr 2015, Meike Stone wrote:

> Hello Benjamin,
>
> 2015-04-17 22:18 GMT+02:00 Benjamin Kaduk <ka...@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

[Meike Stone]

2015-04-20 21:29 GMT+02:00 Benjamin Kaduk <ka...@mit.edu>:
> On Mon, 20 Apr 2015, Meike Stone wrote:
>
>> Hello Benjamin,
>>
>> 2015-04-17 22:18 GMT+02:00 Benjamin Kaduk <ka...@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!

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

Yes :-D

>
>> 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: MST...@CORP.ORG
Password for MST...@CORP.ORG:

# show the TGT
C:\Programme\MIT\Kerberos\bin>klist
Ticket cache: API:Initial default ccache
Default principal: MST...@CORP.ORG

Valid starting Expires Service principal
04/21/15 15:29:15 04/22/15 01:29:19 krbtgt/CORP...@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

# 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

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: MST...@CORP.ORG
Password for MST...@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)
=========================================================

Is there a possibility to debug this, or do you have a hint?
Before I can test SAP with SNC_LIB=gssapi32.dll I should have a TGT in
the MSLSA ccache?!

>
> 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...

Thank you very much,
Meike

[Benjamin Kaduk]

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

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: MST...@CORP.ORG
> Password for MST...@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

[Meike Stone]

Hello Benjamin,

thank you very much for great help!
Today I got running SAP SSO for W2k3 too!

> 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.

Thats what I did!
Switched from MSLSA to MIT ccache AND using gssap32.dll from MIT!

The following and my wrong post in the other thread gave me the
enlightened hint!

> 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.

Yes, that works all as described (but only with the MIT gssapi32.dll ;-)!

Problem was only the weak encryption (single-des) derived from former XP
clients in our AD-Domain (arrg)
I configured this in krb5.ini (allow_weak_crypto = true) and every
thing was working!

Thanks a lot,

Regards Meike!