MIT Kerberos Client and MSLSA Cache

[Meike Stone]

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!

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

# 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: 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)
=========================================================

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