<?Pub UDT _bookmark _target?><?Pub EntList bsol dash hellip gt lt minus?><chapter id="intro2ns-2"><?Pub Tag atict:info tracking="on" ref="0"?><?Pub Tag atict:user
user="sharonr" fullname="Sharon Veach"?><title>Naming and Directory Services (Overview)</title><highlights><para>This chapter provides an overview of naming and directory services used
in Solaris. This chapter also briefly describes DNS, NIS, and LDAP naming
services. See <olink targetdoc="sysadv7" remap="external"><citetitle remap="book">System Administration Guide: Naming and Directory Services (NIS+)</citetitle></olink> for detailed
information about NIS+.</para>
</highlights><sect1 id="a00intro-21293"><title>What Is a Naming Service?</title><indexterm significance="preferred"><primary>naming</primary>
</indexterm><para><emphasis>Naming services</emphasis> store information in a central
place, which enables users, machines, and applications to communicate across
the network. This information can include the following.</para><itemizedlist><listitem><para>Machine (host) names and addresses</para>
</listitem><listitem><para>User names</para>
</listitem><listitem><para>Passwords</para>
</listitem><listitem><para>Access permissions</para>
</listitem><listitem><para>Group membership, printers, and so on</para>
</listitem>
</itemizedlist><para>Without a central naming service, each machine would have to maintain
its own copy of this information. Naming service information can be stored
in files, maps, or database tables.  If you centralize all data, administration
becomes easier.</para><para>Naming services are fundamental to any computing network. Among other
features, naming service provide functionality that does the following.</para><itemizedlist><listitem><para>Associates (<emphasis>binds</emphasis>) names with objects</para>
</listitem><listitem><para>Resolves names to objects</para>
</listitem><listitem><para>Removes bindings</para>
</listitem><listitem><para>Lists names</para>
</listitem><listitem><para>Renames</para>
</listitem>
</itemizedlist><para>A network information service enables machines to be identified by common
names instead of numerical addresses. This makes communication simpler because
users do not have to remember and try to enter cumbersome numerical addresses
like <literal>192.168.0.0</literal>.</para><para><indexterm><primary>/etc/inet/ipnodes</primary></indexterm><indexterm><primary><filename>/etc/hosts</filename></primary></indexterm>For example,
take a network of three machines that are named, <literal>pine</literal>, <literal>elm</literal>, and <literal>oak</literal>. Before <literal>pine</literal> can
send a message to either <literal>elm</literal> or <literal>oak</literal>, <literal>pine</literal> must know their numerical network addresses. For this reason, <literal>pine</literal> keeps a file, <filename>/etc/hosts</filename> or <filename>/etc/inet/ipnodes</filename>, that stores the network address of every machine in the network,
including itself.</para><mediaobject><imageobject><imagedata entityref="fig54.epsi"/>
</imageobject><textobject><simpara>Illustration shows pine, elm, and oak machines with respective
IP addresses listed on pine.</simpara>
</textobject>
</mediaobject><para>Likewise, in order for <literal>elm</literal> and <literal>oak</literal> to
communicate with <literal>pine</literal> or with each other, the machines
must keep similar files.</para><mediaobject><imageobject><imagedata entityref="fig55.epsi"/>
</imageobject><textobject><simpara>Illustration shows machines keeping all IP addresses
of machines on network in their respective /etc/hosts file.</simpara>
</textobject>
</mediaobject><para>In addition to storing addresses, machines store security information,
mail data, network services information and so on.  As networks offer more
services, the list stored of information grows. As a result, each machine
might need to keep an entire set of files which are similar to <filename>/etc/hosts</filename> or <filename>/etc/inet/ipnodes</filename>.</para><para>A network information service stores network information on a server,
which can be queried by any machine.</para><para>The machines are known as <emphasis>clients</emphasis> of the server.
The following figure illustrates the client-server arrangement. Whenever information
about the network changes, instead of updating each client's local file, an
administrator updates only the information stored by the network information
service. Doing so reduces errors, inconsistencies between clients, and the
sheer size of the task.</para><mediaobject><imageobject><imagedata entityref="fig56.epsi"/>
</imageobject><textobject><simpara>Illustration shows server and clients in client-server
computing relationship.</simpara>
</textobject>
</mediaobject><para>This arrangement, of a server providing centralized services to clients
across a network, is known as <emphasis>client-server computing</emphasis>.</para><para>Although the main purpose of a network information service is to centralize
information, the network information service can also simplify network names.
For example, assume your company has set up a network which is connected to
the Internet. The Internet has assigned your network the network number <literal>192.168.0.0</literal> and the domain name <literal>doc.com</literal>. Your
company has two divisions, Sales and Manufacturing (Manf), so its network
is divided into a main net and one subnet for each division. Each net has
its own address.</para><mediaobject><imageobject><imagedata entityref="fig57.epsi"/>
</imageobject><textobject><simpara>Diagram shows doc.com and two subnets with IP addresses.</simpara>
</textobject>
</mediaobject><para>Each division could be identified by its network address, as shown above,
but descriptive names made possible by naming services would be preferable.</para><mediaobject><imageobject><imagedata entityref="fig58.epsi"/>
</imageobject><textobject><simpara>Diagram shows doc.com and two subnets with descriptive
names.</simpara>
</textobject>
</mediaobject><para>Instead of addressing mail or other network communications to <literal>198.168.0.0</literal>, mail could be addressed to <literal>doc</literal>. Instead of
addressing mail to <literal>192.168.2.0</literal> or <literal>192.168.3.0</literal>,
mail could be addressed to <literal>sales.doc</literal> or  <literal>manf.doc</literal>.</para><para>Names are also more flexible than physical addresses. Physical networks
tend to remain stable, but company organization tends to change.</para><para>For example, assume that the <literal>doc.com</literal> network is supported
by three servers, S1, S2, and S3. Assume that two of those servers, S1 and
S3, support clients.</para><mediaobject><imageobject><imagedata entityref="fig59.epsi"/>
</imageobject><textobject><simpara>Illustration shows doc.com domain with three servers,
two of which have three clients each.</simpara>
</textobject>
</mediaobject><para>Clients C1, C2, and C3 would obtain their network information from server
S1. Clients C4, C5, and C6 would obtain information from server S3. The resulting
network is summarized in the following table. The table is a generalized representation
of that network but does not resemble an actual network information map.</para><table frame="topbot" id="a00intro-55314"><title>Representation of docs.com
network</title><tgroup cols="4" colsep="0" rowsep="0"><colspec colnum="1" colname="column1" colwidth="2*"/><colspec colnum="2" colname="column2" colwidth="2*"/><colspec colnum="3" colname="column3" colwidth="2*"/><colspec colnum="4" colname="column4" colwidth="2*"/><thead><row rowsep="1"><entry colname="column1" align="left" valign="bottom"><para>Network Address</para>
</entry><entry colname="column2" align="left" valign="bottom"><para>Network Name</para>
</entry><entry colname="column3" align="left" valign="bottom"><para>Server</para>
</entry><entry colname="column4" align="left" valign="bottom"><para>Clients</para>
</entry>
</row>
</thead><tbody><row><entry colname="column1" align="left" valign="top"><para>192.168.1.0</para>
</entry><entry colname="column2" align="left" valign="top"><para>doc</para>
</entry><entry colname="column3" align="left" valign="top"><para>S1</para>
</entry><entry colname="column4" align="left" valign="top"><para></para>
</entry>
</row><row><entry colname="column1" align="left" valign="top"><para>192.168.2.0</para>
</entry><entry colname="column2" align="left" valign="top"><para>sales.doc</para>
</entry><entry colname="column3" align="left" valign="top"><para>S2</para>
</entry><entry colname="column4" align="left" valign="top"><para>C1, C2, C3</para>
</entry>
</row><row><entry colname="column1" align="left" valign="top"><para>192.168.3.0</para>
</entry><entry colname="column2" align="left" valign="top"><para>manf.doc</para>
</entry><entry colname="column3" align="left" valign="top"><para>S3</para>
</entry><entry colname="column4" align="left" valign="top"><para>C4, C5, C6</para>
</entry>
</row>
</tbody>
</tgroup>
</table><para>Now, assume that you create a third division, Testing, which borrowed
some resources from the other two divisions, but did not create a third subnet.
The physical network would then no longer parallel the corporate structure.</para><mediaobject><imageobject><imagedata entityref="fig60.epsi"/>
</imageobject><textobject><simpara>Diagram shows adding third division called Test without
adding a third subnet.</simpara>
</textobject>
</mediaobject><para>Traffic for the Test Division would not have its own subnet, but would
instead be split between <literal>192.168.2.0</literal> and <literal>192.168.3.0</literal>.
However, with a network information service, the Test Division traffic could
have its own dedicated network.</para><mediaobject><imageobject><imagedata entityref="fig61.epsi"/>
</imageobject><textobject><simpara>Diagram shows Test Division with its own dedicated network.</simpara>
</textobject>
</mediaobject><para>Thus, when an organization changes, its network information service
can change its mapping as shown here.</para><mediaobject><imageobject><imagedata entityref="fig62.epsi"/>
</imageobject><textobject><simpara>Illustration shows change in network mapping where some
clients move from one server to another.</simpara>
</textobject>
</mediaobject><para>Now, clients C1 and C2 would obtain their information from server S2.
C3, C4 and C5 would obtain information from server S3.</para><para>Subsequent changes in your organization would be accommodated by changes
to the network information structure without reorganizing the network structure.</para>
</sect1><sect1 id="a00intro-33967"><title>Solaris Naming Services</title><indexterm><primary>naming</primary><secondary>Solaris naming services</secondary>
</indexterm><indexterm><primary>Solaris naming services</primary>
</indexterm><para>The Solaris platform provides the following naming services.</para><itemizedlist><listitem><para>DNS, the <emphasis>Domain Name System</emphasis> (see <olink targetptr="a00intro-58886" remap="internal">Description of the DNS Naming Service</olink>)</para>
</listitem><listitem><para><indexterm><primary><filename>/etc</filename> files</primary></indexterm><filename>/etc</filename> files, the original <trademark class="registered">UNIX</trademark> naming system (see <olink targetptr="a00intro-29909" remap="internal">Description of the /etc Files Naming Service</olink>)</para>
</listitem><listitem><para>NIS, the <emphasis>Network Information Service</emphasis> (see <olink targetptr="a00intro-97078" remap="internal">Description of the NIS Naming Service</olink>)</para>
</listitem><listitem><para>NIS+, the <emphasis>Network Information Service Plus</emphasis> (see <olink targetdoc="sysadv7" remap="external"><citetitle remap="book">System Administration Guide: Naming and Directory Services (NIS+)</citetitle></olink>)</para>
</listitem><listitem><para>LDAP, the <emphasis>Lightweight Directory Access Protocol</emphasis> (see <olink targetptr="ldapsetup-1" remap="internal">Part&nbsp;IV, LDAP Naming Services Setup and Administration</olink> <citetitle>LDAP Naming Services Setup and Administration</citetitle>)</para>
</listitem>
</itemizedlist><para><indexterm><primary><filename>nsswitch.conf</filename> files</primary></indexterm>Most modern networks use two or more of these services in combination.
When more than one service is used, the services  are coordinated by the <filename>nsswitch.conf</filename> file which is discussed in <olink targetptr="a12swit-86415" remap="internal">Chapter&nbsp;2, The Name Service Switch (Overview)</olink>.</para><sect2 id="a00intro-58886"><title>Description of the DNS Naming Service</title><indexterm significance="preferred"><primary>DNS</primary>
</indexterm><indexterm><primary>naming</primary><secondary>DNS</secondary>
</indexterm><para>DNS is the naming service provided by the Internet for TCP/IP networks.
DNS was developed so that machines on the network could be identified with
common names instead of Internet addresses. DNS performs naming between hosts
within your local administrative domain and across domain boundaries.</para><para><indexterm><primary><command>in.named</command></primary></indexterm><indexterm><primary>name space</primary><secondary>DNS</secondary></indexterm>The collection
of networked machines that use DNS are referred to as the <emphasis>DNS namespace</emphasis>. The DNS namespace can be divided into a hierarchy of <emphasis>domains</emphasis>. A DNS domain is a group of machines. Each domain is supported
by two or more <emphasis>name servers</emphasis>, a principal server and one
or more secondary servers. Each server implements DNS by running the <command>in.named</command> daemon. On the client's side, DNS is implemented through the &ldquo;resolver.&rdquo;
The resolver's function is to resolve users' queries. The resolver queries
a name server, which then returns either the requested information or a referral
to another server.</para>
</sect2><sect2 id="mdns-1"><title>Description of Multicast DNS and Service Discovery</title><para><indexterm><primary>multicast DNS</primary></indexterm><indexterm><primary>mDNS</primary></indexterm><indexterm><primary>DNS service discovery</primary></indexterm>Support for two extensions to the DNS protocol is now available.
These two extensions are multicast DNS (mDNS) and DNS Service Discovery (DNS-SD).
mDNS extends the Domain Name Service system to operate over link-local multicast.
DNS-SD adds support for discovering network services over DNS.</para>
</sect2><sect2 id="a00intro-29909"><title>Description of the <filename>/etc</filename> Files
Naming Service</title><indexterm significance="preferred"><primary>files-based naming</primary>
</indexterm><indexterm><primary>naming</primary><secondary>files-based</secondary>
</indexterm><para>The original host-based UNIX naming system was developed for standalone
UNIX machines and then adapted for network use. Many old UNIX operating systems
and machines still use this system, but the system is not well suited for
large complex networks.</para>
</sect2><sect2 id="a00intro-97078"><title>Description of the NIS Naming Service</title><indexterm significance="preferred"><primary>NIS</primary>
</indexterm><indexterm><primary>naming</primary><secondary>NIS</secondary>
</indexterm><para>The <emphasis>Network Information Service</emphasis> (NIS) was developed
independently of DNS. DNS makes communication simpler by using machine names
instead of numerical IP addresses. NIS focuses on making network administration
more manageable by providing centralized control over a variety of network
information. NIS stores information about the network,  machine names and
addresses, users, and network services. This collection of network information
is referred to as the <emphasis>NIS namespace</emphasis>.</para><para>NIS namespace information is stored in NIS maps. NIS maps were designed
to replace UNIX <filename>/etc</filename> files, as well as other configuration
files. NIS maps store much more than names and addresses. As a result, the
NIS namespace has a large set of maps. See <olink targetptr="anis2-11278" remap="internal">Working
With NIS Maps</olink> for more information.</para><para>NIS uses a client-server arrangement which is similar to DNS. Replicated
NIS servers provide services to NIS clients. The principal servers are called <emphasis>master</emphasis> servers, and for reliability, the servers have backup, or <emphasis>slave</emphasis> servers. Both master and slave servers use the NIS  retrieval
software and both store NIS maps. For more information on NIS Architecture
and NIS Administration, see <olink targetptr="cnis1-25208" remap="internal">Chapter&nbsp;5,
Setting Up and Configuring NIS Service</olink> and <olink targetptr="anis2-22217" remap="internal">Chapter&nbsp;6, Administering NIS (Tasks)</olink>.</para>
</sect2><sect2 id="a00intro-34260"><title>Description of the NIS+ Naming Service</title><para>The <emphasis>Network Information Service Plus</emphasis> (NIS+) is
similar to NIS but with more features. However, NIS+ is not an extension of
NIS.</para><para>The NIS+ naming service is designed to conform to the shape of the organization.
Unlike NIS, the NIS+ namespace is dynamic because updates can occur and be
put into effect at any time by any authorized user.</para><para>NIS+ enables you to store information about machine addresses, security
information, mail information, Ethernet interfaces, and network services in
one central location. This configuration of network information is referred
to as the NIS+ <emphasis>namespace</emphasis>.</para><para>The NIS+ namespace is hierarchical. The NIS+ namespace is similar in
structure to the UNIX directory file system. The hierarchical structure allows
an NIS+ namespace to be configured to conform to the logical hierarchy of
an organization. The namespace's layout of information is unrelated to its <emphasis>physical</emphasis> arrangement. Thus, an NIS+ namespace can be divided into
multiple domains that can be administered autonomously. Clients might have
access to information in domains other than their own if the clients have
the appropriate permissions.</para><para>NIS+ uses a client-server model to store and have access to the information
contained in an NIS+ namespace. Each domain is supported by a set of servers.
The principal server is called the <emphasis>primary</emphasis> server. The
backup servers are called <emphasis>secondary servers</emphasis>. The network
information is stored in 16 standard NIS+ tables in an internal NIS+ database.
Both primary and secondary servers run NIS+ server software and both maintain
copies of NIS+ tables. Changes made to the NIS+ data on the master server
are incrementally propagated automatically to the secondary servers.</para><para>NIS+ includes a sophisticated security system to protect the structure
of the namespace and its information. NIS+ uses authentication and authorization
to verify whether a client's request for information should be fulfilled. <emphasis>Authentication</emphasis> determines whether the information requester is
a valid user on the network. <emphasis>Authorization</emphasis> determines
whether a particular user is allowed to have or modify the information requested.
See <olink targetdoc="sysadv7" remap="external"><citetitle remap="book">System Administration Guide: Naming and Directory Services (NIS+)</citetitle></olink> for a more
detailed description of NIS+ security.</para><para>For information on making the transition from NIS+ to LDAP, see <olink targetptr="nisplus2ldap-1" remap="internal">Chapter&nbsp;16, Transitioning From NIS+ to LDAP</olink>.</para>
</sect2><sect2 id="intro2nds-7"><title>Description of the LDAP Naming Services</title><para>The Solaris Operating System supports LDAP (Lightweight Directory Access
Protocol) in conjunction with the Sun Java System Directory Server (formerly Sun ONE Directory Server), as well
as other LDAP directory servers.</para><para>See <olink targetptr="overview-1" remap="internal">Chapter&nbsp;8, Introduction to LDAP
Naming Services (Overview/Reference)</olink> for more information about LDAP
naming services.</para><para>For information about transitioning from NIS to LDAP or NIS+ to LDAP,
see <olink targetptr="nis2ldap-34" remap="internal">Chapter&nbsp;15, Transitioning From NIS
to LDAP (Overview/Tasks)</olink> or <olink targetptr="nisplus2ldap-1" remap="internal">Chapter&nbsp;16,
Transitioning From NIS+ to LDAP</olink>.</para><para>For information on single sign on, as well as the setup and maintenance
of Kerberos authentication services, refer to the sections on Kerberos Services
in the <olink targetdoc="sysadv6" remap="external"><citetitle remap="book">System Administration Guide: Security Services</citetitle></olink>.</para>
</sect2>
</sect1><sect1 id="intro2ns-5"><title>Naming Services: A Quick Comparison</title><informaltable frame="topbot"><tgroup cols="5" colsep="0" rowsep="0"><?PubTbl tgroup dispwid="7.96in"?><colspec colname="colspec1" colwidth="11.31*"/><colspec colname="colspec2" colwidth="9.10*"/><colspec colname="colspec3" colwidth="9.24*"/><colspec colname="colspec4" colwidth="12.07*"/><colspec colname="colspec6" colwidth="12.19*"/><thead><row rowsep="1"><entry><para></para>
</entry><entry><para>DNS</para>
</entry><entry><para>NIS</para>
</entry><entry><para>NIS+</para>
</entry><entry colname="colspec6"><para>LDAP</para>
</entry>
</row>
</thead><tbody><row><?PubTbl row rht="0.85in"?><entry><para>NAMESPACE</para>
</entry><entry><para>Hierarchical</para>
</entry><entry><para>Flat</para>
</entry><entry><para>Hierarchical</para>
</entry><entry colname="colspec6"><para>Hierarchical</para>
</entry>
</row><row><entry><para>DATA STORAGE</para>
</entry><entry><para>Files/ resource records</para>
</entry><entry><para>2 column maps</para>
</entry><entry><para>Multi-columned tables</para>
</entry><entry colname="colspec6"><para>Directories [varied]</para>
</entry>
</row><row><entry><para>SERVER NAMES</para>
</entry><entry><para>Master/slave</para>
</entry><entry><para>Master/slave</para>
</entry><entry><para>Root master/non-root master primary/secondary cache/stub</para>
</entry><entry colname="colspec6"><para>Master/replica</para>
</entry>
</row><row><entry><para>SECURITY</para>
</entry><entry><para>None</para>
</entry><entry><para>None (root or nothing)</para>
</entry><entry><para>Secure RPC (AUTH_DH)</para><para>Authentication </para>
</entry><entry colname="colspec6"><para>SSL, varied</para>
</entry>
</row><row><entry><para>TRANSPORT</para>
</entry><entry><para>TCP/IP</para>
</entry><entry><para>RPC</para>
</entry><entry><para>RPC</para>
</entry><entry colname="colspec6"><para>TCP/IP</para>
</entry>
</row><row><entry colname="colspec1"><para>SCALE</para>
</entry><entry colname="colspec2"><para>Global</para>
</entry><entry colname="colspec3"><para>LAN</para>
</entry><entry colname="colspec4"><para>LAN</para>
</entry><entry colname="colspec6"><para>Global</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect1>
</chapter><?Pub *0000024031 0?>