[OpenAFS] ADS and MIT Kerberos transition auth continued
Garrison, Eric C
ecgarris@iupui.edu
Wed, 8 Jul 2009 15:34:37 -0400
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