☰

NFSv4無効な有効ユーザー/所有者、sec = krb5匿名ユーザーとして圧縮マウント

tag-icon • tag-icon linux kerberos nfsv4
NFSv4無効な有効ユーザー/所有者、sec = krb5匿名ユーザーとして圧縮マウント

個人用に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 サーバーがファイル操作を実行する場合

    1. パラメーターは、クライアント提供ユーザーからサーバーローカルユーザーにマップする必要があります（chownコマンド）。
    2. 結果はクライアントローカルユーザーに再マップする必要があります（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

ユーザーごとそれ自体が必要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

答え2

その理由の1つは次のとおりです。ウィングバインダーはSamba（smb.conf）構成ですwinbind use default domain = no。

このデフォルト設定では、認証時にユーザー名の前にプレフィックスが付けられることが予想されますDOMAIN\（例DOMAIN\alice：：）。

望むより：https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#winbindusedefaultdomain

としてログインするのではなく、単純にyesログインできるように、このパラメータ（クライアントとサーバーの両方）を設定する必要があります。su - alicesu - DOMAIN\\alice

NFSサーバーがKerberosチケットと比較する名前は短いです。デフォルトの長いバージョンでは、gssはユーザーを見つけることができないので、「nobody」に圧縮します。

答えに関しては@tpecarkinit：私はユーザーの簡単な呼び出しでクライアントキータブを正しく生成しました。他は必要ありません。

関連情報