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
|
configuration data and to add, remove, or modify configuration
|
||||||
data from a single location.</para>
|
data from a single location.</para>
|
||||||
|
|
||||||
|
<para>&os; uses version 2 of the <acronym>NIS</acronym>
|
||||||
|
protocol.</para>
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
<title><acronym>NIS</acronym> Terms and Processes</title>
|
<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
|
<para>It is advisable to remove all entries for system
|
||||||
accounts as well as any user accounts that do not need to
|
accounts as well as any user accounts that do not need to
|
||||||
be propagated to the <acronym>NIS</acronym> clients, such
|
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
|
<note><para>Ensure that the
|
||||||
<filename>/var/yp/master.passwd</filename> is neither
|
<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>
|
<programlisting>NOPUSH = "True"</programlisting>
|
||||||
</sect3>
|
</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>
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
|
|
@ -1831,37 +1856,24 @@ basie&prompt.root;</screen>
|
||||||
|
|
||||||
<indexterm><primary>netgroups</primary></indexterm>
|
<indexterm><primary>netgroups</primary></indexterm>
|
||||||
|
|
||||||
<para>The method shown in the previous section works reasonably
|
<para>Barring specified users from logging on to individual systems
|
||||||
well for special rules in an environment with small numbers of
|
becomes unscaleable on
|
||||||
users and/or machines. On larger networks, administrators
|
larger networks and quickly loses the main benefit of <acronym>NIS</acronym>:
|
||||||
<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:
|
|
||||||
<emphasis>centralized</emphasis> administration.</para>
|
<emphasis>centralized</emphasis> administration.</para>
|
||||||
|
|
||||||
<para>The <acronym>NIS</acronym> developers' solution for this
|
<para>Netgroups were developed to handle large, complex networks
|
||||||
problem is called <emphasis>netgroups</emphasis>. Their
|
with hundreds of users and machines. Their use is comparable
|
||||||
purpose and semantics can be compared to the normal groups
|
to &unix; groups, where the main difference is the
|
||||||
used by &unix; file systems. The main differences are the
|
|
||||||
lack of a numeric ID and the ability to define a netgroup by
|
lack of a numeric ID and the ability to define a netgroup by
|
||||||
including both user accounts and other netgroups.</para>
|
including both user accounts and other netgroups.</para>
|
||||||
|
|
||||||
<para>Netgroups were developed to handle large, complex networks
|
<para>To expand on the example used in this chapter, the
|
||||||
with hundreds of users and machines. On one hand, this is a
|
<acronym>NIS</acronym> domain will be extended to add the users
|
||||||
Good Thing in such a situation. On the other hand, this
|
and systems shown in Tables 28.2 and 28.3:</para>
|
||||||
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
|
<table frame="none" pgwide="1">
|
||||||
<acronym>NIS</acronym> in the laboratory caught a superiors'
|
<title>Additional Users</title>
|
||||||
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>
|
|
||||||
|
|
||||||
<informaltable frame="none" pgwide="1">
|
|
||||||
<tgroup cols="2">
|
<tgroup cols="2">
|
||||||
<thead>
|
<thead>
|
||||||
<row>
|
<row>
|
||||||
|
|
@ -1874,32 +1886,34 @@ basie&prompt.root;</screen>
|
||||||
<row>
|
<row>
|
||||||
<entry><username>alpha</username>,
|
<entry><username>alpha</username>,
|
||||||
<username>beta</username></entry>
|
<username>beta</username></entry>
|
||||||
<entry>Normal employees of the IT department</entry>
|
<entry>IT department employees</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><username>charlie</username>,
|
<entry><username>charlie</username>,
|
||||||
<username>delta</username></entry>
|
<username>delta</username></entry>
|
||||||
<entry>The new apprentices of the IT department</entry>
|
<entry>IT department apprentices</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><username>echo</username>,
|
<entry><username>echo</username>,
|
||||||
<username>foxtrott</username>,
|
<username>foxtrott</username>,
|
||||||
<username>golf</username>, ...</entry>
|
<username>golf</username>, ...</entry>
|
||||||
<entry>Ordinary employees</entry>
|
<entry>employees</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><username>able</username>,
|
<entry><username>able</username>,
|
||||||
<username>baker</username>, ...</entry>
|
<username>baker</username>, ...</entry>
|
||||||
<entry>The current interns</entry>
|
<entry>interns</entry>
|
||||||
</row>
|
</row>
|
||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</informaltable>
|
</table>
|
||||||
|
|
||||||
|
<table frame="none" pgwide="1">
|
||||||
|
<title>Additional Systems</title>
|
||||||
|
|
||||||
<informaltable frame="none" pgwide="1">
|
|
||||||
<tgroup cols="2">
|
<tgroup cols="2">
|
||||||
<thead>
|
<thead>
|
||||||
<row>
|
<row>
|
||||||
|
|
@ -1915,9 +1929,8 @@ basie&prompt.root;</screen>
|
||||||
<entry><hostid>war</hostid>,
|
<entry><hostid>war</hostid>,
|
||||||
<hostid>death</hostid>, <hostid>famine</hostid>,
|
<hostid>death</hostid>, <hostid>famine</hostid>,
|
||||||
<hostid>pollution</hostid></entry>
|
<hostid>pollution</hostid></entry>
|
||||||
<entry>The most important servers deployed. Only the IT
|
<entry>Only IT
|
||||||
employees are allowed to log onto these
|
employees are allowed to log onto these servers.</entry>
|
||||||
machines.</entry>
|
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
|
|
@ -1925,62 +1938,47 @@ basie&prompt.root;</screen>
|
||||||
<entry><hostid>pride</hostid>, <hostid>greed</hostid>,
|
<entry><hostid>pride</hostid>, <hostid>greed</hostid>,
|
||||||
<hostid>envy</hostid>, <hostid>wrath</hostid>,
|
<hostid>envy</hostid>, <hostid>wrath</hostid>,
|
||||||
<hostid>lust</hostid>, <hostid>sloth</hostid></entry>
|
<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
|
department are allowed to login onto these
|
||||||
machines.</entry>
|
servers.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><hostid>one</hostid>, <hostid>two</hostid>,
|
<entry><hostid>one</hostid>, <hostid>two</hostid>,
|
||||||
<hostid>three</hostid>, <hostid>four</hostid>,
|
<hostid>three</hostid>, <hostid>four</hostid>,
|
||||||
...</entry>
|
...</entry>
|
||||||
<entry>Ordinary workstations. Only the
|
<entry>Ordinary workstations used by
|
||||||
<emphasis>real</emphasis> employees are allowed to use
|
employees.</entry>
|
||||||
these machines.</entry>
|
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><hostid>trashcan</hostid></entry>
|
<entry><hostid>trashcan</hostid></entry>
|
||||||
<entry>A very old machine without any critical data.
|
<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>
|
</row>
|
||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</informaltable>
|
</table>
|
||||||
|
|
||||||
<para>An attempt to implement these restrictions by separately
|
<para>When using netgroups to configure this scenario,
|
||||||
blocking each user, would require the addition of the
|
each user is
|
||||||
<literal>-<replaceable>user</replaceable></literal> line to
|
assigned to one or more netgroups and logins are then
|
||||||
each system's <filename>passwd</filename>. One line for each
|
allowed or forbidden for all members of the netgroup. When
|
||||||
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
|
|
||||||
adding a new machine, login restrictions must be defined for
|
adding a new machine, login restrictions must be defined for
|
||||||
all netgroups. If a new user is added, they must be added to
|
all netgroups. When a new user is added, the account must be added to
|
||||||
one or more netgroups. Those changes are independent of each
|
one or more netgroups. If the <acronym>NIS</acronym> setup is
|
||||||
other: no more <quote>for each combination of user and machine
|
|
||||||
do...</quote> If the <acronym>NIS</acronym> setup is
|
|
||||||
planned carefully, only one central configuration file needs
|
planned carefully, only one central configuration file needs
|
||||||
modification to grant or deny access to machines.</para>
|
modification to grant or deny access to machines.</para>
|
||||||
|
|
||||||
<para>The first step is the initialization of the
|
<para>The first step is the initialization of the
|
||||||
<acronym>NIS</acronym> map netgroup. &os;'s &man.ypinit.8;
|
<acronym>NIS</acronym> <literal>netgroup</literal> map. In &os;,
|
||||||
does not create this map by default, but its
|
this map is not created by default. On the
|
||||||
<acronym>NIS</acronym> implementation will support it after
|
<acronym>NIS</acronym> master server, use an editor to create
|
||||||
creation. To create an empty map, simply type</para>
|
a map named <filename>/var/yp/netgroup</filename>.</para>
|
||||||
|
|
||||||
<screen>ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput></screen>
|
<para>This example creates
|
||||||
|
four netgroups to represent IT employees, IT apprentices,
|
||||||
<para>and begin adding content. For our example, we need at
|
employees, and interns:</para>
|
||||||
least four netgroups: IT employees, IT apprentices, normal
|
|
||||||
employees and interns.</para>
|
|
||||||
|
|
||||||
<programlisting>IT_EMP (,alpha,test-domain) (,beta,test-domain)
|
<programlisting>IT_EMP (,alpha,test-domain) (,beta,test-domain)
|
||||||
IT_APP (,charlie,test-domain) (,delta,test-domain)
|
IT_APP (,charlie,test-domain) (,delta,test-domain)
|
||||||
|
|
@ -1988,17 +1986,17 @@ USERS (,echo,test-domain) (,foxtrott,test-domain) \
|
||||||
(,golf,test-domain)
|
(,golf,test-domain)
|
||||||
INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
|
INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
|
||||||
|
|
||||||
<para><literal>IT_EMP</literal>, <literal>IT_APP</literal> etc.
|
<para>Each entry configures a netgroup. The first column in an entry
|
||||||
are the names of the netgroups. Each bracketed group adds
|
is the name of the netgroup. Each set of brackets represents
|
||||||
one or more user accounts to it. The three fields inside a
|
either a group of one or more users or the name of another netgroup.
|
||||||
group are:</para>
|
When specifying a user, the three comma-delimited fields inside each
|
||||||
|
group represent:</para>
|
||||||
|
|
||||||
<orderedlist>
|
<orderedlist>
|
||||||
<listitem>
|
<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
|
valid. If a hostname is not specified, the entry is valid
|
||||||
on all hosts. If a hostname is specified, it will need to
|
on all hosts.</para>
|
||||||
be micro-managed within this configuration.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
|
|
@ -2013,38 +2011,34 @@ INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
|
||||||
</listitem>
|
</listitem>
|
||||||
</orderedlist>
|
</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>
|
&man.netgroup.5; for details.</para>
|
||||||
|
|
||||||
<note>
|
|
||||||
<indexterm><primary>netgroups</primary></indexterm>
|
<indexterm><primary>netgroups</primary></indexterm>
|
||||||
<para>Netgroup names longer than 8 characters should not be
|
<para>Netgroup names longer than 8 characters should not be
|
||||||
used, especially with machines running other operating
|
used. The names
|
||||||
systems within the <acronym>NIS</acronym> domain. The names
|
are case sensitive and using capital letters for netgroup names
|
||||||
are case sensitive; using capital letters for netgroup names
|
|
||||||
is an easy way to distinguish between user, machine and
|
is an easy way to distinguish between user, machine and
|
||||||
netgroup names.</para>
|
netgroup names.</para>
|
||||||
|
|
||||||
<para>Some <acronym>NIS</acronym> clients (other than &os;)
|
<para>Some non-&os; <acronym>NIS</acronym> clients
|
||||||
cannot handle netgroups with a large number of entries. For
|
cannot handle netgroups containing more than 15
|
||||||
example, some older versions of &sunos; start to cause
|
entries. This limit may be
|
||||||
trouble if a netgroup contains more than 15
|
|
||||||
<emphasis>entries</emphasis>. This limit may be
|
|
||||||
circumvented by creating several sub-netgroups with 15 users
|
circumvented by creating several sub-netgroups with 15 users
|
||||||
or fewer and a real netgroup consisting of the
|
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) [...]
|
<programlisting>BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...]
|
||||||
BIGGRP2 (,joe16,domain) (,joe17,domain) [...]
|
BIGGRP2 (,joe16,domain) (,joe17,domain) [...]
|
||||||
BIGGRP3 (,joe31,domain) (,joe32,domain)
|
BIGGRP3 (,joe31,domain) (,joe32,domain)
|
||||||
BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting>
|
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>
|
within a single netgroup.</para>
|
||||||
</note>
|
|
||||||
|
|
||||||
<para>Activating and distributing the new
|
<para>To activate and distribute the new
|
||||||
<acronym>NIS</acronym> map is easy:</para>
|
<acronym>NIS</acronym> map:</para>
|
||||||
|
|
||||||
<screen>ellington&prompt.root; <userinput>cd /var/yp</userinput>
|
<screen>ellington&prompt.root; <userinput>cd /var/yp</userinput>
|
||||||
ellington&prompt.root; <userinput>make</userinput></screen>
|
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
|
<para>This will generate the three <acronym>NIS</acronym> maps
|
||||||
<filename>netgroup</filename>,
|
<filename>netgroup</filename>,
|
||||||
<filename>netgroup.byhost</filename> and
|
<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
|
check if the new <acronym>NIS</acronym> maps are
|
||||||
available:</para>
|
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
|
<para>The output of the first command should resemble the
|
||||||
contents of <filename>/var/yp/netgroup</filename>. The second
|
contents of <filename>/var/yp/netgroup</filename>. The second
|
||||||
command will not produce output without specified
|
command only produces output if
|
||||||
host-specific netgroups. The third command may be used to get
|
host-specific netgroups were created. The third command is used to get
|
||||||
the list of netgroups for a user.</para>
|
the list of netgroups for a user.</para>
|
||||||
|
|
||||||
<para>The client setup is quite simple. To configure the server
|
<para>To configure a client, use &man.vipw.8; to specify the name
|
||||||
<hostid>war</hostid>, use &man.vipw.8; to replace the
|
of the netgroup. For example, on the server named
|
||||||
line</para>
|
<hostid>war</hostid>, replace this
|
||||||
|
line:</para>
|
||||||
|
|
||||||
<programlisting>+:::::::::</programlisting>
|
<programlisting>+:::::::::</programlisting>
|
||||||
|
|
||||||
|
|
@ -2076,85 +2071,63 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
|
||||||
|
|
||||||
<programlisting>+@IT_EMP:::::::::</programlisting>
|
<programlisting>+@IT_EMP:::::::::</programlisting>
|
||||||
|
|
||||||
<para>Now, only the data for the users defined in the netgroup
|
<para>This specifies that only the users defined in the netgroup
|
||||||
<literal>IT_EMP</literal> is imported into
|
<literal>IT_EMP</literal> will be imported into this system's
|
||||||
<hostid>war</hostid>'s password database and only these users
|
password database and only those users
|
||||||
are allowed to login.</para>
|
are allowed to login to this system.</para>
|
||||||
|
|
||||||
<para>Unfortunately, this limitation also applies to the
|
<para>This configuration also applies to the
|
||||||
<literal>~</literal> function of the shell and all routines
|
<literal>~</literal> function of the shell and all routines which
|
||||||
converting between user names and numerical user IDs. In
|
convert between user names and numerical user IDs. In
|
||||||
other words,
|
other words,
|
||||||
<command>cd ~<replaceable>user</replaceable></command> will
|
<command>cd ~<replaceable>user</replaceable></command> will
|
||||||
not work, <command>ls -l</command> will show the numerical ID
|
not work, <command>ls -l</command> will show the numerical ID
|
||||||
instead of the username and
|
instead of the username, and
|
||||||
<command>find . -user joe -print</command> will fail with
|
<command>find . -user joe -print</command> will fail with the message
|
||||||
<errorname>No such user</errorname>. To fix this, import all
|
<errorname>No such user</errorname>. To fix this, import all
|
||||||
user entries <emphasis>without allowing them to login into the
|
user entries without allowing them to login into the
|
||||||
servers</emphasis>.</para>
|
servers. This can be achieved by adding an extra line:</para>
|
||||||
|
|
||||||
<para>This can be achieved by adding another line to
|
<programlisting>+:::::::::/sbin/nologin</programlisting>
|
||||||
<filename>/etc/master.passwd</filename>. This line should
|
|
||||||
contain:</para>
|
|
||||||
|
|
||||||
<para><literal>+:::::::::/sbin/nologin</literal>, meaning
|
<para>This line configures the client to
|
||||||
<quote>Import all entries but replace the shell with
|
import all entries but to replace the shell in those entries with
|
||||||
<filename>/sbin/nologin</filename> in the imported
|
<filename>/sbin/nologin</filename>.</para>
|
||||||
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>
|
|
||||||
|
|
||||||
<!-- Been there, done that, got the scars to prove it - ue -->
|
<!-- Been there, done that, got the scars to prove it - ue -->
|
||||||
<warning>
|
<para>Make sure that extra line
|
||||||
<para>Make sure that the line
|
is placed <emphasis>after</emphasis>
|
||||||
<literal>+:::::::::/sbin/nologin</literal> is placed after
|
|
||||||
<literal>+@IT_EMP:::::::::</literal>. Otherwise, all user
|
<literal>+@IT_EMP:::::::::</literal>. Otherwise, all user
|
||||||
accounts imported from <acronym>NIS</acronym> will have
|
accounts imported from <acronym>NIS</acronym> will have
|
||||||
<filename>/sbin/nologin</filename> as their login
|
<filename>/sbin/nologin</filename> as their login
|
||||||
shell.</para>
|
shell and noone will be able to login to the system.</para>
|
||||||
</warning>
|
|
||||||
|
|
||||||
<para>After this change, the <acronym>NIS</acronym> map will
|
<para>To configure the less important servers,
|
||||||
only need modification when a new employee joins the IT
|
replace the old <literal>+:::::::::</literal>
|
||||||
department. A similar approach for the less important servers
|
on the servers with these lines:</para>
|
||||||
may be used by replacing the old <literal>+:::::::::</literal>
|
|
||||||
in their local version of
|
|
||||||
<filename>/etc/master.passwd</filename> with something like
|
|
||||||
this:</para>
|
|
||||||
|
|
||||||
<programlisting>+@IT_EMP:::::::::
|
<programlisting>+@IT_EMP:::::::::
|
||||||
+@IT_APP:::::::::
|
+@IT_APP:::::::::
|
||||||
+:::::::::/sbin/nologin</programlisting>
|
+:::::::::/sbin/nologin</programlisting>
|
||||||
|
|
||||||
<para>The corresponding lines for the normal workstations
|
<para>The corresponding lines for the workstations
|
||||||
could be:</para>
|
would be:</para>
|
||||||
|
|
||||||
<programlisting>+@IT_EMP:::::::::
|
<programlisting>+@IT_EMP:::::::::
|
||||||
+@USERS:::::::::
|
+@USERS:::::::::
|
||||||
+:::::::::/sbin/nologin</programlisting>
|
+:::::::::/sbin/nologin</programlisting>
|
||||||
|
|
||||||
<para>And everything would be fine until there is a policy
|
<para>NIS supports the creation of netgroups from other netgroups which
|
||||||
change a few weeks later: The IT department starts hiring
|
can be useful if the policy regarding user access changes. One possibility is
|
||||||
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
|
|
||||||
the creation of role-based netgroups. For example, one might
|
the creation of role-based netgroups. For example, one might
|
||||||
create a netgroup called <literal>BIGSRV</literal> to define
|
create a netgroup called <literal>BIGSRV</literal> to define
|
||||||
the login restrictions for the important servers, another
|
the login restrictions for the important servers, another
|
||||||
netgroup called <literal>SMALLSRV</literal> for the less
|
netgroup called <literal>SMALLSRV</literal> for the less
|
||||||
important servers and a third netgroup called
|
important servers, and a third netgroup called
|
||||||
<literal>USERBOX</literal> for the normal workstations. Each
|
<literal>USERBOX</literal> for the workstations. Each
|
||||||
of these netgroups contains the netgroups that are allowed to
|
of these netgroups contains the netgroups that are allowed to
|
||||||
login onto these machines. The new entries for the
|
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>
|
this:</para>
|
||||||
|
|
||||||
<programlisting>BIGSRV IT_EMP IT_APP
|
<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
|
to define login restrictions on a per-machine basis is
|
||||||
required.</para>
|
required.</para>
|
||||||
|
|
||||||
<para>Machine-specific netgroup definitions are the other
|
<para>Machine-specific netgroup definitions are another
|
||||||
possibility to deal with the policy change outlined above. In
|
possibility to deal with the policy changes. In
|
||||||
this scenario, the <filename>/etc/master.passwd</filename> of
|
this scenario, the <filename>/etc/master.passwd</filename> of
|
||||||
each box contains two lines starting with <quote>+</quote>.
|
each system contains two lines starting with <quote>+</quote>.
|
||||||
The first of them adds a netgroup with the accounts allowed to
|
The first line adds a netgroup with the accounts allowed to
|
||||||
login onto this machine, the second one adds all other
|
login onto this machine and the second line adds all other
|
||||||
accounts with <filename>/sbin/nologin</filename> as shell. It
|
accounts with <filename>/sbin/nologin</filename> as shell. It
|
||||||
is a good idea to use the <quote>ALL-CAPS</quote> version of
|
is recommended to use the <quote>ALL-CAPS</quote> version of
|
||||||
the machine name as the name of the netgroup. In other words,
|
the hostname as the name of the netgroup:</para>
|
||||||
the lines should look like this:</para>
|
|
||||||
|
|
||||||
<programlisting>+@<replaceable>BOXNAME</replaceable>:::::::::
|
<programlisting>+@<replaceable>BOXNAME</replaceable>:::::::::
|
||||||
+:::::::::/sbin/nologin</programlisting>
|
+:::::::::/sbin/nologin</programlisting>
|
||||||
|
|
@ -2187,8 +2159,7 @@ USERBOX IT_EMP ITINTERN USERS</programlisting>
|
||||||
<filename>/etc/master.passwd</filename> ever again. All
|
<filename>/etc/master.passwd</filename> ever again. All
|
||||||
further changes can be handled by modifying the
|
further changes can be handled by modifying the
|
||||||
<acronym>NIS</acronym> map. Here is an example of a possible
|
<acronym>NIS</acronym> map. Here is an example of a possible
|
||||||
netgroup map for this scenario with some additional
|
<literal>netgroup</literal> map for this scenario:</para>
|
||||||
goodies:</para>
|
|
||||||
|
|
||||||
<programlisting># Define groups of users first
|
<programlisting># Define groups of users first
|
||||||
IT_EMP (,alpha,test-domain) (,beta,test-domain)
|
IT_EMP (,alpha,test-domain) (,beta,test-domain)
|
||||||
|
|
@ -2226,93 +2197,14 @@ ONE SECURITY
|
||||||
TWO (,hotel,test-domain)
|
TWO (,hotel,test-domain)
|
||||||
# [...more groups to follow]</programlisting>
|
# [...more groups to follow]</programlisting>
|
||||||
|
|
||||||
<para>If some kind of database is used to manage the user
|
<para>It may not always be advisable
|
||||||
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
|
|
||||||
to use machine-based netgroups. When deploying a couple of
|
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
|
role-based netgroups instead of machine-based netgroups may be
|
||||||
used to keep the size of the <acronym>NIS</acronym> map within
|
used to keep the size of the <acronym>NIS</acronym> map within
|
||||||
reasonable limits.</para>
|
reasonable limits.</para>
|
||||||
</sect2>
|
</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>
|
<sect2>
|
||||||
<title>Password Formats</title>
|
<title>Password Formats</title>
|
||||||
|
|
||||||
|
|
@ -2320,65 +2212,40 @@ TWO (,hotel,test-domain)
|
||||||
<primary>NIS</primary>
|
<primary>NIS</primary>
|
||||||
<secondary>password formats</secondary>
|
<secondary>password formats</secondary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
<para>One of the most common issues that people run into when
|
<para><acronym>NIS</acronym> requires that all hosts within an
|
||||||
trying to implement <acronym>NIS</acronym> is password format
|
<acronym>NIS</acronym> domain use the same format for encrypting passwords.
|
||||||
compatibility. If the <acronym>NIS</acronym> server is using
|
If users have trouble authenticating on an
|
||||||
DES encrypted passwords, it will only support clients that are
|
<acronym>NIS</acronym> client, it may be due to a differing password format.
|
||||||
also using DES. For example, if any &solaris;
|
In a heterogeneous network, the format must be supported by all operating systems, where
|
||||||
<acronym>NIS</acronym> clients exist on the network, there is
|
<acronym>DES</acronym>
|
||||||
a highly likelihood DES must be used for encrypted
|
is the lowest common standard.</para>
|
||||||
passwords.</para>
|
|
||||||
|
|
||||||
<para>To check which format the servers and clients are using,
|
<para>To check which format a server or client is using,
|
||||||
look at <filename>/etc/login.conf</filename>. If the host is
|
look at this section of <filename>/etc/login.conf</filename>:</para>
|
||||||
configured to use DES encrypted passwords, then the
|
|
||||||
<literal>default</literal> class will contain an entry like
|
|
||||||
this:</para>
|
|
||||||
|
|
||||||
<programlisting>default:\
|
<programlisting>default:\
|
||||||
:passwd_format=des:\
|
:passwd_format=des:\
|
||||||
:copyright=/etc/COPYRIGHT:\
|
:copyright=/etc/COPYRIGHT:\
|
||||||
[Further entries elided]</programlisting>
|
[Further entries elided]</programlisting>
|
||||||
|
|
||||||
<para>Other possible values for the
|
<para>In this example, the system is using the <acronym>DES</acronym>
|
||||||
<literal>passwd_format</literal> capability include
|
format. Other possible values are
|
||||||
<literal>blf</literal> and <literal>md5</literal> (for
|
<literal>blf</literal> for Blowfish and <literal>md5</literal> for
|
||||||
Blowfish and MD5 encrypted passwords, respectively).</para>
|
MD5 encrypted passwords.</para>
|
||||||
|
|
||||||
<para>If any changes were made to
|
<para>If the format on a host needs to be edited to match the one
|
||||||
<filename>/etc/login.conf</filename>, the login capability
|
being used in the <acronym>NIS</acronym> domain,
|
||||||
database must be rebuilt by running the following command as
|
the login capability
|
||||||
<username>root</username>:</para>
|
database must be rebuilt after saving the change:</para>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
|
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>The format of passwords already in
|
<para>The format of passwords for existing user accounts will not be updated
|
||||||
<filename>/etc/master.passwd</filename> will not be updated
|
until each user changes their password
|
||||||
until a user changes his password for the first time
|
|
||||||
<emphasis>after</emphasis> the login capability database is
|
<emphasis>after</emphasis> the login capability database is
|
||||||
rebuilt.</para>
|
rebuilt.</para>
|
||||||
</note>
|
</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>
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue