[OpenAFS] Re: rxk error: caller not authorized

[J Maynard Gelinas]

On Sun, 25 Apr 2004, J Maynard Gelinas wrote:

>  [snip] 
> 
> So, it appears that the client afslog is unable to generate a usable token
> from my slave krb524d server(s). Finally, if I request a V5 TGT from a
> slave server, change the client krb5.conf to the master kdc, and then use
> that to convert to a V4 TGT, I can run afslog on the client just fine.
> Further showing that whatever is going on, it's limited to V5 to V4
> conversion on my slaves, and the master krb524d still works. 
> 
> I have no idea what changed. Any suggestions? And thanks for the replies!

[snip]

  Aha... an epiphany. So, what changed? Per the more recent krb5-1.2.8 
readme states:

Major Changes:

* [1402, 1385, 1395, 1410, 1411] The krb4 protocol vulnerabilities
  [MITKRB5-SA-2003-004] have been worked around.  Note that this will
  disable krb4 cross-realm functionality, as well as krb4 triple-DES
  functionality.  Please see doc/krb4-xrealm.txt for details of the
  patch

Another change I noticed for kerberos 1.2.6:

* A bug in AFS salt handling has been worked
  around. [krb5-clients/1146] Thanks to Wolfgang Friebel.

* The KDC, in handling both krb5 and krb4 TGS_REQs, now honors the
  DISALLOW_ALL_TIX and DISALLOW_SVR attributes on the server
  principal.  This also now happens with krb524d.

* krb524d will now, by default, convert krb5 tickets for afs service
  princpals to special tokens that are actually just the EncryptedData
  part of a krb5 Ticket structure.  This may be overridden; please
  consult src/krb524/README for details.


  Now, I'm running Debian krb5-1.2.4-5woody4 on the slave and 
krb5-1.2.4-5woody3 on the master. I wonder if one of these fixes were 
backported to the stable debian release and that change within the minor 
update is responsible for this behavior?  I note that TGTs obtained from 
my krb5 server:

[gelinas@swg gelinas]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1126_G86MkA
Default principal: gelinas@LNS.MIT.EDU

Valid starting     Expires            Service principal
04/25/04 15:49:30  04/26/04 01:49:30  krbtgt/LNS.MIT.EDU@LNS.MIT.EDU
        Etype (skey, tkt): DES cbc mode with CRC-32, Triple DES cbc mode 
with HMAC/sha1 
04/25/04 15:49:37  04/26/04 01:49:30  afs/lns.mit.edu@LNS.MIT.EDU
        Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with 
CRC-32 


Kerberos 4 ticket cache: /tmp/tkt1126_5Nauwd
klist: You have no tickets cached
[gelinas@swg gelinas]$

   Notice the krbtgt/LNS.MIT.EDU@LNS.MIT.EDU is set for encryption type:

Etype (skey, tkt): DES cbc mode with CRC-32, Triple DES cbc mode  
with HMAC/sha1

  While Athena gives me:

[gelinas@swg gelinas]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1126_G86MkA
Default principal: gelinas@ATHENA.MIT.EDU

Valid starting     Expires            Service principal
04/25/04 15:50:58  04/26/04 01:50:58  krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
        Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with 
CRC-32 
04/25/04 15:51:15  04/26/04 01:50:58  afs/athena.mit.edu@ATHENA.MIT.EDU
        Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with 
CRC-32 

Kerberos 4 ticket cache: /tmp/tkt1126_5Nauwd
klist: You have no tickets cached
[gelinas@swg gelinas]$ 

   What I'm thinking is that the encrypion type of 3DES cbc mode with
HMAC/sha1 for krbtgt/LNS.MIT.EDU@LNS.MIT.EDU is the real culprit here.  
Assuming that the new krb524d won't accept that encryptiom type, and
that's the true cause, are there any recommendations for an easy way out
of this mess? And if that's not the cause, could any of the other changes 
listed be relevant to the cause? 

Thanks again for any suggestions,
--Maynard