Kerberos-LDAP-NFSv4 HOWTO

Kerberos/LDAP/NFSv4 HOWTOThese instructions are specific to Redhat Enterprise Linux (RHEL), Version 4. A combination of RHEL AS (for servers) and RHEL WS (for workstations) were used. Interoperability with other clients is possible, but is not addressed here (but refer to the references below for links that may be helpfull).The goal of this document is to describe how to setup a network so that the following are attained.∙User authentication is done using a central Kerberos server.∙User information (UID/GID/home directories) are stored in an LDAP directory.∙Store NFS automount information in LDAP.∙NFSv4 authentication using Kerberos is possible with support for legacy NFSv3 mounts.This document will not explain why kerberos, ldap or NFSv4 are good things. If you aren’t convinced, then read up on the subject. If you are convinced, then read on.PrerequisitesTime SynchronizationAll machines that will participate in kerberos authentication must have a reliable, synchronized time source. Most large orgainization offer their own time sources. You can use the RHEL configuration toolsystem-config-time to set this up.If the different in time between systems varies by more than a small amount (usually five minutes), systems will not be able to authenticate.Host NamesAll hosts must have their hostname set to the fully qualified hostname as reported by DNS. Both forward and reverse mapping must work properly.[root@phoenix ~]# hostnamephoenix.physik.unizh.ch[root@phoenix ~]# dig phoenix.physik.unizh.ch +short130.60.164.29[root@phoenix ~]# dig -x 130.60.164.29 +shortphoenix.physik.unizh.ch.The host may be referenced by a CNAME, but the official host name (as reported by hostname) must be an ‘A’ record. This is important; if youdon’t have this setup properly then some things will work, while other things will fail mysteriously.If the host name does not match the reverse DNS lookup, Kerberos authentication will fail.PackagesBefore starting, verify that the necessary RPM packages are installed. The packages required are different for a client or a server.SPECIAL NOTE: Red Hat Enterprise Linux 4 installed on a 64-bit processor can sometimes install the 32 bit version of packages. When verifying that the packages are correctly installed, make sure that the 64 bit version is there if you are on a 64 bit architecture. I had endless grief getting ldap to work until I realized that the Red Hat installer had installed the 32 bit version of cyrus-sasl-gssapi on our 64 bit machine. All of the other packages were correct, or both were installed. To verify a package, use the following command.[root@coma ~]# rpm -q --queryformat="%{n}-%{v}-%{r}.%{arch}\n"cyrus-sasl-gssapicyrus-sasl-gssapi-2.1.19-5.EL4.i386[root@coma ~]# up2date --arch=x86_64 cyrus-sasl-gssapiFetching Obsoletes list for channel: rhel-x86_64-as-4...Fetching rpm headers...Installing...1:cyrus-sasl-gssapi ########################################### [100%][root@coma ~]# rpm -q --queryformat="%{n}-%{v}-%{r}.%{arch}\n"cyrus-sasl-gssapicyrus-sasl-gssapi-2.1.19-5.EL4.i386cyrus-sasl-gssapi-2.1.19-5.EL4.x86_64If you are on a 32 bit architecture, then this is something that you don’t need to worry about.Client Packages∙krb5-libs∙krb5-workstation∙pam_krb5∙cyrus-sasl-gssapi∙openldap-clientsServer Packages (KDC and LDAP)The server will need all of the client package in addition to the following.∙krb5-server∙openldap-serversWhat's in a Name?At this point, you should have all of your machines registered in DNS under one (or more) domains. In our case, our machines are in the physik.unizh.ch domain. We also authenticate our supercomputers which are in the zbox.physik.unizh.ch domain.You need to choose a kerberos realm. A kerberos realm is completely different from a DNS domain, but in most cases you will want to use the same name. By convention, kerberos realms are all upper case. Our kerberos realm is PHYSIK.UNIZH.CH. This realm serves both the physik.unizh.ch and the zbox.physik.unizh.ch DNS domains.There is also a distinction between a unix username and a kerberos principal. You will be creating a kerberos principal for every unix username for which you want to use kerberos authentication. In addition, you will be creating additional kerberos principals for additional purposes (more on this later).In this document, when I say domain, I mean an DNS domain. When I say realm, I mean a kerberos realm. When I say username, I mean a unix user and when I say principal, I mean a kerberos principal.KerberosKerberos Server (KDC)The first step is to setup a kerberos server (or KDC).File ModificationsThere are a number of files that have to be manually edited on the server.Edit /etc/krb5.confThe stock version of this file will have or everwhere you want to put your own realm or domain name. The two sections in question are libdefaults and domain_realm. The other sections do not need to be changed. In libdefaults, enter your own kerberos realm name. You may want to set the clock skew to a lower value (provided you are synchronizing time with ntp).[libdefaults]default_realm = PHYSIK.UNIZH.CHdns_lookup_realm = falsedns_lookup_kdc = falseclockskew = 120The realms section contains the settings for each realm. We have only one realm so it would look like the following. Note that you enter a kdc line for each Kerberos Domain Controller. You should have at least two.[realms]PHYSIK.UNIZH.CH = {kdc = coma.physik.unizh.ch:88kdc = second.physik.unizh.ch:88admin_server = coma.physik.unizh.ch:749default_domain = physik.unizh.ch}In domain_realm, enter the mapping between DNS domains and your kerberos realm. If you are serving multiple DNS domains, you need to put them all here.[domain_realm].zbox.physik.unizh.ch = PHYSIK.UNIZH.CHzbox.physik.unizh.ch = PHYSIK.UNIZH.CH.physik.unizh.ch = PHYSIK.UNIZH.CHphysik.unizh.ch = PHYSIK.UNIZH.CHFinally, you may want to tweak the application defaults, for example to change the renew lifetime.[appdefaults]pam = {debug = falseticket_lifetime = 36000renew_lifetime = 36000forwardable = truekrb4_convert = false}kinit = {ticket_lifetime = 36000renew_lifetime = 36000forwardable = true}Edit /var/kerberos/krb5kdc/kdc.confIn this file, only the realms section needs to be modified. According to this FAQ, it is important to change the key types as well. I can confirm that the setting below work perfectly in our environment. You may want to decide on appropriate values for the maximum life of each ticket, and for how long each ticket can be renewed. Reasonable values are 1 day and 1 week but your needs will vary. The values here are the absolute maximum that the KDC will issue. Each principal has its own maximum as well.[realms]PHYSIK.UNIZH.CH = {master_key_type = des3-hmac-sha1supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normalmax_life = 25hmax_renewable_life = 4w}Edit /var/kerberos/krb5kdc/kadm5.aclThis file determines who can modify the kerberos database. You need to change the realm.*/admin@PHYSIK.UNIZH.CH *A brief note on kerberos users (called principles) is in order at this point. All standard users will be of the form username@REALM. When one tries to run the administration tool, it takes the current username, appends ‘/admin’ and uses that as the principle. If there is no username/admin@REALM principle, then that user cannot modify the database.Change /etc/gssapi_mech.confThere is a problem with this file on 64-bit architectures. It specifies the “lib” library path instead of the “lib64” path. You can just remove the path altogether and it will work on either. This is more important on a kerberos client, but a server can be a client as well, so you may as well change it on all machines.# library initialization function# ================================ ==========================# The MIT K5 gssapi library, use special function for initialization. libgssapi_krb5.so mechglue_internal_krb5_initCreate the Kerberos databaseCreate the database with the following command.[root@coma ~] kdb5_util create -sThis will prompt you for a password. You will only have to enter this password when you initially configure a slave KDC, so choose something large and random and store it in a secure place. Really, you may only have to enter this once more, so make it secure.Add the first Administrative UserI do administration as root, so the first user I add is root/admin. The default realm is appended automatically, so the command to use is as follows.[root@coma ~] kadmin.local -q "addprinc root/admin"Enter a password when prompted. You will need this password every time you administer the database.Starting the ServicesAt this point it is necessary to enable and start the kerberos services.[root@coma ~] chkconfig kadmin on[root@coma ~] service kadmin start[root@coma ~] chkconfig krb5kdc on[root@coma ~] service krb5kdc startTo test if everything is working, run kadmin. By default, the current user appended with ‘/admin’ is used as the principle.[root@coma ~] kadminAuthenticating as principal root/admin@PHYSIK.UNIZH.CH with password. Password for root/admin@PHYSIK.UNIZH.CH:kadmin: listprincsK/M@PHYSIK.UNIZH.CHkadmin/admin@PHYSIK.UNIZH.CHkadmin/changepw@PHYSIK.UNIZH.CHkadmin/history@PHYSIK.UNIZH.CHkrbtgt/PHYSIK.UNIZH.CH@PHYSIK.UNIZH.CHroot/admin@PHYSIK.UNIZH.CHThe additional principles have been created by the tool. They are required so leave them be.Create a Host Principal for the KDCNow you will want to create a host principal for the KDC. This is required for replication (see below). You also need to add this principal to the local key table.[root@coma ~]# kadminAuthenticating as principal root/admin@PHYSIK.UNIZH.CH with password. Password for root/admin@PHYSIK.UNIZH.CH:kadmin: addprinc -randkey host/coma.physik.unizh.chNOTICE: no policy specified forhost/coma.physik.unizh.ch@PHYSIK.UNIZH.CH; assigning "default"Principal "host/coma.physik.unizh.ch@PHYSIK.UNIZH.CH" created.kadmin: ktadd host/coma.physik.unizh.chSetup the default PolicyYou will want to create the default password policy at this point. All new accounts will have this policy enforced.[root@coma ~] kadminAuthenticating as principal root/admin@PHYSIK.UNIZH.CH with password. Password for root/admin@PHYSIK.UNIZH.CH:kadmin: add_policy -maxlife 180days -minlife 2days -minlength 8-minclasses 3 -history 10 defaultYou can also add other policies and apply different policies to different principles. The different flags and their meaning are as follows.Flag Description-maxlife The is the maximum period before the password must be changed.-minlife This is the minimum time after a password change before itcan be changed again. Without a minimum time, users can change their password multiple times and overflow the history (seebelow) and end up back with the same password.-minclasses This is the number of distinct character classes that mustappear in the password. Character classes are uppercaseletters, lowercase letters, number and symbols. Setting thisto 2 for example would mean a password with at least onelowercase letter and a number would be valid.-historyThis is the number of previous passwords to keep. A password may not duplicate a prior password.Changing the Maximum Renewal TimeEach principal has its own maximum renewal life. On RHEL4, new principals are created with a maximum renewal time of zero. This means you can get a renewable ticket, but they can never be renewed. Each principal must be manually changed to the desired maximum renewal time. In addition, the special principal krbtgt/REALM@REALM must be changed to reflect the maximum renewal time that any principal will have.[root@coma ~]# kadminAuthenticating as principal root/admin@PHYSIK.UNIZH.CH with password. Password for root/admin@PHYSIK.UNIZH.CH:kadmin: modprinc -maxrenewlife 2weekskrbtgt/PHYSIK.UNIZH.CH@PHYSIK.UNIZH.CHPrincipal "krbtgt/PHYSIK.UNIZH.CH@PHYSIK.UNIZH.CH" modified. Adding Principals[root@coma ~] kadminuthenticating as principal root/admin@PHYSIK.UNIZH.CH with password. Password for root/admin@PHYSIK.UNIZH.CH:kadmin: addprinc -maxrenewlife 7days dougThe various options allow you to tune your password policy.Slave KDC (Backup KDC)At this point, you will want to setup a backup or “slave” KDC.Host PrincipalFirst, add a host principal for each slave KDC. If you followed the instructions above for the primary KDC, then you will already have a host principal for the primary.[root@coma ~]# kadminAuthenticating as principal root/admin@PHYSIK.UNIZH.CH with password. Password for root/admin@PHYSIK.UNIZH.CH:kadmin: addprinc -randkey host/second.physik.unizh.chNOTICE: no policy specified forhost/second.physik.unizh.ch@PHYSIK.UNIZH.CH; assigning "default"Principal "host/second.physik.unizh.ch@PHYSIK.UNIZH.CH" created. Copy Configuration FilesCopy the following files from the primary KDC to each of the slave KDCs.∙/etc/krb5.conf∙/var/kerberos/krb5kdc/kdc.conf∙/var/kerberos/krb5kdc/kadm5.acl∙/etc/gssapi_mech.confCreate kpropd.aclCreate an ACL file with all of the KDCs listed (both primary and backups). This file is /var/kerberos/krb5kdc/kpropd.acl and should look something like this.host/coma.physik.unizh.ch@PHYSIK.UNIZH.CHhost/second.physik.unizh.ch@PHYSIK.UNIZH.CHDon’t put this file on the primary KD C or kadmin will not start. Add Host Principal to Slave Key TableOn each slave KDC, add the host principal to the local key table.[root@second ~]# kadminAuthenticating as principal root/admin@PHYSIK.UNIZH.CH with password. Password for root/admin@PHYSIK.UNIZH.CH:kadmin: ktadd host/second.physik.unizh.chStart the Kerberos Propagation DaemonOn RHEL4 it is not necessary to create the database on the slave prior to starting the daemon. It was reported (thanks Louis) that on Fedora and perhaps Centos it is required. If the kprop daemon doesn’t start, you may need to create the database with the “kdb5_util create -s” command before starting it.On each slave KDC, use the following command to enable the receipt of the kerberos database.[root@second ~]# chkconfig kprop on[root@second ~]# service kprop startStarting Kerberos 5 Propagation Server: [ OK ] Propagate the DatabaseThe next step is to propagate the database (manually) to each slave KDC. This is a two step process. First, dump the database to a file. Next, propogate the dumped file to each slave KDC.[root@coma ~]# kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans [root@coma ~]# kprop -f /var/kerberos/krb5kdc/slave_datatrans second.physik.unizh.chDatabase propagation to second.physik.unizh.ch: SUCCEEDEDCreate a Stash FileOn each KDC you need to create a stash file. You will need the (really long and random) master key that you entered when you initially created the kerberos database.[root@second ~]# kdb5_util stashkdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master keyEnter KDC database master key:Start the Kerberos 5 KDC on each SlaveNow that the database is there, and you have created the stash file, you are ready to start the KDC Daemon.[root@second ~]# chkconfig krb5kdc on[root@second ~]# service krb5kdc startStarting Kerberos 5 KDC: [ OK ]Do not start the Administration Daemon (kadmin) on the slaves. The Administration Daemon is used to add/remove/modify principals and to change passwords. When the database is replicated to the slaves, any changes that were made on the slaves would be lost. This also means that if the primary KDC goes down, it is not possible to make changes, or for users to modify their password.If the primary KDC will be down for an extended period, you can make any slave the primary, but you will have to replicate the database back to the old primary when it becomes available. This requires manual intervention.Setup Periodic ReplicationReplication from the Master KDC to the slaves is not automatic. You need to set up a cron job. Create a script similar to the following and place it into /etc/cron.hourly.#!/bin/shKDCS="second.physik.unizh.ch"/usr/kerberos/sbin/kdb5_util dump/var/kerberos/krb5kdc/slave_datatransfor KDC in $KDCS ; do/usr/kerberos/sbin/kprop -f /var/kerberos/krb5kdc/slave_datatrans $KDC \| grep -v SUCCEEDEDdoneYou can change how often replication is performed to suit your needs. If you makes changes to the database, you can manually run the script to propagate them. If the primary KDC goes down, then any changes since thelast propogate will not be reflected (hence if a user password has changed, the old password will be valid, not the new one).Firewall ConfigurationIt is highly recommended that a firewall (for example iptables) be used to restrict access. For kerberos to work, the following ports must be opened.∙Clients must be able to reach all KDCs on UDP port 88 (for authentication).∙Clients must be able to reach the primary KDC on TCP port 749 (for password management).∙The primary KDC must be able to reach the secondary KDCs on TCP port 754 (for replication).LDAPPlease read the section below on crash recovery. If the LDAP server (slapd) is not shutdown properly (e.g., your machine crashes) then your LDAP database will be trashed. The LDAP server will start and answer requests but won’t produce any fruitfull result s. Nobody will be able to log in!KerberosYour LDAP server must be configured to use kerberos. If you are running your LDAP server on the same machine as your kerberos KDC, then everything is setup, otherwise see the client section below.You will need to create a kerberos principal for each LDAP server. The special principal, ldap/hostname must be extracted to a key table to which the LDAP server (slapd) has access.[root@coma ~]# kadminAuthenticating as principal root/admin@PHYSIK.UNIZH.CH with password. Password for root/admin@PHYSIK.UNIZH.CH:kadmin: addprinc -randkey ldap/coma.physik.unizh.chkadmin: ktadd -k /etc/openldap/ldap.keytabldap/coma.physik.unizh.chkadmin: exit[root@coma ~]# chgrp ldap /etc/openldap/ldap.keytab[root@coma ~]# chmod 640 /etc/openldap/ldap.keytabYou need to repeat this process on each LDAP server (of which there should be at least two).You have to tell slapd to use this key table by editing /etc/sysconfig/ldap. It should look like this.export KRB5_KTNAME=/etc/openldap/ldap.keytabSSL CertificateThe LDAP server will require an SSL certificate. Of course, you can purchase one, but this isn’t necessary. Unlike web or mail servers, the certificate authority can be easily distributed to the clients during configuration. The openssl package provides the necessary scripts.See Certificates HOWTO for details on creating a certificate.If you plan to use an alias for your ldap server, then the certificate must contain all of the aliases. For example, let’s suppose you will have to ldap servers called host1.domain and host2.domain. You plan to have an alias called ldap.domain that will round robin. Further, a different domain will also reference the servers as ldap.otherdomain. You need to add the following line to openssl.conf before generating the certificates (in the usr_cert section).subjectAltName=DNS:ldap.domain,DNS:ldap.otherdomainName each server normally (host1.domain and host2.domain). slapd.confNow edit /etc/openldap/slapd.conf and make the following changes.TLSCACertificateFile /etc/openldap/cacerts/cacert.pem TLSCertificateFile /etc/openldap/slapd.pemTLSCertificateKeyFile /etc/openldap/slapd.keyThere are some additional changes that need to be made to this file, so we might as well do them now.Add an idle timeout.idletimeout 3600Failure to add this idle timeout will result in LDAP failing after a period of time. The number of TCP connections is limited internally. If connections are not released, the LDAP daemon (slapd) will be unable to open files. This will cause slapd to return an error to all queries. At this point nobody will be able to logon or do much of anything. If this value is too high (or disabled), then slapd will run out of file handles. If this value is set too low, then your system log will be filled with messages about reconnecting to the LDAP server. On our system, the value 3600 (1 hour) works well.You need to change the suffix and rootdn to match your domain. Here is an example.suffix "dc=physik,dc=unizh,dc=ch"rootdn "cn=Manager,dc=physik,dc=unizh,dc=ch"You also need to add a a temporary manager account for the initial load. The best thing to do here is to add an encrypted password. First run slappasswd to encrypt a password.[root@coma ~]# slappasswdNew password:Re-enter new password:{SSHA}ISM1CdMvg6jOMNjASCKZvOWxXy6F8jY4Now change the rootpw section.rootpw {SSHA}ISM1CdMvg6jOMNjASCKZvOWxXy6F8jY4Change the access control section as follows.# This is a bit of a hack to restrict the SASL mechanisms that the# server advertises to just GSSAPI. Otherwise it also advertises# DIGEST-MD5, which the clients prefer. Then you have to add "-Y# GSSAPI" to all of your ldapsearch/ldapmodify/etc. command lines, which # is annoying. The default for this is noanonymous,noplain so the# addition of noactive is what makes DIGEST-MD5 and the others go away. sasl-secprops noanonymous,noplain,noactive# Map SASL authentication DNs to LDAP DNs# This leaves "username/admin" principals untouchedsasl-regexp uid=([^/]*),cn=GSSAPI,cn=authuid=$1,ou=people,dc=physik,dc=unizh,dc=ch# This should be a ^ plus, not a star, but slapd won't accept it# Users can change their shell, anyone else can see itaccess to attr=loginShellby dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" writeby self writeby * read# Only the user can see their employeeNumberaccess to attr=employeeNumberby dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" writeby self readby * none# Default read access for everything elseaccess to *by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" writeby * readldap.confThis file needs to be propagated to each host, including the ldap servers. Only the following three lines need to be present.BASE dc=physik,dc=unizh,dc=chURI ldaps://coma.physik.unizh.ch ldaps://second.physik.unizh.ch TLS_CACERT /etc/openldap/cacerts/cacert.pemCrash RecoveryIf your LDAP server is not shutdown gracefully, then the database will become corrupt. There may be a solution to this problem, but I have yet to find it.For this reason, it is a good idea to use a reliable machine for your LDAP servers, and to put said machines on a UPS.BackupFurther, you must make regular exports of the LDAP database so that you can easily reimport them if there is a problem. The following script (or something like it) can be added to /etc/cron.hourly or /etc/cron.daily/ as you see fit. It uses slapcat to export the database on a regular schedule.#!/bin/bashBACKUPDIR=/root/ldap.backupKEEPDAYS=30# Make sure that the directory existsmkdir -p $BACKUPDIR# Create a new backup (and compress it). Choose one of the following FILENAME# patterns (or create your own). The first has the hour and minute while the# second has only the date. You can run the second hourly to keep only one# copy per day, but have it saved hourly.#FILENAME=$BACKUPDIR/ldap.backup.$(date +%Y%m%d%H%M)FILENAME=$BACKUPDIR/ldap.backup.$(date +%Y%m%d)/usr/sbin/slapcat | gzip --best >${FILENAME}.new.gzmv -f ${FILENAME}.new.gz ${FILENAME}.gz# Delete old copiesOLD=$(find $BACKUPDIR/ -ctime +$KEEPDAYS -and -name 'ldap.backup.*') [ -n "$OLD" ] && rm -f $OLDRestoreTo restore your database from the backup, you need to perform the following steps.∙Stop the LDAP serverservice ldap stop∙Remove the old database (you may want to make a copy “just in case”)rm /var/lib/ldap/*∙Import the latest backup (unzip it first if required). Be patient as this takes a little while.cd /root/ldap.backup/gunzip ldap.backup.20060101.gzslapadd -l ldap.backup.20060101∙Change the ownership of the files.chown ldap.ldap /var/lib/ldap/*∙Restart the serverservice ldap startClient SetupCopy FilesCopy the following files from the KDC or LDAP server.∙/etc/krb5.conf∙/etc/ldap.conf∙/etc/openldap/ldap.conf∙/etc/openldap/cacerts/cacert.pemCreate Kerberos PrincipalsRun kadmin on the server and create the following principals. Replace phoenix.physik.unizh.ch with the fully qualified name of the client machine. If you don’t plan to use NFS, then don’t add the second principal. You can always add it now, even if you aren’t planning on using NFSv4 at the mom ent; it won’t hurt anything.[root@coma misc]# kadminAuthenticating as principal root/admin@PHYSIK.UNIZH.CH with password. Password for root/admin@PHYSIK.UNIZH.CH:kadmin: addprinc -randkey host/phoenix.physik.unizh.chkadmin: addprinc -randkey nfs/phoenix.physik.unizh.chNow run kadmin on the client. Add the above two principals to the keytab file as follows. Note the special way in which the NFS principal is added. This is important or again things will fail in mysterious ways.[root@phoenix ~]# kadminAuthenticating as principal root/admin@PHYSIK.UNIZH.CH with password. Password for root/admin@PHYSIK.UNIZH.CH:kadmin: ktadd host/phoenix.physik.unizh.chkadmin: ktadd -e des-cbc-crc:normal nfs/phoenix.physik.unizh.ch Enable AuthenticationRun the configuration tool by typing authconfig at the shell prompt. You will need to check ‘Use LDAP’ under ‘User Information’ and ‘Use Kerberos’ under ‘Authentication’.NFSv4NFSv4 using Kerberos authentication in RHEL4 seems to be broken with the latest patch level. When I find a solution it will be posted here. LDAP and Kerberos for authentication of users works fine.Create the necessary entries in /etc/exports. First, create an NFSv4 mount point. I would suggest /export. Next bind the real path to the NFSv4 mount point. In this example, we want to export the /data directory. We create /export/data for NFSv4 and mount /data there.mkdir -m 1777 /exportmkdir /export/datamount -n --bind /data /export/dataYou will need to add the mount command to /etc/rc.d/rc.local so that it is remounted after each boot.# NFSv4 Mounts/exportgss/krb5(sync,rw,fsid=0,insecure,no_subtree_check,anonuid=65534,anong id=65534)/export/datagss/krb5(sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anong id=65534)# Legacy mounts/datacoma(sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=6 5534,no_root_squash)Modify /etc/idmapd.confYou must change the domain to your current domain. Also, The user mapping for nobody should be updated.[General]Verbosity = 0Pipefs-Directory = /var/lib/nfs/rpc_pipefsDomain = physik.unizh.ch[Mapping]Nobody-User = nfsnobodyNobody-Group = nfsnobody[Translation]Method = nsswitchModify /etc/sysconfig/nfsTo enable secure NFS, you must add the following line to/etc/sysconfig/nfsSECURE_NFS=yesIf you are still using NFSv3 and a firewall, you may want to add the following definitions as well. Choose ports that are appropriate to your environment, although the listed values work well for us.STATD_PORT=4000LOCKD_TCPPORT=4001LOCKD_UDPPORT=4001MOUNTD_PORT=4002。