The nisaddcred command is used to create security credentials for NIS+ principals. NIS+ credentials serve two purposes. The first is to provide authentication information to various services; the second is to map the authentication service name into a NIS+ principal name.
When the nisaddcred command is run, these credentials get created and stored in a table named cred.org_dir in the default NIS+ domain. If domain_name is specified, the entries are stored in the cred.org_dir of the
specified domain. The specified domain must either be the one to which you belong, or one in which you are authenticated and authorized to create credentials, that is, a subdomain. Note that the credentials of normal users must be stored in the same domain as their passwords.
It is simpler to add credentials using nisclient(1M), because it obtains the required information itself. nispopulate(1M) is used for "bulk" updates and can also be used to add credentials for entries in the hosts and the passwd NIS+ tables.
NIS+ principal names are used in specifying clients that have access rights to NIS+ objects. For more details, refer to the "Principal Names" subsection of the nis+(1) manual page. See nischmod(1), nischown(1), nis_objects(3NSL), and nis_groups(3NSL). Various other services can also implement access control based on these principal names.
The cred.org_dir table is organized as follows:
cname | auth_type | auth_name | public_data | private_data |
user1.foo.com. | LOCAL | 2990 | 10,102,44 | |
user1.foo.com. | DES | unix.2990@foo.com | 098...819 | 3b8...ab2 |
user1.foo.com. | DHmmm-n | unix.2990@foo.com | 248...428 | a42...f32 |
The cname column contains a canonical representation of the NIS+ principal name. By convention, this name is the login name of a user, or the host name of a machine, followed by a dot ('.') followed by the fully qualified "home" domain of that principal. For users,
the home domain is defined to be the domain where their DES credentials are kept. For hosts, their home domain is defined to be the domain name returned by the domainname(1M) command executed on that host.
There are two basic types of auth_type entries in the cred.org_dir table, those with authentication type LOCAL, and those with authentication type DES, auth_type,
specified on the command line in upper or lower case, should be either local or des.
However, the cred.org_dir table may also be used to hold data for other values of auth_type. Currently, this is limited to the mechanisms listed on the nisauthconf(1M) man page, for which the nisaddcred auth_type argument is the same as the name of the mechanism. These mechanisms use a modified form of Secure RPC, and they are similar to the DES authentication
type.
If the auth_type is des, and other authentication mechanisms are configured with nisauthconf(1M), then credential entries are added
or updated for each mechanism configured. To only add or update 1992-bit Diffie Hellman credentials, that is, those with the auth_type of DES, use dh192-0 on the command line. If there are no authentication mechanisms configured, using des on the command line will only add or update 192-bit Diffie Hellman credentials.
Entries of type LOCAL are used by the NIS+ service to determine the correspondence between fully qualified NIS+ principal names and users identified by UIDs in the
domain containing the cred.org_dir table. This correspondence is required when associating requests made using the AUTH_SYS RPC authentication flavor (see rpc_clnt_auth(3NSL)) to a NIS+ principal name. It is also required for mapping a UID in one domain to its fully qualified NIS+ principal name whose home domain may be elsewhere. The principal's credentials for
any authentication flavor may then be sought for within the cred.org_dir table in the principal's home domain (extracted from the principal name). The same NIS+ principal may have LOCAL credential entries in more than
one domain. Only users, and not machines, have LOCAL credentials. In their home domain, users of NIS+ should have both types of credentials.
The auth_name associated with the LOCAL type entry is a UID that is valid for the principal in the domain containing the cred.org_dir table. This may differ from that in the principal's
home domain. The public information stored in public_data for this type contains a list of GIDs for groups in which the user is a member. The GIDs also apply to the domain in which the table resides. There is
no private data associated with this type. Neither a UID nor a principal name should appear more than once among the LOCAL entries in any one cred.org_dir table.
The DES auth_type is used for Secure RPC authentication (see secure_rpc(3NSL)).
The authentication name associated with the DES auth_type is a Secure RPC netname. A Secure RPC netname has the form unix.id@domain.com,
where domain must be the same as the domain of the principal. For principals that are users the id must be the UID of the principal in the principal's home domain. For principals that are hosts, the id is
the host's name. In Secure RPC, processes running under effective UID 0 (root) are identified with the host principal. Unlike LOCAL, there cannot be more than one DES credential entry for one NIS+ principal
in the NIS+ namespace.
The public information in an entry of authentication type DES is the public key for the principal. The private information in this entry is the private key of the principal encrypted by the principal's network password.
User clients of NIS+ should have credentials of both types in their home domain. In addition, a principal must have a LOCAL entry in the cred.org_dir table of each domain from which the principal wishes to make authenticated requests. A client
of NIS+ that makes a request from a domain in which it does not have a LOCAL entry will be unable to acquire DES credentials. A NIS+ service running at security level 2 or higher will consider such users unauthenticated and assign them
the name nobody for determining access rights.
This command can only be run by those NIS+ principals who are authorized to add or delete the entries in the cred table.
If credentials are being added for the caller itself, nisaddcred automatically performs a keylogin for the caller.
You can list the cred entries for a particular principal with nismatch(1).
The cred.org_dir NIS+ table replaces the maps publickey.byname and netid.byname used in NIS (YP).
|