Return-Path: linux-nfs-owner@vger.kernel.org Received: from partagas.dragonet.es ([217.70.240.130]:58403 "EHLO partagas.dragonet.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753592Ab2BCRXU (ORCPT ); Fri, 3 Feb 2012 12:23:20 -0500 Message-ID: <4F2C17F0.3090703@steve-ss.com> Date: Fri, 03 Feb 2012 18:22:56 +0100 From: steve MIME-Version: 1.0 To: tigran.mkrtchyan@desy.de CC: linux-nfs@vger.kernel.org Subject: Re: nfs4 keytabs [was:Re: where can I ask user qns about nfs4]? References: <4F2A2F9E.6030908@steve-ss.com> <4F2A74A7.4060905@steve-ss.com> <4F2A8FBC.1010101@steve-ss.com> <4F2AA430.2040109@steve-ss.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Sender: linux-nfs-owner@vger.kernel.org List-ID: On 02/02/2012 07:57 PM, Tigran Mkrtchyan wrote: > On Thu, Feb 2, 2012 at 3:56 PM, steve wrote: >> On 02/02/12 14:29, steve wrote: >>> On 02/02/2012 02:05 PM, Tigran Mkrtchyan wrote: >>>> On Thu, Feb 2, 2012 at 12:33 PM, steve wrote: >>>>> On 02/02/12 11:58, Tigran Mkrtchyan wrote: >>>>>> Hi Steve, >>>>>> >>>>>>> I already use nfs4 to serve my Linux clients. I'm going to kerberize >>>>>>> it. >>>>>>> My >>>>>>> clients already have machine and host principals. What else do they >>>>>>> need? >>>>>>> >>>>>>> 1. nfs/client.domain.name >>>>>>> 2. nfs/server.domain/name >>>>>>> 3. neither >>>>>>> 4. both >>>>>>> >>>>>> We run kerberized NFS. >>>>>> >>>>>> our keytab contains: >>>>>> >>>>>> on server; >>>>>> nfs/server.domain >>>>>> >>>>>> on client: >>>>>> nfs/client.domain >>>>>> >>>>>> and, of course, you need a consistent idmap configuration. >>>>>> >>>>>> Tigran. >>>>>> >>>>> Hi Tigran >>>>> >>>>> That's what we have on our test lan at the moment. I can understand that >>>>> the >>>>> server would need the service principal: >>>>> nfs/server.domain >>>>> but not the client, as it's not offering any kerberized service. >>>> The mount step happens on behalf of host as there are no user requests >>>> yet. >>>> Client host credentials are used at that time. >>>> >>>>> As an experiment, I removed the nfs/client.domain from a client keytab, >>>>> rebooted and remounted the share. We could still access the kerberized >>>>> nfs >>>>> share. Maybe there were still some tickets left somewhere? That has me >>>>> really confused. >>>> Huh! did you enforce kerberos in /etc/exports? >>>> >>> Yes. /etc/exports exports as gss/krb5 >>> I made a screenshot: >>> >>> >>> http://3.bp.blogspot.com/-g40b11Ys_DA/TypYtlO-ixI/AAAAAAAAAIc/cZdeRhnVuY4/s1600/s4all.png >>> >>> That's why I'm confused. >>> Steve >> >> Digging a bit further, here is the output of mount on the client: >> http://dl.dropbox.com/u/45150875/krb5testnfs.png >> >> And this appears immediately after the mount: >> http://dl.dropbox.com/u/45150875/krb5nfstmp.png >> >> Most of the documentation tells you to stick nfs into the client keytab as >> well as the server keytab, but here, I only have the principal on the >> server. >> >> What am I missing? > I think client simply falls back to 'host' if nfs entry is not available. > > Tigran. I completely cleared /tmp and stuck nfs/client back in the client keytab to see if it made any difference. It still wasn't used. I got exactly the same tickets as above. It looks as though this is a recent change to nfs-utils. I think this post explains why I see nfs being authenticated not by the /nfs/client nor /host/client but by the client$ principal. https://fedorahosted.org/pipermail/sssd-devel/2010-August/004332.html I'm new to all this so nothing is certain for me the moment! Does this make sense? Cheers, Steve