NFSv4 잘못된 유효 사용자/소유자, sec=krb5 익명 사용자로 압축 마운트

글쎄, 나는 그것이 이해할만한 가치가 있다고 생각합니다.어떻게NFS와 Kerberos는 사용자를 다루고 여기서 주체 이름이 어떻게 작용하는지를 다룹니다. 이는 대부분의 가이드에서 종종 무시되는 주제입니다.

---

Kerberos 기반 NFS에서는 다음 간의 차이점을 이해해야 합니다.

• 파일 작업을 수행하는 유효 사용자

  파일 작업에 대한 유효(서버 로컬) 사용자는 Kerberos에 의해 결정됩니다.로컬 인증 인터페이스,지금 바로auth_to_local태그를 통한 구성, 지정되지 않은 경우 기본값은 이고 auth_to_local = DEFAULT해당 작업은 다음과 같이 정의됩니다.

  주체 이름은 로컬 사용자 이름으로 사용됩니다. 주체에 여러 구성 요소가 있거나 기본 영역에 없는 경우 이 규칙이 적용되지 않으며 변환이 실패합니다.

  변환이 실패하면 익명 사용자( nobody:nogroup또는 anonuid:anongid내보내기 항목에 지정된 경우) 로 간주됩니다.

  관련 토론에 좋은 설명이 나와 있습니다.

• 이 파일 작업의 매개변수/결과

  NFS 서버가 파일 작업을 수행하는 경우

  1. 매개변수는 클라이언트 제공 사용자에서 서버 로컬 사용자로 매핑되어야 합니다( chown명령).
  2. 결과는 클라이언트 로컬 사용자에게 다시 매핑되어야 합니다( ls명령)

  이는 또는 (보통) id_resolver에 지정된 upcaller에 의해 처리 됩니다./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

그 이유 중 하나는 다음과 같습니다.윙바인더는 삼바(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:저도 사용자의 간단한 호출로 클라이언트 키탭을 올바르게 생성했습니다. 다른 것은 필요하지 않습니다.