krb524d, aklog and AFS tokens
Nathan Ward
nward at esphion.com
Wed Mar 5 18:30:02 EST 2003
Check your key version numbers, and your enc types. I had this problem
several times and it was a combination of these 2 problems that caused it.
Nathan Ward
Matthew Mauzy wrote:
> I found the following post by Cesar Garcia posted in Feb 2002. I'm
> running into a similar problem and wonder if anyone has solved it.
>
> I just migrated my AFS cell with afs-krb5 Migration Kit v1.3 to use
> krb5 v1.2.7. I'm running fakeka and krb524d on the KDC and
> ka-forwarder on the AFS DB servers and am able to use klog and
> authenticate to the new krb5 database. The problem is that aklog
> isn't working correctly. When I kinit (successfully) and then run
> aklog I get what appears to be a valid AFS token:
>
> mauzy at jag ~ 8: tokens
>
> Tokens held by the Cache Manager:
>
> User's (AFS ID 9458) tokens for afs at amath.unc.edu [Expires Mar 6 03:52]
> --End of list--
>
>
> but any thing that requires permissions, like 'touch temp', fails with
> the following error in the messages file:
>
> kernel: afs: Tokens for user AFS id xxxxx for cell amath.unc.edu are
> discarded (rxkad error=19270408)
>
>
> I'm fairly certain that the fakeka/ka-forwarder combo are working
> properly as klog still works fine. It's just tokens that are created
> with aklog that fail.
>
> Since the windows AFS clients don't use the ka services, none of my
> windows clients are able to login to the AFS cell. I'm trying to use
> WAKE, (from Rose-Hulman http://www.rose-hulman.edu/TSC/software/wake/
> ) to get around the Windows AFS/krb5 issues, but all the problems keep
> coming back to what seems to be a krb524 problem.
>
> --Matthew
>
> --- Forwarded Message ---
>
> 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 <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
>
> __________________________________________________________________
> Matthew W. Mauzy
> Systems Administrator
> Applied Math @ UNC-CH
> email : mauzy at amath.unc.edu pager : mpager at amath.unc.edu
> (W) 919.962.9819 www.amath.unc.edu/~mauzy/ (P) 919.347.0390
> __________________________________________________________________
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
More information about the Kerberos
mailing list