DES Credentials
Note - DES credentials are only one method of achieving authentication. In the future, other methods may be available. Thus, do not equate DES credentials with NIS+ credentials.
In this document, the term DES credentials is used generically to denote a Diffie-Hellman key based authentication, regardless of key length. The system allows you to specify the key length from a pre-determined set. Use nisauthconf(1M) to set or display the Diffie-Hellman key length.
DES (Data Encryption Standard) credentials are the type of credential that 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.
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 Chapter 12, 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 who 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 machine.
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.
Figure 11-3 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 credentials, but a machine can only have DES credentials.
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 doesn't make sense for a client machine; so it is allowed only for a client user.
Table 11-2 Types of Credentials
Type of Credential | Client User | Client machine |
|---|---|---|
DES | Yes | Yes |
LOCAL | Yes | No |
NIS+ Authorization and Access--Introduction
The basic purpose of NIS+ authorization is to specify the access rights that each NIS+ principal has for each NIS+ object and service.
Once the principal making an NIS+ request is authenticated, NIS+ places them in an authorization class. The access rights (permissions) that specify which activities a principal may do with a given NIS+ object are assigned on a class basis. In other words, one authorization class may have certain access rights while a different class has different rights.
Authorization classes. There are four authorization classes: owner, group, world, and nobody. (See "Authorization Classes" below for details.)
Access rights. There are four types of access rights (permissions): create, destroy, modify, and read. (See " NIS+ Access Rights" for details.)
Authorization Classes
NIS+ objects do not grant access rights directly to NIS+ principals. Instead, they grant access rights to four classes of principal:
Owner. The principal who happens to be the object's owner gets the rights granted to the owner class.
Group. Each NIS+ object has one group associated with it. The members of an object's group are specified by the NIS+ administrator. The principals who belong to the object's group class get the rights granted to the group class. (In this context, group refers to NIS+ groups, not UNIX or net groups.)
World. The world class encompasses all NIS+ principals that a server has been able to authenticate. (That is, everyone who has been authenticated but who is not in either the owner or group classes.)
Nobody. Everyone belongs to the nobody class even those who are not authenticated.
Figure 11-4 Authorization Classes
For any NIS+ request, the system determines which class the requesting principal belongs to and the principal then can use whatever access rights belonging to that class.
An object can grant any combination of access rights to each of these classes. Normally, however, a higher class is assigned the same rights as all the lower classes, plus possible additional rights.
For instance, an object could grant read access to the nobody and world classes; both read and modify access to the group class; and read, modify, create, and destroy access to the owner class.
The four classes are described in detail below.
The Owner Class
The owner is a single NIS+ principal.
A principal making a request for access to an NIS+ object must be authenticated (present a valid DES credential) before being granted owner access rights.
By default, an object's owner is the principal that created the object. However, an object's owner can cede ownership to another principal in two ways:
One way is for the principal to specify a different owner at the time the object is created (see "Specifying Access Rights in Commands").
A second way is for the principal to change the ownership of the object after it is created (see "Changing Ownership of Objects and Entries").
Once a principal gives up ownership, that principal gives up all owner's access rights to the object and keeps only the rights the object assigns to either the group, the world, or nobody.
The Group Class
The object's group is a single NIS+ group. (In this context, group refers to NIS+ groups, not UNIX or net groups.)
A principal making a request for access to an NIS+ object must be authenticated (present a valid DES credential) and belong to the group before being granted group access rights.
An NIS+ group is a collection of NIS+ principals, grouped together as a convenience for providing access to the namespace. The access rights granted to an NIS+ group apply to all the principals that are members of that group. (An object's owner, however, does not need to belong to the object's group.)
When an object is created it may be assigned a default group. A nondefault group can be specified for an object when it is created or later. An object's group may be changed at any time.
Note - Information about NIS+ groups is not stored in the NIS+ group table. The group table stores information about UNIX groups. Information about NIS+ groups is stored in the appropriate groups_dir directory object.
Information about NIS+ groups is stored in NIS+ group objects, under the groups_dir subdirectory of every NIS+ domain:
Figure 11-5 NIS+ Directory Structure
Instructions for administering NIS+ groups are provided in Chapter 17, Administering NIS+ Groups.
The World Class
The world class contains all NIS+ principals that are authenticated by NIS+. In other words, the world class includes everyone in the owner and group class, plus everyone else who presents a valid DES credential.
Access rights granted to the world class apply to all authenticated principals.