I've been meaning to submit a patch for this to [EMAIL PROTECTED]:
*** krb524d.c Wed Mar 5 19:24:17 2003
--- krb524d.c.new Wed Mar 5 19:33:44 2003
***************
*** 410,418 ****
--- 410,421 ----
/* out of memory? */
ret = errno;
memset (key, 0, sizeof (*key));
+ krb5_kt_free_entry(context, &entry);
return ret;
}
+ if(kvnop)
+ *kvnop = entry.vno;
krb5_kt_free_entry(context, &entry);
return 0;
} else if (use_master) {
This patch in it's form was not compiled or tested, I just forged it
from actual working changes, but it looks correct. (it also includes a
one line fix for a memory leak).
>>>>> "Matthew" == Matthew Mauzy <[EMAIL PROTECTED]> writes:
Matthew> I found the following post by Cesar Garcia posted in Feb 2002. I'm running
Matthew> into a similar problem and wonder if anyone has solved it.
Matthew> I just migrated my AFS cell with afs-krb5 Migration Kit v1.3 to use krb5
Matthew> v1.2.7. I'm running fakeka and krb524d on the KDC and ka-forwarder on the
Matthew> AFS DB servers and am able to use klog and authenticate to the new krb5
Matthew> database. The problem is that aklog isn't working correctly. When I kinit
Matthew> (successfully) and then run aklog I get what appears to be a valid AFS
Matthew> token:
Matthew> [EMAIL PROTECTED] ~ 8: tokens
Matthew> Tokens held by the Cache Manager:
Matthew> User's (AFS ID 9458) tokens for [EMAIL PROTECTED] [Expires Mar 6 03:52]
Matthew> --End of list--
Matthew> but any thing that requires permissions, like 'touch temp', fails with the
Matthew> following error in the messages file:
Matthew> kernel: afs: Tokens for user AFS id xxxxx for cell amath.unc.edu are
Matthew> discarded (rxkad error=19270408)
Matthew> I'm fairly certain that the fakeka/ka-forwarder combo are working properly
Matthew> as klog still works fine. It's just tokens that are created with aklog
Matthew> that fail.
Matthew> Since the windows AFS clients don't use the ka services, none of my windows
Matthew> clients are able to login to the AFS cell. I'm trying to use WAKE, (from
Matthew> Rose-Hulman http://www.rose-hulman.edu/TSC/software/wake/ ) to get around
Matthew> the Windows AFS/krb5 issues, but all the problems keep coming back to what
Matthew> seems to be a krb524 problem.
Matthew> --Matthew
Matthew> --- Forwarded Message ---
Matthew> OK. I may have figured the error.
Matthew> Although the the key version number for my afs principal is 1,
Matthew> the 1.2.2 krb524d (using -k) returns a V4 cred with a kvno of 0.
Matthew> I determined this on the client side, I'll have to walk through the
Matthew> 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/[EMAIL PROTECTED]
Cesar> 2 - [EMAIL PROTECTED] (*)
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/[EMAIL PROTECTED]
Cesar> for each of our cells, just one principal [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Cesar> (this ticket get's cached)
Cesar> 2 - using k524 and V5 ticket for [EMAIL PROTECTED], obtain a V4 ticket
Cesar> for [EMAIL PROTECTED]
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
Matthew> user of AFS id 4843 for cell w.ny.ms.com are discarded (rxkad
Matthew> 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 [EMAIL PROTECTED] 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
Matthew> __________________________________________________________________
Matthew> Matthew W. Mauzy
Matthew> Systems Administrator
Matthew> Applied Math @ UNC-CH
Matthew> email : [EMAIL PROTECTED] pager : [EMAIL PROTECTED]
Matthew> (W) 919.962.9819 www.amath.unc.edu/~mauzy/ (P) 919.347.0390
Matthew> __________________________________________________________________
Matthew> ________________________________________________
Matthew> Kerberos mailing list [EMAIL PROTECTED]
Matthew> https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos
