krb524d, aklog and AFS tokens

Matthew Mauzy matthew_mauzy at unc.edu
Thu Mar 6 01:58:10 EST 2003


So I may have fixed it, at least partially.  The AFS token discard error 
number, 19270408, when translated with 'translate_et 19270408' gives 
"ticket contained unknown key version number".  Which after some more 
digging gives the following paragraph from the krb524/README file once 
indicates that my Transarc AFS servers don't understand the encrypted 
tickets:

Configuring krb524d AFS Conversion
======================================================================

The krb524d looks in the appdefaults  section of krb5.conf for an
application called afs_krb5 to determine whether  afs principals
support encrypted ticket parts as tokens.  The following configuration
fragment says that afs/sipb.mit.edu at ATHENA.MIT.EDU supports the new
token format but afs at ATHENA.MIT.EDU and
afs/athena.mit.edu at ATHENA.MIT.EDU do not.  Note that the default is to
assume afs servers support the new format.

[appdefaults]
afs_krb5 = {
        ATHENA.MIT.EDU = {
                # This stanza describes principals in the
                #ATHENA.MIT.EDU realm
                afs = false
                afs/athena.mit.edu = false
                afs/sipb.mit.edu = true
        }
}


After adding the appdefaults section to my krb5.conf file and restarting 
the krb5kdc and krb524d services, I am now successfully using aklog.  On 
the windows client it looks like WAKE is able to obtain valid AFS tokens 
using the krb tgt (I'm at home trying to do this via XP's remote desktop so 
it's a little painful).

So yeah, steps forward, but ... This seems to only work on systems for 
which there exists a host/FQDN principal in the krb5 database.  So this 
isn't going to work for systems on a DSL connection or systems under DHCP 
with varying hostnames.  (Testing now gives me an error of "Incorrect net 
address".)

So my question to the group, and sorry if this should go to an afs list 
instead of the krb list - what do people use for AFS access for remote/home 
users once they've migrated their afs to krb5?

--Matthew

--On Wednesday, March 05, 2003 11:06 PM -0500 Matthew Mauzy 
<matthew_mauzy at unc.edu> wrote:

> 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
>>>


__________________________________________________________________
                        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