Adventures with KfW 3.1b2

[Jeffrey Altman]

Henry B. Hotz wrote:
> On Nov 3, 2006, at 1:23 PM, Jeffrey Altman wrote:
> 
>> Henry B. Hotz wrote:
>>> Installed on a W2K Virtual PC on MacOS 10.4.8.  Windows Update seems
>>> to think I have all the latest and greatest.
> 
> But not IE 7.  FYI.

It doesn't matter.

>>> Nit:  [..deleted..]

I think we have a fix for the redraw issues that can be safely pulled in.

>>>
>>> Now we get to the real questions:  Can I make Firefox do cross-realm
>>> with the MIT libraries?  I've set:
>>>
>>> network.negotiate-auth.delegation-uris		jpl.nasa.gov
>>> network.negotiate-auth.gsslib		C:\Program Files\MIT\lib\i386
>>> \gssapi32.lib
>>> network.negotiate-auth.trusted-uris		https://
>>> network.negotiate-auth.using-native-gsslib	false.
>>>
>>> Logout.  (Don't reboot.)
>>>
>>> "Failed to renew credentials for hotz at JPL..." on login.  Opened
>>> NetIDMgr and typed password to get new tgt.  (I thought KfW used to
>>> import the tgt (or at least the password to get a tgt with) as well
>>> as the service tickets.  I *think* I have all the relevant options  
>>> set.)
>> What is the "default" identity set to?

Network Identity Manager refers to identities whereas the rest of the
Kerberos libraries reference credential caches.  I think this is where
there is an issue.

>> We don't import the credentials from the MSLSA: ccache now that it can
>> be used directly as the default.
> 
> If you don't import from the MSLSA, shouldn't the import button on  
> the GUI go away?

I should have written this differently.   You can either Import Always,
Import if the Principal matches the default realm in the krb5.ini, or
Never Import.

If you choose to Import then we end up with a situation in which there
are two credential caches with the same Kerberos principal or identity.

  MSLSA:  			-> hotz at JPL.NASA.GOV
  API:hotz at JPL.NASA.GOV		-> hotz at JPL.NASA.GOV

Both of these will contain the same TGT, the one that was imported from
the MSLSA: ccache.  The only difference is which libraries get used to
obtain new service tickets.  If the MSLSA: ccache is used, new service
tickets will be obtained using the Microsoft Kerberos SSP.  If the
API:hotz at JPL.NASA.GOV ccache is used, the MIT krb5_32.dll will be used
to obtain new service tickets.

> The default identity is hotz at JPL.NASA.GOV and the default ccache  
> apparently is API:hotz at JPL.NASA.GOV.  At any rate the latter is the  
> only ccache shown by klist -C.  The relevant box in the Kerberos 5  
> tab for the specific identity is blank in the GUI.

In this case, the MIT krb5_32.dll will be used to obtain new service
tickets.

"klist -C" only lists the "CCAPI" credential caches.  It should probably
be changed to check for an MSLSA: credential cache as well.

In Network Identity Manager, you can view all of the known ccaches of
all types by using the "View->Layout->By Location" option.

> I'm guessing that this section from the release notes is relevant:
> 
>> The MSLSA: credential cache relies on the ability to extract the  
>> entire Kerberos ticket including the session key from the Kerberos  
>> LSA.  In an attempt to increase security Microsoft has begun to  
>> implement a feature by which they no longer export the session keys  
>> for Ticket Getting Tickets. This has the side effect of making them  
>> useless to the MIT krb5 library when attempting to request  
>> additional service tickets.
>>
>> This new feature has been seen in Windows 2003 Server, Windows 2000  
>> Server SP4, and Windows XP SP2.  We assume that it will be  
>> implemented in all future Microsoft operating systems supporting  
>> the Kerberos SSPI.  Microsoft does work closely with MIT and has  
>> provided a registry key to disable this new feature.
>>
>>   HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
>
>>     AllowTGTSessionKey = 0x01 (DWORD)
>>
>> On Windows XP SP2 the key is specified as
>>
>>   HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos
>>
>>     AllowTGTSessionKey = 0x01 (DWORD)
> 
> I guess you can add W2K Pro to the list.
> 
> I just looked and that key is already set to "1".  Changing it to "0"  
> didn't fix the problem.  Should I have rebooted for it to take effect?

Setting this value to "0" would disable to exporting of TGT session
keys.   This is not what you want to do.  The value the KFW installer
set is correct.

> Page 33 of the user documentation refers to a "Include all API:  
> credential caches check box" that isn't in the example GUI or in mine.

I didn't update the documentation for the Beta.  Taking screen shots
takes a long time and I only want to do that once more for the final
release.  All of the unimplemented features that have been removed will
be removed from the docs at that time.

>>> Firefox works fine with web sites in the main JPL.NASA.GOV realm.  I
>>> want to use the MIT gssapi library because I want to configure some
>>> specific machines to be in a different realm, even though there is no
>>> DNS distinction.  This is outside of AD.
>> I think you are suffering from the fact that your AD realm and Heimdal
>> realms both have the same name.  Therefore, you can't use the MSLSA:
>> credentials at all.  And yet, because identities in both realms  
>> have the
>> same name it is not possible for us to distinguish which should be  
>> used
>> automatically.
> 
> This VPC is "joined" to the Heimdal realm and has no knowledge of the  
> AD realm.  I login with my Heimdal password.  After login, kerbtray  
> shows a tgt and a host ticket for the virtual PC.  NetIDMgr shows  
> only the host ticket.  Since the Windows Kerberos seems to be  
> functioning as well as can be expected, I don't think this is the  
> problem.
> 
>>> Opened Firefox 2.0.  Tried to connect to https:// 
>>> redhotz.jpl.nasa.gov/
>>> cgi-bin/test-cgi.
>>>
>>> Get a basic-auth prompt.  Kerbtray shows a HTTP/
>>> redhotz.jpl.nasa.gov at JPL.NASA.GOV, not a HTTP/... at HOTZ.JPL.NASA.GOV
>>> service ticket.  (If you reopen it.  I guess it doesn't auto-
>>> update.)  NetIDMgr shows the same thing.

This means one of two things.  Either FireFox is using the MSLSA: ccache
or it is using the SSPI.

To debug this I would load FireFox into a debugger and then place a
break point within gss_acquire_cred to see if it is being called and
if so which credential cache it is using.

If it is not being called, then the SSPI is being used and there is
either a bug in FireFox or a configuration problem.

>> If kerbtray is showing the ticket, this indicates that the MSLSA:
>> version of the identity is being used.
>>
>>> In a command prompt window "kvno -c API:hotz at JPL.NASA.GOV HTTP/
>>> redhotz.jpl.nasa.gov at HOTZ.JPL.NASA.GOV" will correctly get the cross-
>>> realm tgt, and the HTTP service principal.
> 
> However the HTTP service ticket is not visible in kerbtray.

If you are using the API:hotz at JPL.NASA.GOV ccache, then the contents
of the ccache will not be visible to KerbTray since KerbTray can only
view the contents of the MSLSA:

> Turning on the "Location" column in the NetIDMgr GUI helped a lot.   
> It clearly shows what gets done with which ccache.
> 
> "kvno -c MSLSA: HTTP/... at HOTZ.JPL.NASA.GOV" doesn't work, and I  
> expect that's because of that registry setting.  "kvno -c  
> API:hotz at JPL.NASA.GOV HTTP/..." only works if I independently kinit  
> so that ccache has a tgt to work with.

I doubt that this is the result of the AllowTGTSessionKey registry
setting.  The AllowTGTSessionKey registry setting is used to
restrict/permit the exporting of the TGT session key outside the LSA.
When the MSLSA: ccache is used, the request for the
HTTP/... at HOTZ.JPL.NASA.GOV service ticket is delivered to the LSA and
the LSA is responsible for performing the cross-realm authentication
and delivering the ticket.  Only if the LSA fails to return the ticket
would the MIT libraries attempt to perform the cross realm on its own.

Your problem here is most likely that Windows has no knowledge of the
HOTZ.JPL.NASA.GOV realm and doesn't know how to perform the cross-realm
authentication.

>>> Looks like Firefox is using the Windows SSPI instead of the MIT
>>> GSSAPI library, in spite of the config items saying otherwise.
>> Or that the GSSAPI is using the MSLSA: credential cache.
> 
> It's pretty clear that Firefox is still using the SSPI instead of the  
> MIT GSSAPI library.  (As you once told me) W2K absent AD, and absent  
> referrals on the KDC, can't tell that a specific experimental web  
> server (redhotz.jpl.nasa.gov) isn't in the JPL.NASA.GOV realm.   
> Firefox is getting an HTTP/redhotz... at JPL... prinicpal in the MSLSA.   
> (That principal exists, but is not used by the actual server.)  As  
> the MIT stuff knows, it should get an HTTP/redhotz... at HOTZ.JPL...  
> principal via a cross-realm auth.

Well then there is a bug that needs to be filed with Mozilla.org.

> I think I understand what NetIDMgr and the Windows Kerberos stuff is  
> doing now.
> 
> I have a Microsoft permission problem w.r.t. that registry setting.
> 
> I still have a Firefox config issue.

It sounds like it.

Jeffrey Altman
Secure Endpoints Inc.