Configuring a secure z/OS NFS client

In order for the z/OS NFS client to support the RPCSEC_GSS authentication flavor using the Kerberos V5 Security Mechanism, the following should be done. We are assuming that a properly configured KDC is already setup in your environment. If a KDC is not already configured, see Setting up NFS functions with Kerberos Support. This document assumes you will be using a KDC provided by “Security Server and Integrated Security Services” (RACF) provided by IBM but are not specific to a KDC provided by IBM. As of z/OS V2R3, ensure that ICSF is started and complete initialization prior to starting the z/OS NFS Client on the system. ICSF will need to be running for the duration of use of all Kerberos functions. See z/OS Integrated Security Services Network Authentication Service Administration. The following steps need to be run on the system that contains the KDC unless otherwise noted:

  1. Add the client principal "mvsnfsc" to the Kerberos database on the KDC with a defined password. This principal should not use randkey as the password. For example, for the z/OS NDBM type or SUN KDC, issue the command "addprinc mvsnfsc" in the kadmin interface, then enter the desired password at the prompt. For the z/OS SAF type KDC, the password can be defined in the "PASSWORD" field of the RACF "adduser" or "altuser" commands. Please remember this password; it will be needed in step 3. Refer to Setting up a Kerberos Key Distribution Center for more information.
  2. Map the principal "mvsnfsc" in lower case to the z/OS NFS client RACF user. For example: 
       ALTUSER mvsnfsc KERB(KERBNAME(‘mvsnfsc’))
    If the SAF KDC is configured on the same system as the z/OS NFS client then a PASSWORD must be set:
       ADDUSER mvsnfsc OWNER(owner) OMVS(UID(0))
   ALTUSER mvsnfsc PASSWORD(password) NOEXPIRED KERB(KERBNAME('mvsnfsc'))
   PASSWORD USER(mvsnfsc) NOINTERVAL
    Note:
    1. We expect that the z/OS NFS client's ID has already been defined to RACF. If it has not been configured, please see Setting up the z/OS NFS authorization.
    2. If a SAF KDC is NOT being used, create a principal ‘mvsnfsc’ according to your vendor's KDC documentation.
    3. The NFS Client requires that the Kerberos segment use KERBNAME ‘mvsnfsc’ and it must be in lowercase.
    4. Including PASSWORD option “NOINTERVAL” prevents the password from expiring.
  3. Regardless of which KDC is used, the system administrator must add the principal "mvsnfsc" into the keytab from the omvs shell. If /etc/skrb/krb5.keytab does not exist, create a new one. Failure to do so will caused the principals "key version" to be incremented causing preciously created keytabs to become absolute. For example: 
    IBMUSER:/ :> keytab add mvsnfsc -p password -k /etc/skrb/krb5.keytab -v 1
    Note:
    1. The "password" in step 3 must match the "password" entered in step 2, when the principal was added to the KDC Kerberos database. This principal "mvsnfsc" is used to perform NFSv4 mounts for all users.
    2. The key version used to create the keytab must be the same key version as in the RACF database. The “-v” option of the keytab command is used to specify the key version when adding a principal to a keytab. Issue the following RACF command to see the current key version: "LU mvsnfsc NORACF KERB" Or from a non SAF or NDBM KDC from kadmin interface issue: "getprinc mvsnfsc"
    3. The password used with the “keytab” command is case sensitive. If mixed case password support is not in effect you must enter the password in uppercase.
    4. SFTP, or Secure copy the new keytab to the z/OS NFS Client and place in “/etc/skrb/krb5.keytab".
    5. To gain access to a secure mount point, all users should perform a "kinit" to acquire their Kerberos credentials.
  4. The z/OS NFS client requires the Kerberos configuration file “krb5.conf” be configured to match your sites Kerberos environment.
    Sample /etc/skrb/krb5.conf file to be put on the z/OS NFS client system: 
    [libdefaults] 
default_realm = KRB390.IBM.COM 
kdc_default_options = 0x40000010 
use_dns_lookup = 0 
default_tkt_enctypes = aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96,
       des3-cbc-sha1,des-hmac-sha1,des-cbc-md5,des-cbc-md4,des-cbc-crc 
default_tgs_enctypes = aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96,
       des3-cbc-sha1,des-hmac-sha1,des-cbc-md5,des-cbc-md4,des-cbc-crc 

[realms] 
KRB390.IBM.COM = { 
kdc = dcesec4.krb390.ibm.com:88 
kpasswd_server = dcesec4.krb390.ibm.com:464 
admin_server = dcesec4.krb390.ibm.com:749 
} 
KRB2000.IBM.COM = { 
kdc = sstone1.krb2000.ibm.com:88 
admin_server = sstone1.krb2000.ibm.com:749 
} 

[domain_realm] 
.krb390.ibm.com = KRB390.IBM.COM 
.krb2000.ibm.com = KRB2000.IBM.COM
    Supported etypes:
    ENCTYPE_DES_CBC_CRC
ENCTYPE_DES_CBC_MD4
ENCTYPE_DES_CBC_MD5
ENCTYPE_DES_HMAC_SHA1
ENCTYPE_DES3_CBC_SHA1
ENCTYPE_AES128_CTS_HMAC_SHA1_96
ENCTYPE_AES256_CTS_HMAC_SHA1_96
  5. Most issues with kerberos are related to invalid keytabs. Once the keytab has been placed on the zNFS client's LPAR in "/etc/skrb/krb5.keytab", verify that the keytab is valid by issuing the following command: 
    kinit -k mvsnfsc
    1. This command should complete with out errors and you should not be prompted for a password.
    2. If this command fails, the keytab is invalid or the Kerberos configuration is incorrect.