From owner-freebsd-users-jp@freebsd.org Sat Sep 22 11:47:37 2018 Return-Path: Delivered-To: freebsd-users-jp@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 886F210950C5 for ; Sat, 22 Sep 2018 11:47:37 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail.allbsd.org (mx-int.allbsd.org [IPv6:2001:2f0:104:e002::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gatekeeper.allbsd.org", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EB14F8FBB0 for ; Sat, 22 Sep 2018 11:47:36 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail-d.allbsd.org ([IPv6:2409:11:a740:c00:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id w8MBlBRb075409 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Sat, 22 Sep 2018 20:47:21 +0900 (JST) (envelope-from hrs@allbsd.org) Received: from alph.d.allbsd.org ([IPv6:2409:11:a740:c00:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id w8MBl50t057805 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 22 Sep 2018 20:47:05 +0900 (JST) (envelope-from hrs@allbsd.org) Received: from localhost (localhost [IPv6:0:0:0:0:0:0:0:1]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id w8MBl3ed057802; Sat, 22 Sep 2018 20:47:05 +0900 (JST) (envelope-from hrs@allbsd.org) Date: Sat, 22 Sep 2018 20:46:50 +0900 (JST) Message-Id: <20180922.204650.2028642500513623137.hrs@allbsd.org> To: hiroo.ono+freebsd@gmail.com Cc: freebsd-users-jp@freebsd.org From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Sep_22_20_46_50_2018_843)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.allbsd.org [IPv6:2001:2f0:104:e001:0:0:0:41]); Sat, 22 Sep 2018 20:47:29 +0900 (JST) X-Spam-Status: No, score=4.2 required=13.0 tests=CONTENT_TYPE_PRESENT, ISO2022JP_BODY,JOUHOU,QENCPTR1,RCVD_IN_AHBL,RCVD_IN_AHBL_PROXY, RCVD_IN_AHBL_SPAM,RDNS_NONE,URIBL_SC2_SURBL,URIBL_XS_SURBL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.allbsd.org Subject: [FreeBSD-users-jp 96316] Re: NFSv4 + Kerberos X-BeenThere: freebsd-users-jp@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion relevant to FreeBSD communities in Japan List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2018 11:47:37 -0000 ----Security_Multipart(Sat_Sep_22_20_46_50_2018_843)-- Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit 佐藤です。もう解決しているかも知れませんが... Hiroo Ono (小野寛生) wrote in : hi> samba4 を Active Directory の DC にしているのですが、こいつを KDC にして NFSv4 で hi> -sec=krb5 でマウントしたいと考えています。 hi> hi> https://wiki.freebsd.org/KerberizedNFS hi> https://lists.samba.org/archive/samba/2014-November/186562.html hi> hi> を参考にしました。 hi> hi> -sec=sys で NFSv4 でマウントできるところまでは確認しました。 hi> その後、下記の手順で keytab を作成して、 hi> # mount_nfs -o nfsv4,sec=krb5 image.oikumene.ukehi.net:/exports/data /mnt hi> hi> としたのですが、マウントはできて、ls でファイルのリストは出てくるものの、 hi> # cat /mnt/data.txt hi> とすると hi> hi> nfsv4 err=10016 hi> cat: /mnt/data.txt: Input/output error hi> hi> とエラーになります。 ぱっと読む限りでは、NFS サーバのサービスプリンシパルが 大文字で書いてあるところが間違いだと思います。 マウントしてから KDC のログを見るとわかると思いますが、 この構成なら nfs/image.oikumene.ukehi.net@OIKUMENE.UKEHI.NET という プリンシパル名が使われるはずです。 また、メールにある exports の V4: 行にある "kerb5p" はスペルが間違っています。 /exports/data は / と同じパーティションであれば -sec のオプションが 適用されるはずですが、間違えやすいので同じ -sec を付けることをお勧めします。 プリンシパル名を修正するだけで動くかも知れません。 ただ、この設定ではマウントする前に kinit しないとサービスプリンシパルのチケットが とれないので、起動時にマウントすることができないと思います。 NFSv4 + Kerberos を設定する場合、次のようにするのがおすすめです。 * NFS サーバで NFS 用のサービスプリンシパルを作成する ドキュメントには kadmin を使った例がありますが、 kadmind を動かしているのであれば、ktutil を使うと 新しいプリンシパルの作成と keytab への挿入が一度にできます。 server# ktutil get nfs/`hostname` FQDN として指定している名前は、逆引きが正しく行なえる 必要があります。DNS で設定するのが一般的ですが、 KDC, クライアント, サーバで情報が一致していれば良いので 3 者の /etc/hosts を手動でそろえても動かせます。 * NFS クライアントで host/FQDN というサービスプリンシパルを作成する マウントするためのプリンシパルを作成します。理由は次のとおりです。 ログインユーザのプリンシパルでもマウントは可能ですが、 起動時に自動的にマウントするには、 そのユーザのチケットをあらかじめ keytab に入れるか 起動のたびに kinit するか、いずれかの作業が必要です。 ログインユーザのチケットを keytab に入れて使うと セキュリティ的に問題なので、通常は専用のプリンシパルを用意します。 root/FQDN, nfs/FQDN, host/FQDN あたりが良く使われます。 下記の例は host/FQDN を使う場合です。 client# ktutil get host/`hostname` * サーバ・クライアント・KDC の時刻が合っていることを確認する ずれているとチケット要求が失敗します。 * サーバ・クライアントで gssd が上がっていることを確認する gssd_enable="YES" を rc.conf に書く必要があります。 ここまで作業したら、クライアントで次の順番で動作を確認します。 1. kdestroy して、自分のユーザプリンシパルのチケットのキャッシュを消す。 2. クライアントでマウントする。 client# mount -o rw,nfsv4,sec=krb5p,gssname=host,noinet6 server.fqdn:/dir /mnt クライアントは KDC に host/FQDN でアクセスし、サーバの nfs/FQDN (上の例だと nfs/server.fqdn) のチケットを取り出します。ここで err=10016 が出る場合、 上記の準備のどれかが欠けています。KDC 側のアクセスログを調べて、 ちゃんとチケットを取りにいっているか確認しましょう。 3. ls -al /mnt してみる。 ここでは次のエラーが出るはずで、エラーが出るのが正しいです。 nfsv4 err=10016 ls: /mnt: Input/output error 4. kinit する。 自分のユーザで kinit し、チケットを取ります。 5. もう一度 ls -al /mnt する。 今度はエラーにならないはずですが、owner の情報が nobody:nogroup になって見えると思います。 このアクセスの際、nfs/FQDN のチケットを取得します。 3 で失敗するのは、kinit する前は TGT がないので nfs/FQDN が 取得できないのが原因です。 ここで klist を実行すると、nfs/FQDN のチケットを 取っていることがわかります。 6. nfsuserd をサーバ・クライアントで起動する rc.conf に nfsuserd_enable="YES" として デーモンを起動します。 7. もう一度 ls -al /mnt する。 owner がきちんと表示されるはずです。 NFSv4 はサーバから UID を数値ではなく文字列で送るため、 サーバと同じ名前のユーザがクライアントに存在しない場合は nobody:nogroup になります。 確認できたら、rc.conf と fstab に設定を書き込んで再起動させ、 自動でマウントされるかどうか確認すると良いでしょう。 gssd が上がらないとマウントに失敗しますので、fstab には late オプションを 指定しておくと良いかも知れません。 -- Hiroki ----Security_Multipart(Sat_Sep_22_20_46_50_2018_843)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iEYEABECAAYFAlumK6oACgkQTyzT2CeTzy3daACeO1eSJ/mcaNzslpo72jQZXjqs u/0AoIOW1OJ1P9l9MjLP38SUVJcWoI5K =Uvdu -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Sep_22_20_46_50_2018_843)----