[OpenAFS] ADS and MIT Kerberos transition auth continued

[Garrison, Eric C]

Quoting Jeffrey Altman <jaltman@secure-endpoints.com>:

> Eric Chris Garrison wrote:
>
>> ...but as ecgarris@ADS.IU.EDU:
>>
>> Wed Jul  1 15:58:37 2009 [6] EVENT AFS_Aud_Unauth CODE -1 STR AFS_SRX_StData
>> Wed Jul  1 15:58:37 2009 [6] EVENT AFS_SRX_StData CODE 0 NAME --UnAuth--
>> HOST 149.166.144.33 ID 32766 FID 536870933:2:2
>>
>> So the ADS.IU.EDU user is showing as unauthorized?  Strange that if I
>> create a file, its UNIX permissions show as owned by ecgarris though.
>>
>>> I would also verify that the keytabs that you are using are in fact
>>> correct.  You can do so using the MIT Kerberos kvno command.  Obtain a
>>> TGT for ecgarris@ADS.IU.EDU and then issue:
>>
>>>   kvno -k <keytab> afs/afstest.iu.edu@ADS.IU.EDU
>
> Your Rx connection is unauthenticated.  That means that
>
> (a) either you do not have an AFS token
>
> (b) the token contains a kvno that is not recognized by the AFS server
>
> (c) the token is bad in some other way
>
> On Windows using the MIT KFW klist command, what does "klist -e" show
> when you have an afs/afstest.iu.edu@ADS.IU.EDU service ticket in the cache?


I have done an "aklog -c afstest.iu.edu" giving the following output 
for "tokens":
Tokens held by the Cache Manager:

User's (AFS ID 37302) tokens for afs@afstest.iu.edu [Expires Jul  9 00:53]
  --End of list--

The kvno command comes back with the right kvno, as seen by ktutil for 
the keytab, just
as it was when I added it with astekey.

Here's what "klist -e" says:

Default principal: ecgarris@ADS.IU.EDU

Valid starting     Expires            Service principal
07/08/09 14:53:40  07/09/09 00:53:44  krbtgt/ADS.IU.EDU@ADS.IU.EDU
       renew until 07/09/09 14:53:40, Etype (skey, tkt): AES-256 CTS 
mode with 96-bit
SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC
07/08/09 14:53:56  07/09/09 00:53:44  afs/afstest.iu.edu@ADS.IU.EDU
       renew until 07/09/09 14:53:40, Etype (skey, tkt): AES-256 CTS 
mode with 96-bit
SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC

So what else should I look for in the token being bad in another way?

Thanks again,

Chris