On Thu, Feb 2, 2012 at 12:33 PM, steve <steve@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html