個人用にKerberized NFSv4を設定しています。
- NFSおよびKDCの手動構成
- ネームサーバーなし（
/etc/hostsオーバーライドを使用）、LDAPなし - すべてのコンピュータで同じユーザー（IDが必ずしも同じである必要はありません）とすべてのセキュリティモードでIDマッピングを有効にする（
nfs4_disable_idmapping「N」に設定）
Ubuntu 20.04 LTSを実行している2台のコンピュータがあります。
arhiv.pecar（ローカルアドレス192.168.56.200）にはNFSサーバーとKDCがあります。client.pecar（ローカルアドレス192.158.56.100）はクライアントです。
すべてのパイプが機能しているようで、共有をうまくマウントできますが、
共有が次のようにエクスポートされた場合
sec=sysサーバー
exportfs -v出力/srv/export <world>(rw,async,wdelay,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)クライアント
mount出力arhiv.pecar:/srv/export on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.56.100,local_lock=none,addr=192.168.56.200)- ルートには完全な読み取り/書き込みアクセス権があります。
- 十分な権限が設定されると、他のユーザーがファイルを読み書きできます。
nfsidmapアクティブなクライアントのファイルを一覧表示します。正しい翻訳ユーザー名/グループchownクライアントから可能、ユーザー名/グループを正しく翻訳します。
ファイルはuid / gidの下に作成されます。顧客、これは間違ったサーバーの uid/gid
サーバーに同じ uid を持つユーザーがいる場合、無効な所有者にマップされます。そうでなければ、所有者は
nobody:4294967294有効なユーザーは、クライアントuidで指定されたユーザーのようです。
私の考えでは、これ既知の欠点使用するとき
sec=sys共有が次のようにエクスポートされた場合
sec=krb5サーバー
exportfs -v出力/srv/export <world>(rw,async,wdelay,no_root_squash,no_subtree_check,sec=krb5p:krb5,rw,secure,no_root_squash,no_all_squash)クライアント
mount出力arhiv.pecar:/srv/export on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.56.100,local_lock=none,addr=192.168.56.200)- すべてのユーザーには読み取り権限がありますが、どのユーザー（ルートも含む）には自分が所有するファイル/フォルダに対する書き込み権限がありません。
- フォルダにファイルを作成すると、
o+w匿名ユーザー（nobody:nogroupまたはanonuid:anongidエクスポートアイテムで指定されている場合）の下にファイルが作成されます。 nfsidmapアクティブなクライアントのファイルを一覧表示します。正しい翻訳ユーザー名/グループchownお客様から失敗するそしてOperation not permitted.
有効なユーザーは匿名ユーザーのようです。
ここで何が間違っているのかわからないので、コミュニティから洞察を得ることができることを願っています。
/etc/hosts要求に応じて関連する設定ファイル（サービスリスト、カーネルモジュール）を提供できます。/etc/krb5.conf/etc/idmapd.conf/etc/default/nfs-common
ベストアンサー1
まあ、私はそれが理解する価値があると思います。どのようにNFSとKerberosはユーザーを扱い、ここでプリンシパル名がどのように機能するかについて説明します。これはほとんどのガイドでしばしば無視されるトピックです。
KerberosベースのNFSでは、次の違いを理解する必要があります。
ファイル操作を実行する実効ユーザー
ファイル操作の有効な（サーバーローカル）ユーザーはKerberosによって決定されます。ローカル認証インターフェース今すぐ
auth_to_localタグによる設定、指定されていない場合、デフォルト値はで、auth_to_local = DEFAULTその操作は次のように定義されます。プリンシパル名はローカルユーザー名として使用されます。サブジェクトに複数のコンポーネントがある場合、または既定の領域にない場合、このルールは適用されず、変換は失敗します。
変換が失敗した場合は、匿名ユーザー（
nobody:nogroupまたはanonuid:anongidエクスポート項目で指定されている場合）と見なされます。このファイル操作のパラメータ/結果
NFS サーバーがファイル操作を実行する場合
- パラメーターは、クライアント提供ユーザーからサーバーローカルユーザーにマップする必要があります（
chownコマンド）。 - 結果はクライアントローカルユーザーに再マップする必要があります（
lsコマンド）
これは、または（通常）
id_resolverで指定されたアップケーラーによって処理されます。/etc/request-key.conf/etc/request-key.d/*nfsidmapユーザー名はホスト間で文字列として送信され、
user@dns_domain両方のローカルuids / gidにマップされます。- パラメーターは、クライアント提供ユーザーからサーバーローカルユーザーにマップする必要があります（
ファイル操作を実行する有効なユーザーはチケットに由来します（したがって、私たちが認証する主体が重要です）。いいえファイル操作を要求するローカル実行プロセスのuid。
したがって、有効なユーザーマッピングが機能するにはusername（効果的にusername@REALM）プリンシパルを作成する必要があり、より複雑なプリンシパル名を使用する場合は、ここで説明されているようにauth_to_local適切なマッピングを提供する必要があります。/etc/krb5.conf
- https://access.redhat.com/articles/4040141
- https://blog.samoylenko.me/2015/04/15/hadoop-security-auth_to_local-examples/
- https://community.cloudera.com/t5/Community-Articles/Auth-to-local-Rules-Syntax/ta-p/245316
ユーザーごとそれ自体が必要user/client-fqdnサーバーローカルユーザーにマッピングするために使用される主体（）。
サービス主体は、サービス自体によって使用および承認されます。おそらく、ユーザーはそれにアクセスする必要はありません（ユーザーのkeytabには保持する必要があります/etc/krb5.keytabが、ユーザーのkeytabには保持しないでください）。
ユーザーキータブの場所はディストリビューションによって異なります。これを使用して、krb5-configビルドで期待するものを決定します。
USER_KEYTAB=$(euid=$EUID; eval echo $(krb5-config --defcktname | tr % $ | sed 's/FILE://'))
以下は、Kerberized NFS 経由でユーザーのマッピングを正しく構成する方法の簡単なデモです。
次の設定は、このガイドで構成されたCentOSシステムでテストされています（ガイドはCentos 7用で、少し追加のCentos 8でテストされました）。
https://www.linuxhelp.com/how-to-set-up-nfs-server-with-kerberos-based-authentication
# Start kadmin on client machine (I assume that you have the root/admin principal already set up)
#
[root@nfsclient ~]# kadmin -p root/admin
Authenticating as principal root/admin with password.
Password for root/[email protected]:
kadmin: addprinc -randkey -clearpolicy host/nfsclient
Principal "host/[email protected]" created.
kadmin: addprinc -randkey -clearpolicy nfs/nfsclient
Principal "nfs/[email protected]" created.
kadmin: ktadd -k /tmp/krb5.keytab host/nfsclient
Entry for principal host/nfsclient with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/krb5.keytab.
...
kadmin: ktadd -k /tmp/krb5.keytab nfs/nfsclient
Entry for principal nfs/nfsclient with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/krb5.keytab.
...
kadmin: addprinc -randkey -clearpolicy testuser
Principal "[email protected]" created.
kadmin: ktadd -k /tmp/client.keytab testuser
Entry for principal testuser with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/client.keytab.
...
kadmin: quit
# Set up the default keytab (service principals)
[root@nfsclient ~]# mv /tmp/krb5.keytab /etc/krb5.keytab
[root@nfsclient ~]# chown root:root /etc/krb5.keytab
# Set up user keytab
[root@nfsclient ~]# mv /tmp/client.keytab /var/kerberos/krb5/user/$(id -u testuser)/client.keytab
[root@nfsclient ~]# chown testuser:testuser /var/kerberos/krb5/user/$(id -u testuser)/client.keytab
# Mount the filesystem
mount nfsserver.kdc.com:/kerberos /mnt
# Test the user
[root@nfsclient ~]# sudo -i -u testuser
# Check that the users client.keytab, is being picked up
# (can access nfs share)
#
# and that the correct effective user is now used for file operation
# (derived from default principal and mapped to server-local user)
# - the server should also have a `testuser` user
#
[testuser@nfsclient ~]$ touch /mnt/testfile
[testuser@nfsclient ~]$ ls -la /mnt/testfile
-rw-rw-r--. 1 testuser testuser 0 Jun 23 16:31 /mnt/testfile
# After accesses one can check the keys that have been retrieved on
[testuser@nfsclient ~]$ klist
Ticket cache: KCM:1051:17737
Default principal: [email protected]
Valid starting Expires Service principal
06/23/2021 16:06:12 06/24/2021 16:06:12 krbtgt/[email protected]
renew until 06/23/2021 16:06:12
06/23/2021 16:06:12 06/24/2021 16:06:12 nfs/[email protected]
renew until 06/23/2021 16:06:12