NFS4 Export

UCS - Univention Corporate Server
#62

Ich habe nun alles immer und immer wieder wiederholt aber es funktioniert einfach nicht. Die Keytab sind angelegt. Auf dem Master:

root@tux:~# ktutil list
FILE:/etc/krb5.keytab:

Vno  Type                     Principal                     Aliases
 40  des-cbc-crc              HOST/tux@GEHR.LAN             
 40  des-cbc-crc              HOST/tux.gehr.lan@GEHR.LAN    
 40  des-cbc-crc              host/tux.gehr.lan@GEHR.LAN    
 40  des-cbc-crc              ldap/tux.gehr.lan@GEHR.LAN    
 40  des-cbc-crc              TUX$@GEHR.LAN                 
 40  des-cbc-md5              HOST/tux@GEHR.LAN             
 40  des-cbc-md5              HOST/tux.gehr.lan@GEHR.LAN    
 40  des-cbc-md5              host/tux.gehr.lan@GEHR.LAN    
 40  des-cbc-md5              ldap/tux.gehr.lan@GEHR.LAN    
 40  des-cbc-md5              TUX$@GEHR.LAN                 
 40  arcfour-hmac-md5         HOST/tux@GEHR.LAN             
 40  arcfour-hmac-md5         HOST/tux.gehr.lan@GEHR.LAN    
 40  arcfour-hmac-md5         host/tux.gehr.lan@GEHR.LAN    
 40  arcfour-hmac-md5         ldap/tux.gehr.lan@GEHR.LAN    
 40  arcfour-hmac-md5         TUX$@GEHR.LAN                 
 40  aes128-cts-hmac-sha1-96  HOST/tux@GEHR.LAN             
 40  aes128-cts-hmac-sha1-96  HOST/tux.gehr.lan@GEHR.LAN    
 40  aes128-cts-hmac-sha1-96  host/tux.gehr.lan@GEHR.LAN    
 40  aes128-cts-hmac-sha1-96  ldap/tux.gehr.lan@GEHR.LAN    
 40  aes128-cts-hmac-sha1-96  TUX$@GEHR.LAN                 
 40  aes256-cts-hmac-sha1-96  HOST/tux@GEHR.LAN             
 40  aes256-cts-hmac-sha1-96  HOST/tux.gehr.lan@GEHR.LAN    
 40  aes256-cts-hmac-sha1-96  host/tux.gehr.lan@GEHR.LAN    
 40  aes256-cts-hmac-sha1-96  ldap/tux.gehr.lan@GEHR.LAN    
 40  aes256-cts-hmac-sha1-96  TUX$@GEHR.LAN                 
 41  des-cbc-crc              HOST/tux@GEHR.LAN             
 41  des-cbc-crc              HOST/tux.gehr.lan@GEHR.LAN    
 41  des-cbc-crc              host/tux.gehr.lan@GEHR.LAN    
 41  des-cbc-crc              ldap/tux.gehr.lan@GEHR.LAN    
 41  des-cbc-crc              TUX$@GEHR.LAN                 
 41  des-cbc-md5              HOST/tux@GEHR.LAN             
 41  des-cbc-md5              HOST/tux.gehr.lan@GEHR.LAN    
 41  des-cbc-md5              host/tux.gehr.lan@GEHR.LAN    
 41  des-cbc-md5              ldap/tux.gehr.lan@GEHR.LAN    
 41  des-cbc-md5              TUX$@GEHR.LAN                 
 41  arcfour-hmac-md5         HOST/tux@GEHR.LAN             
 41  arcfour-hmac-md5         HOST/tux.gehr.lan@GEHR.LAN    
 41  arcfour-hmac-md5         host/tux.gehr.lan@GEHR.LAN    
 41  arcfour-hmac-md5         ldap/tux.gehr.lan@GEHR.LAN    
 41  arcfour-hmac-md5         TUX$@GEHR.LAN                 
 41  aes128-cts-hmac-sha1-96  HOST/tux@GEHR.LAN             
 41  aes128-cts-hmac-sha1-96  HOST/tux.gehr.lan@GEHR.LAN    
 41  aes128-cts-hmac-sha1-96  host/tux.gehr.lan@GEHR.LAN    
 41  aes128-cts-hmac-sha1-96  ldap/tux.gehr.lan@GEHR.LAN    
 41  aes128-cts-hmac-sha1-96  TUX$@GEHR.LAN                 
 41  aes256-cts-hmac-sha1-96  HOST/tux@GEHR.LAN             
 41  aes256-cts-hmac-sha1-96  HOST/tux.gehr.lan@GEHR.LAN    
 41  aes256-cts-hmac-sha1-96  host/tux.gehr.lan@GEHR.LAN    
 41  aes256-cts-hmac-sha1-96  ldap/tux.gehr.lan@GEHR.LAN    
 41  aes256-cts-hmac-sha1-96  TUX$@GEHR.LAN                 
  2  des-cbc-crc              nfs/tux.gehr.lan@GEHR.LAN     
  2  des-cbc-crc              nfs-tux@GEHR.LAN              
  2  des-cbc-md5              nfs/tux.gehr.lan@GEHR.LAN     
  2  des-cbc-md5              nfs-tux@GEHR.LAN              
  2  arcfour-hmac-md5         nfs-tux@GEHR.LAN              
  2  aes128-cts-hmac-sha1-96  nfs-tux@GEHR.LAN              
  2  arcfour-hmac-md5         nfs/tux.gehr.lan@GEHR.LAN     
  2  aes128-cts-hmac-sha1-96  nfs/tux.gehr.lan@GEHR.LAN     
  3  des-cbc-md5              host/pc001.gehr.lan@GEHR.LAN  
  3  des-cbc-crc              host/pc001.gehr.lan@GEHR.LAN  
  2  aes256-cts-hmac-sha1-96  nfs-tux@GEHR.LAN              
  2  aes256-cts-hmac-sha1-96  nfs/tux.gehr.lan@GEHR.LAN     
  3  arcfour-hmac-md5         host/pc001.gehr.lan@GEHR.LAN  
  3  aes128-cts-hmac-sha1-96  host/pc001.gehr.lan@GEHR.LAN  
  3  aes256-cts-hmac-sha1-96  host/pc001.gehr.lan@GEHR.LAN

auf dem Client:

root@pc001:~# ktutil list
FILE:/etc/krb5.keytab:

Vno  Type                     Principal                     Aliases
  3  des-cbc-md5              host/pc001.gehr.lan@GEHR.LAN  
  3  des-cbc-crc              host/pc001.gehr.lan@GEHR.LAN  
  3  arcfour-hmac-md5         host/pc001.gehr.lan@GEHR.LAN  
  3  aes128-cts-hmac-sha1-96  host/pc001.gehr.lan@GEHR.LAN  
  3  aes256-cts-hmac-sha1-96  host/pc001.gehr.lan@GEHR.LAN

Auf dem Master fällt auf das die Key’s des NFS die Version 2 haben und nicht mit der 41 von LDAP & Co korrospondieren. Kann dies das Problem sein?

#63

Was sind für diesen Authentifizierungsprozess (Samba4, NFS, Kerberos) die relevanten Logfile damit ich zumindest eine Möglichkeit habe dem Fehler nachzustellen. In den Logfiles ist ja nichts ersichtlich :frowning:

#64

After three days and felt 20 cans of coffee it is now running. Works on a standard Ubuntu client:

not! I’ll put the steps together and post later.

#65

NFS4 with Kerberos. Yes this sounds like Christmasgifts…

#66

Some clarifications:

  1. /etc/krb5.keytab stores long-term credentials for automatic login. Normal tickets are relatively short-lived (4h-1d) and need to be renewed regularly. For a user it is okay to authenticate once a day and to renew it on-the-fly during the day, but not for services running 24×7. Therefore they need a way to get a ticket without interactive user intervention. Using ktutil you can export credentials to a file krb5.keytab and tell kinit -k -t krb5.keytab to use that file to acquire a ticket.
    The content of that krb5.keytab file is as good as a password and everybody with access to that file can get a ticket. So this is similar to those /etc/*.secret files found on UCS systems.
    Because of that Kerberos has a built-in mechanism to revoke such a file: Es you ever lose such a file you simply can export the key again to a new file. Internally this increments the Key Version Number (KVNO), which invalidates all previous keys. So if you have a krb5.keytab with a KVNO lower then the current one, that file will not work.
    By default kutil will always increment the KVNO and thus will always invalidate previous exports. Because of that we use the “trick” to query the current KVNO from LDAP and tell kutil the export exactly that version of the key.
  2. A krb5.keytab file must exist on all system: The server must have one with the nfs/FQHN@REALM credentials and the clients one with their host/FQHN@REALMS one. If done “correctly” you even can run kutil on the client, authenticate as an administrator there and then do the export locally. But that requires Kerberos to be configured in such a way to allow that. Currently there is no default protocol to export that crytographical private key material: The Kerberos implementation from MIT and Heimdal (and Samba?) are incompatible.
    Therefore it most often is easier to export that file on the Kerberos server itself to a temporary file and copy that file to the target system. Because of 1. you have to be very careful to not export the wrong key, as it would change the KVNO and invalidate you previous keys.
  3. There is no single NFS server process, but NFS requires a multitude of services to cooperate: On the server you have the NFSd “process” in the Linux kernel itself, but it (may) require portmapper (nowadays replaced by rpcbind), the rpc.mountd helper for handling the mount protocol (before v4 it was a separate protocol, but the service is even required with v4 as the Linux kernel delegates client verification to it), the rpc.idmapd to map numeric user IDs, rpc.statd for v3 to handle server reboots, rpc.quotad for quota support, nlockmgr for v3 locking. and rpc.svcgssd to handle the server-part of the Kerberos protocol.
    On the client you also have a bunch of services which must be running: rpc.gssd is there to handle the client-part of the Kerberos protocol, plus sometimes rpc.idmapd as well.
    On top of that (or more correct below of that) you also need working DNS, networking and running Kerberos services.
    Because starting and stopping those services is quiet complex /lib/systemd/system/nfs-config.service exists, which is used by Debian and UCS to configure most services involved with NFS: It calls /usr/lib/systemd/scripts/nfs-utils_env.sh to parse the configuration files /etc/default/nfs-* and extracts the information in a format usable by systemd. If you modify any of those files below /etc/ you should restart that service with systemctl restart nfs-config.service to re-parse those files.
    Before the switch from SysV-Init to systemd the init scripts were quiet complex and tried to determine, if starting a service was required. If for example you never created a /etc/krb5.keytab file the NFS-Server-Part for Kerberos would not start; similar for the Client-side. It may be that on some systems the services are still disabled and must be unmasked to become usable: systemctl unmask xxx.service.
  4. Strictly speaking NFSv3 vs. NFSv4 is independent from sec=system vs. sec=krb: You can both run NFSv3 and NFSv4 with or without Kerberos. NFSv4 mostly improved the protocol to make it more efficient (especially for LAN connections), but by default NFSv4 has the same issues with authentication as NFSv3.
    So the title of this thread is now wrong as it more is about setting up Kerberos then getting NFSv4-only to work. For that there ist this Bug #50730 Feature request.
2 Likes
#67

I have now found a good variant for me.
The Ubuntu (or Mint) client I join with the ADS join script. Afterwards I configure the NFS4 server for Kerberos as described here in the article.

On the client I mount everything via pam_mount. The user home as NFS because the Linux desktop has problems when the home is mounted via CIFS. The data-shares via CIFS so that “force creat … user, mask” is used.

#68

I guess you mean “NFSv3 vs. NFSv4”?

Mastodon