Authentication

In the NFS environment, authentication refers to any of several security mechanisms by which an NFS server can accept or reject requests from NFS clients to mount an NFS shared directory. You can specify individual authentication settings for each NFS share and mount in your environment. Authentication can be based on computer names, netgroups, networks, and/or DNS domains.

Authentication Methods

The specific authentication methods that are available to you depend on the settings in your /etc/nfssec.conf file. The four common NFS authentication methods are as follows:

AUTH_SYS -- The user's UNIX uid and gid are passed as clear (unencrypted) strings on the network, unauthenticated by the NFS server. This is the simplest security method and requires no additional administration, and is the default used by Solaris NFS Version 2 clients and Solaris NFS servers.
AUTH_DES -- Uses a distributed and encrypted public-private key database (similar to PGP) to generate secure transactions among users and servers. This method is only supported in NIS, NIS+, and Secure RPC environments. The Data Encryption Standard (DES) encryption functions use a 56-bit key to encrypt a secret key. If two credential users (or principals) know the same DES key, they can communicate in private, using the key to encipher and decipher text.
Authentication with DES is based on the ability of the sending system to use the common key to encrypt the current time, which the receiving system can decrypt and check against its current time. Make sure you synchronize the time on the client and the server.
The public and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey map, and NIS+ stores the keys in the cred table. These files contain the public key and the private key for all potential users. The system administrator is responsible for setting up NIS or NIS+ tables and generating a public key and a private key for each user. The private key is stored encrypted with the user's password. This makes the private key known only to the user.
AUTH_KERB -- Kerberos is an authentication system that was developed at the Massachusetts Institute of Technology. Kerberos uses DES encryption (see above) to authenticate a user when logging on to the system. Authentication is based on the ability of the sending system to use the common key to encrypt the current time, which the receiving system can decrypt and check against its current time.
Kerberos works by authenticating the user's logon password. A user enters the kinit command, which acquires a ticket that is valid for the time of the session (or eight hours, the default session time) from the Kerberos authentication server. When the user logs off, the ticket can be destroyed (using the kdestroy command).
Like AUTH_DES authentication, AUTH_KERB is only supported in NIS, NIS+, and Secure RPC environments. Unlike AUTH_DES, AUTH_KERB is not a distributed system -- that is, all authentication data for a given environment resides on a single machine. While that machine may be mirrored or backed up, users must go to one particular server for authentication. By contrast, in the distributed model of AUTH_DES, authentication tables are maintained across multiple authentication servers.
AUTH_NONE -- Null authentication. NFS clients using AUTH_NONE have no identity, and are mapped to the anonymous user, called nobody, by NFS servers. A client using a security mode other than the one with which a Solaris NFS server shares the file system will have its security mode mapped to AUTH_NONE. If the file system is shared with AUTH_NONE, users from the client will be mapped to the anonymous user. AUTH_NONE is supported for NFS shares, but not for NFS mounts or automounts.

Using Authentication Methods

Authentication is a two-part process: the NFS server (also called the NFS host) -- the one sharing the directory -- must support a particular authentication method, and an NFS client -- the one mounting the directory -- must be configured to use that same method. For example, for a client to successfully mount a directory using AUTH_SYS, both the client and the server must be configured for AUTH_SYS.

General NFS client authentication settings -- basically, a list of the methods defined on the client -- are stored on the client machine in the /etc/nfssec.conf file. These settings are augmented, particularly when using AUTH_DES or AUTH_KERB, with encrypted settings on one or more remote authentication servers.

If either the client or the server is not configured to use a particular method, and the client attempts to mount a shared directory using that method, the client will be handled as unauthenticated. Unauthenticated clients are given access privileges based on the User ID (uid) you specify on the Advanced tab in the Share Properties dialog box. By default, this uid is UID_NOBODY, which generally provides very limited access to the shared directory.

You can configure NFS clients and servers to use multiple authentication methods. If no method is specified, the default method defined in /etc/nfssec.conf (usually AUTH_SYS) is used automatically.

Client Access Lists

For each authentication method, AdminSuite's Mounts/Shares tool lets you specify default Read Only or Read/Write permissions that will be used by all clients that attempt to mount the shared directory using the same method. For example, you can specify Read/Write for all AUTH_SYS clients, but Read Only for all AUTH_DES clients. Default access privileges, as well as exceptions to the defaults, can be specified in the Advanced path in the Add Shared Directory wizard, or on the Access tab of the Share Properties dialog box.

Alternatively, you can create a Custom Access List for each method, which specifies access privileges for individual client types. In the Mounts/Shares tool, you create Custom Access Lists using the Advanced path in the Add Shared Directory wizard, or in the Add Client subdialog off the Access tab of the Share Properties dialog box.

When you add a client to a Custom Access List, the syntax you use determines the type of client you are adding. Specifically:

Host name -- The name of a host (server). With a server configured for DNS naming in the nsswitch.conf hosts entry, any server name must be represented as a fully qualified DNS name.
Netgroup -- A netgroup contains a number of server names. With a server configured for DNS naming in the nsswitch.conf hosts entry, any server name in a netgroup must be represented as a fully qualified DNS name.
DNS suffix -- To use domain membership, the server must use DNS to resolve server names to IP addresses; that is, the hosts entry in the /etc/nsswitch.conf file specifies dns ahead of nis or nisplus, since only DNS returns the full domain name of the server. Other name services like NIS or NIS+ cannot be used to resolve server names on the server because when mapping an IP address to a server they do not return domain information. For example, in NIS or NIS+, the IP address 129.144.45.9 might be mapped simply to myserver, whereas in DNS the same address might be mapped to myserver.mydomain.mycompany.com.
The DNS suffix is distinguished from server names and netgroups by a prefixed dot. For example, .mydomain.mycompany.com. A single dot can be used to match a server name with no suffix. For example:
.
matches mydomain but not mydomain.mycompany.com. This feature can be used to match server resolved through NIS and NIS+ rather than DNS.
Network -- The network or subnetwork component is preceded by an at-sign (@). It can be either a name or a dotted address. If a name, it will be automatically converted to a dotted address. For example:
    @mynet
is equivalent to:
    @129.144 or @129.144.0.0
The network prefix assumes an octet-aligned netmask determined from the zero octets in the low-order part of the address. In the case where network prefixes are not byte-aligned, the syntax will allow a mask length to be specified explicitly following a slash (/) delimiter. For example:
    @mynet/17 or rw=@129.144.132/17
where the mask is the number of leftmost contiguous significant bits in the corresponding IP address.
A prefixed minus sign (-) denies access to an item in the access list. The list is searched sequentially until a match is found that either grants or denies access, or until the end of the list is reached. For example, if server terra is in the engineering netgroup, then:
    -terra:engineering
denies access to terra, but:
    engineering:-terra
grants access to terra.