建站服务器 环境 Red Hat Enterprise Linux 6 and below NFS protocol versions 3 and 4 问题 How to configure NFSv4 with kerberos authentication in Red Hat Enterprise Linux 5? GIDs of users in more than 16 groups are not recognized properly on NFS in RHEL 决议

To allow NFS manipulate properly the file permissions of users that participate in more than 16 Groups, RPCSEC_GSS and Kerberos need to be used instead the default authentication method (AUTH_SYS). To configure Kerberos and NFSv4, the following article could be used :

创新互联服务项目包括惠民网站建设、惠民网站制作、惠民网页制作以及惠民网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，惠民网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到惠民省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

Environment used in this procedure :

Red Hat Enterprise Linux 5.5 x86_64 server as NFSv4 server and KDC - hostname server.example.com Red Hat Enterprise Linux 4 x86_64 as NFS client - hostname client.example.com

Important points :

Time Synchronization: All machines that will participate in Kerberos authentication must have a reliable, synchronized time source. Most large organization offer their own time sources. You can use the RHEL configuration tool system-config-time to set this up. So, time of both the server and clients will be same. Hostnames : All hosts must have their hostname set to the fully qualified hostname as reported by dns. Both forward and reverse mapping must work properly. 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 you don’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. 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. The kerberos realm used in this article will be EXAMPLE.COM.

Packages needed :

On client machine, make it sure that following packages are installed :

krb5-libs krb5-workstation pam_krb5 cyrus-sasl-gssapi

On server machine, make it sure that following package is installed :

krb5-server

Configuring Kerberos service on the Server :

1.1 There are a number of files that have to be manually edited on the server :

Edit /etc/krb5.conf

The stock version of this file will have EXAMPLE.COM or example.com everywhere 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). The file will look like :

Raw

[root@server ~]# cat /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes

[realms]
EXAMPLE.COM = {
  kdc = server.example.com:88
  admin_server = server.example.com:749
  default_domain = example.com
}

[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM

[appdefaults]
pam = {
  debug = false
  ticket_lifetime = 36000
  renew_lifetime = 36000
  forwardable = true
  krb4_convert = false
}

1.2 Edit /var/kerberos/krb5kdc/kdc.conf

In this file, only the realms section needs to be modified. 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. File will look like :

Raw

[root@server ~]# cat /var/kerberos/krb5kdc/kdc.conf
[kdcdefaults]
v4_mode = nopreauth
kdc_tcp_ports = 88


[realms]
EXAMPLE.COM = {
  #master_key_type = des3-hmac-sha1
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3
}

1.3 Edit /var/kerberos/krb5kdc/kadm5.acl :

This file determines who can modify the Kerberos database. You need to change the realm. File will look like :

Raw

[root@server ~]# cat /var/kerberos/krb5kdc/kadm5.acl
*/admin@EXAMPLE.COM    *

1.4 Make sure /etc/gssapi_mech.conf looks like :

Raw

[root@server ~]# cat /etc/gssapi_mech.conf
# library                              initialization function
# ================================    ==========================
# The MIT K5 gssapi library, use special function for initialization.
libgssapi_krb5.so.2          mechglue_internal_krb5_init
#

1.5 Create the Kerberos database :

Execute the following command :

Raw

[root@server ~]# kdb5_util -r EXAMPLE.COM create -s

This 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.

1.6 Add the first Administrative User :

I 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 :

Raw

[root@server ~]# kadmin.local -q addprinc root/admin

Enter a password when prompted. You will need this password every time you administer the database.

1.7 At this point it is necessary to enable and start the kerberos services :

Raw

[root@server ~]# chkconfig kadmin on
[root@server ~]# service kadmin start
[root@server ~]# chkconfig krb5kdc on
[root@server ~]# service krb5kdc start

To test if everything is working, execute kadmin or kadmin.local. By default, the current user appended with ‘/admin’ is used as the principle.

Raw

[root@server ~]# kadmin
Authenticating as principal root/admin@EXAMPLE.COM with password.
Password for root/admin@EXAMPLE.COM:                          //Please enter admin password
kadmin:  listprincs
K/M@EXAMPLE.COM
host/server.example.com@EXAMPLE.COM
host/client.example.com@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
kadmin/history@EXAMPLE.COM
kadmin/server.example.com@EXAMPLE.COM
kmaiti@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM
nc@EXAMPLE.COM
nfs/server.example.com@EXAMPLE.COM
nfs/client.example.com@EXAMPLE.COM
root/admin@EXAMPLE.COM
kadmin:

The additional principles have been created by the tool. They are required so leave them be.

1.8 Create a Host Principal for the KDC :

Now you will want to create a nfs service principal for nfs server. You also need to add this principal to the local key table.

Raw

[root@server ~]# kadmin
Authenticating as principal root/admin@EXAMPLE.COM with password.
Password for root/admin@EXAMPLE.COM:
kadmin: addprinc -randkey nfs/server.example.com                //Execute this command. Don\'t forget to replace the hostname.
kadmin: ktadd nfs/server.example.com                            // Adding key to keytab file.

1.9 Creating Kerberos Principals for client :

Run kadmin on the server and create the following principals. Replace client.example.com with the fully qualified name of the client machine.

Raw

[root@server ~]# kadmin
Authenticating as principal root/admin@EXAMPLE.COM with password.
Password for root/admin@EXAMPLE.COM:
kadmin: addprinc -randkey nfs/client.example.com

1.10 Generate key in the keytab file for the admin and this will be saved in /var/kerberos/krb5kdc/kadm5.keytab since this has been mentioned in /var/kerberos/krb5kdc/kdc.conf. Use following commands :

Raw

[root@server ~]# kadmin
Authenticating as principal root/admin@EXAMPLE.COM with password.
Password for root/admin@EXAMPLE.COM:
kadmin: ktadd -k /var/kerberos/krb5kdc/kadm5.keytab kadmin/admin                    //Execute these commands
kadmin: ktadd -k /var/kerberos/krb5kdc/kadm5.keytab kadmin/changepw

1.11 Make it sure that ports 88 and 749 has opened at the firewall. Restart the firewall, kadmin and krb5kdc services.

Client Setup :

2.1 Copy the file /etc/krb5.conf from server (Kerberos server) to client machine.
2.2 Make it sure that ports 88 and 749 has opened at the firewall. Restart the firewall.
2.3 Create Kerberos Principals:

Execute kadmin command on the client console. Add the principal to the keytab file as follows for NFS :

Raw

[root@client ~]# kadmin
Authenticating as principal root/admin@EXAMPLE.COM with password.
Password for root/admin@EXAMPLE.COM:
kadmin: ktadd -e des-cbc-crc:normal nfs/client.example.com

Configuring kerberos for NFSv4 (Assuming that NFSv4 has been installed on the server), on the kerberos (i.e NFSv4) server :

3.1 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.

Raw

[root@server /]# mkdir -m 1777 /export
[root@server /]# mkdir /export/data
[root@server /]# mount -n --bind /data /export/data

3.2 Add the following lines in the /etc/exports file :

Raw

/export      gss/krb5(sync,rw,fsid=0,insecure,no_subtree_check,anonuid=65534,anongid=65534)
/export/data gss/krb5(sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534)

3.3 Modify /etc/idmapd.conf and it\'ll look like :

Raw

[root@server /]# cat /etc/idmapd.conf
[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = example.com

[Mapping]

Nobody-User = nfsnobody
Nobody-Group = nfsnobody

[Translation]
Method = nsswitch

3.4 Make the value of SECURE_NFS to yes in /etc/sysconfig/nfs. To enable secure NFS, you must add the following line to /etc/sysconfig/nfs :

Raw

SECURE_NFS=yes

After the restart the NFS servers, the environment is able to work properly using Kerberos authentication and RPCSEC_GSS.

Testing :

On client machine issue the following command to mount the exporting directory of the server :

Raw

# mount -t nfs4 -o sec=krb5 server.example.com:/ /mnt/my_nfs_mount_point

Now create the files inside the /data directory on the server and view the files inside /mnt directory on the client machine.

Note : NFS daemons looks like on the server :

Raw

[root@server /]# service nfs status
rpc.svcgssd (pid 8974) is running...
rpc.mountd (pid 8994) is running...
nfsd (pid 8991 8990 8989 8988 8987 8986 8985 8984) is running...
rpc.rquotad (pid 8979) is running...

根源

By default NFS clients and servers use the AUTH_SYS protocol to authenticate users.
AUTH_SYS is defined in RPC v2 (http://www.ietf.org/rfc/rfc1831.txt) to allocate a 4 bit value to group memberships, hence the 16 groups limitation.
But since v4, NFS can use a different authentication protocol such as RPCSEC_GSS which supports more groups.

诊断步骤

The following considerations can help to debug problems with the above setup.

Are hosts properly resolved via DNS or/etc/hosts? Are the expected principals in the keytab? This can be verified withklist -ke. Are the required services running on client and server? Have the services been restarted? Are the required modules loaded? In some casesrpcsec_gss_krb5was not loaded automatically on RHEL5. Isshowmount -e from the client showing the exports? It might be useful to configure rpc.gssd for more verbosity, setRPCGSSDARGS=-vvvin/etc/sysconfig/nfsand restart the service. For nfs debugging executeecho 32767 > /proc/sys/sunrpc/nfs_debug.
网站题目：【LINUX】怎样配置NFSv4withkerberos自动认证
路径分享：http://kswjz.com/article/cjsego.html