fns_nis+(5)

NAME

fns_nis+ − overview of FNS over NIS+ implementation

DESCRIPTION

Federated Naming Service (FNS) provides a method for federating multiple naming services under a single, simple interface for the basic naming operations. One of the naming services supported by FNS is NIS+, the enterprise-wide information service in Solaris (see nis+(1)). FNS provides the XFN interface for performing naming and attribute operations on FNS enterprise objects (organization, site, user, host, and service objects) using NIS+. FNS stores bindings for these objects in NIS+ and uses them in conjunction with existing NIS+ objects.

FNS Policies and NIS+

FNS defines policies for naming objects in the federated namespace (see fns_policies(5)). At the enterprise level, FNS policies specify naming for organizations, hosts, users, sites, and services. The enterprise-level naming service provides contexts to allow other objects to be named relative to these objects.

The organizational unit namespace provides a hierarchical namespace for naming subunits of an enterprise. An organizational unit maps to an NIS+ domain. Organizational unit names can be either fully qualified NIS+ domain names or relatively NIS+ domain names. If a terminal dot is present in the name, it is treated as a fully qualified name. Otherwise, the name is resolved relative to the root NIS+ domain.

Users in the NIS+ namespace are found in the passwd.org_dir table of an NIS+ domain. Users in an FNS organizational unit correspond to the users in the passwd.org_dir table of the corresponding NIS+ domain. FNS provides a context for each user in the passwd.org_dir table.

Hosts in the NIS+ namespace are found in the hosts.org_dir table of an NIS+ domain. Hosts in an FNS organizational unit correspond to the hosts in the hosts.org_dir table of the corresponding NIS+ domain. FNS provides a context for each host in the hosts.org_dir table.

In NIS+, users and hosts have a notion of a home domain. It is the primary NIS+ domain that maintains information associated with them. A user or host’s home domain can be determined directly using its NIS+ principal name, which is composed of the atomic user (login) name or the atomic host name, and the name of the NIS+ home domain. For example, user jsmith with home domain wiz.com has an NIS+ principal name, jsmith.wiz.com.

A user’s NIS+ home domain corresponds to the user’s FNS organizational unit and determines the binding for myens and myorgunit.

A host’s NIS+ home domain corresponds to the host’s FNS organizational unit and determines the binding for thisens, thisorgunit, user, and host.

Federating NIS+ with DNS or X.500

Federating NIS+ with the global naming systems DNS or X.500 makes NIS+ contexts accessible outside of an NIS+ hierarchy. To enable the federation, the administrator must first add address information in either DNS or X.500 (see fns_dns(5) and fns_x500(5)). After this administrative step has been taken, clients outside of the NIS+ hierarchy can access contexts and perform operations from outside the hierarchy as an unauthenticated NIS+ client.

NIS+ Security

The command fncreate(1M) creates NIS+ tables and directories in the NIS+ hierarchy associated with the domain of the host on which it executes. The invoker of fncreate(1M) and other FNS commands is expected to have the necessary NIS+ credentials. (See nis+(1) and nisdefaults(1)). The environment variable NIS_GROUP of the process specifies the group owner for the NIS+ objects thus created. In order to facilitate administration of the NIS+ objects, NIS_GROUP should be set to the name of the NIS+ administration group for the domain prior to executing fncreate(1M) and other FNS commands. Changes to NIS+-related properties, including default access control rights, could be effected using NIS+ administration tools and interfaces after the context has been created. The NIS+ object name that corresponds to an FNS composite name can be obtained using fnlookup(1) and fnlist(1).

Museum