NIS+ credentials authenticate the identity of each principal requesting an NIS+ service or access to an NIS+ object. The NIS+ credential/authorization process is an implementation of the Secure RPC system.
The credential/authentication system prevents someone from assuming another'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 verify what operations that principal is authorized to perform. (See NIS+ Authorization and Access for further information on authorization.)
There are two basic types of principal, users and machines, and thus two different types of credentials:
NIS+ principals can have two types of credential: DES and local.
Data Encryption Standard (DES) credentials provide secure authentication. When this guide refers to NIS+ checking a credential to authenticate an NIS+ principal, it is the DES credential that NIS+ is validating. (Note that using DES credentials is only one method of achieving authentification. Do not equate DES credentials with NIS+ credentials.)
Each time a principal requests an NIS+ service or access to an 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 an NIS+ administrator, as explained in Administering NIS+ Credentials.
Local credentials are a map between a user's user ID number and their 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. The following figure illustrates this concept.
Figure 7-2. Credential and Domains. This illustration shows a domain hierarchy. The user's home domain has local and DES credentials. The subdomain only has local credentials. Home and the subdomain are labeled Client User Credentials.
|
Local credential information can be stored in any domain. 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+ cannot 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.
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 is not appropriate for a client workstation; it is allowed only for a client user.