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.
This commit is contained in:
Dru Lavigne
parent
f6bfd1748e
commit
ab6fd8bf05
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=42973
1 changed files with 150 additions and 283 deletions
|
|
@ -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 domain</replaceable>,<replaceable>server</
|
|||
<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 server without any errors.</screen>
|
|||
|
||||
<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>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>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<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>
|
||||
<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) (,foxtrott,test-domain) \
|
|||
(,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,test-domain)</programlisting>
|
|||
</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</userinput></screen>
|
|||
<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 -k netgroup.byuser</userinput></screen>
|
|||
|
||||
<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 -k netgroup.byuser</userinput></screen>
|
|||
|
||||
<programlisting>+@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>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>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 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>
|
||||
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 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>
|
||||
<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>+@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>+@IT_EMP:::::::::
|
||||
+@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>+@IT_EMP:::::::::
|
||||
+@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</programlisting>
|
|||
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</programlisting>
|
|||
<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,93 +2197,14 @@ 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>
|
||||
|
||||
|
|
@ -2320,65 +2212,40 @@ TWO (,hotel,test-domain)
|
|||
<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>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 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>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>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue