From owner-freebsd-stable@FreeBSD.ORG Thu Jun 28 20:01:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B759106566C for ; Thu, 28 Jun 2012 20:01:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id E2A928FC18 for ; Thu, 28 Jun 2012 20:01:24 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta01.emeryville.ca.mail.comcast.net with comcast id TvEn1j0031Y3wxoA1w1Q79; Thu, 28 Jun 2012 20:01:24 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta15.emeryville.ca.mail.comcast.net with comcast id Tw1P1j00E4NgCEG8bw1PTY; Thu, 28 Jun 2012 20:01:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q5SK1L1o048740; Thu, 28 Jun 2012 14:01:21 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Herbert Poeckl In-Reply-To: <4FEC694C.6060408@ist.tugraz.at> References: <686121506.2338267.1340842067785.JavaMail.root@erie.cs.uoguelph.ca> <4FEC694C.6060408@ist.tugraz.at> Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Jun 2012 14:01:21 -0600 Message-ID: <1340913681.1110.84.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Need help with nfsv4 and krb5 access denied X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:01:25 -0000 On Thu, 2012-06-28 at 16:25 +0200, Herbert Poeckl wrote: > On 06/28/2012 02:07 AM, Rick Macklem wrote: > > The NFS server will authenticate nfs/tmp2.ist.intra against the Kerberos > > KDC, using the information in the keytab entry. The whole idea behind a > > host based principal like "nfs/tmp2.ist.intra" is that it can only be > > used by the host "tmp2.ist.intra". As such, when the Kerberos KDC receives > > an auathentication request for nfs/tmp2.ist.intra, it will DNS resolve > > tmp2.ist.intra (to 192.168.1.164 it seems) and will compare that to the > > IP address the authentication request is received from. I think this > > means the KDC will fail the request if it is sent to the KDC from 192.168.6.2. > > Yes, of course. There is and will be no traffic on 192.168.6.2. > > What I've tried to say (and probably failed), is that we have a network > card in the machine, where the result is always access denied (with the > correct server IP address set for that NIC). > > > > Your KDC should be logging something when this fails and the traffic you'd > > need to look at is the traffic between the NFS server and the KDC. (I'd use > > wireshark, since it probably knows a fair bit about Kerberos.) > > Thank you, I will give it a try. > > Kind regards, > Herbert When something in software works fine with one NIC but not another (nearly-) identical one, the first thing that comes to my mind is that the MAC address on the card is being used by the software as a sort of UUID. I had that happen with a commercial software once; when I changed NICs in the machine the software stopped working and said it wasn't registered on that machine. (I would have been annoyed except this sophisticed "security system" was circumvented by deleting a file that wasn't even hard to find, and it automatically re-authorized itself on the next run using the new MAC address.) -- Ian