SERVAUTH based restricted MVSLOGIN

The z/OS NFS server relies on the z/OS Communications Server (CS) and RACF to protect several resources and to restrict access from a network, subnetwork, or particular IP address in the network. Using NETACCESS statements in a TCPIP profile, z/OS CS can map networks, subnetworks, and IP addresses to RACF resource names in the SERVAUTH class (see z/OS Communications Server: IP Configuration Guide). Users that are not permitted access to a particular RACF resource are not allowed to execute MVSLOGIN from the corresponding network, subnetwork, or IP address.

User access to MVS data sets through the z/OS NFS Server can be protected/permitted restricted to/from some network, subnetwork, or IP address (see z/OS Security Server RACF Security Administrator's Guide).

To use this capability, the z/OS system administrator must:

Add the NETACCESS section in your TCPIP profile if it does not exist, and modify the NETACCESS section in your TCPIP profile to prevent/permit users from/to accessing a given network, subnetwork, or host.

NETACCESS examples:

  NETACCESS    INBOUND    OUTBOUND ; check both ways
       9.11.117.218 255.255.255.255 SUN1       ; specific UNIX host
       9.11.117.108/32  MVSNFS     ; the z/OS NFS server Requires 
                                   ; matching "PERMIT" to grant access
       192.168.0.0/16   CORPNET ; Net address
       192.168.113.19/32  HOST1    ; Specific host address
       192.168.113.0     255.255.255.0   SUBNET1 ; Subnet address
       192.168.192.0/24  CAMPUS ; Subnet address
       Fe80::6:2900:1dc:21bc/128 HOST2  ; IPv6 specific host address
       2001:0DB8:/16   GLBL  ; IPv6 global network
     DEFAULTHOME      HOME       ; Required local zone   
     DEFAULT 0        DEFZONE    ;Optional Default security zone 
     ENDNETACCESS

Define and activate a RACF profile for each resource specified in the SERVAUTH class via th NETACCESS statement. Issue the following RACF commands (see z/OS Security Server RACF Security Administrator's Guide):
```
RDEFINE SERVAUTH (EZB.NETACCESS.SYSTEM1.TCPIPSJ.MVSNFS)      
RDEFINE SERVAUTH (EZB.NETACCESS.SYSTEM1.TCPIPSJ.SUN1)
RDEFINE SERVAUTH (EZB.NETACCESS.SYSTEM1.TCPIPSJ.HOME)	 
RDEFINE SERVAUTH (EZB.NETACCESS.SYSTEM1.TCPIPSJ.DEFZONE)
SETROPTS CLASSACT(SERVAUTH) REFRESH RACLIST(SERVAUTH)  
```
where SYSTEM1 is the sysname, TCPIPSJ is the tcpname, and MVSNFS is the saf_resname as described later in this section.
The corresponding RACF profile name has the following format (see z/OS Communications Server: IP Configuration Reference):
```
 EZB.NETACCESS.sysname.tcpname.saf_resname
```
where
EZB.NETACCESS

is constant.

sysname

is the value of the MVS &SYSNAME. system symbol.

tcpname

is the name of the procedure used to start the TCP stack.

saf_resname

is 8-character value from the NETACCESS section.

An asterisk is allowed as sysname and tcpname. For example:
```
 EZB.NETACCESS.*.*.CORPNET
 EZB.NETACCESS.*.*.SUBNET1
```

To allow an NFS client to create connections with the z/OS NFS Server, socket activity for the NFS Server and the Port mapper, (or RPCBIND) must be permitted with the following RACF commands:

PERMIT EZB.NETACCESS.SYSTEM1.TCPIPSJ.MVSNFS  ACCESS(ALTER) CLASS(SERVAUTH) ID(IBMUSER)  
PERMIT EZB.NETACCESS.SYSTEM1.TCPIPSJ.SUN1    ACCESS(ALTER) CLASS(SERVAUTH) ID(IBMUSER)
PERMIT EZB.NETACCESS.SYSTEM1.TCPIPSJ.HOME    ACCESS(ALTER) CLASS(SERVAUTH) ID(IBMUSER) 
PERMIT EZB.NETACCESS.SYSTEM1.TCPIPSJ.DEFZONE ACCESS(NONE)  CLASS(SERVAUTH) ID(IBMUSER)

In this example, assuming IBMUSER is the owning ID of both NFS Server and RPCBIND, it is needed to grant ALTER access to IBMUSER.

To allow an NFS client to access the z/OS NFS Server with specific RACF ID (for example, USER3), issue the following RACF PERMIT commands:

PERMIT EZB.NETACCESS.SYSTEM1.TCPIPSJ.MVSNFS  ACCESS(ALTER) CLASS(SERVAUTH) ID(USER3)  
PERMIT EZB.NETACCESS.SYSTEM1.TCPIPSJ.SUN1    ACCESS(ALTER) CLASS(SERVAUTH) ID(USER3)  
PERMIT EZB.NETACCESS.SYSTEM1.TCPIPSJ.HONME   ACCESS(ALTER) CLASS(SERVAUTH) ID(USER3) 
PERMIT EZB.NETACCESS.SYSTEM1.TCPIPSJ.DEFZONE ACCESS(ALTER) CLASS(SERVAUTH) ID(USER3) 
SETROPTS CLASSACT(SERVAUTH) REFRESH RACLIST(SERVAUTH)

NFS client SUN1 (9.11.117.218) can now execute MVSLOGIN with RACF ID USER3, but not other RACF users.

To prevent an NFS client to access the z/OS NFS Server with specific RACF ID (for example, USER3), issue the following RACF PERMIT commands:
```
PERMIT EZB.NETACCESS.SYSTEM1.TCPIPSJ.DEFZONE ACCESS(NONE)  CLASS(SERVAUTH) ID(USER3)  
PERMIT EZB.NETACCESS.SYSTEM1.TCPIPSJ.DEFZONE ACCESS(ALTER) CLASS(SERVAUTH) ID(USER5)  
SETROPTS CLASSACT(SERVAUTH) REFRESH RACLIST(SERVAUTH)
```
NFS client SUN1 (9.11.117.218) can now execute MVSLOGIN with RACF ID USER5, but not USER3 and other RACF users.

By using conditional PERMIT commands, the system administrator can restrict access to a data set profile (for instance 'USER2.*') for USER5. The RACF will permit the access only if USER5 executes MVSLOGIN from SUBNET1 (IP address 192.168.113.19).

 PERMIT 'USER2.*' ID(USER5) ACCESS(ALTER)
  WHEN(SERVAUTH(EZB.NETACCESS.*.*.SUBNET1))

For more informaiton, see z/OS Security Server RACF Command Language Reference.

Note:

The z/OS NFS server supports this capability only in saf or safexp SECURITY mode.
SERVAUTH supports both IPv4 and IPv6 modes.
To change between TERMID and SERVAUTH will require user configuration changes to switch between TERMINAL class security specification and SERVAUTH class specification, respectively.
This feature is also supported with RPCSEC_GSS authentication. However, since mvslogin is no longer required with RPCSEC_GSS, the RACF authentication is done automatically based on the Kerberos segment of the RACF ID.