NIS+ Authentication and Credentials

The purpose of NIS+ credentials is to authenticate (confirm) the identity of each principal requesting a NIS+ service or access to a NIS+ object. In essence, the NIS+ credential/authorization process is an implementation of the Secure RPC system.

The credential/authentication system prevents someone from assuming some other user's identity. That is, it prevents someone with root privileges on one machine from using the su command to assume the identity of a second user who is either not logged in at all or logged in on another machine and then accessing NIS+ objects with the second user's NIS+ access privileges.

Note: NIS+ cannot prevent someone who knows another user's login password from assuming that other user's identity and the other user's NIS+ access privileges. Nor can NIS+ prevent a user with root privileges from assuming the identity of another user who is currently logged in on the same machine.

Once a server authenticates a principal, it then checks the NIS+ object that the principal wants to access to see what activities that principal is authorized to perform. (See NIS+ Authorization and Access for further information on authorization.)

User and Machine Credentials

There are two basic types of principal, users and machines, and thus two different types of credentials:

User credentials

When someone is logged in to an NIS+ client as a regular user, requests for NIS+ services include that person's user credentials.

Machine credentials

When a user is logged in to an NIS+ client as superuser, request for services use the client workstation's credentials.

DES versus LOCAL Credentials

NIS+ principals can have two types of credential: DES and LOCAL.

DES Credentials

Data Encryption Standard (DES) credentials are the type of credential that provide secure authentication. When this guide refers to NIS+ checking a credential to authenticate a NIS+ principal, it is the DES credential that NIS+ is validating. (Note that DES credentials are only one method of achieving authentification. In the future, other methods may be available. Thus, do not equate DES credentials with NIS+ credentials.)

Each time a principal requests a NIS+ service or access to a NIS+ object, the software uses the credential information stored for that principal to generate a credential for that principal. DES credentials are generated from information created for each principal by a NIS+ administrator, as explained in Administering NIS+ Credentials.

• When the validity of a principal's DES credential is confirmed by NIS+, that principal is authenticated.
• A principal must be authenticated in order to be placed in the owner, group, or world authorization classes. In other words, you must have a valid DES credential in order to be placed in one of those classes. (Principals that do not have a valid DES credential are automatically placed in the nobody class.)
• DES credential information is always stored in the cred table of the principal's home domain, regardless of whether that principal is a client user or a client workstation.

LOCAL Credentials

LOCAL credentials are simply a map between a user's User ID number and NIS+ principal name which includes their home domain name. When users log in, the system looks up their LOCAL credential, which identifies their home domain where their DES credential is stored. The system uses that information to get the user's DES credential information.

When users log in to a remote domain, those requests use their LOCAL credential which points back to their home domain; NIS+ then queries the user's home domain for that user's DES credential information. This allows a user to be authenticated in a remote domain even though the user's DES credential information is not stored in that domain. For more information, see figure.

Credentials and Domains

LOCAL credential information can be stored in any domain. In fact, in order to log into a remote domain and be authenticated, a client user must have a LOCAL credential in the cred table of the remote domain. If a user does not have a LOCAL credential in a remote domain the user is trying to access, NIS+ will be unable to locate the user's home domain to obtain the user's DES credential. In such a case the user would not be authenticated and would be placed in the nobody class.

User Types and Credential Types

A user can have both types of credential, but a machine can only have a DES credential.

Root cannot have NIS+ access, as root, to other machines because the root UID of every machine is always zero. If root (UID=0) of machine A tried to access machine B as root, that would conflict with machine B's already existing root (UID=0). Thus, a LOCAL credential does not make sense for a client workstation; so it is allowed only for a client user.