[OpenAFS] Odd token/fileserver permission denied problem

[Dean Knape]

Time skew?

On Jul 30, 2009, at 1:51 PM, Gedaliah Wolosh wrote:

>
>
> On Thu, the 9th of Av, 5769 (07/30/2009) Jeffrey Altman wrote:
>
>> Gedaliah Wolosh wrote:
>>>
>>> Currently our cell is authenticating to both the KA server and  
>>> Krb5. The
>>> AFS Keyfile contains principals for both afs and afs/cellname.  The
>>> KeyFile is distributed via upclient.  This has been working for  
>>> several
>>> months without issue.
>>>
>>> A new file server was put in place. If aklog is used to get a  
>>> token, the
>>> token does not give the user permission in any volume served by  
>>> this new
>>> file server. A token obtained by klog is fine.
>>
>> The kaserver token will be issued from a realm with the same name  
>> as the
>> cell.  What is the name of the Kerberos v5 realm and if it is not the
>> same, does it exist in the afs krb.conf file?
>
> The Kerberos v5 realm is different from the name of the cell, however
> the realm name IS in the afs krb.conf file.
>
>>
>>> Creating a host principal and putting it in the file servers
>>> /etc/krb5.keytab didn't help.
>>
>> Kerberos v5 keytabs are not used by AFS servers.
>
> That is what I thought
>
>>
>>> aklog -d does not offer any useful information, nor do the logs. I
>>> compared the AFS Keyfile to the KeyFile on the other servers and  
>>> they
>>> are the same. The file server is running OpenAFS 1.4.11 on Solaris  
>>> 10.
>>
>> Tokens are obtained for the cell.  If the tokens are obtained there  
>> is
>> nothing for aklog to say other than success.
>>
>>> Any help is greatly appreciated.
>>
>> My guess is that either:
>>
>> . the Kerberos v5 realm name differs from the name of the cell
>>  and that realm name is not in the afs krb.conf file.
>>
>> . the KeyFile on the new file server does not contain all of
>>  the keys that are present on the other file servers.
>
> I checked the KeyFile using bos listkeys and it is the same.
> /usr/afs/etc is identical on all of the servers. We use upclient to  
> keep
> this directory in sync. Note that there is no problem with any of the
> other servers.
>
> Gedaliah Wolosh
> University Computing Systems - IST
> New Jersey Institute of Technology
>
>
>>
>> Jeffrey Altman
>>
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info