Adventures with KfW 3.1b2

[Henry B. Hotz]

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.

>> Nit:  [..deleted..]
>>
>>
>> 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?
>
> 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?

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.

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?

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.

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

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.

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

>> Nit:  [..deleted..]
>>
> Jeffrey Altman

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.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu