HP-UX Reference (11i v2 04/09) - 1 User Commands N-Z (vol 2)

n
nis+(1) nis+(1)
This mechanism of mapping UID and netnames into an NIS+ principal name guarantees that a client of
the NIS+ service has only one principal name. This principal name is used as the basis for authorization
which is described below. All objects in the NIS+ namespace and all entries in NIS+ tables must have an
owner specified for them. This owner field always contains an NIS+ principal name.
Group Names
Like NIS+ principal names, NIS+ group names take the form:
group_name.domain
All objects in the NIS+ namespace and all entries in NIS+ tables may optionally have a group owner
specified for them. This group owner field, when filled in, always contains the fully qualified NIS+ group
name.
The NIS+ client library defines several interfaces ( nis_groups (3N)) for dealing with NIS+ groups. These
interfaces internally map NIS+ group names into an NIS+ simple name which identifies the NIS+ group
object associated with that group name. This mapping can be shown as follows:
group.domain
-> group.groups_dir.domain
This mapping eliminates collisions between NIS+ group names and NIS+ directory names. For example,
without this mapping, a directory with the name
engineering.foo.com.
, would make it impossible
to have a group named
engineering.foo.com.
. This is due to the restriction that within the NIS+
namespace, a name unambiguously identifies a single object. With this mapping, the NIS+ group name
engineering.foo.com.
maps to the NIS+ object name engineering.groups_dir.foo.com.
The contents of a group object is a list of NIS+ principal names and the names of other NIS+ groups. See
nis_groups(3N) for a more complete description of their use.
NIS+ SECURITY
NIS+ defines a security model to control access to information managed by the service. The service
defines access rights that are selectively granted to individual clients or groups of clients. Principal
names and group names are used to define clients and groups of clients that may be granted or denied
access to NIS+ information. These principals and groups are associated with NIS+ domains as defined
below.
The security model also uses the notion of a class of principals called nobody, which contains all clients,
whether or not they have authenticated themselves to the service. The class world includes any client
who has been authenticated.
Directories and Domains
Some directories within the NIS+ namespace are referred to as NIS+ Domains. Domains are those NIS+
directories that contain the subdirectories groups_dir and org_dir. Further, the subdirectory org_dir
should contain the table named cred. NIS+ Group names and NIS+ Principal names always include the
NIS+ domain name after their first label.
Authentication
The NIS+ name service uses Secure RPC for the integrity of the NIS+ service. This requires that users of
the service and their machines must have a Secure RPC key pair associated with them. This key is ini-
tially generated with either the nisaddcred(1M) or nisclient (1M) commands and modified with the
chkey(1) or nispasswd(1) commands.
The use of Secure RPC allows private information to be stored in the name service that will not be avail-
able to untrusted machines or users on the network.
In addition to the Secure RPC key, users need a mapping of their UID into an NIS+ principal name. This
mapping is created by the system administrator using the nisclient (1M) or nisaddcred(1M) command.
Users that will be using machines in several NIS+ domains must insure that they have a local credential
entry in each of those domains. This credential should be created with the NIS+ principal name of the
user in their "home" domain. For the purposes of NIS+ and Secure RPC, the home domain is defined to
be the one where your Secure RPC key pair is located.
Authorization
The NIS+ service defines four access rights that can be granted or denied to clients of the service. These
rights are read, modify, create , and destroy. These rights are specified in the object structure at creation
time and may be modified later with the nischmod(1) command. In general, the rights granted for an
object apply only to that object. However, for purposes of authorization, rights granted to clients reading
HP-UX 11i Version 2: September 2004 − 5 − Hewlett-Packard Company Section 1−−635