Ticket forwarding and IP addresses
Cesar Garcia
Cesar.Garcia at morganstanley.com
Wed Feb 13 23:49:10 EST 2002
FYI,
For those interested, here's a very simple patch to
krb524d.c (release 1.2.2):
Basically, the when looking up the key that krb524d
will use to build the response, the key version number
is not being assigned when using the keytab option.
The code looks OK when using the KDB.
I'll have to hammer away at this server.
What's the story with the alpa status of k524?
Are folks using this in production environments, despite the
recommendation in the README against doing so?
Thanks again for the pointers.
*** krb524d.c.orig Wed Feb 13 22:34:06 2002
--- krb524d.c Wed Feb 13 23:41:34 2002
***************
*** 393,398 ****
--- 393,400 ----
if ((ret = krb5_kt_get_entry(context, kt, p, kvno, ktype, &entry)))
return ret;
memcpy(key, (char *) &entry.key, sizeof(krb5_keyblock));
+ if(kvnop)
+ *kvnop = entry.vno;
return 0;
} else if (use_master) {
return kdc_get_server_key(context, p, key, kvnop, ktype, kvno);
>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia at morganstanley.com> writes:
Cesar> OK. I may have figured the error.
Cesar> Although the the key version number for my afs principal is 1,
Cesar> the 1.2.2 krb524d (using -k) returns a V4 cred with a kvno of 0.
Cesar> I determined this on the client side, I'll have to walk through the
Cesar> server code to see why the cred is returned with a kvno of 0.
>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia at morganstanley.com> writes:
Cesar> This is not exactly a Kerberos specific issue, but perhaps
Cesar> the folks on this mailing list might have some insight.
Cesar> I decided for now to go with Ken's suggestion that I simply
Cesar> remove the IP addresses from my V5 tickets, and do ticket
Cesar> forwarding sans IP addresses.
Cesar> It appears that the one dependency we have on IP addresses
Cesar> is k524. Our client code is modern and works fine. It's an
Cesar> old krb524d which we currently run on a CyberSafe KDC that
Cesar> requires IP addresses in the requesting ticket.
Cesar> So thanks to Doug Engert, we have a -k option that allows
Cesar> one to run the MIT krb524d with a keytab, which handles
Cesar> null IP addresses just fine - and I don't immediately, or
Cesar> perhaps ever, have to solve the problem of writing the glue
Cesar> to get it to work the CyberSafe KDB. Simply extracting all
Cesar> the necessary keys to a keytab file suffices.
Cesar> I then add the following keys to a keytab file:
Cesar> 1 - krbtgt/k5realm at k5realm
Cesar> 2 - afs at k5realm (*)
Cesar> (*) An aside - this predates me, so I'm not sure what all
Cesar> the reasons were) Since all of our AFS cells use the same
Cesar> server principal, we don't have afs/afscellname at k5realm
Cesar> for each of our cells, just one principal afs at k5realm
Cesar> (one k5realm) for all cells. Not sure how/if this is
Cesar> relevant, but it is different.
Cesar> The basic algorithm for obtaining tokens for all cells follows:
Cesar> 1 - using V5 TGS, obtain a ticket V5 ticket for afs at k5realm
Cesar> (this ticket get's cached)
Cesar> 2 - using k524 and V5 ticket for afs at k5realm, obtain a V4 ticket
Cesar> for afs at k5realm
Cesar> 3 - foreach cell, invoke ktc_SetToken, passing in the V4 cred
Cesar> obtained in step 2.
Cesar> This code is implemented in a lib/app we call ak5log and works
Cesar> with the cybersafe based krb524d, with either the cybersafe
Cesar> based k524 client or the MIT based k524 client.
Cesar> When we try to run either the cybersafe or MIT based client
Cesar> against the MIT krb524d (using -k), the ak5log code completes,
Cesar> but I get the following messages in syslog:
Cesar> ----
Cesar> Feb 12 21:05:09 imus afs: [ID 255639 kern.notice] afs: Tokens for user of AFS id 4843 for cell w.ny.ms.com are discarded (rxkad error=19270408)
Cesar> ----
Cesar> with a similar error going to my console.
Cesar> krb524init itself seems to work fine against the same MIT
Cesar> krb524d with the keytab. That is the I can V4 tgt and run
Cesar> my v4 apps with no problem.
Cesar> The error apparently corresponds to "Unknown key". I've verified
Cesar> the key and kvno for afs at k5realm that was extracted to the
Cesar> keytab file, and it appears to be correct. I assume I would
Cesar> have failed earlier had that not been the case.
Cesar> When I list my tokens, the listing looks normal.t The
Cesar> tokens themselves, however, are worthless.
Cesar> We're running various versions of transarc afs (3.5, 3.6)
Cesar> on our solaris machines, openafs 1.2.2 on our linux boxes.
Cesar> AFS servers are solaris.
Cesar> Before I go digging into this problem some more, I was wondering
Cesar> if anyone might have some insight on this one.
Cesar> Thanks in advance.
>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia at morganstanley.com> writes:
Cesar> I've been working with 1.2.2 for a some months now, and only
Cesar> recently have attempted to get the rcmds working, mainly in
Cesar> an effort to better understand how ticket forwarding works,
Cesar> since we have a need to do this in a homegrown application.
Cesar> The behavior that I see is that when I invoke ticket
Cesar> forwarding, the "forwarded" tickets contain only a single
Cesar> IP address.
Cesar> After walking through some of the code, it appears that
Cesar> the client, via krb5_fwd_tgt_creds, determines the target's
Cesar> IP address via a host lookup using gethostbyname(), as
Cesar> implemented in krb5_os_hostaddr().
Cesar> Since we use NIS as the primary source for hostname
Cesar> resolution, all host lookups render a single IP address,
Cesar> even for multihomed machines. Moving to DNS is not an
Cesar> option at the moment. Additionally, we use Veritas VCS
Cesar> and other similar clustering facilities. These hosts
Cesar> will have additional IP addresses that are not associated
Cesar> with the real hostname, but with service names for a
Cesar> particular cluster/application. So even if were to switch
Cesar> to DNS, the client would not be able to determine all the
Cesar> IP addresses for a given target host via the hostname
Cesar> lookup that it uses today.
Cesar> That said (barring hacks to application protocols that
Cesar> would allow target hosts to send IP addresses back to
Cesar> the source host, then having the client embed the full set
Cesar> of tickets), the way to address this would be to have
Cesar> the target host obtain new tickets will a full set of
Cesar> IP addresses.
Cesar> 1 - is this possible?
Cesar> 2 - is it within the limits of the specification?
Cesar> If so, has anyone has implemented this for 1.2.2 or any
Cesar> releases of MIT krb5.
Cesar> _______________________________________________
Cesar> Kerberos mailing list
Cesar> Kerberos at mit.edu
Cesar> http://mailman.mit.edu/mailman/listinfo/kerberos
More information about the Kerberos
mailing list