OK. I may have figured the error. Although the the key version number for my afs principal is 1, the 1.2.2 krb524d (using -k) returns a V4 cred with a kvno of 0.
I determined this on the client side, I'll have to walk through the server code to see why the cred is returned with a kvno of 0. >>>>> "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> 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@k5realm Cesar> 2 - afs@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@k5realm Cesar> for each of our cells, just one principal afs@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@k5realm Cesar> (this ticket get's cached) Cesar> 2 - using k524 and V5 ticket for afs@k5realm, obtain a V4 ticket Cesar> for afs@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@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 <[EMAIL PROTECTED]> 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> [EMAIL PROTECTED] Cesar> http://mailman.mit.edu/mailman/listinfo/kerberos _______________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos