Previous Table of Contents Next

NIS+ Authentication

Every request to an NIS+ server is made by an NIS+ principal. An NIS+ principal can be a user or a workstation. Authentication is the process of identifying the principal who made a request to the NIS+ server by checking the principal’s credentials. These credentials are based on encrypted verification information stored in the NIS+ cred table.

The purpose of authentication is to obtain the principal’s name so that access rights to information in the name server can be looked up and verified. All interactions that an NIS+ principal has with an NIS+ server are authenticated.

The benefit of authentication is the protection of NIS+ information from access by untrusted clients, which provides more flexible and secure administration of NIS+ servers.

NOTE:  Protection of resource information in NIS+ does not imply protection of the resource itself. For example, protecting information about a server does not protect the server itself.

Principals can have two types of credentials: LOCAL and DES. A LOCAL credential consists of the UID of an NIS+ principal. An NIS+ server uses the LOCAL UID credential to look up the identity of the principal who sent the request so that the NIS+ server can determine the principal’s rights to access the requested object.

A DES credential is more complicated, and both users and systems can have such credentials. The DES credential consists of the principal’s secure RPC netname and a verification field.

Table 5-4 shows the columns in the cred table and describes the type of information stored for LOCAL and DES authentication.

Table 5-4 Columns in the cred Table

cname auth_type auth_name public_data private_data
NIS+ principal name of a client user LOCAL UID GID list None
NIS+ principal name of a client user or client system DES Secure RPC netname Public key Encrypted Private key

The first column, cname, contains the fully qualified credential name of an NIS+ principal. When the authentication type is LOCAL, the first column can only contain usernames because client systems cannot have LOCAL credentials. When the authentication type is DES, the principal name can be either a username or a system name.

The following example shows the contents of the cred table on the system named oak. The fields are separated by colons.

oak% niscat -h cred.org_dir
# cname:auth_type:auth_name:public_data:private_data

The first entry shows the names of the columns in the cred table. The second entry is the DES authentication for the system oak. The third and fourth entries are LOCAL and DES authentication entries for the user winsor. The fifth entry is LOCAL authentication for user ignatz, who has an account on the system. User ignatz does not have DES authentication credentials in the local domain. Only a LOCAL cred entry is needed if the user’s home domain is not the local one.

NIS+ security privileges are assigned in two stages: The principal is authenticated (identified) as an authorized user, and the access rights are checked.

Figure 5-7 shows a simplified view of how NIS+ security works.

Figure 5-7  How NIS+ security works.

NIS+ classifies NIS+ principals into four authorization categories, as shown in Table 5-5.

Table 5-5 NIS+ Authorization Categories

Abbreviation Authorization Description
n Nobody A category reserved for unauthenticated requests.
o Owner A single NIS+ principal, who was the creator of the object. You can change the ownership of existing objects using the nischown command.
g Group A collection of NIS+ principals, grouped together to provide access to the namespace. When an object is created, it is by default assigned to the NIS+ principal’s default group. NIS+ group information is stored in the NIS+ group object in the groups_dir subdirectory of every NIS+ domain.
w World All NIS+ principals that are authenticated by NIS+.

Previous Table of Contents Next