z/OS Network File System Guide and Reference
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Configuring a secure z/OS NFS server

z/OS Network File System Guide and Reference
SC23-6883-00

In order for the z/OS NFS version 4 server to be able to provide RPCSEC_GSS security authentication flavors such as krb5, krb5i and krb5p, the z/OS NFS server must be configured to communicate with the Kerberos facilities. To do so, complete the following steps.

We are assuming that a properly configured KDC is already setup in your environment. If a KDC is not already configured please see appendix M. This section is split up into two parts to include specific examples using a KDC provided by “Security Server and Integrated Security Services” (RACF) provided by IBM and generic examples for non RACF KDC’s. These steps assume that Resource Access Control Facility (RACF) is available in the system. If you have a different but equivalent external security manager, please refer to its product documentation for instructions. A domain name server (DNS) resolver should also be available to the z/OS system in order to enable the security feature. Otherwise message GFSA735I is shown during startup of the secure z/OS NFS server. Since there are many options to set up a DNS resolver, such as /etc/resolv.conf or GLOBAL TCPIPDATA, specific examples are not given here. For more information on setting up a DNS resolver, see z/OS Communications Server: IP Configuration Guide.

  1. The Kerberos key distribution center (KDC) must be running, and must contain the z/OS NFS server’s principal before the secure z/OS NFS server starts. If the KDC is not set up correctly, whether the z/OS NFS server can start depends on the hfssec, mvssec, and pubsec attribute settings. If any of these three attributes also contains the sys security flavor in addition to any of the Kerberos flavors, the z/OS NFS server is started with message GFSA737I and functions with the sys security flavor only. On the other hand, if none of the hfssec, mvssec, or pubsec attributes contains the sys security flavor and the KDC is not available, the message GFSA736E is shown and z/OS NFS server does not start. The KDC can be running on z/OS, either on the same host as the z/OS NFS server itself or remotely from the z/OS NFS server. It can also be a KDC running on other platforms, for example, a SUN Solaris system or any other platform.

    For a brief description on how to setup a z/OS KDC, see Setting up a Kerberos Key Distribution Center, or refer to z/OS Integrated Security Services Network Authentication Service Administration for more advanced details. For setting up other platforms' KDCs, refer to the specific platform’s documentation.

  2. Define local realm and default policy. For example, issue the following TSO command:
    RDEFINE REALM KERBDFLT KERB(KERBNAME(KRB390.IBM.COM) PASSWORD(password)
    Note: “KRB390.IBM.COM” should match the Kerberos REALM of the KDC.
  3. Define IRR.RUSERMAP and grant READ authority to all system users, issuing TSO commands:
    RDEFINE FACILITY IRR.RUSERMAP UACC(READ) SETROPTS RACLIST (FACILITY)
    REFRESH PERMIT IRR.RUSERMAP CLASS(FACILITY) ID(mvsnfs) ACCESS(READ)
    SETROPTS CLASSACT (FACILITY) 
    Note: If “mvsnfs” is the RACFID of the z/OS NFS server. It is recommended that you add this path in the z/OS UNIX /.profile:
    “PATH=/usr/lpp/skrb/bin:$PATH” 
    and export the "PATH."
  4. Create RACF user ids with Kerberos segments for the z/OS NFS server.
    For example, to add a RACF ID for the z/OS NFS Server (if one does not already exist), issue the TSO command:
     AU (mvsnfs) OWNER(owner) OMVS(UID(1000)) 
    To add the needed Kerberos segment to this user definition, issue the TSO command:
    ALTUSER mvsnfs PASSWORD(password) NOEXPIRED 
            KERB(KERBNAME(nfs/hostname.domain)) 
    PASSWORD USER(mvsnfs) NOINTERVAL 
    If the Kerberos segment is not defined correctly to RACF, the following error message appears on the server when a NFS client tries to mount to z/OS NFS server with Kerberos.
    GFSA728E SAF APPLICATION USER MAPPING FAILED WITH SAF RETURN CODE 8, 
      RACF RETURN CODE 8, AND RACF REASON CODE 16
    Note:
    1. If you are NOT using a SAF KDC skip the RACF commands in this step and create a principal ‘nfs/hostname.domain’ according to your venders KDC documentation.
    2. The ALTUSER command converts the password to upper case if the MIXEDCASE SETROPTS option is not set. If MIXEDCASE is not set, you must ensure that the upper case value is used when you request an initial ticket. The principal name is not converted to upper case and the realm name is not included. You must change the password for the user in order to create the Kerberos secret key.
    3. The Kerbname must be the fully qualified hostname and domain. For example hostname.domain could be “host1.ibm.com”
    4. Including PASSWORD option “NOINTERVAL” prevents the password from expiring.
  5. The z/OS NFS server 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 server host:
    [libdefaults] 
    default_realm = KRB390.IBM.COM 
    kdc_default_options = 0x40000010 
    use_dns_lookup = 0 
    default_tkt_enctypes = des-cbc-crc 
    default_tgs_enctypes = 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 
    Note: If the z/OS NFS server will be supporting multiple platforms of NFS client, IBM recommends using des-cbc-crc encryption types only for compatibility, as shown in this example.
  6. Generate the keytab from the KDC and put it in /etc/skrb of the z/OS NFS server unless otherwise defined. For more detailed examples of generating keytabs see Setting up a Kerberos Key Distribution Center or in z/OS Integrated Security Services Network Authentication Service Administration.
    From the omvs shell, the system administrator must add the principal "nfs/hostname.domain" into the keytab. If /etc/skrb/krb5.keytab does not exist, create a new one. For example for a SAF or NDBM KDC
    IBMUSER:/ :> keytab add nfs/hostname.domain -p password -k /etc/skrb/krb5.keytab -v 1
    For example for a Unix KDC in kadmin:
    Kadmin: ktadd –e des-cbc-crc:normal –k /etc/krb5/krb5.keytab nfs/hostname.domain
    Note:
    1. The "password" in this step must match the "password" entered in step 4, when the principal was added to the SAF KDC Kerberos database. This principal is used to authenticate the z/OS NFS Sertver to the KDC.
    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 mvsnfs NORACF KERB
    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
  7. For systems with multiple TCPIP stacks you must create the keytab with principals for each stack. If a stack is part of a different REALM then keys will need to be added to the keytab from each KDC. Cross REALM trusts must also be created.
    IBMUSER:/:>klist -k 
    Key table: /etc/skrb/krb5.keytab 
    Principal: nfs/host1.domain.com@KRB390.IBM.COM  
    Key version: 4 
    Principal: nfs/host2.domain.com@KRB390.IBM.COM  
    Key version: 4 
    Principal: nfs/host3.domain.com@KRB2000.IBM.COM  
    Key version: 2 
  8. For Systems having TCP/IP stacks with multiple IP addresses (IPv4/IPv6), their DNS entries must map all of the IP addresses to the default host name for their associated stack.
  9. If there is any multi-realm setup in the environment, the z/OS NFS server needs to have the foreign principals mapped to a RACF ID.
    For example: To map a foreign principal “fprinc” in “KRB2000.IBM.COM” to RACF ID “fprealm2”, issue the TSO commands:
    ADDUSER (fprealm2) OWNER(owner) OMVS(UID(102)) 
    ALTUSER fprealm2 PASSWORD(password) NOEXPIRED
    PASSWORD USER(fprealm2) NOINTERVAL
    RDEFINE KERBLINK /.../KRB2000.IBM.COM/fprealm2 APPLDATA(’’fprealm2’) 
    To map the entire foreign realm (every principal in the trusted foreign realm) to a RACF user, issue the TSO command:
    RDEFINE KERBLINK /.../KRB2000.IBM.COM/ APPLDATA(’fprealm2’) 
    Note: the /…/ and trailing slash are required. “KRB2000.IBM.COM” is the foreign realm.
  10. Start the z/OS NFS server. If set up is correct, the following message should be shown:
    GFSA730I NETWORK FILE SYSTEM SERVER KERBEROS INITIALIZATION SUCCESSFUL 
  11. Most issues with kerberos are related to invalid keytabs. Once the keytab has been placed on the zNFS server's LPAR in "/etc/skrb/krb5.keytab", verify that the keytab is valid by issuing the following command:
    kinit -k nfs/host.domain.com
    1. This command should complete with out errors and you should not be prompted for a password.
    2. If you have multiple stacks, This command should be performed for each principal in the keytab.
    3. If this command fails, the keytab is invalid or the Kerberos configuration is incorrect.
Note:
  1. These are the minimal requirements to set up a secure z/OS NFS server in order for it to communicate with Kerberos facilities. For more advanced configurations, please see z/OS Integrated Security Services Network Authentication Service Administration.
  2. If z/OS NFS server is configured to use a KDC that resides on a remote host, the local KDC procedure (for example, skrbkdc) on the same host as the z/OS NFS server should not be started.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014