krb524d, aklog and AFS tokens
Matthew Mauzy
matthew_mauzy at unc.edu
Wed Mar 5 23:06:41 EST 2003
Key version numbers match (unless I'm not looking at the correct info).
How do I check the enc types?
--Matthew
% bos listkeys db0
key 0 has cksum ...
key 1 has cksum ...
key 2 has cksum ...
Keys last changed on Mon Mar 3 17:34:49 2003.
kadmin: getprinc afs
Principal: afs at AMATH.UNC.EDU
...
Last password change: Mon Mar 03 17:32:38 EST 2003
...
Number of keys: 1
Key: vno 2, DES cbc mode with CRC-32, no salt
Attributes:
--On Thursday, March 06, 2003 12:30 PM +1300 Nathan Ward
<nward at esphion.com> wrote:
> 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
>>
>>
>
>
__________________________________________________________________
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
__________________________________________________________________
More information about the Kerberos
mailing list