[OpenAFS] Odd token/fileserver permission denied problem
Dean Knape
knape@njit.edu
Thu, 30 Jul 2009 14:27:21 -0400
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