svn commit: r42973 - head/en_US.ISO8859-1/books/handbook/network-servers
Dru Lavigne
dru at FreeBSD.org
Wed Oct 16 16:32:58 UTC 2013
Author: dru
Date: Wed Oct 16 16:32:58 2013
New Revision: 42973
URL: http://svnweb.freebsd.org/changeset/doc/42973
Log:
This patch finishes up the NIS section of this chapter. It does the following:
- replaces NISv1 Compatibility section with a note that FreeBSD uses v2
- renames Important Things to Remember to Adding New Users and places it as a subsection of Configuring the NIS Master Server
- removes the reference to auth.log which is now obsolete
- general tightening and clarification
A subsequent white-space patch will follow.
Modified:
head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Wed Oct 16 13:19:44 2013 (r42972)
+++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Wed Oct 16 16:32:58 2013 (r42973)
@@ -1074,6 +1074,9 @@ Exports list on foobar:
configuration data and to add, remove, or modify configuration
data from a single location.</para>
+ <para>&os; uses version 2 of the <acronym>NIS</acronym>
+ protocol.</para>
+
<sect2>
<title><acronym>NIS</acronym> Terms and Processes</title>
@@ -1456,7 +1459,7 @@ nis_client_flags="-S <replaceable>NIS do
<para>It is advisable to remove all entries for system
accounts as well as any user accounts that do not need to
be propagated to the <acronym>NIS</acronym> clients, such
- as the <username>root</username> accounts.</para>
+ as the <username>root</username> and any other administrative accounts.</para>
<note><para>Ensure that the
<filename>/var/yp/master.passwd</filename> is neither
@@ -1506,6 +1509,28 @@ ellington has been setup as an YP master
<programlisting>NOPUSH = "True"</programlisting>
</sect3>
+
+ <sect3>
+ <title>Adding New Users</title>
+
+ <para>Every time a new user is created, the user account must
+ be added to the master <acronym>NIS</acronym> server and
+ the <acronym>NIS</acronym> maps rebuilt. Until this occurs,
+ the new user will not be able to
+ login anywhere except on the <acronym>NIS</acronym>
+ master. For example, to add the new user
+ <username>jsmith</username> to the
+ <literal>test-domain</literal> domain, run these commands on the
+ master server:</para>
+
+ <screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
+&prompt.root; <userinput>cd /var/yp</userinput>
+&prompt.root; <userinput>make test-domain</userinput></screen>
+
+ <para>The user could also be added using
+ <command>adduser jsmith</command>
+ instead of <command>pw useradd jsmith</command>.</para>
+ </sect3>
</sect2>
<sect2>
@@ -1831,37 +1856,24 @@ basie&prompt.root;</screen>
<indexterm><primary>netgroups</primary></indexterm>
- <para>The method shown in the previous section works reasonably
- well for special rules in an environment with small numbers of
- users and/or machines. On larger networks, administrators
- <emphasis>will</emphasis> likely forget to bar some users from
- logging onto sensitive machines, or may even have to modify
- each machine separately, thus losing the main benefit of NIS:
+ <para>Barring specified users from logging on to individual systems
+ becomes unscaleable on
+ larger networks and quickly loses the main benefit of <acronym>NIS</acronym>:
<emphasis>centralized</emphasis> administration.</para>
- <para>The <acronym>NIS</acronym> developers' solution for this
- problem is called <emphasis>netgroups</emphasis>. Their
- purpose and semantics can be compared to the normal groups
- used by &unix; file systems. The main differences are the
+ <para>Netgroups were developed to handle large, complex networks
+ with hundreds of users and machines. Their use is comparable
+ to &unix; groups, where the main difference is the
lack of a numeric ID and the ability to define a netgroup by
including both user accounts and other netgroups.</para>
- <para>Netgroups were developed to handle large, complex networks
- with hundreds of users and machines. On one hand, this is a
- Good Thing in such a situation. On the other hand, this
- complexity makes it almost impossible to explain netgroups
- with really simple examples. The example used in the
- remainder of this section demonstrates this problem.</para>
-
- <para>Let us assume that the successful introduction of
- <acronym>NIS</acronym> in the laboratory caught a superiors'
- interest. The next task is to extend the
- <acronym>NIS</acronym> domain to cover some of the other
- machines on campus. The two tables contain the names of the
- new users and new machines as well as brief descriptions of
- them.</para>
+ <para>To expand on the example used in this chapter, the
+ <acronym>NIS</acronym> domain will be extended to add the users
+ and systems shown in Tables 28.2 and 28.3:</para>
+
+ <table frame="none" pgwide="1">
+ <title>Additional Users</title>
- <informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
@@ -1874,32 +1886,34 @@ basie&prompt.root;</screen>
<row>
<entry><username>alpha</username>,
<username>beta</username></entry>
- <entry>Normal employees of the IT department</entry>
+ <entry>IT department employees</entry>
</row>
<row>
<entry><username>charlie</username>,
<username>delta</username></entry>
- <entry>The new apprentices of the IT department</entry>
+ <entry>IT department apprentices</entry>
</row>
<row>
<entry><username>echo</username>,
<username>foxtrott</username>,
<username>golf</username>, ...</entry>
- <entry>Ordinary employees</entry>
+ <entry>employees</entry>
</row>
<row>
<entry><username>able</username>,
<username>baker</username>, ...</entry>
- <entry>The current interns</entry>
+ <entry>interns</entry>
</row>
</tbody>
</tgroup>
- </informaltable>
+ </table>
+
+ <table frame="none" pgwide="1">
+ <title>Additional Systems</title>
- <informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
@@ -1915,9 +1929,8 @@ basie&prompt.root;</screen>
<entry><hostid>war</hostid>,
<hostid>death</hostid>, <hostid>famine</hostid>,
<hostid>pollution</hostid></entry>
- <entry>The most important servers deployed. Only the IT
- employees are allowed to log onto these
- machines.</entry>
+ <entry>Only IT
+ employees are allowed to log onto these servers.</entry>
</row>
<row>
@@ -1925,62 +1938,47 @@ basie&prompt.root;</screen>
<entry><hostid>pride</hostid>, <hostid>greed</hostid>,
<hostid>envy</hostid>, <hostid>wrath</hostid>,
<hostid>lust</hostid>, <hostid>sloth</hostid></entry>
- <entry>Less important servers. All members of the IT
+ <entry>All members of the IT
department are allowed to login onto these
- machines.</entry>
+ servers.</entry>
</row>
<row>
<entry><hostid>one</hostid>, <hostid>two</hostid>,
<hostid>three</hostid>, <hostid>four</hostid>,
...</entry>
- <entry>Ordinary workstations. Only the
- <emphasis>real</emphasis> employees are allowed to use
- these machines.</entry>
+ <entry>Ordinary workstations used by
+ employees.</entry>
</row>
<row>
<entry><hostid>trashcan</hostid></entry>
<entry>A very old machine without any critical data.
- Even the intern is allowed to use this box.</entry>
+ Even interns are allowed to use this system.</entry>
</row>
</tbody>
</tgroup>
- </informaltable>
+ </table>
- <para>An attempt to implement these restrictions by separately
- blocking each user, would require the addition of the
- <literal>-<replaceable>user</replaceable></literal> line to
- each system's <filename>passwd</filename>. One line for each
- user who is not allowed to login onto that system. Forgetting
- just one entry could cause significant trouble. It may be
- feasible to do this correctly during the initial setup;
- however, eventually someone will forget to add these lines for
- new users.</para>
-
- <para>Handling this situation with netgroups offers several
- advantages. Each user need not be handled separately; they
- would be assigned to one or more netgroups and logins would be
- allowed or forbidden for all members of the netgroup. While
+ <para>When using netgroups to configure this scenario,
+ each user is
+ assigned to one or more netgroups and logins are then
+ allowed or forbidden for all members of the netgroup. When
adding a new machine, login restrictions must be defined for
- all netgroups. If a new user is added, they must be added to
- one or more netgroups. Those changes are independent of each
- other: no more <quote>for each combination of user and machine
- do...</quote> If the <acronym>NIS</acronym> setup is
+ all netgroups. When a new user is added, the account must be added to
+ one or more netgroups. If the <acronym>NIS</acronym> setup is
planned carefully, only one central configuration file needs
modification to grant or deny access to machines.</para>
<para>The first step is the initialization of the
- <acronym>NIS</acronym> map netgroup. &os;'s &man.ypinit.8;
- does not create this map by default, but its
- <acronym>NIS</acronym> implementation will support it after
- creation. To create an empty map, simply type</para>
-
- <screen>ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput></screen>
-
- <para>and begin adding content. For our example, we need at
- least four netgroups: IT employees, IT apprentices, normal
- employees and interns.</para>
+ <acronym>NIS</acronym> <literal>netgroup</literal> map. In &os;,
+ this map is not created by default. On the
+ <acronym>NIS</acronym> master server, use an editor to create
+ a map named <filename>/var/yp/netgroup</filename>.</para>
+
+ <para>This example creates
+ four netgroups to represent IT employees, IT apprentices,
+ employees, and interns:</para>
<programlisting>IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
@@ -1988,17 +1986,17 @@ USERS (,echo,test-domain) (,foxtro
(,golf,test-domain)
INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
- <para><literal>IT_EMP</literal>, <literal>IT_APP</literal> etc.
- are the names of the netgroups. Each bracketed group adds
- one or more user accounts to it. The three fields inside a
- group are:</para>
+ <para>Each entry configures a netgroup. The first column in an entry
+ is the name of the netgroup. Each set of brackets represents
+ either a group of one or more users or the name of another netgroup.
+ When specifying a user, the three comma-delimited fields inside each
+ group represent:</para>
<orderedlist>
<listitem>
- <para>The name of the host(s) where the following items are
+ <para>The name of the host(s) where the other fields representing the user are
valid. If a hostname is not specified, the entry is valid
- on all hosts. If a hostname is specified, it will need to
- be micro-managed within this configuration.</para>
+ on all hosts.</para>
</listitem>
<listitem>
@@ -2013,38 +2011,34 @@ INTERNS (,able,test-domain) (,baker,
</listitem>
</orderedlist>
- <para>Each of these fields may contain wildcards. See
+ <para>If a group contains multiple users, separate each user with
+ whitespace. Additionally, each field may contain wildcards. See
&man.netgroup.5; for details.</para>
- <note>
<indexterm><primary>netgroups</primary></indexterm>
<para>Netgroup names longer than 8 characters should not be
- used, especially with machines running other operating
- systems within the <acronym>NIS</acronym> domain. The names
- are case sensitive; using capital letters for netgroup names
+ used. The names
+ are case sensitive and using capital letters for netgroup names
is an easy way to distinguish between user, machine and
netgroup names.</para>
- <para>Some <acronym>NIS</acronym> clients (other than &os;)
- cannot handle netgroups with a large number of entries. For
- example, some older versions of &sunos; start to cause
- trouble if a netgroup contains more than 15
- <emphasis>entries</emphasis>. This limit may be
+ <para>Some non-&os; <acronym>NIS</acronym> clients
+ cannot handle netgroups containing more than 15
+ entries. This limit may be
circumvented by creating several sub-netgroups with 15 users
or fewer and a real netgroup consisting of the
- sub-netgroups:</para>
+ sub-netgroups, as seen in this example:</para>
<programlisting>BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...]
BIGGRP2 (,joe16,domain) (,joe17,domain) [...]
BIGGRP3 (,joe31,domain) (,joe32,domain)
BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting>
- <para>Repeat this process if more than 225 users will exist
+ <para>Repeat this process if more than 225 (15 times 15) users exist
within a single netgroup.</para>
- </note>
- <para>Activating and distributing the new
- <acronym>NIS</acronym> map is easy:</para>
+ <para>To activate and distribute the new
+ <acronym>NIS</acronym> map:</para>
<screen>ellington&prompt.root; <userinput>cd /var/yp</userinput>
ellington&prompt.root; <userinput>make</userinput></screen>
@@ -2052,7 +2046,7 @@ ellington&prompt.root; <userinput>make</
<para>This will generate the three <acronym>NIS</acronym> maps
<filename>netgroup</filename>,
<filename>netgroup.byhost</filename> and
- <filename>netgroup.byuser</filename>. Use &man.ypcat.1; to
+ <filename>netgroup.byuser</filename>. Use the map key option of &man.ypcat.1; to
check if the new <acronym>NIS</acronym> maps are
available:</para>
@@ -2062,13 +2056,14 @@ ellington&prompt.user; <userinput>ypcat
<para>The output of the first command should resemble the
contents of <filename>/var/yp/netgroup</filename>. The second
- command will not produce output without specified
- host-specific netgroups. The third command may be used to get
+ command only produces output if
+ host-specific netgroups were created. The third command is used to get
the list of netgroups for a user.</para>
- <para>The client setup is quite simple. To configure the server
- <hostid>war</hostid>, use &man.vipw.8; to replace the
- line</para>
+ <para>To configure a client, use &man.vipw.8; to specify the name
+ of the netgroup. For example, on the server named
+ <hostid>war</hostid>, replace this
+ line:</para>
<programlisting>+:::::::::</programlisting>
@@ -2076,85 +2071,63 @@ ellington&prompt.user; <userinput>ypcat
<programlisting>+ at IT_EMP:::::::::</programlisting>
- <para>Now, only the data for the users defined in the netgroup
- <literal>IT_EMP</literal> is imported into
- <hostid>war</hostid>'s password database and only these users
- are allowed to login.</para>
-
- <para>Unfortunately, this limitation also applies to the
- <literal>~</literal> function of the shell and all routines
- converting between user names and numerical user IDs. In
+ <para>This specifies that only the users defined in the netgroup
+ <literal>IT_EMP</literal> will be imported into this system's
+ password database and only those users
+ are allowed to login to this system.</para>
+
+ <para>This configuration also applies to the
+ <literal>~</literal> function of the shell and all routines which
+ convert between user names and numerical user IDs. In
other words,
<command>cd ~<replaceable>user</replaceable></command> will
not work, <command>ls -l</command> will show the numerical ID
- instead of the username and
- <command>find . -user joe -print</command> will fail with
+ instead of the username, and
+ <command>find . -user joe -print</command> will fail with the message
<errorname>No such user</errorname>. To fix this, import all
- user entries <emphasis>without allowing them to login into the
- servers</emphasis>.</para>
-
- <para>This can be achieved by adding another line to
- <filename>/etc/master.passwd</filename>. This line should
- contain:</para>
-
- <para><literal>+:::::::::/sbin/nologin</literal>, meaning
- <quote>Import all entries but replace the shell with
- <filename>/sbin/nologin</filename> in the imported
- entries</quote>. It is possible to replace any field in the
- <literal>passwd</literal> entry by placing a default value in
- <filename>/etc/master.passwd</filename>.</para>
+ user entries without allowing them to login into the
+ servers. This can be achieved by adding an extra line:</para>
+
+ <programlisting>+:::::::::/sbin/nologin</programlisting>
+
+ <para>This line configures the client to
+ import all entries but to replace the shell in those entries with
+ <filename>/sbin/nologin</filename>.</para>
<!-- Been there, done that, got the scars to prove it - ue -->
- <warning>
- <para>Make sure that the line
- <literal>+:::::::::/sbin/nologin</literal> is placed after
+ <para>Make sure that extra line
+ is placed <emphasis>after</emphasis>
<literal>+ at IT_EMP:::::::::</literal>. Otherwise, all user
accounts imported from <acronym>NIS</acronym> will have
<filename>/sbin/nologin</filename> as their login
- shell.</para>
- </warning>
+ shell and noone will be able to login to the system.</para>
- <para>After this change, the <acronym>NIS</acronym> map will
- only need modification when a new employee joins the IT
- department. A similar approach for the less important servers
- may be used by replacing the old <literal>+:::::::::</literal>
- in their local version of
- <filename>/etc/master.passwd</filename> with something like
- this:</para>
+ <para>To configure the less important servers,
+ replace the old <literal>+:::::::::</literal>
+ on the servers with these lines:</para>
<programlisting>+ at IT_EMP:::::::::
+ at IT_APP:::::::::
+:::::::::/sbin/nologin</programlisting>
- <para>The corresponding lines for the normal workstations
- could be:</para>
+ <para>The corresponding lines for the workstations
+ would be:</para>
<programlisting>+ at IT_EMP:::::::::
+ at USERS:::::::::
+:::::::::/sbin/nologin</programlisting>
- <para>And everything would be fine until there is a policy
- change a few weeks later: The IT department starts hiring
- interns. The IT interns are allowed to use the normal
- workstations and the less important servers; and the IT
- apprentices are allowed to login onto the main servers. Add a
- new netgroup <literal>IT_INTERN</literal>, then add the new IT
- interns to this netgroup and start to change the configuration
- on each and every machine. As the old saying goes:
- <quote>Errors in centralized planning lead to global
- mess</quote>.</para>
-
- <para>NIS' ability to create netgroups from other netgroups can
- be used to prevent situations like these. One possibility is
+ <para>NIS supports the creation of netgroups from other netgroups which
+ can be useful if the policy regarding user access changes. One possibility is
the creation of role-based netgroups. For example, one might
create a netgroup called <literal>BIGSRV</literal> to define
the login restrictions for the important servers, another
netgroup called <literal>SMALLSRV</literal> for the less
- important servers and a third netgroup called
- <literal>USERBOX</literal> for the normal workstations. Each
+ important servers, and a third netgroup called
+ <literal>USERBOX</literal> for the workstations. Each
of these netgroups contains the netgroups that are allowed to
login onto these machines. The new entries for the
- <acronym>NIS</acronym> map netgroup should look like
+ <acronym>NIS</acronym> <literal>netgroup</literal> map would look like
this:</para>
<programlisting>BIGSRV IT_EMP IT_APP
@@ -2168,16 +2141,15 @@ USERBOX IT_EMP ITINTERN USERS</progra
to define login restrictions on a per-machine basis is
required.</para>
- <para>Machine-specific netgroup definitions are the other
- possibility to deal with the policy change outlined above. In
+ <para>Machine-specific netgroup definitions are another
+ possibility to deal with the policy changes. In
this scenario, the <filename>/etc/master.passwd</filename> of
- each box contains two lines starting with <quote>+</quote>.
- The first of them adds a netgroup with the accounts allowed to
- login onto this machine, the second one adds all other
+ each system contains two lines starting with <quote>+</quote>.
+ The first line adds a netgroup with the accounts allowed to
+ login onto this machine and the second line adds all other
accounts with <filename>/sbin/nologin</filename> as shell. It
- is a good idea to use the <quote>ALL-CAPS</quote> version of
- the machine name as the name of the netgroup. In other words,
- the lines should look like this:</para>
+ is recommended to use the <quote>ALL-CAPS</quote> version of
+ the hostname as the name of the netgroup:</para>
<programlisting>+@<replaceable>BOXNAME</replaceable>:::::::::
+:::::::::/sbin/nologin</programlisting>
@@ -2187,8 +2159,7 @@ USERBOX IT_EMP ITINTERN USERS</progra
<filename>/etc/master.passwd</filename> ever again. All
further changes can be handled by modifying the
<acronym>NIS</acronym> map. Here is an example of a possible
- netgroup map for this scenario with some additional
- goodies:</para>
+ <literal>netgroup</literal> map for this scenario:</para>
<programlisting># Define groups of users first
IT_EMP (,alpha,test-domain) (,beta,test-domain)
@@ -2226,159 +2197,55 @@ ONE SECURITY
TWO (,hotel,test-domain)
# [...more groups to follow]</programlisting>
- <para>If some kind of database is used to manage the user
- accounts, it may be possible to create the first part of the
- map using the database's reporting tools. This way, new users
- will automatically have access to the boxes.</para>
-
- <para>One last word of caution: It may not always be advisable
+ <para>It may not always be advisable
to use machine-based netgroups. When deploying a couple of
- dozen or even hundreds of identical machines for student labs,
+ dozen or hundreds of systems,
role-based netgroups instead of machine-based netgroups may be
used to keep the size of the <acronym>NIS</acronym> map within
reasonable limits.</para>
</sect2>
<sect2>
- <title>Important Things to Remember</title>
-
- <para>There are still a couple of things administrators need to
- do differently now that machines are in an NIS
- environment.</para>
-
- <itemizedlist>
- <listitem>
- <para>Every time a new user is added to the lab, they must
- be added to the master <acronym>NIS</acronym> server and
- the <acronym>NIS</acronym> maps will need rebuilt. If
- this step is omitted, the new user will not be able to
- login anywhere except on the <acronym>NIS</acronym>
- master. For example, if we needed to add a new user
- <username>jsmith</username> to the lab, we would:</para>
-
- <screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
-&prompt.root; <userinput>cd /var/yp</userinput>
-&prompt.root; <userinput>make test-domain</userinput></screen>
-
- <para>The user may also be added using
- <command>adduser jsmith</command>
- instead of <command>pw useradd jsmith</command>.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>Keep the administration accounts out of the
- <acronym>NIS</acronym> maps</emphasis>. This is
- undesirable as it will create a security risk. These
- users and passwords should not be propagated to all
- machines. Especially if these machines will have users
- whom should not have access to those accounts.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>Keep the <acronym>NIS</acronym> master and
- slave secure, and minimize their downtime</emphasis>.
- If somebody either hacks or simply turns off these
- machines, they have effectively rendered many people
- without the ability to login to the lab.</para>
-
- <para>This is the chief weakness of any centralized
- administration system. If the <acronym>NIS</acronym>
- servers are not protected, there will be a lot of angry
- users and unhappy management!</para>
- </listitem>
- </itemizedlist>
- </sect2>
-
- <sect2>
- <title><acronym>NIS</acronym> v1 Compatibility</title>
-
- <para>&os;'s <application>ypserv</application> has some support
- for serving <acronym>NIS</acronym> v1 clients. &os;'s
- <acronym>NIS</acronym> implementation only uses the
- <acronym>NIS</acronym> v2 protocol; however, other
- implementations include support for the v1 protocol for
- backwards compatibility with older systems. The
- <application>ypbind</application> daemons supplied with these
- systems will attempt to establish a binding to an
- <acronym>NIS</acronym>v1 server even though they may never
- actually need it (and they may persist in broadcasting in
- search of one even after they receive a response from a v2
- server). Note that while support for normal client calls is
- provided, this version of
- <application>ypserv</application> does not handle v1 map
- transfer requests. Additionally, it cannot be used as a
- master or slave in conjunction with older
- <acronym>NIS</acronym> servers that only support the v1
- protocol. Fortunately, there probably are not any such
- servers still in use today.</para>
- </sect2>
-
- <sect2>
<title>Password Formats</title>
<indexterm>
<primary>NIS</primary>
<secondary>password formats</secondary>
</indexterm>
- <para>One of the most common issues that people run into when
- trying to implement <acronym>NIS</acronym> is password format
- compatibility. If the <acronym>NIS</acronym> server is using
- DES encrypted passwords, it will only support clients that are
- also using DES. For example, if any &solaris;
- <acronym>NIS</acronym> clients exist on the network, there is
- a highly likelihood DES must be used for encrypted
- passwords.</para>
-
- <para>To check which format the servers and clients are using,
- look at <filename>/etc/login.conf</filename>. If the host is
- configured to use DES encrypted passwords, then the
- <literal>default</literal> class will contain an entry like
- this:</para>
+ <para><acronym>NIS</acronym> requires that all hosts within an
+ <acronym>NIS</acronym> domain use the same format for encrypting passwords.
+ If users have trouble authenticating on an
+ <acronym>NIS</acronym> client, it may be due to a differing password format.
+ In a heterogeneous network, the format must be supported by all operating systems, where
+ <acronym>DES</acronym>
+ is the lowest common standard.</para>
+
+ <para>To check which format a server or client is using,
+ look at this section of <filename>/etc/login.conf</filename>:</para>
<programlisting>default:\
:passwd_format=des:\
:copyright=/etc/COPYRIGHT:\
[Further entries elided]</programlisting>
- <para>Other possible values for the
- <literal>passwd_format</literal> capability include
- <literal>blf</literal> and <literal>md5</literal> (for
- Blowfish and MD5 encrypted passwords, respectively).</para>
-
- <para>If any changes were made to
- <filename>/etc/login.conf</filename>, the login capability
- database must be rebuilt by running the following command as
- <username>root</username>:</para>
+ <para>In this example, the system is using the <acronym>DES</acronym>
+ format. Other possible values are
+ <literal>blf</literal> for Blowfish and <literal>md5</literal> for
+ MD5 encrypted passwords.</para>
+
+ <para>If the format on a host needs to be edited to match the one
+ being used in the <acronym>NIS</acronym> domain,
+ the login capability
+ database must be rebuilt after saving the change:</para>
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
<note>
- <para>The format of passwords already in
- <filename>/etc/master.passwd</filename> will not be updated
- until a user changes his password for the first time
+ <para>The format of passwords for existing user accounts will not be updated
+ until each user changes their password
<emphasis>after</emphasis> the login capability database is
rebuilt.</para>
</note>
-
- <para>Next, in order to ensure that passwords are encrypted with
- the chosen format, check that the
- <literal>crypt_default</literal> in
- <filename>/etc/auth.conf</filename> gives precedence to the
- chosen password format. To do this, place the chosen format
- first in the list. For example, when using DES encrypted
- passwords, the entry would be:</para>
-
- <programlisting>crypt_default = des blf md5</programlisting>
-
- <para>Having followed the above steps on each of the &os; based
- <acronym>NIS</acronym> servers and clients, verify that they
- all agree on which password format is used within the network.
- If users have trouble authenticating on an
- <acronym>NIS</acronym> client, this is a pretty good place to
- start looking for possible problems. Remember: to deploy an
- <acronym>NIS</acronym> server for a heterogeneous network,
- they will probably have to use DES on all systems because it
- is the lowest common standard.</para>
</sect2>
</sect1>
More information about the svn-doc-head
mailing list