Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-ww0-f44.google.com ([74.125.82.44]:36967 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753014Ab2BBNFT convert rfc822-to-8bit (ORCPT ); Thu, 2 Feb 2012 08:05:19 -0500 Received: by wgbdt10 with SMTP id dt10so2539088wgb.1 for ; Thu, 02 Feb 2012 05:05:18 -0800 (PST) MIME-Version: 1.0 Reply-To: tigran.mkrtchyan@desy.de In-Reply-To: <4F2A74A7.4060905@steve-ss.com> References: <4F2A2F9E.6030908@steve-ss.com> <4F2A74A7.4060905@steve-ss.com> Date: Thu, 2 Feb 2012 14:05:18 +0100 Message-ID: Subject: Re: nfs4 keytabs [was:Re: where can I ask user qns about nfs4]? From: Tigran Mkrtchyan To: steve Cc: linux-nfs@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: 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? Tigran. > > And yes, we found out very early on that idmapd had to be running at both > ends. > > Thanks for the reply. You've got me thinking. > Steve